A. Please look for Quality Data Model (QDM) events on the Electronic Clinical Quality Improvement (eCQI) landscape. The User Group coordinates the QDM contents and responds to requests for additional clarification or content from measure developers and others submitting questions or information to the ONC Project Tracking System (Jira) QDM section.  Please visit the eCQI Resource Center QDM page Connect tab to learn about QDM and to register for the QDM User Group.

A. Measure developers use the Quality Data Model (QDM) along with Clinical Quality Language (CQL) to develop electronic Clinical Quality Measures (eCQMs) in the Measure Authoring Tool (MAT) and test the eCQM logic using the Bonnie tool. The QDM documentation provides guidance for how to use the information model to express eCQM content. Please visit the Electronic Clinical Quality Improvement (eCQI) Resource Center QDM page Connect tab to learn about QDM and to register for the QDM User Group.

A. You can create an account on the ONC Project Tracking System (Jira). Once you are logged in, click Projects from the top menu bar and chose "View All Projects." Select “QDM Issue Tracker (QDM)” from the list. Click “Create” and enter any necessary details of your question or issue. 

A. Many of the acronyms are found on the Electronic Clinical Quality Improvement (eCQI) Resource Center Glossary of eCQI Terms. If you see acronyms that are not explained the Glossary, please send an email to ecqi-resource-center@hhs.gov. 

A. The current version of the Quality Data Model (QDM) is found on the QDM page About tab. Previous versions of the QDM are available on the QDM page Previous Versions tab. 

