read the attachment and answer the question

profileSauraha1996
qdm_4_2.pdf

Centers for Medicare & Medicaid Services Office of the National Coordinator for Health Information Technology

Quality Data Model, Version 4.2

August 31, 2015

CMS / ONC

Quality Data Model, Version 4.2 i August 31, 2015

Record of Changes

Version Date Author / Owner Description of Change CR # 4.0 April 25, 2014 The MITRE Corporation Updated for MU3 measure

development N/A

4.1 July 25, 2014 The MITRE Corporation Updated for MU3 measure development

N/A

4.1.1 September 16, 2014 The MITRE Corporation Updated for MU3 measure development

N/A

4.1.2 January 13, 2015 The MITRE Corporation Updated for MU3 measure development

N/A

4.2 August 31, 2015 The MITRE Corporation Updated for MU3 measure development

N/A

CR: Change Request

CMS / ONC

Quality Data Model, Version 4.2 ii August 31, 2015

Table of Contents

1. Introduction .................................................................................................................. 1 1.1 Background ......................................................................................................................1 1.2 Purpose .............................................................................................................................1 1.3 Vision ...............................................................................................................................1 1.4 Scope ................................................................................................................................2 1.5 Audience ...........................................................................................................................2 1.6 Document Organization ...................................................................................................2

2. Data Model .................................................................................................................... 3 2.1 QDM Basics .....................................................................................................................3 2.2 Category ...........................................................................................................................3 2.3 Datatype ...........................................................................................................................3 2.4 Attribute ...........................................................................................................................3

2.4.1 Datatype-Specific Attributes.................................................................................3 2.4.2 Data Flow Attributes .............................................................................................3

2.5 QDM Element ..................................................................................................................4 2.6 Code System .....................................................................................................................5 2.7 Value Sets .........................................................................................................................5

2.7.1 Value Sets that Define QDM Categories ..............................................................5 2.7.2 Value Sets that Define QDM Attributes ...............................................................5 2.7.3 Value Set Groupings .............................................................................................6

2.8 Specific Occurrences ........................................................................................................6 2.8.1 Simple Usage of Specific Occurrences .................................................................7 2.8.2 Multiple Specific Occurrences of the Same Event Type ......................................7 2.8.3 Multiple Specific Occurrences of Different Event Types ....................................7 2.8.4 Specific Occurrences in OR Clauses and Negations ............................................8 2.8.5 Specific Occurrences between Populations ..........................................................8

2.9 Variables ...........................................................................................................................9 2.10 Inline Comments ............................................................................................................10

3. Logic ............................................................................................................................ 11 3.1 Attribute Filters ..............................................................................................................11

3.1.1 Filter by Existence of a Recorded Value ............................................................11 3.1.2 Filter by Value Set ..............................................................................................11 3.1.3 Filter by Scalar Value or Physical Quantity .......................................................11 3.1.4 Filter by Date ......................................................................................................12

3.2 Functions ........................................................................................................................12 3.2.1 Min ......................................................................................................................12 3.2.2 Max .....................................................................................................................12 3.2.3 Median ................................................................................................................13 3.2.4 Average ...............................................................................................................13 3.2.5 Count ...................................................................................................................14 3.2.6 Sum .....................................................................................................................14

CMS / ONC

Quality Data Model, Version 4.2 iii August 31, 2015

3.2.7 Age At .................................................................................................................14 3.2.8 DateTimeDiff ......................................................................................................14

3.3 Subset Operators ............................................................................................................15 3.3.1 Sort Order for QDM Events................................................................................15 3.3.2 First .....................................................................................................................15 3.3.3 Second .................................................................................................................15 3.3.4 Third....................................................................................................................16 3.3.5 Fourth ..................................................................................................................16 3.3.6 Fifth .....................................................................................................................16 3.3.7 Most Recent ........................................................................................................17 3.3.8 Intersection Of ....................................................................................................17 3.3.9 Union Of .............................................................................................................18 3.3.10 Satisfies Any .......................................................................................................18 3.3.11 Satisfies All .........................................................................................................19

3.4 Logical Operators ...........................................................................................................20 3.4.1 And......................................................................................................................20 3.4.2 Or .......................................................................................................................20 3.4.3 Not ......................................................................................................................20

3.5 Comparison Operators ....................................................................................................21 3.5.1 Equal To ..............................................................................................................21 3.5.2 Less Than ............................................................................................................21 3.5.3 Less Than Or Equal To .......................................................................................22 3.5.4 Greater Than .......................................................................................................22 3.5.5 Greater Than or Equal To ...................................................................................22

3.6 General Relationship Operators .....................................................................................23 3.6.1 Fulfills .................................................................................................................23

3.7 Temporal Operators ........................................................................................................23 3.7.1 Starts Before Start Of ..........................................................................................23 3.7.2 Starts After Start Of ............................................................................................23 3.7.3 Starts Before End Of ...........................................................................................23 3.7.4 Starts After End Of .............................................................................................24 3.7.5 Starts Concurrent With .......................................................................................24 3.7.6 Starts Concurrent With End Of ...........................................................................24 3.7.7 Starts Before Or Concurrent With Start Of ........................................................24 3.7.8 Starts After Or Concurrent With Start Of ...........................................................25 3.7.9 Starts Before Or Concurrent With End Of..........................................................25 3.7.10 Starts After Or Concurrent With End Of ............................................................25 3.7.11 Starts During .......................................................................................................25 3.7.12 Ends Before Start Of ...........................................................................................26 3.7.13 Ends After Start Of .............................................................................................26 3.7.14 Ends Before End Of ............................................................................................26 3.7.15 Ends After End Of ..............................................................................................26 3.7.16 Ends Concurrent With ........................................................................................26 3.7.17 Ends Concurrent With Start Of ...........................................................................27 3.7.18 Ends Before Or Concurrent With End Of ...........................................................27 3.7.19 Ends After Or Concurrent With End Of .............................................................27

CMS / ONC

Quality Data Model, Version 4.2 iv August 31, 2015

3.7.20 Ends Before Or Concurrent With Start Of..........................................................27 3.7.21 Ends After Or Concurrent With Start Of ............................................................28 3.7.22 Ends During ........................................................................................................28 3.7.23 Concurrent With .................................................................................................28 3.7.24 During .................................................................................................................28 3.7.25 Overlaps ..............................................................................................................29 3.7.26 Null Date/Time Comparisons in Temporal Operators ........................................30

3.8 Operator Precedence ......................................................................................................30

4. Component Definitions .............................................................................................. 32 4.1 Categories and Datatypes ...............................................................................................32

4.1.1 Care Experience ..................................................................................................32 4.1.2 Care Goal ............................................................................................................32 4.1.3 Communication ...................................................................................................33 4.1.4 Condition/Diagnosis/Problem .............................................................................33 4.1.5 Device .................................................................................................................34 4.1.6 Diagnostic Study .................................................................................................35 4.1.7 Encounter ............................................................................................................37 4.1.8 Family History ....................................................................................................38 4.1.9 Functional Status.................................................................................................38 4.1.10 Immunization ......................................................................................................39 4.1.11 Individual Characteristic .....................................................................................40 4.1.12 Intervention .........................................................................................................41 4.1.13 Laboratory Test ...................................................................................................42 4.1.14 Medication ..........................................................................................................43 4.1.15 Physical Exam.....................................................................................................45 4.1.16 Procedure ............................................................................................................46 4.1.17 Risk Category/Assessment .................................................................................47 4.1.18 Substance ............................................................................................................48 4.1.19 Symptom .............................................................................................................49 4.1.20 Transfer of Care ..................................................................................................49

4.2 Attributes ........................................................................................................................50

Appendix A. Time Unit and Time Interval Definitions ............................................... 60

Appendix B. Time Interval Calculation Conventions .................................................. 63 B.1 Time Interval Calculations .............................................................................................63 B.2 Timing Relationships with No Calculation Unit Defined ..............................................69

Appendix C. Cumulative Medication Duration ............................................................ 71 C.1 Cumulative Medication Duration in the QDM Datatypes..............................................71 C.2 Representing Cumulative Medication Duration in the QDM ........................................71 C.3 Limitations of the Current Representation in QDM .......................................................72

C.3.1 Imprecision of Calculation Time Span ...............................................................72 C.3.2 Restriction to Calculation Over One Value Set ..................................................74 C.3.3 Unreliability of Dispense Data ...........................................................................74

CMS / ONC

Quality Data Model, Version 4.2 v August 31, 2015

C.4 Providing Measure-Level Guidance ...............................................................................74

Appendix D. Change Log ................................................................................................ 75 D.1 Changes in QDM 4.2 ......................................................................................................75 D.2 Changes in QDM 4.1.2 ...................................................................................................75 D.3 Changes in QDM 4.1.1 ...................................................................................................75 D.4 Changes in QDM 4.1 ......................................................................................................75 D.5 Changes in QDM 4.0 ......................................................................................................76

Acronyms .......................................................................................................................... 78

List of Figures

Figure 1. QDM Element Structure .................................................................................................. 4

Figure 2. Ideal Cumulative Medication Duration Calculation ...................................................... 72

Figure 3. Cumulative Medication Duration Using During ........................................................... 73

Figure 4. Cumulative Medication Duration Using Overlaps ........................................................ 73

Figure 5. Cumulative Medication Duration Using Starts During ................................................. 73

List of Tables

Table 1. Examples of Inputs and Results for Overlaps ................................................................. 29

Table 2. Operator Precedence ....................................................................................................... 30

Table 3. Care Experience Datatypes and Attributes ..................................................................... 32

Table 4. Care Goal Datatype and Attributes ................................................................................. 33

Table 5. Communication Datatypes and Attributes ...................................................................... 33

Table 6. Condition/Diagnosis/Problem Datatypes and Attributes ................................................ 34

Table 7. Device Datatypes and Attributes .................................................................................... 34

Table 8. Diagnostic Study Datatypes and Attributes .................................................................... 36

Table 9. Encounter Datatypes and Attributes ............................................................................... 37

Table 10. Condition/Diagnosis/Problem Datatypes and Attributes .............................................. 38

Table 11. Functional Status Datatypes and Attributes .................................................................. 39

Table 12. Immunization Datatypes and Attributes ....................................................................... 39

CMS / ONC

Quality Data Model, Version 4.2 vi August 31, 2015

Table 13. Individual Characteristic Datatypes and Attributes ...................................................... 40

Table 14. Intervention Datatypes and Attributes .......................................................................... 41

Table 15. Laboratory Test Datatypes and Attributes .................................................................... 42

Table 16. Medication Datatypes and Attributes ........................................................................... 43

Table 17. Physical Exam Datatypes and Attributes ...................................................................... 45

Table 18. Procedure Datatypes and Attributes ............................................................................. 46

Table 19. Risk Category/Assessment Datatypes and Attributes ................................................... 47

Table 20. Substance Datatypes and Attributes ............................................................................. 48

Table 21. Symptom Datatypes and Attributes .............................................................................. 49

Table 22. Transfer of Care Datatypes and Attributes ................................................................... 50

Table 21. Attribute Definitions ..................................................................................................... 50

Table A1. Time Unit and Interval Definitions .............................................................................. 60

Table B1. Time Interval Calculations ........................................................................................... 64

CMS / ONC

Quality Data Model, Version 4.2 1 August 31, 2015

1. Introduction

1.1 Background In 2009, the National Quality Forum convened the Health Information Technology Expert Panel, which established the Quality Data Model (QDM) to enable electronic clinical quality expressions for measurement. The QDM was developed at the request of the American Health Information Community and the Office of the National Coordinator for Health Information Technology (ONC), with funding from the Agency for Healthcare Research and Quality (AHRQ). As of January 1, 2014, The MITRE Corporation, under the direction of the Centers for Medicare & Medicaid Services (CMS) and in conjunction with its federal partner, the ONC, assumed responsibility for its maintenance and evolution.

1.2 Purpose The QDM describes clinical concepts in a standardized format to enable electronic quality performance measurement in support of operationalizing the Meaningful Use Program of the Health Information Technology for Economic and Clinical Health Act. This model is the backbone for representing criteria used in quality measures by stakeholders involved in electronic quality measurement development and reporting. Stakeholders of the QDM include measure developers, federal agencies, Health Information Technology (HIT) vendors, standards organizations, informatics experts, providers, and researchers.

The QDM is intended to enable automation of structured data captured through routine care in electronic health records (EHR), personal health records (PHR), and other electronic clinical sources. It provides a structure for describing clinical concepts contained within quality measures in a standardized format, allowing individuals (e.g., providers, researchers, or measure developers) who monitor clinical performance and outcomes to communicate information concisely and consistently.

The QDM is one of several standards in the broader electronic Clinical Quality Improvement (eCQI) landscape and operates concurrently with changing measure concepts, tools, and other standards for electronically representing quality measures. The QDM is pivotal in the electronic Clinical Quality Measures (eCQM) ecosystem, as the usage of these definitions helps constrain and accurately express the measure logic, resulting in improved quality of the measure outputs. Measure concepts for eCQMs selected for use in CMS’s EHR Incentive Program are represented through the logic and expressions provided by the QDM. The Measure Authoring Tool1 (MAT) implements the QDM specification, thus providing a software tool for measure developers to author their measures in standard formats.

1.3 Vision The QDM must adapt and evolve to facilitate the introduction of quality measurement and feedback into a provider’s daily routine. It must adapt as eCQMs advance from process- to outcomes-based measures and increasingly use patient-reported data. The QDM must evolve to

1 Available at https://www.emeasuretool.cms.gov. Last accessed August 2014.

CMS / ONC Introduction

Quality Data Model, Version 4.2 2 August 31, 2015

align Clinical Decision Support (CDS) rules with quality measurement. As the QDM changes to enable expression of new measure types and CDS rules, its updates must be capable of incorporation into the MAT, where needed, and be compatible with quality and CDS standards.

1.4 Scope The QDM version 4.0 specification aims to accomplish the following:

• Provide the syntax and language of the different data components, operators, and expression logic of the QDM and describe its usage to specify measure criteria

• Provide continuity from prior versions of the QDM

1.5 Audience The audience includes all stakeholders responsible for translating Clinical Quality Measures into electronic specifications. They include, but are not limited to, measure developers, the MAT development team, EHR vendors, providers reporting eCQMs, and the community developing health IT standards.

1.6 Document Organization This document is organized as follows:

Section Purpose Section 1: Introduction Provides an overview and the background of the QDM Section 2: Data Model Describes the general data model for the QDM Section 3: Logic Defines the QDM functions and operators Section 4: Component Definitions Defines the QDM categories, datatypes, and attributes Appendix A: Time Unit and Time Interval

Definitions Provides an overview of International Organization for Standardization (ISO)-defined temporal concepts

Appendix B: Time Interval Calculation Conventions

Provides instructions for how to calculate time intervals in the QDM

Appendix C: Cumulative Medication Duration

Provides instructions for how to calculate the duration of medication in the QDM

Appendix D: Change Log Lists changes since the December 2013 release of the QDM specification

Acronyms Lists and defines the acronyms used in this document

CMS / ONC

Quality Data Model, Version 4.2 3 August 31, 2015

2. Data Model

2.1 QDM Basics The QDM consists of criteria for data elements, relationships for relating data element criteria to each other, and functions for filtering criteria to the subset of data elements that are of interest. The following sections describe the different components of the QDM.

2.2 Category A category consists of a single clinical concept identified by a value set. A category is the highest level of definition for a QDM element. The QDM currently contains 19 categories. Some examples of categories are Medication, Procedure, Condition/Diagnosis/Problem, Communication, and Encounter.

2.3 Datatype A datatype is the context in which each category is used to describe a part of the clinical care process. Examples of datatypes include ‘Medication, Active’ and ‘Medication, Administered’ as applied to the Medication category.

2.4 Attribute An attribute provides specific detail about a QDM element. QDM elements have two types of attributes, datatype-specific and data flow attributes.

2.4.1 Datatype-Specific Attributes Datatype-specific attributes provide detail about a QDM element based on its datatype. For example, Medication, Dispensed and Medication, Ordered contain information about dosage, route, strength, and duration of a medication. A Medication allergy, however, contains information about the allergy type, allergy severity, and more. Because these attributes pertain to specific datatypes, they are called datatype-specific attributes.

2.4.2 Data Flow Attributes Data flow attributes provide specific detail about the location of data represented by a QDM element. In order to identify the authoritative source of an element in a particular use case, the electronic record requires related information – a location of the information of that type within a particular clinical context. For example, a diabetes medication order may be found in medication orders, whereas allergies related to diabetes medication will be on the allergy list. Similarly, a clinician’s account of an allergy may be found in an EHR allergy list, but a patient’s account of an allergy will be found in a PHR allergy list. Data flow attributes allow a measure developer to clearly define the location of the data so that the intended meaning can be achieved. The following data flow attributes apply to all QDM elements.

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.

CMS / ONC Data Model

Quality Data Model, Version 4.2 4 August 31, 2015

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.

2.5 QDM Element A QDM element encapsulates a certain category with an associated datatype. It is a discrete unit of information used in quality measurement to describe part of the clinical care process, including a clinical entity and its context of use. It can include criteria for any relevant metadata about a clinical or administrative concept relevant to quality measurement. A QDM element provides an unambiguous definition and enables consistent capture and use of data for quality measurement. It may be defined for any given measure and reused when the same information is required for another measure. Reuse encourages standardization of quality measures and reduces the generation of additional software requirements for every new measure.2 The figure below identifies the terminology and gives examples of usage for the basic components that constitute a QDM element.

Starting with QDM 4.1, QDM elements are restricted to containing a single attribute (or no attribute) when expressed in measure logic. This eliminates ambiguity in QDM statements, especially those that use attributes in timing comparisons. Existing QDM elements with more than one attribute can usually be rewritten using a satisfies all clause.

Figure 1. QDM Element Structure

2 NQF Health Information Technology Expert Panel II (HITEP II), HIT Automation of Quality Measurement: Quality

Data Set and Data Flow. Washington DC: National Quality Forum; 2009.

CMS / ONC Data Model

Quality Data Model, Version 4.2 5 August 31, 2015

2.6 Code System A code system is a collection of coded concepts with definitions from a particular taxonomy, vocabulary, or classification system. Concepts from a code system are used in value sets. Specific code systems are used in applying the QDM to quality measures based on the recommendations of the HIT Standards Committee of the ONC and established certification rules for meaningful use. For example, International Classification of Diseases, Ninth Revision (ICD-9-CM), International Classification of Diseases, Tenth Revision (ICD-10), Systematized Nomenclature of Medicine – Clinical Terms (SNOMED-CT®), and Current Procedural Terminology (CPT®) are examples of code systems. The concept of diabetes may be described in QDM with ICD-9-CM, ICD-10, and/or SNOMED-CT®.

2.7 Value Sets A value set is a set of values that contain specific codes derived from a particular code system. Value sets are used to define the set of codes that can possibly be found in a patient record for a particular concept. In QDM elements, value sets can be used to define possible codes for the QDM element’s category or the QDM element’s attributes. The 2014 Clinical Quality Measures use the National Library of Medicine Value Set Authority Center as a repository for the associated value sets.3

