Skip to end of metadata
Go to start of metadata

Publication Request

Publication Request

1. Published Name of the Standard for which request is being made

QI-Core Implementation Guide: STU 3.2 (v3.2.0 for FHIR 3.0.1)

2. Standards Material/Document

STU Extension

3. Date of Request

Jun 12, 2020

4. Use Period

5. Reason for extension, timeline, and actions

QI-Core Implementation Guide STU 3.2 (v3.2.0 for FHIR 3.0.1) is still in use for testing eCQMs with implementers currently using FHIR STU 3. The extension will allow continued work as implementers move to FHIR R4 and R4.1.

6. Original Publication Date

Apr 14, 2019

7. End date of the current STU period

Jun 04, 2020

8. Length of the requested extension

2 years

9. Review Process

10. HL7 Work Group making this request and date


10a. Requesting WG Date

Jun 12, 2020

11. URL of approval minutes

12. HL7 Product Management Group


12a. Management Group Date of Approval

Jun 24, 2020

13. URL of approval minutes

14. Is the artifact ready for final publication?


15. If not ready, please describe remaining steps.

16. Tool name used to produce the machine processable artifacts in the IG

17. The name of the “IG artifact” within the context of the above mentioned tool.

18. Balloted Name of the standard for which request is being made

19. Requested name for published standard

20. If CMET, list IDs balloted

21. Project Insight Number


22. Document Realm

US Realm

23. Ballot cycle in which the document was successfully balloted

2017 JAN

24. Results of that ballot (following reconciliation activities):

24. Results of that ballot (following reconciliation activities):

(not needed for errata, STU extension, or unballoted STU update)

25. Affirmative

26. Negative

27. Abstentions

28. Not Returned

29. Total in ballot pool

30. Date on which final document/standards material was supplied to HQ

31. URL of publication material/ SVN repository

32. Publishing Facilitator

Bryn Rhodes

33. Special Publication Instructions

34. URL of ballot reconciliation document

35. Has the Work Group posted its consideration of all comments received in its reconciliation document on the ballot desktop?

36. Substantive Changes Since Last Ballot?

37. Product Brief Reviewed By


38. Date Product Brief Reviewed

Jun 05, 2020

39. Has the Product Brief changed?


Product Brief

Product Brief

40. Family


41. Section

Implementation Guides

42. Topic

Clinical Quality

43. Please Describe the Topic

44. Product Type

Implementation Guide

45. Parent standard


46. Parent Standard Status

Move to Stable

47. Update/replace standard

Extension to accommodate implementations still using FHIR STU 3

48. Common name/search keyword

"HL7 FHIR(®) Profile: Quality, R1", QICore

49. Description

The QI Core Implementation Guide defines a set of FHIR 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.

As an HL7 FHIR Implementation Guide, changes to this specification are managed by the sponsoring workgroup, Clinical Quality Information, and incorporated as part of the standard balloting process. The current roadmap follows closely behind the base FHIR roadmap, and the US Core Implementation Guide.

This STU update to the QI-Core profiles incorporates updates to the US-Core profiles, version 2.0.0. Specifically, it changes the QICore-Encounter and QICore-PractitionerRole profiles to be derived from the new USCore-Encounter and USCore-PractitionerRole profiles, rather than directly from the base resources, as well as changes the QICore-Coverage profile type element to bind to the SOP Payer value set.



These are categories of potential users, implementers, or other interested parties such as those that are indicated on the Project Scope Statement under “Stakeholders/Vendors/Providers”. Select those that are applicable, or suggest others:

50. Stakeholders

Quality Reporting Agencies, Regulatory Agency, Standards Development Organizations (SDOs), Payors

51. Vendors

EHR, PHR, Health Care IT, Clinical Decision Support Systems

52. Providers

Healthcare Institutions (hospitals, long term care, home care, mental health)

53. Benefits

Encourages consistent access and use of data for clinical quality applications, across organizations and between healthcare systems
Provides guidance for consistent use of vocabularies and value sets
Standardizes the requirements for data servers and data consumers (clients) that exchange quality-related clinical data needed for calculation of quality measures and decision support

54. Implementations/Case Studies

Centers for Medicare and Medicaid Services (CMS) and Office of the National Coordinator for Health Information Technology (ONC)
National Committee for Quality Assurance (NCQA) (Draft HEDIS measure guidance)

55. Development Background

This Implementation Guide originated as a U.S. Realm Specification with support from the Clinical Quality Framework (CQF) initiative, which was 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 Clinical Quality Framework effort transitioned to HL7's Clinical Quality Information (CQI) and Clinical Decision Support (CDS) Work Groups in 2016. The HL7 CQI Work Group maintains this Implementation Guide, co-sponsored by the Clinical Decision Support (CDS) HL7 Work Group to inform electronic clinical quality improvement (i.e., measurement and decision support). This Quality Improvement Core (QICore) Implementation Guide is intended to be usable for multiple use cases across domains, and much of the content is likely to be usable outside the U.S. Realm.

In the U.S. Realm, the common reference model for electronic clinical quality measures (eCQMs) is the Quality Data Model (QDM). For clinical decision support, a common reference model is the HL7 Virtual Medical Record for Clinical Decision Support(vMR). Decision support and quality measures are closely related, and can be viewed as "two sides of the same coin". Specifically, decision support provides guidance for clinical best practices, and quality measures assess whether clinical best practices have been followed. It therefore makes intuitive sense to use the same common reference model for both types of applications.

The resulting unified model is known as QUICK. QUICK is a logical model consisting of objects, attributes, and relationships. QUICK provides a uniform way for clinical decision support and quality measures to refer to clinical data. Authors of quality measures and clinical decision support artifacts may use QUICK, together with HL7's Clinical Quality Language (CQL), to create interoperable and executable knowledge artifacts.

This project is part of an effort to align the HL7 Product Family in the area of health quality improvement. The goal is to have a single logical data model (QUICK), as well as a single logical processing language (CQL), for CDS and clinical quality measurement (CQM). This alignment will lessen the cost and complexity for product developers and vendors, reduce the learning curve, and consolidate efforts to maintain multiple standards.