Textbook of Digital Health

Introduction

A GP writes a referral letter for a patient with poorly controlled diabetes and sends it to the local hospital's endocrinology department. The letter contains the patient's diagnosis, current medications, recent HbA1c results, and a summary of what has been tried so far. In principle, this is a straightforward exchange of clinical information between two organisations caring for the same person. In practice, it often goes badly wrong.

The GP's clinical system stores diagnoses using one coding scheme, medications using another, and laboratory results in a format that may or may not match what the hospital system expects. The referral might travel as a structured electronic message, a PDF attachment to an email, or - still, in some settings - a dictated letter sent by post. When it arrives, someone at the hospital may need to re-enter information that already exists in the GP record, introducing transcription errors and wasting time. If the hospital clinician later wants to check what happened at a previous admission, they may find that the hospital's own departments use different systems that do not share data with one another.

This scenario, mundane and frustrating, illustrates why interoperability matters. Health data standards exist to solve exactly this problem: they define common formats, vocabularies, and exchange mechanisms so that clinical information can move between systems without losing its meaning. The difficulty is that agreeing on standards is considerably easier than implementing them. After decades of work by standards organisations, governments, and the health IT industry, interoperability remains one of digital health's most persistent challenges.

This chapter examines why health data interoperability is hard, what the major standards are and how they work, and what national programmes are doing to close the gap between aspiration and reality.

Why Interoperability Is Hard

It is tempting to assume that health data interoperability is primarily a technical problem - that if only the right standard were adopted, systems would communicate seamlessly. The reality is more complicated. Interoperability failures have technical, semantic, and organisational dimensions, and addressing one without the others rarely succeeds.

The technical barriers are the most visible. Health IT systems have been developed over decades by hundreds of vendors, each making independent design choices about data storage, message formats, and communication protocols. A hospital might run one system for its emergency department, another for inpatient wards, a third for laboratory results, and a fourth for radiology - each from a different vendor, installed at a different time, using a different internal data model. Getting these systems to exchange data requires interface engines, custom mappings, and ongoing maintenance. Every new system added to the environment multiplies the number of connections that must be built and maintained.

Semantic interoperability - ensuring that data means the same thing in both the sending and receiving system - is harder still. A GP records that a patient has "type 2 diabetes". The hospital system expects a SNOMED CT code. The diabetes registry wants an ICD-10 code. A research database needs the diagnosis mapped to a study-specific classification. Even when systems can exchange data technically, the meaning of that data may be lost, distorted, or ambiguous if the sending and receiving systems use different terminologies or coding conventions. A blood pressure reading of "120/80" seems unambiguous, but without knowing the measurement method, patient position, and device used, its clinical interpretation may differ.

Organisational barriers are perhaps the most intractable. Health data exchange requires governance agreements about who can access what data, under what circumstances, and with what obligations. These agreements must navigate patient consent, data protection law, professional boundaries, and institutional liability. Even when two organisations use the same technical standard and the same terminology, they may not exchange data because the governance arrangements are not in place. Within the NHS, for instance, the technical capacity for data sharing between primary and secondary care has existed for years, but inconsistent local information governance practices have slowed adoption.

There is also, bluntly, the problem of incentives. For EHR vendors, data portability can work against commercial interests. A health system locked into a single vendor's ecosystem is a captive customer; one that can easily move data between systems has more negotiating power. While vendors publicly support interoperability, the pace of implementation has not always matched the rhetoric. The phrase "information blocking" - now a legal concept in the United States - captures this dynamic.

Terminology Standards

Before systems can exchange clinical data, they need a common language for describing clinical concepts. Terminology standards provide this language, mapping the messy, ambiguous vocabulary of clinical practice to structured codes that computers can process consistently.

SNOMED CT (Systematised Nomenclature of Medicine - Clinical Terms) is the most comprehensive clinical terminology, containing over 350,000 concepts organised in a hierarchical structure (SNOMED International, 2024). Its strength is expressiveness: SNOMED CT can represent clinical findings, procedures, body structures, organisms, substances, and their relationships with a precision that simpler coding systems cannot match. A clinician's narrative description of a "small cell carcinoma of the right upper lobe of the lung" can be represented as a single SNOMED CT concept with defined relationships to its anatomical location, morphology, and disease category. SNOMED CT is the required terminology for clinical recording in the NHS in England and is mandated or recommended in many other national health systems. Its complexity, however, creates implementation challenges: choosing the right concept from 350,000 options requires sophisticated search interfaces, and mapping between SNOMED CT and other terminologies is not always straightforward.

