HL7 FHIR in India: The Standard Underneath Every ABDM Claim Your Vendor Makes

Ask a hospital software vendor whether their product is ABDM compliant and you will get a yes. Ask what FHIR resources they produce for a discharge summary and the conversation changes character, because the second question cannot be answered from a brochure.

FHIR is the format underneath all of it. ABDM's health information exchange moves FHIR bundles. NHCX moves insurance claims as FHIR. The EHR Standards notified by the Ministry of Health and Family Welfare name it. Every interoperability promise a vendor makes in India resolves, eventually, to whether their system can emit and consume valid FHIR R4 — and a surprising number of systems that hold current certification do it through a translation layer that works for the certification test cases and little else.

What is HL7 FHIR?

FHIR — Fast Healthcare Interoperability Resources, pronounced "fire" — is a healthcare data exchange standard built from small, individually addressable units called resources, exchanged over ordinary web APIs as JSON or XML.

The word that matters is resources. Older healthcare messaging, HL7 v2 in particular, moved pipe-delimited messages describing events: a patient was admitted, a result was reported. FHIR instead defines discrete things — a Patient, an Encounter, a Condition, an Observation, a MedicationRequest, a DiagnosticReport — each with a defined structure and its own URL. A discharge summary is not a document format in FHIR; it is a Bundle that gathers a Composition and the resources it references.

This is why FHIR won and why it is harder than it looks. It won because a REST API returning JSON is something any developer can consume without a healthcare integration engine. It is harder than it looks because agreeing on the resource shape is the easy half, and agreeing on what goes in the fields — which code system, which identifier, which cardinality — is the half that determines whether two systems actually understand each other.

Why does FHIR matter specifically in India?

Because ABDM chose it, and everything built on ABDM inherits that choice. India's national digital health architecture is built on FHIR R4, with a country-specific implementation guide maintained by NRCeS that constrains the general standard into the profiles Indian systems must produce.

That last point is the one that gets lost. "Supports FHIR" is a much weaker claim than "conforms to the ABDM FHIR implementation guide", because the general standard leaves most fields optional and the national profile does not. A system can emit technically valid FHIR that an ABDM gateway rejects, for the same reason a technically valid English sentence can fail to be a valid legal filing.

The practical consequence for a buyer is that there are two questions, not one. Does the system speak FHIR at all? And does it conform to the current ABDM implementation guide version — which moves, and has moved several times. A vendor who cannot name the implementation guide version they build against has answered the second question.

The ABDM milestone guide covers what certification tests; the NHCX article covers the claims side, which uses the same machinery for a completely different transaction.

What does a hospital actually have to produce?

The resources that carry the clinical record a patient consents to share, bundled into the ABDM-defined document types.

For most hospitals that means being able to generate, from real transactional data rather than from a form somebody fills in afterwards:

• A Patient resource with correctly formed identifiers, including the ABHA address
• Encounter resources for OPD visits and IPD admissions with real timestamps
• DiagnosticReport and Observation for laboratory and imaging results, with results as values rather than as a scanned PDF
• Condition with coded diagnoses, which is where most Indian systems are thinnest
• MedicationRequest and MedicationStatement for prescriptions
• Composition-led bundles for the ABDM document types — discharge summary, OP consultation, prescription, diagnostic report, wellness record, immunisation record

Read that list against your current system honestly. The uncomfortable entries are usually Condition and Observation. A hospital whose diagnoses live as free text in a consultation note, and whose lab results arrive as PDFs from the analyser, can produce a bundle — but it will be a bundle wrapping unstructured content, which satisfies a gateway and helps no one downstream. The structured clinical record question is the same question in different clothing.

Is a translation layer good enough?

For passing certification, often. For everything you would want interoperability for, usually not, and the difference shows up two years later rather than at go-live.

A translation layer sits between a legacy database and the gateway, mapping columns to FHIR fields on the way out. It is a legitimate engineering approach and plenty of certified systems use one. The failure mode is that the mapping is only as rich as the source: if the underlying table has one free-text field where the profile expects a coded Condition, the translator must either leave it empty or stuff text into a coded field. Both pass a syntax check. Neither produces a record another hospital can use.

The way to test this without reading anyone's code is to ask for output. Request the actual FHIR bundle for a real discharge — de-identified — and read it. Are diagnoses coded, or is there a `text` field carrying a sentence? Are lab results Observations with values and units, or one DocumentReference pointing at a PDF? Are the timestamps the real event times, or all identical because they were stamped at export? Fifteen minutes with one bundle tells you more than a day of demos.

What should be in the contract?

Version commitments and export rights, because the standard moves and vendors do not always follow it on your timetable.

Four clauses worth insisting on. Name the ABDM FHIR implementation guide version the system conforms to today, and commit to a window for supporting future published versions. Require that the hospital can request a FHIR export of its own data on demand, in bulk, without a per-record charge — this is the single most valuable exit clause available to an Indian hospital and almost nobody asks for it. Require that gateway failures are visible to the hospital rather than swallowed. And put the conformance obligation on the vendor rather than on "the integration partner", so it does not become an argument between two suppliers while you are non-compliant.

The switching article covers why the export clause matters far more than it seems when you sign.

Where Kōami fits

Kōami stores the clinical record structurally — coded diagnoses, orders as orders, results as values with units — which is the part that makes FHIR output meaningful rather than merely valid. The ABDM bundles are generated from those records as events happen, not assembled by a nightly job reading free text.

We would rather be tested on this than described. The useful thing to ask for at a demo is the bundle: pick a discharge, ask for the FHIR it produces, and read the Condition and Observation resources. Then ask the same of everyone else on your shortlist. It is the fastest way to sort systems that are interoperable from systems that are certified.