QI-Core Implementation Guide: STU 3.2 (v3.2.0 for FHIR 3.0.1)
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 content on this page was updated based on review by the CQI Workgroup Conference call on April 6, 2018 with reference to QDM 5.3. The content presented here is updated to QDM version 5.4. QDM version 5.4 removed the "method" attribute from "Diagnostic Study, Order" and "Diagnostic Study, Recommended" but retained the "method" attribute for "Diagnostic Study, Performed". There are no other changes in QDM version 5.4 as compared to QDM version 5.3.
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.
| QDM Attribute | QI Core Metadata Element | Comment |
| 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. |
| Negation Rationale | ProcedureRequest.extension (http://hl7.org/fhir/StructureDefinition/procedurerequest-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 | QDM matched to QI Core/FHIR. 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 | 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 on whose behalf the device or practitioner was acting |
| QDM Attribute | QI Core Metadata Element | Comment |
| 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). |
| Negation Rationale | ProcedureRequest.extension (http://hl7.org/fhir/StructureDefinition/procedurerequest-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 | QDM matched to QI Core/FHIR. 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 | 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 on whose behalf the device or practitioner was acting |
| QDM Attribute | QI Core Metadata Element | Comment |
| 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. |
| FacilityLocation | DiagnosticReport.extension (diagnosticReport-locationPerformed) | QDM matched to QI Core / FHIR |
| Method | ImagingStudy.modalityList.code | QDM matched to 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 addresses a Period; QI Core allows an effective time. 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 | DiagnosticReport.issued | QDM matched to FHIR / QI Core – Note: QDM only addresses authorTime; 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). The FHIR Observation resource uses .issued for author time. QI Core also allows a Period during which an observation actually occurs (observation.effective[x]). 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 discharge dateTime to define the Relevant Period). Such concepts would use observation.effective[x]. QDM does not address the time for which the experience is evaluated. Such a concept might be a new consideration for QDM |
| 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 | DiagnosticReport.id | QDM matched to QI Core / FHIR |
| Source | DiagnosticReport.performer | Source is addressed by either DiagnosticReport.performer or Observation.device |
| QDM Attribute | QI Core Metadata Element | Comment |
| 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 (diagnosticReport-locationPerformed) | QI Core observation does not specify a facility location. FHIR provenance may provider guidance. |
| Method | Observaton.method | 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 | 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 addresses a Period; QI Core allows an effective time. 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 | Observation.issued | QDM matched to FHIR / QI Core – Note: QDM only addresses authorTime; 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). The FHIR Observation resource uses .issued for author time. QI Core also allows a Period during which an observation actually occurs (observation.effective[x]). 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 discharge dateTime to define the Relevant Period). Such concepts would use observation.effective[x]. QDM does not address the time for which the experience is evaluated. Such a concept might be a new consideration for QDM |
| 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 |
© HL7.org 2011+. Package hl7.fhir.us.qicore#3.2.0 based on FHIR v3.0.1-11917. Generated on 14/04/2019
Links: Search |
QA Page |
|
Propose a change