Short Description: Continue the testing and use of FHIR-based Quality Measures for use in Quality Measurement programs, including CMS and Clinical Decision Support (CDS) Use Cases. 

Long Description: By hosting the clinical reasoning track, we hope to achieve the following objectives: 

  1. Continue testing Quality Measurement use cases.
    1. Evaluate FHIR-based eCQMs written with CQL.
    2. Test eCQM structure, packaging, and reference libraries from draft MAT on FHIR export packages.
    3. Test and validate the use of the QI-Core model in CQL authoring.
    4. Test supplemental data use cases for eCQMs.
    5. Test continuous variable and stratified eCQMs.
  2. Test the use of FHIR resources in alignment with FHIR R4 Implementation Guides (IG).
    1. QI-Core IG.
    2. Quality Measure IG.
    3. Data Exchange for Quality Measures (DEQM) IG.
  3. Test FHIR Clinical Guidelines example content (in coordination with the Care Planning and Public Health tracks).
  4. Test the new `order-select` hook using CDC Opioid Prescribing (in coordination with the CDS Hooks track).

  5. Conduct end-to-end testing: identify a gap, close gap and report measure, specifically Breast Cancer Screening--CMS 125v8 or v9 (in coordination with the DaVinci DEQM Gaps in Care track)
  6. Continue investigation of bulk import support.

  7. Test the ExecutableLibrary profile.

  8. Test the following CMS Measures for R4

Eligible Professional (EP)/Eligible Clinician (EC) Measures
2019 Reporting Measures

2020 Reporting Measures

2021 Reporting Measures

Other Measures for Consideration

  • CMS130v7: Colorectal Cancer Screening
  • CMS125v7: Breast Cancer Screening
  • CMS165v8: Controlling High Blood Pressure
  • CMS349v2: HIV Screening
  • CMS124v8: Cervical Cancer Screening
  • CMS74v10: Primary Caries Prevention Intervention as Offered by Primary Care Providers, including Dentists
  • CMS124v9: Cervical Cancer Screening
  • CMS125v9: Breast Cancer Screening
  • CMS149v9: Dementia: Cognitive Assessment
  • CMS153v9: Chlamydia Screening for Women
  • CMS347v4: Statin Therapy for the Prevention and Treatment of Cardiovascular Disease
  • CMS127v9: Pneumococcal Vaccination Status for Older Adults
  • CMS146v9:Appropriate Testing for Children with Pharyngitis
  • CMS154v9: Appropriate Treatment for Children with Upper Respiratory Infection (URI)
  • CMS155v9: Weight Assessment and Counseling for Nutrition and Physical Activity for Children and Adolescents
  • CMS159v9: Depression Remission at Twelve Months

Eligible Hospital (EH)/Critical Access Hospital (CAH) Measures

2020 Reporting Measures

2021 Reporting Measures

  • CMS104v8: Discharged on Antithrombotic Therapy
  • CMS105v8: Discharged on Statin Medication
  • CMS108v8: Venous Thromboembolism Prophylaxis
  • CMS506v2: Safe use of opioids - concurrent prescribing (Pre rule for 2020 reporting)
  • CMS111v9: Median Admit Decision Time to ED Departure Time for Admitted Patients
  • CMS529v1: Hybrid Hospital-Wide Readmission

Type of Track: Testing an Implementation Guide

Submitting WG/Project/Implementer Group: CDS/CQI/DaVinci Project 

FHIR Version: R4

Specifications and Artifacts of Focus:

Clinical Input Requested (if any): Clinical review of the proposed workflows for the data exchange scenarios, as well as clinical input on the question of whether there is potential value in the data exchange scenarios for a measure with such a short window of opportunity for intervention like VTE-1 (CMS Measure-Venous Thromboembolism Prophylaxis) would be valuable.

Patient Input Requested (if any): N/A

Related Tracks: Care Planning, Public Health, CDS Hooks, DaVinci DEQM Gaps in Care and PACIO/eLTSS

