Quality Data Model (QDM)

Similar documents
HITSP/IS06. January 25, 2010 Version 2.0. Healthcare Information Technology Standards Panel. Population Perspective Technical Committee.

Terminology Harmonization

HEALTH INITIATIVES CONSULTING, INC. Maintaining Data Mapping in i2itracks

User Manual. phr.mtbc.com

Data Quality Attributes

April 25, Dear Secretary Sebelius,

HITSP/T16. October 15, 2007 Version 1.1. Healthcare Information Technology Standards Panel. Security and Privacy Technical Committee.

NIST Normative Test Process Document: e-prescribing (erx) Test Tool

Certification Commission for Healthcare Information Technology. CCHIT A Catalyst for EHR Adoption

Information Technology (CCHIT): Report on Activities and Progress

Diabetes Data Strategy Project ( Diabe-DS ) Overview and Status Update May 2010

Overview of the Multi-Payer Claims Database (MPCD)

Meaningful Use and the 3M Healthcare Data Dictionary

Meaningful Use Setup Guide

EZ-Suite Interfacing Applications. Jeremy Powell (Chief Growth Officer, Citra Health Solutions) Rini Jose (Product Manager, Citra Health Solutions)

Pennsylvania PROMISe Companion Guide

Document Number: HITSP 08 N 378 Date: December 17, 2008 Report from the HITSP Education, Communication and Outreach (HITSP-ECO) Committee

HPH SCC CYBERSECURITY WORKING GROUP

Certification for Meaningful Use Experiences and Observations from the Field June 2011

MAQ DASHBOARD USERS GUIDE

What is Usability? What is the Current State? Role and Activities of NIST in Usability Reactions from Stakeholders What s Next?

ONC Health IT Certification Program

Healthcare FHIR API TECHNICAL SPECIFICATION 7.4

ProviderConnect Registered Services Autism Service Provider User Manual ASD Behavioral Assessment, Treatment Plan and Program Book Development

IHE Patient Care Coordination (PCC) Technical Framework Supplement. CDA Document Summary Sections (CDA-DSS) Revision 1.1 Trial Implementation

Chapter Two: Conformance Clause

CMS and ehealth. Robert Tagalicod Director, Office of ehealth Standards and Services (OESS)

PANEL 5: IHE CONFORMITY ASSESSMENT TESTING IN A GLOBAL CONTEXT

Report of the Working Group on mhealth Assessment Guidelines February 2016 March 2017

Slide 1 Welcome to Networking and Health Information Exchange, Health Data Interchange Standards. This is lecture b.

Health Information Exchange Content Model Architecture Building Block HISO

Prior Authorization and Clinician Burden: Updates from ONC

Ch 4: Requirements Engineering. What are requirements?

IHE Patient Care Coordination (PCC) Technical Framework Supplement. CDA Document Summary Section (CDA-DSS) Revision 1.0 Draft for Public Comment

ConCert FAQ s Last revised December 2017

pan-canadian Oncology Drug Review Stakeholder Feedback on a pcodr Expert Review Committee Initial Recommendation (Provincial Advisory Group [PAG])

Primary Health Care (PHC) Indicator Inventory: Instructions for Use

EBSCO Publishing Health Library Editorial Policy

The HITECH Act. 5 things you can do Right Now to pave the road to compliance. 1. Secure PHI in motion.

HIT Policy Committee. Recommendations by the Certification and Adoption Workgroup. Paul Egerman Marc Probst, Intermountain Healthcare.

Update from HIMSS National Privacy & Security. Lisa Gallagher, VP Technology Solutions November 14, 2013

The SHARPn phenotyping funnel. Phenotype specific patient cohorts

10-CM/PCS Barriers and Opportunities

Edition. MONTEREY COUNTY BEHAVIORAL HEALTH MD User Guide

Discuss and finalize recommendations on Entity-Level Provider Directories (ELPDs):

Vision for PACE Data Environment, PACE Quantum and the Common Data Set. October 21, 2015

Architecture and Standards Development Lifecycle

NextGen UD2 Upgrade Enhancements

Direct / Secure Messaging