ICD (International Classification of Diseases), maintained by the World Health Organization, serves a different purpose. Where SNOMED CT aims to capture clinical detail, ICD aims to classify diseases and health conditions for statistical reporting, epidemiology, and reimbursement. The base WHO ICD-10, endorsed by the World Health Assembly in 1990 and adopted by most countries through the 1990s, contains around 14,400 diagnostic codes. The United States, which transitioned only in 2015, uses two clinical modifications maintained by CMS and the CDC: ICD-10-CM for diagnoses (some 70,000 codes) and ICD-10-PCS for inpatient procedures (about 87,000 codes), so the "approximately 70,000 codes" figure widely quoted in US contexts refers to ICD-10-CM rather than the base WHO classification. ICD-11 was released by WHO in June 2018, adopted at the 72nd World Health Assembly in May 2019, and came into effect on 1 January 2022 (WHO, 2019); it modernises the classification with a more flexible structure and better digital integration, though country-level adoption remains uneven. In practice, most health systems use ICD for administrative and public health purposes and SNOMED CT (or a national equivalent) for clinical recording, with mappings between the two. These mappings are imperfect - SNOMED CT's clinical granularity does not always reduce neatly to ICD's classification categories - but they are workable for most purposes.

LOINC (Logical Observation Identifiers Names and Codes) standardises the identification of laboratory tests and clinical observations. When a laboratory reports a "serum sodium" result, LOINC provides the code that specifies exactly what was measured, in what specimen, using what method. Without LOINC, the same test might be identified differently by different laboratories, making it difficult to aggregate results or compare values across systems. LOINC contains over 100,000 observation codes and is used internationally, particularly for laboratory data exchange (Regenstrief Institute, 2024).

Drug terminologies vary by jurisdiction. The United States uses RxNorm, which provides normalised names and codes for medications. The United Kingdom uses dm+d (Dictionary of Medicines and Devices), which is maintained by the NHS and integrated into GP and hospital prescribing systems. These terminologies enable accurate medication exchange - ensuring that when a GP prescribes "metformin 500mg tablets", the hospital system recognises the same medication - but cross-border medication data exchange remains challenging because national drug catalogues differ.

The fundamental point is that coded data is vastly more useful than free text. A discharge summary stating that the patient has "sugar" (a common patient term for diabetes) is meaningful to a human reader but invisible to any automated system. The same information coded in SNOMED CT can drive clinical decision support, populate disease registries, and enable research queries across millions of records. The practical challenge is that clinicians must be able to record coded data without it slowing their workflow - a user interface problem as much as a standards problem.

Table 8.1: Key Health Data Terminology Standards

Messaging and Document Standards

Terminology standards solve the vocabulary problem, but clinical data also needs a way to travel between systems. Messaging and document standards define the structure and transport mechanisms for health data exchange.

HL7 Version 2 (HL7v2), first published in 1987, remains the most widely deployed health data messaging standard in the world. Its longevity is both a strength and a limitation. HL7v2 messages are used for laboratory result delivery, patient admissions and discharges, order entry, and dozens of other transactions. Walk into almost any hospital with electronic systems and you will find HL7v2 messages flowing between its laboratory information system, EHR, radiology system, and pharmacy system.

HL7v2's success owes much to its flexibility - the standard defines message structures but allows considerable local variation in how fields are populated, which optional segments are included, and how data is formatted. This flexibility made adoption easier (organisations could implement the standard without changing their existing data models) but undermined interoperability. Two hospitals might both use HL7v2 for laboratory results and still be unable to exchange data because they have made different choices about how to populate the same message fields. In practice, every new interface between two HL7v2 systems requires mapping and testing, and the work of maintaining these interfaces represents a substantial ongoing cost for health IT departments.

