Most hospital administrators in India have heard FHIR mentioned by now. It appears in ABDM integration documents, NHA circulars, and every health-tech vendor pitch deck. What rarely gets explained is what FHIR actually requires your hospital to do differently with the records it already holds.
FHIR (Fast Healthcare Interoperability Resources) is an HL7 standard that structures clinical data as discrete, web-readable resources. India's ABDM mandates HL7 FHIR R4 for health record exchange. Records such as OP consultations, prescriptions, and diagnostic reports travel as FHIR bundles, packaged collections of linked resources that any compliant system can read.
What Is FHIR in Healthcare?
FHIR stands for Fast Healthcare Interoperability Resources. HL7 International publishes and maintains the standard, and India's Ayushman Bharat Digital Mission has adopted HL7 FHIR R4 as the required format for health data exchange. Think of it as a universal packaging specification. Your hospital produces data continuously: prescriptions, discharge summaries, lab results, OT notes. Without a common format, that data stays trapped inside your software. FHIR gives every piece of data a defined structure so that any compliant system, whether your hospital HIS, a patient's ABHA-linked app, or a government health scheme portal, can read it without custom translation work on either side.
In the FHIR healthcare India context, the standard operates at the point of exchange, not at the point of storage. Your HIS continues to store records as it always has. What changes is how records are packaged and transmitted when a patient or an authorised system requests them. The unit of exchange is a FHIR bundle, a structured document that groups related clinical resources into one package with a defined hierarchy.
This matters practically. ABDM FHIR compliance is now a prerequisite for hospitals and diagnostic labs connecting to the Health Information Exchange. Non-compliant systems cannot complete the handshake with the HIE gateway, which means your records stay invisible to the national health data network regardless of how good your internal software is.
FHIR Bundle Types: The Formats Your Hospital Must Produce
A FHIR bundle is the core unit of exchange under ABDM. It groups related resources, a Patient resource, a Practitioner resource, and a set of Observation or Condition resources, into one structured container with a Composition resource at the top acting as the document header. The ABDM implementation guide defines several bundle profiles; the four your hospital will encounter most often are in the table below.
| Bundle Type | Typical Trigger | Key Resources Inside |
|---|---|---|
| OPConsultation | Doctor completes an outpatient visit | Composition, Patient, Practitioner, Condition, MedicationRequest, Observation |
| Prescription | Doctor e-prescribes or pharmacist dispenses | Composition, MedicationRequest, dosage instructions |
| DiagnosticReport | Lab or radiology report finalised | DiagnosticReport, Observation, ImagingStudy |
| DischargeSummary | IP patient discharged | Composition, Encounter, Procedure, Condition, MedicationRequest |
Each resource within a bundle references the others by internal ID. This means the data must already exist in structured form inside your HIS before it can be packaged correctly. A discharge summary typed as one large free-text block in a single database field cannot be split into valid Condition, Procedure, and Observation resources automatically. The OPConsultation bundle is produced at the highest volume: a 200-bed hospital seeing 400 outpatients daily generates 400 bundles per day if every consultation is ABHA-linked. The DischargeSummary bundle is the most complex because it must capture the entire inpatient episode, including procedures performed, final diagnosis, and discharge medications, as a single coherent structured document.
Where Does the Data Actually Come From?
This is the question most vendors sidestep. FHIR bundles do not create data; they package data that already exists in structured form. If your OP module records diagnosis as a free-text string typed by a receptionist, you cannot produce a valid Condition resource. If your pharmacy stores drug names as locally invented abbreviations, your MedicationRequest resources will fail validation at the HIE gateway. Before any FHIR integration goes live, audit these five areas in your current system.
- Diagnosis coding: Conditions must use ICD-10 codes, not plain text descriptions. Check whether your HIS stores an actual code against each encounter or just a typed string.
- Drug coding: MedicationRequest resources need standard drug identifiers. ABDM recommends standard generic names aligned with the National Medicines List rather than brand-specific shorthand.
- Patient identity: Every bundle must include the patient's ABHA address or ABHA number as an identifier. If your registration desk is not capturing ABHA at admission, bundles will be structurally incomplete from the start.
- Practitioner identity: The treating doctor's NMC registration number must appear in the Practitioner resource. Ensure this is stored against each doctor's profile in your HIS, not just in a separate HR spreadsheet.
- Observation units: Lab results need LOINC-coded observation types with UCUM units, for example mg/dL or mmol/L. A result stored without a unit code will fail schema validation at the gateway.
Tier-2 and tier-3 hospitals often find that the data exists but is stored inconsistently. A 60-bed facility in Nashik or Vizag may have three to five years of records in whatever format the original implementation vendor used. Retrofitting that legacy data is a separate remediation project from the integration build itself, so scope and budget it separately before you commit to a go-live date.
Consent and Exchange: How FHIR Moves Between Systems
Producing a valid FHIR bundle is only half the problem. The other half is controlling who receives it. ABDM's HIE-CM (Health Information Exchange and Consent Manager) sits between providers. A patient grants consent through their ABHA app or a registered health locker, and the HIE-CM then sends a data request to your hospital's Health Information Provider endpoint. Your HIS must expose a FHIR-compliant API capable of the following steps in sequence.
- Receive a data request from the HIE-CM with a signed consent artefact attached.
- Validate the consent artefact: check the permitted date range, data types requested, and requester identity.
- Assemble the requested FHIR bundles from structured internal records matching the consent scope.
- Encrypt and transmit the bundles to the requesting Health Information User via the ABDM gateway.
The ABDM gateway uses asynchronous callbacks and webhooks, not simple synchronous REST calls. Your vendor must have tested the full consent flow against the ABDM sandbox before claiming compliance. Ask for a live sandbox demonstration with real test credentials. A screenshot or a PDF compliance certificate does not confirm that the flow actually works end to end.
Your hospital also becomes a Health Information User when your own doctors review records from referring facilities. A specialist in Pune seeing a patient referred from a district hospital in Latur can request that hospital's discharge summary through the HIE, provided the patient has consented. For this to work, your HIS needs a readable viewer for incoming FHIR bundles, not only an outbound emitter. One without the other means your doctors cannot benefit from ABDM even when your patients have consented to sharing.
Vendor Readiness: Questions to Ask Before You Sign
FHIR readiness claims exist on a wide spectrum. A statement that a product supports HL7 FHIR means almost nothing without specifics. Use this checklist during procurement or a licence renewal conversation to separate genuine capability from marketing copy.
- Which ABDM FHIR bundle profiles are validated? Ask for the specific ABDM Implementation Guide profile URLs the system validates against, not a generic claim about HL7 FHIR support.
- Is the ABDM sandbox integration live and demonstrable? Request a live demo through the NHA sandbox portal with real test credentials, not a pre-recorded walkthrough.
- How are ICD-10 codes managed in the OP module? Is there a built-in code picker at the point of consultation, or does the system accept free text that a coder maps later?
- How are incoming FHIR bundles rendered for clinical staff? Doctors need a readable structured view, not raw JSON in a browser window.
- What happens when a bundle fails validation? Is there an error log your IT team can access and act on, or do failed bundles silently drop?
- What is the commercial model for FHIR API calls? Some vendors charge a fee per bundle transmitted. A 100-bed hospital generating 200 OP visits and 50 discharges daily could produce 75,000 or more bundles per month. At that volume, per-call pricing becomes a significant recurring cost.
For hospitals running Ayushman Bharat empanelled wards, CGHS facilities, or ESI-attached units, record exchange volumes run higher than average because scheme patients often visit multiple facilities. Clarify the pricing model in writing before signing any contract.
How eMedHub Handles FHIR
eMedHub's electronic health records module treats ABDM FHIR R4 compliance as a core requirement, not a bolt-on feature negotiated after the base contract. The platform captures structured diagnosis codes through an integrated ICD-10 picker at the point of consultation, stores NMC registration numbers against each doctor's profile, and links patient records to ABHA at registration. When a consent request arrives from the HIE-CM, the system assembles the requested bundles from existing structured data, validates each bundle against the ABDM Implementation Guide profile, and transmits through the HIE gateway. Incoming bundles from other Health Information Providers render in a readable clinical view so your doctors can act on referred patient records without opening a developer tool.
If your hospital is planning ABDM integration or wants to test your current vendor's readiness, book a demo with the eMedHub team to walk through the live consent flow.
Frequently asked questions
What is FHIR in healthcare and why does it matter for Indian hospitals?
FHIR (Fast Healthcare Interoperability Resources) is the HL7 standard India's ABDM mandates for health record exchange. It defines how clinical data, including diagnoses, prescriptions, and lab results, is packaged as structured bundles that any compliant system can read. Hospitals connecting to the ABDM Health Information Exchange must produce valid FHIR bundles or their integration will fail at the gateway level.
Which FHIR bundle types does ABDM require hospitals to produce?
ABDM specifies several bundle profiles. The most common are OPConsultation for outpatient visits, Prescription for medication requests, DiagnosticReport for lab and radiology outputs, and DischargeSummary for inpatient episodes. Each bundle contains a Composition resource as its header plus linked clinical resources such as Condition, Observation, and MedicationRequest, all of which must be populated with structured, coded data rather than free text.
Does a hospital need FHIR compliance if it has not yet registered with ABDM?
Not immediately, but early preparation avoids significant rework later. If your HIS does not store ICD-10 codes, ABHA numbers at registration, or NMC registration numbers for doctors, retrofitting that data becomes a separate project from the integration build itself. Hospitals planning NABH accreditation or Ayushman Bharat empanelment will encounter ABDM integration requirements earlier than they typically anticipate.
How long does FHIR integration take for a 100-bed hospital?
Implementation time depends on two factors: how structured your existing data is and how mature your vendor's FHIR engine is. If diagnosis and drug data are already coded and ABHA capture is active at registration, a vendor with a tested ABDM integration can typically complete the HIE gateway connection in eight to twelve weeks. Unstructured legacy data takes considerably longer and should be scoped as a separate workstream.
Can existing patient records be converted to FHIR format retrospectively?
Only the structured portions convert reliably. A diagnosis stored as an ICD-10 code maps cleanly to a Condition resource. A handwritten note scanned as a PDF does not. For historical records, ABDM allows a phased approach: begin producing compliant bundles for all new records from the go-live date, then convert historical structured data in batches where data quality and coding consistency permit.