Patient Portal- Instructions Overview

CERECONS. Provider Training

Regulating Telemedicine: the

ICD-10 Customer Testing Guidelines and Scenarios

CPRD Aurum Frequently asked questions (FAQs)

National Antimicrobial Resistance Surveillance

HL7 Development Framework

Thank you, and enjoy the webinar.

Diabetes Data Strategy Project ( Diabe-DS ) Overview and Status Update January 2010

QRDA Category I: Ballot Development

Can We Reliably Benchmark HTA Organizations? Michael Drummond Centre for Health Economics University of York

Testing for Reliable and Dependable Health Information Exchange

MAPIR User Guide for Eligible Hospitals. Medical Assistance Provider Incentive Repository (MAPIR): User Guide for Eligible Hospitals

Health Information Exchange - A Critical Assessment: How Does it Work in the US and What Has Been Achieved?

IHE Endoscopy Technical Framework Supplement. Endoscopy Image Archiving (EIA) Rev. 1.1 Trial Implementation

NATIONAL COMMISSION ON FORENSIC SCIENCE

A Pilot Implementation of DIRECT Messaging and Provider Directory Services in the Palomar Health District

Table of Contents [Revised: February 6, 2015] PEI-OMA User Manual MAP Supplemental

Clinical Decision Support

United States Government Cloud Standards Perspectives

Prevention and Early Intervention Outcome Measures Application (PEI-OMA)

Chapter Two: Conformance Clause

Compass Practice Transformation Network (PTN) User Guide

Vaccine data collection tool Oct Functions, Indicators & Sub-Indicators

Overview Functionality Maintenance Future

Qualifying Alternative Payment Model Participants (QPs) Methodology Fact Sheet

Infinedi, LLC. Frequently Asked Questions

Response to CMS. WEDI Attachment Forum Questions. August 9th Attachment Standard

Workflow. Workflow Tabs

SNOMED CT (Systematized Nomenclature of Medicine Clinical Terms)

Preparing for v11.4. From the PM and UC perspective

Digital Imaging and Communications in Medicine (DICOM) Part 1: Introduction and Overview

Illinois Medicaid EHR Incentive Program for EPs

Matt Quinn.

ICD-10 Testing: Testing Your EHR, Practice Management System and Internal Processes for ICD-10 Readiness

Identity Theft: Enterprise-Wide Strategies for Prevention, Detection and Remediation

Outcomes and Lessons Learned From 5010 Testing Project Collaboration

Putting It All Together:

pan-canadian Oncology Drug Review Stakeholder Feedback on a pcodr Expert Review Committee Initial Recommendation (Manufacturer)

HL7 s Common Terminology Services Standard (CTS)

July 13, Via to RE: International Internet Policy Priorities [Docket No ]

IPC Integrated Food Security Phase Classification. Lesson: IPC Quality Assurance

2017 Partners in Excellence Executive Overview, Targets, and Methodology

SUSTAINABLE ELECTRIFICATION OF HEALTH FACILITIES: UGANDA

Near-port Community Capacity Building Toolkit for Effective EJ Stakeholder Engagement

Inpatient Quality Reporting (IQR) Program

pan-canadian Oncology Drug Review Stakeholder Feedback on a pcodr Expert Review Committee Initial Recommendation

European Commission Initiatives in telemedicine Presentation endorsed by the European Commission

Open Source Software Quality Certification

ACCREDITATION COMMISSION FOR CONFORMITY ASSESSMENT BODIES

DATA VALIDATION RESOURCES RCHC Data Group Webinar By Ben Fouts MPH November 14, 2017

Transcription:

Quality Data Model (QDM) Overview Document National Quality Forum 4/20/2011

