This page is part of the Quality Improvement Core Framework (v5.0.0: STU5 (v5.0.0)) based on FHIR R4. The current version which supercedes this version is 4.1.1. For a full list of available versions, see the Directory of published versions

Quality Data Model (QDM)v5.6 to QI-Core R5 Mapping

This page is part of the Quality Improvement Core Framework (v5.0.0: STU 5) based on FHIR R4. This is the current published version. For a full list of available versions, see the Directory of published versions.

Introduction

The CMS Quality Data Model (QDM) has been used to express electronic clinical quality measures (eCQMs) in HQMF since 2012. QDM is a conceptual data model that has evolved based on feedback, testing and use. The current version (Version 5.6 for eCQM implementation 2023 and 2024) and QDM’s complete history can be found on the eCQI Resource Center. Most of the QDM concepts map directly to US Core R5, FHIR R4 resources or extensions represented in QI-Core.

This version of QI Core updates mappings from QI-Core to QDM based on US Core R5 and FHIR R4 and QDM version 5.6. Reviewers can evaluate the comparisons, represented in the Mappings table for each QI-Core resource. Each mapping table shows the QI-Core concept in the right-hand column and the corresponding QDM datatype(s) and attributes in the left-hand column. Only QI-Core metadata concepts represented in QDM are included in the mapping tables. The effort mapped the intended meaning of each QDM datatype and attribute to a QI-Core resource metadata element. In some cases, multiple QDM datatypes map to a single QI-Core resource as indicated in the QI-Core mapping table.

In addition to the QI-Core to QDM comparisons presented with each QI-Core resource, this section of the implementation guide presents the mapping directly from QDM concepts. Thus, the IG provides a view of the mappings in both directions (QI-Core to QDM, and QDM to QI-Core). This section is divided into 55 sections, one for each QDM concept, or QDM datatype. Each QDM datatype includes a general description of the concept and a table mapping each of the QDM datatype-related attributes to QI-Core metadata elements. Refer to the eCQI Resource Center for the full QDM 5.6 documentation.

Change from QI-Core 4.1.1 to QI-Core 5.0.0

QI-Core builds upon US Core and new US Core STU5 profiles include a number of changes that impact expression of requests for information. These include new observation profiles, change to referencing conditions and diagnoses, and addition of a ServiceRequest profile. QI-Core addresses these changes as follows:

1.Condition

• a. QICore Condition Problems and Health Concerns Profile – this is basically a name change from the previously defined QICore Condition profile
• b. QICore Condition Encounter Diagnosis Profile – this new profile, based on US Core STU5 Condition Encounter Diagnosis Profile is based upon the core FHIR Condition Resource and meets the U.S. Core Data for Interoperability (USCDI) v2 ‘Encounter Diagnosis’ requirements. To promote interoperability and adoption through common implementation, this profile defines constraints and extensions on the Condition resource for the minimal set of data to record, search, and fetch information about an encounter diagnosis. It identifies which core elements, extensions, vocabularies and value sets SHALL be present in the resource when using this profile. It provides the floor for standards development for specific uses cases.

2.Observations

QI-Core 5.0.0 includes 22 profiles based on the FHIR Observation resource, some including specific QI-Core constraints added to the US Core profiles, others used as specified by US Core. QI-Core also continues to include a generic QICore Observation profile to address findings not included in the specific profiles. The following list should help determine which QI-Core observation profile to use with each QDM datatype. The subsequent mapping tables provide more detail about how to address these new profiles when converting measures from QDM to QI-Core.

• a) QICore Observation Clinical Test Result – generally used with QDM “Diagnostic Study, Performed”
• b) QICore Observation Imaging Result – generally used with QDM “Diagnostic Study, Performed”
• c) QICore Laboratory Result Observation – generally used with QDM “Laboratory Test, Performed”
• d) QICore Observation Survey – generally used with QDM “Assessment, Performed”
• e) US Core Observation Sexual Orientation Profile – generally used with QDM “Assessment, Performed”
• f) US Core Observation Social History Profile – generally used with QDM “Assessment, Performed”
• g) US Core Observation SDOH Assessment Profile – generally used with QDM “Assessment, Performed”
• h) US Core Smoking Status Observation Profile – generally used with QDM “Assessment, Performed”
• i) US Core Pediatric Head Occipital-frontal Circumference Percentile Profile – generally used with QDM “Physical Exam, Performed”
• j) US Core Blood Pressure Profile – generally used with QDM “Physical Exam, Performed”
• k) US Core BMI Profile – generally used with QDM “Physical Exam, Performed”
• l) US Core Body Height Profile – generally used with QDM “Physical Exam, Performed”
• m) US Core Body Temperature Profile – generally used with QDM “Physical Exam, Performed”
• n) US Core Body Weight Profile – generally used with QDM “Physical Exam, Performed”
• o) US Core Head Circumference Profile – generally used with QDM “Physical Exam, Performed”
• p) US Core Heart Rate Profile – generally used with QDM “Physical Exam, Performed”
• q) US Core Pediatric BMI for Age Observation Profile – generally used with QDM “Physical Exam, Performed”
• r) US Core Pediatric Weight for Height Observation Profile – generally used with QDM “Physical Exam, Performed”
• s) US Core Pulse Oximetry Profile – generally used with QDM “Physical Exam, Performed”
• t) US Core Respiratory Rate Profile – generally used with QDM “Physical Exam, Performed”
• u) QICore Observation Profile – generally used with QDM “Assessment, Performed” and only if the specific observation is not addressed by one of the more specific observation profiles. QDM “Care Experience” is an example of such an observation.

3.ServiceRequest – QI-Core 5.0.0 ServiceRequest adds constraints to the US Core STU5 ServiceRequest rather than the base FHIR 4.0.1 ServiceRequest.

Adverse Event

