Why Standards Matter in Healthcare Data Exchange
Healthcare generates vast amounts of data — clinical notes, lab results, prescriptions, imaging reports, vital signs — but that data has historically been trapped in silos. A hospital's EHR cannot talk to the local laboratory's system. A specialist receives a paper referral letter because there is no structured electronic channel. A patient discharged from hospital arrives at their general practitioner with no discharge summary.
Interoperability standards exist to solve this problem by defining a common language for healthcare data exchange. Without agreed standards, connecting any two healthcare systems requires bespoke, expensive, and brittle point-to-point interfaces. With them, systems can exchange data reliably and at scale.
Two names dominate the interoperability standards landscape: HL7 and FHIR. They are related — FHIR is produced by the same organisation that produces HL7 — but they represent different generations of thinking about how healthcare data should be exchanged.
What Is HL7?
Health Level Seven International (HL7) is a standards development organisation founded in 1987. It has produced a family of messaging and data standards used in healthcare IT worldwide. The "7" in HL7 refers to Level 7 of the OSI networking model — the application layer — indicating that HL7 standards deal with the meaning of data rather than the mechanics of transmission.
HL7 Version 2 (v2)
HL7 v2, first published in 1989 and still in active use today, is the most widely deployed healthcare messaging standard in the world. It defines pipe-delimited text messages for common healthcare events: patient admissions (ADT messages), laboratory orders and results (ORU/ORM messages), scheduling (SIU messages), and many others.
HL7 v2 is ubiquitous precisely because it was simple enough to implement in the technology of its era. Most hospital information systems and laboratory systems worldwide support HL7 v2 interfaces. However, the standard has significant limitations: it is not self-describing, it has many optional fields that different implementations use differently, and it was designed for internal hospital networks rather than internet-scale data exchange.
HL7 Version 3 and Clinical Document Architecture (CDA)
HL7 v3 was developed in the 2000s as a more rigorous, XML-based successor to v2. It introduced a formal information model (the Reference Information Model) intended to ensure that data had consistent meaning across implementations. In practice, v3 proved too complex and has seen limited adoption outside specific use cases.
The Clinical Document Architecture (CDA), a document standard derived from HL7 v3, has been more successful. CDA defines the structure of clinical documents — discharge summaries, referral letters, progress notes — as XML documents with coded sections. In the US, the Consolidated CDA (C-CDA) templates define specific document types used for Meaningful Use reporting and clinical document exchange. CDA documents remain widely used for care transitions.
What Is FHIR?
FHIR — Fast Healthcare Interoperability Resources — is a standard for healthcare data exchange developed by HL7 International and first published in 2014. It represents a fundamental rethinking of how healthcare interoperability should work, drawing on the architecture of modern web applications.
FHIR is built around the concept of resources: discrete, modular units of healthcare information. Each resource represents a specific clinical or administrative concept — a Patient, a Condition, a Medication, an Observation, an Appointment, and so on. There are over 150 FHIR resources in the R4 specification (the current stable version), each with a defined structure and a set of required and optional elements.
REST APIs in FHIR
FHIR uses RESTful APIs as its primary exchange mechanism. This is a significant departure from HL7 v2, which relies on point-to-point message passing. A FHIR server exposes patient data as a web API: systems can query for a patient's conditions with a URL like GET /Condition?patient=12345, receive a structured JSON response, and process it with standard web development tools.
This approach has several important implications:
- Interoperability is accessible: Any developer familiar with web APIs can build FHIR integrations without deep healthcare-specific knowledge
- Granular access: Systems can request exactly the data they need rather than receiving entire messages
- Real-time access: FHIR APIs support synchronous queries, enabling real-time data access for applications
- Cloud-native architectures: FHIR fits naturally into modern cloud infrastructure and microservices patterns
SMART on FHIR
SMART on FHIR (Substitutable Medical Applications, Reusable Technologies) is a framework that builds on FHIR to enable third-party applications to securely access patient data from an EHR. It uses standard OAuth 2.0 for authorisation, allowing applications to request scoped access to specific data on behalf of specific users or patients.
SMART on FHIR is the technical foundation for app galleries in major EHR platforms, patient-facing mobile applications, and clinical decision support tools that plug into EHR workflows. In the US, the ONC's 21st Century Cures Act requires certified EHR vendors to support SMART on FHIR for patient and provider-facing application access — a regulatory mandate that has significantly accelerated adoption.
Key Practical Differences for Implementers
| Aspect | HL7 v2 | FHIR R4 | |---|---|---| | Architecture | Message-based | RESTful API | | Data format | Pipe-delimited text | JSON / XML | | Transport | TCP/IP (MLLP) | HTTPS | | Learning curve | Moderate (healthcare-specific) | Low (standard web skills) | | Flexibility | High (many optional fields, variable implementations) | Structured (defined schemas) | | Tooling | Mature but specialised | Rapidly expanding, uses web tools | | Real-time queries | Not designed for this | Supported natively | | Adoption | Universal in hospitals | Rapidly growing, mandated in some markets |
HL7 v2 is not obsolete — it remains the primary integration mechanism inside most hospitals for ADT events, lab results, and order messages. The installed base is enormous and will not be replaced quickly. However, for new integrations — especially those involving patient-facing applications, national health information networks, or cloud-based platforms — FHIR is the forward-looking choice.
Which Standard Should You Use?
Use HL7 v2 when:
- Integrating with legacy hospital systems that do not support FHIR
- Building internal integrations for ADT, lab, or order messaging in environments where v2 is the established standard
- Working with systems whose FHIR implementations are immature or incomplete
Use FHIR when:
- Building patient-facing applications that need to access EHR data
- Connecting to national health information exchanges or government-mandated interoperability platforms
- Developing clinical decision support tools or analytics applications that need structured, queryable data
- Implementing cross-organisation clinical document sharing
- Working in a regulatory environment (US, Australia, UK) that mandates FHIR compliance
Use CDA/C-CDA when:
- Exchanging clinical documents (discharge summaries, referral letters) in environments where CDA is the established standard, particularly in the US
- Complying with Meaningful Use or Promoting Interoperability requirements that specify C-CDA document types
In practice, most mature healthcare organisations need to support all three. An integration engine or middleware platform (such as Mirth Connect, InterSystems HealthShare, or Azure Health Data Services) is typically used to translate between them.
Global Adoption Status
FHIR R4 has become the dominant interoperability standard for new implementations globally:
- United States: The ONC's 21st Century Cures Act (2020) mandated FHIR R4 APIs for certified EHRs. CMS Interoperability Rule extends this to payer data exchange.
- Australia: The Australian Digital Health Agency's FHIR national profiles define Australian-specific implementation guidance.
- UK: NHS England's National Record Locator and many new digital health programmes use FHIR.
- Europe: The European Health Data Space regulation incorporates FHIR as a key technical standard.
- Canada, Singapore, Saudi Arabia, and many others have published or are developing national FHIR implementation guides.
The trajectory is clear: FHIR is becoming the global lingua franca of healthcare data exchange. Organisations building or procuring digital health systems today should ensure FHIR support is a non-negotiable requirement.
FZ Consulting LLP provides interoperability architecture and implementation services, including HL7 v2 integration, FHIR API design, and health information exchange strategy. Contact our team to discuss your interoperability challenges.