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

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 19 Next »

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:

  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 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
    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 and/or a measure clause
  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

Proposed Track Lead

Yan Heras (yan.heras@optimumehealth.com)

Expected participants

Optum

Dynamic Content Group

Mettles

Cambia

Track Orientation

Webinar: 

Zulip Stream: https://chat.fhir.org/#narrow/stream/179207-connectathon-mgmt/topic/Da.20Vinci.20Gaps.20In.20Care.20Track

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

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

$care-gaps operation

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)

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 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
2$submit-data or $collect-data to close gaps identified in Step 1CMS130v7 colorectal cancer screeningThe provider submits addition data to the payer for the patient 1 that will help to close the gap. 

3Rerun $care-gap operationCMS130v7 colorectal cancer screeningThe 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. 

  1. Find out the Provider's NPI and TIN that data on the ATR server has set up
  2. GET group from ATR Server for the provider (identified with NPI/TIN)
    1. 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. 
  3. Gaps in Care Server will return gaps in care report for the group. 

Preparation:

  1. Identify a list of patients that could use (Synthea patients for the 3 cancer screening measures) by Dragon (ATR Server) to create a group
    1. Dragon to provide the group id and the NPI/TIN that was used to create the group
    2. (Note: check with Sam if there are newer generated Synthea patients. The ones we have now are the ones used for the May connectathon)
  2. 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. 

Success Criteria:

Bonus point: Using Bulk data to test the scenario

(2020-01 Da Vinci Risk Based Contract Member Identification)

Tasks Leading to the Connectathon (Used for Track Preparation)

  1. Identifying the 3 or so measures that have the FHIR measure resource and cql completed
  2. Identify or create via Synthea a set of patients with and without clinical data.
  3. Create a “list” of these patient and their identifiers
  4. Identify the profiles associated with these patients that Member Attribution need, e.g., Coverage resource
  5. Create a FHIR bundle or other FHIR artifact for the member attribution team to load into the Member Attribution server
  6. 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.
  7. 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:

  1. Evaluated resources tracking populations
    1. Need to expose it to the measure report
    2.  Spike to assess if this is doable by the Connectathon 
  2. Validate the return bundle conforms to the profile  
  3. Subject being a patient or a group (group is not supported) 
  4. Status (open or closed, and both as default)
  5. A specific measure (right now is only using topic … "measure" is not currently supported) or a list of specific measures
  6. Creation of detectedIssue for care gaps report
  7. Organization
  8. Practitioner

TestScript(s)

https://github.com/dbcg/connectathon

https://github.com/projecttacoma/fhir-patient-generator (random generated test data):

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.

  • No labels