DSTU2 QA Preview

This page is part of the FHIR Specification (v1.0.0: DSTU 2 Ballot 3). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions

G.0 Clinical Quality Improvement Framework (CQIF) Implementation Guide

In September 2015, this FHIR Implementation Guide will undergo a comment-only ballot. The focus of the ballot is limited in scope to the IG, the profiles, operations, value sets, and conformance statements it defines. This implementation Guide will be balloted separately from the FHIR specification itself.

G.0.1 Table of Contents

Table of Contents

G.0.2 Summary

This Implementation Guide is prepared as a Universal Realm Specification with support from the Clinical Quality Framework (CQF) initiative , which is a public-private partnership sponsored by the Centers for Medicare & Medicaid Services (CMS) and the U.S. Office of the National Coordinator (ONC) to harmonize standards for clinical decision support and electronic clinical quality measurement.

The CQIF Implementation Guide provides profiles and operation definitions to enable multiple quality-related use cases, including decision support request/response, quality measurement evaluation, as well as knowledge artifact representation and sharing.

G.0.3 Background

The CQIF Implementation Guide is built by the Clinical Decision Support (CDS) and Clinical Quality Information (CQI) HL7 Work Groups, with input and coordination from the FHIR Infrastructure and Service Oriented Architecture HL7 Work Groups.

The Clinical Quality Framework initiative has focused on harmonizing the historically disjoint specifications used by the Clinical Quality Measurement and Clinical Decision Support communities. Specifically, the initiative has focused on the specifications used to represent knowledge artifacts within the two communities. The strategy employed has been to break the conceptual content of knowledge artifacts into three core components:

  • Metadata - Descriptive information about the artifact and its content
  • Clinical Information - The representation used to carry clinical information about the patient or population of concern within a given artifact
  • Logic - The representation used to convey the logic involved in the artifact
Clinical Quality Framework Conceptual Components

The first component has resulted in the Clinical Quality Common Metadata Conceptual Model , an informative document harmonizing metadata requirements between Quality Measurement and Decision Support artifacts.

The second component has resulted in the QUICK Conceptual and Logical Models, a harmonization of the Virtual Medical Record (vMR) used in Decision Support and the Quality Data Model (QDM) used in Quality Measurement, and realized in FHIR as the QICore profiles.

And finally, the third component has resulted in the Clinical Quality Language Specification , a harmonization of the expressive capabilities of the Clinical Decision Support Knowledge Artifact Specification (CDS KAS) (produced by the Health eDecisions (HeD) S&I Framework Initiative), and the Health Quality Measures Format (HQMF) .

As part of the CQF initiative Phase II Pilot efforts, these developing specifications are being used to support knowledge artifact sharing, as well as evaluation of knowledge artifacts as part of decision support request/response and measure evaluation.

This implementation guide continues the harmonization of quality domain specifications by defining an approach to using a FHIR server as a component of a knowledge system in one of two roles:

  1. Knowledge Repository - As a knowledge artifact repository for sharing and distributing knowledge artifact definitions
  2. Knowledge Service - As a knowledge service providing for the evaluation of knowledge modules such as decision support artifacts and quality measures.

As such, this implementation guide defines profiles that support multiple use cases in the clinical quality improvement and measurement space. From the perspective of a Knowledge Author, this IG defines profiles to support the definition of knowledge artifacts, as well as profiles for exposing existing CDS KAS artifacts.

From the perspective of a Knowledge Content Provider, this IG defines search functionality for using a FHIR server as a knowledge artifact repository.

From the perspective of a Knowledge Service Provider, this IG defines operations and profiles in support of evaluating quality measures, and defining a service for guidance request and response, consistent with the approach taken by the current Decision Support Specification.

And finally, from the perspective of a Knowledge Service Consumer, this IG defines the expected available operations and behavior of a knowledge service.

G.0.4 Scope

The CQIF Implementation Guide currently focuses on the Decision Support aspects of the Clinical Quality domain. However, this IG has been developed in coordination with the Clinical Quality Information Work Group sponsored project to build FHIR representations for Clinical Quality Measures. As a result of that coordination, many of the profiles defined in this implementation guide are shared by that effort. The scope of this implementation guide therefore broadly falls into two categories:

The common aspects include profiles for defining quality evaluation request/response protocols, as well as representation of knowledge modules generally. The Decision Support-specific aspects then build on those profiles to define guidance request/response protocols, and representation of Decision Support-specific artifacts including rules, order sets, and documentation templates.

