This page is part of the Quality Improvement Core Framework (v2.1.0: STU 3 Ballot 1) based on FHIR R3. The current version which supercedes this version is 4.1.1. For a full list of available versions, see the Directory of published versions

• QDM to QI Core Mapping
• Adverse Event
• AllergyIntolerance
• Assessment
• Care Experience
• Care Goal
• Communication
• Condition/Diagnosis/Problem
• Device
• Diagnostic Study
• Encounter
• Family History
• Immunization
• Individual Characteristic
• Intervention
• Laboratory Test
• Medication
• Participation
• Physical Exam
• Procedure
• Substance
• Symptom

7.0.0 QICore - QDM to QI Core Mapping

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 (5.3) and QDM's complete history can be found on the eCQI Resource Center. Most of the QDM concepts map directly to FHIR resources and extensions represented in QI Core.

This version of QI Core includes mappings from QI Core to QDM. 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 left-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.3 documentation.

7.1.0 Adverse Event

QDM defines Adverse Event as any untoward medical occurrence associated with the clinical care delivery, whether or not considered drug related.

QDM - Adverse Event

QDM Attribute	QI Core Metadata Element	Comments
Relevant Period	AdverseEvent.date	FHIR references a single point in time - not a Period in QI Core. Most likely the event will be recorded with a single point in time. QDM can reference the dateTime as the beginning of the Relevant Period but and endTime will not be available in QI Core or FHIR.
Author dateTime	part of FHIR Provenance Resource	FHIR references authorDatetime as part of the provenance resource for all resources.
code	AdverseEvent.suspectEntity.Instance	A QDM date element binds the Adverse Event datatype to a value set (or to a direct reference code) indicating the suspect entity that might have caused the event. The reason is the measures have mostly been focused on Adverse Event as an exclusion criterion. Thus the "code" attribute is most consistent with AdverseEvent.suspectEntity.instance rather than the type of reaction.
Type	AdverseEvent.reaction	The QDM "Type" attribute definition addresses a value set (or a direct referenced code) that describes the reaction. Hence the mapping of QDM "type" to AdverseEvent.reaction in QI Core. Example - anaphylactic reaction, hives, etc. Greater clarity in definition in QDM descriptions in the CQL-based HQMF and in the QDM publication should be helpful. In the future, QDM might consider adding the FHIR concept AdverseEvent.type (incident, near-miss, unsafe condition) and AdverseEvent.category (AE - adverse event Vs PAE - Potential Adverse Event)
Severity	AdverseEvent.seriousness	QDM matched to QI Core / FHIR
FacilityLocation	AdverseEvent.location	QDM matched to QI Core / FHIR
Recorder	AdverseEvent.recorder	QDM matched to QI Core / FHIR
id	AdverseEvent.id	QDM matched to QI Core / FHIR

7.2.0 Allergy Intolerance

QDM Definitions:

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 - Allergy/Intolerance

