Introduction

This implementation guide documents and supports the use of a prototype Measure Calculation Tool for reporting and calculating FHIR-based digital quality measures (dQMs).

The Measure Calculation Tool is a software system that facilitates gathering quality reporting data, performing measure validation and calculation, and submitting reporting data for a provider. This process makes use of FHIR standard APIs implemented by vendor systems at provider sites, reducing the overall burden of quality reporting by eliminating the currently required transformation from proprietary data models to the conceptual model used for specifying eCQMs (Quality Data Model). By using FHIR as a standard data model for the expression of quality measures, quality reporting data exchange, measure calculation, and reporting submission can be implemented in a single standard way, rather than requiring each vendor system to interpret and apply measure specifications.

Use Case Overview

The following diagram illustrates the primary use case for the measure calculation tool: Reporting Submission

The participants in this use case are:

• Reporting Client: A prototype user-interface that demonstrates the reporting submission workflow
• Measure Calculation Tool: The measure calculation tool prototype as a RESTful web service
• Knowledge Repository: A measure repository providing measure specifications and data requirements features as described by the Measure Repository Service capability statement in the Quality Measure IG
• Terminology Service: A measure terminology service supporting terminology used by measures as described by the Measure Terminology Service capability statement in the Quality Measure IG
• Provider Site System: Clinical systems with patient data exposed via a US Core/QI Core compliant FHIR server
• Receiving System: Receiving system that receives the calculation and patient data submission as described by the Receiving System capability statement in the Data Exchange for Quality Measures IG

Overall, this use case consists of the following steps:

• Initiate: For the selected organization, measure, population, and reporting period, determine and retrieve specific data and terminology requirements
• Gather: For each facility and the population, gather the relevant data from the provider site systems
• Validate: For each gathered data element, validate the data is present and conforms to expected profiles
• Calculate: For each individual, as well as the population, calculate the relevant measure score and determine evaluated resources
• Submit: After reviewing any validation issues, submit the calculated score and relevant supporting data to the receiving system

For more detailed discussion of the use case and implementation, see the Technical Requirements topic.

Target Audience

The target audiences for this implementation guide are:

• Provider Implementer/IT Staff: Technical staff at provider organizations doing quality reporting. For this audience, this IG provides detailed technical documentation for the Measure Calculation Tool in the Technical Requirements Document, as well as step-by-step instructions for deploying and configuring the MCT for use at provider organizations.
• Provider Quality Administrator: Quality improvement specialists and officers at provider organizations doing quality reporting. For this audience, this IG providers overview and background information on the Measure Calculation Tool and how it can be used to facilitate quality reporting.
• Provider Reporting User: Quality improvement specialists at provider organizations doing quality reporting. For this audience, this IG provides overview and background information, as well as user-level documentation for how to use the Measure Calculation Tool to perform quality reporting tasks.

Contents

The main sections of this IG are:

• Background - provides business context for the implementation guide and information that implementers should be familiar with before reading the remainder of the IG
• Technical Requirements - documents the Measure Calculation Tool (MCT) system architecture and design and provides technical requirements, use cases, and supported user stories.
• Implementation Guide - Provides documentation of the use of the Measure Calculation Tool from a healthcare IT staff perspective
• User Guide - Provides documentation of the use of the Reporting Client from the reporting user perspective
• Test Plan - Describes the overall testing plan for both the development and verification of the prototype itself, as well as validation of the use of the prototype at a provider site
• Artifacts Index - An index of the technical artifacts made available as part of this implementation guide.
• License
• Changes
• Downloads - Allows downloading a copy of this implementation guide and other useful information

Glossary

