Quality Data Model (QDM) Qs&As
Q. Where is the eCQI Resource Center?
Q. How do we sign up for the QDM measure development workgroups? How do I sign up for the upcoming QDM events?
A. The CQM QDM is coordinated by a QDM User Group that responds to requests for additional clarification or content from measure developers and others submitting information to the ONC JIRA tracking system QDM section. Please visit the eCQI Resource Center QDM page for further information and to register for the QDM User Group.
Q. How does a person get involved in the QDM project testing, developing measures in QDM?
A. Measure developers use QDM to develop eCQMs in the Measure Authoring Tool (MAT). The QDM documentation provides guidance for how to use the information model to express eCQM content. Please visit the eCQI Resource Center QDM page to learn about QDM and to register for the QDM User Group.
Q. Where do I post any questions or issues I may have with the QDM expression logic?
A. You can create an account on the ONC JIRA tracking system at oncprojectracking.healthit.gov. Once you are logged in, click Projects from the top menu bar and chose “QDM Issue Tracker (QDM)” from the dropdown menu. Click “Create” and enter any necessary details of your question or issue. Alternatively, you can email your question to firstname.lastname@example.org.
Q. Is there a glossary of all the abbreviations for those of us that are novices?
A. Many of the acronyms are found on the eCQI Resource Center Glossary of eCQI Terms. We will be updating and adding new terms relating to the QDM measure in the future. If you see acronyms that are not explained the Glossary, please send us a note at email@example.com.Back to top
Quality Data Model (QDM)
Q. What is the QDM?
A. The QDM is an information model that defines relationships between patients and clinical concepts in a standardized format to enable electronic quality performance measurement. The model is the current structure for electronic clinical quality measures (eCQM) and reporting.
Q. Where can I find the most current QDM version?
A. All versions of the QDM, except the Draft version for use with Clinical Quality Language (CQL), are available on the QDM page on the eCQI Resource Center.
Q. What is the difference between QDM version 4.3 and 5.0, 5.01 and 5.02?
A. QDM version 4.3 includes both the conceptual data model (the categories and their context of use) and the expression logic to state measure clauses. A future effort will remove the expression logic from QDM and use Clinical Quality Language (CQL) instead. QDM 5.0 provides the QDM conceptual model for use with CQL expression logic and is available on the CQL page of the eCQI Resource Center. Note that modifications to QDM for use with CQL includes more explicit definitions that were previously understood, but perhaps less computable. QDM 5.0 and above are currently identified as Draft QDM for CQL usage. As CQL testing progresses, iterative modifications to the Draft QDM have included minor changes as QDM 5.01 and QDM 5.02. The MAT CQL testing application available in Fall 2016 uses QDM 5.0; the MAT CQL testing application update in January 2017 will use QDM 5.02. Further iterations in QDM for use with CQL should be expected as testing progresses.
Q. Where can I get information on Negation in QDM?
A. Negation has several aspects: (a) assurance that a certain condition does not exist (e.g., no known allergies); (b) lack of evidence that a condition does not exist (e.g., no information is available in the EHR about allergies); and (c) that an action was intentionally not performed, with or without a reason (e.g., medication was not prescribed due to interaction with other medications a patient is taking). The QDM negation rationale addresses only the third definition, sometimes called action negation. QDM includes this concept as negation rationale as an attribute of 37 QDM datatypes. Its inclusion allows a measure developer to express a measure criteria or a measure exception if the clinician expressed a reason for not performing the action expected. The QDM documentation on the eCQI Resource Center describes how a measure developer can use negation rationale. Negation rationale is part of the current production version of QDM (version 4.3) and subsequent draft versions for use with CQL logic. A discussion about negation and methods for expressing negation using CQL can be found on the CQL Formatting Wiki
Q. Is there a way to provide a standard structure to construct a quality measure including metadata, data criteria, population criteria, etc. based on the QDM?
A. This information is provided in the QDM-based HQMF R2 Implementation Guide (IG) version 1.4. This document describes constraints on the Health Quality Measure Format Release 2 (HQMF R2) header and body elements for the Quality Data Model (QDM)-based HQMF.
Q. How do you know which version of the QDM you are using?
A. There are currently several versions of QDM available. The measures created and published in 2016 for reporting in 2017 use QDM 4.2. Efforts are underway to create measures to be published in 2018. The QDM is updated as needed – often that means annually but only as needed. Check back soon with the eCQI Resource Center for the version to be used in 2019 reporting.
Q. Where do we find what attributes exist for a particular element like Encounters, Performed?
A. The data model for QDM specifies that information. For more information, visit the QDM page on the eCQI Resource Center.
Q. Does "medication, administered not done" imply an order was placed?
A. No, “Medication, Administered, not done” indicates only that the medication was not administered. While most medications may require orders to be placed prior to administration, that is not necessarily true of all medications (e.g., those with standing orders such that the EHR will not include the order itself). In QDM, negation indicates that an action did not occur for a reason. It indicates that the clinician recorded that he/she did not administer a medication. In the first implementation of electronic clinical quality measures (eCQMs), measure concepts that allowed negation used the same medication value set to represent the type of medications not administered. However, the prior versions of QRDA required that a specific medication be chosen as the one not administered. The issue required a number of discussions in HL7 about how to represent an action that was not performed for any of the elements in the order set. An interim practice used a medication value set listing the medication ingredient, thus a smaller value set. However, the issue of selecting a single agent remained. QRDA Category 1 version R4 allows indication that the action did not occur for any of the elements of the medication value set. Therefore, the current measure reporting allows negation at the level of the medication category.
Q. What does the Encounter, Active datatype mean and how is it different from an Encounter, Performed?
A. Encounter, Active is used to address an encounter that remains in progress, i.e., it has started and has not ended. The User Group strongly believed that Encounter, Active is needed within measure logic. We welcome further input and discussion about whether Encounter, Performed with a start date and no end date might represent the same information in the expression logic.
Q. Can you clarify what recommended means?
A. The intent of the recommended action is intended to represent the healthcare provider's proposal to the patient about a specific treatment or action. The meaning is somewhat implicit. A standard method does not seem to be present for representing recommendations in EHRs. In many cases recommendations exist in narrative text rather than structured fields. A very direct method to address recommendations might be an order for the expected action. If the patient chooses to reject the recommendation, the order will not be fulfilled; however, the order represents the intent in a structured format. Many QDM users reject the proposal to use the order action since clinicians place orders intending them to be fulfilled. Hence, nine QDM datatypes include the recommended context. QDM addresses recommendations from one clinician to another (such as in a consult report) as Communication, Provider to Provider. The recommend context was not created to address a recommendation from the EHR clinical decision support process to a clinician. We welcome further discussion and input regarding modeling the clinical decision support recommendation to a clinician (or possibly a patient) and the feasibility of such activity in existing EHRs.
Q. What are QDM data flow attributes and how is the health record field used?
A. The QDM includes data flow attributes to address the source (originator of information), the recorder (the individual role or software system that entered the information into the EHR), and the health record field. The health record field was initially intended to indicate where or how the EHR is expected to record the information. As eCQMs and clinical software systems have evolved, the source and recorder remain relevant, but access to such information is not necessarily straightforward or feasible. The health record field attribute may generally indicate the type or class of information desired rather than the specific EHR location for that data. However, the QDM datatype defines the class and context of information and the health record field may be overly prescriptive. The QDM User Group will review these issues in a future meeting.
Q. What is the meaning of Medication, Discharge and how is it different from Medication, Active and Medication, Order?
A. Medication, Discharge defines medications intended for use when the patient leaves the hospital. Medication, Active is not necessarily representative of this concern as clinicians do not deactivate hospital medications at the time of discharge. Therefore, items on the hospital active medication list when the patient is discharged may not be continued in subsequent settings. Medication, Order is also problematic as clinicians may also order some medications to be administered immediately prior to discharge. Further, although some discharge medications are ordered (or prescribed) others may already be present in the home setting and still others may be over-the-counter substances for which orders are unnecessary. Hence, Medication, Discharge refers to medications that have been reconciled and are listed on the patient’s Discharge Medication List. It should not be confused with medications that happen to be active at the time of discharge. “Medication, Discharge” events should start and end within the time duration of the episode of care, even though the medication itself may not be started until after the episode ends. It is expected that, at the time of discharge, discharge medications will be the same as the subsequent home medication lists for those medications that are germane to the quality measure, but this cannot be assumed at the time of admission as changes may have occurred since the prior episode of care.
Q. How can measure developers model the prescriber for medication, or the type of provider that performed a task?
A. There has been significant discussion about determining attribution and potentially understanding the person or device responsible for a given QDM data element. Use cases include the one listed in this comment, the "prescriber" of a medication order. Other use cases include assurance that the patient is the informant and possibly also the recorder of patient reported outcome information.
QDM Dataflow Attributes
The QDM dataflow attributes were designed to capture information handling provenance, referring to the origin of data. These dataflow attributes include:
- Health Record Field: The location within an electronic record where the data should be found.
- Source: The originator of the quality data element. The source may be an individual or a device.
- Recorder: The individual or device that enters the data element into a health record field. The desired recorder also may be, but is not necessarily, the source of the data.
The QDM User Group discussed these dataflow attributes on May 18, 2016 with the following comments:
1. Health record field is redundant and may be overly prescriptive. The QDM datatype provides sufficient guidance to allow the EHR vendor or the local implementation site to determine the most appropriate “health record field(s)” that contain the relevant data. Some User Group members suggested there may be some future benefit to be prescriptive, but no examples exist at present.
2. Source may be ambiguous. The intent is to address the informant, which may be a better term. A clearer definition may also help. One example explains the informant as the patient even though the recorder of the information may be a caregiver or clinician. For the medication order example, the provider would be the source or informant.
3. Recorder seems well described.
Actually identifying the source/informant or recorder of a data element is not straightforward, especially if the information did not originate within the EHR reporting it. The Health Information Technology Standards Committee reviewed work from the Standards and Interoperability Data Provenance Initiative and recommended actions to enhance the availability of data provenance. The transmittal letter from the Committee to ONC can be found here: https://www.healthit.gov/facas/sites/faca/files/HITSC_Data_Provenance_Transmittal2015-02-12.pdf. Some of the issues regarding provenance with respect to providers include:
1. There is no standard value set for provider roles (and, in fact, for administration of medication and other datatypes such roles need to include the patient and caregivers in addition to providers)
2. The Measure Authoring Tool (MAT) allows a measure developer to select source as an attribute, but implementers aren't able to find the information so it fails feasibility testing.
3. A measure developer could, potentially, use the National Provider Identifier Index as a value set to get a report back with the provider who ordered or administered the medication. However, if the use case is to assure the provider represents a specific role or specialty, the identifier would need to be cross-checked against a file of specialties to determine if the order or administration occurred with the expected specialty. For some conditions a specialty may be too broad in one sense and too narrow a net in another sense. For example: A provider that treats active hepatitis C may be a Gastroenterologist, but the provider might be a general internist. However, not all Gastroenterologists may treat active hepatitis, nor do all internists. So, the problem is complex.
Currently, SNOMED CT has concepts for provider roles, but it is not complete and a clear use case for developing a value set and groups to use it need to be clarified. From the perspective of QDM, the "source" dataflow attribute may be sufficient, but we look for additional input from others following this issue. Additional input on the need for a healthcare role value set is also invited.Back to top
Quality Data Model (QDM) for use with Clinical Quality Language (CQL)
Q. Where can I find the Draft QDM version for use with Clinical Quality Language (CQL)?
A. The QDM conceptual model for use with CQL expression logic is available on the CQL page on the eCQI Resource Center. A future effort will remove the expression logic from QDM and use Clinical Quality Language (CQL) instead. Note that modifications to QDM for use with CQL includes more explicit definitions that were previously understood, but perhaps less computable. This version is identified as Draft QDM for CQL usage. As CQL testing progresses, iterative modifications to the Draft QDM should be expected.
Q. Where can I get information on QDM Related Formatting Conventions for developing CQL logic?
A. The link to the CQL Formatting and Usage Wiki can be found here
Q. How is CQL logic different from QDM logic?
A. The QDM logic is built from definitions in the HL7 version 3 Reference Information Model (RIM). The RIM was developed for defining information used in direct patient care; it has limited analytic capabilities. The QDM logic does not allow simple calculations such as addition, subtraction, multiplication, and division. Clinical Quality Language (CQL) was developed to allow such basic and more complex relationships among different data elements in a clinical quality measure or clinical decision support expression. CQL also allows more expressive clauses. The QDM structure currently does not allow a clause to specify an attribute of an attribute. For example, for Encounter, Performed: Ambulatory Visit can ask for an attribute diagnosis (i.e., a diagnosis present during the encounter); however, its logic structure does not allow a request for the onset date for that diagnosis attribute. Such a model can be described as flat; it does not allow for attributes to have a complex type. Every attribute must be a date, code, number, string, etc. This limitation is demonstrated in the "Encounter, Performed" data type attributes:
- facility location
- facility location arrival datetime
- facility location departure datetime
CQL allows complex attributes to be easily traversed using dot notation. Using the example above, instead of having the three attributes, "Encounter, Performed" could have a single "facility location" attribute that is of a complex type having the following sub attributes:
- arrival datetime
- departure datetime
In CQL, you could access them like this:
["Encounter, Performed": "Inpatient"] E
where E."facility location"."arrival datetime" during
This approach would be especially valuable in representing encounter diagnoses and principal procedures (although that is admittedly a more significant change than facility location).
Q. What is the driving benefit of CQL in eCQMs instead of QDM logic and does it justify extensive vendor resources to re-write parsing tools?
A. CQL logic increases accuracy and the ability to share between decision support rules and quality measures, and makes it easier to build language processing applications. CQL benefits include: modularity, computability, flexibility, robust logic expression, and reduced duplicative work for vendors and developers. CMS and contracting partners are working with measure developers, implementers, vendors, and owners of the various eCQM tools to test, develop, and evolve the CQL standard to be most effective with eCQMs. Visit the eCQI Resource Center for more information and for information about joining the QDM User Group.
Q. Is there a conversion from QDM to CQL?
A. There is a process to translate QDM expressions into CQL. However, one of the primary design goals of CQL is to make it easier to express complex relationships that are difficult or impossible to express in QDM. As a result, it is often the case that the best approach will be a manual translation of the intent of any given query, rather than an automated translation.
Q. When is CQL going to be in effect?
A. CQL is available now as a draft. The timeline for incorporating it in specifications is in process.
Q. Is CQL to replace HQMF for writing eCQMs?
A. Currently HQMF uses HL7 Reference Information Model (RIM) templates to express each QDM datatype. HQMF, not CQL, describes the structure of a measure. The QDM-based HQMF Implementation Guide uses the QDM version that includes the logic and conceptual data model components. The CQL-based HQMF Implementation Guide describes how to use CQL to express the logic of a measure and QDM to describe each data element. Both Implementation Guides use HQMF to represent the structure of the measure and metadata involved.Back to top
Tooling and Implementation
Q. Is QDM incorporated into the Measure Authoring Tool (MAT)?
A. The MAT is a web-based tool that allows measure developers to author eCQMs using the QDM. The tool provides the capability to express measure logic and export measures in several formats, including a human-readable document that can be viewed in a web browser (HTML), the eCQM XML syntax (SimpleXML – Production version of MAT), and an eCQM XML document for integration with electronic health records (HQMF). Measure developers use both Bonnie and MAT to promote test driven development. Refer to the MAT User Guide for more information.Back to top