HL7 Version 3 and the Clinical Document Architecture (CDA) attempted to address HL7v2's limitations by defining a more rigorous, XML-based data model. CDA, in particular, was designed for sharing clinical documents - discharge summaries, referral letters, care plans - in a standardised format that could be both human-readable and machine-processable. The Continuity of Care Document (CCD) and its variants became the basis for health information exchange in the United States, particularly under the Meaningful Use programme.

In practice, CDA adoption was uneven. The standard's complexity made implementation expensive, and many implementations produced documents that were technically valid CDA but contained most of their clinical content in unstructured narrative blocks rather than coded data. A discharge summary might comply with CDA structurally but contain the clinically important details as free text, limiting the value of structured exchange. HL7v3 and CDA represented an important step toward more rigorous standards, but their complexity and the gap between specification and implementation left many of the original interoperability problems unsolved.

FHIR

HL7 FHIR (Fast Healthcare Interoperability Resources, pronounced "fire") was developed as a deliberate response to the limitations of earlier standards (HL7 International, 2024). Where HL7v2 was flexible to the point of ambiguity and HL7v3/CDA was rigorous to the point of impracticality, FHIR aimed for a middle ground: a modern, web-based standard that developers could implement without years of health informatics training.

FHIR's central concept is the resource - a discrete, self-contained unit of health data. A Patient resource contains demographic information. An Observation resource holds a single clinical measurement (a blood pressure reading, a laboratory result). A Condition resource represents a diagnosis. A MedicationRequest resource captures a prescription. Each resource has a defined structure, with required and optional fields, and can be linked to other resources through references. A laboratory result (Observation) references the Patient it belongs to, the Practitioner who ordered it, and the Encounter during which it was collected.

This resource model differs fundamentally from the message-based approach of HL7v2. Rather than defining large, complex messages for specific transactions (a laboratory result message, an admission message), FHIR defines small, reusable data components that can be combined as needed. Systems can request specific resources using standard web technologies - HTTP requests to RESTful APIs - in the same way that a web browser requests pages from a server. A clinical application might request all Condition resources for a specific Patient, or all MedicationRequest resources from the past year. This approach is familiar to any web developer, which was precisely the point: FHIR was designed to be implementable by the broader software development community, not just health informatics specialists.

SMART on FHIR extends this model by providing a framework for third-party applications to connect securely to EHR systems (SMART Health IT, 2024). A clinical decision support application, a patient-facing portal, or a research data collection tool can authenticate against a FHIR server and access data without needing a custom interface for each EHR vendor. The vision is an "app store" model for clinical software, where applications developed once can run on any FHIR-enabled EHR. In practice, this vision is partially realised - SMART on FHIR applications do exist and run on multiple EHR platforms - but the depth of data available through FHIR APIs varies considerably between implementations.

Implementation Guides address the problem that a base standard, however well designed, still leaves room for variation. An Implementation Guide constrains FHIR for a specific use case, specifying which resources to use, which fields are required, and what terminologies to apply. The US Core Implementation Guide, for instance, defines the minimum data that US EHR systems must expose through FHIR APIs. The UK Core defines equivalent requirements for NHS systems. These guides reduce the "optionality problem" that undermined HL7v2, but they also fragment the standard: a FHIR implementation built for US Core may not be compatible with UK Core without adaptation.

FHIR's adoption has accelerated significantly. In the United States, the 21st Century Cures Act mandated that EHR vendors provide FHIR-based APIs, and most major EHR systems support FHIR R4 (the release mandated for US certification and the most widely deployed). Apple's Health app gives consumers direct access to their clinical records through FHIR APIs, and Google and Microsoft offer FHIR-based cloud services for health data. International adoption is growing, with FHIR implementation guides developed for Australia, Canada, the European Union, and many other jurisdictions.

Yet FHIR has important limitations. The standard is strongest for read access - retrieving data from EHR systems - and weaker for write operations (sending data back) and complex workflows. Bulk data access for research and population health, while possible through FHIR Bulk Data Access specifications, remains less mature than individual record queries. And FHIR, like any standard, is only as good as the data behind it: a FHIR API that exposes poorly coded or incomplete data does not solve the interoperability problem, it merely makes the poor data more accessible.

openEHR

