HL7 FHIR in India: What Hospitals Need to Know (FHIR vs HL7 v2 vs ASTM)

TL;DR: HL7 FHIR is the modern standard for exchanging health records as small, structured resources over REST APIs. In India it matters because ABDM health record exchange uses FHIR R4-based profiles published by NRCeS. But FHIR does not replace everything: lab analyzers still talk HL7 v2 and ASTM. This guide explains the differences and gives hospitals a practical roadmap.

If you run IT for an Indian hospital, you have probably heard three acronyms thrown around in vendor meetings: HL7, FHIR and ASTM. They are often mentioned in the same breath, as if they were interchangeable. They are not. Each one solves a different problem, at a different layer of the hospital, and a modern hospital usually needs more than one of them.

The reason FHIR keeps coming up in India is the Ayushman Bharat Digital Mission (ABDM). When a patient's records move between hospitals, labs and the patient's own PHR app through the ABDM network, they move as FHIR documents. If you want the bigger picture on ABDM itself, read our ABDM and ABHA integration guide for hospitals. This article focuses on the standards underneath it.

What Is HL7 FHIR?

FHIR stands for Fast Healthcare Interoperability Resources. It is a standard published by HL7 International, the same organisation behind the older HL7 v2 messaging standard. FHIR was designed for the web era, and three ideas sit at its core.

1. Resources

FHIR breaks healthcare data into small, well-defined building blocks called resources. Each resource describes one thing. A few you will see often:

• Patient: demographics and identifiers, such as name, gender, date of birth and an ABHA number
• Encounter: a visit, admission or consultation
• Observation: a single measurement, such as a haemoglobin value or a blood pressure reading
• DiagnosticReport: a lab or imaging report that groups related observations
• MedicationRequest: a prescription
• Composition and Bundle: used to package several resources together into one clinical document, such as a discharge summary

Because every resource has a published structure, two systems that both understand "Observation" can exchange a lab value without a custom mapping for every pair of vendors.

2. REST APIs

FHIR uses the same style of API that the rest of the web uses. Systems read and write resources over HTTPS with standard verbs: GET to read, POST to create, PUT to update. A request like GET /Patient/123 returns one patient. That makes FHIR much easier for today's developers to work with than older healthcare formats that need specialised parsers.

3. JSON (and XML)

FHIR resources are usually sent as JSON, the format almost every modern web and mobile application already uses. XML is also supported. Either way, the data is human-readable and self-describing, so a developer can open a FHIR message and understand what it contains.

Profiles and terminology

The base FHIR specification is deliberately broad, so countries and programmes narrow it down with profiles: rules that say which fields are mandatory, which code systems to use, and how resources fit together for a given use case. FHIR also expects clinical concepts to be coded with standard terminologies such as SNOMED CT for clinical terms and LOINC for lab tests, rather than free text alone.

FHIR has gone through several releases. R4 is the release most national programmes, including India's, build on today.

FHIR vs HL7 v2 vs ASTM: How They Compare

Here is how the three standards differ in practice. For a deeper look at the lab side, see our guide to ASTM and HL7 bidirectional lab machine interfaces.

The short version: ASTM and HL7 v2 move data inside the hospital, close to the machines. FHIR moves records between organisations and out to patients.

Why FHIR Matters for Indian Hospitals

ABDM uses FHIR for health record exchange

Under ABDM, a hospital that shares records acts as a Health Information Provider (HIP), and an organisation that requests them acts as a Health Information User (HIU). Records move only with the patient's consent, through ABDM's consent manager.

The records themselves travel as FHIR documents. The FHIR implementation guide for ABDM is published by NRCeS (the National Resource Centre for EHR Standards), and its profiles are based on FHIR R4. The guide covers common record types such as OP consultation notes, prescriptions, diagnostic reports and discharge summaries.

In practice, that means an ABDM-ready HMS must be able to take a discharge summary or lab report from its own database, convert it into the matching FHIR document, and share it when a consented request arrives. It also needs to link those records to the patient's ABHA number.

Exact profile names and versions are updated over time, so always work from the current NRCeS implementation guide and the ABDM sandbox documentation rather than an old copy.

Patients now carry their records

With ABDM, a patient can pull records from different hospitals into a PHR app. If your hospital cannot produce records in the expected FHIR format, your reports simply will not show up there, while a competitor's will.

FHIR makes future integrations cheaper

Even outside ABDM, a FHIR interface is easier to reuse. Insurance partners, telemedicine apps and analytics tools increasingly expect REST and JSON. Building those connections on a shared standard is usually simpler than a one-off integration for every partner.

Where HL7 v2 and ASTM Still Rule: The Lab Analyzer

Here is the part that vendor marketing often skips. Most lab analyzers in Indian hospitals do not speak FHIR. Hematology counters, biochemistry analyzers and many immunoassay systems send results over ASTM or HL7 v2, often across a serial cable or a direct TCP connection on the lab network.

That is not going to change because of ABDM. ABDM governs how records leave the hospital. It does not change how a Mindray hematology analyzer talks to the PC sitting next to it.

So a typical modern setup has two layers:

1. Inside the lab: analyzers send results to LIS middleware using ASTM or HL7 v2. The middleware parses them and passes clean values to the HMS.
2. At the hospital boundary: the HMS assembles those results into a diagnostic report and, when ABDM sharing is needed, converts it into a FHIR document.

