NRCeS FHIR profiles
India's national FHIR profiles — what NRCeS publishes, why base FHIR alone is never enough for a country, and how the ABDM Implementation Guide constrains R4 into something interoperable.
In one line
NRCeS — the National Resource Centre for EHR Standards — publishes India's national FHIR profiles: the constrained, opinionated version of FHIR R4 that ABDM systems must speak so that two conformant implementations can actually understand each other.
Why base FHIR is never enough
This is the single most misunderstood thing about FHIR, and it's worth being blunt.
Plain FHIR does not make two systems interoperable. It makes them syntactically
compatible, which is a much weaker claim than it sounds. Base FHIR is deliberately permissive:
almost every element is optional, Patient.identifier accepts any identifier system you like,
and codes can come from any vocabulary. Two hospitals can both emit flawless, spec-valid FHIR
Patient resources and share nothing meaningful — one keying on a hospital MRN, the other on a
national ID, with names structured differently and neither carrying the field the other needs.
Valid FHIR. Zero interoperability.
A profile fixes that by removing freedom. It says: for India, Patient must carry an
ABHA identifier, in this system, with these fields mandatory and
these codes drawn from this ValueSet. Interoperability isn't what the standard gives you — it's
what the profile takes away.
What NRCeS actually publishes
The FHIR Implementation Guide for ABDM is a real, versioned artefact, not a policy document:
- Built on FHIR R4 (4.0.1).
- 38 core profiles, 42 terminology ValueSets, and 92 examples.
- An NHCX layer for claims, adding 10 CodeSystems,
17 ValueSets and 51 examples, with claim artefacts profiled on the
Bundleresource. - Terminology anchored in SNOMED CT and LOINC.
The examples matter more than people expect. A profile tells you the rule; an example shows you what a conformant instance looks like when a real person's data is in it. When you're stuck, read the examples first.
It moves — and you must track which version
Current published guidance sits at v6.5.0, with v7.0.0 in preview. That versioning is not bureaucratic noise; it's the thing that breaks your integration.
The practical rule: pin the IG version you built against and know it. "We're ABDM FHIR compliant" is a meaningless sentence on its own. Compliant with which IG version? A bundle that validated perfectly against one version can fail the next when a binding tightens or a cardinality changes. Treat the IG version like a dependency version, because that's exactly what it is.
India's profiles vs US Core
If you know US Core, NRCeS will feel familiar in shape and different in substance — and the differences are precisely the interesting part:
- Identity. US Core builds around MRNs and payer identifiers; NRCeS builds around ABHA. A national health ID as the anchor is a structurally different starting point.
- Consent. US Core largely assumes HIPAA's treatment/payment/operations permissions. NRCeS lives inside ABDM's consent-artefact world, where a flow requires an explicit, scoped grant.
- Terminology. Both lean on SNOMED and LOINC; the coding systems around the edges differ, and claims diverge sharply — X12 in the US, FHIR-native in NHCX.
The deeper lesson generalises: profiling is where a global standard meets a real country. Every nation adopting FHIR does this, because every nation has its own identity system, its own laws and its own vocabularies. There is no such thing as a country using "just FHIR".
Working with them
Read the comparison of US Core and NRCeS profiling for the mechanics of profiling itself, and practise against the profiling and FHIR labs before taking your bundles to the Sandbox. Validation failures are far cheaper to learn from on synthetic patients.