Proposed Track Lead: Bryn Rhodes,

Expected Participants (feel free to add your organization)

American Academy of Neurology


Dynamic Health IT


Epic (via CDS Hooks)


Indicina, LLC

iParsimony LLC



The Joint Commission

Zulip Stream:

Track Orientation:

Getting Started:

Artifacts During Connectathon:

System Roles (Quality Reporting)

Systems capable of playing these roles should implement the exchange and reporting scenarios as described in the Data Exchange for Quality Measures implementation guide.

The CQF Ruler, a reference implementation of FHIR Clinical Reasoning based on the HAPI FHIR Server is available to either play the Consumer, Receiver, and CDS Service roles, or to help guide and test implementations in preparation for the track.

A test instance of the CQF Ruler is available here:

Data Exchange Scenarios

For these scenarios, the Producer and Consumer exchange the data-of-interest for a quality measure, either by push or pull

This is the EHR Reference Implementation server endpoint for the Medication Reconciliation Post Discharge use case to test the DEQM $submit-data operation -

This is the Payer Reference Implementation server endpoint for this use case -

Individual Exchange Scenarios

Push Scenario ($submit-data)
Pull Scenario ($collect-data)

Group Exchange Scenarios

For the Group Exchange scenarios, we focus on the need for payers to track status of members for a screening measure, a Colorectal Cancer Screening measure in this case. The scenarios are based on the case where a payer sends a request to a provider for the screening information for a group of covered patients.

These scenarios will attempt to use the Bulk Data API as specified in the FHIR specification. In particular:

Push Scenario ($submit-data)

In the push scenario, the provider - through some interface in their system - gathers the screening information for the set of patients and submits it:

Pull Scenario ($collect-data)

In the pull scenario, the payer uses the $collect-data operation to request through the provider's API

Reporting Scenarios

For these scenarios, a Reporter and Receiver exchange the data and results of a quality measure.

Individual Report Scenario

Summary Report Scenario

Calculation Scenarios

For these scenarios, a Receiver requests the calculation of a quality measure by a Reporting system.

Individual Report Scenario

Summary Report Scenario

Public Health Reporting Scenario

System Roles (PHR)

Clinical System - A system that deals with health data and potentially reportable events
Reporting Application - A system that focuses on identifying and submitting potentially reportable events
Receiving System - A system that receives potentially reportable events

Negative Chlamydia Screening Report Scenario

Decision Support Scenarios

System Roles (CDS)

CDS Service - A system that provides decision support guidance via the CDS Hooks API
CDS Client - A system that consumes decision support via the CDS Hooks API

Systems capable of playing these roles should implement the CDS Hooks API. Systems may also support ingestion of computable decision support content as described in the Clinical Guidelines implementation guide.

Opioid Decision Support

The Centers for Disease Control and Prevention (CDC) have issued guidelines relating to the prescription of opioids: (Opioid Prescription Guideline)

The Opioid Prescribing Support Implementation Guide represents several recommendations of this guideline as computable artifacts using the FHIR Clinical Reasoning Module: (Opioid Prescribing Support Implementation Guide)

This scenario will focus on testing usage with the new order-select hook for recommendations #5, #10, and #11

For the purposes of this scenario, long-term opioid therapy is defined as use of opioids on most days for > 3 months, and the patient does not have metastatic cancer. To determine these, the CDS Service will need to access:

For communicating medications, the service will expect information in a MedicationRequest or MedicationStatement, with at least the following supplied:

The implementation guide provides computable artifacts describing the calculations for MME based on the CDC Guidance. The CDS Service can use these representations to provide the functionality described for this scenario.

TestScript(s): All testing materials can be accessed from the Connectathon GitHub Repository:

Security and Privacy Considerations: The scenarios and reference implementations here run using open (i.e. unsecured) connections. Systems SHALL NOT use PHI in any form, or data derived directly from PHI.