QUALITY DATA MODEL (QDM): OVERVIEW TABLE OF CONTENTS Quality Data Model (QDM): Overview... 2 National Quality Forum: Overview and Goals... 3 Performance Measurement: Information Needs and the Quality Data Model... 3 Electronic Measures (emeasures) and QDM s Role... 4 Quality Data Model: Status and the Public Comment Process... 5 Quality Data Model: The Full Description, Specificity, and Technical Detail... 6 Figure 1. QDM Composition Diagram... 7 Figure 2. QDM Element Structure... 8 Figure 3. QDM Use of Value Sets.... 9 Table 1. QDM Concepts... 10 Table 2. QDM States... 11 Figure 4: Timing Attribute... 12 Figure 5: Data Flow Attribute... 12 Figure 6. Actor Attribute... 13 Figure 7. Concept Specific Attribute... 13 Table 3. QDM Concepts and Specific Attributes... 14 April 20, 2011 Quality Data Model Overview pg. 2

National Quality Forum: Overview and Goals The National Quality Forum (NQF) is a nonprofit organization that operates under a three-part mission to improve the quality of American healthcare by: building consensus on national priorities and goals for performance improvement and working in partnership to achieve them; endorsing national consensus standards for measuring and publicly reporting on performance; and promoting the attainment of national goals through education and outreach programs. NQF drives improvements in care by rigorously endorsing evidence-based measures of performance focusing on measurement for accountability and quality improvement. Measurement has the greatest impact on quality when it supports transparency and public reporting, but it also provides information to help clinicians make improvements in care delivery. To date, quality measurement and public reporting have been thought of as secondary data uses rather than as drivers of care. By setting standardized performance measures and properly designing and building health IT, however, it will now be possible to capture performance data as part of the care process and provide immediate information feedback and clinical decision support to clinicians to improve care. Designing and building health IT to support performance improvement requires close collaboration between the quality and health IT communities. NQF plays a key role in the quality community as the national standard-endorsing body for performance measures and as a neutral convener of multiple stakeholders to set National Priorities for improvement and drive quality improvement. Performance Measurement: Information Needs and the Quality Data Model Collecting and reporting accurate, comparative healthcare performance data is a complex and largely time-consuming and manual process. Much of the information required to measure performance is collected in the process of routine clinical care and is available in electronic health records (EHRs) and other clinical data sources. It has not, however, been routinely available for export and use for reporting or performance measurement. Performance measures are most frequently developed based on routinely available sources of data and therefore are often based on claims and clinically enriched administrative data. Taking advantage of comprehensive clinical data contained in EHRs and other clinical applications, including personal health records (PHRs) requires that measures are specified to account for the way data are expressed in such products. April 20, 2011 Quality Data Model Overview pg. 3

NQF, through the Health Information Technology Expert Panel (HITEP), a committee of health IT industry experts, established the Quality Data Model (QDM) to enable such expression of data criteria for measurement to address data that are available in EHRs and other clinical information sources. QDM s development was based on a request by the American Health Information Community (AHIC) and the Office of the National Coordinator for Health Information Technology (ONC), with funding from the Agency for Healthcare Research and Quality (AHRQ). The QDM (formerly referred to as the Quality Data Set, or QDS) is an information model that clearly defines concepts used in quality measures and clinical care and is intended to enable automation of structured data capture in EHRs, PHRs, and other clinical applications. It provides a way to describe clinical concepts in a standardized format so individuals (i.e., providers, researchers, or measure developers) monitoring clinical performance and outcomes can clearly and concisely communicate necessary information. The QDM also describes information so EHR and other clinical electronic system vendors can consistently interpret and easily locate the data required. The QDM provides the potential for more precisely defined, universally adopted electronic quality measures to automate measurement and compare and improve quality using electronic health information. Use of the QDM will enable more standardized, less-burdensome quality measurement and reporting and more consistent use and communication of EHRs for direct patient care. The QDM is described in detail in the Health Information Technology Expert Panel Report: Recommended Common Data Types and Prioritized Performance Measures for Electronic Healthcare Information Systems. The model was further clarified and described in a second report, Health Information Technology Automation of Quality Measurement: Quality Data Set and Data Flow. Electronic Measures (emeasures) and QDM s Role During the last 18 months, NQF and many measure stewards have been involved in efforts to rapidly convert, or retool, existing measures for use on an electronic platform. As part of the Department of Health and Human Services (HHS) contract, NQF has worked with measure stewards to retool an initial set of more than 100 performance measures.many of these are being used for the Health Information Technology for Economic and Clinical Health Act (HITECH) incentive payments linked to meaningful use of EHRs. In a recent child health quality measures project, NQF received, for the first time, measures submitted with EHR specifications. NQF has been laying the groundwork for the endorsement of emeasures for some time. The Testing Task Force Report released in 2011 specifies requirements for testing new and retooled e-measures. The QDM is an essential building block of both performance measures and EHRs. April 20, 2011 Quality Data Model Overview pg. 4

