9.1 Introduction
The purpose of this section is to guide measure developers on how to develop and document
eMeasure specifications for either an adapted (retooled) measure or a new (de novo) measure. Final technical specifications should be detailed and concise, and provide the comprehensive details that allow the measure to be collected and implemented consistently, reliably, and effectively. The process of developing eMeasure specifications occurs throughout the measure development process. In the information gathering stage, the measure contractor identifies whether existing measures may be adapted/retooled to fit the desired purpose. If no measures are identified that match the desired purpose for the measure, the contractor must work with its technical expert panel (TEP) to develop new measures. Depending on the information gathering findings, the TEP will consider potential measures that are newly proposed or are derived from existing measures. The measure contractor submits the list of candidate measures, selected with TEP input, to the Centers for Medicare & Medicaid Services (CMS) Contracting Officer Representative/Government Task Leader (COR/GTL) for approval. Upon approval from the COR/GTL, the measure contractor proceeds with the development of detailed technical specifications for the measures.
The detailed process for development of a de novo measure is outlined in the preceding Blueprint sections. Contractors are expected to follow these procedures, which often include special
considerations for eMeasures. Where the process deviates from the way other types of measures are developed, it is denoted with the following icon (scaled to fit the text):
Figure 9-1 eMeasure icon denoting special considerations for eMeasures in the Blueprint.
Developing eMeasure specifications is an iterative process. A brief overview of this process is as follows.
1. Prior to drafting initial eMeasure specifications, the measure contractor should consider the data elements necessary for the proposed measure, and conduct preliminary feasibility assessments to confirm availability of the information within a structured format within the electronic health record (EHR). This will better ensure that a developed measure passes feasibility assessments during beta (field) testing. (Refer to the Measure Testing section.) 2. The measure contractor then drafts the initial specifications. The TEP will review and advise the
measure contractor of the recommended changes. (Refer to the Technical Expert Panel section.)
3. If directed by the COR/GTL, public comments may be obtained regarding the draft measures. (Refer to the Public Comment section.) Comments received during the public comment period
will be reviewed and taken into consideration by the measure contractor, CMS, and the TEP. This often results in revisions to the measure specifications.
4. During the development process, alpha (formative) testing of the measure occurs. (Refer to the Measure Testing section.)
5. When the specifications are more fully developed, beta (field) testing occurs. (Refer to the Measure Testing section.) As a result, technical specifications will continue to evolve and become more detailed and precise.
6. After measure testing is complete, obtain additional public comments using the formal process outlined in the Public Comment section. All of these factors will enhance the technical
specifications and make the measure more valid and reliable. Figure 9-2 illustrates the inputs to the process
Figure 9-2 Factors Influencing the Development of the Measure Technical Specifications
eMeasures, derived from Clinical Quality Measures for electronic capture, will be authored in the National Quality Forum (NQF)-developed Measure Authoring Tool (MAT). This section is a conceptual guide to eMeasure specifications development, intended to be used in conjunction with the tool and the tool's user guide. Consistency in the representation of all eMeasures used in CMS programs requires that measure developers follow the guidance in this document and adhere to the tool's user guide. The Measure Authoring Tool’s output is designed so that the contractor may submit the completed eMeasure to NQF for endorsement if desired.
As further described in this section, eMeasures are written to conform to the Health Quality Measures Format standard (HQMF), published in 2010 as a Health Level Seven (HL7) Draft Standard for Trial Use (DSTU). A DSTU is a draft standard, issued at a point in the standards development lifecycle when many but not all of the guiding requirements have been clarified. A DSTU is intended to be tested and
Technical Specifications TEP Alpha Testing Public Comment Literature Review Existing Measures CMS Beta Testing Measure Contractor
ultimately taken back through the HL7 ballot process, to be formalized into an American National Standards Institute (ANSI)-accredited standard.
To ensure consistency in the eMeasure development process, CMS convenes an ongoing eMeasures Issues Group (eMIG) meeting where new requirements can be vetted. The eMIG serves as a forum to discuss and propose solutions for issues encountered during the development of eMeasures. A
fundamental activity of the eMIG is to develop additional guidance for issues encountered by measure developers. Solutions proposed and presented at the eMIG meetings are expected to address areas where common standards or approaches have not yet been specified, or where the Blueprint for the CMS Measures Management System does not supply guidance. This ever-expanding body of
information discussed in the eMIG will be incorporated into the Blueprint guidance provided to
developers. Measure developers should contact a member of the CMS Measures Management System team at [email protected] for inclusion in these regularly scheduled eMIG meetings.
CMS anticipates that a final ANSI-accredited eMeasure standard may represent certain constructs differently than the way they are represented through the NQF-developed Measure Authoring Tool or the supplemental CMS eMeasure editorial guidelines. Such differences will be published in parallel with the ANSI standard. For now, measure developers need to be knowledgeable of this section, the Measure Authoring Tool's user guide, and the eMIG recommendations. When in doubt, measure developers should consult with their COR/GTL. Given the evolving nature of Health Information Technology (HIT) standards, this Blueprint section will be reviewed on an ongoing basis and updated quarterly as changing standards necessitate.
A fully constructed eMeasure is an XML document. It can be viewed in a standard web browser, when associated with an eMeasure rendering style sheet supplied by CMS. Exports of an eMeasure from the MAT include the eMeasure XML file, and the eMeasure style sheet.
9.2 Deliverables
eMeasure XML file eMeasure style sheet
Measure Justification form (required only for de novo eMeasures and located in the Measure Development section)
9.3 Health Quality Measures Format
A health quality measure (or clinical quality measure) encoded in the Health Quality Measures Format is referred to as an “eMeasure.” eMeasure is an HL7 standard for representing a health quality
measure as an electronic XML document. Through standardization of a measure’s structure, metadata, definitions, and logic, the HQMF provides for quality measure consistency and unambiguous
interpretation. HQMF is a component of a larger quality end-to-end framework in which providers will ideally be able to push a button and import these eMeasures into their Electronic Health Records (EHRs). The eMeasures can be turned into queries that automatically gather data from the EHR's data
repositories and generate reports for quality reporting. From there, individual and/or aggregate patient quality data can be transmitted to the appropriate agency.
Major components of an HQMF document include a Header and a Body. The Header identifies and classifies the document and provides important metadata about the measure. The HQMF Body contains eMeasure sections, e.g., data criteria, population criteria, and supplemental data elements. Each section can contain narrative descriptions and formally encoded HQMF entries.
To aid in the creation of an eMeasure, NQF has developed a Measure Authoring Tool.1 The authoring tool uses a graphical user interface (GUI) to guide measure developers through the measure authoring process to create an eMeasure. The tool hides much of the complexity of the underlying HQMF from the developer. This section of the Blueprint assumes that measure developers will be using the authoring tool, and describes the eMeasure authoring process from that perspective. When seeking NQF endorsement for an eMeasure, it is important to note that the preferred submission format is based on MAT output.
eMeasure is one component of a larger quality framework. When measures are unambiguously represented as eMeasures, they can be used to guide collection of EHR and other data, which is then assembled into quality reports and submitted to organizations such as CMS. The transmission format (i.e., the interoperability specification that governs how the individual or aggregate patient data is to be communicated to CMS) is another important component of the quality framework. Developing the transmission format along with an eMeasure maximizes internal consistency.
9.4 National Quality Forum Quality Data Model
The Health Information Technology Expert Panel (HITEP), a committee of content experts convened by NQF, created the Quality Data Model (QDM, formerly referred to as Quality Data Set or QDS).2 The QDM is an information model that defines concepts that recur across quality measures and clinical care and is intended to enable automation of EHR use. The QDM contains six components: (1) QDM
element—an atomic unit of information that has precise meaning to communicate the data required within a quality measure), (2) category—a particular group of information that can be addressed in a quality measure, (3) state—context expected for any given QDM element, (4) taxonomy—standard vocabulary or other classification system to define a QDM element’s category, (5) value set—used to define an instance of a category , and (6) attribute—specific detail about a QDM element. A QDM element is specified by selecting a category, the state in which the category is expected to be found with respect to electronic clinical data, a value set from an appropriate taxonomy (or vocabulary) , and all required attributes. For example, defining a value set for diabetes and applying the category, diagnosis, and the state “active” forms the QDM element, active diabetes diagnosis, as a specific instance for use in a measure.
1https://mat.qualityforum.org/Login.html 2
9.5 Building Block Approach to eMeasures
NQF has developed a building-block approach to develop eMeasures. This approach, built into the NQF-developed authoring tool, takes each category-state pair (e.g., active diagnosis) in the QDM and represents it as a reusable pattern. Coupled with a value set (e.g., SNOMED CT, ICD 10 CM and ICD9 CM, codes for pneumonia), a quality pattern becomes a QDM element representing an HQMF data criterion (e.g., “active diagnosis of pneumonia”). Data criteria are assembled (using Boolean and other logical, temporal, and numeric operators) into population criteria (e.g., “Denominator = active
diagnosis of pneumonia, AND age > 18 at time of hospital admission”), thereby creating a formal representation of a quality measure that can be processed by a computer.
Thus, at a high level, the process of creating an eMeasure is to map measure data elements to the correct category-state pairs in the QDM, associate each category-state pair with the correct value set(s) to create data criteria, and then assemble the data criteria into population criteria.
9.6 Measure Authoring Tool
As described above, NQF has developed a web-based Measure Authoring Tool, a software authoring tool that measure developers use to create eMeasures. The authoring tool allows measure developers to create their eMeasures in a highly structured format using the QDM and healthcare industry
standard vocabularies.3
The QDM is labeled version 2.1.1.1, in the January 2012 release of the MAT, which is also the version cited under Meaningful Use Stage 2.
The Measure Authoring Tool does not require measure developers to have an extensive knowledge of the HQMF standard. It is based on the QDM and the building-block approach to creating eMeasures. It supports common-use cases and the existing patterns in the pattern library. The Measure Authoring Tool will require ongoing maintenance and support to meet any future measure authoring needs. For instance, if a measure requires a new category-state pair and therefore a new corresponding quality pattern, the pattern must first be developed and then added to the Measure Authoring Tool.
9.7 Procedure
When retooling or developing a new eMeasure, the developer should use the process outlined in the following figure and detailed in the sections that follow. Dashed boxes are only required under certain circumstances.
3
Figure 9-3 eMeasure Specifications and Transmission Format Development Process
Determine final list
of measures Perform preliminary feasibility assessment Define metadata Define data criteria Map to QDM Define/Reuse Value Sets Data population
criteria Author narrative
Define Measure Observations Define reporting stratification Define supplemental data elements Define transmission format Document the measure and obtain COR/GTL approval
Complete measure testing
Submit measure to NQF for endorsement
Author narrative
Author narrative
Author narrative
Step 1: Determine final list of measures (and perform preliminary feasibility
assessment)
Based on the environmental scan, measure gap analysis, and other information gathering activities, the measure contractor submits the list of candidate measures—selected with TEP input—to the COR/GTL
for approval. These measures may be retooled or de novo. Before deciding to retool a measure, consider the following issues.
If the existing measure is NQF-endorsed, are the changes to the measure significant enough to require resubmission to NQF for endorsement?
Will the measure owner be agreeable to the changes in the measure specifications that will meet the needs of the current project?
If a measure is copyright protected, are there issues relating to the measure’s copyright that need to be considered?
These considerations must be discussed with the COR/GTL and the measure owner, while NQF endorsement status may need to be discussed with NQF. Upon approval from the COR/GTL, the measure contractor proceeds with the development of detailed technical specifications for the measures using the NQF-developed MAT.
Prior to drafting initial eMeasure specifications, the measure contractor should consider the data elements necessary for the proposed measure, and conduct preliminary feasibility assessments (alpha testing) to confirm availability of the information within a structured format within the electronic health record. This will better ensure that a developed measure passes feasibility assessments during beta (field) testing. (Refer to the Measure Testing section).
Step 2: Define metadata
The Header of an eMeasure document identifies and classifies the document and provides important metadata about the measure. eMeasure metadata are summarized in Table 9-1 listing elements in the order that they are conventionally displayed.
The eMeasure Header should include the appropriate information for each element as described in the Definition column of Table 9-1. The default for each element in the Measure Authoring Tool is a blank field, but all header fields need to have an entry. The Preferred Term column indicates how the developer should complete entry into the MAT. “Required” means that the measure developer must populate the metadata element field as defined in column 2. All eMeasure header fields must have information completed OR placement of a “None” or “Not Applicable” in the header field. Conventions for when to use “None” versus “Not applicable” have been described for each metadata element and should be entered according to Preferred Term column instructions (e.g., measures not endorsed by NQF should populate the metadata element NQF Number with “Not Applicable”).