While FHIR addresses how data is exchanged between systems, openEHR takes a fundamentally different approach to how clinical data is modelled and stored. The openEHR architecture is built on the principle of two-level modelling: a stable reference model defines the basic structure of health records (entries, compositions, demographic data), while clinical content definitions called archetypes are managed separately by clinicians and domain experts.

An archetype defines what a particular clinical concept looks like in data: what a blood pressure measurement contains (systolic, diastolic, position, cuff size, device), what a medication order includes, or what a discharge summary should contain. Archetypes are designed to be clinically meaningful, vendor-neutral, and reusable across different health IT systems. A blood pressure archetype defined once can be used in a GP system, a hospital system, and a research database, ensuring that blood pressure data is captured and stored consistently regardless of the underlying technology.

The practical implication is that openEHR separates clinical knowledge from software engineering. When a clinical requirement changes - a new field needs to be added to a medication record, or a new type of observation needs to be captured - the change is made at the archetype level rather than requiring software development. This separation, in principle, allows clinical systems to evolve more quickly and consistently than systems where data models are embedded in application code.

openEHR has been adopted primarily in national and regional programmes (openEHR Foundation, 2024). Norway, Sweden, and parts of Germany use openEHR-based systems for clinical data repositories. In the UK, openEHR is used in several NHS trusts and has influenced the design of national data standards. Australia's national digital health infrastructure incorporates openEHR principles. The Clinical Knowledge Manager, an international repository of archetypes, allows organisations to share and reuse clinical content definitions rather than each designing their own.

FHIR and openEHR are not mutually exclusive. FHIR serves primarily as an interface standard - defining how systems exchange data - while openEHR defines how data is modelled and stored within systems. Many implementations use openEHR for internal data persistence and expose that data through FHIR APIs for external exchange. The two approaches address different layers of the interoperability problem and are increasingly seen as complementary rather than competing.

National Interoperability Programmes

Standards define what is possible; national programmes attempt to make it happen. Several countries have launched major interoperability initiatives, each reflecting their healthcare system's particular structure and challenges.

United States

The United States has pursued interoperability primarily through regulation. The 21st Century Cures Act (2016) and its implementing regulations established two key principles: EHR vendors must provide standardised APIs (specifically FHIR-based), and information blocking - practices that prevent or discourage the exchange of electronic health information - is prohibited and subject to penalties. The Office of the National Coordinator for Health Information Technology (ONC) enforces these provisions through its certification programme and compliance activities.

TEFCA (Trusted Exchange Framework and Common Agreement), which went operational in December 2023 when the first Qualified Health Information Networks were designated, provides a national governance framework for health information exchange (ONC, 2024). TEFCA establishes common rules that allow different health information networks to exchange data with one another without requiring bilateral agreements between every pair of organisations. Qualified Health Information Networks (QHINs) that agree to TEFCA's terms can exchange data for treatment, payment, and public health purposes. TEFCA represents a significant step toward nationwide interoperability, though as of 2025 participation was still growing and the framework's real-world impact had yet to be established.

United Kingdom

The NHS has pursued interoperability through a combination of national infrastructure and local implementation. NHS Spine provides a national messaging backbone connecting GP practices, hospitals, and other NHS organisations, supporting services including the Summary Care Record (an extract of key patient information accessible across care settings), the Electronic Prescription Service, and demographic services. GP Connect enables hospital clinicians to view a patient's GP record directly, addressing the common problem of secondary care clinicians lacking primary care context.

However, the NHS interoperability picture remains fragmented in practice. Despite national standards and infrastructure, many hospitals still operate information systems that do not fully interoperate with one another or with GP systems. The NHS has mandated FHIR-based APIs for new systems and has developed UK Core Implementation Guides, but the installed base of legacy systems means that HL7v2 messaging and even paper-based processes persist in many settings. NHS England's strategy emphasises Shared Care Records at regional level - platforms that aggregate data from GP practices, hospitals, community services, and mental health trusts within a geographic area - as a pragmatic step toward comprehensive data sharing.

European Union

The European Health Data Space (EHDS), proposed by the European Commission in 2022, entered into force as Regulation (EU) 2025/327 in March 2025 (European Parliament and Council, 2025) and represents the EU's most ambitious health data initiative. EHDS aims to establish citizens' rights to access and share their health data across EU member states, and to create a framework for secondary use of health data for research, innovation, and public health.