Our own LIS Middleware works at the first layer. It is a Windows application that connects Mindray BC-5000 and BC-5150 hematology analyzers and BS-240 and BS-480 chemistry analyzers to OmniWorks HMS over a network (TCP) or USB/Serial link. On the protocol side, it handles ASTM E1394 records and HL7 v2.3.1 result (ORU) messages over MLLP, acknowledges each transmission, and pushes the values to the HMS within seconds. It also sends test orders from the HMS to the analyzer, and it can connect other analyzers that speak ASTM or HL7. It does not use FHIR to talk to analyzers, because the analyzers do not.

If you are trying to replace manual result entry in your lab, the protocol you need is whatever your analyzer sends, not FHIR. Our step-by-step guide to connecting a Mindray BC-5000 shows what that looks like in practice.

What a Hospital or HMS Needs to Do

Getting FHIR-ready is less about the standard and more about your data. FHIR will faithfully transmit whatever is in your system, including mistakes. Here is what matters.

Clean, structured patient identity

Every FHIR record points to a Patient resource. If your registration desk creates duplicate patient records, or stores phone numbers and names inconsistently, those problems travel into every shared document. Link ABHA numbers to the correct patient record at registration.

Structured clinical data, not just PDFs

A scanned discharge summary is better than nothing, but a structured one, with diagnoses, medications and lab values as separate fields, is far more useful. The more of your clinical workflow is captured in structured fields inside the HMS, the better your FHIR output will be.

Standard codes for tests and diagnoses

Map your internal lab test codes to LOINC and your diagnoses to a standard coding system. This mapping is tedious, one-time work, and it is often the biggest task in a FHIR project. Start with your highest-volume tests.

Consent and audit

ABDM sharing is consent-driven. Your HMS should record what was shared, with whom, and under which consent, and your staff should understand how the consent flow looks to a patient.

Security

FHIR runs over HTTPS, so the usual web security basics apply: encrypted connections, strong authentication between systems, access control by role, and logs you can actually review.

The right questions for your HMS vendor

Before you sign or renew, ask your vendor directly:

• Which ABDM milestones have you completed, and can you show it in the sandbox or production?
• Which ABDM health record types can your system share as FHIR documents today?
• Which version of the NRCeS implementation guide do you follow, and how do you handle updates?
• How do lab results from the analyzer reach the shared diagnostic report?
• Who maintains the code mappings (LOINC and others), you or us?

Clear, specific answers are a good sign. Vague answers like "fully FHIR compliant" without detail are not.

A Practical FHIR Roadmap for Indian Hospitals

You do not need to do everything at once. A phased approach works better.

Step 1: Map your current systems

List every system that holds patient data: HMS, LIS, radiology, pharmacy, billing and any standalone apps. Note how each one connects today, whether by HL7 v2, ASTM, file export or manual re-entry.

Step 2: Fix the lab layer first

If technicians are still typing analyzer results into the HMS, fix that before worrying about FHIR. Automated capture through LIS middleware gives you accurate, structured lab values, which is exactly what a good FHIR diagnostic report needs later.

Step 3: Clean up master data

Deduplicate patient records, standardise registration fields, and start the lab test code mapping. This is unglamorous work, but it decides the quality of everything you share.

Step 4: Turn on ABDM identity and linking

Start ABHA creation and verification at registration, and link ABHA numbers to existing patient records. This is the foundation for record sharing.

Step 5: Share records through ABDM

Work with your HMS vendor to share the record types that matter most to your patients first, typically prescriptions, lab reports and discharge summaries. Test in the ABDM sandbox before going live.

Step 6: Extend to other partners

Once you have FHIR output for ABDM, consider reusing it for insurance partners, telemedicine and referral networks.

Where OmniWorks Fits

OmniWorks HMS is built to be ABDM-ready, with support for ABHA creation, PHR linking and consent-based health record sharing. When records are shared through ABDM, OmniWorks HMS sends them in the FHIR format ABDM requires. On the lab side, OmniWorks LIS Middleware handles the ASTM and HL7 v2 layer between analyzers and the HMS, so results enter the system as structured data instead of retyped values.

If you are planning your hospital's interoperability roadmap and want to see how lab results flow from the analyzer into the HMS, we are happy to walk you through it.

Frequently Asked Questions

Is FHIR replacing HL7 v2 in India?

Not inside the hospital, at least not soon. FHIR is the standard for ABDM health record exchange and for newer web-based integrations. HL7 v2 and ASTM remain common between lab analyzers, LIS and hospital systems, and most analyzers do not support FHIR.

Which FHIR version does ABDM use?

ABDM's health record exchange uses profiles based on FHIR R4, published by NRCeS in its FHIR implementation guide for ABDM. Always check the current NRCeS guide for the latest profile versions.

Do I need FHIR to connect my lab analyzers to the HMS?

No. Lab analyzers usually send results using ASTM or HL7 v2. LIS middleware receives those messages and passes the results to your HMS. FHIR comes in later, when records are shared outside the hospital.

What is the difference between HL7 v2 and HL7 FHIR?

Both come from HL7 International. HL7 v2 uses pipe-delimited messages sent over TCP, usually with MLLP framing, and is mostly used inside a hospital. FHIR uses resources in JSON or XML over HTTPS REST APIs, and is designed for exchange across organisations, apps and national networks.

Does a hospital need to be ABDM-ready to use FHIR?

No. FHIR is a general standard and can be used for any integration. But in India, ABDM is the main reason most hospitals will need FHIR output, because ABDM health record exchange depends on it.

FAQ Schema JSON-LD