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:
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
Yan Heras (email@example.com)
Dynamic Content Group
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.
|Time (ET)||Sept. 9th (Wed)||Sept. 10th (Thur)||Sept. 11th (Fri)|
9am (ET) Join the Clinical Reasoning Track to discuss coordination of testing the end-to-end reporting scenario.
(Use the Clinical Reasoning Track)
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) - 6pm(ET): DaVinci Track Kickoff
|6pm (ET)||Connectathon 25 Wraps Up|
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)
|Step||Description||FHIR R4 Measure||Scenario Details||Operation||Bonus Point|
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.
Additional candidate measures:
|2||Send additional or new data to close gaps identified in Step 1||CMS130v7 colorectal cancer screening||The 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|
|3||Rerun $care-gap operation||CMS130v7 colorectal cancer screening||The 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:
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.)
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.
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