The primary use component would enable a patient treated in one EU country to have their clinical data available to healthcare providers in another - a particular challenge given the diversity of national health IT systems across 27 member states. The secondary use component would create national Health Data Access Bodies to manage researchers' and innovators' access to anonymised or pseudonymised health data, subject to governance requirements.

EHDS faces substantial implementation challenges. Member states have very different levels of health IT maturity, different national health data standards, and different legal frameworks for data sharing. The regulation mandates the use of specific standards (including FHIR) and establishes a cross-border infrastructure, but the work of connecting 27 national systems to a common framework is measured in years, not months.

Table 8.2: National Interoperability Programmes

The Implementation Gap

The technical standards described in this chapter exist. FHIR is mature and widely supported. SNOMED CT, ICD, and LOINC are well-established terminologies. National programmes in the US, UK, and EU have set regulatory requirements and built infrastructure. Yet interoperability remains poor in practice. Why?

Part of the answer is the legacy problem. Health IT systems have long lifespans - a hospital EHR might remain in use for fifteen or twenty years - and the installed base of older systems was built before current standards existed. Replacing these systems is expensive and disruptive, so organisations often choose incremental upgrades and interface layers rather than wholesale replacement. The result is an environment where new standards coexist with older ones, and the interfaces between them introduce complexity and fragility.

Data quality is another persistent issue. A FHIR API can only expose data that exists and is correctly coded. If clinicians routinely enter diagnoses as free text rather than selecting coded terms, if medication records contain inconsistencies, or if laboratory results lack proper LOINC codes, then standards-compliant data exchange simply transmits poor-quality data more efficiently.

Vendor incentives remain misaligned in many markets. While regulations like the 21st Century Cures Act have forced US vendors to provide APIs, the depth and usability of those APIs vary. Some vendors implement the minimum required by regulation; others go further. Switching costs remain high, and the competitive dynamics of the EHR market do not always reward interoperability. In markets without strong regulatory mandates, vendor cooperation on data exchange is even more variable.

Governance and trust present ongoing challenges. Even when technical interoperability is achievable, organisations may lack the governance agreements needed to share data. Who is responsible if shared data is incorrect and contributes to a clinical error? How are data protection requirements met when data flows across organisational boundaries? In the UK, despite national NHS infrastructure, local information governance concerns have slowed the adoption of data sharing that is technically possible. Patient consent models add further complexity: different jurisdictions take different approaches to whether patients must actively opt in to data sharing, opt out, or have no choice at all.

Finally, there is the problem of standards proliferation. The health IT landscape contains not one interoperability standard but dozens, each addressing different aspects of the problem, each with its own community of implementers and advocates. FHIR, openEHR, HL7v2, CDA, DICOM (for medical imaging), IHE profiles (which specify how standards should be used for particular workflows) - the sheer number of standards creates its own form of fragmentation. The often-cited observation that standards multiply rather than converge is not unique to health IT, but it is particularly acute in a domain where the stakes of getting data exchange wrong include patient harm.

Summary

Health data interoperability has been a goal of health IT for decades, and the gap between aspiration and reality remains wide. The standards themselves are increasingly mature: FHIR provides a modern, web-based framework for data exchange that has achieved broad adoption; terminology standards like SNOMED CT, ICD, and LOINC offer the coded vocabularies that make data computable; and openEHR provides an alternative approach to clinical data modelling that separates clinical knowledge from software engineering. National programmes in the US, UK, and EU have moved from voluntary adoption to regulatory mandates, reflecting a recognition that market forces alone have not delivered interoperability.

Yet standards adoption does not equal interoperability. Legacy systems, inconsistent data quality, misaligned vendor incentives, and unresolved governance challenges all contribute to an environment where data exchange remains harder in practice than it should be. The technical barriers are increasingly solvable; the organisational, commercial, and political barriers are not. For healthcare professionals, the practical implication is that interoperability will improve incrementally rather than through any single standard or programme, and that the quality of clinical data recording - choosing coded terms over free text, entering complete and accurate information - directly affects whether standards deliver their intended benefits.