Structured Quality Measure Definition and Import

From IHE Wiki
Jump to navigation Jump to search

"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

2. The Problem

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. "


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.


Appendix 1 Inpatient Quality Workflow Scenario, Excerpted from: US Department of Health and Human Services, Office of the National Coordinator for Health Information Technology. Quality Detailed Use Case. June 18, 2007, page 25. Available at: http://www.dhhs.gov/healthit/documents/UseCaseQuality.pdf

Retrieved from "http://wiki.ihe.net/index.php?title=Structured_Quality_Measure_Definition_and_Import&oldid=11275"