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 — align must-support, subtypes, and cardinality with QI-Core where India exchange allows, without forcing US-only codings at storage.
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.

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)
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.

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.