HL7 FHIR Integration Guide: HL7 v2 vs FHIR R4, Labs, PACS and ABDM

HL7 FHIR integration is how modern healthcare systems share data, but most hospitals still run on a mix of standards. Lab analysers send results one way, the PACS another, the hospital system a third, and national programmes like India's ABDM expect FHIR. Getting these to work together reliably is less about any single standard and more about knowing which to use where, and testing relentlessly.

This guide explains HL7 v2 and FHIR R4 in practical terms, compares them, walks through lab and PACS integration, shows how ABDM uses FHIR, and sets out a step-by-step approach to an integration project.

It is written for hospital IT heads, CTOs of health software companies and developers starting their first healthcare integration.

The standards in one minute

• HL7 v2: a messaging standard in use since the late 1980s and still the workhorse inside hospitals. Messages are text with pipe-delimited segments, usually sent over TCP using MLLP.
• FHIR: Fast Healthcare Interoperability Resources, a modern standard from HL7 based on web APIs. Data is organised as resources, such as Patient or Observation, exchanged as JSON or XML over REST.
• FHIR R4: the 2019 release, the first with normative content, and still the most widely implemented version. Later releases exist, but most national programmes and products target R4.
• DICOM: the standard for medical images and imaging workflow, used by PACS and modalities.
• ASTM and related lab protocols: used by many lab analysers to talk to the lab information system.
• Terminologies: code systems such as LOINC for tests, SNOMED CT for clinical terms and ICD-10 for diagnoses, which make data mean the same thing across systems.

HL7 v2 vs FHIR R4

HL7 v2 is organised around events. An ADT message announces an admission, discharge, transfer or registration update. An order message (ORM, or OML in later versions) sends a lab or radiology order. An ORU message returns results. Each message is made of segments, such as MSH for the header, PID for patient identity, PV1 for the visit, OBR for the order and OBX for each result value. The standard is flexible, which is both its strength and its weakness: two hospitals' "HL7 v2.5" feeds can differ substantially.

FHIR models healthcare data as resources: Patient, Encounter, Practitioner, Observation, DiagnosticReport, ServiceRequest, MedicationRequest, ImagingStudy and many more. Resources can be fetched and searched through REST APIs or bundled into documents and messages. Profiles and implementation guides define how resources are used in a specific programme, such as US Core in the United States or the ABDM profiles in India.

Example: one admission, two standards

Following a single event through both standards makes the difference concrete.

1. A patient is admitted to a ward in the hospital system.
2. The hospital system sends an HL7 v2 ADT admission message over MLLP to the integration engine. It carries an MSH header, a PID segment with the patient's identifiers and name, and a PV1 segment with the ward, bed and admitting doctor.
3. The integration engine forwards the message to the LIS, pharmacy and diet systems, each of which now knows the patient is on that ward.
4. A patient portal asks the hospital's FHIR API for the patient's current encounter. The API returns an Encounter resource with status, class, location and participant, linked to the Patient resource.
5. At discharge, the hospital system creates a discharge summary which, if the patient consents, can be shared through ABDM as a FHIR document bundle.

The same facts travel in different shapes for different consumers. The integration layer's job is to keep them consistent.

Lab integration: analysers, LIS and HMS

Lab integration usually has two layers, and each uses different standards.

1. Analyser to LIS: analysers send results to the lab information system, commonly using ASTM-based protocols or HL7 v2, either directly or through middleware.
2. HMS to LIS for orders: when a doctor orders a test, the hospital system sends an order to the LIS, typically as an HL7 v2 order message or a FHIR ServiceRequest.
3. LIS to HMS for results: validated results come back as an HL7 v2 ORU message or as FHIR DiagnosticReport and Observation resources.
4. Report delivery: a signed PDF may travel alongside structured results for display and sharing.

Mapping is where most effort goes: test codes, units, reference ranges and patient identifiers must line up between systems. Using LOINC codes where possible makes results reusable later. Our guides to the laboratory information system for hospitals and diagnostic centre software cover the operational side.

PACS and radiology integration

Imaging integration combines HL7 or FHIR for orders and reports with DICOM for images.

