Page tree
Skip to end of metadata
Go to start of metadata

Short Description

Continue the testing and use of the Data Exchange for Quality Measures (DEQM IG) for gaps in care reporting use cases using FHIR-based eCQMs

Long Description

The Gaps in Care/Member Attribution Track will be combined with the Clinical Reasoning Track in this Connectathon. 

  1. Test an end-to-end DEQM/GIC scenario
    1. Run $care-gaps using the colorectal cancer screening FHIR-based measure written with CQL (CMS130v7: Colorectal Cancer Screening)
    2. Use $submit-data or $collect-data to close some gaps identified in the gaps in care report
    3. Re-run $care-gaps for an updated gaps in care report to see that gaps were closed
    4. Report Summary measure report
  2. Test the updated GIC profiles/operation incorporating changes applied from the DEQM IG September 2020 ballot reconciliation.
  3. Discuss potential enhancement to the DEQM Gaps In Care DetectedIssue profile to allow for more granular gap detection
    1. MITRE demo of measure highlighting service
  4. Test the use of DaVinci Risk Based Contracts Member Attribution (ATR) List IG to attribute members when create a gaps in care report.
  5. Explore potential roadmap for testing the Quality Improvement Ecosystem end-to-end scenario
  6. FHIR HEDIS DQMs implementer feedback/discussion session

Agenda

Gaps in Care/Member Attribution Track orientation: 12/3/2020 2pm ET (see here for meeting information)

To find us at the Connectathon - please go to the Clinical Reasoning Track through Whova.

Agenda: https://drive.google.com/file/d/1P9RWtmzaynIoMEsuBSgJb7h0t5cAPTYy/view?usp=sharing 

Type

Testing an Implementation Guide

Submitting Work Group/Project/Accelerator/Affiliate/Implementer Group  

CQI

Track Leads

Yan Heras (yan.heras@optimumehealth.com), Rob Reynolds (rob@alphora.com)

Related Tracks

2021-01 Clinical Reasoning

FHIR Version

R4

Specification(s) this track uses

Artifacts of focus

Clinical input requested (if any)

Clinical review of the input parameters for generating the Care Gaps report and expected results in the payload.

Patient input requested (if any)

No

Expected participants

  • MITRE
  • Cigna
  • Optum
  • Cambia
  • Dynamic Content Group

Zulip stream

Da Vinci Gaps in Care Track stream under connectathon mgmt 

Clinical Reasoning Track Zoom Link

Track Orientation Date

December 3rd, 2020

Track Orientation Details

Gaps in Care/Member Attribution Track Orientation 12/3/2020 (2pm ET), click here for GotoMeeting details 

See the 2021-01 Clinical Reasoning Track page for information about the Clinical Reasoning Track Orientation.

Gaps in Care/Member Attribution Track Orientation Powerpoint and recording.

Track Details

System Roles (Gaps in Care)

  • Client - A system submitting a request for gaps in care results.
  • Server- A system receiving a request for gaps in care results and returning a care gaps response in the form of a Care Gaps report.
  • Knowledge Repository - A system that supports searching and retrieval of measure artifacts
  • Terminology Service - A system that supports searching and retrieval of measure-related terminology

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 or Receiver, or to help guide and test implementations in preparation for the track.

A test instance of the CQF Ruler is available here: https://gic-sandbox.alphora.com.  This testing instance is subject to change throughout the event.


Scenario: End-to-End Gaps in Care Reporting

Action: A Client calls the $care-gaps operation using the Colorectal Cancer Screening measure and receives the gaps in care report from the Server. The Client uses the $collect-data or $submit-data operation to gather data-of-interest that would close the open gap and submit to the Server. The Client then calls the $care-gaps operation again for the Colorectal Cancer Screening measure using the same set of in parameters. The Client uses the $submit-data operation to send the summary measure report

Precondition: The Server knows the patient and has appropriate measure data for the patient to produce gaps in care report. The Server supports measure calculations for the measure of interest and is able to generate summary report

Success Criteria: The end to end is successful

Bonus point: Run for additional measure(s)

TestScript(s):

Scenario: Test the updated GIC profiles/operation incorporating changes applied from the DEQM IG September 2020 ballot reconciliation

Action: A Client calls the $care-gaps operation to request a gaps in care report from the Server, using various combinations of the $care-gaps in parameters

Precondition: The Server knows the patient and has appropriate measure data for the patient to produce gaps in care report. 

Success Criteria:  The Client receives the gaps in care report as expected based on the in parameters provided to the $care-gaps operation and successfully processes the data

Bonus point: 

TestScript(s):

Scenario: Test the use of ATR IG to attribute members when create a gaps in care report

Action: A Client calls the $care-gaps operation for a specific Group from the Server. The Server gets a pre-configured Group. The Server returns gaps in care report for the Group, which shows open and/or closed gaps for each patient in the Group for the Colorectal Cancer Screening measure.

Precondition: Group is pre-configured on both Gaps in Care Server and Member Attribution Server. 

Success Criteria: The gaps in care Client receives gaps in care report for the Group

Bonus point: Using Bulk data to test the scenario

TestScript(s): All testing materials can be accessed from the DA Vinci Gaps in care GitHub Repository: https://github.com/dbcg/davinci-gic. These testing materials are subject to change throughout the event.

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.