QDM Attribute	QI Core Metadata Element	Comments
Prevalence Period	AllergyIntolerance.onset[x]	QDM Prevalence Period addressed the onset dateTime and the abatement dateTime for an allergy. The options provided in QI Core / FHIR include (a) AllergyIntolerance.reaction.onset, (b) AllergyIntolerance.onset[x] (which allows a period), (c) AllergyIntolerance.reaction.allergyintoleranceduration (the time the allergyIntolerance persisted, and (d) allergyintolerance-resolutionAge (limited to age rather than dateTime). It seems that the QDM Prevalence Period start should map to AllergyIntolerance.onset[x] and the Prevalence Period end should map to allergyintolerance-resolutionAge, but the age is an extension (i.e., QI Core only) and implementers would potentially need to map an age to a year and default a month and day.
	allergyintolerance-resolutionAge
Author dateTime	AllergyIntolerance.assertedDate	The definition of AllergyIntolerance.assertedDate may not be a direct match to authorDatetime. Please advise if the definition in QI Core/FHIR is consistent with the authorDatetime reference in QDM and whether QDM requires greater clarity in definition (i.e., potentially change authorDatetime to Asserted dateTime).
Code (for substance)	AllergyIntolerance.code	The QDM "Type" attribute definition addresses a value set (or a direct referenced code) that describes the reaction. Hence the mapping of QDM "type" to AllergyIntolerance.reaction.substance in QI Core. QI Core and FHIR use "type" to describe the underlying physiologic mechanism for the reaction (i.e., allergy or intolerance). Greater clarity in definition in QDM descriptions in the CQL-based HQMF and in the QDM publication should be helpful.
Type	AllergyIntolerance.reaction.manifestation	In the future, QDM might consider adding the FHIR concept AllergyIntolerance.type (Allergy, Intolerance) and AllergyIntolerance.category (food, medication, environment, biologic).
Severity	Allergyintolerance.reaction.severity	Note the comment in QI Core/FHIR: "It is acknowledged that this assessment is very subjective. There may be some some specific practice domains where objective scales have been applied. Objective scales can be included in this model as extensions." In the future, consider addressing criticality in QDM as well (i.e., low risk, high risk).
Source	AllergyIntolerance.asserter	QDM matched to QI Core / FHIR
Recorder	AllergyIntolerance.recorder	QDM matched to QI Core / FHIR
id	AllergyIntolerance.id	QDM matched to QI Core / FHIR

7.3.0 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. QDM further defines contexts for assessments: Assessment, Performed and Assessment, Recommended. Each context is mapped to QI Core elements in the following tables.

Assessment, Performed

QDM Attribute	QI Core Metadata Element	Comments
Assessment, Performed	Observation (the .status metadata allows conformance to the specific QDM datatype context)	The context "performed" maps closest to the Observation.status final, amended, or corrected.
Author dateTime	Observation.effective[x]	QDM only addresses authorTime; QI Core allows a Period. Assessment generally address specific documentation of observations. Consider: Assessment to determine tobacco use history might ask for when tobacco use started and when it ended. The start time and stop time could be represented as answers to two different questions (i.e., when did the patient start and when did the patient end tobacco use). The Observation.effective[x] would apply more directly to a laboratory test the included collection of a specimen over a period of time. Consider authorDatetime for Assessment, Performed is the dateTime the assessment is captured.
Negation Rationale	Observation.dataAbsentReason	QDM negation rationale addresses absence of the information for a known, and approved reason determined by the measure author. Thus eCQMs use a measure developer-specific value set for negation rationale. The value set for Observation.dataAbsentReason is required so QI Core would need to be an extension of the existing information. Note, the referenced value set is extensible.
Reason	Observaton.basedOn	QDM matched to QI Core / FHIR
Method	Observation.method	QDM matched to QI Core / FHIR
Result	Observation.value[x]	QDM matched to QI Core / FHIR Note - QI Core also includes Observation.interpretation and Observation.comment - eCQMs have addressed interpretation as an implementation issue.
Related to	Observaton.basedOn	QDM matched to QI Core / FHIR Alternate name: fulfills
code	Observation.code	QDM matched to QI Core / FHIR
Components	Components	QDM uses components to combine related observations to each other, e.g., a set of independent observations performed within an admission assessment for an inpatient admission. Each observation is unique (e.g., questions about tobacco usage, other substance usage, blood pressure, pulse, skin turgor, etc., etc.) but they are captured during the same patient-provider interaction. Such QDM components should map directly to QI Core / FHIR observations that can be linked to other observations. Other QDM component examples include multiple questions that are part of a validated evaluation tool (e.g., a Braden skin assessment scale). This latter example indicates individual questions that are inherently tied to the Braden scale instrument and the questions and answers do not have inherent value without being part of the instrument. QI Core / FHIR considers each such question as an Observation.component. A general rule of thumb is QI Core / FHIR components apply only when the inherent value of the observation is defined by the parent observation. The result is that the content will determine if a QDM component maps to Observation.code or to Observation.component.code.
Component code	Observation.component.code	See "Components" - The content will determine if a QDM component maps to Observation.code or to Observation.component.code
Component result	Component result	See "Components" - The content will determine if a QDM component maps to Observation.value[x] or to Observation.component.value[x]
id	Observaton.id	QDM matched to QI Core / FHIR Alternate name: fulfills
Source	Observation.performer	QI Core / FHIR does not have a direct concept of "source" but it does list Observation.performer and Observation.device, both of which would address the QDM concept of Source.

Assessment, Recommended

QDM Attribute	QI Core Metadata Element	Comments
Assessment, Recommended	ProcedureRequest.intent	Procedure Request intent uses the concepts proposal, plan, order, original-order, reflex-order, filler-order, instance-order, option. "Proposal" is most consistent with the ProcedureRequest when applied to clinical decision support (CDS) in which the CDS proposes an action to a provider or to a patient. The QDM concept Recommended addresses expectations a provider gives to a patient. Such recommendations are most consistent with the ProcedureRequest.intent value of "plan" (an intension to ensure something occurs without providing an authorization to act).
Author dateTime	ProcedureRequest.authoredOn	QDM matched to QI Core / FHIR Note - ProcedureRequest.occurrence[x] defines a dateTime when the event should occur - not addressed in QDM
Negation Rationale	ProcedureRequest.extension (reasonRefused)	QDM matched to QI Core / FHIR
Reason	ProcedureRequest.reasonCode	QDM matched to QI Core / FHIR
Method		This item is not found in QI Core.
code	ProcedureRequest.code	QDM matched to QI Core / FHIR
id	ProcedureRequest.id	QDM matched to QI Core / FHIR
Source	ProcedureRequest.requester	QDM to QI Core mapping seems most appropriate to ProcedureRequest.requester as defined for the "source" attribute.
Recorder	ProcedureRequest.requester.agent	QDM matched to QI Core / FHIR

7.4.0 Care Experience

QDM defines Care Experience as the experience a patient has when receiving care or a provider has when providing care. The individual Care Experience datatypes should be consulted for further details. QDM represents two kinds of care experience: Patient Care Experience and Provider Care Experience.

Patient Care Experience

QDM Attribute	QI Core Metadata Element	Comments
Patient Care Experience	Observation (the .status metadata allows conformance to the specific QDM datatype context)	QDM matched to QI Core / FHIR
Author dateTime	Observation.effective[x]	QDM only addresses authorTime; QI Core allows a Period. Patient Care Experience generally address specific documentation of observations. However, the experience may be referencing a specific period of time during which the patient was exposed to the healthcare system (e.g., Patient Care Experience during a hospitalization - i.e., with an admission dateTime and discharege dateTime to define the Relevant Period). Such concepts would use observation.effective.[x]. Consider authorDatetime for Patient Care Experience is the dateTime the experience is captured (i.e., the start of the effectiveTime).
code	Observation.code	QDM matched to QI Core / FHIR
id	Observation.id	QDM matched to QI Core / FHIR
Source	Observation.performer	QI Core / FHIR does not have a direct concept of "source" but it does list Observation.performer and Observation.device, both of which would address the QDM concept of Source.

Provider Care Experience

QDM Attribute	QI Core Metadata Element	Comments
Provider Care Experience	Observation (the .status metadata allows conformance to the specific QDM datatype context)	QDM matched to QI Core / FHIR
Author dateTime	Observation.effective[x]	QDM only addresses authorTime; QI Core allows a Period. Provider Care Experience generally address specific documentation of observations. However, the experience may be referencing a specific period of time during which the patient was exposed to the healthcare system (e.g., Provider care experience during a hospitalization - i.e., with an admission dateTime and discharege dateTime to define the Relevant Period). Such concepts would use observation.effective.[x]. Consider authorDatetime for Provider Care Experience is the dateTime the experience is captured (i.e., the start of the effectiveTime).
code	Observation.code	QDM matched to QI Core / FHIR
id	Observation.id	QDM matched to QI Core / FHIR
Source	Observation.performer	QI Core / FHIR does not have a direct concept of "source" but it does list Observation.performer and Observation.device, both of which would address the QDM concept of Source.

7.5.0 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 all stakeholders, including the patient, 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 the QDM categories as a Record Artifact. A time/date stamp is required.

Provider Care Experience

QDM Attribute	QI Core Metadata Element	Comments
Care Goal	Goal.status	QDM matched to QI Core / FHIR
Related to	Goal.addresses	QDM matched to QI Core / FHIR Alternate name: fulfills
Relevant Period	Goal.start[x]	Relevant Period should be calculated from the Goal.start[x] to the Goal.target.due[x]
	Goal.target.due[x]	Relevant Period should be calculated from the Goal.start[x] to the Goal.target.due[x]
Target Outcome	Goal.target.detail[x]	QDM matched to QI Core / FHIR
code	Goal.description	QDM matched to QI Core / FHIR
id	Goal.id	QDM matched to QI Core / FHIR
Source	Goal.expressedBy	QDM matched to QI Core / FHIR The person responsible for setting the goal.

7.6.0 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. It also may include the receipt of response from a patient with respect to any aspect of the care provided. Furthermore, it may include the conveying of information from provider to patient (e.g., results, findings, plans for care, medical advice, instructions, educational resources, appointments). A time and date stamp is required. QDM defines three contexts for communication: Communication, Patient to Provider; Communication, Provider to Patient; Communication, Provider to Provider.

Communication, Patient to Provider

QDM Attribute	QI Core Metadata Element	Comments
Communication, Patient to Provider	Communication (the .status metadata allows conformance to the specific QDM datatype context)	QDM matched to QI Core / FHIR - constrain to "completed"
Negation Rationale	Communication.notDoneReason	QDM matched to QI Core / FHIR
Author dateTime	Communication.sent	QDM addresses authorDatetime as the time the communication is sent.
Related to	Observation.basedOn	QDM matched to QI Core / FHIR Alternate name: fulfills
Code	Communication.reasonCode	Note - CommunicationRequest in QI Core could be considered but QDM does not differentiate a Communication recommended or ordered, only communication so the mapping assumes the communication has occurred, with or without a response.
id	Communication.id	QDM matched to QI Core / FHIR
Source	Communication.sender	QDM matched to QI Core / FHIR

Communication, Provider to Patient

QDM Attribute	QI Core Metadata Element	Comments
Communication, Provider to Patient	Communication (the .status metadata allows conformance to the specific QDM datatype context)	QDM matched to QI Core / FHIR
Negation Rationale	Communication.notDoneReason	QDM matched to QI Core / FHIR
Author dateTime	Communication.sent	QDM addresses authorDatetime as the time the communication is sent.
Related to	Observation.basedOn	QDM matched to QI Core / FHIR Alternate name: fulfills
Code	Communication.reasonCode	Note - CommunicationRequest in QI Core could be considered but QDM does not differentiate a Communication recommended or ordered, only communication so the mapping assumes the communication has occurred, with or without a response.
id	Communication.id	QDM matched to QI Core / FHIR
Source	Communication.sender	QDM matched to QI Core / FHIR

Communication, Provider to Provider

QDM Attribute	QI Core Metadata Element	Comments
Communication, Provider to Provider	Communication (the .status metadata allows conformance to the specific QDM datatype context)	QDM matched to QI Core / FHIR
Negation Rationale	Communication.notDoneReason	QDM matched to QI Core / FHIR
Author dateTime	Communication.sent	QDM addresses authorDatetime as the time the communication is sent.
Related to	Observation.basedOn	QDM matched to QI Core / FHIR Alternate name: fulfills
Code	Communication.reasonCode	Note - CommunicationRequest in QI Core could be considered but QDM does not differentiate a Communication recommended or ordered, only communication so the mapping assumes the communication has occurred, with or without a response.
id	Communication.id	QDM matched to QI Core / FHIR
Source	Communication.sender	QDM matched to QI Core / FHIR

7.7.0 Condition/Diagnosis/Problem

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 may also represent neutral or favorable conditions that affect a patient's plan of care (e.g., pregnancy).

Diagnosis

QDM Attribute	QI Core Metadata Element	Comments
Diagnosis	Condition (the .clinicalstatus metadata allows conformance to the specific QDM datatype context)	QDM defaults the status to active and prevalence period provides the evidence of activity.
Prevalence Period	Condition.onset[x]	QDM matched to QI Core / FHIR
	Condition.abatement[x]	QDM matched to QI Core / FHIR
Anatomical Location Site	Condition.bodySite	QDM matched to QI Core / FHIR
Severity	Condition.severity	QDM matched to QI Core / FHIR
code	Condition.code	QDM matched to QI Core / FHIR
Author dateTime	Condition.assertedDate	QDM matched to QI Core / FHIR
id	Condition.id	QDM matched to QI Core / FHIR
Source	Condition.asserter	QDM matched to QI Core / FHIR

7.8.0 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.¹ QDM provides three contexts for expressing devices: Device, Applied; Device, Order; and Device, Recommended.

Device, Applied

QDM Attribute	QI Core Metadata Element	Comments
Device, Applied	Procedure (the .status metadata allows conformance to the specific QDM datatype context)	Device.status allows active | inactive | entered-in-error | unknown as a required value set; Procedure.status seems more appropriate - constrain the event code to "Completed"
Anatomical Approach Site	Procedure.extension (approachBodySite)	QDM matched to QI Core / FHIR
Anatomical Location Site	Procedure.bodySite	Device.location (QI Core only) can indicate where the resource is found, but Procedure seems a better fit for Device, Applied
Negation Rationale	Procedure.notDoneReason	QDM matched to QI Core / FHIR
Reason	Procedure.reasonCode	QDM matched to QI Core / FHIR
Relevant Period	Procedure.performed[x]	QDM matched to QI Core / FHIR
Author dateTime	part of FHIR Provenance Resource	FHIR references authorDatetime as part of the provenance resource for all resources. Is authorDateTime still appropriate for this datatype?
Code	Procedure.focalDevice	QDM matched to QI Core / FHIR
id	Procedure.id	QDM matched to QI Core / FHIR
Source	Procedure.performer	QDM matched to QI Core / FHIR

Device, Order

QDM Attribute	QI Core Metadata Element	Comments
Device, Order	ProcedureRequest.intent	Procedure Request intent uses the concepts proposal, plan, order, original-order, reflex-order, filler-order, instance-order, option. Constrain to "order" from the intent value set for QDM datatypes with the order context.
Negation Rationale	ProcedureRequest.extension (reasonRefused)	QDM matched to QI Core / FHIR
Reason	ProcedureRequest.reasonCode	QDM matched to QI Core / FHIR
Author dateTime	ProcedureRequest.authoredOn	Note - ProcedureRequest.occurrence[x] defines a dateTime when the event should occur - not addressed in QDM
code	ProcedureRequest.code	See also, Observation.category
id	ProcedureRequest.id	QDM matched to QI Core / FHIR
Source	ProcedureRequest.requester	Author, orderer - note also, ProcedureRequest.requester.agent for device, practitioner or organization who initiated the request; or ProcedureRequest.requester.onBehalfOf - the organization the device or practitioner was acting on behalf of

Device, Recommended

QDM Attribute	QI Core Metadata Element	Comments
Device, Recommended	ProcedureRequest.intent	Procedure Request intent uses the concepts proposal, plan, order, original-order, reflex-order, filler-order, instance-order, option. "Proposal" is most consistent with the ProcedureRequest when applied to clinical decision support (CDS) in which the CDS proposes an action to a provider or to a patient. The QDM concept Recommended addresses expectations a provider gives to a patient. Such recommendations are most consistent with the ProcedureRequest.intent value of "plan" (an intension to ensure something occurs without providing an authorization to act).
Negation Rationale	ProcedureRequest.extension (reasonRefused)	QDM matched to QI Core / FHIR
Reason	ProcedureRequest.reasonCode	QDM matched to QI Core / FHIR
Author dateTime	ProcedureRequest.authoredOn	Note - ProcedureRequest.occurrence[x] defines a dateTime when the event should occur - not addressed in QDM
Code	ProcedureRequest.code	See also, Observation.category
id	ProcedureRequest.id	QDM matched to QI Core / FHIR
Source	ProcedureRequest.requester	Author, orderer - note also, ProcedureRequest.requester.agent for device, practitioner or organization who initiated the request; or ProcedureRequest.requester.onBehalfOf - the organization the device or practitioner was acting on behalf of

7.9.0 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 defines diagnostic studies as 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. QDM defines three contexts for Diagnostic Study: Diagnostic Study, Order; Diagnostic Study, Performed; and Diagnostic Study, Recommended. Note that QI Core maps for imaging type diagnostic studies are mapped to DiagnosticReport; QI Core maps for non-imaging type diagnostic studies are mapped to Observation.

Diagnostic Study, Order

QDM Attribute	QI Core Metadata Element	Comments
Diagnostic Study, Order	ProcedureRequest.intent	Procedure Request intent uses the concepts proposal, plan, order, original-order, reflex-order, filler-order, instance-order, option. Constrain to "order" from the intent value set for QDM datatypes with the order context.
Method		This item is not found in QI Core.
Negation Rationale	ProcedureRequest.extension (reasonRefused)	QDM matched to QI Core / FHIR
Reason	ProcedureRequest.reasonCode, Use http://hl7.org/fhir/us/qicore/qicore-procedurerequest-appropriatenessScore.html to address RAND criteria for appropriate imaging usage criteria.	QDM matched to QI Core / FHIR
Author dateTime	ProcedureRequest.authoredOn	Note - ProcedureRequest.occurrence[x] defines a dateTime when the event should occur - not addressed in QDM
code	ProcedureRequest.code	See also, Observation.category
id	ProcedureRequest.id	QDM matched to QI Core / FHIR
Source	ProcedureRequest.requester	Author, orderer - note also, ProcedureRequest.requester.agent for device, practitioner or organization who initiated the request; or ProcedureRequest.requester.onBehalfOf - the organization the device or practitioner was acting on behalf of

Diagnostic Study, Performed (imaging studies)

QDM Attribute	QI Core Metadata Element	Comments
Diagnostic Study, Performed (Specific to imaging studies)	DiagnosticReport (the .status metadata allows conformance to the specific QDM datatype context)	QDM matched to QI Core / FHIR. Quality measures and CDS artifacts may need to address which status is desired: Partial, preliminary, final, amended, corrected, appended. Most quality measures will address final, amended, corrected, appended.
FacilityLocations	DiagnosticReport.extension (locationPerformed)	QDM matched to QI Core / FHIR
Method		Not available in QI Core / FHIR
Negation Rationale	None	FHIR DiagnosticReport does not address negation since there would be no report. QDM usage to indicate studies that have not been done should address negation rationale for the order or the recommendation (i.e., ProcedureRequest.extension (reasonRefused).
Reason	None	FHIR DiagnosticReport does not address reason since reason is a function of the order or recommendation. QDM reference to indicate the reason for imaging studies should reference qicore-procedurerequest-appropriatenessScore.
Result	DiagnosticReport.result	Note - QI Core also includes Observation.interpretation and Observation.comment - eCQMs have addressed interpretation as an implementation issue. Perhaps that approach should be reconsidered.
Result dateTime	DiagnosticReport.issued	QDM matched to QI Core / FHIR
Relevant Period	DiagnosticReport.effective[x]	QDM only addresses authorTime; QI Core allows a Period. Consider addressing the difference.
Status	DiagnosticReport.status	QDM matched to QI Core / FHIR
Code	DiagnosticReport.code	Note - QI Core includes DiagnosticReport.specimen - eCQMs use the LOINC value set to determine the specimen source
Author dateTime	part of FHIR Provenance Resource	FHIR references authorDatetime as part of the provenance resource for all resources. Is authorDatetime still appropriate for this datatype?
Components		Components for imaging studies not addressed in QICore
Component code		Components for imaging studies not addressed in QICore
Component result		Components for imaging studies not addressed in QICore
id	DiagnosticReport.id	QDM matched to QI Core / FHIR
Source	DiagnosticReport.performer	Source is addressed by either DiagnosticReport.performer or Observation.device

Diagnostic Study, Performed (non-imaging studies)

QDM Attribute	QI Core Metadata Element	Comments
Diagnostic Study, Performed (Specific to non-imaging studies)	Observation (the .status metadata allows conformance to the specific QDM datatype context)	QDM matched to QI Core / FHIR. Quality measures and CDS artifacts may need to address which status is desired: Partial, preliminary, final, amended, corrected, appended. Most quality measures will address final, amended, corrected, appended.
FacilityLocation	DiagnosticReport.extension (locationPerformed)	QDM matched to QI Core / FHIR
Method	Observation.method	Not available in QI Core / FHIR
Negation Rationale	Observation.dateAbsentReason	The value set is required. Many eCQMs use a measure developer-specific value set. Note, component also has a Observation.component.dataAbsentReason in QI Core.
Reason	Observation.basedOn	This is the best fit in QI Core
Result	Observation.value[x]	Note - QI Core also includes Observation.interpretation and Observation.comment - eCQMs have addressed interpretation as an implementation issue. Perhaps that approach should be reconsidered.
Result dateTime	Observation.issued	QDM matched to QI Core / FHIR
Relevant Period	Observation.effective[x]	QDM only addresses authorTime; QI Core allows a Period. Consider addressing the difference.
Status	Observation.status	QDM matched to QI Core / FHIR
Code	Observation.code	Note - QI Core includes Observation.specimen - eCQMs use the LOINC value set to determine the specimen source
Author dateTime	part of FHIR Provenance Resource	FHIR references authorDatetime as part of the provenance resource for all resources. Is authorDatetime still appropriate for this datatype?
Components	Observation.component	QDM uses components to combine related observations to each other, e.g., a set of independent observations performed within an admission assessment for an inpatient admission. Each observation is unique (e.g., questions about tobacco usage, other substance usage, blood pressure, pulse, skin turgor, etc., etc.) but they are captured during the same patient-provider interaction. Such QDM components should map directly to QI Core / FHIR observations that can be linked to other observations. Other QDM component examples include multiple questions that are part of a validated evaluation tool (e.g., a Braden skin assessment scale). This latter example indicates individual questions that are inherently tied to the Braden scale instrument and the questions and answers do not have inherent value without being part of the instrument. QI Core / FHIR considers each such question as an Observation.component. A general rule of thumb is QI Core / FHIR components apply only when the inherent value of the observation is defined by the parent observation. The result is that the content will determine if a QDM component maps to Observation.code or to Observation.component.code.
Component code	Observation.component.code	See "component" - content-specific
Component result	Observation.component.value[x]	See "component" - content-specific
id	Observation.id	QDM matched to QI Core / FHIR
Source	Observation.performer	Source is addressed by either Observation.performer or Observation.device

Diagnostic Study, Recommended

QDM Attribute	QI Core Metadata Element	Comments
Diagnostic Study, Recommended	ProcedureRequest.intent	Procedure Request intent uses the concepts proposal, plan, order, original-order, reflex-order, filler-order, instance-order, option. "Proposal" is most consistent with the ProcedureRequest when applied to clinical decision support (CDS) in which the CDS proposes an action to a provider or to a patient. The QDM concept Recommended addresses expectations a provider gives to a patient. Such recommendations are most consistent with the ProcedureRequest.intent value of "plan" (an intension to ensure something occurs without providing an authorization to act).
Method		This item is not found in QI Core.
Negation Rationale	ProcedureRequest.extension (reasonRefused)	QDM matched to QI Core / FHIR
Author dateTime	ProcedureRequest.authoredOn	Note - ProcedureRequest.occurrence[x] defines a dateTime when the event should occur - not addressed in QDM
code	ProcedureRequest.code	See also, Observation.category
id	ProcedureRequest.id	QDM matched to QI Core / FHIR
Source	ProcedureRequest.requester	Author, orderer - note also, ProcedureRequest.requester.agent for device, practitioner or organization who initiated the request; or ProcedureRequest.requester.onBehalfOf - the organization the device or practitioner was acting on behalf of

7.10.0 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. Encounters can be billable events but are not limited to billable interactions. Each encounter has an associated location or modality within which it occurred (such as an office, home, electronic methods, phone encounter, or telemedicine methods). The encounter location is the patient's location at the time of measurement. Different levels of interaction can be specified in the value associated with the element while modes of interaction (e.g., telephone) may be modeled using the data flow attribute. QDM defines three contexts for Encounter: Encounter, Order; Encounter, Performed; Encounter, Recommended.

Encounter, Order

QDM Attribute	QI Core Metadata Element	Comments
Encounter, Order	ReferralRequest.intent	Referral Request intent uses the concepts proposal, plan, order, original-order, reflex-order, filler-order, instance-order, option. For QDM datatypes with the context "order" the ReferralRequest.intent value shall be constrained to "order"
FacilityLocation	ReferralRequest.context	QDM matched to QI Core / FHIR
Negation Rationale	ProcedureRequest.extension (reasonRefused)	Modeled as a procedure request - there is no Encounter request in QI Core
Reason	ReferralRequest.reasonCode	QDM matched to QI Core / FHIR
Author dateTime	ReferralRequest.authoredOn	Note - ProcedureRequest.occurrence[x] defines a dateTime when the event should occur - not addressed in QDM
code	ReferralRequest.code	See also, Observation.category
id	ReferralRequest.id	QDM matched to QI Core / FHIR
Source	ReferralRequest.requester	Author, orderer - note also, ProcedureRequest.requester.agent for device, practitioner or organization who initiated the request; or ProcedureRequest.requester.onBehalfOf - the organization the device or practitioner was acting on behalf of

Encounter, Performed

QDM Attribute	QI Core Metadata Element	Comments
Encounter, Performed	Encounter (the .status metadata allows conformance to the specific QDM datatype context)	Constrained to status consistent with in-progress or finished.
Relevant Period	Encounter.period	QDM matched to QI Core / FHIR
Admission Source	Encounter.hospitalization.admitSource	QDM matched to QI Core / FHIR
Diagnosis	Encounter.diagnosis	QDM matched to QI Core / FHIR
Discharge Disposition	Encounter.hospitalization.dischargeDisposition	QDM matched to QI Core / FHIR
Length of Stay	Encounter.length	QDM matched to QI Core / FHIR
Negation Rationale	Encounter.extension (reasonCancelled)	Only applies to an encounter that was cancelled, not an encounter that was never planned for a specific reason.
Principal Diagosis	Encounter.diagnosis.role	Not a direct fit - the value set does not include principal diagnosis, which could be added to the value set. It is a better fit than diagnosis rank since the primary diagnosis may not be the same as the principal diagnosis.
Author dateTime	part of FHIR Provenance Resource	FHIR references authorDatetime as part of the provenance resource for all resources. Is authorDatetime still appropriate for this datatype?
Code	Encounter.class	Encounter.class fits best with the type of encounter. Measure developers create their own values and might need to constrain the use to the suggested value set. The previous Encounter.class value set included OBS - observation defined as "Provision of care of women during pregnancy, childbirth and immediate postpartum period. Also known as Maternity." The updated value set includes OBSENC for "observation encounter" approved in the November 2017 Harmonization cycle.
FacilityLocations	Encounter.location	QDM matched to QI Core / FHIR
FacilityLocations code	Location.type	QDM matched to QI Core / FHIR
FacilityLocations location period	Location.period	QDM matched to QI Core / FHIR
id	Encounter.id	QDM matched to QI Core / FHIR

Encounter, Recommended

QDM Attribute	QI Core Metadata Element	Comments
Encounter, Order	ReferralRequest.intent	Referral Request intent uses the concepts proposal, plan, order, original-order, reflex-order, filler-order, instance-order, option. "Proposal" is most consistent with the ReferralRequest when applied to clinical decision support (CDS) in which the CDS proposes an action to a provider or to a patient. The QDM concept Recommended addresses expectations a provider gives to a patient. Such recommendations are most consistent with the ReferralRequest.intent value of "plan" (an intension to ensure something occurs without providing an authorization to act).
FacilityLocation	ReferralRequest.context	QDM matched to QI Core / FHIR
Negation Rationale	ProcedureRequest.extension (reasonRefused)	QDM matched to QI Core / FHIR
Reason	ReferralRequest.reasonCode	QDM matched to QI Core / FHIR
Author dateTime	ReferralRequest.authoredOn
Code	ReferralRequest.type
id	ReferralRequest.id	QDM matched to QI Core / FHIR
Source	ReferralRequest.requester

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

Family History

QDM Attribute	QI Core Metadata Element	Comments
Family History	FamilyMemberHistory.status	QDM matched to QI Core / FHIR
Author dateTime	FamilyMemberHistory.date	QDM matched to QI Core / FHIR
Relationships	FamilyMemberHistory.relationship	QDM matched to QI Core / FHIR
Code	FamilyMemberHistory.condition.code	QDM matched to QI Core / FHIR
id	FamilyMemberHistory.id	QDM matched to QI Core / FHIR
Source	FamilyMemberHistory.patient	QDM matched to QI Core / FHIR

7.12.0 Immunization

QDM defines Immunization as vaccines administered to patients in healthcare settings but does not include non-vaccine agents. QDM defines two contexts for immunization: Immunization, Administered; Immunization, Order.

Immunization, Administered

QDM Attribute	QI Core Metadata Element	Comments
Immunization, Administered	Immunization (the .status metadata allows conformance to the specific QDM datatype context)	QDM matched to QI Core / FHIR
Dosage	Immunization.doseQuantity	QDM matched to QI Core / FHIR
Negation Rationale	Immunization.explanation.reasonNotGiven	QDM matched to QI Core / FHIR
Reason	Immunization.explanation.reason	QDM matched to QI Core / FHIR
Route	Immunization.route	QDM matched to QI Core / FHIR
Author dateTime	Immunization.date	QDM matched to QI Core / FHIR
Supply		Not addressed in QI Core
Code	Immunization.vaccineCode	QDM matched to QI Core / FHIR
id	Immunization.id	QDM matched to QI Core / FHIR
Source	Immunization.primarySource	Source addressed by primarySource or reportOrigin

Immunization, Order

QDM Attribute	QI Core Metadata Element	Comments
Immunization, Order	Immunization (the .status metadata allows conformance to the specific QDM datatype context)	the Immunization.status value set does not include an option for "requested" and needs to add the concept to the value set. Alternatively, use Procedure.status (which also needs "requested" as a concept to meet the need here).
Active dateTime	ImmunizationRecommendation.recommendation.dateCriterion	QDM matched to QI Core / FHIR
Dosage	Immunization.doseQuantity	Not sure this applies since it addresses what was given, not what should be given. There is no QI Core Counterpart for immunization order
Negation Rationale	ProcedureRequest.extension (reasonRefused)	QDM matched to QI Core / FHIR
Reason	ImmunizationRecommendation.recommendation.protocol	QDM matched to QI Core / FHIR
Route	Immunization.route	Not sure this applies since it addresses the route used, not what route should be used. There is no QI Core Counterpart for immunization order
Supply		Not addressed in QI Core
Author dateTime	ImmunizationRecommendation.recommendation.date	QDM matched to QI Core / FHIR
Code	ImmunizationRecommendation.recommendation.vaccineCode	QDM matched to QI Core / FHIR
id	ImmunizationRecommendation.id	QDM matched to QI Core / FHIR
Source	ProcedureRequest.requester	QDM matched to QI Core / FHIR

7.13.0 Individual Characteristic

QDM defines Individual Characteristic as specific factors about a patient, clinician, provider, or facility. Included are 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.
QDM defines nine individual characteristics: Patient Characteristic; Patient Characteristic, Birthdate; Patient Characteristic, Clinical Trial Participant; Patient Characteristic, Ethnicity; Patient Characteristic, Expired; Patient Characteristic, Payer; Patient Characteristic, Race; Patient Characteristic, Sex; Provider Characteristic.

Patient Characteristic

QDM Attribute	QI Core Metadata Element	Comments
Author dateTime	part of FHIR Provenance Resource	FHIR references authorDatetime as part of the provenance resource for all resources.
Code		Not addressed in QI Core
id	patient.id	QDM matched to QI Core / FHIR
Source		Not addressed in QI Core
Recorder		Possbly addressed in FHIR provenance

Patient Characteristic: Birthdate

QDM Attribute	QI Core Metadata Element	Comments
Birth dateTime	Patient.birthDate Patient.extension.birthTime	Patient.extension.birthTime used for birthTime for newborns
Code		Not addressed in QI Core
id	patient.id	QDM matched to QI Core / FHIR

Patient Characteristic: Clinical Trial Participant

QDM Attribute	QI Core Metadata Element	Comments
Reason	Patient.extension.clinicalTrial.reason	QDM matched to QI Core / FHIR
Relevant Period	Patient.extension.clinicalTrial.period	QDM matched to QI Core / FHIR
Code	Patient.extension.clinicalTrial.NCT	QDM matched to QI Core / FHIR
id	patient.id	QDM matched to QI Core / FHIR

Patient Characteristic: Ethnicity

QDM Attribute	QI Core Metadata Element	Comments
Code	​Patient.extension (ethnicity.ombCategory)	QDM matched to QI Core / FHIR
id	patient.id	QDM matched to QI Core / FHIR

Patient Characteristic: Expired

QDM Attribute	QI Core Metadata Element	Comments
Cause		Not addressed in QI Core
Expiration dateTime	Patient.deceasedDateTime
Code	deceasedBoolean	If the code exisits in QDM the deceasedBoolean is true. Uses a direct referenced code (SNOMED CT 419099009 2016-03).
id	patient.id

Patient Characteristic: Payer

QDM Attribute	QI Core Metadata Element	Comments
Relevant Period		Not addressed in QI Core
Code		Not addressed in QI Core
id	patient.id

Patient Characteristic: Race

QDM Attribute	QI Core Metadata Element	Comments
Code	​Patient.extension (race.ombCategory)	QDM matched to QI Core / FHIR
id	patient.id	QDM matched to QI Core / FHIR

Patient Characteristic: Sex

QDM Attribute	QI Core Metadata Element	Comments
Code	Patient.gender	QDM matched to QI Core / FHIR
id	patient.id	QDM matched to QI Core / FHIR

Provider Characteristic

QDM Attribute	QI Core Metadata Element	Comments
Author dateTime	part of FHIR Provenance Resource	FHIR references authorDatetime as part of the provenance resource for all resources. Note - FHIR includes a concept Practitioner.qualification.period (period during which the qualification is valid). The qualification period may be useful in defining CDS or eCQMs.
Code	Practitioner.qualification.code	QDM matched to QI Core / FHIR
id	Practitioner.identifier.id	QDM matched to QI Core / FHIR

7.14.0 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. QDM defines three contexts for intervention: Intervention, Order; Intervention, Performed; Intervention, Recommended.

Intervention, Order

QDM Attribute	QI Core Metadata Element	Comments
Intervention, Order	ProcedureRequest.intent	Procedure Request intent uses the concepts proposal, plan, order, original-order, reflex-order, filler-order, instance-order, option. Constrain to "order" from the intent value set for QDM datatypes with the order context.
Negation Rationale	ProcedureRequest.extension (reasonRefused)	QDM matched to QI Core / FHIR
Reason	ProcedureRequest.reasonCode	QDM matched to QI Core / FHIR
Author dateTime	ProcedureRequest.authoredOn	Note - ProcedureRequest.occurrence[x] defines a dateTime when the event should occur - not addressed in QDM
Code	ProcedureRequest.code	See also, Observation.category
id	ProcedureRequest.id	QDM matched to QI Core / FHIR
Source	ProcedureRequest.requester	Author, orderer - note also, ProcedureRequest.requester.agent for device, practitioner or organization who initiated the request; or ProcedureRequest.requester.onBehalfOf - the organization the device or practitioner was acting on behalf of

Intervention, Performed

QDM Attribute	QI Core Metadata Element	Comments
Intervention, Performed	Procedure (the .status metadata allows conformance to the specific QDM datatype context)	QDM matched to QI Core / FHIR
Negation Rationale	Procedure.notDoneReason	QDM matched to QI Core / FHIR
Reason	Procedure.reasonCode	QDM matched to QI Core / FHIR
Result	Procedure.outcome	QDM matched to QI Core / FHIR
Relevant Period	Procedure.performed[x]	QDM matched to QI Core / FHIR
Author dateTime	part of FHIR Provenance Resource	FHIR references authorDatetime as part of the provenance resource for all resources. Is authorDatetime still appropriate for this datatype?
Status	Procedure.status	QDM matched to QI Core / FHIR
Code	Procedure.code	QDM matched to QI Core / FHIR
id	Procedure.id	QDM matched to QI Core / FHIR
Source	Procedure.performer	QDM matched to QI Core / FHIR

Intervention, Recommended

QDM Attribute	QI Core Metadata Element	Comments
Intervention, Reecommended	ProcedureRequest.intent	Procedure Request intent uses the concepts proposal, plan, order, original-order, reflex-order, filler-order, instance-order, option. "Proposal" is most consistent with the ProcedureRequest when applied to clinical decision support (CDS) in which the CDS proposes an action to a provider or to a patient. The QDM concept Recommended addresses expectations a provider gives to a patient. Such recommendations are most consistent with the ProcedureRequest.intent value of "plan" (an intension to ensure something occurs without providing an authorization to act).
Negation Rationale	ProcedureRequest.extension (reasonRefused)	QDM matched to QI Core / FHIR
Reason	ProcedureRequest.reasonCode	QDM matched to QI Core / FHIR
Author dateTime	ProcedureRequest.authoredOn	Note - ProcedureRequest.occurrence[x] defines a dateTime when the event should occur - not addressed in QDM
Code	ProcedureRequest.code	See also, Observation.category
id	ProcedureRequest.id	QDM matched to QI Core / FHIR
Source	ProcedureRequest.requester	Author, orderer - note also, ProcedureRequest.requester.agent for device, practitioner or organization who initiated the request; or ProcedureRequest.requester.onBehalfOf - the organization the device or practitioner was acting on behalf of

7.15.0 Laboratory Test

QDM defines Laboratory Test as a medical procedure that involves testing a sample of blood, urine, or other substance from the body. 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. QDM defines three contexts for Laboratory Test: Laboratory Test, Order; Laboratory Test, Performed; Laboratory Test, Recommended.

Laboratory Test, Order

QDM Attribute	QI Core Metadata Element	Comments
Laboratory Test, Order	ProcedureRequest.intent	Procedure Request intent uses the concepts proposal, plan, order, original-order, reflex-order, filler-order, instance-order, option. Constrain to "order" from the intent value set for QDM datatypes with the order context.
Method
Negation Rationale	ProcedureRequest.extension (reasonRefused)	QDM matched to QI Core / FHIR
Reason	ProcedureRequest.reasonCode	QDM matched to QI Core / FHIR
Author dateTime	ProcedureRequest.authoredOn	Note - ProcedureRequest.occurrence[x] defines a dateTime when the event should occur - not addressed in QDM
Code	ProcedureRequest.code	See also, Observation.category
id	ProcedureRequest.id	QDM matched to QI Core / FHIR
Source	ProcedureRequest.requester	Author, orderer - note also, ProcedureRequest.requester.agent for device, practitioner or organization who initiated the request; or ProcedureRequest.requester.onBehalfOf - the organization the device or practitioner was acting on behalf of

Laboratory Test, Performed

QDM Attribute	QI Core Metadata Element	Comments
Laboratory Test, Performed	Observation (the .status metadata allows conformance to the specific QDM datatype context)	QDM matched to QI Core / FHIR.
Method	Observation.method	Not available in QI Core / FHIR
Negation Rationale	Observation.dateAbsentReason	The value set is required. Many eCQMs use a measure developer-specific value set. Note, component also has a Observation.component.dataAbsentReason in QI Core.
Reason	Observation.basedOn	This is the best fit in QI Core
Reference Range High	Observation.referenceRange.high	QI Core also references Observation.referenceRange.type - i.e. what part of the referenced target population it applies to (e.g., normal or therapeutic range); and Observation.referenceRange.appliesTo - i.e., the target population (normal population, or particular sex or race), and Observation.referenceRange.age. QI Core also addresses Observation.component.referenceRange. Should these options be considered for QDM?
Reference Range Low	Observation.referenceRange.low	QI Core also references Observation.referenceRange.type - i.e. what part of the referenced target population it applies to (e.g., normal or therapeutic range); and Observation.referenceRange.appliesTo - i.e., the target population (normal population, or particular sex or race), and Observation.referenceRange.age. QI Core also addresses Observation.component.referenceRange. Should these options be considered for QDM?
Result	Observation.value[x]	Observation.value[x] refers to QI Core Observation which is noted here. Note - QI Core also includes Observation.interpretation and Observation.comment - eCQMs have addressed interpretation as an implementation issue. Perhaps that approach should be reconsidered.
Result dateTime	Observation.issued	QDM matched to QI Core / FHIR
Relevant Period	Observation.effective[x]	QDM only addresses authorTime; QI Core allows a Period. Consider addressing the difference.
Status	Observation.status	QDM matched to QI Core / FHIR
Author dateTime	Observation.issued	QDM only addresses authorTime; QI Core allows a Period. Consider addressing the difference.
Code	Observation.code	Note - QI Core includes Observation.specimen - eCQMs use the LOINC value set to determine the specimen source
Components	Observation.component	QDM uses components to combine related observations to each other, e.g., a set of independent observations performed within an admission assessment for an inpatient admission. Each observation is unique (e.g., questions about tobacco usage, other substance usage, blood pressure, pulse, skin turgor, etc., etc.) but they are captured during the same patient-provider interaction. Such QDM components should map directly to QI Core / FHIR observations that can be linked to other observations. Other QDM component examples include multiple questions that are part of a validated evaluation tool (e.g., a Braden skin assessment scale). This latter example indicates individual questions that are inherently tied to the Braden scale instrument and the questions and answers do not have inherent value without being part of the instrument. QI Core / FHIR considers each such question as an Observation.component. A general rule of thumb is QI Core / FHIR components apply only when the inherent value of the observation is defined by the parent observation. The result is that the content will determine if a QDM component maps to Observation.code or to Observation.component.code.
Component code	Observation.component.code	See "component" - content-specific
Component result	Observation.component.value[x]	See "component" - content-specific
Component reference range high	Observation.component.referenceRange	Refers back to Component.referenceRange
Component reference range low	Observation.component.referenceRange	Refers back to Component.referenceRange
id	Observation.id	QDM matched to QI Core / FHIR
Source	Observation.performer	Note - QI Core includes Observation.subject - QDM should consider adding subject instead of health record field.

Laboratory Test, Recommended

QDM Attribute	QI Core Metadata Element	Comments
Laboratory Test, Recommended	ProcedureRequest.intent	Procedure Request intent uses the concepts proposal, plan, order, original-order, reflex-order, filler-order, instance-order, option. Constrain to "order" from the intent value set for QDM datatypes with the order context.
Method		Not addressed in QI Core
Negation Rationale	ProcedureRequest.extension (reasonRefused)	QDM matched to QI Core / FHIR
Reason	ProcedureRequest.reasonCode	QDM matched to QI Core / FHIR
Author dateTime	ProcedureRequest.authoredOn	Note - ProcedureRequest.occurrence[x] defines a dateTime when the event should occur - not addressed in QDM
Code	ProcedureRequest.code	See also, Observation.category
id	ProcedureRequest.id	QDM matched to QI Core / FHIR
Source	ProcedureRequest.requester	Author, orderer - note also, ProcedureRequest.requester.agent for device, practitioner or organization who initiated the request; or ProcedureRequest.requester.onBehalfOf - the organization the device or practitioner was acting on behalf of

7.16.0 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: Medication, Active; Medication, Administered; Medication, Discharge; Medication, Dispensed; Medication, Order.

Medication, Active

QDM Attribute	QI Core Metadata Element	Comments
Medication, Active	MedicationStatement (the .status metadata allows conformance to the specific QDM datatype context)	The Medication, Active datatype requires use of the "active" status code from the FHIR value set.
Dosage	MedicationStatement.dosage.dose	QDM matched to QI Core / FHIR
Supply		Not present in QI Core
Frequency	MedicationStatement.dosage.timing	QDM matched to QI Core / FHIR
Route	MedicationStatement.dosage.route	QDM matched to QI Core / FHIR
Relevant Period	MedicationStatement.effective[x]	QDM matched to QI Core / FHIR
Code	MedicationStatement.medication[x]	QDM matched to QI Core / FHIR
Source	MedicationStatement.informationSource	QDM matched to QI Core / FHIR

Medication, Administered

QDM Attribute	QI Core Metadata Element	Comments
Medication, Administered	MedicationAdministration (the .status metadata allows conformance to the specific QDM datatype context)	QDM matched to QI Core / FHIR
Dosage	MedicationAdministration.dosage.dose	QDM matched to QI Core / FHIR
Supply		Not addressed in QI Core
Frequency	MedicationAdministration.dosage.timing	QDM matched to QI Core / FHIR
Negation Rationale	MedicationAdministration.reasonNotGiven	QDM matched to QI Core / FHIR
Reason	MedicationAdministration.reasonCode	QDM matched to QI Core / FHIR
Route	MedicationAdministration.dosage.route	QDM matched to QI Core / FHIR
Relevant Period	MedicationAdministration.effective[x]	QDM matched to QI Core / FHIR
Author dateTime	part of FHIR Provenance Resource	FHIR references authorDatetime as part of the provenance resource for all resources. Is authorDateTime still appropriate for this datatype?
Code	MedicationAdministration.medication[x]	QDM matched to QI Core / FHIR
id	MedicationAdministration.id	QDM matched to QI Core / FHIR

Medication, Discharge

QDM Attribute	QI Core Metadata Element	Comments
Medication, Discharge	MedicationRequest.intent	New profile created to address Medication-request-category = dischargeMedication (LOINC code 8654-6 Hospital Discharge medications) bound to RxNorm.
Dosage	MedicationRequest.dosage.dose[x]	Note - modeled using MedicationRequest - could also be modeled as MedicationStatement with a status of "intended". May be modeled better as a component of a discharge instruction set but I can't find that in QI Core or FHIR
Frequency	MedicationRequest.dosageInstruction.timing	Note - MedicationRequest.dosageInstruction.timing includes both the frequency instruction (e.g., every 8 hours) and the start and stop dates for the amount included.
Supply		Supply shouldn't be required for Medication, Discharge since it is a set of medication instructions for a patient after departing from the hospital. Consider removing this attribute from this QDM datatype. Also- not present in MedicationStatement in QI Core.
Negation Rationale	MedicationStatement.reasonNotTaken	Medication Request in QI Core does not reference negation rationale
Refills		Not present in QI Core - refills shouldn't be an attribute for a list of medicaitons intended at dischage - consider retiring this attribute for Medication, Discharge in QDM
Route	MedicationRequest.dosage.route	QDM matched to QI Core / FHIR
Author dateTime	MedicationRequest.authoredOn	Start of relevant period - no specific author time in QI Core
	MedicationRequest.dispenseRequest.validityPeriod	Consider prescription validity as a QDM attribute
	MedicationRequest.dosageInstruction.timing	Note - MedicationRequest.dosageInstruction.timing includes both the frequency instruction (e.g., every 8 hours) and the start and stop dates for the amount included.
Code	MedicationRequest.reasonCode	QDM matched to QI Core / FHIR
id	MedicationRequest.id	QDM matched to QI Core / FHIR

Medication, Dispensed

QDM Attribute	QI Core Metadata Element	Comments
Medication, Dispensed	MedicationDispense (the .status metadata allows conformance to the specific QDM datatype context)	QDM matched to QI Core / FHIR
Dosage	MedicationDispense.quantity	QDM matched to QI Core / FHIR
Supply	MedicationDispense.daysSupply	Not addressed in QI Core
Frequency	MedicationDispense.dosageInstruction.timing	QDM matched to QI Core / FHIR
Negation Rationale	MedicationDispense.notDoneReason[x]	QDM matched to QI Core / FHIR
Refills	MedicationDispense.extension (refillsRemaining)	QDM matched to QI Core / FHIR
Route	MedicationDispense.dosageInstruction.route	QDM matched to QI Core / FHIR
Relevant Period	MedicationDispense.extension (validityPeriod)	QDM matched to QI Core / FHIR
Author dateTime	part of FHIR Provenance Resource	FHIR references authorDateTime as part of the provenance resource for all resources.
Code	MedicationDispense.medication[x]	QDM matched to QI Core / FHIR
id	MedicationDispense.id	QDM matched to QI Core / FHIR
Source	MedicationDispense.performer	QDM matched to QI Core / FHIR

Medication, Order

QDM Attribute	QI Core Metadata Element	Comments
Medication, Order	MedicationRequest.intent	Medication Request intent uses the concepts proposal, plan, order, original-order, reflex-order, filler-order, instance-order, option. Constrain to "order" from the intent value set for QDM datatypes with the order context.
Dosage	MedicationRequest.dosageInstruction.dose[x]	QDM matched to QI Core / FHIR
Supply	MedicationRequest.dispenseRequest.quantity	QDM matched to QI Core / FHIR
Frequency	MedicationRequest.dosageInstruction.timing	QDM matched to QI Core / FHIR
Code	MedicationRequest.medication[x]	QDM matched to QI Core / FHIR
Method		Not addressed in QI Core
Negation Rationale	MedicationStatement.reasonNotTaken	Medication Request in QI Core does not reference negation rationale
Reason	MedicationRequest.reasonCode	QDM matched to QI Core / FHIR
Refills	MedicationRequest.dispenseRequest.numberOfRepeatsAllowed	QDM matched to QI Core / FHIR
Relevant Period	MedicationRequest.dispenseRequest.expectedSupplyDuration	QDM matched to QI Core / FHIR
Route	MedicationRequest.dosageInstruction.route	QDM matched to QI Core / FHIR
Author dateTime	MedicationRequest.authoredOn	QDM matched to QI Core / FHIR
id	MedicationRequest.id	QDM matched to QI Core / FHIR
Source	MedicationStatement.requester	QDM matched to QI Core / FHIR
Recorder	MedicationRequest.recorder	QDM matched to QI Core / FHIR

7.17.0 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.⁶

Participation

QDM Attribute	QI Core Metadata Element	Comments
Participation	Coverage (the .status metadata allows conformance to the specific QDM datatype context)	QDM matched to QI Core / FHIR
Code	Coverage.type	Modeled with FHIR Resource Coverage - may not apply to non-financial program participation but there is no other clear option identified. Not in QI Core
Participation Period	Coverage.period	QDM matched to QI Core / FHIR
id	Coverage.id	QDM matched to QI Core / FHIR

7.18.0 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. QDM defines three contexts for Physical Exam: Physical Exam, Order; Physical Exam, Performed; Physical Exam, Recommended.

Physical Exam, Order

QDM Attribute	QI Core Metadata Element	Comments
Physical Exam, Order	ProcedureRequest.intent	Procedure Request intent uses the concepts proposal, plan, order, original-order, reflex-order, filler-order, instance-order, option. Constrain to "order" from the intent value set for QDM datatypes with the order context.
Anatomical Location Site	ProcedureRequest.extension (approachBodySite)	QDM matched to QI Core / FHIR
Method		Not present in QI Core
Negation Rationale	The reason the request was refused. Applies only if the status is refused.	QDM matched to QI Core / FHIR
Reason	An explanation or justification for why this diagnostic investigation is being requested in coded or textual form. This is often for billing purposes. May relate to the resources referred to in supportingInformation.	QDM matched to QI Core / FHIR
Author dateTime	ProcedureRequest.authoredOn	Note - ProcedureRequest.occurrence[x] defines a dateTime when the event should occur - not addressed in QDM
Code	Observation.code	See also, Observation.category
id	ProcedureRequest.id	QDM matched to QI Core / FHIR
Source	ProcedureRequest.requester	Author, orderer - note also, ProcedureRequest.requester.agent for device, practitioner or organization who initiated the request; or ProcedureRequest.requester.onBehalfOf - the organization the device or practitioner was acting on behalf of

Physical Exam, Performed

QDM Attribute	QI Core Metadata Element	Comments
Physical Exam, Performed	Observation (the .status metadata allows conformance to the specific QDM datatype context)	QDM matched to QI Core / FHIR.
Anatomical Location Site	Observation.bodySite	QDM matched to QI Core / FHIR
Method	Observation.method	QDM matched to QI Core / FHIR
Negation Rationale	Observation.dateAbsentReason	The value set is required. Many eCQMs use a measure developer-specific value set. Note, component also has a Observation.component.dataAbsentReason in QI Core.
Reason	Observation.basedOn	QDM matched to QI Core / FHIR
Reference Range High	Observation.referenceRange.high	QI Core also references Observation.referenceRange.type - i.e. what part of the referenced target population it applies to (e.g., normal or therapeutic range); and Observation.referenceRange.appliesTo - i.e., the target population (normal population, or particular sex or race), and Observation.referenceRange.age. QI Core also addresses Observation.component.referenceRange. Should these options be considered for QDM?
Result	Observation.value[x]	Note - QI Core also includes Observation.interpretation and Observation.comment - eCQMs have addressed interpretation as an implementation issue. Perhaps that approach should be reconsidered.
Relevant Period	Observation.effective[x]	QDM matched to QI Core / FHIR
Code	Observation.code	See also, Observation.category
Author dateTime	part of FHIR Provenance Resource	FHIR references authorDatetime as part of the provenance resource for all resources. Is authorDatetime still appropriate for this datatype?
	Observation.effective[x]	QDM only addresses authorTime; QI Core allows a Period. Consider addressing the difference.
Components	Observation.component	QDM uses components to combine related observations to each other, e.g., a set of independent observations performed within an admission assessment for an inpatient admission. Each observation is unique (e.g., questions about tobacco usage, other substance usage, blood pressure, pulse, skin turgor, etc., etc.) but they are captured during the same patient-provider interaction. Such QDM components should map directly to QI Core / FHIR observations that can be linked to other observations. Other QDM component examples include multiple questions that are part of a validated evaluation tool (e.g., a Braden skin assessment scale). This latter example indicates individual questions that are inherently tied to the Braden scale instrument and the questions and answers do not have inherent value without being part of the instrument. QI Core / FHIR considers each such question as an Observation.component. A general rule of thumb is QI Core / FHIR components apply only when the inherent value of the observation is defined by the parent observation. The result is that the content will determine if a QDM component maps to Observation.code or to Observation.component.code.
Component code	Observation.component.code	See "component" - content-specific
Component result	Observation.component.value[x]	See "component" - content-specific
id	Observation.id	QDM matched to QI Core / FHIR
Source	Observation.performer	Note - QI Core includes Observation.subject - QDM should consider adding subject instead of health record field.

Physical Exam, Recommended

QDM Attribute	QI Core Metadata Element	Comments
Physical Exam, Recommended	ProcedureRequest.intent	Procedure Request intent uses the concepts proposal, plan, order, original-order, reflex-order, filler-order, instance-order, option. "Proposal" is most consistent with the ProcedureRequest when applied to clinical decision support (CDS) in which the CDS proposes an action to a provider or to a patient. The QDM concept Recommended addresses expectations a provider gives to a patient. Such recommendations are most consistent with the ProcedureRequest.intent value of "plan" (an intension to ensure something occurs without providing an authorization to act).
Anatomical Location Site	ProcedureRequest.extension (approachBodySite)	QDM matched to QI Core / FHIR
Method		Not addressed in QI Core
Negation Rationale	ProcedureRequest.extension (reasonRefused)	QDM matched to QI Core / FHIR
Reason	ProcedureRequest.reasonCode	QDM matched to QI Core / FHIR
Author dateTime	ProcedureRequest.authoredOn	Note - ProcedureRequest.occurrence[x] defines a dateTime when the event should occur - not addressed in QDM
Code	ProcedureRequest.code	See also, Observation.category
id	ProcedureRequest.id	QDM matched to QI Core / FHIR
Source	ProcedureRequest.requester	Author, orderer - note also, ProcedureRequest.requester.agent for device, practitioner or organization who initiated the request; or ProcedureRequest.requester.onBehalfOf - the organization the device or practitioner was acting on behalf of

7.19.0 Procedure

QDM defines Procedure as "An Act whose immediate and primary outcome (post-condition) is the alteration of the physical condition of the subject. ... Procedure is but one among several types of clinical activities such as observation, substance-administrations, and communicative interactions ... Procedure does not comprise all acts of [sic] whose intent is intervention or treatment."⁷ 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.⁸ QDM defines three contexts for Procedure: Procedure, Order; Procedure, Performed; Procedure, Recommended.

Procedure, Order

QDM Attribute	QI Core Metadata Element	Comments
Procedure, Order	ProcedureRequest.intent	Procedure Request intent uses the concepts proposal, plan, order, original-order, reflex-order, filler-order, instance-order, option. Constrain to "order" from the intent value set for QDM datatypes with the order context.
Anatomical Approach Site	ProcedureRequest.reason	Note QI Core http://hl7.org/fhir/us/qicore/qicore-procedurerequest-appropriatenessScore.html applies to Diagnostic Study, Order when used for imaging studies. QDM identifies imaging procedures in the Diagnostic Study category.
Anatomical Location Site	ProcedureRequest.bodySite	QDM matched to QI Core / FHIR
Method		Not addressed in QI Core
Negation Rationale	ProcedureRequest.extension (reasonRefused)	QDM matched to QI Core / FHIR
Ordinality		Not addressed in QI Core
Reason	ProcedureRequest.extension (appropriatenessScore)	Suspect this code set references Appropriate Use Criteria but it is not generic to cover all procedures.
	ProcedureRequest.reasonCode
Author dateTime	ProcedureRequest.authoredOn	QDM matched to QI Core / FHIR
	ProcedureRequest.occurrence[x]	QDM matched to QI Core / FHIR
Code	ProcedureRequest.code	Corrected to link for USCore Procedure Type per Rob's comments
id		QDM matched to QI Core / FHIR
Source	ProcedureRequest.requester	Author, orderer - note also, ProcedureRequest.requester.agent for device, practitioner or organization who initiated the request; or ProcedureRequest.requester.onBehalfOf - the organization the device or practitioner was acting on behalf of

Procedure, Performed

QDM Attribute	QI Core Metadata Element	Comments
Procedure, Performed	Procedure (the .status metadata allows conformance to the specific QDM datatype context)	Device.status allows active | inactive | entered-in-error | unknown as a required value set; Procedure.status seems more appropriate - constrain the event code to "Completed"
Anatomical Approach Site	Procedure.extension (approachBodySite)	QDM matched to QI Core / FHIR
Anatomical Location Site	Procedure.bodySite	QDM matched to QI Core / FHIR
Incision dateTime	Procedure.extension (incisionDateTime)	QDM matched to QI Core / FHIR
Method		Not addressed in QI Core
Negation Rationale	Procedure.notDoneReason	QDM matched to QI Core / FHIR
Ordinality		Not addressed in QI Core
Reason	Procedure.reasonCode	QDM matched to QI Core / FHIR
Result	Procedure.outcome	QDM matched to QI Core / FHIR
Relevant Period	Procedure.performed[x]	The Procedure.Performed[x] is defined as a period so I believe it fits well.
Author dateTime	part of FHIR Provenance Resource	FHIR references authorDatetime as part of the provenance resource for all resources. Is authorDateTime still appropriate for this datatype?
Status	Procedure.status	QDM matched to QI Core / FHIR
Code	Procedure.code	QDM matched to QI Core / FHIR
Components		QDM uses components to combine related observations to each other, e.g., a set of independent observations performed within an admission assessment for an inpatient admission. Each observation is unique (e.g., questions about tobacco usage, other substance usage, blood pressure, pulse, skin turgor, etc., etc.) but they are captured during the same patient-provider interaction. Such QDM components should map directly to QI Core / FHIR observations that can be linked to other observations. Other QDM component examples include multiple questions that are part of a validated evaluation tool (e.g., a Braden skin assessment scale). This latter example indicates individual questions that are inherently tied to the Braden scale instrument and the questions and answers do not have inherent value without being part of the instrument. QI Core / FHIR considers each such question as an Observation.component. A general rule of thumb is QI Core / FHIR components apply only when the inherent value of the observation is defined by the parent observation. The result is that the content will determine if a QDM component maps to Observation.code or to Observation.component.code.
Component code		See "component" - content-specific
Component result		See "component" - content-specific
id	Procedure.id	QDM matched to QI Core / FHIR
Source	Procedure.performer	QDM matched to QI Core / FHIR

Procedure, Recommended

QDM Attribute	QI Core Metadata Element	Comments
Procedure, Recommended	ProcedureRequest.intent	Procedure Request intent uses the concepts proposal, plan, order, original-order, reflex-order, filler-order, instance-order, option. Constrain to "order" from the intent value set for QDM datatypes with the order context.
Anatomical Approach Site	ProcedureRequest.extension (approachBodySite)	Note QI Core ProcedureRequest.extension (http://hl7.org/fhir/us/qicore/StructureDefinition/qicore-procedurerequest-appropriatenessScore) - not included in QDM but may potentially apply to Appropriate Use Criteria
Anatomical Location Site	ProcedureRequest.bodySite	QDM matched to QI Core / FHIR
Method		Not addressed in QI Core
Negation Rationale	ProcedureRequest.extension (reasonRefused)	QDM matched to QI Core / FHIR
Ordinality		Not addressed in QI Core
Reason	ProcedureRequest.extension (appropriatenessScore)	Suspect this code set references Appropriate Use Criteria but it is not generic to cover all procedures.
	ProcedureRequest.reasonCode
Author dateTime	ProcedureRequest.authoredOn	Note - ProcedureRequest.occurrence(x) defines a dateTime when the event should occur - not addressed in QDM
Code	ProcedureRequest.code	See also, Observation.category
id	ProcedureRequest.id	QDM matched to QI Core / FHIR
Source	ProcedureRequest.requester	Author, orderer - note also, ProcedureRequest.requester.agent for device, practitioner or organization who initiated the request; or ProcedureRequest.requester.onBehalfOf - the organization the device or practitioner was acting on behalf of

7.20.0 Substance

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). QDM defines three contexts for Substance: Substance, Administered; Substance, Order; Substance, Recommended. Since QDM addresses substance a something that is administered, ordered or recommended, the actions are analogous to medications. Hence, the QDM category Substance is mapped to QI core Medication concepts.

Substance, Administered

QDM Attribute	QI Core Metadata Element	Comments
Substance, Administered	MedicationAdministration (the .status metadata allows conformance to the specific QDM datatype context)	QDM matched to QI Core / FHIR
Dosage	MedicationAdministration.dosage.dose	QDM matched to QI Core / FHIR
Frequency	MedicationAdministration.dosage.timing	Not addressed in QI Core
Negation Rationale	MedicationAdministration.reasonNotGiven	QDM matched to QI Core / FHIR
Reason	MedicationAdministration.reasonCode	QDM matched to QI Core / FHIR
Route	MedicationAdministration.dosage.route	QDM matched to QI Core / FHIR
Relevant Period	MedicationAdministration.effective[x]	QDM matched to QI Core / FHIR
Author dateTime	part of FHIR Provenance Resource	FHIR references authorDatetime as part of the provenance resource for all resources. Is authorDateTime still appropriate for this datatype?
Supply		Not addressed in QI Core
Code	MedicationAdministration.medication[x]	QDM matched to QI Core / FHIR
id	MedicationAdministration.id	QDM matched to QI Core / FHIR

Substance, Order

QDM Attribute	QI Core Metadata Element	Comments
Substance, Order	MedicationRequest.intent	Medication Request intent uses the concepts proposal, plan, order, original-order, reflex-order, filler-order, instance-order, option. Constrain to "order" from the intent value set for QDM datatypes with the order context.
Dosage	MedicationRequest.dosageInstruction.dose[x]	QDM matched to QI Core / FHIR
Supply	MedicationRequest.dispenseRequest.quantity	QDM matched to QI Core / FHIR
Frequency	MedicationRequest.dosageInstruction.timing	QDM matched to QI Core / FHIR
Code	MedicationRequest.medication[x]	QDM matched to QI Core / FHIR
Reason	MedicationRequest.reasonCode	QDM matched to QI Core / FHIR
Method
Negation Rationale		Medication Request in QI Core does not reference negation rationale
Refills	Refills	QDM matched to QI Core / FHIR
Route	Route	http://hl7.org/fhir/STU3/valueset-route-codes.html
Author dateTime	MedicationRequest.authoredOn	QDM matched to QI Core / FHIR
id	MedicationRequest.id	QDM matched to QI Core / FHIR
Source	MedicationStatement.requester	QDM matched to QI Core / FHIR
Recorder	MedicationRequest.recorder	Possibly addressed in FHIR provenance

Substance, Recommended

QDM Attribute	QI Core Metadata Element	Comments
Substance, Recommended	MedicationRequest.intent	Medication Request intent uses the concepts proposal, plan, order, original-order, reflex-order, filler-order, instance-order, option. "Proposal" is most consistent with the ProcedureRequest when applied to clinical decision support (CDS) in which the CDS proposes an action to a provider or to a patient. The QDM concept Recommended addresses expectations a provider gives to a patient. Such recommendations are most consistent with the MedicationRequest.intent value of "plan" (an intension to ensure something occurs without providing an authorization to act).
Dosage	MedicationRequest.dosage.dose[x]	QDM matched to QI Core / FHIR
Frequency	MedicationRequest.dosageInstruction.timing	QDM matched to QI Core / FHIR
Method		Not addressed in QI Core - consider retiring from QDM
Negation Rationale	ProcedureRequest.extension (reasonRefused)	Medication Request in QI Core does not reference negation rationale
Reason	MedicationRequest.reasonCode	QDM matched to QI Core / FHIR
Refills	Refills	QDM matched to QI Core / FHIR
Author dateTime	MedicationRequest.authoredOn	QDM matched to QI Core / FHIR
Code	MedicationRequest.medication	See also, Observation.category
id	MedicationRequest.id	QDM matched to QI Core / FHIR
Source	MedicationRequest.requester	QDM matched to QI Core / FHIR
Recorder	MedicationRequest.recorder	QDM matched to QI Core / FHIR

7.20.0 Symptom

QDM defines Symptom as an indication that a person has a condition or disease. Some examples are headache, fever, fatigue, nausea, vomiting, and pain.¹⁰ Also, 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 either a temperature-measuring device together with a recorder of the device (electronically) or an individual (healthcare provider, patient, etc.).

Symptom

QDM Attribute	QI Core Metadata Element	Comments
Symptom	Condition (the .clinicalstatus metadata allows conformance to the specific QDM datatype context)	QDM matched to QI Core / FHIR
Prevalence Period	Condition.onset[x]	QDM matched to QI Core / FHIR
	Condition.abatement[x]	QDM matched to QI Core / FHIR
Severity	Condition.severity	QDM matched to QI Core / FHIR
Code	Condition.code	QDM matched to QI Core / FHIR
id	Condition.id	QDM matched to QI Core / FHIR
Source	Condition.asserter	QDM matched to QI Core / FHIR

---

<sup>1. Derived from the device definition of the U.S. Food and Drug Administration (FDA), Department of Health and Human Services, Washington DC; 2010. Available at: http://www.fda.gov/. Last accessed August 2017.↩
2. Canada Health Infoway EHR Glossary, https://www.infoway-inforoute.ca/. Last accessed August 2017.↩
3. International Organization for Standardization (ISO), Health Informatics - Requirements for an Electronic Health Record Architecture, ISO 18308:2011. Available at: http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=52823. Last accessed August 2017.↩
4. National Cancer Institute (NCI). Bethesda, MD: NCI; 2010. Available at: www.cancer.gov/. Last accessed August 2017.↩
5. See https://www.nlm.nih.gov/research/umls/rxnorm/. Last accessed August 2017.↩
6. Definitions modeled similar to HL7 FHIR STU 3.0 - https://www.hl7.org/fhir/coverage.html.↩
7. HL7, available at: http://www.hl7.org/documentcenter/public_temp_9D8B62D1-1C23-BA17-0C978A875D9E7083/wg/java/apidocs/org/hl7/rim/Procedure.html. Last accessed August 2017.↩
8. Modified from Canada Health Infoway, available at: https://www.infoway-inforoute.ca/. Last accessed August 2017.↩
9. HL7 Fast Health Information Resources (FHIR). 1.25.2.1.279. Value Set Substance Category. DSTU 2. 24 October 2015. Available at: https://www.hl7.org/fhir/valueset-substance-category.html. Last accessed August 2017.↩
10. UMLS Dictionary, available at: http://www.nlm.nih.gov/research/umls/. Last accessed August 2017.↩
11. National Cancer Institute (NCI), Bethesda, MD; NCI 2010, available at: www.cancer.gov/. Last accessed August 2017.↩</sup>