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: Draft Detailed Proposal 07 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.

<Demonstrate in a line or two that the key integration features are available in existing standards. E.g. "DICOM has an SR format for radiation dose events and a protocol for exchanging them.">

<Summarize in a line or two why IHE would be a good venue to solve the problem. E.g. "The main challenges are dealing with the chicken-and-egg problem and avoiding inconsistent implementations.">

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

<This section can be very short but include as much detail as you like. The Technical Committee will flesh it out when doing the effort estimation.>

Existing actors

<Indicate what existing actors could be used or might be affected by the profile.>

New actors

<List possible new actors>

Existing transactions

<Indicate how existing transactions might be used or might need to be extended.>

New transactions (standards used)

<Describe possible new transactions (indicating what standards would likely be used for each. Transaction diagrams are very helpful here. Feel free to go into as much detail as seems useful.>

Impact on existing integration profiles

<Indicate how existing profiles might need to be modified.>

New integration profiles needed

<Indicate what new profile(s) might need to be created.>

Breakdown of tasks that need to be accomplished

<A list of tasks would be helpful for the technical committee who will have to estimate the effort required to design, review and implement the profile.>

6. Support & Resources

<List groups that have expressed support for the proposal and resources that would be available to accomplish the tasks listed above.>

7. Risks

<List technical or political risks that will need to be considered to successfully field the profile.>

8. Open Issues

<Point out any key issues or design problems. This will be helpful for estimating the amount of work and demonstrates thought has already gone into the candidate profile.>

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