• Application programming interface (API): A computing interface that can define interactions between multiple software intermediaries. An API can be customized to a specific component or industry standard for the purpose of ensuring interoperability.
• Bulk-FHIR: Bulk-FHIR is a standard for exchanging large volumes of FHIR resources between systems. It is designed to facilitate the bulk transfer of data, such as patient records, between healthcare organizations.
• Certified EHR Technology (CEHRT): A designation of EHR technology offering the necessary technological capabilities, functionalities, and security to meet predetermined requirements and give assurance to purchasers and other users. Certification helps health professionals and patients to have confidence that health IT products and systems can be used in a secure way, maintaining confidential data, and working in conjunction with other information systems. Requirements for CEHRT, in order to qualify for use in the Medicare and Medicaid Promoting Interoperability Programs, are set by CMS and ONC.
• Clinical Quality Language (CQL): The Clinical Quality Language (CQL) is a standardized language used to express clinical knowledge in a computable form. It is designed to facilitate the development of clinical decision support and quality measures.
• CQFramework: CQFramework is an open-source framework for developing clinical decision support systems (CDSS) and quality measures using the Clinical Quality Language (CQL).
• Data Element: A generic term describing some relevant data point for a particular purpose. In the context of quality measurement, this term refers specifically to the data points referenced by a quality measure such as a "Qualified Encounter"
• Digital data: Data that represents information using specific machine language systems that can be interpreted by various technologies (example: binary).
• Digital quality measure (dQM): Quality measures, organized as self-contained measure specifications and code packages, that use one or more sources of health information that is captured and can be transmitted electronically via interoperable systems. dQMs improve the patient experience including quality of care, improve population health, and reduce costs. Data sources for dQMs include administrative systems, electronically submitted clinical assessment data, case management systems, EHRs, laboratory systems, prescription drug monitoring programs (PDMPs), instruments (for example, medical devices and wearable devices), patient portals or applications (for example, for collection of patient-generated data such as a home blood pressure monitor, or patient-reported health data), health information exchanges (HIEs) or registries, and other sources.
• Docker Image: A Docker image is a lightweight, standalone, and executable package that contains all the necessary files, libraries, and dependencies to run an application. It is a snapshot of an application or service and can be used to deploy and run the application on any system that supports Docker.
• Electronic clinical quality measure (eCQM): A clinical quality measure expressed and formatted to use data from an electronic health record (EHR) to measure healthcare quality, ideally data captured in structured form during the process of patient care. For the eCQM to be reported from an EHR, the Health Quality Measure Format is used to format the eCQM content using the QDM to define the data elements and Clinical Quality Language (CQL) to express the logic needed to evaluate a provider or organization’s performance.
• Expression Logical Model: An Expression Logical Model (ELM) is a standardized format for expressing clinical knowledge in a computable form. It is used in the Clinical Quality Language (CQL) to represent clinical rules and logic.
• Fast Healthcare Interoperability Resources® (FHIR®): An interoperability standard for the electronic exchange of healthcare information. This standard was developed by Health Level Seven International (HL7®) as a draft for trial use to enable health IT developers to promote faster data exchange and retrieval. Learning health system: As defined by ONC in its Interoperability Roadmap, “an ecosystem where all stakeholders can securely, effectively and efficiently contribute, share and analyze data. A learning health system is characterized by continuous learning cycles, which encourage the creation of new knowledge that can be consumed by a wide variety of electronic health information systems. This knowledge can support effective decision-making and lead to improved health outcomes.”
• HAPI FHIR Service: HAPI FHIR (Fast Healthcare Interoperability Resources) is an open-source Java-based library and toolkit for building HL7 FHIR (Fast Healthcare Interoperability Resources) compliant applications. A HAPI FHIR service is a web service built using this library.
• Interoperability: refers to the ability of different healthcare information technology systems and devices to communicate, exchange data, and use the information that has been exchanged. Interoperability ensures that patient health information can be easily accessed and shared between healthcare providers, patients, and other stakeholders, regardless of the technology or platform they are using.
• Java Application: A Java application is a software program developed using the Java programming language. Java applications can run on a wide range of platforms, including desktop computers, servers, and mobile devices.
• Knowledge Repository: A measure repository providing measure specifications and data requirements features as described by the Measure Repository Service capability statement in the Quality Measure IG
• Maven: Maven is a build automation tool for Java projects. It provides a standardized way to manage project dependencies, compile source code, and package application artifacts for deployment. Maven uses a project object model (POM) to describe a project's configuration, including dependencies, plugins, and build profiles. It also provides a set of standard project structures and lifecycle phases that can be customized to suit the needs of different projects.
• Measure calculation tool (MCT): A tool that maps the quality measure criterion to the corresponding API endpoint and aggregates the data to perform the requested analysis. Such a tool could be housed within individual provider EHRs, developed and maintained by external health IT vendors, and/or run by CMS for the purpose of quality measurement. Open-core software: a platform with a standard core architecture available for use under an opensource license supporting an ecosystem of offerings of additional proprietary, closed source add-on functionalities, and services that are not required.
• Population health: An approach utilizing non-traditional partnerships among various sectors of the community: public health, industry, academia, healthcare, local government entities, etc. to achieve positive health outcomes. It is also the intersecting and overlapping factors that influence health such as environment, education, mobility, policy and governance, socioeconomic status, race, infrastructure, access to technology, and urban planning.
• Quality Improvement (QI) Core Implementation Guide: A guide based on FHIR that defines a set of profiles with extensions and bindings needed to create interoperable, quality-focused applications. The profiles in this implementation guide derive from and extend the US Core profiles to provide a common foundation for building, sharing, and evaluating knowledge artifacts across quality improvement efforts in the US Realm.
• ReactJS: ReactJS, or simply React, is an open-source JavaScript library for building user interfaces. It is often used in web development to create dynamic, interactive, and responsive user interfaces. React allows developers to build reusable UI components and manage the state of an application in a declarative and efficient way. React is widely used in the development of single-page applications and is known for its high performance and ease of use.
• REST: REpresentational State Transfer is an architectural style for distributed hypermedia systems, and is the industry standard architecture for web-based services and systems.
• Service-oriented architecture: As defined by ONC in its Interoperability Roadmap, “Service-oriented architecture is based on distinct pieces of software providing application functionality as services to other applications via a protocol. Depending on the service design approach taken, each service-oriented architecture service is designed to perform one or more activities by implementing one or more service operations. As a result, each service is built as a discrete piece of code. This makes it possible to reuse the code in different ways throughout the application by changing only the way an individual service interoperates with other services that make up the application, versus making code changes to the service itself. Service-oriented architecture design principles are used during software development and integration.”
• Spring Boot: Spring Boot is an open-source Java-based framework for building standalone, production-ready applications. It provides a set of pre-configured components and tools that streamline the application development process.
• Standards: refer to a set of established guidelines, specifications. Standards are designed to ensure consistency, quality, safety, and interoperability in the development, implementation, and use of products, services, or technologies.
• Terminology Service: A measure terminology service supporting terminology used by measures as described by the Measure Terminology Service capability statement in the Quality Measure IG
• CMS Certification number (CCN): replaces the term Medicare Provider Number, Medicare Identification Number or OSCAR Number. The CCN is used to verify Medicare/Medicaid certification for survey and certification, assessment-related activities and communications.
• United States Core Data for Interoperability (USCDI): A standardized set of health data classes and constituent data elements for nationwide, interoperable health information exchange. United States Core Data for Interoperability Plus (USCDI+): A new initiative established by ONC to support the identification and establishment of domain or program-specific datasets that will operate as extensions to the existing USCDI. In particular, USCDI+ is a service that ONC will provide to federal partners who have a need to establish, harmonize, and advance the use of interoperable datasets that extend beyond the core data in the USCDI in order to meet agency-specific programmatic requirements. US Core Implementation Guide (US Core IG): A guide based on FHIR Version R4 that defines the minimum conformance requirements for accessing patient data. This guide is based on the USCDI requirements.
• Use Case: A use case is a description of how a user interacts with a system to achieve a specific goal or outcome. It outlines the steps involved in the user's interactions with the system and the expected results.
• User Interface (UI): A user interface is the means by which a user interacts with a computer system or application. It encompasses all the visual and interactive elements of an application, including buttons, menus, forms, and text.
• Yarn: Yarn is a package manager for Node.js-based applications. It provides a more efficient and reliable way to manage dependencies than the built-in npm package manager. Yarn uses a deterministic algorithm to ensure that each time a package is installed, the same dependencies and versions are installed, regardless of the system on which it is installed. This helps to ensure consistency and reduce the likelihood of compatibility issues.

