Structured Quality Measure Definition and Import Detailed Proposal

"Structured Quality Measure Definition and Import"

1. Proposed Workitem: Structured Quality Measure Definition and Import

• Proposal Editor: Floyd Eisenberg
• Editor: Floyd Eisenberg
• Date: N/A (Wiki keeps history)
• Version: N/A (Wiki keeps history)
• Domain: Quality
• Status: Detailed Proposal Completed 14 Nov 2007

2. The Problem

Summary

Today, quality measurement is performed through a retrospective review process by analyzing patient-level clinical data elements, manual and isolated electronic chart abstracting records to determine if missing elements can be identified to enhance compliance with processes and outcomes, and through submission of the data for aggregation and reporting. A very significant amount of human intervention is required up front to collect and manage the data so that full credit is given to the clinical care provider or to the organizational provider. New interoperability methodologies for extracting clinical data at the patient level would enable quality measurement through a more advanced and refined concurrent review process presenting quality measurement information to the provider at the point of service (POS). Such automated methodologies provide data locally at the provider organization at the time of service, and/or by the receiver of the final measurement assessment. This profile is intended to establish a specification for structured content to enable validation and augmentation of patient-level data collected for quality analysis. It is further intended to establish a specification for aggregation of individual patient-level data for comparison and benchmarking, allowing immediate feedback in real time for performance improvement initiatives within the EHR.

3. Key Use Case

The Quality Detailed Use Case of the US Office of the National Coordinator for Healthcare Information Technology (ONC – June 18, 2007) provides a good model as it specifies that quality measures, their definitions, and abstraction specifications are received by an organization electronically, areas for improvement are identified, followed by the provision and documentation of patient care. (Appendix A and B in this document). The scenario is specified for inpatient care settings and ambulatory care settings alike. The requirement is ubiquitous in that quality measures are defined and specified by measure development organizations, but the structure, format and logic of the specifications vary among multiple measure development organizations. These specifications, further, are provided in text form intended for consumption by abstracters who will interpret the requirements and implement the measures. The long term goal is to enable standardization and electronic implementation of measures, such that they can represent queries to an electronic record system and allow automated capture of required data elements for patients meeting inclusion an/or exception criteria. Further, the queries must be sufficiently specified in standard format and structure that analysis of compliance with the expected process or outcome can be automated. The use case further specifies that the output of a measure is available for review by the clinical care provider or organizational provider to enable augmentation of data that exist but are not captured electronically for query analysis. Also implied in the use case is that, on receipt of the measure, the clinical care provider or organizational provider identifies areas for improvement and incorporates these areas into the clinical care process. Therefore, the measures must be able to communicate actionable criteria for inclusion in clinical decision support strategies in the EHR. The use case requirement is specific to a clinical quality measure; however, such measures are derived from clinical practice guidelines. Therefore, the ideal process is for the clinical practice guideline creator to specify the algorithms in the guidelines according to expected processes and related exceptions to those processes, required data elements, and expected measures of performance so these can be incorporated into measures of adherence. Semantic interoperability remains a challenging issue, but given a standard structure for representation, that issue is more readily identified and managed.

Key integration features

The proposal is to integrate the requirement to identify a cohort of patients for which provider performance will be evaluated (clinical care providers and organizational providers). The processes and/or outcomes expected for this cohort of patients (and exception criteria for patient exclusion) also are identified within the measure. That these elements are consistent in the measure and in the EHR and in the subsequent data warehouse analyzer represent significant interoperability integration value.

How the problem could be solved

Standardization of quality measure definition by measure developers with sufficient granularity for import and management by EHRs will significantly enable (a) understanding of data types, (b) logic for identification of patient cohorts that meet the measure domain, and (c) consistency of measurement definition. Moving forward, such standardization will enable more implementable defnition of clinical guidelines as well as provide infrastructure for testing of various existing clinical decision support methodologies.

Market interest & available resources

The Quality Detailed Use Case of the US Office of the National Coordinator for Healthcare Information Technology (ONC – June 18, 2007) has been reviewed by the US Healthcare Information Technology Standards Panel (HITSP) leading to the publication of an Interoperability Specification (IS06) for implementation of the Quality Use Case. Similar to the Quality Domain Framework, the IS06 manages to-date to provide methodology for extracting clinical data required for the quality measures. Scoped out for the 2007 document is the import / definition of the measure. This profile would provide the methodology to manage that profile. There is significant market interest and the profile would also be included in the 2008 HITSP IS06 version, making it a requirement for implementations in the US. The standardization of quality measures is also a significant demand in the US, Canada and Europe as well.

IHE as a venue to solve the problem

The intent of the Quality Domain as established is to create methodology to manage quality measures concurrently within the EHR. Such concurrent management requires a measure definition directly consistent with the document structure used within the EHR. Therefore, consistency with EHR document management is essential for importation of the measure as well as definition of the quality measure document for patient-level reporting.

4. Standards & Systems

HL7 Structured Documents XML Logic, algorithms open, but reference to OWL, GELLO, Arden Syntax, Common Logic for trial implementations

5. Discussion