2.7.1 Value Sets that Define QDM Categories It is important to note that value sets define a QDM element’s category, not a QDM element’s datatype. Here is an example of a very common QDM element:

Procedure, Performed: "value set A"

In this example, the value set defines which procedure the criterion is looking for. The codes in this value set should only indicate the procedure, not whether the procedure was performed, ordered, or recommended, since that is represented using different datatypes. The following example shows a QDM element with an attribute:

Laboratory Test, Performed: "value set A" (result: "value set B")

In this example, value set A defines the category of the QDM element. Since the category is a Laboratory Test, value set A answers the question of which laboratory test. Value set B, on the other hand, defines the attribute result. Value set B should contain codes for different coded result values.

2.7.2 Value Sets that Define QDM Attributes Some QDM attributes can be defined by value sets, similar to how QDM Categories are defined by value sets.

3 The Value Set Authority Center provides downloadable access to all official versions of the vocabulary value sets

contained in the 2014 Clinical Quality Measures. For more information, visit https://vsac.nlm.nih.gov/. Last accessed August 2014.

CMS / ONC Data Model

Quality Data Model, Version 4.2 6 August 31, 2015

2.7.3 Value Set Groupings Each value set contains codes from one code system. However, multiple value sets can be combined into one value set called a value set grouping. A parent value set may also contain child (or nested) value sets that define the same category. The approach is consistent with the Health Level 7 (HL7) definition for a value set as “a uniquely identifiable set of valid concept representations, where any concept representation can be tested to determine whether or not it is a member of the value set … A sub-value set is a sub-set of a ‘parent’ value set … When a value set entry references another value set, the child value set is referred to as a nested value set. There is no pre-set limit to the level of nesting allowed within value sets. Value sets cannot contain themselves or any of their ancestors (i.e., they cannot be defined recursively).”4 With respect to value sets, a value is a specific code defined by a given taxonomy. Values are included in value sets. In the context of QDM elements, some categories (e.g., laboratory test) have an attribute of “result.” A result may be expressed as a value (numeric or alphanumeric).

2.8 Specific Occurrences When a QDM element is used in a measure, the intended interpretation assumes that the measure is looking for any instance of a concept that matches the QDM element’s criteria. For example, the QDM element "Diagnosis: Diabetes" should be interpreted as any diagnosis with a code matching the Diabetes value set. In some cases, a measure may refer to the same instance throughout the measure logic. This is indicated in the QDM through labeling instances of a data element as a “specific occurrence.” For example, the QDM element "Occurrence A of Diagnosis: Diabetes" should be interpreted as a specific instance of a diagnosis with a code matching the Diabetes value set. If "Occurrence A of Diagnosis: Diabetes" is used multiple times in a measure, then each time it is referring to the same instance. Each occurrence of a given QDM element is distinguished with a unique letter. For example, if there were two distinct occurrences of the QDM element "Diagnosis: Diabetes" the two occurrences would be distinguished as "Occurrence A of Diagnosis: Diabetes" and "Occurrence B of Diagnosis: Diabetes".

Note that a specific occurrence label only has meaning and specificity for the QDM element to which it is applied. In other words, it is invalid to reference "Occurrence A" without its associated QDM element. In the same way, "Occurrence A of Diagnosis: Diabetes" is entirely different from "Occurrence A of Diagnosis: Pneumonia" even though they both use the same occurrence label.

Specific occurrences are the most challenging aspect of the QDM logic from an implementation perspective. The following sections provide guidance regarding the use of specific occurrences in different contexts.

4 HL7 Domain and Value Set Definitions and Binding, available at:

http://wiki.hl7.org/index.php?title=Domain_and_Value_Set_Definitions_and_Binding. Last accessed August 2014.

CMS / ONC Data Model

Quality Data Model, Version 4.2 7 August 31, 2015

2.8.1 Simple Usage of Specific Occurrences When a specific occurrence of an event is specified in multiple clauses linked by AND logic, the logic is only satisfied if all of the individual clauses are satisfied for a specific (single) instance of the event.

In the following example from the measure CMS169v2, there must be at least one instance of "BH Outpatient Encounter" that satisfies both clauses, occurring between the measurement start date and 42 days before the measurement end date:

AND: "Occurrence A of Encounter, Performed: BH Outpatient encounter" >= 42 day(s) starts before start of "Measurement End Date"

AND: "Occurrence A of Encounter, Performed: BH Outpatient encounter" starts after start of "Measurement Start Date"

2.8.2 Multiple Specific Occurrences of the Same Event Type A logical clause may reference other (distinct) specific occurrences of a particular type or specific occurrences of a different type. The following example from the measure CMS52v2 references two specific occurrences of type "Encounter, Performed: HIV Visit":

AND: "Occurrence A of Encounter, Performed: HIV Visit" during "Measurement Period"

AND: "Occurrence B of Encounter, Performed: HIV Visit" during "Measurement Period"

AND: "Occurrence B of Encounter, Performed: HIV Visit" >= 90 day(s) starts after end of "Occurrence A of Encounter, Performed: HIV Visit"

Specific occurrences of the same type will be referenced with an alphabetically incrementing label (e.g., “Occurrence B”). The order of the labeling does not have any significance other than indicating that they represent different instances. Specifically, no temporal relationship is implied by the alphabetical ordering of the occurrences; Occurrence A does not necessarily occur prior to Occurrence B. When a measure references Occurrence A and Occurrence B of an event type (e.g., Encounter, Performed: HIV Visit), the logic of the measure will evaluate true when Occurrence A and Occurrence B reference distinct instances of the event type. In the previous example, the logic is looking for two different HIV Visits. Both visits must occur during the measurement period as defined in the first two statements, and one visit (“Occurrence B”) must start 90 days or more after an initial visit (“Occurrence A”), as defined in the last statement.

2.8.3 Multiple Specific Occurrences of Different Event Types Logic clauses can also reference occurrences of different types. The following example, also from the measure CMS52v2, has specific occurrences referencing two different medications and a laboratory test result:

AND: "Occurrence A of Medication, Order: Dapsone and pyrimethamine" <= 3 month(s) starts after end of "Occurrence A of Laboratory Test, Performed: CD4+ Count (result)"

CMS / ONC Data Model

Quality Data Model, Version 4.2 8 August 31, 2015

AND: "Occurrence A of Medication, Order: Leucovorin" <= 3 month(s) starts after end of "Occurrence A of Laboratory Test, Performed: CD4+ Count (result)"

This logic will evaluate to true when a Laboratory Test, Performed: CD4+ Count (result) exists such that there are medication orders for “Dapsone and pyrimethamine” and “Leucovorin” and both start within three months of the end of the lab test.

2.8.4 Specific Occurrences in OR Clauses and Negations When multiple logical statements referencing a specific occurrence are joined by an OR clause, the logic can evaluate to true if there is an event that satisfies the specific occurrence in the logic of at least one branch of the OR clause. The specific occurrence does not have to hold true for every branch of the OR clause. When logical statements containing specific occurrences are used as part of a negated clause (e.g., AND NOT), the specific occurrence of the event must either evaluate to false for the negated logic clause, or a viable specific occurrence for the event must not exist. In other words, in a negated clause, the specific occurrence must not evaluate to true, or the event must not exist. The case where an event does not exist is important where a specific occurrence is only referenced in negated clauses within a measure. If a specific occurrence is referenced by both negated and non- negated clauses, then it must exist for the logic of the measure to hold, and it must evaluate to false for the negated logic.

2.8.5 Specific Occurrences between Populations Conditions applied to specific occurrences carry forward from one population to the next, in the order in which they are calculated. See the eCQM Logic and Implementation Guidance5 for details on the calculation order of the measures.

For instance, consider an encounter with “Occurrence A” restricted to the Measurement Period in the “Initial Patient Population.” That occurrence will carry into the “Denominator,” thus restricting it to the Measurement Period as well. Similarly, occurrences in the “Denominator” will carry into the “Numerator.”

For “Denominator Exclusions,” it is the negation of the specific occurrence conditions that is carried forward into the “Numerator.” Consider an episode-of-care measure where an episode is excluded if the patient is pregnant during the encounter. In this case the encounters where the patient was NOT pregnant will be considered for the Numerator.

Similarly, the negation of the conditions applied to the specific occurrences in the “Numerator” carry forward into the “Denominator Exceptions.” This allows the “Denominator Exceptions” to only consider occurrences that did not evaluate to true in the “Numerator.”

5 Available at:

http://www.cms.gov/Regulations-and-Guidance/Legislation/EHRIncentivePrograms/eCQM_Library.html. Last accessed August 2014.

CMS / ONC Data Model

Quality Data Model, Version 4.2 9 August 31, 2015

2.9 Variables Sometimes measure developers need to use a defined set of data elements in multiple pieces of logic throughout the measure. Rather than copy the entire set of data elements in every place they are needed, measure developers can define the set once and assign it to a variable. Wherever the set of data elements is needed in the measure, it can be referenced by the variable name.

Measure developers must follow these rules when assigning variables:

• Variable names must start with a $, followed by a letter • Variable names can only consist of letters, numbers, and the underscore character (_) • Variables can only be assigned to logic that results in a set of data elements • Variables cannot be assigned to any logic that uses specific occurrences • Once a variable is assigned, the same variable cannot be re-assigned in the same measure

The following example assigns a set of medications to a variable called $TargetMedications: $TargetMedications = Union of:

"Medication, Order: BH Antidepressant medication" "Medication, Order: BH Mood stabilizer medication"

After assigning the variable, the measure developer can use $TargetMedications to represent that set of data elements anywhere in the measure. The developer can even apply a specific occurrence to the variable (e.g., Occurrence A of $TargetMedications).

Variables can also be used in permutations of logic that otherwise would not be possible without grouping value sets. For example, consider the following logic:

AND: Union of:

"Medication, Order: BH Antidepressant medication" during "Encounter, Performed: BH Outpatient encounter"

"Medication, Order: BH Mood stabilizer medication" during "Encounter, Performed: BH Outpatient encounter"

"Medication, Order: BH Antidepressant medication" during "Encounter, Performed: BH Outpatient psychotherapy"

"Medication, Order: BH Mood stabilizer medication" during "Encounter, Performed: BH Outpatient psychotherapy"

In the example above, the measure developer is looking for cases where an antidepressant or mood stabilizer was ordered during an outpatient behavior health encounter or outpatient psychotherapy encounter. Without variables, the measure developer needs to express every possible combination. If the measure developer uses variables to group the target medications and target encounters, however, then the same logic can be expressed this way:

$TargetMedications = Union of: "Medication, Order: BH Antidepressant medication" "Medication, Order: BH Mood stabilizer medication"

CMS / ONC Data Model

Quality Data Model, Version 4.2 10 August 31, 2015

$TargetEncounters = Union of: "Encounter, Performed: BH Outpatient encounter" "Encounter, Performed: BH Outpatient psychotherapy"

AND: $TargetMedications during $TargetEncounters

The construction of the target sets could also contain additional logic, including temporal references or subset operators. For example, each of the target encounters could be restricted to the measurement period:

$TargetEncounters = Union of:

"Encounter, Performed: BH Outpatient encounter" during "Measurement Period"

"Encounter, Performed: BH Outpatient psychotherapy" during "Measurement Period"

2.10 Inline Comments Sometimes a measure developer may want to provide additional clarity to a difficult or complex section of logic. The QDM allows measure developers to do this by using inline comments. Any line starting with a # in the human readable format will be treated as a comment and will not alter the intent or execution of the logic. Developers can provide multiple lines of comments by starting each line with the # character.

The following example demonstrates the format and use of an inline comment:6 # Check if there were more than 4 inpatient encounters during the MP

Count > 4 of: "Encounter, Performed: Inpatient" during "Measurement Period"

Note that inline comments should be used sparingly, as their main purpose is to provide clarification for difficult sections of logic. Inline comments should not be used to provide guidance that would alter or influence the implementation of the logic.

6 Note that the logic in this example is sufficiently clear so that it normally would not require a comment.

CMS / ONC

Quality Data Model, Version 4.2 11 August 31, 2015

3. Logic

3.1 Attribute Filters Attribute filters can be applied to QDM elements to further restrict the set of events that are returned. These filters indicate a condition that the value of the attribute must satisfy for the given event to be included in the set.

3.1.1 Filter by Existence of a Recorded Value The simplest attribute filter tests for the existence of a recorded value for the attribute. This filter is applied by simply specifying the name of the attribute in the QDM Element. For example:

"Physical Exam, Performed: Systolic Blood Pressure (result)"

This example refers to all physical exams for which the result of the patient’s systolic blood pressure was recorded in structured data (regardless of the value). If the systolic blood pressure was taken but the result was not recorded, it would not qualify for inclusion.

3.1.2 Filter by Value Set One way to use attribute filters is to filter by value set. When an attribute is filtered by a value set, its value must be a code within that value set. Filtering by value set uses the : (colon) operator. For example:

"Risk Category Assessment: VTE Risk Assessment (result: 'Low Risk')"

The example above refers to all VTE risk assessments for which the result was recorded as one of the codes in the “Low Risk” value set.

3.1.3 Filter by Scalar Value or Physical Quantity Attributes can also be filtered by comparing their values to a scalar value or physical quantity. A physical quantity is a scalar value with a specified unit of measurement. Units of measurement must be specified using a code from the Unified Code for Units of Measure (UCUM)7 or a QDM temporal unit (e.g., day(s)). For example:

"Laboratory Test, Performed: LDL-c Test (result < 100 mg/dL)"

This example refers to all LDL-c tests for which the result was less than 100 milligrams per deciliter. Any cases without a recorded result or with a result greater than or equal to 100 milligrams per deciliter would not be included.

See Section 3.5, Comparison Operators, for a list of valid comparison operators.

7 Available at: http://unitsofmeasure.org/trac/. Health Level Seven International (HL7) also provides a table of

commonly used UCUM codes: http://www.hl7.de/download/documents/ucum/ucumdata.html. Last accessed August 2014.

CMS / ONC Logic

Quality Data Model, Version 4.2 12 August 31, 2015

3.1.4 Filter by Date Attributes representing a date/time can be compared against a specific date. This can be used to determine that something occurred during a specific period of time (not related to the measurement period or other clinical events). For example:

AND: "Patient Characteristic Birthdate: (start datetime >= 01/01/1965)"

AND: "Patient Characteristic Birthdate: (start datetime <= 12/31/1992)"

This example refers to all patients who were born in a year from 1965 to 1992.

Comparing attributes against dates uses day precision. See Appendix B for more information about performing timing calculations in QDM.

3.2 Functions

3.2.1 Min Given a QDM element and attribute, the Min function extracts the minimum value from the matching set of events. Within a measure population, the Min function is used in a comparison to determine eligibility for the population. For example:

Min >= 120 mmHg of: "Physical Exam, Performed: Systolic Blood Pressure (result)" during "Measurement Period"

The example above would evaluate to true if the minimum systolic blood pressure recorded for the patient (during the measurement period) was at least 120 mm Hg, otherwise it would evaluate to false.

Within a measure observation, the Min function returns the minimum value for reporting purposes.

The Min function can only operate on attributes that have numeric values.

3.2.2 Max Given a QDM element and attribute, the Max function extracts the maximum value from the matching set of events. Within a measure population, the Max function is used in a comparison to determine eligibility for the population. For example:

Max < 120 mmHg of: "Physical Exam, Performed: Systolic Blood Pressure (result)" during "Measurement Period"

The example above would evaluate to true if the maximum systolic blood pressure recorded for the patient (during the measurement period) was less than 120 mm Hg, otherwise it would evaluate to false.

Within a measure observation, the Max function returns the maximum value for reporting purposes.

The Max function can only operate on attributes that have numeric values.

CMS / ONC Logic

Quality Data Model, Version 4.2 13 August 31, 2015

3.2.3 Median For an ordered set of numbers (lowest to highest), the median is the middle value in the set. Median should not be confused with average (mean), which is the sum of numbers divided by the count of numbers in a set.

When there is an odd number of values in the set, the median is the value that separates the higher half from the lower half. For example, consider the following list of numbers: 1, 6, 7, 21, and 25. The median is 7.

When there is an even number of items, the median is the average of the middle two items. For example, consider the following list of numbers: 1, 2, 3, 7, 8, and 100. The median is 5 (i.e., average of 3 and 7).

The Median function is most often used in measure observations. The following example demonstrates determining the median of the patient’s systolic blood pressure readings during the measurement period:

Median of: "Physical Exam, Performed: Systolic Blood Pressure (result)" during "Measurement Period"

The Median function can also be used in a comparison to determine eligibility for a measure population. The following example would evaluate to true for patients with a median systolic blood pressure reading less than 140 mm Hg during the measurement period:

Median < 140 mmHg of: "Physical Exam, Performed: Systolic Blood Pressure (result)" during "Measurement Period"

3.2.4 Average For a set of numbers, the average (or mean) is the sum of the numbers divided by the count of the numbers. For example, consider the following list of numbers: 1, 12, 7, 9, and 1. The average is 6 (the sum [30] divided by the count [5]).

In the QDM, the Avg function is most often used in measure observations to report the average for a datatype-specific attribute value of a QDM element. For example, the following expression would return the patient’s average systolic blood pressure reading during the measurement period:

Avg of: "Physical Exam, Performed: Systolic Blood Pressure (result)" during "Measurement Period"

The Avg function can also be used in a comparison to determine eligibility for a measure population. The Avg function can also be used in comparisons. The above example would evaluate to true if the patient’s average systolic blood pressure was below 140 mm Hg during the measurement period:

Avg < 140 mmHg of: "Physical Exam, Performed: Systolic Blood Pressure (result)" during "Measurement Period"

The Avg function can only operate on attributes that have numeric values.

CMS / ONC Logic

Quality Data Model, Version 4.2 14 August 31, 2015

3.2.5 Count The Count function returns the number of individual instances for a particular QDM element or set of QDM elements. While the Count function can be used in measure observations, it is most often used in a comparison to determine eligibility for a measure population. For example:

Count > 4 of: "Encounter: Hospital Inpatient" during "Measurement Period"

The above example would evaluate to true if the patient had more than 4 hospital inpatient encounters during the measurement period, otherwise it would evaluate to false.

3.2.6 Sum The Sum function operates on a datatype-specific attribute for a QDM element, returning the sum of that attribute’s values across all of the events in the set. While the Sum function can be used in measure observations, it is most often used in a comparison to determine eligibility for a measure population. For example:

Sum > 48 hour(s) of: "Encounter, Performed: Inpatient (length of stay)" during "Measurement Period"

The example above would evaluate to true if the summed overall length of stay for inpatient encounters was greater than 48 hours, otherwise it would evaluate to false.

The sum operator has a special meaning and implementation when used in conjunction with the cumulative medication duration attribute. In this context, it provides the sum of unique medication days. See Appendix C for more information.

3.2.7 Age At Many measures specify requirements on the patient’s age in order to be in the Initial Patient Population or the denominator. This construct is used often enough that QDM provides a special Age At function to determine a patient’s age at the start of an event. The following example indicates that a patient must be at least two years old but not yet 18 years old at the start of the measurement period:

AND: Age >= 2 year(s) at: "Measurement Period"

AND: Age < 18 year(s) at: "Measurement Period"

If comparing against events other than the measurement period, specific occurrences must be used to ensure that both comparisons are executed against each instance of the event:

AND: Age >= 2 year(s) at: "Occurrence A of Diagnosis: Diabetes"

AND: Age < 18 year(s) at: "Occurrence A of Diagnosis: Diabetes"

Note that the Age At operator is only valid within measure populations. It cannot be used in measure observations.

3.2.8 DateTimeDiff The DateTimeDiff function returns the amount of time between two date/times (identified by attributes in two QDM elements). The DateTimeDiff function is only valid for use in measure

CMS / ONC Logic

Quality Data Model, Version 4.2 15 August 31, 2015

observations. One common use case is determining the median length of stay at a facility location. For example:

Median of: Datetime difference of:

"Occurrence A of Encounter, Performed: Inpatient (facility location arrival datetime)"

"Occurrence A of Encounter, Performed: Inpatient (facility location departure datetime)"

This function replaces the DateDiff and TimeDiff functions that were available in past versions of the QDM. Please note that these functions were previously allowed in measure population definitions, but DateTimeDiff is not. Rather than DateTimeDiff, measure developers should use temporal relationships with quantity comparisons in measure population definitions.

3.3 Subset Operators

3.3.1 Sort Order for QDM Events In order for the FIRST, SECOND, THIRD, FOURTH, FIFTH, and MOST RECENT subset operators to behave in a deterministic manner, the QDM defines a sort order for events. Events are sorted by date/time in ascending order (i.e., the oldest event is FIRST). The sort algorithm uses each event’s start date, unless there is no start date, in which case it will use the end date.8

3.3.2 First Return the first occurrence of the associated QDM element or phrase. This is the first item in a list.

The following example demonstrates getting the first instance of an inpatient encounter: FIRST: "Encounter, Performed: Inpatient"

If Encounter, Performed: Inpatient resulted in the list of events below, then the example above would return the first item in the list:

1. "Encounter, Performed: Inpatient" 2. "Encounter, Performed: Inpatient" 3. "Encounter, Performed: Inpatient" 4. "Encounter, Performed: Inpatient" 5. "Encounter, Performed: Inpatient"

3.3.3 Second Return the second occurrence of the associated QDM element or phrase. This is the second item in a list.

The following example demonstrates getting the second instance of an inpatient encounter: SECOND: "Encounter, Performed: Inpatient"

8 In cases where two or more events have the same exact date/times for comparison, they will hold equal status

(i.e., in rare cases, it is possible for subset operators like FIRST and MOST RECENT to return more than one event).

CMS / ONC Logic

Quality Data Model, Version 4.2 16 August 31, 2015

If Encounter, Performed: Inpatient resulted in the list of events below, then the example above would return the second item in the list:

1. "Encounter, Performed: Inpatient" 2. "Encounter, Performed: Inpatient" 3. "Encounter, Performed: Inpatient" 4. "Encounter, Performed: Inpatient" 5. "Encounter, Performed: Inpatient"

3.3.4 Third Return the third occurrence of the associated QDM element or phrase. This is the third item in a list.

The following example demonstrates getting the third instance of an inpatient encounter: THIRD: "Encounter, Performed: Inpatient"

If Encounter, Performed: Inpatient resulted in the list of events below, then the example above would return the third item in the list:

1. "Encounter, Performed: Inpatient" 2. "Encounter, Performed: Inpatient" 3. "Encounter, Performed: Inpatient" 4. "Encounter, Performed: Inpatient" 5. "Encounter, Performed: Inpatient"

3.3.5 Fourth Return the fourth occurrence of the associated QDM element or phrase. This is the fourth item in a list.

The following example demonstrates getting the fourth instance of an inpatient encounter: FOURTH: "Encounter, Performed: Inpatient"

If Encounter, Performed: Inpatient resulted in the list of events below, then the example above would return the fourth item in the list:

1. "Encounter, Performed: Inpatient" 2. "Encounter, Performed: Inpatient" 3. "Encounter, Performed: Inpatient" 4. "Encounter, Performed: Inpatient" 5. "Encounter, Performed: Inpatient"

3.3.6 Fifth Return the fifth occurrence of the associated QDM element or phrase. This is the fifth item in a list.

The following example demonstrates getting the fifth instance of an inpatient encounter: FIFTH: "Encounter, Performed: Inpatient"

CMS / ONC Logic

Quality Data Model, Version 4.2 17 August 31, 2015

If Encounter, Performed: Inpatient resulted in the list of events below, then the example above would return the fifth item in the list:

1. "Encounter, Performed: Inpatient" 2. "Encounter, Performed: Inpatient" 3. "Encounter, Performed: Inpatient" 4. "Encounter, Performed: Inpatient" 5. "Encounter, Performed: Inpatient" 6. "Encounter, Performed: Inpatient" 7. "Encounter, Performed: Inpatient"

3.3.7 Most Recent Return the most recent occurrence of the associated QDM element or phrase. This is the last item in a list.

The following example demonstrates getting the most recent instance of an inpatient encounter: MOST RECENT: "Encounter, Performed: Inpatient"

If Encounter, Performed: Inpatient resulted in the list of events below, then the example above would return the last item in the list:

1. "Encounter, Performed: Inpatient" 2. "Encounter, Performed: Inpatient" 3. "Encounter, Performed: Inpatient" 4. "Encounter, Performed: Inpatient" 5. "Encounter, Performed: Inpatient" 6. "Encounter, Performed: Inpatient" 7. "Encounter, Performed: Inpatient"

3.3.8 Intersection Of The Intersection Of operator provides a mechanism for specifying that qualifying events must be members of all data sets being intersected. For example, the intersection of set A and set B is all events in both set A and set B. QDM elements and clauses defining each set to be intersected should be listed on subsequent lines below the Intersection Of operator. The Intersection Of operator can operate on the following data:

• QDM elements (e.g., “Encounter, Performed: Inpatient”) • QDM elements with attributes (e.g., “Encounter, Performed: Inpatient (length of stay > 1

day(s))”) • Specific occurrences (e.g., “Occurrence A of Encounter, Performed: Inpatient”) • Expressions w/ relationships (e.g., “Encounter, Performed: Inpatient” during

“MeasurementPeriod”) • Variables (e.g., $TargetEncounters)

CMS / ONC Logic

Quality Data Model, Version 4.2 18 August 31, 2015

The following example represents an intersection of office visits during the measurement period and office visits before a diagnosis of diabetes:

AND: Intersection of:

"Encounter, Performed: Office Visit" during "MeasurementPeriod"

"Encounter, Performed: Office Visit" ends before start of "Diagnosis: Diabetes"

The resulting set contains all office visit encounters during the measurement period and before a diagnosis of diabetes. If a diagnosis of diabetes occurred during the measurement period, the office visit in which the diagnosis occurred and any office visits afterwards would not be in the resulting set. (Note that this specific example could also be represented using Satisfies All).

3.3.9 Union Of The Union Of operator provides a mechanism for specifying that qualifying events must be a member of at least one of the data sets being unioned. For example, the union of set A and set B is all events in set A, or in set B, or in set A and set B. QDM elements and clauses defining each set to be unioned should be listed on subsequent lines below the Union Of operator. The Union Of operator can operate on the following data:

• QDM elements (e.g., “Encounter, Performed: Inpatient”) • QDM elements with attributes (e.g., “Encounter, Performed: Inpatient (length of stay > 1

day(s))”) • Specific occurrences (e.g., “Occurrence A of Encounter, Performed: Inpatient”) • Expressions w/ relationships (e.g., “Encounter, Performed: Inpatient” during

“MeasurementPeriod”) • Variables (e.g., $TargetEncounters)

The following example represents the first office visit or face-to-face interaction: AND: FIRST:

Union of:

"Encounter, Performed: Office Visit"

"Encounter, Performed: Face-to-Face Interaction"

In the example above, if a patient had two office visits and two face-to-face interactions (that were not “office visits”), then the result of the union would be the set of all four encounters. After performing the union, the first of these four encounters would be chosen.

3.3.10 Satisfies Any The Satisfies Any operator provides a mechanism for specifying that qualifying events must meet at least one condition from a set of conditions. This allows measure developers to filter a set of events to only those that are of interest.

Individual conditions that qualify an event for selection should be listed on subsequent lines below the Satisfies Any operator. Each of these conditions will be evaluated against the QDM

CMS / ONC Logic

Quality Data Model, Version 4.2 19 August 31, 2015

element on the left-hand side of Satisfies Any. The resulting subset will contain only the instances of the QDM element that met at least one of the conditions.

Satisfies Any supports the following types of conditions:

• Timing relationships (e.g., “starts before start of…”) • Timing relationships w/ operators (e.g., “< 5 day(s) starts before start of…”) • Datatype-specific attribute conditions (e.g., “(length of stay < 90 day(s))”)

The following example represents inpatient encounters that were less than two days long or were during an active antibiotic medication or started no more than one day before an admission to an ICU:9

AND: "Encounter, Performed: Inpatient Encounter" satisfies any (length of stay < 2 day(s)) during "Medication, Active: Antibiotic Medications" <= 1 day(s) starts before start of "Encounter, Performed: ICU Admission or Transfer"

An encounter is selected if it meets any of these criteria (at least one of the criteria must hold true). If an encounter does not meet any of the criteria, it will not be a part of the resulting subset.

3.3.11 Satisfies All The Satisfies All operator provides a mechanism for specifying that qualifying events must meet all conditions from a set of conditions. This allows measure developers to filter a set of events to only those that are of interest. One of the benefits of the Satisfies All operator is that it allows subsets to be filtered in ways that previously required specific occurrences.

Individual conditions that are required to qualify an event for selection should be listed on subsequent lines below the Satisfies All operator. Each of these conditions will be evaluated against the QDM element on the left-hand side of the Satisfies All. The resulting subset will contain only the instances of the QDM element that met every one of the conditions.

Satisfies All supports the following types of conditions:

• Timing relationships (e.g., “starts before start of…”) • Timing relationships w/ operators (e.g., “< 5 day(s) starts before start of…”) • Datatype-specific attribute conditions (e.g., “(length of stay < 90 day(s))”)

The following example represents BMI exams that occurred during an encounter and had a result that was at least 18.5 kg/m2 and below 25 kg/m2:

AND: "Physical Exam, Performed: BMI LOINC Value" satisfies all during "Encounter, Performed: BMI Encounter Code Set" (result >= 18.5 kg/m2) (result < 25 kg/m2)

9 This example obviously has no applicability to real world clinical situations, but rather is intended only to show

the syntax of how to use Satisfies Any.

CMS / ONC Logic

Quality Data Model, Version 4.2 20 August 31, 2015

A physical exam is selected only if it meets all of the criteria specified. Thus, exams that did not occur during the specified encounter type or did not fit within the defined bounds of results will not be a part of the resulting subset.

3.4 Logical Operators

3.4.1 And The AND operator is used to conjoin two or more QDM elements or phrases that must all be true for the logic to hold. In the QDM, truth is determined by the existence of matching events (or the expected non-existence of such events).

The following example asserts that an inpatient encounter and a physical exam with a weight measurement both occurred during the measurement period:

AND: "Encounter: Hospital Inpatient"

AND: "Physical Exam, Performed: Weight Measurement"

during "Measurement Period"

Note: The addition of any measure phrase should always be preceded by an AND or an OR.

3.4.2 Or The OR operator is used to conjoin two or more QDM elements or phrases for which at least one must be true for the logic to hold. In the QDM, truth is determined by the existence of matching events (or the expected non-existence of such events).

The following example asserts that a hospital inpatient encounter or a hospital outpatient encounter occurred during the measurement period:

OR: "Encounter: Hospital Inpatient"

OR: "Encounter: Hospital Outpatient"

during "Measurement Period"

Note: The addition of any measure phrase should always be preceded by an AND or an OR.

3.4.3 Not The NOT operator is used to negate a QDM element or phrase when defining a population. In the QDM, negation asserts the non-existence of matching events for the QDM element or phrase. When an attribute is indicated for a QDM element in a negated phrase, what is being negated is the occurrence of a particular QDM element with that attribute. For example:

AND NOT: "Laboratory Test, Performed: LDL (result)" starts after start of "Measurement Period"

The above example asserts that no LDL reading was performed that met the following criteria:

• Had a documented result • Started after the start of the measurement period

CMS / ONC Logic

Quality Data Model, Version 4.2 21 August 31, 2015

However, there could have been an LDL reading that occurred that met the following criteria:

• Did not have a documented result • Started after the start of the measurement period

3.5 Comparison Operators

3.5.1 Equal To In a mathematical expression, the Equal To operator denotes that the value of the left-hand side is equal to the value of the right-hand side (e.g., x = y).

In the QDM, the Equal To operator can be used to filter a set of events to only those events for which a datatype-specific attribute has a certain value. The following example refers to the set of inpatient encounters that were 120 days long:

"Encounter: Hospital Inpatient (length of stay = 120 day(s))"

The QDM also allows timing relationships to specify the desired delta between events. The following example would refer to the set of inpatient encounters that started exactly three days before a diagnosis of diabetes:

"Encounter: Hospital Inpatient" = 3 day(s) starts before start of "Diagnosis: Diabetes"

As seen above, the QDM human readable format uses the = symbol for Equal To relationships. For more information about comparisons in timing relationships, see Appendix B: Time Interval Calculation Conventions.

3.5.2 Less Than In a mathematical expression, the Less Than operator is used to denote that the value of the left- hand side is less than the value of the right-hand side (e.g., x < y).

In the QDM, the Less Than operator can be used to filter a set of events to only those events for which a datatype-specific attribute’s value is less than another specified value. The following example refers to the set of inpatient encounters that were less than 120 days long:

"Encounter: Hospital Inpatient (duration < 120 day(s))"

The QDM also allows timing relationships to specify the desired delta between events. The following example would refer to the set of inpatient encounters that started less than three days before a diagnosis of diabetes:

"Encounter: Hospital Inpatient" < 3 day(s) starts before start of "Diagnosis: Diabetes"

As seen above, the QDM human readable format uses the < symbol for Less Than relationships. For more information about comparisons in timing relationships, see Appendix B: Time Interval Calculation Conventions.

CMS / ONC Logic

Quality Data Model, Version 4.2 22 August 31, 2015

3.5.3 Less Than Or Equal To In a mathematical expression, the Less Than Or Equal To operator is used to denote that the value of the left-hand side is less than or equal to the value of the right-hand side (e.g., x ≤ y).

In the QDM, the Less Than Or Equal To operator can be used to filter a set of events to only those events for which a datatype-specific attribute’s value is less than or equal to another specified value. The following example would refer to the set of inpatient encounters that were at most 120 days long:

"Encounter: Hospital Inpatient (duration <= 120 day(s))"

The QDM also allows timing relationships to specify the desired delta between events. The following example would refer to the set of inpatient encounters that started at most three days before a diagnosis of diabetes:

"Encounter: Hospital Inpatient" <= 3 day(s) starts before start of "Diagnosis: Diabetes"

As seen above, the QDM human readable format uses <= to represent for Less Than Or Equal To relationships. For more information about comparisons in timing relationships, see Appendix B: Time Interval Calculation Conventions.

3.5.4 Greater Than In a mathematical expression, the Greater Than operator is used to denote that the value of the left-hand side is greater than the value of the right-hand side (e.g., x > y).

In the QDM, the Greater Than operator can be used to filter a set of events to only those events for which a datatype-specific attribute’s value is greater than another specified value. The following example refers to the set of inpatient encounters that were more than 120 days long:

"Encounter: Hospital Inpatient (duration > 120 day(s))"

The QDM also allows timing relationships to specify the desired delta between events. The following example refers to the set of inpatient encounters that started more than three days before a diagnosis of diabetes:

"Encounter: Hospital Inpatient" > 3 day(s) starts before start of "Diagnosis: Diabetes"

As seen above, the QDM human readable format uses the > symbol for Greater Than relationships. For more information about comparisons in timing relationships, see Appendix B: Time Interval Calculation Conventions.

3.5.5 Greater Than or Equal To In a mathematical expression, the Greater Than or Equal To comparison operator is used to denote that the value of the left-hand side is greater than or equal to the value of the right-hand side (e.g., x ≥ y).

In the QDM, the Greater Than or Equal To operator can be used to filter a set of events to only those events for which a datatype-specific attribute’s value is greater than or equal to another specified value. The following example refers to the set of inpatient encounters that were at least 120 days long:

CMS / ONC Logic

Quality Data Model, Version 4.2 23 August 31, 2015

"Encounter: Hospital Inpatient (duration >= 120 day(s))"

The QDM also allows timing relationships to specify the desired delta between events. The following example would refer to the set of inpatient encounters that started at least three days before a diagnosis of diabetes:

"Encounter: Hospital Inpatient" >= 3 day(s) starts before start of "Diagnosis: Diabetes"

As seen above, the QDM human readable format uses >= to represent Greater Than or Equal To relationships. For more information about comparisons in timing relationships, see Appendix B: Time Interval Calculation Conventions.

3.6 General Relationship Operators

3.6.1 Fulfills The Fulfills general relationship operator indicates that one QDM element fulfills another. This is often used in the context of a note / report fulfilling a referral or order, but other applications may exist.

This relationship correlates exactly to the HL7 ActRelationshipType: FLFS. The following example asserts that a consult note fulfills a referral:

"Communication: Provider to Provider: Consult Note" fulfills "Intervention, Order: Referral"

3.7 Temporal Operators

3.7.1 Starts Before Start Of The Starts Before Start Of operator asserts that the start date/time of the event on the left- hand side is temporally before the start date/time of the event on the right-hand side.

The following example asserts that an inpatient encounter started before a diagnosis of diabetes: "Encounter: Hospital Inpatient" starts before start of "Diagnosis:

Diabetes"

3.7.2 Starts After Start Of The Starts After Start Of operator asserts that the start date/time of an event on the left- hand side is temporally after the start date/time of an event on the right-hand side.

The following example asserts that a diagnosis of diabetes started after an inpatient encounter started:

"Diagnosis: Diabetes" starts after start of "Encounter: Hospital Inpatient"

3.7.3 Starts Before End Of The Starts Before End Of operator asserts that the start date/time of an event on the left-hand side is temporally before the end date/time of an event on the right-hand side.

CMS / ONC Logic

Quality Data Model, Version 4.2 24 August 31, 2015

The following example asserts that an inpatient encounter started before the end of a diagnosis of diabetes:

"Encounter: Hospital Inpatient" starts before end of "Diagnosis: Diabetes"

Note: Previous versions of QDM represented this relationship using the Starts Before or During operator.

3.7.4 Starts After End Of The Starts After End Of operator asserts that the start date/time of an event on the left-hand side is temporally after the end date/time of an event on the right-hand side.

The following example asserts that a diagnosis of diabetes started after an inpatient encounter ended:

"Diagnosis: Diabetes" starts after end of "Encounter: Hospital Inpatient"

3.7.5 Starts Concurrent With The Starts Concurrent With operator asserts that the start date/time of an event on the left- hand side is the same as the start date/time of an event on the right-hand side.