With support from HHS, NQF subcontracted with the IFMC to develop a Measure Authoring Tool that will help developers generate specifications for emeasures in a consistent fashion. The tool is expected to be publicly available to measure developers starting in fall 2011. Quality Data Model: Status and the Public Comment Process To ensure QDM s continued value and use, NQF will enhance and update it as needed in response to evolving quality measurement needs. The QDM Version 2.1 was published for public comment in September 2010. The current version, QDM 3.0, contains updates based on feedback from the comment period as well as from information learned in applying the QDM to retooling more than 100 measures in 2010. This new version has a number of modifications, including: 1. A more hierarchical structure has been implemented. 2. A more detailed set of information about each QDM element has been included to allow a more complete description of information required. 3. A method for describing data relationships enabling more expressive measure criteria has been employed. 4. Standard categories are now referred to as concepts. 5. States are subdivided into states of action or states of being. (States of action are present-tense verbs, and states of being are nouns.) 6. The terminology and definitions of some concepts, states, and attributes has shifted in some cases to make these components more applicable and reusable. For example, allergy is now a concept to allow clearer description of information requirements rather than its prior use as a context of medications or substances. A new concept has also been added to enable measurement of the use of health IT as part of care coordination, the health record component. This new concept is derived from the Health IT Assessment Framework published in 2010. 1 7. Data type previously was used to combine a concept (referred to as standard category ) and its context of use. For example, the data type Diagnostic study order now is referenced by the concept Diagnostic study and the state in which it is expected, for example, order. This change allows states to be more interchangeable. 8. Data types context components are now referred to as states. 9. Each concept has a defined list of states (states of action and/or states of being) that can be used to describe how it is used within a measure statement. To see the full list of 1 NQF, Expert Panel Report: Driving Quality: A Health IT Assessment Framework for Measurement, 2010, Washington, DC: NQF; 2010. Available at: http://www.qualityforum.org/publications/2010/12/driving_quality_- _A_Health_IT_Assessment_Framework_for_Measurement.aspx. Last accessed April 2011. April 20, 2011 Quality Data Model Overview pg. 5

concepts and states, refer to the list below and more complete detail in the Appendix under QDM Concepts and States. Individuals can submit public comments on the most current QDM version on a continual basis. NQF will use relevant elements of its Consensus Development Process to receive and review comments on the most current version of the QDM. NQF s Health Information Technology Advisory Committee (HITAC), in collaboration with NQF staff, will regularly review public comments on the QDM. Based on the findings and HITAC recommendations, the QDM will be updated and new versions released as needed. Each new version of the QDM will be posted to the NQF website and will then be available for public comment. The next version of the QDM will be posted for public comment at the end of April 2011 and released in early summer. Quality Data Model: The Full Description, Specificity, and Technical Detail The QDM is a model of information used to express patient, clinical, and community characteristics as well as the basic logic required to express quality measure criteria. Measure specifications include population, denominator, numerator, exclusion, and optionally risk adjustment criteria. The QDM describes the data elements and the states, or contexts in which the data elements are expected to exist in clinical information systems (see Figure 1, below). As such, coordination with standards is required to ensure the information is clear, unambiguous, consistent, and accurate. Readers interested in understanding more of QDM s technical details and specifications (e.g., expression language, relative timing) should refer to the companion document, QDM Technical Specification. April 20, 2011 Quality Data Model Overview pg. 6