The current profile is intended establish a specification for structured content to express measurements and related criteria. An example of such a profile might be a constrained HL7 Structured Document content profile. The content for the profile will be informed by the work of the Collaborative for Performance Measure Integration with EHRs, a collaborative of the American Medical Association (AMA), the National Committee for Quality Assurance (NCQA), in cooperation with the Electronic Healthcare Vendor Association (EHRVA). Workgroup B of the Collaborative has identified measurement import and export criteria. The export criteria have been incorporated into a constrained CDA document now under review by the HL7 Pediatric SIG as the Quality Reporting Document Architecture (QRDA). The message content is also incorporated into the HITSP Interoperability Specification as a Patient Level Quality Data Document, Component C38 of the Quality Interoperability Specification IS-06 (available at: HITSP Quality Constructs). That component is similar to QRDA.

Establishment of a Structured Quality Measure Definition and Import will significantly move forward automated representation of clinical guideline and measurement specifications in usable format for incorporation into electronic health record systems and analyzers. In the United States, measure developers are expected to have their measures endorsed by the National Quality Forum (NQF). Endorsement criteria are under revision now as a result of the work performed by the Healthcare Information Technology Expert Panel (HITEP), convened by NQF to identify data element classes and types required for quality measurement as part of the ONC Quality Detailed Use Case. In cooperation with HITSP, the HITEP identified a need for standard representation of measures and the work of the Collaborative (referenced above) is helping to feed that process. Standardization of the Collaborative import model into a constrained CDA structure would enable trial implementations and significantly move the industry toward greater interoperability with respect to clinical quality measures and take the next step toward clinical decision support (CDS) representation. Creation of a structure in which CDS can be presented to the EHR will further enable real world implementation trials of various competing CDS models and expedite outcomes. Still to be considered is the representation and prioritization of temporal components where there are multiple data elements in the record reflecting the same concept. Such semantic interoperability components can be incorporated in the profile as determined feasible by the Technical Committee.

5. Technical Approach

HL7 Structured Documents has a standard format that can be constrained for documentation of a structured quality measure document. There is existing work from the Collaborative for Performance Measure Integration with EHR Systems Workgroup B that identifies, in XML format, the metadata and component data required for detailed, granular description of a quality measure. The Healthcare Information Technology Expert Panel (HITEP), a subgroup of the US National Quality Forum (NQF) was established to identify highest priority measures from NQF endorsed ambulatory and inpatient quality measures. Identifying 84 high priority measures, the HITEP further identified a specified list of data element classes and types required to compute compliance with all of the 84 high priority measures. The Collaborative XML import model plus the HITEP data element classes and types define the content with which to constrain an HL7 structured document. That constrained document thus creates a profile that is reusable for multiple quality measures with applicability to major clinical areas of concern (e.g., but not limited to Cardiac disease, Diabetes, Asthma, Pneumonia, Surgical Care, etc.). The proposal is to create a generic profile which, in subsequent years can be extended with appendices to enable additional data element types to manage an increasing number of quality measurement domains.

Existing actors

Existing actors include those identified in the Quality Technical Framework (Patient Level Export of Quality Data).

New actors

• Quality Measure Sender - The originater of the quality measure which sends the quality measure to the measure repository or directly to the EHR or analyzer.
• Quality Measure Receiver - This actor can be represented by the business actor EHR, Analyzer or a measure repository

Existing transactions

There is no existing transaction for send or receipt of quality measures. The draft PEQD framework for the Quality Domain has an open, unresolved, need for a measure definition to begin the process.

New transactions (standards used)

HL7 Structured Documents and Templates can be constrained to define quality measures. The transactions can be managed through creation of a Quality Measure XDS Registry and utilize the XDS infrastructure for storing and retrieving quality measures.

Impact on existing integration profiles

Extension of PEQD to include required data and logic import with respect to quality measures.

New integration profiles needed

Quality Measure Document (QMD).

Breakdown of tasks that need to be accomplished

1. Evaluate HL7 Structured Documents, review with experts, Keith Boone, Liora Alschuler, Bob Dolin the best approach for QMD
2. Create constraint on appropriate document architecture identified in bullet 1, consistent with HL7 RIMM
3. Coordinate with HL7 addition to or new standard to accomodate the constraint identified in bullet 2
4. Evaluate with ITI Co-Chairs extension of XDS as a document registry for Quality Documents

6. Support & Resources

Support, in principal, has been expressed by The Alschuler Group, the Office of the National Coordinator, the National Quality Forum, the Collaborative for Performance Measure Integration with EHRs (AMA and NCQA sponsored), and the HITSP Population Health Technical Committee. There is also significant interest in the PCC Domain with respect to use of the QMD content for Public Health Registry and Clinical Trials patient cohort selection and logic representation.

7. Risks

Technical risks include

1. Identification of the appropriate construct to constrain for the QMD
2. Modification of the content to accomodate Clinical Trials and Public Health
3. Resources and possibly funding for those resources to manage the constraints

Political risks include

1. Alignment with PCC Focused Care Management activities with Public Health and Clinical Trials
2. Modification of the content to accomodate Clinical Trials and Public Health

8. Open Issues

Open Issues detailed in the Risks section.

9. Tech Cmte Evaluation

<The technical committee will use this area to record details of the effort estimation, etc.>

Effort Evaluation (as a % of Tech Cmte Bandwidth):

• 35% for ...

Responses to Issues:

See italics in Risk and Open Issue sections

Candidate Editor:

TBA