The following example asserts that an ICU admission or transfer started at the same time as an inpatient encounter:

"Encounter, Performed: ICU Admission or Transfer" starts concurrent with "Encounter, Performed: Encounter Inpatient"

Note: Since the QDM defines timing comparisons to have a default precision of one minute, the start of the left-hand event must be within one minute of the start of the right-hand event. This may limit the number of use cases in which this temporal operator is applicable.

3.7.6 Starts Concurrent With End Of The Starts Concurrent With End Of operator asserts that the start date/time of an event on the left-hand side is the same as the end date/time of an event on the right-hand side.

The following example asserts that a medication became active at the end of an office visit: "Medication, Active: Antibiotic Medications" starts concurrent with end

of "Encounter, Performed: Office Visit"

Note: Since the QDM defines timing comparisons to have a default precision of one minute, the start of the left-hand event must be within one minute of the end of the right-hand event. This may limit the number of use cases in which this temporal operator is applicable.

3.7.7 Starts Before Or Concurrent With Start Of The Starts Before or Concurrent With Start Of operator asserts that the start date/time of an event on the left-hand side is temporally before or equal to the start date/time of an event on the right-hand side.

CMS / ONC Logic

Quality Data Model, Version 4.2 25 August 31, 2015

The following example asserts that an inpatient encounter started before or at the same time as a diagnosis of diabetes:

"Encounter: Hospital Inpatient" starts before or concurrent with start of "Diagnosis: Diabetes"

3.7.8 Starts After Or Concurrent With Start Of The Starts After or Concurrent With Start Of operator asserts that the start date/time of an event on the left-hand side is temporally after or equal to the start date/time of an event on the right-hand side.

The following example asserts that a diagnosis of diabetes started after or at the same time as an inpatient encounter started:

"Diagnosis: Diabetes" starts after or concurrent with start of "Encounter: Hospital Inpatient"

3.7.9 Starts Before Or Concurrent With End Of The Starts Before or Concurrent With End of operator asserts that the start date/time of an event on the left-hand side is temporally before or equal to the end date/time of an event on the right-hand side.

The following example asserts that an inpatient encounter started before or during a diagnosis of diabetes:

"Encounter: Hospital Inpatient" starts before or concurrent with end of "Diagnosis: Diabetes"

3.7.10 Starts After Or Concurrent With End Of The Starts After or Concurrent With End Of operator asserts that the start date/time of an event on the left-hand side is temporally after or equal to the end date/time of an event on the right-hand side.

The following example asserts that a diagnosis of diabetes started after or at the same time as an inpatient encounter ended:

"Diagnosis: Diabetes" starts after or concurrent with end of "Encounter: Hospital Inpatient"

3.7.11 Starts During The Starts During operator asserts that the start date/time of an event on the left-hand side is both:

• Temporally after or equal to the start date/time of an event on the right-hand side • Temporally before or equal to the end date/time of the same right-hand side event

The following example asserts that a diagnosis of diabetes started during an inpatient encounter: "Diagnosis: Diabetes" starts during "Encounter: Hospital Inpatient"

CMS / ONC Logic

Quality Data Model, Version 4.2 26 August 31, 2015

3.7.12 Ends Before Start Of The Ends Before Start Of operator asserts that the end date/time of an event on the left-hand side is temporally before the start date/time of an event on the right-hand side.

The following example asserts that an inpatient encounter ended before a diagnosis of diabetes started:

"Encounter: Hospital Inpatient" ends before start of "Diagnosis: Diabetes"

3.7.13 Ends After Start Of The Ends After Start Of operator asserts that the end date/time of an event on the left-hand side is temporally after the start date/time of an event on the right-hand side.

The following example asserts that a diagnosis of diabetes ended after the measurement period started:

"Diagnosis: Diabetes" ends after start of "Measurement Period"

3.7.14 Ends Before End Of The Ends Before End Of operator asserts that the end date/time of an event on the left-hand side is temporally before the end date/time of an event on the right-hand side.

The following example asserts that a diagnosis of diabetes ended before the end of the measurement period:

"Diagnosis: Diabetes" ends before end of "Measurement Period"

Note: Previous versions of QDM represented this relationship using the Ends Before Or During operator.

3.7.15 Ends After End Of The Ends After End Of operator asserts that the end date/time of an event on the left-hand side is temporally after the end date/time of an event on the right-hand side.

The following example asserts that a diagnosis of diabetes ended after an inpatient encounter ended:

"Diagnosis: Diabetes" ends after end of "Encounter: Hospital Inpatient"

3.7.16 Ends Concurrent With The Ends Concurrent With operator asserts that the end date/time of an event on the left-hand side is the same as the end date/time of an event on the right-hand side.

The following example asserts that an inpatient encounter ended at the same time as diagnosis of diabetes ended:

"Encounter: Hospital Inpatient" ends concurrent with "Diagnosis : Diabetes"

CMS / ONC Logic

Quality Data Model, Version 4.2 27 August 31, 2015

Note: Since the QDM defines timing comparisons to have a default precision of one minute, the end of the left-hand event must be within one minute of the end of the right-hand event. This may limit the number of use cases in which this temporal operator is applicable.

3.7.17 Ends Concurrent With Start Of The Ends Concurrent With Start Of operator asserts that the end date/time of an event on the left-hand side is the same as the start date/time of an event on the right-hand side.

The following example asserts that an office visit ended at the same time as antibiotic medications became active:

"Encounter: Office Visit" ends concurrent with start of "Medication, Active: Antibiotic Medications"

Note: Since the QDM defines timing comparisons to have a default precision of one minute, the end of the left-hand event must be within one minute of the start of the right-hand event. This may limit the number of use cases in which this temporal operator is applicable.

3.7.18 Ends Before Or Concurrent With End Of The Ends Before Or Concurrent With End Of operator asserts that the end date/time of an event on the left-hand side is temporally before or equal to the end date/time of an event on the right-hand side.

The following example asserts that a diagnosis of diabetes ended before or during the measurement period:

"Diagnosis: Diabetes" ends before or concurrent with end of "Measurement Period"

3.7.19 Ends After Or Concurrent With End Of The Ends After Or Concurrent With End Of operator asserts that the end date/time of an event on the left-hand side is temporally after or equal to the end date/time of an event on the right-hand side.

The following example asserts that a diagnosis of diabetes ended after or at the same time as an inpatient encounter ended:

"Diagnosis: Diabetes" ends after or concurrent with end of "Encounter: Hospital Inpatient"

3.7.20 Ends Before Or Concurrent With Start Of The Ends Before Or Concurrent With Start Of operator asserts that the end date/time of an event on the left-hand side is temporally before or equal to the start date/time of an event on the right-hand side.

The following example asserts that an inpatient encounter ended before or at the same time as a diagnosis of diabetes started:

"Encounter: Hospital Inpatient" ends before or concurrent with start of "Diagnosis: Diabetes"

CMS / ONC Logic

Quality Data Model, Version 4.2 28 August 31, 2015

3.7.21 Ends After Or Concurrent With Start Of The Ends After Or Concurrent With Start Of operator asserts that the end date/time of an event on the left-hand side is temporally after or equal to the start date/time of an event on the right-hand side.

The following example asserts that a diagnosis of diabetes ended after or at the same time as the measurement period started:

"Diagnosis: Diabetes" ends after or concurrent with start of "Measurement Period"

3.7.22 Ends During The Ends During operator asserts that the end date/time of an event on the left-hand side is both:

• Temporally after or equal to the start date/time of an event on the right-hand side • Temporally before or equal to the end date/time of the same right-hand side event

The following example asserts that a diagnosis of diabetes ended during the measurement period: "Diagnosis: Diabetes" ends during "Measurement Period"

3.7.23 Concurrent With The Concurrent With operator asserts that an event on the left-hand side has the same effective time as an event on the right-hand side. In other words, both of the following statements must be true:

• The start date/time of an event on the left-hand side is equal to the start date/time of an event on the right-hand side

• The end date/time of the same left-hand side event is equal to the end date/time of the same right-hand side event

The following example asserts that an order of Leucovorin is concurrent with an order of Dapsone and Pyrimethamine:

"Medication, Order: Leucovorin" concurrent with "Medication, Order: Dapsone and Pyrimethamine"

Note: Since the QDM defines timing comparisons to have a default precision of one minute, the starts of the events must be within one minute of each other and the ends of the events must be within one minute of each other. This may limit the number of use cases in which this temporal operator is applicable.

3.7.24 During The During operator asserts that an event on the left-hand side is wholly within an event on the right-hand side. In other words, both of the following statements must be true:

• The start date/time of an event on the left-hand side is after or equal to the start date/time of an event on the right-hand side

CMS / ONC Logic

Quality Data Model, Version 4.2 29 August 31, 2015

• The end date/time of the same left-hand side event is before or equal to the end date/time of the same right-hand side event

The following example asserts that an inpatient encounter occurred wholly within the measurement period:

"Encounter: Hospital Inpatient" during "Measurement Period"

3.7.25 Overlaps The Overlaps operator asserts that there exists some point in time at which the event on the left- hand side is effective at the same time as the event on the right-hand side.

The following example asserts that an inpatient encounter overlapped the measurement period: "Encounter: Hospital Inpatient" overlaps "Measurement Period"

Since events can have a left overlap, right overlap, inner overlap, or outer overlap, the Overlaps operator uses the start date/time and end date/time of each event to determine if there is overlap.

In cases where an event lacks a recorded end date/time, the Overlaps operator will interpret the missing end date/time as ongoing (i.e., positive infinity). This interpretation allows common use cases (such as a diagnosis overlapping the measurement period) to work as measure developers intend.

Table 1 demonstrates the calculated results of an overlap operation for various sets of data corresponding to the QDM statement:

"Diagnosis: Diabetes" overlaps "Measurement Period"

Table 1. Examples of Inputs and Results for Overlaps Dx Start Dx End MP Start MP End Dx Overlaps MP? 6/1/2010 6/1/2012 1/1/2013 12/31/2013 false 6/1/2010 6/1/2013 1/1/2013 12/31/2013 true 6/1/2010 6/1/2014 1/1/2013 12/31/2013 true 6/1/2010 none 1/1/2013 12/31/2013 true 6/1/2013 8/1/2013 1/1/2013 12/31/2013 true 6/1/2013 6/1/2014 1/1/2013 12/31/2013 true 6/1/2013 none 1/1/2013 12/31/2013 true 6/1/2014 8/1/14 1/1/2013 12/31/2013 false 6/1/2014 none 1/1/2013 12/31/2013 false

Note: This interpretation of missing data is unique to Overlaps and does not apply to other temporal operators (e.g., During). In addition, measure developers should consider the potentially unintended consequences of using Overlaps with datatypes that are not usually ongoing. For example, if an EHR reports only a start date/time for a procedure, the Overlaps operator will treat the procedure as ongoing even though the procedure has likely ended. For this

CMS / ONC Logic

Quality Data Model, Version 4.2 30 August 31, 2015

reason, EHR vendors are encouraged to always report an end date/time for events that are known to have ended (including events that occur at a single point in time).

3.7.26 Null Date/Time Comparisons in Temporal Operators It is important to note that whenever a temporal operator compares a null (i.e., missing) date/time, it will always evaluate to false. For example, Ends Before Start Of returns false if the left-hand side event has a missing end date/time or the right-hand side event has a missing start date/time. Consult the definition of each temporal operator to determine which date/times are required.

3.8 Operator Precedence Measure specifications are evaluated in a manner that differs from a typical procedural specification. A measure is composed of populations (e.g., Denominator, Numerator), and each population is composed from “lines” of logic that constitute a single AND/OR statement. The order of the lines within a population does not determine the computed result. Within a line, logic is evaluated according to the order of operations described in the following table.10

The example column in Table 2 describes how the order of operations applies to the execution of the QDM phrase below:

FIRST : "Occurrence A of Procedure, Performed: abc (method: xyz)" during "Measurement Period"

Table 2. Operator Precedence Order Precedence Rule Example

1 First, evaluate that the data element’s code is present in a matching QDM element’s category value set.

Select all procedures from a patient based on matching code as defined by the QDM element’s value set “abc.”

2 Filter to only include data elements that match QDM element’s datatype (e.g., active, ordered, resolved).

Only select procedures that were actually performed. Do not select procedures that were ordered or recommended.

3 Filter data elements based on whether the QDM element has the negation rationale attribute.

Check whether the procedure was not done for a particular reason. Additional example: "Procedure, Performed: abc (not done: reason not done)"

4 Filter out data elements based on QDM attribute value set criteria (e.g., method, severity, facility location).

Only select procedures that have the right method, based on QDM attribute method value set “xyz.”

5 Filter out data elements that do not meet temporal constraints (e.g., starts after start, during).

Only select procedures that occur within the measurement period.

10 Note: The only way to link the events described in one line of logic with those in another line of logic is through

the use of specific occurrences.

CMS / ONC Logic

Quality Data Model, Version 4.2 31 August 31, 2015

Order Precedence Rule Example 6 Filter out data elements that don’t meet attribute

comparison criteria. Not applicable to above example. Additional example: "Physical Exam, Performed: Systolic Blood Pressure (result < 140 mmHg)"

7 Filter data elements by function (FIRST, SECOND, MOST RECENT).

Only select the first procedure data element matching all of the above criteria

8 Label data elements with a specific occurrence. Label the matching procedure as occurrence A so that it can be referenced in subsequent AND/OR statements or distinguished from another

Note that when filtering out data elements that do not meet temporal constraints (Step 6), first the timing relationship is evaluated using minute granularity and then the delta (if specified) is evaluated using the granularity of the specified timing unit. For example, < 3 day(s) starts before start of would first evaluate if the starts before start of constraint is met. If so, it would then determine if the delta is less than 3 days.

Also note that the order of applying the subset operators (Step 7) is critical, since the order in which subset operators are applied can change the results of execution. For instance, the result of selecting the first procedure and then restricting it temporally to “during the measurement period” could produce a different result from what would be produced by restricting procedures temporally to “during the measurement period” and then selecting the first such procedure.

CMS / ONC

Quality Data Model, Version 4.2 32 August 31, 2015

4. Component Definitions

4.1 Categories and Datatypes

4.1.1 Care Experience Care Experience represents 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.

Table 3. Care Experience Datatypes and Attributes Datatype Definition Attributes

Patient Care Experience

Data elements that meet this criterion indicate the patient’s care experience, usually measured with a validated survey tool. The most common tool is the Consumer Assessment of Healthcare Providers and Systems.

• Start Datetime • Stop Datetime

Provider Care Experience

Data elements that meet this criterion indicate the provider's experience with availability of resources (e.g., scheduling, equipment, space, and such consumables as medications). Provider care experience gauges provider satisfaction with key structures, processes, and outcomes in the healthcare delivery system.

• Start Datetime • Stop Datetime

4.1.2 Care Goal Care Goal represents 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. Specifically, a care plan is composed of the following elements:

• Problem, which is managed by other QDM standard categories (condition/diagnosis/ problem) and their related data elements.

• Procedure, which is managed by other standard categories and their related data elements. Note that procedures are a continuum of interventions ranging from actions patients can do for themselves to those that can be performed by others (caregivers or clinical professionals), including detailed complex surgical procedures requiring highly trained physicians, nurses, and state-of-the-art facilities.

• Goal, which is what is expected to happen.

CMS / ONC Component Definitions

Quality Data Model, Version 4.2 33 August 31, 2015

• Outcome, which is what happened. An outcome can be shown by other QDM standard categories and their related data elements.

Table 4. Care Goal Datatype and Attributes Datatype Definition Attributes

Care Goal Unlike other QDM datatypes, the Care Goal datatype does not indicate a specific context of use. Instead, to meet this criterion, there must be documentation of a care goal as defined by the Care Goal QDM category and its corresponding value set.

• Related To • Start Datetime • Stop Datetime • Target Outcome

4.1.3 Communication Communication represents 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.

Table 5. Communication Datatypes and Attributes Datatype Definition Attributes

Communication: From Patient to Provider

To meet criteria using this datatype, the communication indicated by the Communication QDM category and its corresponding value set must be communicated from a patient to a provider.

• Negation Rationale • Start Datetime • Stop Datetime

Communication: From Provider to Patient

To meet criteria using this datatype, the communication indicated by the Communication QDM category and its corresponding value set must be communicated from a provider to a patient.

• Negation Rationale • Start Datetime • Stop Datetime

Communication: From Provider to Provider

To meet criteria using this datatype, the communication indicated by the Communication QDM category and its corresponding value set must be communicated from one provider to another.

• Negation Rationale • Start Datetime • Stop Datetime

4.1.4 Condition/Diagnosis/Problem Condition/Diagnosis/Problem represents 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).

CMS / ONC Component Definitions

Quality Data Model, Version 4.2 34 August 31, 2015

The QDM does not prescribe the source of diagnosis data in the EHR. Diagnoses may be found in a patient’s problem list, encounter diagnosis list, claims data, or other sources within the EHR. The preferred terminology for diagnoses is SNOMED-CT, but diagnoses may also be encoded using ICD-9/10.

The Diagnosis datatype should not be used for differential diagnoses or rule-out diagnoses (neither of which are currently supported by the QDM).

Table 6. Condition/Diagnosis/Problem Datatypes and Attributes Datatype Definition Attributes

Diagnosis Data elements that meet criteria using this datatype should document the Condition/Diagnosis/Problem and its corresponding value set. The onset datetime corresponds to the implicit start datetime of the datatype and the abatement datetime corresponds to the implicit stop datetime of the datatype. If the abatement datetime is null, then the diagnosis is considered to still be active. When this datatype is used with timing relationships, the criterion is looking for an active diagnosis for the time frame indicated by the timing relationships.

• Abatement Datetime • Onset Datetime • Anatomical Location Site • Severity

4.1.5 Device Device represents 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.11

Table 7. Device Datatypes and Attributes Datatype Definition Attributes

Device, Adverse Event

Data elements that meet criteria using this datatype should document an unexpected or dangerous reaction to a device indicated by the QDM category and its corresponding value set.

• Reaction • Start Datetime • Stop Datetime

Device, Allergy Data elements that meet criteria using this datatype should document an immunologically mediated reaction that exhibits specificity and recurrence on re-exposure to the offending device indicated by the QDM category and its corresponding value set.

• Reaction • Start Datetime • Stop Datetime

11 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 2014.

CMS / ONC Component Definitions

Quality Data Model, Version 4.2 35 August 31, 2015

Datatype Definition Attributes Device, Applied Data elements that meet criteria using this