QDM defines Adverse Event as any untoward medical occurrence associated with the clinical care delivery, whether or not considered drug related. The concepts aligns with the FHIR R4 resource Adverse Event (http://hl7.org/fhir/adverseevent-definitions.html#AdverseEvent). The FHIR resource provides clearer expressivity as compared with QDM.

QDM includes an attribute code that represents the specific type of event that occurred, consistent with AdverseEvent.event.

QDM does not include an attribute to address the additional elements available in QI-Core: AdverseEvent.suspectEntity (the suspected cause), or the AdverseEvent.resultingCondition. As an example to differentiate these elements:

• AdverseEvent.event = fall
• AdverseEvent.resultingCondition = fracture
• AdverseEvent.suspectEntity = area rug

QDM version 5.6 (and earlier versions) only address one of these elements, the event. Therefore, QDM AdverseEvent code maps to AdverseEvent.event. Measure developers seeking to retrieve data about the cause of an AdverseEvent may be able to relate the occurrence timing of a potential causative event and the AdverseEvent.event timing. Further detail about the AdverseEvent will require use of FHIR or potentially a subsequent version of QDM after QDM 5.6.

QDM Context	QI-Core R5	Comments
Adverse Event	AdverseEvent
	AdverseEvent.actuality	Although not specified in QDM, QI-Core provides the ability to differentiate between potential versus actual events
QDM Attributes
code	AdverseEvent.event	Type of the event itself in relation to the subject; reference SNOMED-CT event hierarchy to represent the event in an eCQM. Note: QDM does not include an attribute to address additional elements available in QI-Core: AdverseEvent.suspectEntity (the suspected cause), or the AdverseEvent.resultingCondition.
type	AdverseEvent.category
severity	AdverseEvent.severity
relevantdateTime	AdverseEvent.date
facilityLocations	AdverseEvent.location
authorDatetime	AdverseEvent.recordedDate
id	AdverseEvent.id
recorder	AdverseEvent.recorder
	AdverseEvent.suspectEntity.instance	The actual instance of what caused the adverse event. May be a substance, medication, medication administration, medication statement or a device.
	AdverseEvent.resultingCondition	Effect on the subject due to this event

Allergy/Intolerance

Allergy is used to address immune-mediated reactions to a substance such as type 1 hypersensitivity reactions, other allergy-like reactions, including pseudo-allergy.

Intolerance is a record of a clinical assessment of a propensity, or a potential risk to an individual, to have a non-immune mediated adverse reaction on future exposure to the specified substance, or class of substance.

QDM Context	QI-Core R5	Comments
Allergy/Intolerance	AllergyIntolerance
	AllergyIntolerance.clinicalStatus	active, inactive, resolved
	AllergyIntolerance.type	Defines difference between Allergy and Intolerance
	AllergyIntolerance.verificationStatus	unconfirmed, confirmed, refuted, entered-in-error
	AllergyIntolerance.category	Food, medication, environment, biologic
QDM Attributes
code	AllergyIntolerance.code	USCoreAllergySubstance; RxNorm for medication ingredients
id	AllergyIntolerance.id
prevalencePeriod	AllergyIntolerance.onset[x]	Prevalence Period start time maps to AllergyIntolerance.onset[x]. Implementers may need to “map” existing allergy onset timings (e.g., day, age, year, etc.) to a corresponding dateTime to allow calculation of measure or CDS expressions.
	AllergyIntolerance.lastOccurrence
	AllergyIntolerance.extension:resolutionAge	Prevalence Period end time maps to AllergyIntolerance.extension:resolutionAge. Implementers may need to “map” existing allergy resolution timings (e.g., day, age, year, etc.) to a corresponding dateTime to allow calculation of measure or CDS expressions.
authorDatetime	AllergyIntolerance.recordedDate
type	AllergyIntolerance.reaction
	AllergyIntolerance.reaction.substance
	AllergyIntolerance.reaction.manifestation
	AllergyIntolerance.reaction.onset
severity	AllergyIntolerance.reaction.severity	mild, moderate, severe
	AllergyIntolerance.criticality	low, high, unable-to-assess
recorder	AllergyIntolerance.asserter
	AllergyIntolerance.recorder

Assessment

QDM defines Assessment as a resource used to define specific observations that clinicians use to guide treatment of the patient. An assessment can be a single question, or observable entity with an expected response, an organized collection of questions intended to solicit information from patients, providers or other individuals, or a single observable entity that is part of such a collection of questions. In previous versions of QI-Core, QDM Assessment category mapped directly to QICore Observation. Changes in US Core STU5 include several new observation-type profiles such that there are now six profiles providing greater specificity in defining observations. QI-Core inherits four of the observation profiles directly from US Core as no additional constraints are necessary:

• US Core Observation Sexual Orientation Profile
• US Core Observation Social History Profile
• US Core Observation SDOH Assessment Profile
• US Core Smoking Status Observation Profile

QI-Core includes a profile based on US Core Observation Survey to address additional constraints (Must Support elements), and QI-Core retains a generic Observation profile to allow measure and CDS expressions requiring data not covered by the more specific profiles:

• QICore Observation Survey – generally used with for evaluation surveys and assessment tools
• QICore Observation Profile – used only if the specific observation is not addressed by one of the more specific observation profiles; for example, gestational age at birth as a standalone observation (i.e., not part of a survey or assessment tool).

Assessment, Order

Assessment, Order uses the ServiceRequest resource. The codes for ordering specific observations should reference the code element specified in the respective profile: QICore Observation Survey; US Core Observation Sexual Orientation, US Core Observation Social History, US Core Observation SDOH Assessment, US Core Smoking Status Observation, or QICore Observation.

QDM Context	QI-Core R5	Comments
Assessment, Order	ServiceRequest
	ServiceRequest.status	Constrain to active, completed
	ServiceRequest.intent	Constrain only to “order” (include children: original-order, reflex-order, filler-order, instance-order)
QDM Attributes
Code	ServiceRequest.code
id	ServiceRequest.id
Reason	ServiceRequest.reasonCode
Author dateTime	ServiceRequest.authoredOn	When the request transitioned to being actionable.
Negation Rationale	See Below
Requester	ServiceRequest.requester

Negation Rationale for Assessment, Order

Use QICoreServiceNotRequested and reference the code element specified in the respective observation profile:

• ServiceRequest.doNotPerform - Fixed value: “true”
• ServiceRequest.status - Fixed value: “completed”
• ServiceRequest.extension:reasonRefused - Use value set NegationReasonCodes
• ServiceRequest.authoredOn - dateTime when this was made available
• ServiceRequest.extension.code:notDoneValueSet - Use qicore-notDoneValueSet to indicate the specific ServiceRequest that was not performed

Assessment, Performed

QDM defines Assessment as a resource used to define specific observations that clinicians use to guide treatment of the patient. An assessment can be a single question, or observable entity with an expected response, an organized collection of questions intended to solicit information from patients, providers or other individuals, or a single observable entity that is part of such a collection of questions.

“Assessment, Performed” maps to the one of several QI-Core profiles as applicable for the information desired:

• QICore Observation Survey – generally used with for evaluation surveys and assessment tools
• US Core Observation Sexual Orientation Profile
• US Core Observation Social History Profile
• US Core Observation SDOH Assessment Profile
• US Core Smoking Status Observation Profile
• QICore Observation Profile – used only if the specific observation is not addressed by one of the more specific observation profiles.

QDM Context	QI-Core R5	Comments
Assessment, Performed: General Use Case	Observation
	Observation.category	Since Assessment is a broad concept, the measure developer will need to select the appropriate category.
	Observation.status	Constrain status to -  final, amended, corrected
QDM Attributes
code	Observation.code
id	Observation.id
method	Observation.method
relatedTo	Observation.basedOn
	Observation.partOf	A larger event of which this particular Observation is a component or step. For example, an observation as part of a procedure.
	Observation.derivedFrom
negationRationale	See Below
reason	Observation.basedOn	The observation fulfills a plan, proposal or order - trace for authorization. Not a perfect  fit for the intent in QDM (e.g., observation “reason” = a diagnosis)  Is an extension needed?
result	Observation.value[x]
interpretation	Observation.interpretation	New in QDM 5.6
relevantDatetime	Observation.effective[x] dateTime
relevantPeriod	Observation.effective[x] Period
authorDatetime	Observation.issued
component	Observation.component
	Observation.component.id
component.code	Observation.component.code
component.result	Observation.component.value[x]
	Observation.component.interpretation
	Observation.component.dataAbsentReason
performer	Observation.performer

Negation Rationale for Assessment, Performed

Use QICoreObservationCancelled and reference the code element specified in the respective observation profile:

• Observation.status - Fixed as “cancelled”
• Observation.extension:notDoneReason - Use value set NegationReasonCodes
• Observation.issued - When this was made available
• Observation.code.extension:notDoneValueSet - Use qicore-notDoneValueSet to indicate the specific Observation that was not performed

Assessment, Recommended

Assessment, Recommended uses the ServiceRequest resource. The codes for recommending specific observations should reference the code element specified in the respective profile: QICore Observation Survey; US Core Observation Sexual Orientation, US Core Observation Social History, US Core Observation SDOH Assessment, US Core Smoking Status Observation, or QICore Observation.

QDM Context	QI-Core R5	Comments
Assessment, Recommended	ServiceRequest
	ServiceRequest.status	Constrain to active, completed
	ServiceRequest.intent	Constrain only to “plan”
QDM Attributes
code	ServiceRequest.code
id	ServiceRequest.id
reason	ServiceRequest.reasonCode
authorDatetime	ServiceRequest.authoredOn	When the request transitioned to being actionable.
negationRationale	See Below
requester	ServiceRequest.requester

Negation Rationale for Assessment, Recommended

Use QICoreServiceNotRequested and reference the code element specified in the respective observation profile:

• ServiceRequest.doNotPerform - Fixed value: “true”
• ServiceRequest.status - Fixed value: “completed”
• ServiceRequest.extension:reasonRefused - Use value set NegationReasonCodes
• ServiceRequest.authoredOn - dateTime when this was made available
• ServiceRequest.code.extension:notDoneValueSet - Use qicore-notDoneValueSet to indicate the specific ServiceRequest that was not performed

Care Experience

QDM defines Care Experience as the experience a patient has when receiving care or a provider has when providing care. QDM represents two kinds of care experience: Patient Care Experience and Provider Care Experience. While generally interpreted as patient or provider satisfaction, experience may also represent understanding, involvement and other factors about the care received or given. Most often organizations obtain such information using questionnaires. Use cases are welcome to help provide examples for us of this concept. The Care Experience concept best fits with the FHIR Observation resource.

QDM’s “Care Experience” maps to either one of two QI-Core profiles, dependent on the type of information desired:

• QICore Observation Survey Profile – generally used with for evaluation surveys and assessment tools; if the care experience information is obtained using a survey, the QICore Observation Survey Profile is appropriate.
• QICore Observation Profile – If care experience is expressed as a single finding or observation, the QICore Observation profile is appropriate.

Patient Care Experience

QDM “Patient Care Experience” maps to QICore Observation Survey Profile or QICore Observation, as applicable, for the information desired:

QDM Context	QI-Core R5	Comments
Patient Care Experience	Observation
	Observation.status	Constrain status to -  final, amended, corrected
QDM Attributes
code	Observation.code
id	Observation.id
	Observation.effective[x] dateTime
	Observation.effective[x] Period
authorDatetime	Observation.issued
recorder	Observation.performer	who was responsible for asserting the observation as “true”

Provider Care Experience

QDM “Provider Care Experience” maps to QICore Observation Survey Profile or QICore Observation, as applicable, for the information desired:

QDM Context	QI-Core R5	Comments
Provider Care Experience	Observation
	Observation.status	Constrain status to -  final, amended, corrected
QDM Attributes
code	Observation.code
id	Observation.id
	Observation.effective[x] dateTime
	Observation.effective[x] Period
authorDatetime	Observation.issued
recorder	Observation.performer	who was responsible for asserting the observation as “true”

Care Goal

QDM defines Care Goal as a defined target or measure to be achieved in the process of patient care, that is, an expected outcome. A typical goal is expressed as a change in status expected at a defined future time. That change can be an observation represented by other QDM categories (diagnostic tests, laboratory tests, symptoms, etc.) scheduled for some time in the future and with a particular value. A goal can be found in the plan of care (care plan), the structure used by many stakeholders to define the management actions for the various conditions, problems, or issues identified for the target of the plan. This structure, through which the goals and care-planning actions and processes can be organized, planned, communicated, and checked for completion, is represented in QDM as a Record Artifact in which Care Goal is found.

QDM Context	QI-Core R5	Comments
Care Goal	Goal
	Goal.achievementStatus
QDM Attributes
code	Goal.target.measure
	Goal.target.detail[x]
id	Goal.id
statusDate
targetOutcome	Goal.target.detail[x]
relevantPeriod	Goal.start[x]
	Goal.target.due[x]
statusDate	Goal.statusDate
relatedTo	Goal.addresses
performer	Goal.expressedBy

Communication

QDM defines Communication as the transmission, receipt, or acknowledgement of information sent from a source to a recipient, such as from one clinician to another regarding findings, assessments, plans of care, consultative advice, instructions, educational resources, etc.  The following text from the FHIR Communication and Procedure Resources may help to differentiate when to use Communication.

FHIR Communication Resource

This resource is a record of a communication. A communication is a conveyance of information from one entity, a sender, to another entity, a receiver. The sender and receivers may be patients, practitioners, related persons, organizations, or devices. Communication use cases include:

• A reminder or alert delivered to a responsible provider

• A recorded notification from the nurse to the on-call physician (or any other specified person) that a patient’s temperature exceeds a value

• A notification to a public health agency of a patient presenting with a communicable disease reportable to the public health agency

• Patient educational material sent by a provider to a patient

• Unable to deliver lab results to ordering physician

Non-patient specific communication use cases may include:

• A nurse call from a hall bathroom

• Advisory for battery service from a pump

Boundaries and Relationships (Section 8.20.2) - Communication and Encounter

• The Communication is about the transfer of information (which might or might not occur as part of an encounter), while Encounter is about the coming together (in person or virtually) of a Patient with a Practitioner. Communication does not deal with the duration of a call, it represents the fact that information was transferred at a particular point in time.

• The phone calls involving the Patient should be handled using Encounter. Phone calls not involving the patient (e.g. between practitioners or practitioner to relative) that are tracked for billing or other purposes can use Communication to represent the information transferred but are not ideal to represent the call itself. A better mechanism for handling such calls will be explored in a future release.

HL7 FHIR Procedure Resource

The boundary between determining whether an action is a Procedure (training or counseling) as opposed to a Communication is based on whether there’s a specific intent to change the mind-set of the patient. Mere disclosure of information would be considered a Communication. A process that involves verification of the patient’s comprehension or to change the patient’s mental state would be a Procedure.

Communication, Performed

QDM Context	QI-Core R5	Comments
Communication, Performed	Communication
	Communication.status	constrain to completed
QDM Attributes
code	Communication.topic
id	Communication.id
category	Communication.category	alert, notification, reminder, instruction
medium	Communication.medium
sentDatetime	Communication.sent
receivedDatetime	Communication.received
authorDatetime	Communication.extension:recorded	for use with negationRationale
relatedTo	Communication.basedOn	An order, proposal or plan fulfilled in whole or in part by this Communication.
	Communication.inResponseTo	Response to a communication
sender	Communication.sender
recipient	Communication.recipient
negationRationale	See Below

Negation Rationale for Communication, Performed

Use QICoreCommunicationNotDone, which contains:

• Communication.status - Fixed Value: “not-done”
• Communication.statusReason - Use value set NegationReasonCodes
• Communication.extension:recorded - dateTime when this was made available
• Communication.topic.extension:notDoneValueSet - Use qicore-notDoneValueSet to indicate the specific Communication that was not performed

Diagnosis

QDM defines Condition/Diagnosis/Problem as a practitioner’s identification of a patient’s disease, illness, injury, or condition. This category contains a single datatype to represent all of these concepts: Diagnosis. A practitioner determines the diagnosis by means of examination, diagnostic test results, patient history, and/or family history. Diagnoses are usually considered unfavorable, but they may also represent neutral or favorable conditions that affect a patient’s plan of care (e.g., pregnancy).

Based on changes in US Core STU5, QI-Core now has two methods for expressing conditions, QICore Condition Problems and Health Concerns Profile, and QICore Condition Encounter Diagnosis Profile. Please reference the respective profile pages for explanation of the rationale for using each of these profiles. Briefly, the Condition Problems and Health Concerns Profile meets the US Core Data for Interoperability (USCDI) version 2 ‘Problems’ and ‘Health Concerns’ and SDOH Problems/Health Concerns requirements. The Condition Encounter Diagnosis Profile further meets the USCDI v2 requirement to define Encounter Diagnosis.

QDM Context	QI-Core R5	Comments
Condition - Diagnosis - Problem	Condition Problems and Health Concerns
	ConditionProblemsHealthConcerns.clinicalStatus	defines active/inactive
	ConditionProblemsHealthConcerns.verificationStatus	confirmed, unconfirmed provisional, differential, refuted, entered-in-error,
	ConditionProblemsHealthConcerns.category	problem-list-item, encounter-diagnosis, health-concern
QDM Attributes
code	ConditionProblemsHealthConcerns.code
id	ConditionProblemsHealthConcerns.id
prevalencePeriod	ConditionProblemsHealthConcerns.onset[x]	May be dateTime, Age, Period Range, string
	ConditionProblemsHealthConcerns.abatement[x]	May be dateTime, Age, Period Range, string
authorDatetime	ConditionProblemsHealthConcerns.recordedDate
severity	ConditionProblemsHealthConcerns.severity	severe, moderate, mild
anatomicalLocationSite	ConditionProblemsHealthConcerns.bodySite
recorder	ConditionProblemsHealthConcerns.recorder	Individual who recorded the record and takes responsibility for its content
	ConditionProblemsHealthConcerns.asserter	Individual who is making the condition statement

Device

QDM defines Device as an instrument, apparatus, implement, machine, contrivance, implant, in-vitro reagent, or other similar or related article, including a component part or accessory, intended for use in the diagnosis, cure, mitigation, treatment, or prevention of disease and not dependent on being metabolized to achieve any of its primary intended purposes.

FHIR defines the Device Resource as a type of a manufactured item that is used in the provision of healthcare without being substantially changed through that activity. The device may be a medical or non-medical device.

FHIR and US Core further differentiate devices into two “classes”:

• Devices that interact with the human body but do not stay in it are referred to as non-implantable medical devices.
• Implantable devices are those which stay in the human body with a medical objective for an extended period of time, or even a lifetime.

[Definition reference: Imam W. How to use ISO 13485:2016 to manage implantable devices, ISO 13485 Blog. July 4, 2016. Available at: https://advisera.com/13485academy/blog/2017/07/04/how-to-use-iso-134852016-to-manage-implantable-medical-devices/. Accessed 28 January 2020.]

The FHIR Device Resource addresses both implantable and non-implantable devices. US Core only references Implantable Device. QI-Core inherits Implantable Device from US Core and builds directly from FHIR for the QI-Core Device Resource.

Device, Applied

QDM originally designed Device, Applied to allow access to documentation of device usage. However, evaluation over time indicates that all documentation about usage of a device occurs as an observation. Thus, information about an implanted pacemaker status check, utilization of a patient-use Continuous Positive Airway Pressure (CPAP) device, results from a glucometer, or use of a wheelchair or cane should use the QDM datatype, Assessment, Performed, or QI-Core Observation. Use of Device, Applied has been synonymous with Procedure, Performed, i.e., placement of or adjustment to a device.

“Device Applied” has been retired in QDM 5.6 in favor of using “Procedure, Performed” or “Assessment, Performed” as appropriate.

Device, Order – Non-Patient-use Devices

QDM Context	QI-Core R5	Comments
Device Request	ServiceRequest
	ServiceRequest.status	Constrain to active, completed
Device, Order	ServiceRequest.intent	Constrain to “order” (include children)
QDM Attributes
code	ServiceRequest.code
id	ServiceRequest.id
reason	ServiceRequest.reasonCode
authorDatetime	ServiceRequest.authoredOn	FHIR allows dateTime or Period for desired time or schedule for use.
negationRationale	See Below
requester	ServiceRequest.requester

Negation Rationale for Device, Order

Use QICoreServiceNotRequested, which contains:

• ServiceRequest.doNotPerform - Fixed value: “true”
• ServiceRequest.status - Fixed value: “completed”
• ServiceRequest.extension:reasonRefused - Use value set NegationReasonCodes
• ServiceRequest.authoredOn - dateTime when this was made available
• ServiceRequest.code.extension:notDoneValueSet - Use qicore-notDoneValueSet to indicate the specific ServiceRequest that was not performed

Device, Order – Personal Use Devices

QDM Context	QI-Core R5	Comments
Device Request	DeviceRequest
	DeviceRequest.status	Constrain to active, completed
Device, Order	DeviceRequest.intent	Constrain to “Order” (include children)
QDM Attributes
code	DeviceRequest.code[x]
id	DeviceRequest.id
reason	DeviceRequest.reasonCode
authorDatetime	DeviceRequest.authoredOn	FHIR allows dateTime or Period for deseired time or schedule for use.
negationRationale	See Below
requester	DeviceRequest.requester

Negation Rationale for Device, Order – Personal Use Devices

Use QICoreDeviceNotRequested, which contains:

• DeviceRequest.modifierExtension:doNotPerform - Fixed value: “true”
• DeviceRequest.status - Fixed value: “completed”
• DeviceRequest.extension:doNotPerformReason - Use value set NegationReasonCodes
• DeviceRequest.authoredOn - dateTime when this was made available
• DeviceRequest.code[x].extension:doNotPerformValueSet - Use qicore-notDoneValueSet to indicate the specific DeviceRequest that was not performed

Device, Recommended – Non-Patient-use Devices

QDM Context	QI-Core R5	Comments
Device Request	ServiceRequest
	ServiceRequest.status	Constrain to active, completed
Device, Order	ServiceRequest.intent	Constrain to “order” (include children)
QDM Attributes
code	ServiceRequest.code
id	ServiceRequest.id
reason	ServiceRequest.reasonCode
authorDateTime	ServiceRequest.authoredOn	FHIR allows dateTime or Period for desired time or schedule for use.
negationRationale	See Below
requester	ServiceRequest.requester

Negation Rationale for Device, Recommended

Use QICoreServiceNotRequested, which contains:

• ServiceRequest.doNotPerform - Fixed value: “true”
• ServiceRequest.status - Fixed value: “completed”
• ServiceRequest.extension:reasonRefused - Use value set NegationReasonCodes
• ServiceRequest.authoredOn - dateTime when this was made available
• ServiceRequest.code.extension:notDoneValueSet - Use qicore-notDoneValueSet to indicate the specific ServiceRequest that was not performed

Device, Recommended – Personal Use Devices

QDM Context	QI-Core R5	Comments
Device Request	DeviceRequest
	DeviceRequest.status	Constrain to active, completed
Device, Order	DeviceRequest.intent	Constrain to “Order” (include children)
QDM Attributes
code	DeviceRequest.code[x]
id	DeviceRequest.id
reason	DeviceRequest.reasonCode
authorDatetime	DeviceRequest.authoredOn	FHIR allows dateTime or Period for deseired time or schedule for use.
negationRationale	See Below
requester	DeviceRequest.requester

Negation Rationale for Device, Recommended – Personal Use Devices

Use QICoreDeviceNotRequested, which contains:

• DeviceRequest.modifierExtension:doNotPerform - Fixed value: “true”
• DeviceRequest.status - Fixed value: “completed”
• DeviceRequest.extension:doNotPerformReason - Use value set NegationReasonCodes
• DeviceRequest.authoredOn - dateTime when this was made available
• DeviceRequest.code[x].extension:doNotPerformValueSet - Use qicore-notDoneValueSet to indicate the specific DeviceRequest that was not performed

Diagnostic Study

QDM defines Diagnostic Study as any kind of medical test performed as a specific test or series of steps to aid in diagnosing or detecting disease (e.g., to establish a diagnosis, measure the progress or recovery from disease, confirm that a person is free from disease). The QDM differentiates diagnostic studies from laboratory tests in that diagnostic studies are those that are not performed in organizations that perform testing on samples of human blood, tissue, or other substance from the body. Diagnostic studies may make use of digital images and textual reports. Such studies include but are not limited to imaging studies, cardiology studies (electrocardiogram, treadmill stress testing), pulmonary-function testing, vascular laboratory testing, and others.

QI-Core has added specific constraints on US Core STU5 additional profiles that address such non-laboratory tests:

1. QICore Observation Clinical Test Result – non-laboratory, non-imaging tests; this profile is sufficiently broad that it should be used instead of the QI-Core Observation profile for all non-laboratory, non-imaging test results
2. QICore Observation Imaging Result – imaging study results

Diagnostic Study, Order

“Diagnostic Study, Order” should reference orders for studies that will generate results for activities that meet criteria for Observation Clinical Test or Observation Imaging Result profiles.

QDM Context	QI-Core R5	Comments
Diagnostic Study, Order	ServiceRequest
	ServiceRequest.status	Constrain to active, completed
	ServiceRequest.intent	Constrain only to “order” (include children: original-order, reflex-order, filler-order, instance-order)
QDM Attributes
code	ServiceRequest.code
id	ServiceRequest.id
reason	ServiceRequest.reasonCode
authorDatetime	ServiceRequest.authoredOn	When the request transitioned to being actionable.
negationRationale	See Below
requester	ServiceRequest.requester

Negation Rationale for Diagnostic Study, Order

Use QICoreServiceNotRequested and reference the code element specified in the respective observation profile:

• ServiceRequest.doNotPerform - Fixed value: “true”
• ServiceRequest.status - Fixed value: “completed”
• ServiceRequest.extension:reasonRefused - Use value set NegationReasonCodes
• ServiceRequest.authoredOn - dateTime when this was made available
• ServiceRequest.code.extension:notDoneValueSet - Use qicore-notDoneValueSet to indicate the specific ServiceRequest that was not performed

Diagnostic Study, Performed

Individual studies may use the US Core DiagnosticReport Profile for Report and Note Exchange to provide information about an individual study (e.g., a cardiac ultrasound, MRI, etc.) although some have considered use of other reporting resources and artifacts. Since new studies regularly become available and the nature of existing studies change over time, a complete list of studies to reference a desired result cannot be assured. Therefore, a quality measure or clinical decision support (CDS) artifacts seeking a specific result value should use the QICore Observation Clinical Test Result or the QICore Observation Imaging Result to request a retrieve of the result value desired. This practice will enable implementers to determine which is the best source for the desired observation. LOINC observable entities may indicate specific methods for determination of results. Measure and CDS developers can reference direct reference codes or value sets using such LOINC codes to specify the type of testing considered acceptable to provide sufficient fidelity to their requests.

QDM Context	QI-Core  R5	Comments
Diagnostic Study, Performed	•Observation Clinical Test Profile for non-laboratory, non-imaging study results •Observation Imaging Result Profile for imaging study results
	•ObservationClinicalTestResult.partOf •ObservationImagingResult.partOf	A larger event of which this particular Observation is a component or step. For example, an observation as part of a procedure.
	•ObservationClinicalTestResult.status •ObservationImagingResult.status	Constrain status to -  final, amended, corrected
QDM Attributes
code	•ObservationClinicalTestResult.code •ObservationImagingResult.code
id	•ObservationClinicalTestResult.id •ObservationImagingResult.id
method	•ObservationClinicalTestResult.method •ObservationImagingResult.method
facilityLocation	N/A
	•ObservationClinicalTestResult.bodySite •ObservationImagingResult.bodySite
negationRationale	See Below
reason	•ObservationClinicalTestResult.basedOn •ObservationImagingResult.basedOn	the Observation.basedOn concept indicates the plan, proposal or order that the observation fulfills. This concept is not consistent with the QDM concept of “reason” for the study to be performed.
relatedTo	•ObservationClinicalTestResult.basedOn •ObservationImagingResult.basedOn	New in QDM 5.6
result	•ObservationClinicalTestResult.value[x] •ObservationImagingResult.value[x]
interpretation	•ObservationClinicalTestResult.interpretation •ObservationImagingResult.interpretation	New in QDM 5.6
resultDatetime	•ObservationClinicalTestResult.issued •ObservationImagingResult.issued
relevantDatetime	•ObservationClinicalTestResult.effective[x] dateTime •ObservationImagingResult.effective[x] dateTime
relevantPeriod	•ObservationClinicalTestResult.effective[x] Period •ObservationImagingResult.effective[x] Period
status	•ObservationClinicalTestResult.status •ObservationImagingResult.status	Constrain status to -  final, amended, corrected, appended
authorDatetime	•ObservationClinicalTestResult.issued •ObservationImagingResult.issued	Issued - the date and time this version of the observation was made available to providers, typically after the results have been reviewed and verified. Consider if QI-Core should include an extension to manage timing of the dataAbsentReason.
component	•ObservationClinicalTestResult.component •ObservationImagingResult.component	Components not present in US Core-R4 DiagnosticReport but the report references Observation for results; thus it seems reasonable to re-use observation concepts for the components of a DiagnosticReport
	•ObservationClinicalTestResult.component.id •ObservationImagingResult.component.id
component.code	•ObservationClinicalTestResult.component.code •ObservationImagingResult.component.code
component.result	•ObservationClinicalTestResult.component.value[x] •ObservationImagingResult.component.value[x]
	•ObservationClinicalTestResult.component.interpretation •ObservationImagingResult.component.interpretation
	•ObservationClinicalTestResult.component.dataAbsentReason •ObservationImagingResult.component.dataAbsentReason
performer	•ObservationClinicalTestResult.performer •ObservationImagingResult.performer

Negation Rationale for Diagnostic Study, Performed

Use QICoreObservationCancelled and reference the code element specified in the respective observation profile:

• Observation.status - Fixed value: “cancelled”
• Observation.extension:notDoneReason - Use value set NegationReasonCodes
• Observation.issued - dateTime when this was made available
• Observation.code.extension:notDoneValueSet - Use qicore-notDoneValueSet to indicate the specific Observation that was not performed

Diagnostic Study, Recommended

“Diagnostic Study, Recommended” should reference recommendations for studies that will generate results for activities that meet criteria for Observation Clinical Test or Observation Imaging Result profiles.

QDM Context	QI-Core R5	Comments
Diagnostic Study, Recommended	ServiceRequest
	ServiceRequest.status	Constrain to active, completed
	ServiceRequest.intent	Constrain only to “plan”
QDM Attributes
code	ServiceRequest.code
id	ServiceRequest.id
reason	ServiceRequest.reasonCode
authorDatetime	ServiceRequest.authoredOn	When the request transitioned to being actionable.
negationRationale	See Below
requester	ServiceRequest.requester

Negation Rationale for Diagnostic Study, Recommended

Use QICoreServiceNotRequested and reference the code element specified in the respective observation profile:

• ServiceRequest.doNotPerform - Fixed value: “true”
• ServiceRequest.status - Fixed value: “completed”
• ServiceRequest.extension:reasonRefused - Use value set NegationReasonCodes
• ServiceRequest.authoredOn - dateTime when this was made available
• ServiceRequest.code.extension:notDoneValueSet - Use qicore-notDoneValueSet to indicate the specific ServiceRequest that was not performed

Encounter

QDM defines Encounter as an identifiable grouping of healthcare-related activities characterized by the entity relationship between the subject of care and a healthcare provider; such a grouping is determined by the healthcare provider. A patient encounter represents interaction between a healthcare provider and a patient with a face-to-face patient visit to a clinician’s office, or any electronically remote interaction with a clinician for any form of diagnostic treatment or therapeutic event.

Encounter Timing

Implementation considerations must be considered when referencing encounter periods (start to end time).  Some clinical sites may leave Encounters “open” until all documentation has been completed which may take 72 hours or more.  However, the actual encounter may have lasted for a much shorter time period (e.g., 15 minutes for an ambulatory encounter). This issue is addressed in The Office of the National Coordinator for Health IT (ONC) Issue Tracking System as item QDM-235. Two approaches clinical sites have used to manage this issue include:

• Include a patient check-in and check-out time as part of the visit documentation. These times represent when the patient arrives and leaves, respectively, and these times are used for the Encounter relevant period. However, patient arrival at a location does not necessarily mean the start of the encounter (e.g. a patient arrives an hour earlier than he or she is actually seen by a practitioner).

• Default an Encounter end as 23:59 on the date of the Encounter date if it is left open to allow completion of documentation and update the end time if the practitioner closing the chart enters a specific time that the encounter ended.

Undoubtedly, other clinical sites have implemented other solutions to documenting end times for ambulatory visits. Quality measure and clinical decision support (CDS) artifact authors should consider such issues when testing the validity and reliability of retrieved responses to data queries.

Encounter-Related Diagnoses and Procedures

Encounter.diagnosis refers to the list of diagnosis/diagnoses relevant to the encounter. The Encounter.diagnosis.use value differentiates if the diagnosis is the admission diagnosis (AD), the discharge diagnosis (DD), the chief complaint (CC), a comorbidity diagnosis (CM), a pre-op diagnosis (pre-op), a post-op diagnosis (post-op) or a billing diagnosis (billing).

Some quality measures used to evaluate care provided in hospital settings use concepts to define principal diagnosis and present on admission:

• Principal diagnosis is defined as the condition that, after study, was determined to be the principal cause of the admission. QDM version 5.5 addresses that concept using the US Core concepts Encounter.diagnosis.use value=billing with an diagnosis.rank=1.

• Present on admission (POA) is an indicator assigned to Inpatient Encounter diagnoses and is used in quality and patient safety measures. QDM version 5.5 references this indicator as a component of each Encounter, Performed diagnosis The US Core and FHIR Encounter resources do not address present on admission. However, the FHIR Claim resource includes a claim.diagnosis.onAdmission element referencing similar terms as the US UB-04 claim form to indicate present on admission – yes (y), no (n), unknown (u), and undetermined (w). QI-Core includes an extension on Encounter.diagnosis to reference the onAdmission element, thus enabling specification of an Encounter.diagnosis that is present on admission.

• Principal procedure is the procedure performed for definitive treatment rather than diagnostic or exploratory purposes, or which is necessary to take care of a complication.
  [https://manual.jointcommission.org/releases/TJC2015B/DataElem0685.html] Principal procedure defines a procedures relationship to an encounter (most often an inpatient encounter). It has not relationship to the inherent nature of the procedure. Therefore, QI-Core includes an extension modeling Encounter.procedure in the same way as Encounter.diagnosis. The Encounter.procedure has a code to indicate the procedure code and a rank to indicate its ordinality such that rank=1 identifies the procedure as a principal procedure.

• Elective procedure is another concept used in quality measurement, especially in hospital measures. A specific measure may have interest in evaluating care provided for elective procedures (e.g., hip surgery due to osteoarthritis) while excluding emergency, non-planned procedures (e.g., hip surgery due to acute fracture). The procedure code does not necessarily allow differentiation of the two concepts. A ServiceRequest.priority does have the ability to differentiate the urgency with which the request (or order) should be fulfilled. However, there is no element within the FHIR Procedure resource to address the issue. Encounter.priority allows specification of whether the encounter is elective. Since the Encounter.procedure can be linked to the ServiceRequest with its priority, there is no need to add a specific extension in QI-Core for Encounter.procedure.priority. Therefore, there is no direct mapping from the QDM Procedure priority attribute to QI-Core and measures considering the concept should reference QDM’s Encounter, Order with its priority.

Encounter, Order

QDM Context	QI-Core R5	Comments
Encounter, Order	ServiceRequest
	ServiceRequest.status	Constrain to active, completed
	ServiceRequest.intent	Constrain only to “order” (include children: original-order, reflex-order, filler-order, instance-order)
QDM Attributes
code	ServiceRequest.code
id	ServiceRequest.id
reason	ServiceRequest.reasonCode
authorDatetime	ServiceRequest.authoredOn	When the request transitioned to being actionable.
facilityLocation	ServiceRequest.locationCode
priority	ServiceRequest.modifierExtension:isElective
negationRationale	See Below
requester	ServiceRequest.requester

Negation Rationale for Encounter, Order

Use QICoreServiceNotRequested, which contains:

• ServiceRequest.doNotPerform - Fixed value: “true”
• ServiceRequest.status - Fixed value: “completed”
• ServiceRequest.extension:reasonRefused - Use value set NegationReasonCodes
• ServiceRequest.authoredOn - dateTime when this was made available
• ServiceRequest.code.extension:notDoneValueSet - Use qicore-notDoneValueSet to indicate the specific ServiceRequest that was not performed

Encounter, Performed

QDM Context	QI-Core R5	Comments
Encounter, Performed	Encounter
	Encounter.status	constrain to - arrived, triaged, in-progress, on-leave, finished Note: most retrospective eCQMs will constrain Encounter.status to “finished”. Measures designed to monitor active encounters should consider using “in-progress”.
QDM Attribute
code	Encounter.type	Uses value set: USCoreEncounterType
id	Encounter.id
class	Encounter.class	New in QDM 5.6 uses V3 Value Set ActEncounterCode
relatedTo	Encounter.basedOn	New in QDM 5.6
relevantPeriod	Encounter.period	start and end time of encounter
diagnoses
diagnosis (code)	Encounter.diagnosis.condition with reference to: •QICore Encounter Condition Diagnosis AND •QICore Condition Problems and Health Concerns	can be used for coded diagnoses
presentOnAdmissionIndicator (code)	Encounter.diagnosis.extension:diagnosisPresentOnAdmission	Indicator of whether the Encounter diagnosis was present at the time of admission. Note: this element uses the value set (required) diagnosis-on-admission (the same value set as used with the claim resource)
rank (Integer)	Encounter.diagnosis.rank	for each diagnosis role
procedures	Encounter.reasonReference.procedure	References the procedure relevant to encounter
	Encounter.diagnosis.procedure	References the procedure code
lengthOfStay	Encounter.length
authorDatetime	Not Addressed
admissionSource	Encounter.hospitalization.admitSource
dischargeDisposition	Encounter.hospitalization.dischargeDisposition	E.g., home, hospice, long-term care, etc.
	Encounter.hospitalizaton.destination
facilityLocations
code	Encounter.location.location
locationPeriod	Encounter.location.period
participant	Encounter.participant.individual
	Encounter.serviceProvider	Encounter.serviceProvider identifies the organization that is primarily responsible for the Encounter’s services.

Encounter, Recommended

QDM Context	QI-Core R5	Comments
Encounter, Recommended	ServiceRequest
	ServiceRequest.status	Constrain to active, completed
	ServiceRequest.intent	Constrain only to “plan”
QDM Attributes
code	ServiceRequest.code
id	ServiceRequest.id
reason	ServiceRequest.reasonCode
authorDatetime	ServiceRequest.authoredOn	When the request transitioned to being actionable.
facilityLocation	ServiceRequest.locationCode
priority	ServiceRequest.modifierExtension:isElective
negationRationale	See Below
requester	ServiceRequest.requester

Negation Rationale for Encounter, Recommended

Use QICoreServiceNotRequested, which contains:

• ServiceRequest.doNotPerform - Fixed value: “true”
• ServiceRequest.status - Fixed value: “completed”
• ServiceRequest.extension:reasonRefused - Use value set NegationReasonCodes
• ServiceRequest.authoredOn - dateTime when this was made available
• ServiceRequest.code.extension:notDoneValueSet - Use qicore-notDoneValueSet to indicate the specific ServiceRequest that was not performed

Family History

QDM defines Family History as a diagnosis or problem experienced by a family member of the patient. Typically, a family history will not contain very much detail, but the simple identification of a diagnosis or problem in the patient’s family history may be relevant to the care of the patient.

QDM Context	QI-Core R5	Comments
Family History	FamilyMemberHistory
	FamilyMemberHistory.status	Constrain to partial, completed
QDM Attributes
code	FamilyMemberHistory.condition.code
id	FamilyMemberHistory.id
authorDatetime	FamilyMemberHistory.date
relationship	FamilyMemberHistory.relationship
recorder	N/A

Immunization

QDM defines Immunization as vaccines administered to patients in healthcare settings but does not include non-vaccine agents. The FHIR Immunization Recommendation resource is specifically designed to provide an immunization forecast from a forecasting engine to a provider, basically to carry clinical decision support recommendations specific to immunizations and, therefore, is not consistent with the intent of the QDM datatype “Immunization, Order” or “Immunization, Administered.” The FHIR Immunization Evaluation references an appraisal of an immunization that was administered to determine if it is valid with respect to the expected immunization schedule. The US Core Immunization profile is most consistent with the QDM datatype Immunization, Administered.  The mapping tables provided include mapping from QDM Immunization, Administered and a reference to the FHIR Immunization Evaluation resource. Note, the mapping table includes additional metadata about immunizations that QDM does not address, but that may be relevant to quality measures or clinical decision support (CDS) artifacts.

Immunization, Administered

QDM Context	US Core R5	Comments
Immunization, Administered	Immunization
	Immunization.status	Constrain to “completed”
QDM Attributes
code	Immunization.vaccineCode
id	Immunization.id
dosage	Immunization.doseQuantity
negationRationale	See Below
route	Immunization.route
reason	Immunization.reasonCode
relevantDatetime	Immunization.occurrence[x]
authorDatetime	Immunization.recorded
performer	Immunization.performer.actor

Negation Rationale for Immunization, Administered

Use QICoreImmunizationNotDone, which contains:

• Immunization.status - Fixed value: “not-done”
• Immunization.statusReason - Use value set NegationReasonCodes
• Immunization.recorded - dateTime
• Immunization.vaccineCode.extension:notDoneValueSet - Use qicore-notDoneValueSet to indicate the specific immunization that was not administered

Immunization, Order

This QDM context references the QI-Core MedicationRequest profile as there is no other FHIR resource to reference an order for an immunization. The mapping uses the QI-Core MedicationRequest resource with the MedicationRequest.intent = order and MedicationRequest.setting set to the setting most appropriate for the intended meaning of the quality measure or clinical decision support (CDS) expression.

QDM Context	QI-Core R5	Comments
Immunization, Order	MedicationRequest
	MedicationRequest.status	Constrain to active, completed
	MedicationRequest.statusReason	The reason for ordering or not ordering the medication
	MedicationRequest.intent	Constrain to “order” for Medication, Order - note that QDM does not include Medication, Recommended - should that concept be desired, use MedicationRequest.intent constrained to “plan”
QDM Attributes
code	MedicationRequest.medication[x]	RxNorm
id	MedicationRequest.id
activeDatetime	MedicationRequest.dosageInstruction.timing with Timing.repeat.bounds[x] Period	QDM defines active dateTime as when the order indicates the first immunization administration should occur. Active dateTime is most often used to specify immunizations for which administration is intended at a specific time in the future. FHIR allows specification of the period during which the immunization should occur (start dateTime to end dateTime)
authorDatetime	MedicationRequest.authoredOn
dosage	MedicationRequest.dosageInstruction.doseAndRate.dose[x]	Range, quantity
route	MedicationRequest.dosageInstruction.route
reason	MedicationRequest.reasonCode	The reason for ordering or not ordering the medication
supply	MedicationRequest.dispenseRequest.quantity	Amount to be dispensed in one fill
negationRationale	See Below
	MedicationRequest.reasonCode	The reason for ordering or not ordering the medication.
requester	MedicationRequest.requester	Note - MedicationRequest.performer indicates the performer expected to administer the medication

Negation Rationale for Immunization, Order

Use QICoreMedicationNotRequested, which contains:

• MedicationRequest.doNotPerform - Fixed value: “true”
• MedicationRequest.status - Fixed value: “completed”
• MedicationRequest.reasonCode - Use value set NegationReasonCodes
• MedicationRequest.authoredOn - dateTime when this was made available
• MedicationRequest.medication[x].extension:notDoneValueSet - Use qicore-notDoneValueSet to indicate the specific MedicationRequest that was not performed

Individual Characteristics

QDM’s approach to defining information about participants In the healthcare process by defining Individual Characteristics. These properties of a patient, clinician, provider, or facility include demographics, behavioral factors, social or cultural factors, available resources, and preferences. Behaviors reference responses or actions that affect (either positively or negatively) health or healthcare. Included in this category are mental health issues, adherence issues unrelated to other factors or resources, coping ability, grief issues, and substance use/abuse. Social/cultural factors are characteristics of an individual related to family/caregiver support, education, and literacy (including health literacy), primary language, cultural beliefs (including health beliefs), persistent life stressors, spiritual and religious beliefs, immigration status, and history of abuse or neglect. Resources are means available to a patient to meet health and healthcare needs, which might include caregiver support, insurance coverage, financial resources, and community resources to which the patient is already connected and from which the patient is receiving benefit. Preferences are choices made by patients and their caregivers relative to options for care or treatment (including scheduling, care experience, and meeting of personal health goals) and the sharing and disclosure of their health information.

FHIR more effectively represents these concepts in the Level 3 Administration Module – base data that is linked into other modules for clinical content, finance/billing, workflow, etc. The Administration Module specifies information about the patient, related person, practitioner and organization that is the basis of healthcare-related interactions such as encounters. QDM version 5.5 adopted a similar approach to such information by adding a new concept called Entities. Entities  represent concepts that can be used to specify details about an actor (or performer) participant in any activity represented by a QDM datatype. These entities are analogous to the FHIR resources Patient, RelatedPerson, Practitioner, and Organization, respectively called Patient, CarePartner, Practitioner and Organization in QDM. The mapping tables show these direct relationships to FHIR resources. However, to maintain backward compatibility with prior QDM versions, QDM 5.5 retains the concept of Patient Characteristics for some metadata about a patient; most of these characteristics map directly to metadata elements in the FHIR Patient resource. QDM 5.5 removed the Provider Characteristics QDM datatype in favor of the Practitioner and Organization entities since there had been little, if any, use of these QDM elements.

Accommodating patient-related metadata requires QI-Core extensions for several elements including:

• Clinical Trial – Patients may be excluded from some quality measures or clinical decision support (CDS) workflows if they are participating in clinical trials. It is often necessary to determine the nature of the trial as exclusions may only apply if the clinical trial addresses the same clinical condition as the measure or CDS artifact, or if treatments potentially used in the clinical trial or the measure or CDS intervention conflict.

QDM 5.5 also added a new QDM datatype Related Person to allow reference to an individual who has a personal or non-healthcare-specific professional relationship with a patient. Modeled the same as the CarePartner entity, the Related Person is an individual from whose record clinical information should be retrieved to support care provided to the index patient. 

• Example 1: An infant’s gestational age at the time of birth may be calculated as the difference between the days between the mother’s estimated date of delivery (EDD) and the actual birth date. The mother’s EDD might be entered directly on the infant’s record as an observable entity about a Related Person (the infant’s mother). Alternatively, a cross-context query might request the information from the Related Person’s (mother’s) record.

• Example 2: An organ recipient risk factor may include a donor’s positive Hepatitis C antibody result. The result relates to the donor (Related Person) whether that result is present on the recipient’s record or if the a cross-context query to the donor’s record retrieves the information.

QDM Entities

QDM Entities & Attributes	QI-Core R5	Comment
Patient	Patient
identifier	Patient.identifier.value
id	Patient.id
Care Partner	RelatedPerson	Related Person
identifier	RelatedPerson.identifier
id	RelatedPerson.id
relationship	RelatedPerson.relationship
Practitioner	Practitioner
identifier	Practitioner.identifier (or specific practitioner identifier types: Practitioner.identifier:ein)
id	Practitioner.id
role	PractitionerRole.code
specialty	PractitionerRole.specialty
qualification	Practitioner.qualification.code
Organization	Organization
identifier	Organization.identifier (or specific organizational identifier types: Organization.identifier:ccn, Organization.identifier:ein)
id	Organization.id
organizationType	Organization.type	QDM attribute name update in QDM 5.6
Location	Location	New in QDM 5.6
identifier	Location.identifier.value	New in QDM 5.6
id	Location.id	New in QDM 5.6
locationType	Location.type	New in QDM 5.6

Patient Characteristics

QDM Attribute	US Core R5	Comments
Race		See US CoreRaceExtension for details
code	Patient.extension:race
id
Ethnicity
code	Patient.extention:ethnicity	See US CoreEthnicityExtension for details
id
Sex
code	Patient.extension:birthsex
code	Patient.gender	Administrative Gender
id
Birthdate
birthDatetime	Patient.birthdate	Fixed code 21112-8
id
Clinical Trial Participant		Clinical Trial Participant should be handled as an Observation (i.e., Assessment, Performed) in QDM rather than a Patient Characteristic
Expired
code	Patient.deceased[x] boolean
id
cause		Expiration cause requires use of Observation
expirationDatetime	Patient.deceased[x] dateTime
Payer	Coverage
code	Coverage.payor	QI-Core currently maps to policy holder which actually references the person who owns the policy, not the payor.
relevantPeriod	Coverage.period
id	Coverage.id
Patient Characteristic (generic)
N/A		Requires definition for modeling a characteristic to QI-Core and FHIR

QDM datatype - Related Person

QDM Attribute	QI-Core R5	Comments
Related Person	RelatedPerson
identifier	RelatedPerson.identifier
id	RelatedPerson.id
linkedPatientId	N/A	Not present in QI-Core
code	RelatedPerson.relationship

Intervention

QDM defines Intervention as a course of action intended to achieve a result in the care of persons with health problems that does not involve direct physical contact with a patient. Examples include patient education and therapeutic communication.

Procedure Vs Intervention

FHIR references both of these concepts using the Procedure resource, specifically noting a process that involves verification of the patient’s comprehension or to change the patient’s mental state would be a Procedure. Therefore, both QDM datatypes, Procedure and Intervention are included in this section of the QDM to QI-Core mapping especially since all of the QDM attributes for each of these QDM datatypes are identical.

Intervention, Performed

QDM Context	QI-Core R5	Comments
Intervention, Performed	Procedure
	Procedure.category	Helps differentiate “intervention” from “procedure”
QDM Attributes
status	Procedure.status	constrain to “completed”
code	Procedure.code
id	Procedure.id
relatedTo	Procedure.basedOn	A reference to a resource that contains details of the request for this procedure. New in QDM 5.6
method	N/A	Procedure.method does not exist in FHIR. Rather than create an extension, QI-Core’s approach is to assume the Procedure.code includes reference to the method.
rank	Encounter.diagnosis.rank	Referenced as the principal or non-principal diagnosis of the Encounter.
priority	Encounter.reasonReference.procedure	This QDM attribute is intended to reference elective from non-elective procedures. QI-Core references procedure.priority based on the relationship of the procedure to the Encounter; hence, Encounter.reasonReference.procedure (which is a reference to the procedure). The elective nature of a procedure can also be referenced based on the elective nature of an Encounter (Encounter.priority) for which the respective procedure is a principal procedure. The concept may also be addressed as an Encounter, Order or Procedure, Order (both using ServiceRequest) and ServiceRequest.priority.
anatomicalLocationSite	Procedure.bodySite
reason	Procedure.reasonCode
result	Observation that includes the element Observation.partOf to reference the procedure to which it applies.	Procedure.report references DiagnosticReport-note, DocumentReference, Composition (histology result, pathology report, surgical report, etc.); the latter two are not QI-Core resources. However, based on feedback regarding the use of the Observation resource, a procedure result might be better referenced as an Observation that includes the element Observation.partOf to reference the procedure to which it applies.
	Observation.partOf	Reference to a resource that contains details of the request for this procedure.
negationRationale	See Below
relevantDatetime	Procedure.performed[x] dateTime
relevantPeriod	Procedure.performed[x] Period
incisionDatetime	Procedure.extension:incisionDateTime
authorDatetime	Procedure.extension:recorded	The concept “author” requires a reference to a report about the procedure or about an indication the procedure was not performed. Therefore, the procedure resource does not have a reference to author dateTime. Author dateTime can reference a report about the procedure or an observation describing that result (e.g., Observation with metadata Observation.partOf procedure). However, Procedure.statusReason needs to address a dateTime that it is recorded.
	Procedure.usedReference	To add reference to a device, medication, or substance used as part of an intervention the QI-Core element to address the device is Procedure.usedReference
components	N/A	Procedure does not include components and the concept of components references a observation that is a result of the procedure (Observation.partOf) for which that observation has components consistent with the Observation component modeling recommendation in FHIR.
component.code	N/A	N/A
component.result	N/A	N/A
performer	Procedure.performer.actor

Negation Rationale for Intervention, Performed

Use QICoreProcedureNotDone, which contains:

• Procedure.status - Fixed value: “not-done”
• Procedure.statusReason - Use value set NegationReasonCodes
• Procedure.extension:recorded - dateTime when this was made available
• Procedure.code.extension:notDoneValueSet - Use qicore-notDoneValueSet to indicate the specific Procedure that was not performed

Intervention, Order

QDM Context	QI-Core R5	Comments
Intervention, Order	ServiceRequest
	ServiceRequest.status	Constrain to active, completed
	ServiceRequest.intent	Constrain only to “order” (include children: original-order, reflex-order, filler-order, instance-order)
QDM Attributes
code	ServiceRequest.code
id	ServiceRequest.id
reason	ServiceRequest.reasonCode
authorDatetime	ServiceRequest.authoredOn	When the request transitioned to being actionable.
negationRationale	See Below
requester	ServiceRequest.requester

Negation Rationale for Intervention, Order

Use QICoreServiceNotRequested, which contains:

• ServiceRequest.doNotPerform - Fixed value: “true”
• ServiceRequest.status - Fixed value: “completed”
• ServiceRequest.extension:reasonRefused - Use value set NegationReasonCodes
• ServiceRequest.authoredOn - dateTime when this was made available
• ServiceRequest.code.extension:notDoneValueSet - Use qicore-notDoneValueSet to indicate the specific ServiceRequest that was not performed

Intervention, Recommended

QDM Context	QI-Core R5	Comments
Intervention, Recommended	ServiceRequest
	ServiceRequest.status	Constrain to active, completed
	ServiceRequest.intent	Constrain only to “plan”
QDM Attributes
code	ServiceRequest.code
id	ServiceRequest.id
reason	ServiceRequest.reasonCode
authorDatetime	ServiceRequest.authoredOn	When the request transitioned to being actionable.
negationRationale	See Below
requester	ServiceRequest.requester

Negation Rationale for Intervention, Recommended

Use QICoreServiceNotRequested, which contains:

• ServiceRequest.doNotPerform - Fixed value: “true”
• ServiceRequest.status - Fixed value: “completed”
• ServiceRequest.extension:reasonRefused - Use value set NegationReasonCodes
• ServiceRequest.authoredOn - dateTime when this was made available
• ServiceRequest.code.extension:notDoneValueSet - Use qicore-notDoneValueSet to indicate the specific ServiceRequest that was not performed

Laboratory Test

QDM defines Laboratory Test as a medical procedure that involves testing a sample of blood, urine, or other body fluids or specimens. Tests can help determine a diagnosis, plan treatment, check to see if treatment is working, or monitor the disease over time. This QDM data category for Laboratory Test is only used for information about the subject of record.

Rather than directly referencing the US Core Laboratory Result Observation Profile, QI-Core 5.0.0 builds on that profile to add further constraint requirements as QICore Laboratory Result Observation. The reason for this approach is to assure Must Support elements for the interpretation element, specific result datatypes, and specific references.

Thus far, consensus opinion suggests that the US Core Observation-Lab Profile best fits the laboratory test use case for querying clinical data to retrieve information about the event and/or the result of the study. Individual studies may use the US Core DiagnosticReport-lab to provide information about an individual laboratory test although some have considered use of other reporting resources and artifacts. Each laboratory test may be ordered individually or in a panel. Many use panels for convenience for ordering laboratory tests. Since new laboratory panels regularly become available and the myriad of potential laboratory panels available, a complete list cannot be assured. Therefore, a quality measure or clinical decision support (CDS) artifacts seeking a specific result value should use the US Core Observation-Lab profile to request a retrieve of the result value desired. This practice will enable implementers to determine which is the best source for the desired observation. LOINC observable entities may indicate specific methods for determination of results. Measure and CDS developers can reference direct reference codes or value sets using the such LOINC codes to specify the type of testing considered acceptable to provide sufficient fidelity to their requests.

Laboratory Test, Order

“Laboratory Test, Order” should reference orders for studies that will generate results for activities that meet criteria for Observation Lab Result.

QDM Context	QI-Core R5	Comments
Laboratory Test, Order	ServiceRequest
	ServiceRequest.status	Constrain to active, completed
	ServiceRequest.intent	Constrain only to “order” (include children: original-order, reflex-order, filler-order, instance-order)
QDM Attributes
code	ServiceRequest.code
id	ServiceRequest.id
reason	ServiceRequest.reasonCode
authorDatetime	ServiceRequest.authoredOn	When the request transitioned to being actionable.
negationRationale	See Below
requester	ServiceRequest.requester

Negation Rationale for Laboratory Test, Order

Use QICoreServiceNotRequested, which contains:

• ServiceRequest.doNotPerform - Fixed value: “true”
• ServiceRequest.status - Fixed value: “completed”
• ServiceRequest.extension:reasonRefused - Use value set NegationReasonCodes
• ServiceRequest.authoredOn - dateTime when this was made available
• ServiceRequest.code.extension:notDoneValueSet - Use qicore-notDoneValueSet to indicate the specific ServiceRequest that was not performed

Laboratory Test, Performed

QDM Context	QI Core R5	Comments
Laboratory Test, Performed	Laboratory Result Observation
	Observation.status	Constrain status to -  final, amended, corrected
QDM Attribute
code	Observation.code
id	Observation.id
method	Observation.method
	Observation.bodySite
negationRationale	See Below
reason	Observation.basedOn	Allows reference to QICore CarePlan, QICore DeviceRequest, QICore ImmunizationRecommendation, QICore MedicationRequest, QICore NutritionOrder, QICore ServiceRequest
result	Observation.value[x]
interpretation	Observation.interpretation	New in QDM 5.6
	Observation.specimen
relatedTo	Observation.partOf	Allows reference to QICore MedicationAdministration, QICore MedicationDispense, QICore MedicationStatement, QICore Procedure, QICore Immunization, QICore ImagingStudy
resultDatetime	Observation.issued
relevantDatetime	Observation.effective[x]
relevantPeriod	Observation.effective[x]
status	Observation.status	Constrain status to -  final, amended, corrected
authorDatetime	Observation.issued	Issued - the date and time this version of the observation was made available to providers, typically after the results have been reviewed and verified. The .issued element also addresses the time for capture of dataAbsentReason.
referenceRangeHigh	Observation.referenceRange.high
referenceRangeLow	Observation.referenceRange.low
component	Observation.component
	Observation.component.id
component.code	Observation.component.code
component.result	Observation.component.value[x]
	Observation.component.interpretation
	Observation.component.dataAbsentReason
component.referenceRangeHigh	Observation.component.referenceRange
component.referenceRangeLow	Observation.component.referenceRange
performer	Observation.performer

Negation Rationale for Laboratory Test, Performed

Use QICoreObservationCancelled, which contains:

• Observation.status - Fixed value: “cancelled”
• Observation.extension:notDoneReason - Use value set NegationReasonCodes
• Observation.issued - dateTime when this was made available
• Observation.code.extension:notDoneValueSet - Use qicore-notDoneValueSet to indicate the specific Observation that was not performed

Laboratory Test, Recommended

QDM Context	QI-Core R5	Comments
Laboratory Test, Recommended	ServiceRequest
	ServiceRequest.status	Constrain to active, completed
	ServiceRequest.intent	Constrain only to “plan”
QDM Attributes
code	ServiceRequest.code
id	ServiceRequest.id
reason	ServiceRequest.reasonCode
authorDatetime	ServiceRequest.authoredOn	When the request transitioned to being actionable.
negationRationale	See Below
requester	ServiceRequest.requester

Negation Rationale for Laboratory Test, Recommended

Use QICoreServiceNotRequested, which contains:

• ServiceRequest.doNotPerform - Fixed value: “true”
• ServiceRequest.status - Fixed value: “completed”
• ServiceRequest.extension:reasonRefused - Use value set NegationReasonCodes
• ServiceRequest.authoredOn - dateTime when this was made available
• ServiceRequest.code.extension:notDoneValueSet - Use qicore-notDoneValueSet to indicate the specific ServiceRequest that was not performed

Medication

QDM defines Medication as clinical drugs or chemical substances intended for use in the medical diagnosis, cure, treatment, or prevention of disease. Medications are defined as direct referenced values or value sets containing values derived from code systems such as RxNorm. QDM defines five contexts for Medication, each of which is listed below referencing the US Core or FHIR resource which provides the expected context:

Medication, Active

This QDM context correlates with a medication on a patient’s active medication list. In QI-Core STU3, Medication, Active was mapped to MedicationStatement. However, consistent with US Core R4 Update, medication list should use MedicationRequest and not MedicationStatement. The mapping table provides guidance about how to use MedicationRequest.requester to specify medications ordered directly, those reported by a physician and those reported by the patient for a medication list.

The MedicationRequest SHALL include all prescribed and “self-prescribed” medications reported by the Provider, Patient or Related Person.

• SHALL use reported[x] to indicate the MedicationRequest record was captured as a secondary “reported” record rather than an original primary source-of-truth record. It may also indicate the source of the report
• When recording “self-prescribed” medications SHALL use intent = “plan”
• When recording “self-prescribed” orders, SHOULD use the requester to indicate the Patient or RelatedPerson as the prescriber

QDM Context	QI-Core R5	Comments
Medication, Active	MedicationRequest
	MedicationRequest.status	Constrain to “active”
	MedicationRequest.intent	When recording “self-prescribed” medications SHALL use intent = “plan” for prescribed use intent = “order”
	MedicationRequest.reported[x]	When recording “self-prescribed” medications SHALL use reported[x] to indicate the MedicationRequest record was captured as a secondary “reported” record rather than an original primary source-of-truth record
	MedicationRequest.category	inpatient, outpatient, community, patient-specified
QDM Attribute
code	MedicationRequest.medication[x]
id	MedicationRequest.id
dosage	MedicationRequest.dosageInstruction.doseAndRate.dose[x]	Amount of medication per dose
frequency	MedicationRequest.dosageInstruction.timing
route	MedicationRequest.dosageInstruction.route
	MedicationRequest.reasonCode
relevantDatetime	MedicationRequest.dosageInstruction.timing with Timing.event dateTime
relevantPeriod	MedicationRequest.dosageInstruction.timing with Timing.repeat.bounds[x] Period
	MedicationRequest.authoredOn	Author dateTime not referenced in QDM
recorder	MedicationRequest.requester	To address all medications on a medication list, use MedicationRequest with status = active; intent = order; and requester = organization (for prescribed medications for which an order exists), requester = practitioner (for medications entered by clinicians but not ordered), and intent = plan and requester = patient or RelatedPerson (for patient/related person reported)

Medication, Administered

This QDM context correlates with a record of a patient consuming or otherwise being administered a medication. It references individual medication administration events and, therefore, may not reference frequency of administration. Note that a separate QDM and US Core profile address Immunization, Administered.

QDM Context	QI-Core R5	Comments
Medication, Administered	MedicationAdministration
	MedicationAdministration.status	Constrain status to “In-progress” or “completed” Note: Measures that look for evidence of potential adverse events might use MedicationAdministration.status = on-hold, or stopped as possible indicators of such events.
	MedicationAdministration.category	Allows specification of Inpatient, Outpatient, Community
QDM Attributes
code	MedicationAdministration.medication[x]	ֵ Example uses SNOMED substance codes
id	MedicationAdministration.id
dosage	MedicationAdministration.dosage.dose	Simple Quantity - Amount of medication for one administration
route	MedicationAdministration.dosage.route
frequency	MedicationAdministration.request	Reference to original MedicationRequest with content about prescription
	MedicationAdministration.dosage.rate[x]	Identifies the speed with which the medication was or will be introduced into the patient (e.g., infusion rate).
	MedicationRequest.dosageInstruction.timing	Timing schedule (e.g., every 8 hours). MedicationAdministration.request provides reference to the applicable MedicationRequest for this information.
reason	MedicationAdministration.reasonCode	None, given as ordered, emergency
relevant dateTime	MedicationAdministration.effective[x] dateTime
relevant Period	MedicationAdministration.effective[x] Period
author dateTime	MedicationAdministration.extension:recorded
Negation Rationale	See Below
Performer	MedicationAdministration.performer.actor

Negation Rationale for Medication, Administered

Use QICoreMedicationAdministrationNotDone, which contains:

• MedicationAdministration.status - Fixed value: “not-done”
• MedicationAdministration.statusReason - Use value set NegationReasonCodes
• MedicationAdministration.extension:recorded - dateTime when this was made available
• MedicationAdministration.medication[x].extension:notDoneValueSet - Use qicore-notDoneValueSet to indicate the specific MedicationAdministration that was not performed

Medication, Discharge

This QDM context specifically references the discharge medication list provided to a patient at the time of discharge from an inpatient setting. The list may include reference to new prescriptions sent to a pharmacy for dispensing and self-administration after discharge. It may also include over-the-counter medications and those medications already present in the patient’s home for which new prescriptions are not necessary.  The QDM Medication, Discharge concept is mapped to MedicationRequest as a request to the patient to take the medication with MedicationRequest.intent = plan and MedicationRequest.setting = discharge.

MedicationRequest.intent should always be order even if the medication is patient reported and the order is not processed as an e-prescription. The reporter is specified as MedicationRequest.reported[x] which is a reportedBoolean and uses reportedReference (patient, practitioner, practitionerRole, relatedPerson, organization).

This change should also be used to reference the mapping from QDM Medication, Order which can address order or recommended.

QDM Context	QI-Core R5	Comments
Medication, Discharge	MedicationRequest
Medication, Discharge active	MedicationRequest.status	Constrain to “active”
	MedicationRequest.statusReason
QDM Attributes
code	MedicationRequest.medication[x]	RxNorm
id	MedicationRequest.id
dosage	MedicationRequest.dosageInstruction.doseAndRate.dose[x]	Range, quantity
supply	MedicationRequest.dispenseRequest.quantity	Amount to be dispensed in one fill
daysSupplied	MedicationRequest.dispenseRequest.expectedSupplyDuration	Duration
frequency	MedicationRequest.dosageInstruction.timing	Timing schedule (e.g., every 8 hours)
refills	MedicationRequest.dispenseRequest.numberOfRepeatsAllowed	Integer
route	MedicationRequest.dosageInstruction.route
setting	MedicationRequest.category	Constrain category to “Community”
reason	MedicationRequest.reasonCode	The reason for ordering or not ordering the medication
relevantDatetime	MedicationRequest.dosageInstruction.timing with Timing.event dateTime
relevantPeriod	MedicationRequest.dosageInstruction.timing with Timing.repeat.bounds[x] Period
authorDatetime	MedicationRequest.authoredOn
negationRationale	See Below
prescriber	MedicationRequest.requester	Note - MedicationRequest.performer indicates the performer expected to administer the medication

Negation Rationale for Medication, Discharge

Use QICoreMedicationNotRequested, which contains:

• MedicationRequest.doNotPerform - Fixed value: “true”
• MedicationRequest.status - Fixed value: “completed”
• MedicationRequest.reasonCode - Use value set NegationReasonCodes
• MedicationRequest.authoredOn - dateTime when this was made available
• MedicationRequest.medication[x].extension:notDoneValueSet - Use qicore-notDoneValueSet to indicate the specific MedicationRequest that was not performed

Medication, Dispensed

This QDM context maps to the QI-Core MedicationDispense resource, indicating information about medications that have been dispensed.

QDM Context	QI-Core R5	Comments
Medication, Dispensed	MedicationDispense
	MedicationDispense.status	Constrain MedicationDispense.status to completed
QDM Attributes
code	MedicationDispense.medication[x]
id	MedicationDispense.id
dosage	MedicationDispense.dosageInstruction	ordered, calculated
supply	MedicationDispense.quantity
daysSupplied	MedicationDispense.daysSupply
frequency	MedicationDispense.dosageInstruction.timing	See dosageInstruction
refills	MedicationDispense.authorizingPrescription	Reference authorizing prescription (MedicationRequest) which contains Medication.Request.dispsenseRequest.numberOfRepeatsAllowed
	MedicationRequest.dispenseRequest.numberOfRepeatsAllowed	Timing schedule (e.g., every 8 hours). MedicationDispense.authorizingPrescription provides reference to the applicable MedicationRequest for this information.
route	MedicationDispense.dosageInstruction.route	See dosageInstruction
setting	MedicationDispense.category	Inpatient, Outpatient, Community, Discharge
reason	MedicationDispense.statusReason[x]	The reason for ordering or not ordering the medication
relatedTo	MedicationDispense.authorizingPrescription	New in QDM 5.6
relevant dateTime	MedicationDispense.whenHandedOver	When provided to patient or representative. Recommendations from pharmacy experts suggest that all medication dispensing events include a time for MedicationDispense.whenPrepared (i.e., when the dispensed product was packaged and reviewed. The time the medication was handed over to the patient or representative may not be populated. Note that medications not picked up are restocked such that a MedicationDispense.status = completed will assure the patient or representative received the medication even if whenHandedOver is not available. Therefore, measure developers should consider including the time whenPrepared if whenHandedOver is null and status = completed.
relevant Period	MedicationRequest.dosageInstruction.timing with Timing.repeat.bounds[x] Period	The anticipated time from starting to stopping an ordered or dispensed medication can also be computed in an expression and derived from the duration attribute
author dateTime	MedicationDispense.extension:recorded
Negation Rationale	See Below
Prescriber	MedicationDispense.authorizingPrescription	Reference authorizing prescription (MedicationRequest) which contains Medication.Request.requester
	MedicationRequest.requester
dispenser	MedicationDispense.performer.actor

Negation Rationale for Medication, Dispensed

Use QICoreMedicationDispenseDeclined, which contains:

• MedicationDispense.status - Fixed value: “declined”
• MedicationDispense.statusReason[x] - Use value set NegationReasonCodes
• MedicationDispense.extension:recorded - dateTime when this was made available
• MedicationDispense.medication[x].extension:notDoneValueSet - Use qicore-notDoneValueSet to indicate the specific MedicationDispense that was not performed

The MedicationDispensed.status is fixed to “declined” which is defined as “The dispense was declined and not performed.” Considering the clinical workflow, only the pharmacist likely performs the “decline” status - based on medication interaction or on failure of insurance authorization (perhaps due to patient declining when the cost/co-pay is identified). But the patient would not enter the status, only the pharmacist would do so. The use case likely still works for the measure developer intent (that a valid reason exists for not dispensing the medication). However, if the measure developer wants to address patient’s decisions to avoid dispensing, the patient will likely not show up at the pharmacy for the medication to be dispensed - hence, there will be no dispensing event. The best way to capture that scenario may be to assure the MedicationRequest includes a Patient reason.

Medication, Order

This QDM context references the QI-Core MedicationRequest resource with MedicationRequest.intent = order and MedicationRequest.setting as the most appropriate for the intended meaning of the quality measure or clinical decision support (CDS) expression.

QDM Context	QI-Core R5	Comments
Medication, Order	MedicationRequest
Medication, Order active	MedicationRequest.status	Constrain to active, completed
	MedicationRequest.statusReason
	MedicationRequest.intent	When recording “self-prescribed” medications SHALL use intent = “plan” for prescribed use intent = “order”
	MedicationRequest.reported[x]	When recording “self-prescribed” medications SHALL use reported[x] to indicate the MedicationRequest record was captured as a secondary “reported” record rather than an original primary source-of-truth record
QDM Attributes
code	MedicationRequest.medication[x]	RxNorm
id	MedicationRequest.id
dosage	MedicationRequest.dosageInstruction.doseAndRate.dose[x]	Range, quantity
supply	MedicationRequest.dispenseRequest.quantity	Amount to be dispensed in one fill
daysSupplied	MedicationRequest.dispenseRequest.expectedSupplyDuration	Duration
frequency	MedicationRequest.dosageInstruction.timing	Timing schedule (e.g., every 8 hours)
refills	MedicationRequest.dispenseRequest.numberOfRepeatsAllowed	Integer
route	MedicationRequest.dosageInstruction.route
setting	MedicationRequest.category	Constrain category to: Inpatient, Outpatient, Community
reason	MedicationRequest.reasonCode	The reason for ordering or not ordering the medication
relatedTo	MedicationRequest.basedOn	New in QDM 5.6
relevantDatetime	MedicationRequest.dosageInstruction.timing with Timing.event dateTime
relevantPeriod	MedicationRequest.dosageInstruction.timing with Timing.repeat.bounds[x] Period	The anticipated time from starting to stopping an ordered or dispensed medication can also be computed in an expression and derived from the duration attribute
authorDatetime	MedicationRequest.authoredOn
negationRationale	See Below
prescriber	MedicationRequest.requester	Note – The prescriber is the MedicationRequest.requester and not the MedicationRequest.performer which indicates the performer expected to administer the medication

Negation Rationale for Medication, Order

Use QICoreMedicationNotRequested, which contains:

• MedicationRequest.doNotPerform - Fixed value: “true”
• MedicationRequest.status - Fixed value: “completed”
• MedicationRequest.reasonCode - Use value set NegationReasonCodes
• MedicationRequest.authoredOn - dateTime when this was made available
• MedicationRequest.medication[x].extension:notDoneValueSet - Use qicore-notDoneValueSet to indicate the specific MedicationRequest that was not performed

Participation

QDM defines Participation as a patient’s coverage by a program such as an insurance or medical plan or a payment agreement. Such programs can include patient-centered medical home, disease-specific programs, etc. Definitions modeled similar to the FHIR R4 Coverage resource.

QDM Context	QI-Core R5	Comments
Participation	Coverage
	Coverage.status	Constrain to “active”
QDM Attributes
code	Coverage.type
id	Coverage.id
participationPeriod	Coverage.period

Physical Exam

QDM defines Physical Exam as the evaluation of the patient’s body and/or mental status exam to determine its state of health. The techniques of examination can include palpation (feeling with the hands or fingers), percussion (tapping with the fingers), auscultation (listening), visual inspection or observation, inquisition and smell. Measurements may include vital signs (blood pressure, pulse, respiration) as well as other clinical measures (such as expiratory flow rate and size of lesion). Physical exam includes psychiatric examinations.

US Core STU5 added twelve observation profiles that address specific elements of physical examinations. The previous version inherited the FHIR Vital Signs Profile; in version STU5, US Core created specific profiles for each of those vital sign elements, resulting in a Vital Signs Profile with 12 component profiles that meet the definition of QDM “Physical Examination”. The following table lists each profile and the respective data element codes referenced in each of those profiles.

Profile	Data element codes
US Core Vital Signs Profile	Vital Signs (panel) – Fixed Value: 85353-1
US Core Pediatric Head Occipital-frontal Circumference Percentile Profile	Head Occipital-Frontal Circumference Percentile - Fixed Value: 8289-1
US Core Blood Pressure Profile	•Blood Pressure Systolic and Diastolic – Fixed Value: 85354-9 •Systolic Blood Pressure – Fixed Value: 8480-6 •Diastolic Blood Pressure – Fixed Value: 8462-4 •valueQuantity - Fixed Value: mm[Hg]
US Core BMI Profile	•ValueQuantity.system - Fixed Value: http://unitsofmeasure.org •ValueQuantity.code - Coded responses from the common UCUM units for vital signs value set - Fixed Value: kg/m2
US Core Body Height Profile	•Body Height – Fixed Value: 8302-2 •ValueQuantity.system - Fixed Value: http://unitsofmeasure.org •ValueQuantity.code - - Coded responses from the common UCUM units for vital signs value set - Binding: BodyLengthUnits (required)
US Core Body Temperature Profile	•Body Temperature – Fixed Value: 8310-5 •ValueQuantity.system - Fixed Value: http://unitsofmeasure.org •ValueQuantity.code - - Coded responses from the common UCUM units for vital signs value set – Binding: BodyTemperatureUnits (required)
US Core Body Weight Profile	•Body Weight – Fixed Value: 29463-7 •ValueQuantity.system - Fixed Value: http://unitsofmeasure.org •ValueQuantity.code – Coded responses from the common UCUM units for vital signs value set – Binding: BodyWeightUnits (required)
US Core Head Circumference Profile	•Head Circumference – Fixed Value: 9843-4 •ValueQuantity.system - Fixed Value: http://unitsofmeasure.org •ValueQuantity.code - Coded responses from the common UCUM units for vital signs value set - Binding: BodyLengthUnits (required)
US Core Heart Rate Profile	•Vital Signs – Heart Rate – Fixed Value: 8867-4 •ValueQuantity.system - Fixed Value: http://unitsofmeasure.org •ValueQuantity.code - Fixed Value: /min
US Core Pediatric BMI for Age Observation Profile	•Pediatric BMI for Age – Fixed Value: 59576-9 •ValueQuantity.system - Fixed Value: http://unitsofmeasure.org
US Core Pediatric Weight for Height Observation Profile	•Pediatric Weight for Height – Fixed Value: 77606-2 •ValueQuantity.system - Fixed Value: http://unitsofmeasure.org •ValueQuantity.code - Coded responses from the common UCUM units for vital signs value set. Fixed Value: %
US Core Pulse Oximetry Profile	•Pulse Oximetry – Fixed Value: 59408-5 •O2 Saturation - Fixed Value: 2708-6 •Flow rate Fixed Value: 2708-6 •Flow rate Value quantity Fixed Value: L/min •Concentration Fixed Value: 3150-0 •ValueQuantity.system - Fixed Value: http://unitsofmeasure.org •ValueQuantity.code – Fixed Value: %
US Core Respiratory Rate Profile	•Vital Signs – Respiratory Rate – Fixed Value: 9279-1 •ValueQuantity.system - Fixed Value: http://unitsofmeasure.org •ValueQuantity.code - Coded responses from the common UCUM units for vital signs value set - Fixed Value: /min

Physical Exam, Order

QDM “Physical Exam, Order” should use ServiceRequest with intent = order for the specific examination requested.

QDM Context	QI-Core R5	Comments
Physical Exam, Order	ServiceRequest
	ServiceRequest.status	Constrain to active, completed
	ServiceRequest.intent	Constrain only to “order” (include children: original-order, reflex-order, filler-order, instance-order)
QDM Attributes
code	ServiceRequest.code
id	ServiceRequest.id
reason	ServiceRequest.reasonCode
authorDatetime	ServiceRequest.authoredOn	When the request transitioned to being actionable.
anatomicalLocationSite	ServiceRequest.bodySite
negationRationale	See Below
requester	ServiceRequest.requester

Negation Rationale for Physical Exam, Order

Use QICoreServiceNotRequested, which contains:

• ServiceRequest.doNotPerform - Fixed value: “true”
• ServiceRequest.status - Fixed value: “completed”
• ServiceRequest.extension:reasonRefused - Use value set NegationReasonCodes
• ServiceRequest.authoredOn - dateTime when this was made available
• ServiceRequest.code.extension:notDoneValueSet - Use qicore-notDoneValueSet to indicate the specific ServiceRequest that was not performed

Physical Exam, Performed

QDM “Physical Exam, Performed” should reference the specific US Core vital signs profiles directly as appropriate. Some results may also be identified using the QICore Observation Clinical Test Result profile. The QI-Core generic Observation profile may be appropriate for other physical examination observations not covered by the Observation Clinical Test Result profile.

QDM Context	QI-Core R5	Comments
Physical Exam, Performed - General	Observation
	Observation.status	Constrain status to -  final, amended, corrected
	Observation.category	Constrain to “exam” [Observations generated by physical exam findings including direct observations made by a clinician and use of simple instruments and the result of simple maneuvers performed directly on the patient’s body.]
QDM Attributes
code	Observation.code
id	Observation.id
anatomicalLocationSite	Observation.bodySite
relatedTo	Observation.basedOn	A plan, proposal or order that is fulfilled in whole or in part by this event. For example, a MedicationRequest may require a patient to have laboratory test performed before it is dispensed. New in QDM 5.6
	Observation.partOf	Reference a MedicationAdministration, MedicationDispense, MedicationStatement, Procedure, Immunization, or ImagingStudy during which this physical examination is performed as part of a larger activity.
negationRationale	See Below
reason	Observation.basedOn	Reference a CarePlan, DeviceRequest, ImmunizationRecommendation, MedicationRequest, NutritionOrder, or ServiceRequest that is the reason for this physical examination
result	Observation.value[x]
	Observation.interpretation
relevantDatetime	Observation.effective[x] dateTime
relevantPeriod	Observation.effective[x] Period
authorDatetime	Observation.issued
component	Observation.component
	Observation.component.id
component.code	Observation.component.code
component.result	Observation.component.value[x]
	Observation.component.interpretation
	Observation.component.dataAbsentReason
performer	Observation.performer

Negation Rationale for Physical Exam, Performed

Use QICoreObservationCancelled, which contains:

• Observation.status - Fixed value: “cancelled”
• Observation.extension:notDoneReason - Use value set NegationReasonCodes
• Observation.issued - dateTime when this was made available
• Observation.code.extension:notDoneValueSet - Use qicore-notDoneValueSet to indicate the specific Observation that was not performed

Physical Exam, Recommended

QDM “Physical Exam, Recommended” should use ServiceRequest with intent = plan for the specific examination recommended.

QDM Context	QI-Core R5	Comments
Physical Exam, Recommended	ServiceRequest
	ServiceRequest.status	Constrain to active, completed
	ServiceRequest.intent	Constrain only to “plan”
QDM Attributes
code	ServiceRequest.code
id	ServiceRequest.id
reason	ServiceRequest.reasonCode
authorDatetime	ServiceRequest.authoredOn	When the request transitioned to being actionable.
anatomicalLocationSite	ServiceRequest.bodySite
negationRationale	See Below
requester	ServiceRequest.requester

Negation Rationale for Physical Exam, Recommended

Use QICoreServiceNotRequested, which contains:

• ServiceRequest.doNotPerform - Fixed value: “true”
• ServiceRequest.status - Fixed value: “completed”
• ServiceRequest.extension:reasonRefused - Use value set NegationReasonCodes
• ServiceRequest.authoredOn - dateTime when this was made available
• ServiceRequest.code.extension:notDoneValueSet - Use qicore-notDoneValueSet to indicate the specific ServiceRequest that was not performed

Procedure

QDM defines Procedure as an act whose immediate and primary outcome (post-condition) is the alteration of the physical condition of the subject. A procedure may be a surgery or other type of physical manipulation of a person’s body in whole or in part for purposes of making observations and diagnoses or providing treatment.

Procedure Vs Intervention

FHIR references both of these concepts using the Procedure resource, specifically noting a process that involves verification of the patient’s comprehension or to change the patient’s mental state would be a Procedure.

Procedure Vs Task

Some use cases have considered differentiating a FHIR Procedure Resource from a FHIR core Task Resource. For example, should a request to perform medication reconciliation be classified as a Task or a Procedure? The FHIR Procedure Resource Boundaries and Relationships (Section 9.3.2) provides some distinction between a Task and a Procedure:

A Task is a workflow step such as cancelling an order, fulfilling an order, signing an order, merging a set of records, admitting a patient. Procedures are actions that are intended to result in a physical or mental change to or for the subject (e.g. surgery, physiotherapy, training, counseling). A Task resource often exists in parallel with clinical resources. For example, a Task might request fulfillment of a ServiceRequest ordering a Procedure.

Based on the guidance provided above, the workflow step to reconcile medication lists may be considered a Task to perform the Procedure that includes reviewing the medication list with the patient to assure it is correct and to education the patient about proper medication usage.

The sponsoring work group is specifically seeking feedback on the following suggestions for use of Task rather than Procedure for workflow steps that require attestation such as medication list review or reconciliation: Example: A workflow step to review or to reconcile medication lists may be considered a Task to perform the Procedure that includes reviewing the medication list with the patient to assure it is correct and to educate the patient about proper medication usage. Thus, a Task can reference the Task.focus as a procedure.

QDM 5.6 does not address Task; therefore, there is no direct mapping from QDM Intervention or Procedure to the FHIR Task resource.  The mapping presented is from QDM to QI-Core referencing the FHIR Procedure resource.

Consistent with the method for specifying QDM’s concept negation rationale, a TaskRejected is represented with the following content:

• Task.status with valueset-task-status constrained to “rejected” (The potential performer who claimed ownership of the task has decided not to execute it prior to performing any action.)
• Task.statusReason binding to Negation Reason Codes (extensible)
• Task.code (Codes to identify how the task manages fulfillment of activities - the specific choice depends on the measure context) the direct reference code, it needs a cardinality of 1..1 and binding to the code or value set (it would need a notDoneValueSet URL: notDoneValueSet to reference the value set not performed
• Task.focus to reference the Resource (likely procedure) the task was acting on
• Task.encounter (Healthcare event during which this task originated)
• Task.for (Beneficiary of the Task) Reference (qicore-patient)
• Task.executionPeriod for the period/dateTime - the timing the task was rejected and the reason.

Procedure Priority

QDM 5.6 includes a new attribute for Procedure: priority with the following definition:

Priority indicates the urgency of the procedure or the encounter referenced. In [electronic clinical quality measures] (eCQMs) the priority attribute will help specify elective from urgent encounters (e.g., hospital admissions) or procedures. Priority is a codeable concept (i.e., may use a direct reference code or a value set). For example, priority is used to express an elective procedure or encounter from an emergency procedure or encounter.

As noted in the QDM to QI-Core Mapping for Encounter-Related Diagnoses and Procedures, a specific measure may have interest in evaluating care provided for elective procedures (e.g., hip surgery due to osteoarthritis) while excluding emergency, non-planned procedures (e.g., hip surgery due to acute fracture). The procedure code does not necessarily allow differentiation of the two concepts. A ServiceRequest.priority does have the ability to differentiate the urgency with which the request (or order) should be fulfilled. However, there is no element within the FHIR Procedure resource to address the issue. Encounter.priority allows specification of whether the encounter is elective. An encounter with Encounter.priority = elective and an Encounter.diagnosis.rank = 1 addresses the need to specify an elective encounter with a principal procedure. Therefore, based on the current use case QI-Core has not added an extension to address Procedure.priority and, as a result, there is no direct mapping from the QDM Procedure priority attribute to QI-Core.

Procedure, Performed

QDM Context	QI-Core R5	Comments
Procedure, Performed	Procedure
	Procedure.category	Helps differentiate “intervention” from “procedure”
QDM Attributes
status	Procedure.status	constrain to “completed”
code	Procedure.code
id	Procedure.id
relatedTo	Procedure.basedOn	A reference to a resource that contains details of the request for this procedure. New in QDM 5.6
method	N/A	Procedure.method does not exist in FHIR. Rather than create an extension, QI-Core’s approach is to assume the Procedure.code includes reference to the method.
rank	Encounter.diagnosis.rank	Referenced as the principal or non-principal diagnosis of the Encounter.
priority	Encounter.reasonReference.procedure	This QDM attribute is intended to reference elective from non-elective procedures. QI-Core references procedure.priority based on the relationship of the procedure to the Encounter; hence, Encounter.reasonReference.procedure (which is a reference to the procedure). The elective nature of a procedure can also be referenced based on the elective nature of an Encounter (Encounter.priority) for which the respective procedure is a principal procedure. The concept may also be addressed as an Encounter, Order or Procedure, Order (both using ServiceRequest) and ServiceRequest.priority.
anatomicalLocationSite	Procedure.bodySite
reason	Procedure.reasonCode
result	Observation that includes the element Observation.partOf to reference the procedure to which it applies.	Procedure.report references DiagnosticReport-note, DocumentReference, Composition (histology result, pathology report, surgical report, etc.); the latter two are not QI-Core resources. However, based on feedback regarding the use of the Observation resource, a procedure result might be better referenced as an Observation that includes the element Observation.partOf to reference the procedure to which it applies.
	Observation.partOf	Reference to a resource that contains details of the request for this procedure.
Negation Rationale	See Below
Relevant dateTime	Procedure.performed[x] dateTime
Relevant Period	Procedure.performed[x] Period
Incision dateTime	Procedure.extension:incisionDateTime
Author dateTime	Procedure.extension:recorded	The concept “author” requires a reference to a report about the procedure or about an indication the procedure was not performed. Therefore, the procedure resource does not have a reference to author dateTime. Author dateTime can reference a report about the procedure or an observation describing that result (e.g., Observation with metadata Observation.partOf procedure). However, Procedure.statusReason needs to address a dateTime that it is recorded.
	Procedure.usedReference	To add reference to a device, medication, or substance used as part of a procedure the QI-Core element to address the device is Procedure.usedReference
Components	N/A	Procedure does not include components and the concept of components references a observation that is a result of the procedure (Observation.partOf) for which that observation has components consistent with the Observation component modeling recommendation in FHIR.
Component code	N/A	N/A
Component result	N/A	N/A
Performer	Procedure.performer.actor

Negation Rationale for Procedure, Performed

Use QICoreProcedureNotDone, which contains:

• Procedure.status - Fixed value: “not-done”
• Procedure.statusReason - Use value set NegationReasonCodes
• Procedure.extension:recorded - dateTime when this was made available
• Procedure.code.extension:notDoneValueSet - Use qicore-notDoneValueSet to indicate the specific Procedure that was not performed

Procedure, Order

QDM Context	QI-Core R5	Comments
Procedure, Order	ServiceRequest
	ServiceRequest.status	Constrain to one or more of active, completed
	ServiceRequest.intent	Constrain only to “order” (include children: original-order, reflex-order, filler-order, instance-order)
QDM Attributes
code	ServiceRequest.code
id	ServiceRequest.id
reason	ServiceRequest.reasonCode
authorDatetime	ServiceRequest.authoredOn	When the request transitioned to being actionable.
negationRationale	See Below
requester	ServiceRequest.requester

Negation Rationale for Procedure, Order

Use QICoreServiceNotRequested, which contains:

• ServiceRequest.doNotPerform - Fixed value: “true”
• ServiceRequest.status - Fixed value: “completed”
• ServiceRequest.extension:reasonRefused - Use value set NegationReasonCodes
• ServiceRequest.authoredOn - dateTime when this was made available
• ServiceRequest.code.extension:notDoneValueSet - Use qicore-notDoneValueSet to indicate the specific ServiceRequest that was not performed

Procedure, Recommended

QDM Context	QI-Core R5	Comments
Procedure, Recommended	ServiceRequest
	ServiceRequest.status	Constrain to one or more of active, completed
	ServiceRequest.intent	Constrain only to “plan”
QDM Attributes
code	ServiceRequest.code
id	ServiceRequest.id
reason	ServiceRequest.reasonCode
authorDateTime	ServiceRequest.authoredOn	When the request transitioned to being actionable.
negationRationale	See Below
requester	ServiceRequest.requester

Negation Rationale for Procedure, Recommended

Use QICoreServiceNotRequested, which contains:

• ServiceRequest.doNotPerform - Fixed value: “true”
• ServiceRequest.status - Fixed value: “completed”
• ServiceRequest.extension:reasonRefused - Use value set NegationReasonCodes
• ServiceRequest.authoredOn - dateTime when this was made available
• ServiceRequest.code.extension:notDoneValueSet - Use qicore-notDoneValueSet to indicate the specific ServiceRequest that was not performed

Substance

Substance, Administered; Substance, Order; Substance Recommended

QDM defines Substance as a homogeneous material with definite composition that includes allergens, biological materials, chemicals, foods, drugs and materials. QDM distinguishes between medications from non-medication substances by separately listing medication datatypes. Substance may or may not have a code or be classified by a code system such RxNorm. Examples of a substance may include environmental agents (e.g., pollen, dust) and food (e.g., vitamins). Where a substance can be addressed using medication terminology (e.g. egg albumin) used the Medication mappings listed in this QDM-to-QI-Core section.

FHIR defines substance as a homogeneous material with a definite composition. Medications are classified as substances. However, to reference other substances, especially using the SubstanceDefinition resource is challenging since the resource is still undergoing development.

Ideally, use of a substance-related resource should be driven by use cases and examples. Two such use cases currently exist in the quality measure community::

• Determination that blood products (a biological product in FHIR resources) are ordered or are administered within specific time relationships to other data elements – The FHIR Resource, BiologicallyDerivedProduct, possibly using Procedure and ServiceRequest might have promise. However, the resource is still in development. Therefore, until further information is available, rather than expressing the QDM datatype Substance, Administration to address administration of blood transfusion, quality measure and clinical decision support (CDS) authors should consider using the procedure resource with a code representing transfusion.
• Determination that human breast milk is used exclusively to feed newborn infants during the initial stay in the hospital after birth – Currently, FHIR includes a NutritionOrder resource to reference a request for a specific diet, or supplements to a diet. However, a resource for documenting administration of nutrition-related substances is still in development. Therefore, for this use case a quality measure or a clinical decision support (CDS) author could reference a NutritionOrder for an exclusive breast milk diet for the infant; however, such an expression could not reference clinical intake and output records to determine if anything other than human breast milk was administered to the infant. Moreover, classification of human breast milk requires clarification as to whether it is a BiologicallyDerivedProduct, or if it should be referenced as a Substance.

To provide some context and guidance, this QDM-to-QI-Core mapping includes reference to the QDM datatypes Substance, Order and Substance, Recommended using the NutritionOrder resource. As noted in the second example provided, the resource is relatively new and it allows expressions to address only the type of diet ordered, not the foods or substances administered to a patient.

The CQI Workgroup suggests use of the Procedure resource for QDM’s Substance, Administered for nutritional and other non-medication substances. Indicate the procedure (e.g., oral feeding) and the Procedure.UsedCode to indicate the direct reference code or value set indicating the expected nutritional element expected. There is no current known eCQM use case or common practice for documenting NutritionOrder “negation rationale”. Further, the only expressed use cases for substance other than those that are modeled similar to medications are nutritional substance administered (human breast milk) and biologically-derived product administration (blood) - both of these use cases can use the Procedure resources as noted. Further work in base FHIR will advise how to reference specific administration details in QI-Core.

QDM Context	QI-Core R5	Comments
Substance, Order/Recommended - For Diet Orders	NutritionOrder	Limited to orders for diets or diets with supplements
Substance Order/Recommended Activity	NutritionOrder.status	Constrain to active, completed
Substance, Order	NutritionOrder.intent	Constrain to “order” and child concepts
Substance, Recommended	NutritionOrder.intent	Constrain to “plan”
QDM Attributes
ORAL DIET	NutritionOrder.oralDiet
code (to represent a diet order)	NutritionOrder.oralDiet.type
	NutrientOrder.oralDiet.nutrient.modifier
id	NutritionOrder.id
dosage	N/A
frequency	NutritionOrder.Diet.schedule
negationRationale	N/A
authorDatetime	NutritionOrder.dateTime
relevantPeriod	N/A
reason	N/A
supply	N/A
refills	N/A
route	NutritionOrder.oralDiet
requester	NutritionOrder.orderer
ENTERAL FORMULA	NutritionOrder.enteralFormula
code (to represent a diet order)	NutritionOrder.enteralFormula.baseFormulaType
Additive to diet order	NutritionOrder.enteralFormula.additiveType
id	N/A
dosage	NutritionOrder.enterealFormula.administration.quantity
frequency	NutritionOrder.enteralFormula.administration.rate[x]
negationRationale	N/A
authorDatetime	NutritionOrder.dateTime
relevantPeriod	NutritionOrder.enteralFormula.administration.schedule
reason	N/A
supply	N/A
refills	NutritionOrder.enteralFormula
route	NutritionOrder.enteralFormula.routeofAdministration
requester	NutritionOrder.orderer

Symptom

QDM defines Symptom as an indication that a person has a condition or disease. Some examples include headache, fever, fatigue, nausea, vomiting, and pain. Symptoms are subjective manifestations of the disease perceived by the patient. As an example to differentiate symptom from finding, the patient’s subjective symptom of fever is distinguished from the temperature (a finding). For a finding, there is either a source of a temperature-measuring device together with a recorder of the device (electronically) or an individual (healthcare provider, patient, etc.).

Note: Definitions regarding symptom on the FHIR condition resource Boundaries and Relationships (Section 9.2.2: http://hl7.org/fhir/condition.html):

• [The Condition] resource is not typically used to record information about subjective and objective information that might lead to the recording of a Condition resource. Such signs and symptoms are typically captured using the Observation resource; although in some cases a persistent symptom, e.g. fever, headache may be captured as a condition before a definitive diagnosis can be discerned by a clinician. By contrast, headache may be captured as an Observation when it contributes to the establishment of a meningitis Condition.

• Use the Observation resource when a symptom is resolved without long term management, tracking, or when a symptom contributes to the establishment of a condition.

• Use Condition when a symptom requires long term management, tracking, or is used as a proxy for a diagnosis or problem that is not yet determined.

Based on the FHIR referenced provided above, the QDM datatype Symptom maps to the FHIR Observation resource.

QDM Context	QI-Core R5	Comments
Symptom	Observation
	Observation.status	restrict to preliminary, final, amended, corrected
	Observation.category	add symptom concept
QDM Attributes
code	Observation.value[x]	Use codable concept
id	Observation.id
severity	Observation.interpretation	Definition suggests high, low, normal - perhaps consider severe, moderate, mild.
prevalencePeriod	Observation.effective[x]	dateTime, period, timing, instant
recorder	Observation.performer