Last updated: August 2026
HL7 vs FHIR
HL7 is a family of healthcare data exchange standards dating to the late 1980s, and FHIR (Fast Healthcare Interoperability Resources) is HL7's modern iteration — built on REST APIs and JSON rather than HL7 v2.x's older pipe-delimited message format. The two standards coexist in most healthcare organizations today: HL7 v2.x still handles the bulk of existing EHR-to-EHR communication, while FHIR is the standard for new implementations and regulatory interoperability requirements.
What HL7 v2.x is
HL7 v2.x, developed in the late 1980s, uses pipe-delimited message segments to exchange data between hospital information systems — lab results, admissions/discharge/transfer events, orders. It's not a REST API in the modern sense; it's a message-based protocol, typically transmitted over dedicated interface engines, and it remains deeply embedded in existing hospital IT infrastructure precisely because so much legacy integration already runs on it. Replacing it wholesale in an established hospital system is a substantial, high-risk undertaking, which is why it persists alongside newer standards rather than being fully retired.
What FHIR is
FHIR, published in 2014, represents healthcare data as discrete, well-defined "resources" (Patient, Observation, Medication) exchanged over standard RESTful APIs using JSON or XML. This makes it dramatically easier for modern web and mobile applications to integrate with healthcare data than HL7 v2.x's message-based approach — a developer already familiar with REST APIs can start working with FHIR resources without learning an entirely separate integration paradigm. FHIR is the standard being mandated for patient-facing applications, payer-to-provider data exchange, and CMS interoperability rule compliance in the US specifically.
When to use HL7 v2.x
HL7 v2.x remains the right integration point when connecting to an existing hospital system whose interface engine only speaks v2.x — which is still true for a large share of installed EHR and hospital information systems. Building a new v2.x interface from scratch for a greenfield project, when FHIR is available as an alternative, generally isn't the right default choice anymore, but for legacy system integration it's often the only practical option.
When to use FHIR
FHIR is the right default for any new healthcare integration project, especially patient-facing applications, mobile health apps, or anything needing to comply with current US interoperability regulations (like the CMS Interoperability and Patient Access rule). Its REST/JSON foundation also makes it the natural choice when integrating healthcare data into AI systems — a RAG pipeline or analytics platform consuming FHIR resources faces far less integration friction than one built against HL7 v2.x messages.
Comparison
| Dimension | HL7 v2.x | FHIR |
|---|---|---|
| Format | Pipe-delimited messages | JSON/XML over REST APIs |
| Published | Late 1980s | 2014 |
| Best for | Existing legacy hospital system integration | New builds, patient-facing apps, regulatory compliance |
| Developer familiarity | Specialized, less common | Standard REST/JSON, widely known |
What Code Ninety does
Code Ninety builds new healthcare integrations against FHIR by default, while maintaining HL7 v2.x interface capability for clients whose existing hospital systems require it — assessing which standard a specific integration actually needs during discovery rather than defaulting to one regardless of the target system. Code Ninety delivers cloud-native healthcare integration for US and Gulf providers. See the EHR integration case study for how this works on a live hospital system.