datatype should document that the device indicated by the QDM category and its corresponding value set is in use, or impacts or alters the treatment, care plan, or encounter (e.g., an antithrombotic device has been placed on the patient's legs to prevent thromboembolism, or a cardiac pacemaker is in place).

• Anatomical Approach Site • Anatomical Location Site • Negation Rationale • Reason • Removal Datetime • Start Datetime

Device, Intolerance Data elements that meet criteria using this datatype should document a reaction in specific patients who have a low threshold to the normal reported or expected reactions of the device indicated by the QDM category and its corresponding value set.

• Reaction • Start Datetime • Stop Datetime

Device, Order Data elements that meet criteria using this datatype should document an order for the device indicated by the QDM category and its corresponding value set. NOTE: The start and stop datetime of Device, Order reflects the “author time” of the record in the Quality Reporting Document Architecture (QRDA). This corresponds to when the order was signed.

• Negation Rationale • Reason • Start Datetime • Stop Datetime

Device, Recommended

Data elements that meet criteria using this datatype should document a recommendation to use the device indicated by the QDM category and its corresponding value set.

• Negation Rationale • Reason • Start Datetime • Stop Datetime

4.1.6 Diagnostic Study Diagnostic Study represents 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).12 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.

12 Canada Health Infoway EHR Glossary, https://www.infoway-inforoute.ca/. Last accessed August 2014.

CMS / ONC Component Definitions

Quality Data Model, Version 4.2 36 August 31, 2015

Table 8. Diagnostic Study Datatypes and Attributes Datatype Definition Attributes

Diagnostic Study, Adverse Event

Data elements that meet criteria using this datatype should document an unexpected or dangerous reaction to the diagnostic study indicated by the QDM category and its corresponding value set.

• Radiation Dosage • Radiation Duration • Reaction • Start Datetime • Stop Datetime

Diagnostic Study, Intolerance

Data elements that meet criteria using this datatype should document a reaction in specific patients who have a low threshold to the normal reported or expected reactions of the diagnostic study indicated by the QDM category and its corresponding value set.

• Radiation Dosage • Radiation Duration • Reaction • Start Datetime • Stop Datetime

Diagnostic Study, Order

Data elements that meet criteria using this datatype should document a request by a clinician or appropriately licensed care provider to an appropriate provider or organization to perform the diagnostic study indicated by the QDM category and its corresponding value set. The request may be in the form of a consultation or a direct order to the organization that performs the diagnostic study. Diagnostic studies are those that are not performed in the clinical laboratory. Such studies include but are not limited to imaging studies, cardiology studies (electrocardiogram, treadmill stress testing), pulmonary function testing, vascular laboratory testing, and others. NOTE: The start and stop datetime of Medication, Order reflects the “author time” of the record in QRDA. This corresponds to when the order was signed.

• Method • Negation Rationale • Radiation Dosage • Radiation Duration • Reason • Start Datetime • Stop Datetime

Diagnostic Study, Performed

Data elements that meet criteria using this datatype should document the completion of the diagnostic study indicated by the QDM category and its corresponding value set.

• Facility Location • Method • Negation Rationale • Radiation Dosage • Radiation Duration • Reason • Result • Start Datetime • Status • Stop Datetime

Diagnostic Study, Recommended

Data elements that meet criteria using this datatype should document a recommendation for a request by a clinician or appropriately licensed care provider to an appropriate provider or organization to perform the diagnostic study indicated by the QDM category and its corresponding value set.

• Method • Negation Rationale • Radiation Dosage • Radiation Duration • Start Datetime • Stop Datetime

CMS / ONC Component Definitions

Quality Data Model, Version 4.2 37 August 31, 2015

4.1.7 Encounter Encounter represents 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.13 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.

Table 9. Encounter Datatypes and Attributes Datatype Definition Attributes

Encounter, Active Data elements that meet criteria using this datatype should document that an encounter indicated by the QDM category and its corresponding value set is in progress. Keep in mind that when this datatype is used with timing relationships, the criterion is looking for an encounter that was in progress for the time frame indicated by the timing relationships.

• Admission Datetime • Discharge Datetime • Facility Location • Facility Location Arrival Datetime • Facility Location Departure

Datetime • Length of Stay • Reason

Encounter, Order Data elements that meet criteria using this datatype should document that an order for the encounter indicated by the QDM category and its corresponding value set has been recommended. NOTE: The start and stop datetime of Encounter, Order reflects the “author time” of the record in QRDA. This corresponds to when the order was signed.

• Facility Location • Negation Rationale • Reason • Start Datetime • Stop Datetime

13 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 2014.

CMS / ONC Component Definitions

Quality Data Model, Version 4.2 38 August 31, 2015

Datatype Definition Attributes Encounter, Performed

Data elements that meet criteria using this datatype should document that the encounter indicated by the QDM category and its corresponding value set has been completed.

• Admission Datetime • Diagnosis • Discharge Datetime • Discharge Status • Facility Location • Facility Location Arrival Datetime • Facility Location Departure

Datetime • Length of Stay • Negation Rationale • Principal Diagnosis • Reason

Encounter, Recommended

Data elements that meet criteria using this datatype should document that the encounter indicated by the QDM category and its corresponding value set has been recommended.

• Facility Location • Negation Rationale • Reason • Start Datetime • Stop Datetime

4.1.8 Family History Family History represents 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.

If a relationship is specified, codes from the HL7 Personal Relationship Role Type value set (2.16.840.1.113883.1.11.19563) should be used to ensure compatibility with QRDA reporting constraints.

Table 10. Condition/Diagnosis/Problem Datatypes and Attributes Datatype Definition Attributes

Family History To meet criteria using this datatype, the diagnosis/problem indicated by the FamilyHistory QDM category and its corresponding value set should reflect a diagnosis/problem of a family member. When used in timing relationships, the recorded datetime acts as both the implicit start datetime and implicit stop datetime.

• Onset Age • Recorded Datetime • Relationship

4.1.9 Functional Status Functional Status is specific to tools that evaluate an individual patient’s actual physical or behavioral performance as an indicator of capabilities at a point in time. The functional status assessment can be used in measurement to determine change in physical or behavioral performance over time, or specific capabilities that cause a patient to be included or excluded from a measurement population.

Examples include: Eastern Cooperative Oncology Group (ECOG) Performance Status, Edmonton Functional Assessment Tool (EFAT), Karnofsky Performance Scale, Katz Index of

CMS / ONC Component Definitions

Quality Data Model, Version 4.2 39 August 31, 2015

Independence in Activities of Daily Living, Palliative Performance Scale Version 2, the Medical Outcomes Study (MOS) Short Form Survey Instrument (SF-12), and the Asthma Quality of Life Questionnaire. Alternately, risk assessment refers to appraisals of health and well-being, providing information as to the risk for conditions or increased severity of illness (e.g., Braden Skin Scale, Morse Fall Risk Scale), while physical exam includes psychiatric examinations.

Table 11. Functional Status Datatypes and Attributes Datatype Definition Attributes

Functional Status, Order

Data elements that meet criteria using this datatype should document that a request to perform the functional status assessment indicated by the QDM category and its corresponding value set has been completed. NOTE: The start and stop datetime of Functional Status, Order reflects the “author time” of the record in QRDA. This corresponds to when the order was signed.

• Method • Negation Rationale • Reason • Start Datetime • Stop Datetime

Functional Status, Performed

Data elements that meet criteria using this datatype should document the completion of the functional status assessment indicated by the QDM category and its corresponding value set.

• Method • Negation Rationale • Reason • Result • Start Datetime • Stop Datetime

Functional Status, Recommended

Data elements that meet criteria using this datatype should document a recommendation regarding the functional status assessment indicated by the QDM category and that its corresponding value set has been completed.

• Method • Negation Rationale • Reason • Start Datetime • Stop Datetime

4.1.10 Immunization Immunization represents vaccines administered to patients in healthcare settings but does not include non-vaccine agents.

Table 12. Immunization Datatypes and Attributes Datatype Definition Attributes

Immunization, Administered

Data elements that meet criteria using this datatype should document that the vaccine indicated by the QDM category and its corresponding value set was actually administered to the patient.

• Dose • Negation Rationale • Reason • Route • Start Datetime • Stop Datetime

CMS / ONC Component Definitions

Quality Data Model, Version 4.2 40 August 31, 2015

Datatype Definition Attributes Immunization, Allergy

Data elements that meet criteria using this datatype should document an immunologically mediated reaction that exhibits specificity and recurrence on re-exposure to the offending vaccine indicated by the QDM category and its corresponding value set.

• Reaction • Start Datetime • Stop Datetime

Immunization, Intolerance

Data elements that meet criteria using this datatype should document a reaction in specific patients representing a low threshold to the normal pharmacological action of the vaccine indicated by the QDM category and its corresponding value set.

• Reaction • Start Datetime • Stop Datetime

Immunization, Order

Data elements that meet criteria using this datatype should document a request for the immunization indicated by the QDM category and its corresponding value set. NOTE: The start and stop datetime of Immunization, Order reflects the “author time” of the record in QRDA. This corresponds to when the order was signed.

• Active Datetime • Dose • Negation Rationale • Reason • Route • Signed Datetime • Start Datetime • Stop Datetime

4.1.11 Individual Characteristic Individual Characteristic represents 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. In the quality data element the attribute source is used to indicate whether it relates to the patient or the provider.

Table 13. Individual Characteristic Datatypes and Attributes Datatype Definition Attributes

Patient Characteristic

Data elements that meet criteria using this datatype should document a characteristic of the patient not represented by one of the more specific Individual Characteristic datatypes.

• Start Datetime • Stop Datetime

CMS / ONC Component Definitions

Quality Data Model, Version 4.2 41 August 31, 2015

Datatype Definition Attributes Patient Characteristic Birthdate

The Patient Characteristic Birthdate data element should document the patient’s date of birth. Note: Patient Characteristic Birthdate is fixed to LOINC code 21112-8 (Birth date) and therefore cannot be further qualified with a value set.

• Start Datetime • Stop Datetime

Patient Characteristic Clinical Trial Participant

Data elements that meet criteria using this datatype should document that the patient is a clinical trial participant for the clinical trial indicated by the QDM category and its corresponding value set.

• Reason • Start Datetime • Stop Datetime

Patient Characteristic Ethnicity

Data elements that meet criteria using this datatype should document that the patient has one or more of the ethnicities indicated by the QDM category and its corresponding value set.

• None

Patient Characteristic Expired

The Patient Characteristic Expired data element should document that the patient is deceased. Note: Patient Characteristic Expired is fixed to SNOMED-CT® code 419099009 (Dead) and therefore cannot be further qualified with a value set.

• Cause • Date • Time

Patient Characteristic Payer

Data elements that meet criteria using this datatype should document that the patient has one or more of the payers indicated by the QDM category and its corresponding value set.

• Start Datetime • Stop Datetime

Patient Characteristic Race

Data elements that meet criteria using this datatype should document the patient’s race.

• None

Patient Characteristic Sex

Data elements that meet criteria using this datatype should document that the patient's sex matches the QDM category and its corresponding value set.

• Start Datetime • Stop Datetime

Provider Characteristic

Data elements that meet criteria using this datatype should document a characteristic of the provider.

• Start Datetime • Stop Datetime

4.1.12 Intervention Intervention represents 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.

Table 14. Intervention Datatypes and Attributes Datatype Definition Attributes

Intervention, Adverse Event

Data elements that meet criteria using this datatype should document an unexpected or dangerous reaction to the intervention indicated by the QDM category and its corresponding value set.

• Reaction • Start Datetime • Stop Datetime

CMS / ONC Component Definitions

Quality Data Model, Version 4.2 42 August 31, 2015

Datatype Definition Attributes Intervention, Intolerance

Data elements that meet criteria using this datatype should document a reaction in specific patients representing a low threshold to the normal reported or expected reactions of intervention indicated by the QDM category and its corresponding value set.

• Reaction • Start Datetime • Stop Datetime

Intervention, Order Data elements that meet criteria using this datatype should document a request to perform the intervention indicated by the QDM category and its corresponding value set. NOTE: The start and stop datetime of Intervention, Order reflects the “author time” of the record in QRDA. This corresponds to when the order was signed.

• Negation Rationale • Reason • Start Datetime • Stop Datetime

Intervention, Performed

Data elements that meet criteria using this datatype should document the completion of the intervention indicated by the QDM category and its corresponding value set.

• Negation Rationale • Reason • Result • Start Datetime • Status • Stop Datetime

Intervention, Recommended

Data elements that meet criteria using this datatype should document a recommendation for the intervention indicated by the QDM category and its corresponding value set.

• Negation Rationale • Reason • Start Datetime • Stop Datetime

4.1.13 Laboratory Test Laboratory Test represents 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.14 Laboratory tests may be performed on specimens not derived from patients (electrolytes or contents of water or consumed fluids, cultures of environment, pets, other animals). The states will remain the same.

Table 15. Laboratory Test Datatypes and Attributes Datatype Definition Attributes

Laboratory Test, Adverse Event

Data elements that meet criteria using this datatype should document an unexpected or dangerous reaction to the laboratory test indicated by the QDM category and its corresponding value set.

• Reaction • Start Datetime • Stop Datetime

14 National Cancer Institute (NCI). Bethesda, MD: NCI; 2010. Available at: www.cancer.gov/. Last accessed August

2014.

CMS / ONC Component Definitions

Quality Data Model, Version 4.2 43 August 31, 2015

Datatype Definition Attributes Laboratory Test, Intolerance

Data elements that meet criteria using this datatype should document a reaction in specific patients representing a low threshold to the normal reported or expected reactions of the laboratory test indicated by the QDM category and its corresponding value set.

• Reaction • Start Datetime • Stop Datetime

Laboratory Test, Order

Data elements that meet criteria using this datatype should document a request for the laboratory test indicated by the QDM category and its corresponding value set. NOTE: The start and stop datetime of Laboratory Test, Order reflects the “author time” of the record in QRDA. This corresponds to when the order was signed.

• Method • Negation Rationale • Reason • Start Datetime • Stop Datetime

Laboratory Test, Performed

Data elements that meet criteria using this datatype should document the laboratory test indicated by the QDM category and its corresponding value set was performed.

• Method • Negation Rationale • Reason • Reference Range High • Reference Range Low • Result • Start Datetime • Status • Stop Datetime

Laboratory Test, Recommended

Data elements that meet criteria using this datatype should document a recommendation for the laboratory test indicated by the QDM category and its corresponding value set.

• Method • Negation Rationale • Reason • Start Datetime • Stop Datetime

4.1.14 Medication Medication represents clinical drugs or chemical substances intended for use in the medical diagnosis, cure, treatment, or prevention of disease. A medication contains a value derived from taxonomies such as RxNorm.15

Table 16. Medication Datatypes and Attributes Datatype Definition Attributes

Medication, Active Data elements that meet criteria using this datatype should document that the medication indicated by the QDM category and its corresponding value set is being taken by the patient. Keep in mind that when this datatype is used with timing relationships, the criterion is looking for a medication being taken for the time frame indicated by the timing relationships.

• Cumulative Medication Duration • Dose • Frequency • Route • Start Datetime • Stop Datetime

15 See https://www.nlm.nih.gov/research/umls/rxnorm/. Last accessed August 2014.

CMS / ONC Component Definitions

Quality Data Model, Version 4.2 44 August 31, 2015

Datatype Definition Attributes Medication, Administered

Data elements that meet criteria using this datatype should document that the medication indicated by the QDM category and its corresponding value set was actually administered to the patient.

• Cumulative Medication Duration • Dose • Frequency • Negation Rationale • Reason • Route • Start Datetime • Stop Datetime

Medication, Adverse Effects

Data elements that meet criteria using this datatype should document an unexpected or dangerous reaction to the medication indicated by the QDM category and its corresponding value set.

• Reaction • Start Datetime • Stop Datetime

Medication, Allergy Data elements that meet criteria using this datatype should document an immunologically mediated reaction that exhibits specificity and recurrence on re-exposure to the offending medication indicated by the QDM category and its corresponding value set.

• Reaction • Start Datetime • Stop Datetime

Medication, Discharge

Data elements that meet criteria using this datatype should document that the medications indicated by the QDM category and its corresponding value set should be taken by or given to the patient after being discharged from an inpatient encounter.

• Dose • Frequency • Negation Rationale • Refills • Route • Start Datetime • Stop Datetime

Medication, Dispensed

Data elements that meet criteria using this datatype should document that a prescription for the medication indicated by the QDM category and its corresponding value set has been dispensed and provided to the patient or patient proxy. In the ambulatory setting, medications are primarily taken directly by patients and not directly observed. Hence, dispensed is the closest health provider documentation of medication compliance. In settings where patients attest to taking medications in electronic format (perhaps a Personal Health Record), patient attestation of “medication taken” may be available.

• Cumulative Medication Duration • Dose • Frequency • Negation Rationale • Refills • Route • Start Datetime • Stop Datetime

Medication, Intolerance

Data elements that meet criteria using this datatype should document a reaction in specific patients representing a low threshold to the normal pharmacological action of the medication indicated by the QDM category and its corresponding value set.

• Reaction • Start Datetime • Stop Datetime

CMS / ONC Component Definitions

Quality Data Model, Version 4.2 45 August 31, 2015

Datatype Definition Attributes Medication, Order Data elements that meet criteria using this

datatype should document a request to a pharmacy to provide the medication indicated by the QDM category and its corresponding value set. NOTE: The start and stop datetime of Medication, Order reflects the “author time” of the record in QRDA. This corresponds to when the order was signed.

• Active Datetime • Cumulative Medication Duration • Dose • Frequency • Method • Negation Rationale • Reason • Refills • Route • Signed Datetime • Start Datetime • Stop Datetime

4.1.15 Physical Exam Physical Exam represents the evaluation of the patient's body to determine its state of health. The techniques of inspection include palpation (feeling with the hands or fingers), percussion (tapping with the fingers), auscultation (listening), visual inspection, 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.

Table 17. Physical Exam Datatypes and Attributes Datatype Definition Attributes

Physical Exam, Order

Data elements that meet criteria using this datatype should document a request for the physical exam indicated by the QDM category and its corresponding value set. The datatype is expected to be used to identify orders such as "vital signs, frequency every x hours,” or "pedal pulse check, frequency every 15 minutes for x hours." NOTE: The start and stop datetime of Physical Exam, Order reflects the “author time” of the record in QRDA. This corresponds to when the order was signed.

• Anatomical Location Site • Method • Negation Rationale • Reason • Start Datetime • Stop Datetime

Physical Exam, Performed

Data elements that meet criteria using this datatype should document the completion of the physical exam indicated by the QDM category and its corresponding value set.

• Anatomical Location Site • Method • Negation Rationale • Reason • Result • Start Datetime • Stop Datetime

CMS / ONC Component Definitions

Quality Data Model, Version 4.2 46 August 31, 2015

Datatype Definition Attributes Physical Exam, Recommended

Data elements that meet criteria using this datatype should document a recommendation for the physical exam indicated by the QDM category and its corresponding value set.

• Anatomical Location Site • Method • Negation Rationale • Reason • Start Datetime • Stop Datetime

4.1.16 Procedure Procedure is derived directly from HL7 and Canada Health Infoway: “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.”16 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. 17

Table 18. Procedure Datatypes and Attributes Datatype Definition Attributes

Procedure, Adverse Event

Data elements that meet criteria using this datatype should document an unexpected or dangerous reaction to the procedure indicated by the QDM category and its corresponding value set.

• Reaction • Start Datetime • Stop Datetime

Procedure, Intolerance

Data elements that meet criteria using this datatype should document a reaction in specific patients representing a low threshold to the normal execution of the procedure indicated by the QDM category and its corresponding value set.