Quality Data Model: QDM Element Structure Example of a Performance Measure Phrase Diagnosis active: Asthma Starts before or during Encounter Office & Outpatient Consult QDM Element Comparator QDM Element Consists of a Concept Has many Has an Has an State Has many Attribute Relevant Attributes Relevant Attributes Instance Is defined by a Is defined by a OR Which contains each of the following Type(s) of Attributes OR State of Action Timing Codesets Codesets Code List Code List Grouping State of Being Actor Codesets Codesets Is defined by an Is defined by many Data Flow Codesets Codesets Allowable Taxonomy Code Lists Relevant Attributes Relevant Attributes Each of which Is defined by an Concept Specific Codesets (OPTIONAL) Codesets Allowable Taxonomy Relevant Attributes Relevant Attributes Figure 1. QDM Composition Diagram The diagram depicts the direction and interrelationship between the various QDM element components (i.e., concepts, states, and attributes.) The left side of the diagram shows the definition of a QDM element. This begins with defining a concept for which each use April 20, 2011 Quality Data Model Overview pg. 7

has an instance (or specific use), which in turn is defined by a value set. Value sets may be individual or comprised of child value sets. An example of child value sets is provided in Figure 3. Each value set is defined by a taxonomy that is based on established standards for clinical system use and interoperability. The middle section of the diagram shows the application of a state to the defined instance of a concept. States may be actions (states of action) or indicate the existence of a specific concept instance (states of being). The concept-state pair comprises the QDM element, which can be further described using the elements on the right of the diagram the attributes. Attributes include four basic categories: timing, actor, data flow, and concept-specific. Greater detail is provided in Figures 4, 5, 6, and 7. Enhancements are incorporated into the QDM to enable expanding concepts of measurement. This helps to ensure the QDM covers data required to evaluate care coordination across venues of care, patient, and family engagement in care and longitudinal outcomes. These QDM elements are used in different contexts, depending on the measure (see Figure 2, below). For example, one measure may assess if a lab test was ordered, while another may assess if it was performed, and a third may compare the actual lab result to a guideline threshold or the amount of change in the result over time. Figure 2. QDM Element Structure The components of a QDM element are shown in the figure. The figure on the left identifies the terms used for each component of the QDM element. The figure on the right uses each of these components to describe a QDM element indicating Medication, administer aspirin. Each QDM element is composed of a concept, the state in which that concept is expected to be used and a value set of codes in a defined taxonomy to specify which instance of the concept is expected. The boxes in the lower section of the QDM element specify individual attributes, or additional data to April 20, 2011 Quality Data Model Overview pg. 8

describe the QDM element. Attributes include: timing, actor, data flow, and concept-specific. More detail about each of these QDM components is provided in the text. Figure 3. QDM Use of Value Sets This figure shows three QDM elements, each of which uses value sets. The figure on the left shows a value set for medication (aspirin) that includes a single set of codes using a single taxonomy. The middle figure shows the instance diabetes of the concept diagnosis. In the middle figure the value set provided is a parent value set composed of three child value sets, one each using the taxonomies SNOMED-CT, ICD-9-CM, and ICD-10-CM, respectively. In this case the parent value set indicates the same concept instance but expressed in different taxonomies. The figure on the right provides a parent value set titled ACEI/ARB* comprised of two child value sets, each in the same taxonomy (RxNorm). This example uses a parent value set for convenience, expressing a combination of two different concept instances (both ACEI and ARB medications). *ACEI = angiotensin-converting enzyme inhibitor; ARB = angiotensin receptor blocker. April 20, 2011 Quality Data Model Overview pg. 9

1. QDM Concepts and States Table: The following table lists all the QDM concepts and states. More details on the possibilities of each concept and state and the relationships among all concepts and all states are included in the companion document, QDM Technical Specifications. The QDM element (concept, state, value set, and attributes) comprise the atomic data expression that is used to specify data criteria required for the quality measure. Table 1. QDM Concepts QDM Concepts 1. Allergy 2. Characteristics 3. Communication 4. Condition/Diagnosis/Problem 5. Device 6. Diagnostic Study 7. Encounter 8. Experience 9. Family History 10. Functional Status 11. Health Record Component 12. Intervention 13. Intolerance 14. Laboratory Test 15. Medication 16. Physical Exam 17. Preference 18. Procedure 19. Risk Evaluation 20. Substance 21. Symptom 22. System Resources 23. Transfer April 20, 2011 Quality Data Model Overview pg. 10

