This page is part of the Quality Improvement Core Framework (v3.2.0: STU 3) 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
The CQI Workgroup reviewed the mapping to QDM version 5.3 in April 2018. The content is updated on June 7, 2018 based on QDM version 5.4. The changes based on QDM 5.4 include:
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.
QDM Attribute | QI Core Metadata Element | Comment |
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 (http://hl7.org/fhir/us/qicore/StructureDefinition/qicore-procedurerequest-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 |
Negation Rationale | ProcedureRequest.extension (http://hl7.org/fhir/StructureDefinition/procedurerequest-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 Note: FHIR Provenance generally addresses the author of the message; the identifier/source of the original resource element is defined by the resource. Individual resource element provenance is summarized in the FHIR W5 Report (http://hl7.org/fhir/w5.html). |
Code | ProcedureRequest.code | QDM matched to QI Core / FHIR |
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 |
QDM Attribute | QI Core Metadata Element | Comment |
Physical Exam, 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 Location Site | ProcedureRequest.extension (http://hl7.org/fhir/us/qicore/StructureDefinition/qicore-procedurerequest-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 |
Negation Rationale | ProcedureRequest.extension (http://hl7.org/fhir/StructureDefinition/procedurerequest-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 Note: FHIR Provenance generally addresses the author of the message; the identifier/source of the original resource element is defined by the resource. Individual resource element provenance is summarized in the FHIR W5 Report (http://hl7.org/fhir/w5.html). |
Code | ProcedureRequest.code | QDM matched to QI Core / FHIR |
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 |
QDM Attribute | QI Core Metadata Element | Comment |
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 | Observaton.method | QDM matched to QI Core / FHIR |
Relevant Period | observation.effective.x | QDM matched to QI Core / FHIR |
Negation Rationale | Observation.dataAbsentReason | 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 | Observaton.basedOn | QDM matched to QI Core / FHIR |
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. |
Author dateTime | Observation.issued | QDM matched to QI Core / FHIR Note: FHIR Provenance generally addresses the author of the message; the identifier/source of the original resource element is defined by the resource. Individual resource element provenance is summarized in the FHIR W5 Report (http://hl7.org/fhir/w5.html). |
Status | Procedure.status | QDM matched to QI Core / FHIR |
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 |
Code | Observation.code | QDM matched to QI Core / FHIR |
id | Observation.id | QDM matched to QI Core / FHIR |
Source | Observation.performer | QDM matched to QI Core / FHIR |