• Ordinality • Reaction • Start Datetime • Stop Datetime

Procedure, Order Data elements that meet criteria using this datatype should document a request for the procedure indicated by the QDM category and its corresponding value set. NOTE: The start and stop datetime of Procedure, Order reflects the “author time” of the record in QRDA. This corresponds to when the order was signed.

• Anatomical Approach Site • Anatomical Location Site • Method • Negation Rationale • Ordinality • Radiation Duration • Reason • Start Datetime • Stop Datetime

16 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 2014. 17 Modified from Canada Health Infoway, available at: https://www.infoway-inforoute.ca/. Last accessed August

2014.

CMS / ONC Component Definitions

Quality Data Model, Version 4.2 47 August 31, 2015

Datatype Definition Attributes Procedure, Performed

Data elements that meet criteria using this datatype should document the completion of the procedure indicated by the QDM category and its corresponding value set.

• Anatomical Approach Site • Anatomical Location Site • Incision Datetime • Method • Negation Rationale • Ordinality • Radiation Dosage • Radiation Duration • Reason • Result • Start Datetime • Status • Stop Datetime

Procedure, Recommended

Data elements that meet criteria using this datatype should document the recommendation for the procedure indicated by the QDM category and its corresponding value set.

• Anatomical Approach Site • Anatomical Location Site • Method • Negation Rationale • Ordinality • Reason • Start Datetime • Stop Datetime

4.1.17 Risk Category/Assessment Risk Category/Assessments include tools and calculators that suggest vulnerabilities for any given patient. Distinct from functional status, risk categorization uses findings, observations, results, and sometimes judgments and patient-generated information for use within clinical care algorithms, clinical decision support, and severity analysis. A time and date stamp is required. Examples include the Braden Score for Predicting Pressure Score Risk, Morse Fall Risk Scale, and Pneumonia Severity Index.18

Table 19. Risk Category/Assessment Datatypes and Attributes Datatype Definition Attributes

Risk Category/ Assessment

Data elements that meet criteria using this datatype should document the use of tools and calculators (indicated by the QDM category and its corresponding value set) that suggest vulnerabilities for any given patient. This datatype should be used with the QDM Attribute result to specify criteria related to the actual result.

• Negation Rationale • Result • Start Datetime • Stop Datetime

18 AHRQ, Pneumonia Severity Index Calculator (PSI), Bethesda, MD: AHRQ. Available at:

http://pda.ahrq.gov/clinic/psi/psi.htm. Last accessed August 2014.

CMS / ONC Component Definitions

Quality Data Model, Version 4.2 48 August 31, 2015

4.1.18 Substance Substance represents a chemical element and its compounds in the natural state or obtained by any manufacturing process (other than pharmaceutical drugs), including any additive necessary to preserve its stability and any impurity deriving from the process used, but excluding any solvent that may be separated without affecting the stability of the substance or changing its composition.19 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).

Table 20. Substance Datatypes and Attributes Datatype Definition Attributes

Substance, Administered

Data elements that meet criteria using this datatype should document that the substance indicated by the QDM category and its corresponding value set was actually given to the patient.

• Dose • Frequency • Negation Rationale • Route • Start Datetime • Stop Datetime

Substance, Adverse Event

Data elements that meet criteria using this datatype should document an unexpected or dangerous reaction to the substance (e.g., food, environmental agent) indicated by the QDM category and its corresponding value set.

• Reaction • Start Datetime • Stop Datetime

Substance, Allergy Data elements that meet criteria using this datatype should document an immunologically mediated reaction that exhibits specificity and recurrence on re-exposure to the offending substance indicated by the QDM category and its corresponding value set.

• Reaction • Start Datetime • Stop Datetime

Substance, Intolerance

Data elements that meet criteria using this datatype should document a reaction in specific patients representing a low threshold to the normal effects of the substance indicated by the QDM category and its corresponding value set.

• Reaction • Start Datetime • Stop Datetime

Substance, Order Data elements that meet criteria using this datatype should document a request for the substance indicated by the QDM category and its corresponding value set. NOTE: The start and stop datetime of Substance, Order reflects the “author time” of the record in QRDA. This corresponds to when the order was signed.

• Dose • Frequency • Method • Negation Rationale • Reason • Refills • Route • Start Datetime • Stop Datetime

19 European Chemicals Agency, REACH-Registration, Evaluation and Authorization of Chemicals, France; 2005.

Available at: www.prc.cnrs-gif.fr/reach/en/home.html. Last accessed August 2014.

CMS / ONC Component Definitions

Quality Data Model, Version 4.2 49 August 31, 2015

Datatype Definition Attributes Substance, Recommended

Data elements that meet criteria using this datatype should document a recommendation for the substance indicated by the QDM category and its corresponding value set.

• Dose • Frequency • Method • Negation Rationale • Reason • Refills • Route • Start Datetime • Stop Datetime

4.1.19 Symptom Symptom represents an indication that a person has a condition or disease. Some examples are headache, fever, fatigue, nausea, vomiting, and pain.20 Also, symptoms are subjective manifestations of the disease perceived by the patient.21 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.).

Table 21. Symptom Datatypes and Attributes Datatype Definition Attributes

Symptom Data elements that meet criteria using this datatype should document the symptom and its corresponding value set. The onset datetime corresponds to the implicit start datetime of the datatype and the abatement datetime corresponds to the implicit stop datetime of the datatype. If the abatement datetime is null, then the symptom is considered to still be active. When this datatype is used with timing relationships, the criterion is looking for whether the symptom was active for the time frame indicated by the timing relationships.

• Abatement Datetime • Onset Datetime • Severity

4.1.20 Transfer of Care Transfer of Care represents the different locations or settings a patient is released to, or received from, to ensure the coordination and continuity of healthcare. Such transfers involve a handoff process, whereby patient information and permanent or temporary medical devices or equipment are exchanged, and accountability and responsibility for patient care are transferred.22 This may 20 UMLS Dictionary, available at: http://www.nlm.nih.gov/research/umls/. Last accessed August 2014. 21 National Cancer Institute (NCI), Bethesda, MD; NCI 2010, available at: www.cancer.gov/. Last accessed August

2014. 22 (i) Coleman E, Falling through the cracks: challenges and opportunities for improving transitional care for

persons with continuous complex care needs, J Am Geriatr Soc,2003;51(4):549-555. (ii); Alem L Joseph M, Kethers S et al., Information environments for supporting consistent registrar medical Handover, Health Inform Manage J , 2008;37(1): 9-23; Anderson CD, Mangino RR, Nurse shift report: who says you can't talk in front of the patient?, Nurs Ad Q, 2006;30(2):112-122.

CMS / ONC Component Definitions

Quality Data Model, Version 4.2 50 August 31, 2015

include the setting from which a patient is received or released (e.g., home, acute-care hospital, skilled nursing facility) to the current location.

Table 22. Transfer of Care Datatypes and Attributes Datatype Definition Attributes

Transfer From Data elements that meet criteria using this datatype should document the setting, indicated by the QDM category and its corresponding value set, from which a patient is received (e.g., home, acute care hospital, skilled nursing) to the current location.

• Negation Rationale • Start Datetime • Stop Datetime

Transfer To Data elements that meet criteria using this datatype should document the setting, indicated by the QDM category and its corresponding value set, to which a patient is released (e.g., home, acute care hospital, skilled nursing) from the current location.

• Negation Rationale • Start Datetime • Stop Datetime

4.2 Attributes Table 21. Attribute Definitions

Attribute Definition Datatype(s) Abatement Datetime The estimated or actual date/time that

the diagnosis/problem (a) or symptom (b) resolved or went into remission.

• Diagnosis (a) • Symptom (b)

Active Datetime The date and time at which an order becomes active. In most cases, this is the same as the signed datetime, but in advance orders it may be after the signed datetime.

• Immunization, Order • Medication, Order

Admission Datetime The start date and time for admission to an encounter in an inpatient setting. This attribute should not be used for outpatient encounters.

• Encounter, Active • Encounter, Performed

Anatomical Approach Site The anatomical site or structure through which the action represented by the datatype reaches, or should reach, its target.

• Device, Applied • Procedure, Order • Procedure, Performed • Procedure, Recommended

Anatomical Location Site The anatomical site or structure • Where the diagnosis/problem

manifests itself (a). • That is the focus of the action

represented by the datatype (b).

• Diagnosis (a) • Device, Applied (b) • Physical Exam, Order (b) • Physical Exam, Performed (b) • Physical Exam, Recommended

(b) • Procedure, Order (b) • Procedure, Performed (b) • Procedure, Recommended (b)

Cause The recorded cause of death.

Note: Previous versions of the QDM referred to this attribute as reason.

• Patient Characteristic Expired

Cumulative Medication Duration

The cumulative number of medication days for an individual over a span of

• Medication, Active • Medication, Administered

CMS / ONC Component Definitions

Quality Data Model, Version 4.2 51 August 31, 2015

Attribute Definition Datatype(s) time. For more information, see Appendix C.

• Medication, Dispensed • Medication, Order

Date The date that the patient passed away. • Patient Characteristic Expired Diagnosis A coded diagnosis/problem addressed

during the encounter. • Encounter, Performed

Discharge Datetime The date and time that the patient was discharged from an inpatient encounter. This attribute should not be used for outpatient encounters.

• Encounter, Active • Encounter, Performed

Discharge Status The disposition of the patient at the time of discharge.

• Encounter, Performed

Dose The amount of therapeutic agent that was • Used while the patient was on the

given medication (a). • Actually administered to a patient (b). • Indicated to be given during a

procedure, diagnostic test, or medication or substance administration (c).

• Dispensed to a patient to be taken at a later time (d).

• Indicated to be given to a patient (e). • Recommended to be taken or

administered to a patient (f).

• Medication, Active (a) • Immunization, Administered (b) • Medication, Administered (b) • Substance, Administered (b) • Medication, Discharge (c) • Medication, Dispensed (d) • Immunization, Order (e) • Medication, Order (e) • Substance, Order (e) • Substance, Recommended (f)

Facility Location The particular location of a facility in which the diagnostic study or encounter occurs or occurred. Examples include, but are not limited to, intensive care units (ICUs), non-ICUs, burn critical- care unit, neonatal ICU, and respiratory- care unit.

• Diagnostic Study, Performed • Encounter, Active • Encounter, Order • Encounter, Performed • Encounter, Recommended

Facility Location Arrival Datetime

The time that the patient arrived at the specific facility for the encounter.

• Encounter, Active • Encounter, Performed

Facility Location Departure Datetime

The time that the patient departed the specific facility related to the encounter.

• Encounter, Active • Encounter, Performed

Frequency Indicates how frequently the medication or substance • Is administered to a patient for an

active medication (a). • Was administered to the patient (b). • Should be taken by the patient or

administered to the patient (c). • Is recommended to be given to the

patient (d).

• Medication, Active (a) • Medication, Administered (b) • Substance, Administered (b) • Medication, Discharge (c) • Medication, Dispensed (c) • Medication, Order (c) • Substance, Order (c) • Substance, Recommended (d)

Incision Datetime The date and time of the first incision of the procedure.

• Procedure, Performed

Length of Stay The difference of the admission date/time and the discharge date/time for the encounter. This attribute should not be used for outpatient encounters.

• Encounter, Active • Encounter, Performed

CMS / ONC Component Definitions

Quality Data Model, Version 4.2 52 August 31, 2015

Attribute Definition Datatype(s) Method Indicates the procedure or technique to

be • Used in the datatype (a). • Used in or for the datatype (b). • Used in the administration of the

ordered medication or substance (c).

• Diagnostic Study, Order (a) • Functional Status, Order (a) • Laboratory Test, Order (a) • Physical Exam, Order (a) • Procedure, Order (a) • Diagnostic Study,

Recommended (a) • Functional Status,

Recommended (a) • Laboratory Test, Recommended

(a) • Physical Exam, Recommended

(a) • Procedure, Recommended (a) • Substance, Recommended (a) • Diagnostic Study, Performed (b) • Functional Status, Performed (b) • Laboratory Test, Performed (b) • Physical Exam, Performed (b) • Procedure, Performed (b) • Medication, Order (c) • Substance, Order (c)

Negation Rationale Indicates the reason that something did not occur or was not done.

• Communication: From Patient to Provider

• Communication: From Provider to Patient

• Communication: From Provider to Provider

• Device, Applied • Device, Order • Device, Recommended • Diagnostic Study, Order • Diagnostic Study, Performed • Diagnostic Study,

Recommended • Encounter, Order • Encounter, Performed • Encounter Recommended • Functional Status, Order • Functional Status, Performed • Functional Status,

Recommended • Immunization, Administered • Immunization, Order • Intervention, Order • Intervention, Performed • Intervention, Recommended

CMS / ONC Component Definitions

Quality Data Model, Version 4.2 53 August 31, 2015

Attribute Definition Datatype(s) • Laboratory Test, Order • Laboratory Test, Performed • Laboratory Test, Recommended • Medication, Administered • Medication, Discharge • Medication, Dispensed • Medication, Order • Physical Exam, Order • Physical Exam, Performed • Physical Exam, Recommended • Procedure, Order • Procedure, Performed • Procedure, Recommended • Risk Category/Assessment • Substance, Administered • Substance, Order • Substance, Recommended • Transfer From • Transfer To

Onset Age The estimated or actual age in years of the family member when the diagnosis/problem began.

• Family History

Onset Datetime The estimated or actual date/time that the diagnosis/problem (a) or symptom (b) began.

• Diagnosis (a) • Symptom (b)

Ordinality The scale in which different procedures are ordered in terms of the qualitative value, as opposed to a ranking performed strictly numerically or quantitatively.

• Procedure, Intolerance • Procedure, Order • Procedure, Performed • Procedure, Recommended

Principal Diagnosis The coded diagnosis/problem established after study to be chiefly responsible for occasioning the admission of the patient to the hospital for care.

• Encounter, Performed

Radiation Dosage Indicates the total dosage of radiation associated with the action referenced by the datatype.

• Diagnostic Study, Adverse Event • Diagnostic Study, Intolerance • Diagnostic Study, Order • Diagnostic Study, Performed • Diagnostic Study,

Recommended • Procedure, Performed

Radiation Duration Indicates the time (duration) of radiation exposure associated with the action referenced by the datatype.

• Diagnostic Study, Adverse Event • Diagnostic Study, Intolerance • Diagnostic Study, Order • Diagnostic Study, Performed • Diagnostic Study,

Recommended • Procedure, Order • Procedure, Performed

CMS / ONC Component Definitions

Quality Data Model, Version 4.2 54 August 31, 2015

Attribute Definition Datatype(s) Reaction Indicates the effect or consequence

experienced by a patient as a response to the adverse event, or the allergy, or the intolerance to the specified action referenced by the datatype.

• Device, Adverse Event • Device, Allergy • Device, Intolerance • Diagnostic Study, Adverse Event • Diagnostic Study, Intolerance • Immunization, Allergy • Immunization, Intolerance • Intervention, Adverse Event • Intervention, Intolerance • Laboratory Test, Adverse Event • Laboratory Test, Intolerance • Medication, Adverse Effects • Medication, Allergy • Medication, Intolerance • Procedure, Adverse Event • Procedure, Intolerance • Substance, Adverse Event • Substance, Allergy • Substance, Intolerance

CMS / ONC Component Definitions

Quality Data Model, Version 4.2 55 August 31, 2015

Attribute Definition Datatype(s) Reason The thought process or justification for

the datatype. In some measures, specific treatments are acceptable inclusion criteria only if a justified reason is present. Each of these measures uses a value set (often, but not exclusively, using SNOMED-CT®) to express acceptable justification reasons. Other measures specify reasons as justification for exclusions. Examples include patient, system, or medical-related reasons for declining to perform specific actions. Each of these measures also uses a value set to express acceptable justification reasons for declining to perform expected actions.

• Device, Applied • Device, Order • Device, Recommended • Diagnostic Study, Order • Diagnostic Study, Performed • Encounter, Active • Encounter, Order • Encounter, Performed • Encounter, Recommended • Functional Status, Order • Functional Status, Performed • Functional Status,

Recommended • Immunization, Administered • Immunization, Order • Intervention, Order • Intervention, Performed • Intervention, Recommended • Laboratory Test, Order • Laboratory Test, Performed • Laboratory Test, Recommended • Medication, Administered • Medication, Order • Patient Characteristic Clinical

Trial Participant • Physical Exam, Order • Physical Exam, Performed • Physical Exam, Recommended • Procedure, Order • Procedure, Performed • Procedure, Recommended • Substance, Order • Substance, Recommended

Recorded Datetime The date/time the family history entry was recorded.

• Family History

Reference Range High The high bound (inclusive) of values that are considered normal.

• Laboratory Test, Performed

Reference Range Low The low bound (inclusive) of values that are considered normal.

• Laboratory Test, Performed

Refills The number of refills allowed by the prescription.

• Medication, Discharge • Medication, Dispensed • Medication, Order • Substance, Order • Substance, Recommended

Related To Something to which the Care Goal is related.

• Care Goal

Relationship The relationship of the family member to the patient. To ensure compatibility with QRDA reporting constraints, relationship codes should come from the HL7 Personal Relationship Role

• Family History

CMS / ONC Component Definitions

Quality Data Model, Version 4.2 56 August 31, 2015

Attribute Definition Datatype(s) Type value set (2.16.840.1.113883.1.11.19563).

Removal Datetime The date and time at which the device was removed.

• Device, Applied

Result The final consequences or data collected from the datatype. Results can be used in three ways: • To express that a result is present in

the electronic record but any entry is acceptable

• To express a numerical result, combined with a mathematical operator and units (e.g., LDL >= 100 mg/dL, or systolic blood pressure is < 140 mmHg)

• To express a result that matches one of a specific set of coded concepts in a value set

• Diagnostic Study, Performed • Functional Status, Performed • Intervention, Performed • Laboratory Test, Performed • Physical Exam, Performed • Procedure, Performed • Risk Category/Assessment

Route Refers to the path by which the medication or substance should be taken into the body systems, such as intradermally, intrathecally, intramuscularly, intranasally, intravenously, orally, rectally, subcutaneously, sublingually, topically, or vaginally.

• Immunization, Administered • Immunization, Order • Medication, Active • Medication, Administered • Medication, Discharge • Medication, Dispensed • Medication, Order • Substance, Administered • Substance, Order • Substance, Recommended

Severity Indicates the intensity of the specified datatype (e.g., persistent, moderate, or severe).

• Diagnosis • Symptom

Signed Datetime The date and time at which the order was signed. This is often the same as the active datetime, but in the case of advance orders may be before the active datetime.

• Immunization, Order • Medication, Order

Start Datetime The time the indicated event starts. In the case of Order datatypes, this is the “author time” (when the order was signed).

• Care Goal • Communication: From Patient to

Provider • Communication: From Provider

to Patient • Communication: From Provider

to Provider • Device, Adverse Event • Device, Allergy • Device, Applied • Device, Intolerance • Device, Order • Device, Recommended • Diagnostic Study, Adverse Event • Diagnostic Study, Intolerance • Diagnostic Study, Order • Diagnostic Study, Performed

