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

Runtime Mapper

Runtime Mapping for QI-Core Evaluation

Legacy / optional. Primary evaluation for new Atrius measures uses Atrius profiles and Atrius ValueSets directly — see Atrius evaluation strategy. Use this page when running unmodified QI-Core ELM or validating projected shapes against QI-Core.

This page defines the Atrius runtime projection behavior from Atrius authoring/storage profiles into QI-Core evaluation shapes used by CQL execution.

Purpose and scope

• Atrius data is authored and stored on HFS using Atrius profiles under https://atrius.in/fhir/r4/atrius-core/StructureDefinition/.
• CQL $evaluate uses unchanged QI-Core ELM and QI-Core model semantics.
• A runtime mapper projects Atrius resources into QI-Core-compatible shapes immediately before evaluation.

Profiles in scope (v0.1)

Common projection rules

Apply these steps to every mapped resource unless a resource-specific rule overrides them.

1. Profile tag: set meta.profile to the mapped QI-Core StructureDefinition URL.
2. Reference rewrite: recursively project referenced resources in the evaluation bundle and rewrite Reference values to the projected resource ids. Do not rewrite to QI-Core profile URLs in the reference string itself; keep Patient/{id}, Encounter/{id}, etc.
3. Storage-only data: retain India/NDHM-specific elements in storage. At evaluation time, pass through elements QI-Core allows; omit or transform elements the evaluator cannot consume only when required for validation or measure logic.
4. Actor anchors: Patient, Encounter, Practitioner, PractitionerRole, Organization, Location, RelatedPerson, and Coverage stubs exist primarily as reference targets. Project them before clinical or financial resources that point to them.
5. Bundle order: project dependencies first (Patient → Location → Encounter → Condition → Coverage → Claim → ClaimResponse, etc.) so reference rewriting resolves consistently.

Actor and reference anchor mapping

These actor profiles carry NDHM-aligned (or R4, for RelatedPerson) storage constraints plus QI-relevant must-support. Projection is a profile swap, recursive reference rewrite, and the element notes below.

Patient (atrius-patient → QICorePatient)

• Map atrius-patient → QICorePatient.
• Preserve QI Must Have demographics: name, identifier, and gender.
• Preserve QI Elements used by measure logic: birthDate, telecom, address, deceased[x], link, communication, generalPractitioner, and managingOrganization.
• Rewrite generalPractitioner and managingOrganization → projected QI-Core Organization, Practitioner, or PractitionerRole matching the reference type.
• Rewrite link.other → projected QI-Core Patient or RelatedPerson.
• NDHM extensions (birthPlace, nationality, birthTime, recordedSexOrGender, interpreterRequired, citizenship) remain in storage; pass through when QI-Core/US Core allows, otherwise omit only if the evaluator rejects them.
• US Core extensions (race, ethnicity, tribal affiliation, sex, gender identity): not fixed in Atrius storage; inject on the projected copy at evaluation time when a measure requires them.
• Rewrite inbound references from other Atrius resources to the projected Patient instance.

Encounter (atrius-encounter → QICoreEncounter)

• Map atrius-encounter → QICoreEncounter (single QI-Core profile; no lab/note-style subtypes).
• Rewrite subject → projected QI-Core Patient.
• Rewrite participant.individual → projected QI-Core Practitioner, PractitionerRole, or RelatedPerson.
• Rewrite serviceProvider → projected QI-Core Organization.
• Rewrite reasonReference and diagnosis.condition using Condition category rules when references target Conditions.
• Rewrite location.location, hospitalization.origin, and hospitalization.destination → projected QI-Core Location or Organization matching the reference type.
• Preserve status, class, type (CQL primary code path), period, reasonCode, serviceType, and hospitalization.dischargeDisposition for encounter class and timing logic.
• Required as the reference target for Condition, AdverseEvent, CareTeam, Claim item encounters, DiagnosticReport, DeviceRequest, Communication, and others.

Notes:

• NDHM Encounter parents R4 Encounter directly; no separate NDHM imaging/lab encounter split.
• NDHM already requires rich type, class, and period metadata for India exchange; Atrius adds QI subject 1..1 and actor reference wiring.

FamilyMemberHistory (atrius-familymemberhistory → QICoreFamilyMemberHistory)

• Map atrius-familymemberhistory → QICoreFamilyMemberHistory (single QI-Core profile; no subtypes).
• Rewrite patient → projected QI-Core Patient.
• Preserve status, relationship, date, age[x], deceased[x], and condition entries including condition.code (CQL primary code path), condition.onset[x], and QI condition extensions (familymemberhistory-abatement, familymemberhistory-severity) when present.

Notes:

• NDHM FamilyMemberHistory requires at least one condition entry with coded condition details; Atrius retains that for India storage.
• QI-Core uses patient (not Encounter.subject) as the anchor reference for family history.

Flag (atrius-flag → QICoreFlag)

• Map atrius-flag → QICoreFlag (single QI-Core profile; no subtypes).
• Rewrite subject → projected QI-Core target matching the subject type (Patient, Organization, Practitioner, Location, or pass through R4 Group when present).
• Preserve status, category, code (CQL primary code path), and period for alert and timing logic.

Notes:

• NDHM does not define Flag; storage parents R4 Flag directly.
• QI-Core allows subject on Patient, Organization, Practitioner, Location, or Group; Atrius storage wires Patient, actor profiles, Location, plus R4 Group.

Goal (atrius-goal → QICoreGoal)

• Map atrius-goal → QICoreGoal (single QI-Core profile; no subtypes).
• Rewrite subject → projected QI-Core Patient.
• Preserve lifecycleStatus, description, start[x], and target (including target.due[x]) for goal lifecycle and outcome logic.
• Preserve category when present for CQL primary code path (category is the QI-Core PCPath for Goal retrieves).

Notes:

• NDHM does not define Goal; storage parents R4 Goal directly.
• QI-Core restricts subject to Patient; Atrius wires subject to AtriusPatient.
• CarePlan goal references project through this profile when Goal resources are included in the evaluation bundle.

Practitioner (atrius-practitioner → QICorePractitioner)

• Map atrius-practitioner → QICorePractitioner.
• Preserve QI Must Have: name and identifier.
• Preserve QI Elements: identifier.use, identifier.system, identifier.value, and NDHM telecom and address when present.
• US Core identifier slices (NPI, EIN): India Health ID and local license identifiers stay in storage; supplement or map to US Core slices on the projected copy only when required for validation or measure logic.

