This page is part of the FHIR Specification (v1.4.0: STU 3 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

This draft of the CQIF IG is being balloted as the FHIR-Based Clinical Quality Framework (CQF-on-FHIR) as a comment-only ballot for the May 2016 ballot cycle. In addition, this IG will be used to support the SOA/CDS track in the May 2016 FHIR connect-a-thon.

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 for Health Information Technology (ONC) to harmonize standards for clinical decision support and electronic clinical quality measurement.

G.0.1 Introduction

The CQIF Implementation Guide describes a framework for health quality measurement and improvement using Fast Healthcare Interoperability Resources (FHIR). The IG covers a broad range of topics related to healthcare quality in both the decision support and quality measurement domains.

Topic	Description
Overview and Background	If you're interested in the background and development of the Clinical Quality Framework, this topic covers where it came from and why it exists.
Representing Knowledge Artifacts	If you want to represent knowledge artifacts such as Event-Condition-Action rules, Order Sets, or Quality Measures, start here.
Integrating Decision Support in a Clinical Workflow	If you want to see how to request and respond to clinical guidance, start here.
Sharing Knowledge Artifacts	If you want to distribute knowledge artifacts, start here.
Quality Reporting	If you want to define or report clinical quality measures, start here.

G.0.2 Background

The CQIF Implementation Guide is sponsored 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 disjointed 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

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 ongoing CQF initiative 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 patient data and clinical context using knowledge modules such as decision support artifacts and quality measures.

As such, this implementation guide references resources in the base specification, as well as defines profiles that support multiple use cases in the clinical quality improvement and measurement space. From the perspective of a Knowledge Author, this IG specifies the approach to representing knowledge artifacts within FHIR.

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 Service 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.3 Scope

This implementation guide focuses on several primary use cases:

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

The sharing use case is the focus of the Representing Knowledge Artifacts topic, which covers how to use the various types and resources defined within FHIR to represent computable knowledge artifacts such as Event-Condition-Action rules, Documentation Templates, Order Sets, and Quality Measures.

The evaluation use case is discussed in the next three topics, Integrating Decision Support in a Clinical Workflow, Using a Documentation Template in a Clinical Workflow, and Using an OrderSet in a Clinical Workflow, which cover how to use the various decision support artifacts in a clinical workflow.

The distribution use case is discussed in the Sharing Knowledge Artifacts topic, which covers how to use the Search Parameters defined for each of the resources to expose and retrieve knowledge artifacts.

And finally, Quality Reporting is covered in a separate topic focused on how to use the Measure and MeasureReport resources to define and report on quality measures.

G.0.4 Conventions

The keywords SHALL, SHOULD, MAY, NEED NOT, SHOULD NOT, and SHALL NOT in this document are to be interpreted as described in the HL7 Version 3 Publishing Facilitator's Guide.

• SHALL: an absolute requirement for the particular element. Where a SHALL constraint is applied to an XML element, that element must be present in an instance when the cardinality is greater than zero. Where a SHALL constraint is applied to an XML attribute, that attribute must be present, and must contain a conformant value.
• SHALL NOT: an absolute prohibition against inclusion
• SHOULD/SHOULD NOT: best practice or recommendation. There may be valid reasons to ignore an item, but the full implications must be understood and carefully weighed before choosing a different course
• MAY/NEED NOT: truly optional; can be included or omitted as the author decides with no implications

G.0.5 Related Specifications

The approach and representations within this guide are intended to be consistent with the following specifications:

• HL7 Version 3 Standard: Clinical Decision Support Knowledge Artifact Specification, Release 1.2
• HL7 Version 3 Standard: Representation of the Health Quality Measure Format (eMeasure) DSTU, Release 2
• HL7 Version 3 Standard: Decision Support Service, Release 2
• HL7 Version 3 Implementation Guide: Decision Support Service, Release 1

G.0.6 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 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.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 Acknowledgements

This implementation guide is the work of a joint project between the HL7 Clinical Quality Information and Clinical Decision Support Working Groups with the co-sponsorhip of the FHIR Infrastructure, Implementable Technology Specifications, and Service Oriented Architecture Work Groups. The project team was:

Project Facilitator/Editor	Bryn Rhodes	Database Consulting Group	bryn@databaseconsultinggroup.com
Project Facilitator/Editor	Jason Walonoski	The MITRE Corporation	jwalonoski@mitre.org
Editor	Marc Hadley	The MITRE Corporation	mhadley@mitre.org
Modeling Facilitator	Gay Dolin	Intelligent Medical Objects	gdolin@imo-online.com
Publishing Facilitator	Lloyd McKenzie	Gevity	lmckenzie@gevityinc.com
Domain Expert	KP Sethi	Lantana Consulting Group	kp.sethi@lantanagroup.com
Domain Expert	Chris Moesel	The MITRE Corporation	cmoesel@mitre.org
Domain Expert	Darrell Woelk	SocialCare	dwoelk@socialcare.com
Vocabulary Facilitator	Sarah Ryan	The MITRE Corporation	sarahryan@mitre.org
Vocabulary Facilitator	Rob McClure	MD Partners	rmcclure@mdpartners.com
Co-Chair	Crystal Kallem	Lantana Consulting Group	crystal.kallem@lantanagroup.com
Co-Chair	Patricia Craig	The Joint Commission	pcraig@jointcommission.org
Co-Chair	Floyd Eisenberg	iParsimony LLC	feisenberg@iparsimony.com
Co-Chair	Chris Millet	National Quality Forum	cmillet@qualityforum.org
Co-Chair	Walter Suarez	Kaiser Permanente	walter.g.suarez@kp.org
Co-Chair	Guilherme Del Fiol	University of Utah Health Care	guilherme.delfiol@utah.edu
Co-Chair	Ken Kawamoto	University of Utah Health Care	kensaku.kawamoto@utah.edu
Co-Chair	Robert Jenders	Charles Drew University/UCLA	jenders@ucla.edu
Co-Chair	Howard Strasberg	Wolters Kluwer Health	howard.strasberg@wolterskluwer.com