CMS / ONC Component Definitions

Quality Data Model, Version 4.2 57 August 31, 2015

Attribute Definition Datatype(s) • Diagnostic Study,

Recommended • Encounter, Order • Encounter Recommended • Functional Status, Order • Functional Status, Performed • Functional Status,

Recommended • Immunization, Administered • Immunization, Allergy • Immunization, Intolerance • Immunization, Order • Intervention, Adverse Event • Intervention, Intolerance • Intervention, Order • Intervention, Performed • Intervention, Recommended • Laboratory Test, Adverse Event • Laboratory Test, Intolerance • Laboratory Test, Order • Laboratory Test, Performed • Laboratory Test, Recommended • Medication, Active • Medication, Adverse Effects • Medication, Administered • Medication, Allergy • Medication, Discharge • Medication, Dispensed • Medication, Intolerance • Medication, Order • Patient Care Experience • Patient Characteristic • Patient Characteristic Birthdate • Patient Characteristic Clinical

Trial Participant • Patient Characteristic Payer • Patient Characteristic Sex • Physical Exam, Order • Physical Exam, Performed • Physical Exam, Recommended • Procedure, Adverse Event • Procedure, Intolerance • Procedure, Order • Procedure, Performed • Procedure, Recommended • Provider Care Experience • Provider Characteristic • Risk Category/Assessment • Substance, Administered • Substance, Adverse Event • Substance, Allergy

CMS / ONC Component Definitions

Quality Data Model, Version 4.2 58 August 31, 2015

Attribute Definition Datatype(s) • Substance, Intolerance • Substance, Order • Substance, Recommended • Transfer From • Transfer To

Status Indicates the particular stage of the action represented by the datatype.

• Diagnostic Study, Performed • Intervention, Performed • Laboratory Test, Performed • Procedure, Performed

Stop Datetime The time the indicated event ends. In the case of Order datatypes, this corresponds to the QRDA “author time” (when the order was signed).

• Care Goal • Communication: From Patient to

Provider • Communication: From Provider

to Patient • Communication: From Provider

to Provider • Device, Adverse Event • Device, Allergy • Device, Applied • Device, Intolerance • Device, Order • Device, Recommended • Diagnostic Study, Adverse Event • Diagnostic Study, Intolerance • Diagnostic Study, Order • Diagnostic Study, Performed • Diagnostic Study,

Recommended • Encounter, Order • Encounter Recommended • Functional Status, Order • Functional Status, Performed • Functional Status,

Recommended • Immunization, Administered • Immunization, Allergy • Immunization, Intolerance • Immunization, Order • Intervention, Adverse Event • Intervention, Intolerance • Intervention, Order • Intervention, Performed • Intervention, Recommended • Laboratory Test, Adverse Event • Laboratory Test, Intolerance • Laboratory Test, Order • Laboratory Test, Performed • Laboratory Test, Recommended • Medication, Active • Medication, Adverse Effects • Medication, Administered

CMS / ONC Component Definitions

Quality Data Model, Version 4.2 59 August 31, 2015

Attribute Definition Datatype(s) • Medication, Allergy • Medication, Discharge • Medication, Dispensed • Medication, Intolerance • Medication, Order • Patient Care Experience • Patient Characteristic • Patient Characteristic Birthdate • Patient Characteristic Clinical

Trial Participant • Patient Characteristic Payer • Patient Characteristic Sex • Physical Exam, Order • Physical Exam, Performed • Physical Exam, Recommended • Procedure, Adverse Event • Procedure, Intolerance • Procedure, Order • Procedure, Performed • Procedure, Recommended • Provider Care Experience • Provider Characteristic • Risk Category/Assessment • Substance, Administered • Substance, Adverse Event • Substance, Allergy • Substance, Intolerance • Substance, Order • Substance, Recommended • Transfer From • Transfer To

Target Outcome The expected outcome representing when the care goal is met.

• Care Goal

Time The time that the patient passed away. • Patient Characteristic Expired

CMS / ONC

Quality Data Model, Version 4.2 60 August 31, 2015

Appendix A. Time Unit and Time Interval Definitions

ISO 8601:200423 defines data elements and interchange formats for the representation of dates and times, including time intervals. The following table summarizes important terms defined in the standard that are of particular importance and can be drawn upon for use in time interval calculations for eCQMs.

Table A1. Time Unit and Interval Definitions Term ISO Definition ISO Notes

Time interval Part of the time axis limited by two instants. • A time interval comprises all instants between the two limiting instants and, unless otherwise stated, the limiting instants themselves.

Duration Non-negative quantity attributed to a time interval, the value of which is equal to the difference between the time points of the final instant and the initial instant of the time interval, when the time points are quantitative marks.

• In case of discontinuities in the time scale, such as a leap second or the change from winter time to summer time and back, the computation of the duration requires the subtraction or addition of the change of duration of the discontinuity.

• The International System of Units (SI) unit of duration is the second.

Nominal duration Duration expressed among others in years, months, weeks, or days.

• The duration of a calendar year, a calendar month, a calendar week, or a calendar day depends on its position in the calendar. Therefore, the exact duration of a nominal duration can only be evaluated if the duration of the calendar years, calendar months, calendar weeks, or calendar days used is known.

Second Base unit of measurement of time in the SI as defined by the International Committee of Weights and Measures.

Minute Unit of time equal to 60 seconds.

Hour Unit of time equal to 60 minutes.

Day <unit of time> Unit of time equal to 24 hours.

23 Available at: http://www.iso.org/iso/catalogue_detail?csnumber=40874. Last accessed August 2014.

CMS / ONC Time Unit and Time Interval Definitions

Quality Data Model, Version 4.2 61 August 31, 2015

Term ISO Definition ISO Notes Calendar day Time interval starting at midnight and ending at

the next midnight, the latter being also the starting instant of the next calendar day.

• A calendar day is often also referred to as a day.

• The duration of a calendar day is 24 hours, except if modified by:

– The insertion or deletion of leap seconds, by decision of the International Earth Rotation Service (IERS), or

– The insertion or deletion of other time intervals, as may be prescribed by local authorities to alter the time scale of local time.

Day <duration>

Duration of a calendar day. • The term “day” applies also to the duration of any time interval which starts at a certain time of day at a certain calendar day and ends at the same time of day at the next calendar day.

Calendar week Time interval of seven calendar days starting with a Monday.

• A calendar week is also referred to as a week.

Week Duration of a calendar week. • The term “week” also applies to the duration of any time interval which starts at a certain time of day at a certain calendar day and ends at the same time of day at the same calendar day if the next calendar week.

Calendar month Time interval resulting from the division of a calendar year into 12 time intervals, each with a specific name and containing a specific number of calendar days.

• A calendar month is often referred to as a month.

Month Duration of 28, 29, 30, or 31 calendar days depending on the start and/or the end of the corresponding time interval within the specific calendar month.

• The term “month” applies also to the duration of any time interval which starts at a certain time of day at a certain calendar day of the calendar month and ends at the same time of day at the same calendar day of the next calendar month, if it exists. In other cases, the ending calendar day has to be agreed on.

• In certain applications a month is considered as a duration of 30 calendar days.

Calendar year Cyclic time interval in a calendar which is required for one revolution of the Earth around the Sun and approximated to an integral number of calendar days.

• A calendar year is also referred to as a year.

• Unless otherwise specified, the term designates a calendar year in the Gregorian calendar.

CMS / ONC Time Unit and Time Interval Definitions

Quality Data Model, Version 4.2 62 August 31, 2015

Term ISO Definition ISO Notes Year Duration of 365 or 366 calendar days depending

on the start and/or the end of the corresponding time interval within the specific calendar year.

• The term “year” applies also to the duration of any time interval which starts at a certain time of day at a certain calendar date of the calendar year and ends at the same time of day at the same calendar date of the next calendar year, if it exists. In other cases, the ending calendar day has to be agreed on.

Common year Calendar year in the Gregorian calendar that has 365 calendar days.

Leap year Calendar year in the Gregorian calendar that has 366 days.

The standard also defines multiple formats for the representation of date and time as well as time intervals and durations. ISO 8601 postulates that duration can be expressed by a combination of components with accurate duration (hour, minute, and second) and components with nominal duration (year, month, week, and day). The standard allows for the omission of lower-level components for “reduced accuracy” applications.

CMS / ONC

Quality Data Model, Version 4.2 63 August 31, 2015

Appendix B. Time Interval Calculation Conventions

B.1 Time Interval Calculations The unit in which a time interval (or its duration) is expressed may depend on the necessary level of accuracy for the purposes of measurement. As such, the selection of the time unit to be used should be made according to the level of granularity needed to meet the intent of the measure.

These conventions are intended to standardize the interpretation of time calculation units for durations (i.e., difference between two date/time elements), typically with time relationships defined in the QDM, such as starts after start of and ends before start of.

Timing comparisons using quantities (e.g., < 3 day(s), >= 30 minutes, etc.) are only allowed when expressing relationships requiring one element to be before or after another. Temporal relationships based only on concurrency or containment do not allow quantity-based comparisons. For example, the statement "Medication, Order: A" < 3 days(s) starts during "Encounter, Performed: B" is not supported, because its meaning is not clear. Therefore, the following temporal relationships cannot be used with quantity-based comparisons:

• starts concurrent with • starts concurrent with end of • starts during • ends concurrent with • ends concurrent with start of • ends during • concurrent with • during • overlaps

CMS / ONC Time Interval Calculation Conventions

Quality Data Model, Version 4.2 64 August 31, 2015

Table B1. Time Interval Calculations Calculation

Unit Definition Calculation 24, 25,26

Year Duration of any time interval which starts at a certain time of day at a certain calendar date of the calendar year and ends at: • The same time of day at the

same calendar date of the next calendar year, if it exists

• The same time of day at the immediately following calendar date of the ending calendar year, if the same calendar date of the ending calendar year does not exist

For the purposes of quality measures, duration expressed in years ignores the time of day associated with the date/time stamps used in the calculation – i.e., the number of years will not change until the month and day of date 2 reach (or surpass) the month and day of date 1; time of day should be ignored or set to 00:00:00 for this calculation. Notes: 1. When in the next calendar year

the same calendar date does not exist, the ISO states that the ending calendar day has to be agreed upon. The above convention is proposed as a resolution to this issue.

2. The ISO permits the representation of dates and times with “reduced accuracy” when necessary. As noted above, time of day should be ignored.

1. When Month (date 2) < month (date 1): Duration (years) = year (date 2) – year (date 1) – 1 Example 1:

Date 1: 2012-03-10 22:05:09

Date 2: 2013-02-18 19:10:03

Duration = 2013 – 2012 – 1 = 0 years

2. When Month (date 2) = month (date 1) and day (date

2) >= day (date 1) Duration (years) = year (date 2) – year (date 1) Example 2.a: When day (date 1) = day (date 2)

Date 1: 2012-03-10 22:05:09

Date 2: 2013-03-10 08:01:59

Duration = 2013 – 2012 = 1 year

Note: Time of day is ignored in this calculation. If time of day were to be considered for the calculation, the duration of the time interval would be 0 years according to the definition.

Example 2.b: When day (date 2) > day (date 1)

Date 1: 2012-03-10 22:05:09

Date 2: 2013-03-20 04:01:30

Duration = 2013 – 2012 = 1 year

(continued on next page)

24 For the purposes of this document, date 2 is assumed to be more recent than date 1. 25 All dates are represented according to the extended format designated in ISO 8601: YYYY-MM-DD HH:MM:SS

and a 24-hour timekeeping system. 26 The result of the calculation is always an integer; if the result includes decimals, it should be truncated (rounded

down) to the unit.

CMS / ONC Time Interval Calculation Conventions

Quality Data Model, Version 4.2 65 August 31, 2015

Calculation Unit Definition Calculation

24, 25,26

Year (continued)

3. When Month (date 2) = month (date 1) and day (date 2) < day (date 1) Duration (years) = year (date 2) – year (date 1) – 1 Example 3:

Date 1: 2012-02-29

Date 2: 2014-02-28

Duration = 2014 – 2012 – 1 = 1 year

4. When Month (date 2) > month (date 1)

Duration (years) = year (date 2) – year (date 1) Example 4.a:

Date 1: 2012-03-10 11:16:02

Date 2: 2013-08-15 21:34:16

Duration = 2013 – 2012 = 1 year

Example 4.b:

Date 1: 2012-02-29 10:18:56

Date 2: 2014-03-01 19:02:34

Duration = 2014 – 2012 = 2 years

Note: Because there is no February 29 in 2014, the number of years can only change when the date reaches March 1, the first date in 2014 that surpasses the month and day of date 1 (February 29).

CMS / ONC Time Interval Calculation Conventions

Quality Data Model, Version 4.2 66 August 31, 2015

Calculation Unit Definition Calculation

24, 25,26

Month Duration of any time interval which starts at a certain time of day at a certain calendar day of the calendar month and ends at: • The same time of day at the

same calendar day of the ending calendar month, if it exists

• The same time of day at the immediately following calendar date of the ending calendar month, if the same calendar date of the ending month year does not exist

For the purposes of quality measures, duration expressed in months ignores the time of day associated with the date/time stamps used in the calculation – i.e., the number of months will not change until the month and day of date 2 reach (or surpass) the month and day of date 1; time of day should be ignored or set to 00:00:00 for this calculation. Notes: 1. When in the next calendar year

the same calendar date does not exist, the ISO states that the ending calendar day has to be agreed upon. The above convention is proposed as a resolution to this issue.

2. The ISO permits the representation of dates and times with “reduced accuracy” when necessary. As noted above, time of day should be ignored.