A. Quality Data Model (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. Subsequent QDM versions include only the conceptual data model. Starting with eCQMs for the 2019 reporting period, the expression logic is no longer represented using QDM. Measure developers now use Clinical Quality Language (CQL) to express logic. The current versions of QDM can be downloaded from the Electronic Clinical Quality Improvement (eCQI) Resource Center QDM page under "Find the current 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 electronic health record [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 Quality Data Model (QDM) negation rationale addresses only the third definition, sometimes called action negation. QDM includes this concept as negation rationale as an attribute of 73 QDM datatypes. Its inclusion allows a measure developer to express a measure criterion or a measure exception if the clinician expressed a reason for not performing the action expected. The QDM documentation on the Electronic Clinical Quality Improvement (eCQI) Resource Center describes how a measure developer can use negation rationale. Negation rationale is part of the current production version of QDM version 5.3 for use in 2019 reporting and version 5.4 anticipated for implementation in calendar year 2020. A discussion about negation and methods for expressing negation using Clinical Quality Language (CQL) can be found on the CQL Formatting Wiki.

A. This information is provided in the Clinical Quality Language (CQL)-based Health Quality Measure Format (HQMF) Implementation Guide (IG). This document describes constraints on the HQMF Normative edition Release 1 (HQMF R1) header and body elements for the CQL-based HQMF. Volume 3 of the IG references QDM. Note, eCQMs for the 2019 reporting period use the CQL-based HQMF STU 2.1 which references QDM version 5.3. eCQMs for the 2020 reporting period will use CQL-based HQMF STU 3.0 which references QDM version 5.4.

A. The Quality Data Model (QDM) is generally updated annually and there are currently several versions of QDM available, although each for a different Centers for Medicare & Medicaid Services (CMS) program year of measures. See the eCQM Standards and Tools Versions table on the Electronic Clinical Quality Improvement (eCQI) Resource Center on the eCQI Tools and Key Resources page for the version by reporting year.

A. The Quality Data Model (QDM) specifications provide tables for each datatype available for use. For more information, visit the QDM page on the Electronic Clinical Quality Improvement (eCQI) Resource Center, and retrieve the correct version of the specifications under "Find the current QDM".

A. No, “Medication, not Administered” 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 electronic health record [EHR] will not include the order itself). In the Quality Data Model (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. Additionally, the prior versions of Quality Reporting Document Architecture (QRDA) required that a specific medication be chosen as the one not administered. The issue required a number of discussions in the Health Level Seven International (HL7) Clinical Quality Information Workgroup 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 and subsequent versions allow an 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. 

A. "Encounter, Active" was removed from the Quality Data Model (QDM) in version 5.3 since it was basically no different from an "Encounter, Performed" that started but has not yet completed.

A. The intent of the recommended action is 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 electronic health records (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 Quality Data Model (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. 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.

A. The Quality Data Model (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 electronic health record [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 electronic clinical quality measures (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.

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.

A. There has been significant discussion about determining attribution and potentially understanding the person or device responsible for a given Quality Data Model (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:

• 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 commenting that 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.
Based on the need for implementing a specific measure, the measure developer can address the identifier most appropriate.
Beginning with eCQMs developed for the 2020 reporting period, QDM 5.4 includes two new attributes that allow specification of prescriber identifier for "Medication, Order", "Medication, Dispensed", and "Medication, Discharge" and dispenser identifier for "Medication, Dispensed". These new attributes allow measures to address individual medication prescribers or dispensers.

A. There are no formatting conventions specific to the Quality Data Model (QDM), the QDM specification should be reviewed for specific guidance on using the datatpes and attributes in the conceptual model. However, there is information on conventions for formatting statements and expressions in Clinical Quality Language (CQL) which encourage consistency, readability, maintainability, and reusability of the resulting CQL.These conventions can be  found on the CQL Formatting and Usage Wiki. Additionally, CMS has published a CQL Style Guide, based on the Formatting and Usage Wiki contents, which focuses on a set of common best practices implemented across CQL-based electronic clinical quality measures (eCQMs) in the Centers for Medicare & Medicaid Services (CMS) reporting programs and also promotes the use of consistent language within the framework of CQL, including libraries, aliases, definitions, functions and conventions. Measure stewards or developers who are developing or specifying eCQMs for future inclusion in CMS programs should align with these best practices.

A. The Quality Data Model (QDM) is a conceptual data model that helps measure developers and implementers understand the general concepts needed to compute a quality measure. However, QDM only defines the concepts, such as a diagnosis, or a laboratory test (with a result), or a physical examination finding (such as blood pressure readings). A method to relate each concept to other concepts requires an expression language. As an example, the QDM data element is similar to a noun in expressing grammar (e.g., a laboratory test) and related adjectives (the time the laboratory test was performed). But to create a sentence, one must have verbs (e.g., starts) and adverbs (after the beginning of). The expression language provides the verbs and adverbs. Prior versions of QDM (version 4.3 and earlier) included the expression language and the conceptual data model. The expression language portion of QDM was difficult to understand and more challenging to compute. So, Clinical Quality Language (CQL) was developed as a way to express what was needed. CQL can express that some specific activity happened during an inpatient encounter and that it happened before another activity. However, CQL needs a data model to indicate what is related to what.

• CQL defines the expression – i.e., the relationship between item A and item B
• QDM defines the items
• CQL can work with other data models. It is not restricted to QDM. However, in the current Centers for Medicare & Medicaid Services (CMS) measure development activities, QDM is the chosen data model to work with CQL. Other projects could consider other data models. 

In the Health Level Seven International (HL7) community, efforts have progressed to try to define a standard data model. One effort reviewed the QDM and also a data model created by the Clinical Decision Support Workgroup called virtual medical record (vMR). After coordinating the concepts from QDM and vMR, the HL7 effort created a new model, based on the Fast Health Interoperability Resources (FHIR) content. This new model is called Quality Improvement (QI) Core – the FHIR extension that describes how to use FHIR resources to express a quality measure or a clinical decision support artifact. However, QI Core is not something that can be used directly in a computer model. So tooling was developed to create a model that can be used to help author measures or clinical decision support artifacts. The QI Core model thus appears in a logical view for use – that logical view is called QUICK (Quality Improvement and Clinical Knowledge). So, QI Core is the FHIR-based data model and QUICK is a more usable view and version of QI Core. However, QUICK (which is also logical view of QI Core) represents the nouns and CQL expression language is needed to create full queries.

Thus, CQL and QDM is currently in use to create quality measures in the CMS activities for electronic clinical quality measures (eCQMs). CQL and QUICK (which is also logical view of QI Core) can be used to create eCQMs and clinical decision support artifacts. Note that using QUICK requires that the system implemented must be able to understand HL7 FHIR. QUICK provides some ‘extensions’ to FHIR by further clarifying some of the metadata (adjectives) to help make the descriptions clearer.

A. Yes, the Measure Authoring Tool (MAT) is a web-based tool that allows measure developers to author electronic clinical quality measures (eCQMs) using the Quality Data Model (QDM) to represent clinical concepts and Clinical Quality Language (CQL) to represent the logic. The tool provides the capability to export measures in several formats that support both human- and machine-reading. Refer to the MAT User Guide for more information.