Advancing Quality Measures Reporting in HIEs

by Randolph C. Barrows Jr., MD, MS

Members of the NHIN Cooperative demonstrated significant interoperability advances in support of healthcare quality measurement, feedback, and reporting at the 5th Nationwide Health Information Network (NHIN) Forum last December. The public forum included demonstrations of technology developed by NHIN awardees working on a variety of infrastructure and application areas designed to facilitate secure health information exchange (HIE).

The forum also illustrated developments made during the quality use case (QUC) demonstration project and indicated next steps for advancing HIE.

The Foundation of the NHIN Demonstrations

The QUC demonstrations were guided by the Office of the National Coordinator for Health Information Technology’s (ONC) Quality Detailed Use Case. The use case was developed by the American Health Information Community to create consensus around the workflows and information exchanges necessary to:

  • Incorporate quality measurement, feedback, and reporting into electronic health record (EHR) systems for provider service improvements
  • Use quality measures data in clinical decision making for direct patient care improvements
  • Aggregate quality reporting across provider organizations and health plans for accountability and transparency to healthcare consumers for public health and commercial service improvements

The use case contains two scenarios for quality information collection and reporting: one for hospital-based care and another for office-based clinician care. The two scenarios are largely analogous in their representation of suggested work and information flows, but they reflect the markedly different legacy and maturation of processes supporting quality measurement and reporting in the two environments.

The quality use case covers the roles of healthcare providers, health information exchanges, quality data measurement and reporting facilities, and other information sources and recipients relevant in the measurement of healthcare quality. In addition, the two scenarios describe analogous quality-related information exchanges, or “flows,” between participants.

Moving Quality Reporting Forward in HIEs

The QUC demonstration project was divided into five phases: a workgroup phase for creating functional requirements; a core content phase for generating data exchange specifications; a testing phase to examine the validity of the exchange specifications; an implementation phase for local software and system build activities; and a demonstration phase. NHIN awardees participating in the QUC demonstration included the Long Beach Network for Health, the Indiana Health Information Exchange, and the New York eHealth Collaborative.

During the workgroup phase , awardees were charged with producing a single set of functional requirements to support ONC’s designated “priority” information flows (summarized in the table at right), taken as a subset from those described in the full quality use case.

In addition to understanding the priority flows, workgroup members also needed to reference the Healthcare Information Technology Standards Panel (HITSP) Quality Use Case Interoperability Specification (IS06). The specification was especially useful for its gap analysis of existing and missing technical standards that could support the priority flows. Input was supplemented by participants’ awareness of relevant ongoing standards development efforts.

Due to the large number of identified gaps, this effort became integrated with the core content phase for the definition of quality data exchange specifications. The work involved composing a quality use case content specification document, including functional requirements and data exchange specifications with suitable rationale. This document was subsequently reviewed and accepted by the quality use case workgroup, the core content workgroup, and the Office of the National Coordinator.

The content specifications document noted:

  • A lack of applicable standards for priority flow 1.
  • Relevant HITSP constructs for priority flow 3, in particular longitudinal patient data elements could be mapped into the NHIN summary patient record document.
  • HITSP constructs for patient-level quality data messages and patient-level quality data documents using the IHE Medical Summary for priority flow 4. Though these component-level interoperability specifications mapped a limited set of quality data elements to structured data fields, infrastructural pieces were missing, and no sample implementations existed. As an alternative, the content specification pointed to the work of the Quality Reporting Document Architecture (QRDA), a Health Level Seven draft standard under development at the time.
  • Absence of a suitable HITSP standard for priority flow 9; however, the New York eHealth Collaborative contract charged that group with addressing this deficit. Representatives supporting the project joined the QRDA collaboration prior to the NHIN project to help enunciate specifications for population-level quality data reporting. The resulting specification, later known as QRDA Category 3, became the official deliverable of New York eHealth Collaborative for the NHIN project.

The content specification document also revealed that the quality use case did not reflect certain real-world quality data and system modeling needs encountered by workgroup members, including:

  • The quality use case models only patient-level quality data exchange from provider systems to quality data measurement and reporting facilities. This is unnecessarily restrictive and unrepresentative of the robust analytic and reporting capabilities in many modern EHRs and integrated provider systems. This role issue was clarified to some extent in the HITSP IS06, but the language is inconsistent and discordant with the use case.
  • The quality use case information flows do not accommodate exchange of quality data germane to quality dashboards (i.e., patient-level quality measure assessments that may come from external measurement and reporting facilities back into provider systems for display and use).
  • The quality use case does not model aggregate or population-level quality data flow to an external quality data warehouse for further analysis, aggregation, and reporting.

The specification testing phase was unremarkable for the project, since a majority of the data specifications did not map to the NHIN-specific summary patient record document. Priority flow 1 for the exchange of quality measure specifications was not demonstrated because this work was not funded.

The implementation phase was a two-month period of local awardee project software engineering, system setup, data entry, testing, and validation. There was little inter-awardee collaboration during this period.

The demonstration phase consisted of two major events: a testing event at the National Institute of Standards and Technology in November 2008 and the NHIN Public Forum in December 2008. The NIST testing event was a technical check in which all deliverables were examined for authenticity, while each system, running live over secure network connections, was examined in real time.

Priority Information Flows

During the workgroup phase, awardees were charged to collaborate and produce a single set of functional requirements to support the Office of the National Coordinator’s designated “priority” information flows, taken as a subset from those described in the full quality use case.

Priority Information Flow

Description

Quality Use Case Scenario(s)

 

Next Steps for Quality Reporting in HIEs

Currently most quality reporting activities rely heavily on claims data, which are an incomplete surrogate for the quality-of-care metrics sought by advocates, researchers, consumers, public agencies, commercial health plans, organizational providers, and clinical providers. Others rely heavily on manual data abstraction, which is time-consuming, expensive, and error-prone.

Healthcare processes, including quality measurement, are still generally oriented around the paper record, which has long-since outgrown its utility. Storing scanned images of paper documents in computer systems does not provide for interpretation or intelligent use of information content, such as for decision support and quality reporting. Neither do EHR systems, which accommodate narrative (text) data input over the capture of meaningful structured and coded clinical information.

Useful and ubiquitous quality measures data will depend upon meaningful clinical data that information systems can interpret and process. To leverage quality measures, provider systems must encourage the capture of clinical information as coded data or as structured data in nonproprietary usable formats, which may be easily mapped to HITSP standard terminologies and code sets.

Even after the NHIN quality use case efforts, it is clear that the domain of quality measurement and reporting is considerably immature compared to some of the NHIN sister use cases. The quality use case remains challenged with respect to interoperability standards that promote widespread adoption of quality measures for the use and sharing of quality measures data. However, as demonstrated at the NHIN forum, the QRDA work represents a significant advance for patient-level and population-level quality data exchange.

Although not demonstrated, a standardized expression of quality measures specifications, suitable for exchange and import into EHR systems, remains a pressing domain requirement. The Collaborative for Performance Measure Integration with EHR Systems released an updated and improved draft of its proposed quality measures exchange specification in October 2008. Relevant work in all these areas continues by many individuals and organizations to promote care improvement activities for patients, providers, health plans, communities, and the public health.

Randolph C. Barrows (rcbjr@hvc.rr.com) is an independent consultant in health information technology.


Article citation:
Barrows, Randolph C. Jr.. "Advancing Quality Measures Reporting in HIEs" Journal of AHIMA 80, no.4 (April 2009): 52-53;56.