Track Short Description: Continue the testing and use of the Data Exchange for Quality Measures (DEQM IG) for gaps in care and quality measurement reporting use cases using FHIR-based eCQMs; Testing the use of the member attribution for gaps in care.
Track Long Description:
- Continue testing the gaps in care profiles and $care-gaps operation specified in the September 2020 Ballot DEQM IG (with gaps in care content)
- Continue to test gaps in care and DEQM use cases focusing on an interactive and end-to-end scenario and closely coordinate with the Clinical Reasoning Track
- Run $care-gaps using the colorectal cancer screening FHIR-based measure written with CQL (CMS130v7: Colorectal Cancer Screening)
- Use $submit-data or $collect-data to close some gaps identified in the gaps in care report
- Re-run $care-gaps for an updated gaps in care report to see that gaps were closed
- Report Summary measure report
- Test the use of populationReference extension to support associating a specific evaluatedResource to a population and/or a measure clause
- Test the use of DaVinci Risk Based Contracts Member Attribution (ATR) List IG to attribute members when create a gaps in care report
- 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:
- Data Exchange for Quality Measures (DEQM) IG STU3 for FHIR R4 (September 2020 Ballot) (http://build.fhir.org/ig/HL7/davinci-deqm/branches/gic-branch/)
- Quality Measure IG (Quality Measure STU2 for FHIR R4 Implementation Guide)
- QI-Core IG (QI-Core Implementation Guide: STU 4 (v4.0.0 for FHIR 4.0.1))Implementation Guides:
- DaVinci Risk Based Contracts Member Attribution (ATR) List IG
- FHIR Resources:
- Measure Resource: http://hl7.org/implement/standards/fhir/measure.html
- Measure Report: http://hl7.org/implement/standards/fhir/measurereport.html
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
Proposed Track Lead
Yan Heras (firstname.lastname@example.org)
Dynamic Content Group
Track information will be provided on the regular Da Vinci Gaps In Care weekly meeting in the coming weeks leading to the Connectathon.
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. The Server supports $evaluate-measure
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 operation to gather data-of-interest that could 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 Server 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 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||$submit-data or $collect-data to close gaps identified in Step 1||CMS130v7 colorectal cancer screening||The provider submits addition data to the payer for the patient 1 that will help to close the gap.|
|3||Rerun $care-gap operation||CMS130v7 colorectal cancer screening||The provider requests a Gaps in Care Report for his 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 supports $evaluate-measure and is able to track which data is used for calculate 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
Bonus point: Track and reference a specific measure logic phrase of a population criteria (e.g., a measure logic phrase within a numerator)
Member Attribution Scenario
Action: A Client calls the $care-gaps operation for a specific group from the Server. The Server get a pre-arranged 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.
- Find out the Provider's NPI and TIN that data on the ATR server has set up
- GET group from ATR Server for the provider (identified with NPI/TIN)
- For this to happen: both Gaps in Care Server and ATR Server have to have the same set of patients, and the same group id. All patients have to have the same patient ids. All these are pre-configured for this Connecathon senario.
- Gaps in Care Server will return gaps in care report for the group.
- Dragon to identify a list of patients that he would use to create a group by selecting from the Synthea test patients for the 3 cancer screening measures (links to the Synthea patients are in the Test Scripts section below)
- Dragon to provide the group id and the NPI/TIN that was used to create the group
- Dragon then provides a bundle that contains group, patients belong to the group to Rob. Rob then post the group and patients to the Gaps in Care Server.
Bonus point: Using Bulk data to test the scenario
Tasks Leading to the Connectathon (Used for Track Preparation)
- Identifying the 3 or so measures that have the FHIR measure resource and cql completed
- Identify or create via Synthea a set of patients with and without clinical data.
- Create a “list” of these patient and their identifiers
- Identify the profiles associated with these patients that Member Attribution need, e.g., Coverage resource
- Create a FHIR bundle or other FHIR artifact for the member attribution team to load into the Member Attribution server
- Test the member attribution operation based on these patients and retrieve this list of patients. Confirm that we provided the correct data to return the list of patients.
- Determine how the MA data may need to be “massaged” to be use in the $care-gaps operation. Additionally, determine if any necessary data may be missing.
Reference Implementation tasks:
- Evaluated resources tracking populations
- Need to expose it to the measure report
- Spike to assess if this is doable by the Connectathon
- Validate the return bundle conforms to the profile
- Subject being a patient or a group (group is not supported)
- Status (open or closed, and both as default)
- A specific measure (right now is only using topic … "measure" is not currently supported) or a list of specific measures
- Creation of detectedIssue for care gaps report
https://github.com/projecttacoma/fhir-patient-generator (random generated test data):
- Cervical Cancer Screening https://github.com/projecttacoma/fhir-patient-generator/tree/master/EXM_124
- Breast Cancer Screening https://github.com/projecttacoma/fhir-patient-generator/tree/master/EXM_125
- Colorectal Cancer Screening https://github.com/projecttacoma/fhir-patient-generator/tree/master/EXM_130
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.