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

Track 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; Testing the use of the member attribution for gaps in care.

Track Long Description:

  1. Continue testing the gaps in care profiles and $care-gaps operation specified in the September 2020 Ballot DEQM IG (with gaps in care content) 
  2. Continue testing gaps in care use cases focusing on an interactive and end-to-end scenario and closely coordinate with the Clinical Reasoning Track
    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
  3. Test the use of populationReference extension to support associating a specific evaluatedResource to a population
  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. Test the use of bulk data 

Type of Track: Testing an Implementation Guide

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

FHIR Version: R4

Implementation Guide and or FHIR Resources will this track use:

Clinical input requested (if any): Clinical review of the input parameters for generating the Care Gaps report and expected results in the payload.

Related tracks: Clinical Reasoning

Track Lead

Yan Heras (yan.heras@optimumehealth.com)

Expected participants

Optum

Dynamic Content Group

Mettles Solutions

Cambia

Track Orientation

Orientation Presentation Recording and Slides

Connectathon Information Session Recording and Slides

Zulip Stream:  Da Vinci Gaps in Care Track stream under connectathon mgmt 

Track information will be provided on the regular Da Vinci Gaps In Care weekly meeting in the coming weeks leading to the Connectathon. 

Track Schedules

Time (ET)Sept. 9th (Wed)Sept. 10th (Thur)Sept. 11th (Fri)
9am (ET)

9am (ET) Join the Clinical Reasoning Track to discuss coordination of testing the end-to-end reporting scenario.

(Use the Clinical Reasoning Track)

10am (ET)

10:00am (ET) - 10:30am (ET): Track Kickoff

Review track information and an overview of the DEQM IG STU 2.1.0 September ballot

10:00am (ET) Track Zoom starts


4pm (ET)4pm(ET) - 5pm(ET): Connectathon 25 Kickoff

5pm (ET)

5pm(ET) - 6pm(ET):  DaVinci Track Kickoff 



6pm (ET)

Connectathon 25 Wraps Up

System Roles

Client - A system that submit the gaps in care results of quality measure(s). 

Server - A system that receives the request for the gaps in care report and produces a gaps in care report based on the information available in the system. 

Gaps in Care Reporting Scenario

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: Run bulk data 

End to End Gaps in Care Reporting Scenario

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)

StepDescriptionFHIR R4 MeasureScenario DetailsOperationBonus Point
1

Initial run of the $care-gap operation 

CMS130v7 colorectal cancer screening

A provider requests a Gaps in Care Report for his/her patients from the payer and receives the report. The report includes gaps in care information for two patients. Patient 1 has an open gap. Patient 2 has closed gap. 

$care-gaps

Additional candidate measures: 

  • CMS124v9: Cervical Cancer Screening
  • CMS125v9: Breast Cancer Screening
2Send additional or new data to close gaps identified in Step 1CMS130v7 colorectal cancer screeningThe provider submits addition data or new data to the payer for the patient 1 that will help to close the gap. $submit-data or $collect-data
3Rerun $care-gap operationCMS130v7 colorectal cancer screeningThe provider requests a Gaps in Care Report  for his/her patients again from the payer and receives the report. The report shows that both Patient 1 and Patient 2 now have closed gaps. $care-gaps

evaluatedResource Population Referencing Scenario

Action: A Client calls the $care-gaps operation and receives the gaps in care report from the Server. The Server tracks the evaluatedResource used for calculating a specific population type (e.g., numerator, denominator) and include this information in the resulted gaps in care report 

Precondition: The Server knows the patient and has appropriate measure data for the patient to produce gaps in care report. The Server is able to track which data is used for calculating which population within the measure

Success Criteria: The Client receives the gaps in care report and the evaluatedResource is tracked properly to the population type it was used for satisfying the population criteria using the DEQM Population Reference Extension

Member Attribution Scenario

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

Member Attribution APIs:


Pre-configured information:

  • Both the Gaps in Care Server and ATR Server will pre-configure for the scenario to have the same set of patients and the same Group id. All patients have to have the same patient ids.
  1. Provider's NPI and TIN on the ATR Server
    1. NPI: 1316206220
    2. TIN: 789456231
  2. GET group from ATR Server for the provider (identified with NPI/TIN). Gaps in Care Server pre-configures the same set of patients with the same Group id as what are pre-configured on the ATR Server.
    1. Group Id: 1
    2. Group downloaded will contain 3 patients common to Gaps In Care
      • Dominique369_Ledner144 
      • Emilie407_Cole117 
      • Malcolm243_Erdman779

Gaps in Care Reference Implementation Server

This is the Reference Implementation server endpoint for Gaps in Care to call the $care-gaps operation - 

          (Measures loaded to the r4 sandbox are specified based on FHIR 4.0.0  and are using the CQL 1.4 Translator.)

TestScripts

https://github.com/dbcg/connectathon

Synthea generated test patients: https://github.com/projecttacoma/fhir-patient-generator:

Touchstone Test Scripts are available HERE (covering the use cases for this Connectathon).  Please contact Touchstone_Support@aegis.net for any questions on using Touchstone and an AEGIS.net representative will be joining the track on Friday to assist with testing and provide a hands-on demonstration of the system and show the tests associated with the track.

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.

Report Out

Summary: 

The purpose of the Gaps in Care/Member Attribution Connectathon track is to continue testing the gaps in care reporting scenarios. The testing is focused on the following four scenarios: 1) test the new gaps in care profiles and operation defined in the Data Exchange for Quality Measure (DEQM) IG September 2020 ballot; 2) test end-to-end gaps in care reporting; 3) test the use of the populationReference extension to associate a specific evaluatedResource in a measure report with a population type code (i.e., numerator, denominator); 3) test the use of the Da Vinci Risk Based Contracts Member Attribution (ATR) List IG for gaps in care

Participants:

  • Mettles Solution
  • The MITRE Corporation
  • Optum
  • Dynamic Content Group
  • Epic
  • University of Pittsburgh Medical Center
  • Healthfirst
  • Yale/CORE
  • Tata Consultancy Services
  • Drajer LLC
  • Optimum eHealth

Systems:

  • Cqf-ruler reference implementation
  • Mettles Solution's implementation

Notable Achievements:

  • Actively developing and testing the reference implementation and resolving issues
  • Successfully tested the end-to-end gaps in care reporting
    • Reference Implementation in collaboration with the Clinical Reasoning Track
    • Mettles Solution’s Implementation
  • Successfully tested the gaps in care use and member attribution scenario
  • Discussed potential need for future enhancement of using populationReference extension and detectedIssue
  • Identified a few places in the specification that might need clarification and filed trackers
  • AEGIS Touchstone demonstrated how their tooling benefited the testing of conformance between an implementation and the implementation guide

Discovered Issues 

  • Issues with Reference Implementation that were identified and fixed
    • Fixed measure parameter to use id instead of name
    • Fixed a bug in status parameter that was not correctly including everything in the case of no parameter
    • Updated name of the parameter in report to the correct value per the spec
    • fixed bug in the case of a null measure related to the measure parameter
  • Issues logged as FHIR tracker
  • The reference implementation uses the HAPI server to run $care-gap operation. HAPI does not support bulk-data by default. 

Now What?

  • Join the Da Vinci Gaps in Care Track debrief during the weekly Da Vinci Gaps In Care meeting. Meeting details are available on the Gaps in Care Confluence page.
  • Discuss and resolve issues discovered in future Da Vinci Gaps in Care meetings
  • Ballot reconciliation in the CQI Work Group meetings




  • No labels