FHIR vs HL7 v2 vs CDA: Interoperability Standards Explained
HL7 v2, CDA, and FHIR are three generations of Health Level Seven (HL7) standards for exchanging health information. HL7 v2 is a pipe-delimited messaging standard that moves real-time events such as admissions and lab results between hospital systems; the Clinical Document Architecture (CDA) is an XML standard for complete, signed clinical documents such as discharge summaries; and Fast Healthcare Interoperability Resources (FHIR) is a modern standard that exposes granular data as web resources through RESTful APIs. Most health systems run all three at once, so research data platforms have to ingest and harmonize every one of them.
Why this matters now
For decades interoperability meant HL7 v2 interfaces inside a hospital and document exchange between organizations. FHIR changed the expectation to on-demand access through standard APIs. In the United States, the Office of the National Coordinator for Health IT (ONC) Cures Act Final Rule required certified EHR technology to support standardized FHIR APIs, using FHIR Release 4 and the US Core implementation guide, with a compliance deadline at the end of 2022. The same rule set pushed adoption of SMART on FHIR for app authorization and FHIR Bulk Data Access for population-level export.
In Europe, the European Health Data Space regulation sets a common European electronic health record exchange format and builds a framework for secondary use of health data under Article 50 and related provisions, which will draw on existing standards including HL7 CDA and FHIR. National programs elsewhere are making similar moves. The upshot for research teams is that the data they need now arrives in a mix of formats, and the newest format does not replace the older ones overnight.
The three standards explained
HL7 version 2
HL7 v2 dates from the late 1980s and remains the most widely deployed health messaging standard in hospitals. A v2 message is plain text made of segments, each on its own line and identified by a three-letter code: MSH for the message header, PID for patient identification, PV1 for the visit, OBR and OBX for orders and observations. Fields are separated by pipe characters. Message types describe events, such as ADT (admit, discharge, transfer) and ORU (unsolicited observation result).
V2 is fast, lightweight, and supported by almost every clinical system. Its weakness is flexibility. The standard permits many optional fields and local Z-segments, so two hospitals can both be “HL7 v2 compliant” and still send structurally different messages. Every interface needs site-specific mapping, usually managed in an integration engine.
Clinical Document Architecture
CDA, whose Release 2 was published in 2005, is an XML standard for clinical documents. A CDA document has a header describing the patient, author, custodian, and document type, and a body that can hold human-readable narrative and machine-readable coded entries. It is built on the HL7 Reference Information Model. In the United States, Consolidated CDA (C-CDA) templates, such as the Continuity of Care Document, became the basis for summary-of-care exchange under earlier meaningful use programs.
CDA’s strength is that it represents a complete, attested record of an encounter, suitable for legal retention and for display. Its weakness for analytics is that coded content depends on how thoroughly the sender populated the structured entries; many documents carry rich narrative and thin coding.
Fast Healthcare Interoperability Resources
FHIR breaks health information into small, reusable resources such as Patient, Encounter, Condition, Observation, and MedicationRequest, each with a defined structure and a web address. Systems read and write resources through RESTful APIs, in JSON or XML. FHIR Release 4, published in 2019, was the first release with normative content, and Release 5 followed in 2023. Implementation guides such as US Core, International Patient Summary, and national profiles constrain the base resources for specific uses.
FHIR is easier for developers to adopt and supports both app-level access and bulk export. Its challenge is that it is only as consistent as the profiles and terminology each implementer adopts. Two FHIR servers can use different code systems for the same lab test unless an implementation guide requires otherwise.
FHIR vs HL7 v2 vs CDA at a glance
| Dimension | HL7 v2 | CDA (including C-CDA) | FHIR |
|---|---|---|---|
| Primary purpose | Real-time event messaging between systems | Exchange of complete clinical documents | Granular data access through APIs |
| Format | Pipe-delimited text segments | XML document with header and body | JSON or XML resources |
| Transport pattern | Push messages, typically over MLLP interfaces | Document exchange via HIEs, direct messaging, or repositories | RESTful APIs, subscriptions, bulk export |
| Unit of exchange | An event (admission, result) | A document (summary, report) | A resource (patient, observation) |
| Typical use | Lab, ADT, orders inside a hospital | Transitions of care, record sharing | Patient apps, payer and provider APIs, population export |
| Consistency across sites | Low, heavy local variation | Moderate, depends on template use | Moderate to high where profiles are enforced |
| Research suitability | Good source of real-time events after mapping | Useful narrative and summaries, variable coding | Best structured source, still needs harmonization |
The Data Harmonization angle
None of these three standards is a research data model. They are designed to move information between systems for care, not to support cohort definition, longitudinal analysis, or cross-site comparison. For research, data from all three sources usually lands in an analytical model such as the Observational Medical Outcomes Partnership (OMOP) Common Data Model, where standardized vocabularies (SNOMED CT, LOINC, RxNorm) make a diagnosis or lab result mean the same thing at every site. Our comparison of OMOP vs FHIR explains why the two are complementary: FHIR for exchange, OMOP for analysis.
The harmonization work differs by source. HL7 v2 feeds need parsing, local code translation, and event reconstruction into encounters. CDA documents need extraction of coded entries and, often, natural language processing of narrative sections. FHIR resources map most directly, but still need terminology alignment and de-duplication across servers. Lifebit’s approach uses AI-assisted mapping to automate much of this translation into OMOP; our article on AI-automated OMOP harmonization at scale describes how that works.
Harmonization happens inside each custodian’s federated Trusted Research Environment (TRE), so the data never leaves the source. Researchers then query or analyze harmonized OMOP data across many sites through the federated layer, and only reviewed aggregate outputs are released.
Practical guide: choosing and combining standards
- Inventory what you already receive. List every feed by standard, version, sending system, and volume. Most organizations find they depend on v2 for timeliness, CDA for summaries, and FHIR for newer integrations.
- Use FHIR for new integrations where supported. If the source system offers a certified FHIR API or Bulk Data export, it is usually the most structured option and the easiest to maintain.
- Keep v2 where latency matters. For real-time events such as admissions or critical results, v2 interfaces remain reliable and are often faster to stand up than a new API.
- Extract CDA for historical and cross-organization records. Summary documents from partners and health information exchanges often exist only as CDA. Plan for both coded extraction and narrative processing.
- Converge on one analytical model. Map all sources into OMOP with standard vocabularies, and track provenance so every OMOP record can be traced back to the message, document, or resource it came from.
- Measure mapping quality. Report the share of source codes mapped to standard concepts, per source and per domain, and review unmapped high-frequency codes first.
Real-world context
Large programs show the pattern in practice. Genomics England, a Lifebit customer, combines genomic data with clinical information drawn from health service systems for research in a trusted environment, which requires translating routinely collected clinical data into consistent research formats. Singapore’s Ministry of Health, also a Lifebit customer, oversees a national health system where data from many care providers must be brought together under national governance. Public research infrastructure points the same way: the All of Us Research Program ingests EHR data from participating health care organizations and converts it to the OMOP Common Data Model for its Researcher Workbench, and the Observational Health Data Sciences and Informatics (OHDSI) community publishes open tools for mapping source data, including FHIR, into OMOP.
Common pitfalls and objections
“FHIR will replace v2 and CDA”
Not soon. V2 interfaces are embedded in hospital operations and work well for what they do, and CDA remains the format for many legal and cross-organization records. Plan for coexistence for years.
“If it is FHIR, it is interoperable”
FHIR standardizes structure, not meaning. Without shared profiles and terminology, two FHIR sources can still disagree. Enforce implementation guides and map to standard vocabularies.
“We can analyze FHIR directly”
For small projects, yes. At scale, nested resources and repeated references make cohort queries and longitudinal analysis slow and error-prone. An analytical model such as OMOP is designed for that job.
Losing provenance
When data passes through several transformations, it becomes hard to explain where a value came from. Keep source identifiers and transformation logs from the start.
What to do next
Start with the inventory in step one and a mapping-coverage report for your most important clinical domains. That will show where FHIR can simplify ingestion, where v2 and CDA still carry critical data, and how much harmonization is needed before cross-site research is reliable. For a view of how harmonization, federated access, and output review fit together, see the federated Trusted Research Environment overview.
Frequently asked questions
What is the main difference between HL7 v2 and FHIR?
HL7 v2 pushes pipe-delimited event messages between systems, usually inside a hospital, with a lot of local variation. FHIR exposes granular data as web resources that applications can query through RESTful APIs in JSON or XML, with implementation guides to constrain variation.
Is CDA still used?
Yes. CDA and its Consolidated CDA templates remain widely used for clinical documents such as care summaries and discharge documents, especially for exchange between organizations and through health information exchanges.
Which FHIR version should I use?
FHIR Release 4 is the most widely implemented version and is required for certified APIs in the United States. Release 5 is available, but most production ecosystems and implementation guides still target R4.
Is FHIR a research data model?
No. FHIR is designed for exchange. For research and analytics, data is usually transformed into an analytical model such as the OMOP Common Data Model, which uses standard vocabularies and a structure optimized for cohort and longitudinal queries.
Can HL7 v2 data be used for research?
Yes, after mapping. V2 messages carry valuable real-time clinical events such as lab results and admissions, but they need parsing, local code translation, and reconstruction into encounters before analysis.
How do these standards relate to OMOP?
HL7 v2, CDA, and FHIR are common sources of data that is then mapped into OMOP. OMOP provides the consistent analytical layer, so a study defined once can run across sites regardless of which exchange standard each site used.