1.0 Introduction

1.1 Interoperability Specification Overview

This Quality Interoperability Specification is designed to enable interoperable, electronic quality (eQuality) monitoring, providing selected standards for encoding the data types required for encoding an electronic quality measure. In this release of the Interoperability Specification, we provide the standards required to support the encoding of the initial set of quality measures selected by the Health Technology Expert Panel (HITEP) as well as the set of Stroke, Venous Thromboembolism (VTE), and Emergency Department (ED) measures provided to HITSP by the Centers for Medicare and Medicaid Services (CMS). The intent is to identify and exemplify the use of a method to interoperably encode a quality measure specification as well as clinical data routinely obtained during healthcare delivery that would be available for use in calculating the quality measure in the manner defined by the encoded quality measure specification.In so doing, our hope is that we can provide feedback to clinicians, administrators, policy makers and public health authorities for the purpose of improving the quality of healthcare provided to U.S. patients.

This Quality Interoperability Specification is based on a Use Case (formerly called Use Case) that assumes the presence of Electronic Health Records (EHRs) within the healthcare delivery system and promotes the development of longer-term efforts.

The Use Case models the exchange of information between the EHR and quality measurement, feedback and reporting systems. The Use Case allows for a hybrid model of data collection, where claims and or manual data collection will be used to support certain measures that are not fully supported through EHRs. This Use Case acknowledges the need to include a combination of claims and clinical (e.g., EHR) data. With more automation, EHR data could be extracted for patients to provide a richer measure set. However, the Use Case acknowledges that manual review and processing will continue to be required in many contexts and settings.

This Use Case does not attempt to prescribe a definitive approach to the location of data aggregation. The Use Case does describe roles for these processes which may be fulfilled in several different settings. The Use Case also does not describe harmonized quality measures. Federal, State, Local, and business policies will determine the initial and subsequent quality measures to be used. The data flows indicated are not intended to be comprehensive or limiting.

The Interoperability Specification is created to be architecture neutral. Patient level data analysis and aggregation may occur at the local care delivery locations, at an intermediate site, or at the location of the receiver of patient level quality data. It is expected that implementations will use the standards identified to accommodate any of these site-specific architecture requirements.

1.2 Document Scope

The design leverages existing HITSP constructs and communication methodologies. Additional communication methodologies are identified for consideration of enabling media and email-based communications of quality measures, validation reports, and patient level quality data. There is a significant variation in practice and insufficient standards to express measures and results, requiring significant harmonization and analytical effort to establish a consistent approach for the Interoperability Specifications. Therefore, the requirements have been scoped into releases to align with expected timelines of parallel efforts at standardization and harmonization in HL7, the Collaborative for Performance Measure Integration into EHRs, and the IHE Quality Domain. The work also specifically enables communication of three measure sets provided to HITSP by CMS: Stroke, VTE, and ED. The design is intended to enable electronic communication of patient level quality data. This effort will further inform requirements for structured specification of quality measures and aggregate report.

Due to gaps identified within this interoperability specification, further specification for capabilities for sending Aggregated Quality Measure Data is deferred until the associated standards gap is filled. Additional updates to this specification will require continued collaboration with the HITEP who will work with measure developers for standardization and greater completeness of measure specification.

1.3 Copyright Permissions

COPYRIGHT NOTICE

2009 ANSI. This material may be copied without permission from ANSI only if and to the extent that the text is not altered in any fashion and ANSIs copyright is clearly noted.

1.4 Conformance

This section describes the conformance criteria, which are objective statements of requirements that can be used to determine if a specific behavior, function, interface, or code set has been implemented correctly.

1.4.1 Conformance Criteria

For an implementation to claim conformance to a HITSP Interoperability Specification, it must be implemented in its entirety or within a limited scope or subset as defined within the Interoperability Specification, its associated construct specifications, as well as conformance criteria from the selected base and composite standards. A conformant system must be constrained as specified in this Interoperability Specification, and implement all of the required interfaces within the scope, subset or implementation options as described.

1.4.2 Conformance Scoping, Subsetting and Options

HITSP may define the permissibility for system scoping, subsetting or implementation options by which the specification may be implemented in a limited manner. The selected scope, subset or options shall specifically be stated, and implementations must include all requirements within the selected scope, subset or options to claim conformance.

For this Interoperability Specification, conformance may be declared by a participating system for any Capability provided that all declared constraints, conditions and requirements imposed by the Capability and its referenced HITSP constructs are satisfied.

1.4.3 Test Methods

HITSP relies on the conformance test methods, test tools and other test-related material produced by, or under the auspices, of standards developers, profiling organizations and implementation guide producers as part of its collaborative implementation testing effort. Efforts to produce conformance test methods, tools, etc. may be internal to the organization or provided by an external organization.

An HIT Implementaton Testing and Support website has been developed in collaboration with HITSP, NIST, CCHIT, and ONC to advance conformance and interoperability testing capabilities. This website provides HIT implementers with the necessary resources to support and test their implementation of standards-based health systems.