1. When Day (date 2) >= day (date 1) Duration (months) = (year (date 2) – year (date 1))*12 + (month (date 2) – (month (date 1)) Example 1.a:

Date 1: 2012-03-01 14:05:45

Date 2: 2012-03-31 23:01:49

Duration = (2012 – 2012)*12 + (3 – 3) = 0 + 0 = 0 months

Example 1.b:

Date 1: 2012-03-10 22:05:09

Date 2: 2013-06-30 13:00:23

Duration = (2013 – 2012)*12 + (6 – 3) = 12 + 3 = 15 months

2. When Day (date 2) < day (date 1) Duration (months) = (year(date 2) – year(date 1))*12 + (month(date 2) – month (date 1)) – 1

Example 2:

Date 1: 2012-03-10 22:05:09

Date 2: 2013-01-09 07:19:33

Duration = (2013 – 2012)*12 + (1 – 3) - 1 = 12 – 2 - 1 = 9 months

CMS / ONC Time Interval Calculation Conventions

Quality Data Model, Version 4.2 67 August 31, 2015

Calculation Unit Definition Calculation

24, 25,26

Week Duration of any time interval which starts at a certain time of day at a certain calendar day at a certain calendar week and ends at the same time of day at the same calendar day of the ending calendar week. For the purposes of quality measures, duration expressed in weeks ignores the time of day associated with the date/time stamps used in the calculation – i.e., a complete week is always seven days long: a week has passed when the same weekday in the following week is reached; time of day should be ignored or set to 00:00:00 for this calculation. Notes: 1. The ISO permits the

representation of dates and times with “reduced accuracy” when necessary. As noted above, time of day should be ignored.

2. If the result is not an integer, it should be truncated to an integer.

1. Duration = Duration(days) 27 / 7

Example 1:

Date 1: 2012-03-10 22:05:09

Date 2: 2012-03-20 07:19:33

Duration = 10 / 7 = 1 week (result truncated to integer)

27 For information on how to calculate the duration, in days, of a time interval, please see “day”.

CMS / ONC Time Interval Calculation Conventions

Quality Data Model, Version 4.2 68 August 31, 2015

Calculation Unit Definition Calculation

24, 25,26

Day Duration of any time interval that starts at a certain calendar day and ends at the next calendar day (the possible range is 1 second to 47 hours, 59 minutes and 59 seconds); the number of times midnight is crossed. For the purposes of quality measures, duration expressed in days ignores the time of day associated with the date/time stamps used in the calculation – i.e., the number of days will not change until the month and day of date 2 surpasses the month and day of date 1. Notes: 1. The ISO permits the

representation of dates and times with “reduced accuracy,” when necessary. As noted above, time of day should be ignored.

The duration in days between two dates will be generally given by subtracting the start calendar date to the end calendar date, regardless of the time of day between the two dates. Example 1:

Date 1: 2012-01-31 12:30:00

Date 2: 2012-02-01 09:00:00

Duration = [2012-02-01] – [2012-01- 31] = 1 day

Example 2:

Date 1: 2012-01-31 12:30:00

Date 2: 2012-02-01 14:00:00

Duration = [2012-02-01] – [2012-01- 31] = 1 day

Hours The number of 60-minute cycles between two given dates. For the purposes of quality measures, duration expressed in hours ignores the seconds associated with the date/time stamps used in the calculation. Notes: 1. Use the date, hour, and minute

of the date/time stamps to compute the interval.

2. The ISO permits the representation of dates and times with “reduced accuracy,” when necessary. As noted above, seconds should be ignored.

3. If the result is not an integer, it should be truncated to an integer.

The duration in hours between two dates is the number of minutes between the two dates, divided by 60. The result is truncated to the unit. Example 1:

Date/Time 1: 2012-03-01 03:10

Date/Time 2: 2012-03-01 05:09

Duration = 119 / 60 = 1 hour

Example 2:

Date/Time 1: 2012-02-29 23:10

Date/Time 2: 2012-03-01 00:10

Duration = 60 / 60 = 1 hour

Example 3:

Date/Time 1: 2012-03-01 03:10

Date/Time 2: 2012-03-01 04:00

Duration = 50 / 60 = 0 hours

CMS / ONC Time Interval Calculation Conventions

Quality Data Model, Version 4.2 69 August 31, 2015

Calculation Unit Definition Calculation

24, 25,26

Minutes The number of minutes between two given dates. For the purposes of quality measures, duration expressed in minutes ignores the seconds associated with the date/time stamps used in the calculation. Notes: 1. Use the date, hour, and minute

of the date/time stamps to compute the interval.

2. The ISO permits the representation of dates and times with “reduced accuracy,” when necessary. As noted above, seconds should be ignored.

Example 1:

Date/Time 1: 2012-03-01 03:10

Date/Time 2: 2012-03-01 05:20

Duration = 130 minutes

Example 2:

Date/Time 1: 2012-02-29 23:10

Date/Time 2: 2012-03-01 00:20

Duration = 70 minutes

B.2 Timing Relationships with No Calculation Unit Defined When no threshold is defined in a measure phrase that compares timing between two elements, a common level of granularity needs to be established for comparisons within and across EHRs. For example, the following criterion does not indicate a unit of comparison:

A starts before start of B

Depending on the level of granularity of the data (e.g., HH:MM:SS vs. HH:MM), the result of the timing comparison may vary if no comparison unit is defined. The following two examples show how the level of granularity can potentially affect the result of a comparison:

Example 1: Granularity to Seconds28 A: 2012-01-01 11:00:01

B: 2012-01-01 11:00:02

A starts before B = TRUE

Example 2: Granularity to Minutes A: 2012-01-01 11:00

B: 2012-01-01 11:00

A starts before B = FALSE

28 Note: This example does not show how QDM calculates comparisons. As described in the following section, this

comparison actually evaluates to false in the QDM (since QDM ignores seconds).

CMS / ONC Time Interval Calculation Conventions

Quality Data Model, Version 4.2 70 August 31, 2015

In order to resolve this type of issue, calculations should be performed with dates represented with reduced accuracy to the minute (date/time truncated to minute prior to calculation – i.e., seconds not used in calculation):

Example 3 A: 2012-01-01 11:00:01

B: 2012-01-01 11:00:02

A starts before B = FALSE

Note: Seconds are not used in the calculation.

Example 4

A: 2012-01-01 11:00

B: 2012-01-01 11:00

A starts before B = FALSE

If no unit of comparison has been defined in the logic (e.g., A starts before start of B), minutes will be used as the default unit for the calculation. This convention effectively renders the following criteria equivalent:

• A starts before start of B • A > 0 minute(s) starts before start of B • A >= 1 minute(s) starts before start of B

If another unit is intended, it should be specified in the criterion, for instance: • If the intended unit of comparison is the second:

– A starts before start of B would “default” to comparison in minutes. – A > 1 second(s) starts before start of B would explicitly refer to the

granularity intended for the calculation of duration between the two date/time stamps. (Criterion would be true if A started at least one second before B.)

• If the intended unit of comparison is the day: o A > 1 day(s) starts before start of B

(Criterion would be true if A started at least one day before B.)

The best practice is to always explicitly define the unit of calculation, as this shows intent on the part of the measure developer and provides a completely unambiguous interpretation of the level of granularity with which the computation should be performed. However, if no unit is defined, the above convention determines that the computation unit should be minutes.

CMS / ONC

Quality Data Model, Version 4.2 71 August 31, 2015

Appendix C. Cumulative Medication Duration

Cumulative medication duration (CMD) is the number of medication days for an individual over a span of time. CMD does not count gaps between medications and never counts a single calendar day as more than one (even for overlapping medications).

Cumulative medication duration should generally be calculated as the number of doses in the interval of interest, divided by the doses per day. For example, if a patient received 60 doses in the interval of interest, and took three doses per day, the CMD would be 20 days (60 / 3 = 20).

C.1 Cumulative Medication Duration in the QDM Datatypes In the QDM, cumulative medication duration can be calculated for four of the Medication datatypes:

• Medication, Order: CMD represents the intended number of medication days, based on the metadata of the order. Refills are taken into account.

• Medication, Active: CMD represents the same information as for Medication, Order. • Medication, Dispensed: CMD represents the number of medication days available in the

supply that was dispensed (i.e., picked up). Only actual dispenses should be taken into account.

• Medication, Administered: CMD represents the number of days for which an individual was actually administered the medicine, regardless of the supply in the order or dispense.

Note that calculating CMD for Medication, Administered would generally only be meaningful in a setting where administrations are actually recorded (e.g., inpatient).

Measuring CMD for Medication, Dispensed should also be used with caution, as many EHRs do not yet have access to dispense data. Until pharmacies communicate dispense data as a common practice, CMD for Medication, Dispensed will be inconsistently available in many systems. See section C.3.3 for additional details.

C.2 Representing Cumulative Medication Duration in the QDM Each of the medication datatypes noted above has a cumulative medication duration attribute. In a given instance of a datatype, the cumulative medication duration attribute represents only the CMD for that instance (as opposed to the aggregate CMD over the set). For this reason, cumulative medication duration should be used in conjunction with the sum operator:

AND: Sum > 180 day(s) of: "Medication, Order: Warfarin (cumulative medication duration)" during "Measurement Period"

The example above is asserting that the combined CMD over all Warfarin orders in the measurement period must be more than 180 days. The example uses the during temporal operator, but measure developers are free to use whichever temporal operator best fits their use case.

CMS / ONC Cumulative Medication Duration

Quality Data Model, Version 4.2 72 August 31, 2015

When sum is used in conjunction with cumulative medication duration, implementers should note that no calendar day should be counted more than once. A typical solution might map medication days to a calendar and then count the number of unique days.

Note that some existing measures may use cumulative medication duration incorrectly without the sum operator. The following example is an incorrect representation of the same statement as above:

AND: "Medication, Order: Warfarin (cumulative medication duration > 180 day(s)" during "MeasurementPeriod"

This is incorrect because it is asserting that there must exist a single instance of an order for which the CMD is more than 180 days. This is usually not what the measure developer intends.

C.3 Limitations of the Current Representation in QDM The representation of cumulative medication duration outlined in this appendix is considered an interim solution, as it has several significant limitations. These limitations must be considered by measure developers to determine if this representation is sufficient for their needs.

C.3.1 Imprecision of Calculation Time Span Using the current representation, the cumulative medication duration will be calculated based on the entirety of each medication event captured in the logic. There is no capability for getting a true calculation over a fixed interval of time, as this would require the calculation to prorate events overlapping that interval on its boundaries.

For example, the current representation is not capable of expressing the cumulative medication duration shaded in in the measurement period below:

Figure 2. Ideal Cumulative Medication Duration Calculation

Measure developers can only use logic to capture the medication events that will contribute to the CMD calculation. The following illustrations use the same set of orders as above, but demonstrate how CMD will be calculated based on different timing relationships. The illustrations below only show a few of the timing relationships; they are not meant to be exhaustive.

C.3.1.1 During The during relationship will only capture medication events fully contained within the interval. As a result, calculations of CMD will be smaller than expected if there are events that overlap the borders of the interval.

CMS / ONC Cumulative Medication Duration

Quality Data Model, Version 4.2 73 August 31, 2015

AND: Sum > 180 day(s) of: "Medication, Order: Warfarin (cumulative medication duration)" during "Measurement Period"

Figure 3. Cumulative Medication Duration Using During

C.3.1.2 Overlaps The overlaps relationship will capture all medication events contained within the interval, in addition to the events overlapping the boundaries of the interval. As a result, calculations of CMD will be larger than expected if there are events that overlap the borders of the interval.

AND: Sum > 180 day(s) of: "Medication, Order: Warfarin (cumulative medication duration)" overlaps "Measurement Period"

Figure 4. Cumulative Medication Duration Using Overlaps

C.3.1.3 Starts During The starts during relationship will capture all medication events that start during the interval. This includes all of the events captured by during, in addition to events that overlap the end boundary of the interval. In some cases, capturing events that overlap the end boundary of the interval might compensate for uncaptured events at the start boundary of the interval.

AND: Sum > 180 day(s) of: "Medication, Order: Warfarin (cumulative medication duration)" starts during "Measurement Period"

Figure 5. Cumulative Medication Duration Using Starts During

CMS / ONC Cumulative Medication Duration

Quality Data Model, Version 4.2 74 August 31, 2015

C.3.2 Restriction to Calculation Over One Value Set The current representation is only able to calculate cumulative medication duration based on a single value set. If measure developers need to calculate combined CMD over several value sets, they will need to create a new grouping value set.

C.3.3 Unreliability of Dispense Data As noted previously, it is not yet common practice for pharmacies to provide dispense data to EHRs and practices. As a result, the Medication, Dispensed datatype may not capture all of the dispenses for a given patient. In most cases, calculations over Medication, Dispensed will be missing data and result in lower CMD values.

It should also be noted that the source (i.e., claims versus pharmacy fill data) of dispense data can affect what proportion of medications are transmitted to the physician or EHR. For example, medications that are self-pay are rarely captured by claims data, and over the counter medications are rarely captured by either source of data. Measure developers should consider whether the current approach is adequate for the purpose intended.

C.4 Providing Measure-Level Guidance When the interim solution for representing cumulative medication duration does not fit a measure’s use case, the measure developer will need to provide measure-level guidance and/or supplemental materials and should consider whether the use of this construct is appropriate to specify the intended content. While this is not the ideal situation, it reflects the reality that CMD is a complex topic and the current solution has significant limitations.

CMS / ONC

Quality Data Model, Version 4.2 75 August 31, 2015

Appendix D. Change Log

D.1 Changes in QDM 4.2 The Quality Data Model, Version 4.2 specification contains the following changes from the Quality Data Model, Version 4.1.2 specification:

• Enhanced support for encounter diagnoses and principal diagnoses • Re-specified the Diagnosis datatypes • Re-specified the Diagnosis, Family History datatype (now Family History) • Re-specified the Symptom datatypes • Added the Immunization category and datatypes • Added reference range attributes to Laboratory Test, Performed • Removed patient preference and provider preference attributes from all datatypes • Removed negation rationale from inappropriate datatypes • Fixed transposed descriptions of Transfer From and Transfer To datatypes

D.2 Changes in QDM 4.1.2 The Quality Data Model, Version 4.1.2 specification contains the following changes from the Quality Data Model, Version 4.1.1 specification:

• Removed anatomical approach site attribute from all Physical Exam datatypes • Removed method attribute from Procedure, Intolerance datatype • Clarified the meaning of start datetime and stop datetime in all Order datatypes • Updated Appendix B to indicate where quantity-based temporal comparisons can and

cannot be used

D.3 Changes in QDM 4.1.1 The Quality Data Model, Version 4.1.1 specification contains the following changes from the Quality Data Model, Version 4.1 specification:

• Replaced DateDiff and TimeDiff functions with DateTimeDiff • Specified DateTimeDiff function to be used in measure observations only • Added new section describing the use of attribute filters • Added support for filtering date/time attributes by date • Re-specified Overlaps to interpret missing end dates/times as ongoing

D.4 Changes in QDM 4.1 The Quality Data Model, Version 4.1 specification contains the following changes from the Quality Data Model, Version 4.0 specification:

CMS / ONC Change Log

Quality Data Model, Version 4.2 76 August 31, 2015

• New QDM functions and operators – Union – Intersection – Fulfills

• New QDM temporal operators – Starts Concurrent With End Of – Ends Concurrent With Start Of

• Clarified names of existing QDM temporal operators – Starts Before or Concurrent With  Starts Before or Concurrent With Start Of – Starts After or Concurrent With  Starts After or Concurrent With Start Of – Starts Before or During  Starts Before End Of – Ends Before or Concurrent With  Ends Before or Concurrent With End Of – Ends After or Concurrent With  Ends After or Concurrent With End Of – Ends Before or During  Ends Before End Of

• Modified existing datatypes – Added signed datetime and active datetime to Medication, Order – Added target outcome to Care Goal – Renamed reason to cause in Patient Characteristic Expired – Clarified or removed ambiguous attributes (see QDM-46 for details)

• Removed System Characteristic Datatype • Removed Measurement Start Date and Measurement End Date in favor of

MeasurementPeriod • Restricted QDM elements to use only one attribute at a time • Added an appendix covering the representation of Cumulative Medication Duration

D.5 Changes in QDM 4.0 The Quality Data Model, Version 4.0 specification contains the following changes from the Quality Data Model, December 2013 specification:

• New document template and layout to improve readability • Updated the wording in some sections to improve clarity • Added definitions for all QDM functions, operators, and timing relationships • New high-level QDM language constructs

– Variable assignment – Inline comments

• New QDM functions and operators – Age At – Satisfies Any – Satisfies All

• New QDM temporal operators – Starts Before or Concurrent With – Starts Before of Concurrent With End Of – Starts After or Concurrent With

CMS / ONC Change Log

Quality Data Model, Version 4.2 77 August 31, 2015

– Starts After or Concurrent With End Of – Ends Before or Concurrent With – Ends Before or Concurrent With Start Of – Ends After or Concurrent With – Ends After or Concurrent With Start

• Incorporated guidance from eCQM Measure Logic and Implementation Guidance and Technical Release Notes, Version 1.729 – Specific occurrences – Calculation of time intervals

29 Available at: http://www.cms.gov/Regulations-and-

Guidance/Legislation/EHRIncentivePrograms/Downloads/eCQM_MeasureLogicGuidance_2014.pdf. Last accessed August 2014.

CMS / ONC

Quality Data Model, Version 4.2 78 August 31, 2015

Acronyms

Term Definition

AHRQ Agency for Healthcare Research and Quality

CDS Clinical Decision Support

CMD Cumulative Medication Directive

CMS Centers for Medicare & Medicaid Services

CPT® Current Procedural Terminology eCQI Electronic Clinical Quality Improvement eCQM Electronic Clinical Quality Measure EHR Electronic Health Record

HIT Health Information Technology

HL7 Health Level 7

ICD-9-CM International Classification of Diseases, Ninth Revision

ICD-10 International Classification of Diseases, Tenth Revision

ISO International Organization for Standardization

MAT Measure Authoring Tool

ONC Office of the National Coordinator for Health Information Technology

PHR Personal Health Record QDM Quality Data Model QRDA Quality Reporting Document Architecture SI International System of Units SNOMED-CT® Systematized Nomenclature of Medicine – Clinical Terms

UCUM Unified Code for Units of Measure

  • Record of Changes
  • Table of Contents
  • List of Figures
  • List of Tables
  • 1. Introduction
    • 1.1 Background
    • 1.2 Purpose
    • 1.3 Vision
    • 1.4 Scope
    • 1.5 Audience
    • 1.6 Document Organization
  • 2. Data Model
    • 2.1 QDM Basics
    • 2.2 Category
    • 2.3 Datatype
    • 2.4 Attribute
      • 2.4.1 Datatype-Specific Attributes
      • 2.4.2 Data Flow Attributes
    • 2.5 QDM Element
    • 2.6 Code System
    • 2.7 Value Sets
      • 2.7.1 Value Sets that Define QDM Categories
      • 2.7.2 Value Sets that Define QDM Attributes
      • 2.7.3 Value Set Groupings
    • 2.8 Specific Occurrences
      • 2.8.1 Simple Usage of Specific Occurrences
      • 2.8.2 Multiple Specific Occurrences of the Same Event Type
      • 2.8.3 Multiple Specific Occurrences of Different Event Types
      • 2.8.4 Specific Occurrences in OR Clauses and Negations
      • 2.8.5 Specific Occurrences between Populations
    • 2.9 Variables
    • 2.10 Inline Comments
  • 3. Logic
    • 3.1 Attribute Filters
      • 3.1.1 Filter by Existence of a Recorded Value
      • 3.1.2 Filter by Value Set
      • 3.1.3 Filter by Scalar Value or Physical Quantity
      • 3.1.4 Filter by Date
    • 3.2 Functions
      • 3.2.1 Min
      • 3.2.2 Max
      • 3.2.3 Median
      • 3.2.4 Average
      • 3.2.5 Count
      • 3.2.6 Sum
      • 3.2.7 Age At
      • 3.2.8 DateTimeDiff
    • 3.3 Subset Operators
      • 3.3.1 Sort Order for QDM Events
      • 3.3.2 First
      • 3.3.3 Second
      • 3.3.4 Third
      • 3.3.5 Fourth
      • 3.3.6 Fifth
      • 3.3.7 Most Recent
      • 3.3.8 Intersection Of
      • 3.3.9 Union Of
      • 3.3.10 Satisfies Any
      • 3.3.11 Satisfies All
    • 3.4 Logical Operators
      • 3.4.1 And
      • 3.4.2 Or
      • 3.4.3 Not
    • 3.5 Comparison Operators
      • 3.5.1 Equal To
      • 3.5.2 Less Than
      • 3.5.3 Less Than Or Equal To
      • 3.5.4 Greater Than
      • 3.5.5 Greater Than or Equal To
    • 3.6 General Relationship Operators
      • 3.6.1 Fulfills
    • 3.7 Temporal Operators
      • 3.7.1 Starts Before Start Of
      • 3.7.2 Starts After Start Of
      • 3.7.3 Starts Before End Of
      • 3.7.4 Starts After End Of
      • 3.7.5 Starts Concurrent With
      • 3.7.6 Starts Concurrent With End Of
      • 3.7.7 Starts Before Or Concurrent With Start Of
      • 3.7.8 Starts After Or Concurrent With Start Of
      • 3.7.9 Starts Before Or Concurrent With End Of
      • 3.7.10 Starts After Or Concurrent With End Of
      • 3.7.11 Starts During
      • 3.7.12 Ends Before Start Of
      • 3.7.13 Ends After Start Of
      • 3.7.14 Ends Before End Of
      • 3.7.15 Ends After End Of
      • 3.7.16 Ends Concurrent With
      • 3.7.17 Ends Concurrent With Start Of
      • 3.7.18 Ends Before Or Concurrent With End Of
      • 3.7.19 Ends After Or Concurrent With End Of
      • 3.7.20 Ends Before Or Concurrent With Start Of
      • 3.7.21 Ends After Or Concurrent With Start Of
      • 3.7.22 Ends During
      • 3.7.23 Concurrent With
      • 3.7.24 During
      • 3.7.25 Overlaps
  • Table 1. Examples of Inputs and Results for Overlaps
    • 3.7.26 Null Date/Time Comparisons in Temporal Operators
    • 3.8 Operator Precedence
  • Table 2. Operator Precedence
  • 4. Component Definitions
    • 4.1 Categories and Datatypes
      • 4.1.1 Care Experience
  • Table 3. Care Experience Datatypes and Attributes
    • 4.1.2 Care Goal
  • Table 4. Care Goal Datatype and Attributes
    • 4.1.3 Communication
  • Table 5. Communication Datatypes and Attributes
    • 4.1.4 Condition/Diagnosis/Problem
  • Table 6. Condition/Diagnosis/Problem Datatypes and Attributes
    • 4.1.5 Device
  • Table 7. Device Datatypes and Attributes
    • 4.1.6 Diagnostic Study
  • Table 8. Diagnostic Study Datatypes and Attributes
    • 4.1.7 Encounter
  • Table 9. Encounter Datatypes and Attributes
    • 4.1.8 Family History
  • Table 10. Condition/Diagnosis/Problem Datatypes and Attributes
    • 4.1.9 Functional Status
  • Table 11. Functional Status Datatypes and Attributes
    • 4.1.10 Immunization
  • Table 12. Immunization Datatypes and Attributes
    • 4.1.11 Individual Characteristic
  • Table 13. Individual Characteristic Datatypes and Attributes
    • 4.1.12 Intervention
  • Table 14. Intervention Datatypes and Attributes
    • 4.1.13 Laboratory Test
  • Table 15. Laboratory Test Datatypes and Attributes
    • 4.1.14 Medication
  • Table 16. Medication Datatypes and Attributes
    • 4.1.15 Physical Exam
  • Table 17. Physical Exam Datatypes and Attributes
    • 4.1.16 Procedure
  • Table 18. Procedure Datatypes and Attributes
    • 4.1.17 Risk Category/Assessment
  • Table 19. Risk Category/Assessment Datatypes and Attributes
    • 4.1.18 Substance
  • Table 20. Substance Datatypes and Attributes
    • 4.1.19 Symptom
  • Table 21. Symptom Datatypes and Attributes
    • 4.1.20 Transfer of Care
  • Table 22. Transfer of Care Datatypes and Attributes
    • 4.2 Attributes
  • Table 21. Attribute Definitions
  • Table A1. Time Unit and Interval Definitions
  • Table B1. Time Interval Calculations