Table 2. QDM States QDM States QDM State of QDM State of Action Being 1. 1. Access 1. Active 2. Acknowledge 2. Inactive 3. Administer 3. Resolved 4. Alert 5. Apply 6. Assess 7. Calculate 8. Create 9. Decline 10. Discontinue 11. Dispense 12. Document 13. Implement 14. Notify 15. Order 16. Perform 17. Plan 18. Receive 19. Recommend 20. Reconcile 21. Record 22. Remind 23. Report 24. Request 25. Review 26. Stratify 27. Transmit 28. Update April 20, 2011 Quality Data Model Overview pg. 11

Attributes QDM Element attributes include four basic categories: timing, actor, data flow, and conceptspecific. Greater detail is provided in Figures 4, 5, 6, and 7. Figure 4. Timing Attribute: The timing attribute indicates the time of occurrence, including whether the beginning or end of a process is the time of interest. Timing provides the process context for the QDM element. Figure 5. Data Flow Attribute: The data flow attribute allows specification of a specific sender or receiver of a transaction, enabling expression of criteria that a specific health care component is shared by a clinician (sender) with a patient (receiver). April 20, 2011 Quality Data Model Overview pg. 12

Figure 6. Actor Attribute: The actor attribute allows the measure developer to define the expected source, recorder, and subject for each QDM element; thus, it is possible to specify data only derived and recorded by devices, patients, or clinicians. Figure 7. Concept-Specific Attribute: Concept-specific attributes are listed separately in Table 3 of this document. April 20, 2011 Quality Data Model Overview pg. 13

Table 3. QDM Concepts and Specific Attributes: This table provides detail on the specific relationships between the attributes and concepts. The individual concept-specific attributes are provided as headers for each column. The concepts define the rows. Concept-specific attributes that apply to each concept are depicted with an x in the applicable columns. Full descriptions of the concepts and attributes are provided in the QDM Technical Specification (glossary section) companion document. Concept (From Anatomical Environmental Facility Health Record Version X.X) structure Dosage location location Field Laterality Ordinality Reason Result Route Severity Status 1. Allergy x x x 2. Characteristics x x 3. Communication x x x 4. Condition/ x Diagnosis/ Problem x X X x x 5. Device x x X X x 6. Diagnostic x study X x X x x 7. Encounter x X x x 8. Experience x 9. Family History x x 10. Functional x Status 11. Health record component x x X x x x x X 12. Intervention x x x x X X x x 13. Intolerance x x x 14. Laboratory test x x x x x x x 15. Medication x x x 16. Physical Exam x x x x x x x 17. Preference x x 18. Procedure x x x x x X x x x 19. Risk evaluation x x x x 20. Substance x x x 21. Symptom x x x x x X x x April 20, 2011 Quality Data Model Overview pg. 14

Concept (From Anatomical Environmental Facility Health Record Version X.X) structure Dosage location location Field Laterality Ordinality Reason Result Route Severity Status 22. System resources x x x x 23. Transfer x x x x April 20, 2011 Quality Data Model Overview pg. 15

The companion document, QDM Technical Specification, provides greater detail on the technical issues and specifications (e.g., expression language, relative timing) associated with the QDM. This document includes the following: QDM Glossary: Provides detailed definitions with relevant examples for all terms and components of the QDM. QDM Relative Timings Functions and Operators: Describes the interactions of QDM components related to the: 1) relative timing, 2) operator, or 3) function. Relative timings allow a measure developer to describe timing relationships among individual QDM elements. Combining the QDM elements in this way allows the measure developer to create phrases that can add meaning to the individual elements. Operators allow measure developers to compare two or more QDM elements logically or mathematically. Functions use a QDM element as an input and return a calculation based on that input. QDM Mapping of Concepts to States: Provides detail on the possibilities of each concept and state and describes the relationships among all concepts and all states (e.g., every state that corresponds with diagnosis). April 20, 2011 Quality Data Model Overview pg. 16