• The hospital system sends a radiology order to the RIS through HL7 v2 or FHIR.
• The RIS provides a DICOM Modality Worklist, so the scanner receives patient and order details without retyping.
• Images go from the modality to the PACS using DICOM.
• The radiologist's report returns to the hospital system as an HL7 v2 ORU message or a FHIR DiagnosticReport.
• Doctors view images through a viewer link, often using DICOMweb, launched from the patient record.

The most common failures are mismatched accession numbers, patients registered differently on the scanner and in the HMS, and reports that arrive without a link to the images. Clear identifiers and worklists solve most of them.

How ABDM uses FHIR

India's Ayushman Bharat Digital Mission uses FHIR R4 for sharing health records. The National Resource Centre for EHR Standards (NRCeS) publishes the FHIR implementation guide and profiles that ABDM-integrated systems follow.

In practice:

• Records are shared as FHIR document bundles for defined health information types, such as OP consultation records, prescriptions, discharge summaries, diagnostic reports, immunisation records, wellness records and general health documents.
• Sharing happens only with the patient's consent, managed through ABDM's consent flow.
• A facility acting as a health information provider (HIP) links records to the patient's ABHA and shares them when consent is granted; a health information user (HIU) requests and receives them.
• Data is encrypted for exchange, and systems integrate through ABDM's gateway APIs.

ABDM's milestones, M1 to M3, describe this journey from ABHA handling to sharing and requesting records. Our post on ABDM integration for hospital software explains each milestone. For hospitals, the practical message is simple: if your records are not structured enough to build FHIR bundles, ABDM sharing will be painful.

Integration in the UAE and US

Other markets have their own exchanges and rules built on HL7 standards. In the UAE, health information exchanges such as NABIDH in Dubai, Malaffi in Abu Dhabi and Riayati under MOHAP publish their own integration specifications, which providers must follow. In the US, certified EHRs must offer standardised FHIR APIs, and US Core profiles define the baseline, with SMART on FHIR used to authorise apps. If you build products for more than one market, design an internal data model that can be mapped to each programme's profiles rather than coding to one of them.

Integration engines and architecture

Point-to-point connections between every pair of systems become unmanageable quickly. Most hospitals benefit from an integration layer that receives, transforms, routes and logs messages.

Open-source and commercial integration engines both work; the choice depends on volume, skills and support needs. Custom services in Node.js or Python are a good fit for FHIR facades and specific transformations. Our healthcare integration team designs this layer, and our Node.js development practice builds the services around it.

A step-by-step integration plan

1. Inventory systems: list every system, its vendor, version and the standards it supports.
2. Define flows: for each flow, note the trigger, sender, receiver, message type and timing.
3. Get specifications: obtain interface specs and sample messages from each vendor.
4. Map data: identifiers, codes, units and required fields, with decisions on gaps.
5. Build in a test environment: never develop against live clinical systems.
6. Test with real-world cases: duplicates, merges, cancellations, corrections, amended results and unusual characters in names.
7. Plan monitoring: alerts for failed messages and a queue staff can work through.
8. Go live in stages: one flow at a time, with fallbacks ready.
9. Document and hand over: specifications, mappings and runbooks for the support team.

Common pitfalls

• Assuming "supports HL7" means two systems will work together without mapping.
• Ignoring corrections and cancellations, so amended results never reach the record.
• Matching patients on name and age rather than identifiers.
• Building point-to-point links that nobody can monitor.
• Skipping terminology mapping, which blocks analytics and ABDM later.
• Treating integration as finished at go-live, when vendor upgrades can change message formats.

What drives integration cost

Cost depends on the number of systems, the quality of their interfaces, how much mapping is needed, testing effort and ongoing monitoring. A single analyser connection or ABDM milestone is a contained piece of work. A hospital-wide integration layer connecting HMS, LIS, RIS, PACS, pharmacy and national exchanges is a significant project. Vendor cooperation, or the lack of it, often affects timelines more than the technical work does.

Conclusion

HL7 FHIR integration is less about choosing one standard and more about using each where it fits: HL7 v2 for the hospital's internal event feeds, DICOM for imaging, FHIR R4 for APIs, apps and national programmes such as ABDM. Build an integration layer, map identifiers and codes carefully, test with real messages and monitor everything after go-live. Do that, and your hospital management system becomes a connected part of a wider health ecosystem rather than an island.