Acknowledgements

This implementation guide and the prototype Measure Calculation Tool were made possible by the thoughtful contributions of many individuals, including:

• Chris Schuler, Developer, Smile Digital Health
• Dewar Tan, Developer, Vermonster
• Josh Reynolds, Knowledge Engineer, Smile Digital Health
• Emily Bancroft, Project Coordinator, Smile Digital Health
• Bryn Rhodes, Editor, Smile Digital Health
• Iman Simmonds, Project Manager, Yale New Haven Health
• Kate Wright, Project Manager, Yale New Haven Health
• Anne Weinstein, Program Lead
• Brooke Villareal, Associate Director, Digital Product Development
• Faseeha Altaf, Division Lead, Digital Product Development
• Matthew Saenz, Research Support
• Kerry McDowell, Project Manager
• Tom Lantz Senior Program Technical Advisor
• Bridget Calvert Senior dQM Implementation Lead
• Joel Andress Senior dQM Program Lead
• Bill Lakenan ADO
• Reid Kiser DQM Division Director R
• Mark Canfield Division Deputy Director
• Michellene Roberts HQR Program Lead
• Mindy Riley Division Director
• Andrew Fulks Principal Engineer, eSimplicity
• Kevin Carr, Strategic Advisor
• Larnie Uson, QAD
• Patrick O'Keefe, Operational Functional Advisor
• Joel Montavon, Technical Functional Advisor
• Julette Van Vuuren, Creative Director
• Amber Ownes, Project Manager
• Kaliko Zabalo-Moore, Project Coordinator
• Jason Cipriano, Technical Editor
• Shawn Baugess, Graphic Design Lead
• Aileen Ballacillo, Tool Administrator
• David Yule, Agile Expert

References

• Quality Measure Development
• Health Level 7 Fast Healthcare Interoperability Resources (FHIR) R4
• US Core Profiles (STU 3.1.1)
• QI Core Profiles (STU 4.1.1)
• Clinical Quality Language N1
• Quality Measure Implementation Guide STU 3
• Data Exchange for Quality Measures Implementation Guide STU3