Atrius India Core FHIR Implementation Guide
0.1.0 - ci-build

Atrius India Core FHIR Implementation Guide - Local Development build (v0.1.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

Atrius and Ndhm

Atrius and NDHM (ABDM)

Atrius India Core is an operational national-grade FHIR IG for hospital EMR, ambulatory care, CDS, and quality measurement. Published NDHM/ABDM (ndhm.in 6.5.0) is our compatibility baseline for India data exchange — not our inheritance chain or product ceiling.

Official NDHM IG: ABDM FHIR IG v6.5.0
Atrius canonical base: https://atrius.in/fhir/r4/atrius-in/


Strategy

Principle Atrius approach
Storage & CDS meta.profile = Atrius URLs; profiles parent FHIR R4
NDHM alignment Same must-support, profile-specific bindings, slices, document shapes, element min/max, complete Coding (system/code/display), and literal Reference.reference as published NDHM profiles
Extensions Where NDHM defines an extension, Atrius uses that NDHM URL. Atrius adds hospital ops, scheduling/ADT, CDS, and richer terminology only where NDHM is silent
ABDM export Outgoing bundles mapped to NDHM record/bundle profiles and validated at the boundary
QI-Core Second layer for negation profiles and eCQM projection (runtime-mapper)

We do not use Parent: $ABDMPatient in FSH. We do implement NDHM constraints in Atrius FSH so instances are NDHM-conformant by validation, while remaining Atrius-canonical by URL.

Bindings: NDHM profiles parent FHIR R4 the same way Atrius does. Bindings such as Patient.gender, Patient.telecom.system, and Composition.status are unchanged from R4 in NDHM — they appear in NDHM snapshots but not in NDHM differentials. Parity work only re-declares bindings NDHM changes (e.g. Patient.identifier.typendhm-identifier-type-code).

Published NDHM 6.5.0  ⊂  Atrius India Core  ⊕  Atrius innovations
                              ↓
                    QI-Core where CDS/eCQM requires

Why not inherit NDHM StructureDefinitions?

NDHM 6.5.0 is a small IG (~63 StructureDefinitions) focused on documents, claims, and basic clinical resources. It has seen limited evolution while hospital platforms need scheduling, ADT, orders, pathways, and strict CDS validation.

Inheriting NDHM profiles would:

  • Anchor Atrius to an outdated constraint set
  • Complicate CDS and QI-Core (conflicting must-support and reference graphs)
  • Hide Atrius leadership behind NRCES canonical URLs

Instead, Atrius documents parity explicitly and validates export against NDHM.


Parity status (summary)

Legend: match = Atrius satisfies NDHM when validated; stricter = superset; partial = known gaps; extension = Atrius-only; n/a = no NDHM profile.

Actors and encounters

NDHM profile Atrius profile Parity Notes
Patient atrius-in-patient match MS + NDHM identifier.type; ABHA in examples
Practitioner atrius-in-practitioner match MS + NDHM identifier.type; HPID in examples
Organization atrius-in-organization match MS + NDHM identifier.type; ROHINI/HIP facility id
PractitionerRole atrius-in-practitionerrole match MS + NDHM role VS on code
Encounter atrius-in-encounter match MS + NDHM encounter-type / diagnosis-use; Atrius encounter-class VS
Appointment atrius-in-appointment match NDHM MS parity; Atrius OPD service + visit-mode extensions
Coverage atrius-in-coverage match NDHM + Atrius coverage-type VS

Clinical (NDHM-mapped)

NDHM profile Atrius profile Parity Notes
Condition atrius-in-condition match MS + code.coding/text; QI subtypes = extension
Observation atrius-in-observation match Base observation MS
ObservationVitalSigns atrius-in-observation-vital-signs match NDHM vital-signs VS on code
ObservationBodyMeasurement atrius-in-observation-body-measurement match NDHM body-measurement VS
ObservationGeneralAssessment atrius-in-observation-general-assessment match NDHM general-assessment VS
ObservationLifestyle atrius-in-observation-lifestyle match NDHM lifestyle VS
ObservationPhysicalActivity atrius-in-observation-physical-activity match NDHM physical-activity VS
ObservationWomenHealth atrius-in-observation-women-health match NDHM women-health VS
AllergyIntolerance atrius-in-allergyintolerance match MS + code.coding/text
Procedure atrius-in-procedure match  
ServiceRequest atrius-in-servicerequest match MS includes text; negation subtypes = extension
MedicationRequest atrius-in-medicationrequest match NDHM medicine/route VS; negation subtypes = extension
MedicationStatement atrius-in-medicationstatement match NDHM medicine/route VS
Immunization atrius-in-immunization match NDHM vaccine-codes VS
DiagnosticReportLab atrius-in-diagnosticreport-lab match Full NDHM lab MS
DiagnosticReportImaging atrius-in-diagnosticreport-note match Full NDHM imaging MS
Claim atrius-in-claim match NDHM VS bindings + supportingInfo MS
ClaimResponse atrius-in-claimresponse match  

Payer and financial (NDHM-mapped)

NDHM profile Atrius profile Parity Notes
Medication atrius-in-medication match NDHM identifier.type binding
ImmunizationRecommendation atrius-in-immunizationrecommendation match Used in ImmunizationRecord
Invoice atrius-in-invoice match NDHM invoice-types + price-components VS
CoverageEligibilityRequest atrius-in-coverageeligibilityrequest match PMJAY/eligibility path
CoverageEligibilityResponse atrius-in-coverageeligibilityresponse match  
InsurancePlan atrius-in-insuranceplan match 6 NDHM VS bindings; NDHM min cardinalities (identifier/type/period/ownedBy/coverage/plan.type)
ChargeItem atrius-in-chargeitem match NDHM chargeitem-types VS; Atrius charge-master provenance is extension
ChargeItemDefinition atrius-in-chargeitemdefinition n/a Atrius schedule / package definition
Contract atrius-in-payer-contract n/a Payer schedule binding; not practitioner compensation
PaymentNotice atrius-in-paymentnotice match R4 baseline (NDHM has no differential MS)
PaymentReconciliation atrius-in-paymentreconciliation match NDHM payment-type on detail.type
CarePlan atrius-in-careplan match category.coding/text MS
FamilyMemberHistory atrius-in-familymemberhistory match relationship/condition/reasonCode MS
Specimen atrius-in-specimen match NDHM specimen-types VS
ImagingStudy atrius-in-imagingstudy match  
Task atrius-in-task match NDHM task/reason/input/output VS
Communication atrius-in-communication match  
CommunicationRequest atrius-in-communicationrequest match  

Interop references and payloads

NDHM profile Atrius profile Parity Notes
DocumentReference atrius-in-documentreference match Attachment MS; Atrius actor refs
Media atrius-in-media match Modality + content MS
Binary atrius-in-binary match Embedded document payloads

Exchange bundles

NDHM profile Atrius profile Parity Notes
DocumentBundle atrius-in-document-bundle match ABDM clinical document envelope
ClaimBundle atrius-in-claim-bundle match Collection + Claim entry slice
ClaimResponseBundle atrius-in-claimresponse-bundle match Collection + ClaimResponse entry slice
CoverageEligibilityRequestBundle atrius-in-coverageeligibilityrequest-bundle match Single eligibility request
CoverageEligibilityResponseBundle atrius-in-coverageeligibilityresponse-bundle match Single eligibility response
InsurancePlanBundle atrius-in-insuranceplan-bundle match Collection + InsurancePlan entry slice
TaskBundle atrius-in-task-bundle match Single Task entry

NDHM extensions (used at NDHM canonicals)

NDHM 6.5.0 defines four extensions. Atrius profiles slice them in at the published https://nrces.in/ndhm/fhir/r4/StructureDefinition/... URLs. Instances therefore already have ABDM wire shape (outer NDHM url; inner slice urls such as category and claim-condition). Atrius does not re-publish clones of these extensions.

NDHM authors Claim-* Extension.context as profile-qualified element ids (…/InsurancePlan#InsurancePlan, …#InsurancePlan.plan, and so on). The FHIR validator accepts those only when the instance has no errors against the NDHM InsurancePlan profile. BrandName uses the same pattern on Immunization and passes because NDHM Immunization adds no extra min=1 beyond R4. NDHM InsurancePlan does (identifier 1..1, type 1..1, period 1..1, ownedBy 1..1, coverage 1.., plan.type 1..1). Atrius copies those cardinalities so a valid AtriusInInsurancePlan instance also satisfies the NDHM context check. Parenting R4 is not the cause.

NDHM extension Canonical Used on
BrandName StructureDefinition/BrandName Immunization
Claim-Condition StructureDefinition/Claim-Condition InsurancePlan coverage, coverage.benefit, plan
Claim-Exclusion StructureDefinition/Claim-Exclusion InsurancePlan root, plan
Claim-SupportingInfoRequirement StructureDefinition/Claim-SupportingInfoRequirement InsurancePlan root, coverage, coverage.benefit, plan

Full matrix (63/63 NDHM StructureDefinitions mapped) is maintained in this page and updated as FSH parity work closes gaps (see project ndhm_parity.plan.md). Automated diff: docs/ndhm-parity-report.md (regenerate with python3 scripts/ndhm-parity-diff.py).

Composition records (ABDM documents)

NDHM record Atrius composition profile Parity Notes
OPConsultRecord atrius-in-op-consult-record match MS + 12 SNOMED section slices
DischargeSummaryRecord atrius-in-discharge-summary-record match MS + 10 section slices
PrescriptionRecord atrius-in-prescription-record match MS + MedicationRequest/Binary entry slices
DiagnosticReportRecord atrius-in-diagnostic-report-record match MS + NDHM diagnostic-report-type; entry slices
WellnessRecord atrius-in-wellness-record match MS + 8 title-discriminated wellness sections
ImmunizationRecord atrius-in-immunization-record match MS + Immunization/Recommendation/DocumentReference entries
HealthDocumentRecord atrius-in-health-document-record match MS + unstructured document section
InvoiceRecord atrius-in-invoice-record match MS + NDHM invoice-types; Invoice entry slice

Export packaging uses atrius-in-document-bundle (NDHM DocumentBundle parity) at the ABDM boundary — see export adapter plan.

Atrius extensions (no NDHM equivalent)

Atrius artifact Purpose
atrius-in-schedule, -slot OPD scheduling
atrius-in-episode-of-care ADT care episodes
atrius-in-location-bed Bed board
atrius-in-schedule-recurrence iCal recurrence
atrius-in-appointment-visit-mode In-person / tele
atrius-in-consult-follow-up-appointment OP consult plan
Clinical reasoning (PlanDefinition, ActivityDefinition, …) CDS pathways

Terminology

Layer Source
NDHM CS/VS (20 + 48) Dependency ndhm.in; see NDHM terminology
Atrius CS/VS India OPD, visit mode, encounter class, composition sections, …
Atrius supersets Where Atrius needs extra codes on an NDHM-bound path, the local ValueSet includes the NDHM ValueSet (e.g. AtriusPrivilegeVS includes ndhm-practitioner-role). Binding strength is at least NDHM's.
Atrius-only bindings Paths NDHM leaves unconstrained (encounter class, care-plan category, appointment type, …) may bind Atrius ValueSets

Validation model

Operation Validates against
HIS create/update (production) Atrius profiles (HFS_PROFILE_VALIDATION_MODE=strict)
CDS / CQL evaluation Atrius storage profiles
ABDM document export preflight NDHM record + DocumentBundle profiles
CMS eCQM (legacy) QI-Core via runtime-mapper

Leadership and national standard

Atrius publishes an open IG NPM package, reference server, conformance examples, and a public parity matrix showing full NDHM 6.5.0 coverage plus extensions. Goal: become the implementation reference for Indian hospital FHIR — input to a future NRCES/ABDM revision, not a fork that ignores the published baseline.

Implement NDHM. Extend where India needs more. Prove it in production.