PractitionerRole (atrius-practitionerrole → QICorePractitionerRole)

• Map atrius-practitionerrole → QICorePractitionerRole.
• Preserve QI Elements: identifier, active, period, practitioner, organization, code (CQL primary code path), specialty, telecom, and location.
• Rewrite practitioner, organization, and each location → projected QI-Core Practitioner, Organization, and Location.
• active and period: required 1..1 on QI-Core; Atrius storage enforces the same cardinality (not must-support).

Organization (atrius-organization → QICoreOrganization)

• Map atrius-organization → QICoreOrganization.
• Preserve QI Must Have: active and name.
• Preserve QI Elements: identifier, type (CQL primary code path), telecom, address, and partOf.
• Rewrite partOf → projected QI-Core Organization when the parent organization is in the bundle.
• Set active = true on the projected copy when absent but required by QI-Core validation.
• US Core identifier slices (EIN, CCN): retain India facility and payer identifiers in storage; supplement on the projected copy when required.

Location (atrius-location → QICoreLocation)

• Map atrius-location → QICoreLocation (single QI-Core profile; no subtypes).
• Rewrite managingOrganization → projected QI-Core Organization.
• Rewrite partOf → projected QI-Core Location when the parent location is in the bundle.
• Preserve name, type (CQL primary code path), telecom, address, and identifier for facility identification and measure logic.
• Set status = active on the projected copy when absent or required by QI-Core/US Core validation (QI-Core fixes active at evaluation).

Notes:

• NDHM does not define Location; storage parents R4 Location directly.
• Project Location before Encounter, Claim, Immunization, ImagingStudy, and Flag resources that reference it.

RelatedPerson (atrius-relatedperson → QICoreRelatedPerson)

• Map atrius-relatedperson → QICoreRelatedPerson.
• Preserve QI Must Have: active and patient.
• Preserve QI Elements: relationship (CQL primary code path), name, and telecom.
• Rewrite patient → projected QI-Core Patient.
• Set active = true on the projected copy when absent but required by QI-Core validation.

Coverage (atrius-coverage → QICoreCoverage)

See Coverage mapping below.

Coverage mapping

• Map atrius-coverage → QICoreCoverage.
• Rewrite beneficiary, policyHolder, subscriber, and payor to projected QI-Core actor targets.
• Preserve status, type (CQL primary code path), relationship, period, class, and identifiers for payer and eligibility logic.
• payor: QI-Core/US Core expect exactly one payor. Storage may list multiple NDHM payors; project a single primary payor at evaluation time when the measure requires QI-Core cardinality.
• identifier / subscriberId: US Core requires member id in identifier (Member ID type) or subscriberId. Retain India-specific identifiers in storage; ensure one of these is present on the projected copy when required for validation.
• type binding: QI-Core uses US PHDSC payer-type value set extensibly. India payer schemes (PM-JAY, private insurer, etc.) stay in storage; map or supplement codings only when needed for measure value set membership.

Notes:

• Project Coverage before Claim and ClaimResponse resources that reference insurance.coverage.
• NDHM does not constrain payor cardinality; Atrius storage follows NDHM while evaluation follows QI-Core.

Condition mapping

Condition resources use deterministic category selection to choose the QI-Core Condition subtype:

1. If Condition.category contains encounter-diagnosis, map to QICoreConditionEncounterDiagnosis.
2. Else if Condition.category contains problem-list-item, map to QICoreConditionProblemsHealthConcerns.
3. Else if Condition.encounter is present, map to QICoreConditionEncounterDiagnosis.
4. Else map to QICoreConditionProblemsHealthConcerns.

Notes:

• atrius-condition-encounter-diagnosis requires encounter and fixes category to encounter-diagnosis.
• atrius-condition-problems-health-concerns fixes category to problem-list-item.
• Rewrite subject → projected QI-Core Patient; rewrite encounter → projected QI-Core Encounter when present.
• Preserve condition-assertedDate (http://hl7.org/fhir/StructureDefinition/condition-assertedDate) for CQL timing logic.

AllergyIntolerance mapping

• Map atrius-allergyintolerance → QICoreAllergyIntolerance.
• Rewrite patient → projected QI-Core Patient.
• Preserve clinical status, verification status, code, onset/recurrence timing, and reaction.manifestation for value set and timing logic.

AdverseEvent mapping

• Map atrius-adverseevent → QICoreAdverseEvent.
• Rewrite subject → projected QI-Core Patient.
• Rewrite encounter → projected QI-Core Encounter when present.
• Rewrite resultingCondition using the Condition category rules above (typically QICoreConditionEncounterDiagnosis or QICoreConditionProblemsHealthConcerns).

BodyStructure mapping

• Map atrius-bodystructure → QICoreBodyStructure.
• Rewrite patient → projected QI-Core Patient.
• Preserve active, location, and locationQualifier for anatomy-related measure logic.

Device mapping

Implantable vs non-implantable is not a separate FHIR resource type. Both QI-Core Device and US Core Implantable Device are profiles on the same R4 Device resource. QI-Core lists both on Communication sender/recipient because US eCQM and USCDI logic often targets implantable UDI data, while general device measures use QICoreDevice for wheelchairs, pumps, monitors, and similar non-implantable equipment.

Atrius storage uses a single profile, atrius-device. The runtime mapper chooses the evaluation profile tag on the projected copy:

1. Default: set meta.profile to QICoreDevice.
2. Implantable path: when the stored device carries implantable UDI data (udiCarrier present, or other implantable indicators required by the measure bundle), set meta.profile to US Core Implantable Device instead of (or in addition to) QICoreDevice, preserving type, udiCarrier, manufacture/expiration/lot/serial/distinctIdentifier, and related fields.

Projection steps:

• Rewrite patient → projected QI-Core Patient.
• Preserve type (CQL primary code path), status, identifier, and implantable fields when present.
• When Communication or CommunicationRequest references a Device on sender or recipient, project the referenced Device first, then rewrite the Communication reference to the same Device/{id}.

Notes:

• NDHM does not define Device; storage parents R4 Device directly.
• Do not author a separate Atrius Implantable Device storage profile unless India-specific constraints diverge from R4 + UDI.

DeviceRequest mapping

DeviceRequest resources use profile and negation signals to choose the QI-Core DeviceRequest subtype (same pattern as Condition category selection):

1. If meta.profile includes atrius-devicerequest-prohibited, or modifierExtension http://hl7.org/fhir/5.0/StructureDefinition/extension-DeviceRequest.doNotPerform = true, map to QICoreDeviceProhibited.
2. Else if meta.profile includes atrius-devicerequest-requested, or the doNotPerform modifier is explicitly false, map to QICoreDeviceRequested.
3. Else map to QICoreDeviceRequest.

Projection steps (all branches):

• Rewrite subject → projected QI-Core Patient.
• Rewrite encounter → projected QI-Core Encounter when present.
• Rewrite codeReference → projected Device using the Device rules above.
• Preserve status, intent, authoredOn, and code codings or code.codeOptions extension (drq-3: coding xor codeOptions when not using codeReference).
• Rewrite requester, performer, reasonReference, and insurance to projected Atrius actor targets.
• Rewrite Claim.prescription when it references any Atrius DeviceRequest profile.

Notes:

• atrius-devicerequest is the general storage profile; doNotPerform is not fixed on storage.
• atrius-devicerequest-requested fixes doNotPerform = false when the modifier is present (positive request / existence CQL).
• atrius-devicerequest-prohibited fixes doNotPerform = true, requires authoredOn and code[x], and requires reasonCode for negation reason logic. QI-Core STU6 named this pattern Device Not Requested; STU7 renamed the evaluation target to DeviceProhibited — the mapper always projects to QICoreDeviceProhibited.
• NDHM does not define DeviceRequest; storage parents R4 DeviceRequest directly.

DeviceUseStatement mapping

• Map atrius-deviceusestatement → QICoreDeviceUseStatement.
• Rewrite subject → projected QI-Core Patient.
• Rewrite device → projected Device using the Device rules above (apply QICoreDevice vs US Core Implantable Device profile selection on the referenced Device resource before rewriting this reference).
• Preserve status, timing[x], recordedOn, and bodySite for use and timing logic.
• Rewrite source and reasonReference to projected Atrius actor targets when present.

Notes:

• NDHM does not define DeviceUseStatement; storage parents R4 DeviceUseStatement directly.
• CQL primary code path is device.type; project the referenced Device before evaluating value set membership on the use statement.
• QI-Core defines no negation subtype for DeviceUseStatement (negation of device orders uses DeviceRequest / DeviceProhibited).

Medication mapping

• Map atrius-medication → QICoreMedication (single QI-Core profile; no subtypes).
• Rewrite manufacturer → projected QI-Core Organization when present.
• Preserve code (CQL primary code path), form, identifier, and batch for medication identification logic.
• Project Medication before MedicationRequest, MedicationAdministration, MedicationDispense, and other resources that reference medicationReference. NDHM MedicationRequest and MedicationStatement fix medication[x] to CodeableConcept only; Administration and Dispense allow medicationReference on storage.

Notes:

• NDHM Medication requires coded product details and supports batch/lot metadata for India pharmacy exchange.
• QI-Core Medication has no negation or code-specific subtypes.

MedicationRequest mapping

MedicationRequest resources use profile and doNotPerform to choose the QI-Core MedicationRequest subtype (same pattern as DeviceRequest):

1. If meta.profile includes atrius-medicationrequest-prohibited, or MedicationRequest.doNotPerform = true, map to QICoreMedicationProhibited.
2. Else if meta.profile includes atrius-medicationrequest-requested, or doNotPerform is explicitly false, map to QICoreMedicationRequested.
3. Else map to QICoreMedicationRequest.

Projection steps (all branches):

• Rewrite subject → projected QI-Core Patient.
• Rewrite encounter → projected QI-Core Encounter when present.
• Preserve status, intent, authoredOn, medicationCodeableConcept codings or medication.codeOptions extension, and NDHM dosageInstruction / substitution metadata on the storage copy.
• Rewrite requester, performer, reasonReference, basedOn, insurance, and priorPrescription to projected Atrius targets using the corresponding profile rules.
• Rewrite Claim.prescription when it references any Atrius MedicationRequest profile.

Notes:

• atrius-medicationrequest is the general storage profile; doNotPerform is not fixed on storage.
• atrius-medicationrequest-requested fixes doNotPerform = false for positive request / existence CQL.
• atrius-medicationrequest-prohibited fixes doNotPerform = true, requires authoredOn, medication[x], and reasonCode for negation reason logic.
• NDHM requires authoredOn, requester, dosageInstruction, and substitution.allowed[x] for India prescribing exchange; retain on storage even when QI-Core treats some elements as optional.
• NDHM fixes medication[x] to CodeableConcept only (no medicationReference on storage); use coded products or medication.codeOptions for value-set-driven prescribing.
• Project MedicationRequest before Claim resources that reference prescription.

MedicationStatement mapping

• Map atrius-medicationstatement → QICoreMedicationStatement (single QI-Core profile; no subtypes).
• Rewrite subject → projected QI-Core Patient.
• Rewrite context → projected QI-Core Encounter when present.
• Rewrite informationSource, basedOn, reasonReference, and partOf using the corresponding Atrius profile rules.
• Preserve status, medicationCodeableConcept (CQL primary code path), effective[x], dateAsserted, reasonCode, and dosage for medication use and timing logic.

Notes:

• NDHM MedicationStatement parents R4 with India-specific dosage and reason metadata; QI-Core restricts subject to Patient — Atrius storage wires subject to AtriusPatient.
• NDHM fixes medication[x] to CodeableConcept only on storage (same as MedicationRequest).
• QI-Core defines no negation subtype for MedicationStatement (negation of medication orders uses MedicationRequest / MedicationProhibited).
• Project MedicationRequest before MedicationStatement resources that reference basedOn.
• Rewrite partOf → projected MedicationAdministration or MedicationDispense when references target those resources.

MedicationAdministration mapping

MedicationAdministration resources use profile and status to choose the QI-Core MedicationAdministration subtype (same pattern as Immunization and Communication):

1. If meta.profile includes atrius-medicationadministration-not-done, or MedicationAdministration.status = not-done, map to QICoreMedicationAdministrationNotDone.
2. Else if status is in-progress, on-hold, completed, or stopped, map to QICoreMedicationAdministrationDone.
3. Else map to QICoreMedicationAdministration.

Projection steps (all branches):

• Rewrite subject → projected QI-Core Patient.
• Rewrite context → projected QI-Core Encounter when present.
• Rewrite medicationReference → projected QI-Core Medication when present (project Medication first).
• Rewrite request → projected QI-Core MedicationRequest using MedicationRequest subtype rules.
• Rewrite performer.actor, reasonReference, partOf, and device using the corresponding Atrius profile rules.
• Preserve status, statusReason, medication[x] (CQL primary code path), effective[x], and dosage for administration timing and dose logic.

Notes:

• atrius-medicationadministration is the general storage profile; positive administration statuses are not fixed on storage.
• atrius-medicationadministration-not-done fixes status = not-done and requires statusReason for negation reason logic.
• NDHM does not define MedicationAdministration; storage parents R4 MedicationAdministration directly.
• Project Medication and MedicationRequest before MedicationAdministration resources that reference them.

MedicationDispense mapping

MedicationDispense resources use profile and status to choose the QI-Core MedicationDispense subtype:

1. If meta.profile includes atrius-medicationdispense-declined, or MedicationDispense.status = declined, map to QICoreMedicationDispenseDeclined.
2. Else if status is preparation, in-progress, on-hold, completed, or stopped, map to QICoreMedicationDispenseDone.
3. Else map to QICoreMedicationDispense.

Projection steps (all branches):

• Rewrite subject → projected QI-Core Patient.
• Rewrite context → projected QI-Core Encounter when present.
• Rewrite medicationReference → projected QI-Core Medication when present.
• Rewrite each authorizingPrescription reference using MedicationRequest subtype rules.
• Rewrite performer.actor, location, and destination to projected Atrius actor targets.
• Preserve status, statusReason, medication[x] (CQL primary code path), type, quantity, daysSupply, whenPrepared, whenHandedOver, and dosageInstruction for dispense timing and supply logic.
• Inject extension-MedicationDispense.recorded on the projected copy when required by QI-Core MedicationDispenseDeclined validation.

Notes:

• atrius-medicationdispense is the general storage profile; positive dispense statuses are not fixed on storage.
• atrius-medicationdispense-declined fixes status = declined and requires statusReason for negation reason logic.
• NDHM does not define MedicationDispense; storage parents R4 MedicationDispense directly.
• Project Medication and MedicationRequest before MedicationDispense resources that reference them.

NutritionOrder mapping

• Map atrius-nutritionorder → QICoreNutritionOrder (single QI-Core profile; no subtypes).
• Rewrite patient → projected QI-Core Patient.
• Rewrite encounter → projected QI-Core Encounter when present.
• Rewrite orderer → projected QI-Core Practitioner or PractitionerRole.
• Rewrite allergyIntolerance → projected QI-Core AllergyIntolerance when present.
• Preserve status, intent, dateTime, and diet/supplement/enteral formula elements (oralDiet.type, supplement.type, enteralFormula.baseFormulaType) for nutrition order logic.

Notes:

• NDHM does not define NutritionOrder; storage parents R4 NutritionOrder directly.
• QI-Core uses patient (not subject) as the anchor reference.

Procedure mapping

Procedure resources use profile and status to choose the QI-Core Procedure subtype:

1. If meta.profile includes atrius-procedure-not-done, or Procedure.status = not-done, map to QICoreProcedureNotDone.
2. Else map to QICoreProcedure.

Projection steps (all branches):

• Rewrite subject and encounter → projected QI-Core Patient and Encounter.
• Rewrite basedOn, partOf, performer, and reasonReference using the corresponding Atrius profile rules.
• Preserve status, statusReason, category, code (CQL primary code path), performed[x], reasonCode, bodySite, and NDHM outcome/usedCode metadata on the storage copy.

Notes:

• atrius-procedure is the general storage profile; positive procedure statuses are not fixed on storage.
• atrius-procedure-not-done fixes status = not-done, requires statusReason and code, and supports code.codeOptions for value-set-driven negation.
• NDHM Procedure parents R4 with India-specific performer and body-site metadata.
• Project Procedure before Claim, QuestionnaireResponse, MedicationAdministration, and MedicationStatement resources that reference it.

ServiceRequest mapping

ServiceRequest resources use profile and doNotPerform to choose the QI-Core ServiceRequest subtype (same pattern as MedicationRequest and DeviceRequest):

1. If meta.profile includes atrius-servicerequest-not-requested, or ServiceRequest.doNotPerform = true, map to QICoreServiceNotRequested.
2. Else map to QICoreServiceRequest.

Projection steps (all branches):

• Rewrite subject and encounter → projected QI-Core Patient and Encounter.
• Rewrite requester, performer, basedOn, reasonReference, and specimen using the corresponding Atrius profile rules.
• Preserve status, intent, code codings or code.codeOptions / code.notDoneValueSet extension, and NDHM text on the storage copy.
• Rewrite Claim.referral when it references any Atrius ServiceRequest profile.

Notes:

• atrius-servicerequest-not-requested fixes doNotPerform = true, requires authoredOn, code, and reasonCode for negation reason logic. Inject the QI reasonRefused extension (qicore-doNotPerformReason) and map code.codeOptions to code.notDoneValueSet on the projected copy when required by measure validation.
• NDHM ServiceRequest requires requester 1..1 for India exchange.
• Project Specimen and ServiceRequest before Claim resources that reference referral or specimen.

QuestionnaireResponse mapping

• Map atrius-questionnaireresponse → QICoreQuestionnaireResponse (single QI-Core profile; no subtypes).
• Rewrite subject and encounter → projected QI-Core Patient and Encounter.
• Rewrite author, basedOn, and partOf using the corresponding Atrius profile rules.
• Preserve status, questionnaire (CQL primary code path), authored, and item answer content for survey logic.

Notes:

• NDHM does not define QuestionnaireResponse; storage parents R4 QuestionnaireResponse directly.
• QI-Core restricts subject to Patient; Atrius storage wires subject to AtriusPatient.

Specimen mapping

• Map atrius-specimen → US Core Specimen (no separate QI-Core Specimen profile; US Core is the evaluation target).
• Rewrite subject → projected QI-Core Patient when present.
• Preserve type and receivedTime for specimen identification and timing logic.

Notes:

• NDHM Specimen is minimal (type and receivedTime must-support); Atrius adds Patient subject wiring for US Core alignment.
• Project Specimen before Observation and ServiceRequest resources that reference it.

Substance mapping

• Map atrius-substance → QICoreSubstance (single QI-Core profile; no subtypes).
• Rewrite nested ingredient.substanceReference → projected QI-Core Substance when present (project parent substances before child ingredient references).
• Preserve code (CQL primary code path), status, instance, and ingredient composition metadata.

Notes:

• NDHM does not define Substance; storage parents R4 Substance directly.

Task mapping

Task resources use profile and status to choose the QI-Core Task subtype:

1. If meta.profile includes atrius-task-rejected, or Task.status = rejected, map to QICoreTaskRejected.
2. Else if status indicates completion or in-progress fulfillment, map to QICoreTaskDone when measure logic requires the Done profile.
3. Else map to QICoreTask.

Projection steps (all branches):

• Rewrite for and encounter → projected QI-Core Patient and Encounter.
• Rewrite requester, owner, and partOf using the corresponding Atrius profile rules.
• Preserve status, statusReason, intent, priority, code (CQL primary code path), executionPeriod, and NDHM reasonCode on the storage copy.

Notes:

• atrius-task-rejected fixes status = rejected, requires statusReason and code, and supports code.codeOptions for value-set-driven negation.
• NDHM Task is minimal (only reasonCode must-support); Atrius adds QI QI-Element gaps for measure evaluation.
• QI-Core TaskDone is selected at evaluation from positive fulfillment statuses; no separate Done storage profile is required when multiple positive statuses are valid.

ImagingStudy mapping

• Map atrius-imagingstudy → QICoreImagingStudy (single QI-Core profile; no subtypes).
• Rewrite subject and encounter → projected QI-Core Patient and Encounter.
• Rewrite basedOn → projected QI-Core CarePlan, ServiceRequest, or ServiceNotRequested using the ServiceRequest subtype rules.
• Rewrite referrer, interpreter, and each series.performer.actor to the projected QI-Core target matching the reference type (Patient, Practitioner, PractitionerRole, Organization, CareTeam, Device, RelatedPerson).
• Rewrite reasonReference using Condition, DiagnosticReport, and Observation subtype rules when references target those resources.
• Rewrite location → projected QI-Core Location.
• Preserve status, modality, started, procedureReference, procedureCode (CQL primary code path), reasonCode, numberOfSeries, numberOfInstances, and NDHM series metadata (uid, modality, instance) for DICOM and timing logic.

Notes:

• NDHM defines ImagingStudy for India radiology exchange; Atrius adds QI QI-Element gaps (encounter, started, basedOn, procedureReference) and actor reference wiring.
• QI-Core restricts subject to Patient; NDHM also allows Device and Group — Atrius storage wires subject to AtriusPatient.
• Project ImagingStudy before DiagnosticReport note resources that reference imagingStudy.

DiagnosticReport mapping

NDHM storage splits lab and imaging profiles; QI-Core evaluation splits lab and note. There is no QI-Core imaging subtype — radiology and other NDHM imaging reports project to QICoreDiagnosticReportNote.

1. If meta.profile includes atrius-diagnosticreport-lab, or DiagnosticReport.category contains http://terminology.hl7.org/CodeSystem/v2-0074 / LAB, map to QICoreDiagnosticReportLab.
2. Else if meta.profile includes atrius-diagnosticreport-note, or the resource was stored as NDHM DiagnosticReportImaging, map to QICoreDiagnosticReportNote.
3. Else if category is not laboratory, map to QICoreDiagnosticReportNote.
4. Else map to QICoreDiagnosticReportLab.

Projection steps (both branches):

• Rewrite subject and encounter → projected QI-Core Patient and Encounter.
• Rewrite performer and resultsInterpreter → projected Atrius actor targets.
• Rewrite basedOn → projected QI-Core targets using CarePlan, ServiceRequest, and other Atrius request profile rules.
• Rewrite each result reference using Observation subtype rules.
• Rewrite each imagingStudy reference → projected QI-Core ImagingStudy when ImagingStudy resources are included in the bundle.
• Preserve status, code, effective[x], issued, conclusion, and NDHM specimen (lab) or media / imagingStudy (note/imaging) on the storage copy.

Notes:

• atrius-diagnosticreport-lab parents NDHM DiagnosticReportLab. NDHM fixes category.coding.system to SNOMED (conflicts with QI LAB slice) — inject http://terminology.hl7.org/CodeSystem/v2-0074 / LAB on the projected copy when absent.
• atrius-diagnosticreport-note parents NDHM DiagnosticReportImaging for India radiology/media exchange; evaluation uses QICoreDiagnosticReportNote. Inject a US Core diagnostic report category coding on the projected copy when absent and required by measure validation.
• NDHM DiagnosticReportRecord is a Composition document wrapper, not a DiagnosticReport resource — out of scope for these profiles.
• Lab reports require result 1..* on storage (NDHM); note/imaging may carry media 1..* instead.

Observation mapping

NDHM storage uses seven observation profiles (lab/panel plus six clinical subtypes). QI-Core evaluation uses six observation profiles (Simple, Cancelled, NonPatient, Lab, Clinical Result, Screening Assessment). US Core adds many code-specific vital sign and social-history profiles that QI-Core inherits directly. Atrius does not author separate storage profiles for each US Core vital sign — the runtime mapper selects the US Core or QI target at evaluation time from code, category, status, and subject.

QI-Core evaluation target selection

Apply in order (first match wins unless noted):

1. status = cancelled (negation intent) → QICoreObservationCancelled. Preserve or require notDoneReason and code / notDoneValueSet on the projected copy when measure logic requires negation semantics.
2. subject is Device or Location (not Patient) on an R4 Observation outside NDHM patient-only storage → QICoreNonPatientObservation. Apply Device profile selection on device subjects before rewriting references. Atrius NDHM observation storage profiles require subject = Patient.
3. meta.profile is atrius-observation or Observation.category contains laboratory → QICoreObservationLab. Inject the US Core laboratory category slice (http://terminology.hl7.org/CodeSystem/observation-category / laboratory) when absent and required by validation.
4. Observation.category contains imaging, procedure, or activity (clinical result) → QICoreObservationClinicalResult. Inject the US Core clinical-result category slice when absent.
5. meta.profile is atrius-observation-lifestyle, atrius-observation-general-assessment, or atrius-observation-women-health, or category contains survey or social-history → QICoreObservationScreeningAssessment. Inject the US Core survey category slice when absent.
6. US Core code-specific profile — when Observation.code matches a US Core vital sign, blood pressure, BMI, smoking status, pregnancy, or related pattern, project to that US Core profile URL (for example us-core-heart-rate, us-core-blood-pressure, us-core-bmi) instead of QICoreSimpleObservation. This mirrors the Device → Implantable Device selection pattern.
7. Default → QICoreSimpleObservation (includes NDHM vital signs, body measurement, physical activity, and uncategorized clinical observations).

Projection steps (all branches)

• Rewrite subject and encounter → projected QI-Core Patient, Device, Location, or Encounter matching the reference type.
• Rewrite performer, basedOn, partOf, hasMember, and derivedFrom using the corresponding Atrius profile rules.
• Preserve status, category, code (CQL primary code path), effective[x], value[x], dataAbsentReason, interpretation, issued, and referenceRange for result and timing logic.

NDHM storage profile hints

Notes:

• NDHM category codings may differ from US Core/QI category slices — inject evaluation categories on the projected copy when required (same pattern as DiagnosticReport lab/note).
• Project Observation resources before DiagnosticReport, ImmunizationRecommendation, ImagingStudy, and Immunization resources that reference them.
• CQL retrieves for negation use ObservationCancelled; positive retrieves use the specific QI or US Core profile type, not a generic Observation type.

Immunization mapping

Immunization resources use status and profile selection to choose the QI-Core Immunization subtype:

1. If meta.profile includes atrius-immunization-not-done, or Immunization.status = not-done, map to QICoreImmunizationNotDone.
2. Else if meta.profile includes atrius-immunization-done, or Immunization.status = completed, map to QICoreImmunizationDone.
3. Else map to QICoreImmunization (base profile for entered-in-error or other allowed statuses).

Projection steps (all branches):

• Rewrite patient and encounter → projected QI-Core Patient and Encounter.
• Rewrite manufacturer, performer.actor, and protocolApplied.authority → projected Atrius actor targets.
• Rewrite reasonReference using Condition and DiagnosticReport subtype rules when references target those resources; rewrite Observation references using Observation subtype rules.
• Rewrite location → projected QI-Core Location.
• Preserve status, statusReason, vaccineCode (CQL primary code path), vaccineCode.codeOptions, occurrence[x], recorded, and NDHM administration metadata (site, route, lotNumber, protocolApplied, etc.).

Notes:

• atrius-immunization is the NDHM-aligned base profile for general storage; status is not fixed on storage.
• atrius-immunization-done fixes status = completed for positive immunization statements.
• atrius-immunization-not-done fixes status = not-done and requires statusReason 1..1 for negation reason logic.
• NDHM requires coded vaccineCode.coding for India exchange; QI-Core allows vaccineCode.codeOptions alone for negation retrieves (qim-1) — the mapper may supply codeOptions on the projected copy when measure logic requires value-set-level negation without a specific CVX code.
• CQL retrieves use ImmunizationDone and ImmunizationNotDone profile types, not the base Immunization profile, for positive and negation statements.

ImmunizationEvaluation mapping

• Map atrius-immunizationevaluation → QICoreImmunizationEvaluation (single QI-Core profile; no subtypes).
• Rewrite patient → projected QI-Core Patient.
• Rewrite authority → projected QI-Core Organization.
• Rewrite immunizationEvent using Immunization subtype rules when the target is an Atrius Immunization resource.
• Preserve identifier, status, date, targetDisease (CQL primary code path), doseStatus, and doseStatusReason for evaluation and validity logic.

Notes:

• NDHM does not define ImmunizationEvaluation; storage parents R4 ImmunizationEvaluation directly.
• NDHM ImmunizationRecommendation.recommendation.supportingImmunization allows R4 ImmunizationEvaluation alongside NDHM Immunization; Atrius wires both to Atrius profiles.
• Project referenced Immunization resources before ImmunizationEvaluation when both are in the evaluation bundle.

ImmunizationRecommendation mapping

• Map atrius-immunizationrecommendation → QICoreImmunizationRecommendation (single QI-Core profile; no subtypes).
• Rewrite patient → projected QI-Core Patient.
• Rewrite authority → projected QI-Core Organization.
• Rewrite each recommendation.supportingImmunization reference using Immunization subtype rules or straight ImmunizationEvaluation swap when the target is an Atrius ImmunizationEvaluation resource.
• Rewrite each recommendation.supportingPatientInformation reference to projected QI-Core AllergyIntolerance or Observation using the Observation subtype rules.
• Preserve date, recommendation entries, recommendation.vaccineCode (CQL primary code path), recommendation.forecastStatus, recommendation.doseNumber[x], and NDHM forecast metadata (targetDisease, contraindicatedVaccineCode, forecastReason, dateCriterion) on the storage copy.

Notes:

• NDHM defines ImmunizationRecommendation for India immunization forecasting exchange; Atrius adds QI patient 1..1, recommendation 1..*, and recommendation.doseNumber[x] gaps plus actor reference wiring.
• imr-1 requires recommendation.vaccineCode or recommendation.targetDisease; NDHM already requires coded details on both when present.
• Project referenced Immunization and ImmunizationEvaluation resources before ImmunizationRecommendation when they are in the evaluation bundle.

CarePlan mapping

CarePlan resources are projected using profile and category selection:

1. If meta.profile includes atrius-careplan-assess-plan, or CarePlan.category contains assess-plan, map to QICoreCarePlan.
2. Else if stored as base atrius-careplan, map to QICoreCarePlan and inject an assess-plan category entry when absent.
3. Preserve additional clinical category codings (for example NDHM SNOMED plan type) when present.

Notes:

• atrius-careplan remains the general NDHM-aligned storage profile.
• atrius-careplan-assess-plan parents R4 directly because NDHM CarePlan fixes category.coding.system to SNOMED, which conflicts with US Core assess-plan.
• Rewrite subject → projected QI-Core Patient.
• Rewrite each goal reference → projected QI-Core Goal when Goal resources are included in the bundle.

CareTeam mapping

• Map atrius-careteam → QICoreCareTeam.
• Rewrite subject → projected QI-Core Patient.
• Rewrite encounter → projected QI-Core Encounter when present.
• Rewrite each participant.member to the projected QI-Core target matching the member type (Patient, Practitioner, PractitionerRole, Organization, CareTeam, RelatedPerson).
• Ensure participant.role is present (required 1..1 on both Atrius and QI-Core profiles).

Communication mapping

Communication resources use status and profile selection to choose the QI-Core Communication subtype:

1. If meta.profile includes atrius-communication-not-done, or Communication.status = not-done, map to QICoreCommunicationNotDone.
2. Else if Communication.status is one of preparation, in-progress, on-hold, stopped, or completed, map to QICoreCommunicationDone.
3. Else map to QICoreCommunication.

Notes:

• atrius-communication is the NDHM-aligned base profile for general storage; status is not fixed on storage.
• atrius-communication-not-done fixes status = not-done, requires statusReason 1..1, and requires event-recorded (http://hl7.org/fhir/StructureDefinition/event-recorded).
• Rewrite subject, encounter, sender, and recipient to projected QI-Core actor targets. When sender or recipient is a Device, apply Device profile selection (QICoreDevice vs US Core Implantable Device) before rewriting the Communication reference.
• Preserve topic codings or topic.codeOptions extension (com-1: one or the other) for measure topic matching.
• Preserve sent, received, and payload.content[x] for timing and content logic.
• For NotDone projection, ensure statusReason uses QI-Core negation reason semantics when required by the measure.

CommunicationRequest mapping

• Map atrius-communicationrequest → QICoreCommunicationRequest.
• Rewrite subject, encounter, requester, sender, and recipient to projected QI-Core actor targets. When sender or recipient is a Device, apply Device profile selection before rewriting the reference.
• Preserve status, category (primary code path for CQL retrieve), and doNotPerform for request and negation logic.
• Rewrite replaces to projected QI-Core CommunicationRequest when present.
• Rewrite reasonReference using Condition category rules when the reference targets a Condition.

Notes:

• CommunicationRequest is distinct from Communication: requests are orders/intents; Communication records fulfilled messages. Project each resource type separately.
• ClaimResponse communicationRequest references should point to projected QI-Core CommunicationRequest after the request resource is mapped.

Claim mapping

Claims are the most sensitive financial resource because NDHM storage and QI-Core evaluation expectations diverge.

Target

• Map atrius-claim → QICoreClaim.

Evaluation-time transforms

1. status: QI-Core fixes Claim.status to active. Storage may contain other statuses (cancelled, entered-in-error, etc.). Set status = active on the projected copy when the measure logic expects an active claim; otherwise exclude the claim from the evaluation bundle.
2. patient, provider, enterer, insurer, payee.party, careTeam.provider: rewrite to projected QI-Core actor targets.
3. insurance.coverage: rewrite to projected QI-Core Coverage (project Coverage before Claim).
4. insurance.claimResponse: rewrite to projected QI-Core ClaimResponse when present (project ClaimResponse after Claim).
5. item.encounter: rewrite each entry to projected QI-Core Encounter.
6. diagnosis.diagnosisReference: project the referenced Condition using the Condition category rules. QI-Core expects QICoreConditionEncounterDiagnosis for reference-typed diagnoses; prefer the encounter-diagnosis branch when ambiguous.
7. diagnosis.diagnosisCodeableConcept: pass through codings used by value set membership.
8. procedure.procedureReference: rewrite using Procedure subtype rules (QICoreProcedureNotDone or QICoreProcedure).
9. prescription: rewrite DeviceRequest references using the DeviceRequest subtype rules above (QICoreDeviceRequested, QICoreDeviceProhibited, or QICoreDeviceRequest). Rewrite MedicationRequest references using the MedicationRequest subtype rules (QICoreMedicationRequested, QICoreMedicationProhibited, or QICoreMedicationRequest).
10. referral: rewrite using ServiceRequest subtype rules (QICoreServiceNotRequested or QICoreServiceRequest).
11. facility: rewrite to projected QI-Core Location.

Storage-only NDHM elements

Retain in HFS; do not require for QI-Core validation unless measure logic references them:

• supportingInfo and NDHM supporting-info extensions
• NDHM-required item / item.detail category and product codings
• related.claim and insurance.claimResponse chains (project linked Claim/ClaimResponse pairs together)

ClaimResponse mapping

ClaimResponse adjudication resources follow the same storage-vs-evaluation split as Claim.

Target

• Map atrius-claimresponse → QICoreClaimResponse.

Evaluation-time transforms

1. status: QI-Core fixes ClaimResponse.status to active. Set status = active on the projected copy when required by measure logic; otherwise exclude non-active responses from the evaluation bundle.
2. use: QI-Core fixes ClaimResponse.use to preauthorization. Storage may record claim, preauthorization, or predetermination per NDHM exchange. Set use = preauthorization on the projected copy when the evaluator expects QI-Core ClaimResponse semantics.
3. patient, insurer, requestor: rewrite to projected QI-Core actor targets.
4. request: rewrite to projected QI-Core Claim (project Claim before ClaimResponse).
5. insurance.coverage: rewrite to projected QI-Core Coverage.
6. item.adjudication.category: QI-Core requires pattern http://terminology.hl7.org/CodeSystem/adjudication / submitted. India adjudication records may use other category codes in storage; inject or normalize to submitted on the projected copy when required for QI-Core validation.
7. item.adjudication.amount: preserve monetary amounts used by measure logic.
8. item.detail.detailSequence: preserve sequence linkage to submitted claim line details.
9. communicationRequest: rewrite to projected QI-Core CommunicationRequest.

Storage-only NDHM elements

Retain in HFS unless measure logic references them:

• addItem product/service codings and nested detail structures
• outcome, disposition, total, and error as returned by NDHM payers

Fields commonly required for QI-Core CQL evaluation

Runtime projection must preserve or derive fields used by quality logic:

• Clinical verification context: clinicalStatus, verificationStatus (Condition, AllergyIntolerance).
• Code semantics: code and codings needed for VSAC/value set membership.
• Subject / patient linkage: references required by population criteria.
• Assertion timing: condition-assertedDate when available.
• Temporal logic inputs: onset[x], abatement[x], recordedDate, billablePeriod, period, and analogous timing elements per resource.
• Financial timing: Claim.created, Claim.billablePeriod, ClaimResponse.created, diagnosis/procedure sequences linked to items, adjudication amounts on ClaimResponse items.

When adding new Atrius profiles

When a new clinical, financial, or actor profile is added to the IG, update all of the following so mapping stays traceable:

Pending profiles and downstream updates

All profiles listed in the v0.1 inventory table above are implemented. When adding new Atrius profiles beyond v0.1, follow the checklist in the previous section and search the IG for only Reference( constraints that should target the new profile.

Reference-constraint rule of thumb: whenever a new Atrius profile replaces an NDHM or R4 reference target, search the IG for only Reference( rules pointing at the old target and narrow them to the new Atrius profile, then mirror the same rule in the mapper’s reference rewrite table.

Example projection (Condition)

The following example illustrates how an Atrius encounter diagnosis is projected to a QI-Core-compatible shape for evaluation.

Input (Atrius storage profile)

{
  "resourceType": "Condition",
  "meta": {
    "profile": [
      "https://atrius.in/fhir/r4/atrius-core/StructureDefinition/atrius-condition-encounter-diagnosis"
    ]
  },
  "clinicalStatus": {
    "coding": [
      {
        "system": "http://terminology.hl7.org/CodeSystem/condition-clinical",
        "code": "active"
      }
    ]
  },
  "verificationStatus": {
    "coding": [
      {
        "system": "http://terminology.hl7.org/CodeSystem/condition-ver-status",
        "code": "confirmed"
      }
    ]
  },
  "category": [
    {
      "coding": [
        {
          "system": "http://terminology.hl7.org/CodeSystem/condition-category",
          "code": "encounter-diagnosis"
        }
      ]
    }
  ],
  "code": {
    "coding": [
      {
        "system": "http://hl7.org/fhir/sid/icd-10",
        "code": "I10"
      }
    ]
  },
  "subject": {
    "reference": "Patient/p1"
  },
  "encounter": {
    "reference": "Encounter/e1"
  },
  "extension": [
    {
      "url": "http://hl7.org/fhir/StructureDefinition/condition-assertedDate",
      "valueDateTime": "2026-05-24"
    }
  ],
  "onsetDateTime": "2026-05-20",
  "recordedDate": "2026-05-24"
}

Output (QI-Core evaluation shape)

{
  "resourceType": "Condition",
  "meta": {
    "profile": [
      "http://hl7.org/fhir/us/qicore/StructureDefinition/qicore-condition-encounter-diagnosis"
    ]
  },
  "clinicalStatus": {
    "coding": [
      {
        "system": "http://terminology.hl7.org/CodeSystem/condition-clinical",
        "code": "active"
      }
    ]
  },
  "verificationStatus": {
    "coding": [
      {
        "system": "http://terminology.hl7.org/CodeSystem/condition-ver-status",
        "code": "confirmed"
      }
    ]
  },
  "category": [
    {
      "coding": [
        {
          "system": "http://terminology.hl7.org/CodeSystem/condition-category",
          "code": "encounter-diagnosis"
        }
      ]
    }
  ],
  "code": {
    "coding": [
      {
        "system": "http://hl7.org/fhir/sid/icd-10",
        "code": "I10"
      }
    ]
  },
  "subject": {
    "reference": "Patient/p1"
  },
  "encounter": {
    "reference": "Encounter/e1"
  },
  "extension": [
    {
      "url": "http://hl7.org/fhir/StructureDefinition/condition-assertedDate",
      "valueDateTime": "2026-05-24"
    }
  ],
  "onsetDateTime": "2026-05-20",
  "recordedDate": "2026-05-24"
}

The following example illustrates the PHC branch when no encounter is present and category is problem-list-item.

Input (Atrius storage profile, PHC)

{
  "resourceType": "Condition",
  "meta": {
    "profile": [
      "https://atrius.in/fhir/r4/atrius-core/StructureDefinition/atrius-condition-problems-health-concerns"
    ]
  },
  "clinicalStatus": {
    "coding": [
      {
        "system": "http://terminology.hl7.org/CodeSystem/condition-clinical",
        "code": "active"
      }
    ]
  },
  "verificationStatus": {
    "coding": [
      {
        "system": "http://terminology.hl7.org/CodeSystem/condition-ver-status",
        "code": "confirmed"
      }
    ]
  },
  "category": [
    {
      "coding": [
        {
          "system": "http://terminology.hl7.org/CodeSystem/condition-category",
          "code": "problem-list-item"
        }
      ]
    }
  ],
  "code": {
    "coding": [
      {
        "system": "http://snomed.info/sct",
        "code": "38341003"
      }
    ]
  },
  "subject": {
    "reference": "Patient/p2"
  },
  "extension": [
    {
      "url": "http://hl7.org/fhir/StructureDefinition/condition-assertedDate",
      "valueDateTime": "2026-05-18"
    }
  ],
  "onsetDateTime": "2026-05-15",
  "recordedDate": "2026-05-18"
}

Output (QI-Core evaluation shape, PHC)

{
  "resourceType": "Condition",
  "meta": {
    "profile": [
      "http://hl7.org/fhir/us/qicore/StructureDefinition/qicore-condition-problems-health-concerns"
    ]
  },
  "clinicalStatus": {
    "coding": [
      {
        "system": "http://terminology.hl7.org/CodeSystem/condition-clinical",
        "code": "active"
      }
    ]
  },
  "verificationStatus": {
    "coding": [
      {
        "system": "http://terminology.hl7.org/CodeSystem/condition-ver-status",
        "code": "confirmed"
      }
    ]
  },
  "category": [
    {
      "coding": [
        {
          "system": "http://terminology.hl7.org/CodeSystem/condition-category",
          "code": "problem-list-item"
        }
      ]
    }
  ],
  "code": {
    "coding": [
      {
        "system": "http://snomed.info/sct",
        "code": "38341003"
      }
    ]
  },
  "subject": {
    "reference": "Patient/p2"
  },
  "extension": [
    {
      "url": "http://hl7.org/fhir/StructureDefinition/condition-assertedDate",
      "valueDateTime": "2026-05-18"
    }
  ],
  "onsetDateTime": "2026-05-15",
  "recordedDate": "2026-05-18"
}

Contract statement

$evaluate executions in CDS/measure services SHALL use QI-Core ELM and QI-Core model semantics.

Atrius profiles define the authoring and storage contract on HFS. Runtime projection is the compatibility layer that aligns stored Atrius resources with the QI-Core shapes expected by the evaluator.