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

Evaluation Strategy

Atrius India Core evaluation strategy

Three layers

Layer Purpose Canonical base
Storage (HFS) Author and validate clinical and financial data for India https://atrius.in/fhir/r4/atrius-india-core/StructureDefinition/
Evaluation (primary) Run CQL and clinical reasoning on stored resources Atrius India Core profiles + Atrius India Core ValueSets
Evaluation (legacy) Run unmodified QI-Core ELM (e.g. imported US eCQMs) Optional projection per Runtime Mapping

New measures and custom clinical libraries SHALL target Atrius India Core profiles and India terminology. They do not require runtime projection when instances conform to Atrius India Core bindings at storage time.

When the mapper is not used

  • New Atrius-authored CQL with modelInfo pointing at Atrius India Core StructureDefinitions
  • Value set membership checked against Atrius India Core or NDHM ValueSets as bound in FSH
  • Resources carry meta.profile for the storage profile (including subtypes such as atrius-india-core-condition-encounter-diagnosis)
  • Category, status, and negation semantics are expressed in storage (profiles + slices), not injected at evaluation

When the mapper is used (legacy)

  • Third-party QI-Core ELM libraries you have not reauthored
  • Cross-checking storage against QI-Core validation expectations
  • Transition period while migrating measures from QI to Atrius India Core CQL

The mapper remains documented in Runtime Mapping for QI-Core Evaluation. It is optional for the India-primary path.

Profile design rules

  1. Parent FHIR R4 — Atrius India Core profiles parent base FHIR R4 resources, not NDHM or QI-Core StructureDefinitions.
  2. Structural QI parity — map QI-Core 6 qicore-keyelement paths to Atrius MS (documentation / CQL retrieve hints). HFS does not enforce MS. Do not copy the qicore-keyelement extension into Atrius StructureDefinitions.
  3. India bindings — use Atrius India Core or NDHM ValueSets on discriminating elements (category, class, status, payer type) instead of relying on evaluation-time coding injection.
  4. Subtypes in storage — use Atrius India Core sub-profiles (Condition, Observation, ServiceRequest negation, etc.) so CQL retrieves match storage meta.profile.
  5. Prefer storage over mapper — if QI and India terminology disagree on a coding, bind storage to a ValueSet that includes codes your measures use; do not depend on mapper injection for new content.

QI-Core constraint ceiling

QI-Core 6.0.0 differentials use zero mustSupport; quality-significant paths are qicore-keyelement. Snapshot mustSupport on QI profiles is inherited from US Core parents and is not the Atrius parity target. Do not add hl7.fhir.us.qicore as an IG dependency.

Resource class Atrius may add Atrius must not add
NDHM also profiles the type (Patient, Encounter, Condition, Observation, Procedure, Immunization, ServiceRequest, MedicationRequest, Communication, Task, Claim, …) NDHM MS / cards / CompleteCoding / India bindings; QI subtypes (negation, condition category) that do not tighten the base profile vs NDHM US Core / VSAC / CMS bindings; QI required non-negative status on the base (would reject NDHM-valid not-done); QI-only extensions (race, ethnicity, qicore-recorded, qicore-notDoneValueSet, qicore-doNotPerformReason); extra cards/MS beyond NDHM ∪ QI keyelement
QI-Core type, no NDHM profile (DeviceRequest, Device, MedicationAdministration, MedicationDispense, AdverseEvent, …) QI keyelement set as Atrius MS; QI cardinality on negation subtypes; Atrius-owned copies of non-negative status ValueSets where QI binds them Extra MS beyond QI keyelement; US-realm ValueSets (http://hl7.org/fhir/us/qicore/ValueSet/*)
NDHM-only (Appointment, Invoice, ChargeItem, Composition records, …) No QI-Core work n/a

Keep the NDHM Observation taxonomy. Do not author US Core Observation profiles (observation-lab, clinical-result, screening-assessment, simple-observation, nonpatient-observation) — the runtime mapper projects those for legacy ELM. QI-Core extensions (qicore-notDoneValueSet, qicore-doNotPerformReason, qicore-recorded, POA, elective, appropriateness) stay mapper-only; storage uses HL7 codeOptions / event-recorded instead.

Machine check: scripts/qicore-parity-diff.py → docs/qicore-parity-report.md.

Terminology sources

Source Package / path Documentation
NDHM (ABDM) ndhm.in 6.5.0 in sushi-config.yaml NDHM terminology, FSH input/fsh/aliases/aliases_ndhm.fsh
Atrius India Core This IG (atrius.fhir.r4.india) Terminology artifacts

NDHM ValueSets are referenced explicitly in FSH bindings where India code lists apply. NDHM profiles are not used as parents.

Terminology binding policy

Strength Use for
required Small closed sets Atrius India Core owns (fixed category slices on subtype profiles; Atrius-owned non-negative status on QI-only MedAdmin / MedDispense positives)
extensible Admin and clinical routing ValueSets that may grow (encounter class, claim status, observation category, coverage type)

Do not copy entire HL7 or SNOMED value sets as required Atrius India Core enumerations.

QI-Core ValueSets at storage

QI-Core ValueSet Decision
qicore-non-negative-*-status on NDHM-overlapping types (Procedure, Communication, Immunization, Observation, Task) Do not bind on the base. Negation subtypes fix status; NDHM-valid not-done must still validate as the base profile.
qicore-non-negative-medication-admin-status / medicationdispense-status Clone as Atrius-owned, required on the positive MedAdmin / MedDispense profiles only (no NDHM profile). Negation subtypes parent an abstract common profile with no status binding (QI-Core parents R4 directly); do not re-bind or inherit the non-negative binding.
qicore-negation-reason Mapper-only (VSAC US SNOMED). Do not bind at storage.
qicore-present-on-admission (CMS HAC) Do not use. Keep CQL atrius-vs-present-on-admission.
qicore-medication-dose-type / qicore-observation-body-position Skip (do not clone).

Do not depend on http://hl7.org/fhir/us/qicore/ValueSet/* at storage time.

Phase 2 — clinical reasoning content (in progress)

  • Atrius India Core CQL library package and modelInfo generation (regenerate after profile URL change)
  • VSAC India mappings for measure value sets
  • Rust mapper implementation consuming the profile manifest
  • Authored PlanDefinition resources (CDSHooksServicePlanDefinition) and KR migration off bulk eCQM — see docs/authoring-plan.md in the repository

See Profile inventory for per-profile terminology, QI-Core alignment notes, and legacy mapper flags.