This implementation guide focuses on several primary use cases:

  • Sharing - The representation of computable, shareable knowledge artifacts
  • Evaluation - The evaluation of knowledge artifacts with respect to a particular patient or population
  • Distribution - Functionality required to enable a searchable artifact repository

G.0.5 Ballot Objectives

For this ballot cycle, we are presenting this implementation guide as a comment-only ballot with the objective of gathering community feedback. We welcome any comments, criticisms and suggestions on any topic, but in particular, we seek feedback on the following areas:

  • The representation of knowledge modules in general, and decision support artifacts in particular. The guide is constructed to allow knowledge modules to be represented either as potentially generated wrappers around existing specifications such as the Clinical Decision Support Knowledge Artifact Specification, or as first-class FHIR structures modeling the artifact content (such as order set items and rule actions) directly. Clearly there are pros and cons to both approaches; we seek community feedback on the preferred direction, or whether both options should continue to be supported.
  • The mechanisms used for referencing logic from within knowledge artifacts. In particular, the use of the "content" element to allow Clincal Quality Language and Expression Logical Model content to be attached directly, versus requiring such content to be addressed through a library reference.
  • The use of FHIR operations as the protocol for defining artifact evaluation requests and responses. In particular, the ability to bundle multiple requests into a single operation, as well as the use of a generic FHIR operation for any module evaluation, versus defining an evaluation specific to a given knowledge module.
  • The use of FHIR interactions in general as a mechanism for enabling knowledge module repository and distribution functionality.

G.0.6 Known Issues

At the time of this ballot, there are several issues outstanding that prevented some material from being included. The following list details these known issues:

IssueDescription
Coverage element The KnowledgeModule structure should contain a "coverage" element that allows categorized topics to be represented in the same way that coverage is modeled within the Clinical Decision Support Knowledge Artifact Specification. There is an issue with the knowledge module profile definition that prevents it from being included. See the Suicide Risk Order Set Example for an example of coverage elements included in a knowledge module.
Data Requirements Filters The data extension used to define data requirements within a knowledge module should contain a "codeFilter" element to allow the expression of terminology restrictions on data requirements, as well as a "dateFilter" element to allow the expression of date-based restrictions on data requirements. There is an issue with the knowledge module profile definition that prevents these elements from being included. See the Knowledge Module Library Example for an example of a data requirement with a code filter applied.
Action Customization Expression The action extension has a customization element that is supposed to contain a path and an expression, but only contains a path. For an example of an action with a customization expression defined, see the Respiratory Protocol Orderset Example.
Action Subelements The action extension is supposed to contain an "actions" element that allows each action to contain any number of sub-actions. For an example of actions with subelements defined, see the Suicide Risk Order Set Example.
Missing Examples Several of the examples could not be included in the build because they will not validate for various reasons. Specifically, a Suicide Risk Order Set, and the Guidance Request/Response examples for the guidance operation.

G.0.7 Copyright Information

This material includes SNOMED Clinical Terms ® (SNOMED CT®), which are used by permission of the International Health Terminology Standards Development Organization (IHTSDO). All rights reserved. SNOMED CT was originally created by The College of American Pathologists. "SNOMED ®" and "SNOMED CT ®" are registered trademarks of the IHTSDO.

This material contains content from LOINC® (http://loinc.org ). The LOINC table, LOINC codes, and LOINC panels and forms file are copyright © 1995-2011, Regenstrief Institute, Inc. and the Logical Observation Identifiers Names and Codes (LOINC) Committee and available at no cost under the license at http://loinc.org/terms-of-use .

This material contains content from the Unified Code for Units of Measure (UCUM) (http://unitsofmeasure.org ). The UCUM specification is copyright © 1999-2013, Regenstrief Institute, Inc. and available at no cost under the license at http://unitsofmeasure.org/trac/wiki/TermsOfUse .

This material contains quality measure content developed by the National Committee for Quality Assurance (NCQA). The measure content is copyright (c) 2008-2013 National Committee for Quality Assurance and used in accordance with the NCQA license terms for non-commercial use.

G.0.8 Author Information

Author Name
Bryn Rhodes
Jason Walonoski
Marc Hadley
Lloyd McKenzie (Supporting)
Chris Moesel (Supporting)