HL7 vs FHIR: Healthcare Integration Guide | Trilops

HL7 Version 2 is a family of healthcare messaging standards designed to exchange clinical and administrative events between systems. In day-to-day integration work, "HL7" often means HL7 v2 pipe-delimited messages moving through an interface engine or point-to-point interface.

Messages are organized into segments such as MSH for message metadata, PID for patient identity, PV1 for encounter context, OBR for order or observation request information, and OBX for observation values. The exact structure depends on the message type, version, implementation guide, trading-partner agreement, and local conventions.

MSH|^~\&|EHR|CLINIC|LAB|NETWORK|20260819||ORU^R01|MSG123|P|2.5
PID|||P12345||DOE^JANE||19840408|F
OBR|1||LAB7788|718-7^Hemoglobin
OBX|1|NM|718-7^Hemoglobin||13.4|g/dL

Event:
  laboratory result available

Patient:
  local patient identifier P12345

Observation:
  Hemoglobin = 13.4 g/dL

Workflow:
  route result to receiving system

FHIR, or Fast Healthcare Interoperability Resources, is an HL7 standard for exchanging healthcare information electronically. Its core building blocks are resources such as Patient, Practitioner, Encounter, Observation, Condition, MedicationRequest, ServiceRequest, DiagnosticReport, Appointment, and DocumentReference.

FHIR is often discussed as a REST API standard, but it is broader than REST. The specification includes resource models plus exchange approaches that include RESTful APIs, search, documents, messaging, services, subscriptions, and other patterns. JSON is common in application development, but FHIR also defines other representations.

{
  "resourceType": "Observation",
  "status": "final",
  "code": {
    "coding": [{
      "system": "http://loinc.org",
      "code": "718-7",
      "display": "Hemoglobin"
    }]
  },
  "subject": { "reference": "Patient/P12345" },
  "valueQuantity": {
    "value": 13.4,
    "unit": "g/dL"
  }
}

HL7 v2 messages usually describe an event in context. A single result message may include message metadata, patient identity, encounter information, order context, and multiple observations. The receiver processes the message as an event and updates its local state.

FHIR decomposes healthcare information into resources that reference one another. A Patient can be read independently. An Encounter can reference that Patient. An Observation can reference the Patient and Encounter. A DiagnosticReport can reference multiple Observations.

As of August 2026, HL7 lists FHIR R5, version 5.0.0, as the current published base specification. That does not mean every production EHR or U.S. interoperability program has moved to R5.

The current published US Core Implementation Guide, version 9.0.0, is still based on FHIR R4 and meets USCDI v6 requirements. The current published SMART App Launch guide, version 2.2.0, is also published against FHIR R4, while documenting compatibility with FHIR versions from DSTU2 onward.

SMART App Launch is an HL7 implementation guide that defines OAuth 2.0 based patterns for applications to authorize, authenticate, and integrate with FHIR-based systems. It supports EHR-launched apps, standalone apps, scopes for limiting access, discovery of server configuration, and backend-service patterns.

HL7's v2-to-FHIR implementation guide provides standardized mappings for messages, segments, data types, and vocabularies into FHIR R4 concepts. It is an important starting point, but each production transformation still needs local implementation rules.

A practical architecture often keeps v2 at the system boundary where legacy or operational systems already use it, then normalizes data into an internal model or FHIR layer for modern applications. Other systems may remain FHIR-native end to end.

FHIR's REST API specification explicitly notes that authentication, authorization, and audit collection are not solved by the REST interactions themselves. SMART provides authorization patterns for FHIR applications, but implementation still needs organizational policy, appropriate scopes, identity, consent where applicable, logging, secrets, network controls, and incident response.

Authoritative references

• HL7: FHIR Release 5, current published base specification
• HL7 FHIR: RESTful API
• HL7: Version 2 to FHIR Implementation Guide
• HL7: v2 to FHIR message maps
• HL7: SMART App Launch 2.2.0
• HL7: US Core Implementation Guide 9.0.0
• HL7: US Core 9.0.0 change log and USCDI v6 alignment

FHIR versions, implementation guides, vendor support, regulatory programs, and certification requirements evolve. Verify the exact target ecosystem immediately before implementation. This article is technical guidance, not legal, regulatory, or compliance advice.