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

Note that this track will be nearly identical to the clinical reasoning track at Connectathon 21

Submitting WG/Project/Implementer Group

Clinical Decision Support/Clinical Quality Information/Da Vinci Project

Justification and Objectives

This track will focus on using the quality reporting capabilities of FHIR for 3 use cases:

  1. Test FHIR-based Quality Reporting scenarios described in the Data Exchange for Quality Measures implementation guide, specifically
    1. Medication Reconciliation Post-Discharge (MRP)
    2. Colorectal Cancer Screening (COL)
    3. Venous Thromboembolism Prophylaxis (VTE-1)
  2. Test the exchange scenarios for MRP and COL
  3. Test the reporting scenarios for MRP, COL, and VTE-1

This track will use the STU3 version of FHIR.

Clinical input requested (if any)

Clinical review of the proposed workflows for the data exchange scenarios, as well as clinical input on the question of whether there is potential value in the data exchange scenarios for a measure with such a short window of opportunity for intervention like VTE-1.

Proposed Track Leads

Michael O'Keefe (mokeefe@mitre.org)

Nikolai Schwertner (nikolai@interopion.com)

Expected participants

Track Orientation

Orientation slides (presented 5/16/2019):

System Roles

Producer - System of record for clinical information such as an EHR
Consumer - A system that aggregates data from multiple sites related to reporting quality measures such as a payer, hie, reporting vendor or public health registry
Reporter - A system that sends quality reporting data and results
Receiver - A system that receives quality reporting data and results

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

A test instance of the CQF Ruler is available here: http://measure.eval.kanvix.com/cqf-ruler/baseDstu3

A test population for the measure calculations is available here: https://drive.google.com/open?id=1AEzOaYam2ngaEdFASsjWBNJ1PynNmyhn

Scenarios

Data Exchange Scenarios:

For these scenarios, the Producer and Consumer exchange the data-of-interest for a quality measure, either by push, pull, or subscription.

This is the EHR Reference Implementation server endpoint for the Medication Reconcilation Post Discharge use case to test the DEQM $submit-data operation - https://api-v8-stu3.hspconsortium.org/DaVinciMRPProvider/open

This is the Payer Reference Implementation server endpoint for this use case - https://api-v8-stu3.hspconsortium.org/DaVinciMRPPayer/open

Individual Exchange Scenarios

Push Scenario ($submit-data)

Action: An EHR playing the role of the Producer uses the $submit-data operation to report the data-of-interest for an MRP measure

Precondition: The EHR has appropriate data to produce the data-of-interest for the measure, either based on the test data, or by walking through a simulated workflow that produces the data required

Success Criteria: The Consumer receives the data and successfully processes the data

Bonus Point: Run the operation multiple times throughout a simulated measurement period to feed incremental data of interest for the measure to the Consumer

Pull Scenario ($collect-data)

Action: A Consumer uses the $collect-data operation to gather the data-of-interest for an MRP

Precondition: The EHR has appropriate data to produce the data-of-interest for the measure, either based on the test data, or by walking through a simulated workflow that produces the data required

Success Criteria: The Producer responds to the $collect-data and the Consumer is able to successfully process the response

Bonus Point: Run the operation multiple times throughout a simulated measure period to collect incremental data of interest for the measure

Subscription Scenario

Action: An EHR playing the role of the Producer notifies a Consumer that data-of-interest for an MRP measure is available.

Precondition: The Consumer has registered a subscription with the Producer

Success Criteria: The Producer receives notification of the available data and successfully uses a $collect-data operation to gather the data-of-interest

Bonus Point: Queue subscription notifications from multiple patients and collect them using a bundle containing multiple $collect-data operations

Group Exchange Scenarios

For the Group Exchange scenarios, we focus on the need for payers to track status of members for a screening measure, a Colorectal Cancer Screening measure in this case. The scenarios are based on the case where a payer sends a request to a provider for a the screening information for a group of covered patients.

Push Scenario ($submit-data)

In the push scenario, the provider - through some interface in their system - gathers the screening information for the set of patients and submits it:

Action: An EHR playing the role of the Producer uses a batch of $submit-data interactions to report the data-of-interest for the COL measure for the set of patients

Precondition: The EHR has appropriate data to produce the data-of-interest for the measure, either based on the test data, or by walking through a simulated workflow that produces the data required

Success Criteria: The Consumer receives the data and successfully processes the data

Bonus Point: The provider system uses the Bulk Data format send the information

Pull Scenario ($collect-data)

In the pull scenario, the payer uses the $collect-data operation to request through the provider's API

Action: A Consumer uses a batch of $collect-data interactions to gather the data-of-interest for a COL measure for a set of patients

Precondition: The EHR has appropriate data to produce the data-of-interest for the measure, either based on the test data, or by walking through a simulated workflow that produces the data required

Success Criteria: The Producer responds to the $collect-data batch and the Consumer is able to successfully process the responses

Bonus Point: The payer system uses the Bulk Data format to request the information

Reporting Scenarios:

For these scenarios, a Reporter and Receiver exchange the data and results of a quality measure.

Individual Report Scenario

Action: An Reporter reports the data and results for an Individual MRP, COL, or VTE-1 measure to a Receiver

Precondition: The Reporter has appropriate data to produce the individual MeasureReport for the measure

Success Criteria: The Receiver receives a completed MeasureReport and verifies that it has the correct data and the calculated result is correct for the individual

Bonus Point: Use a subscription to notify the Receiver when the report is ready for retrieval


Summary Report Scenario

Action: A Reporter reports the results for a Summary MRP, COL, or VTE-1 measure to a Receiver

Precondition: The Reporter has appropriate data to produce the summary MeasureReport for the measure

Success Criteria: The Receiver recieves a completed MeasureReport and verifies that it has the expected result for the population

Bonus Point: Use a subscription to notify the Receiver when the report is ready for retrieval

Calculation Scenarios:

For these scenarios, a Receiver requests the calculation of a quality measure by a Reporting system.

Individual Report Scenario

Action: A Receiver uses $evaluate-measure to request the data and results for an Individual MRP, COL, or VTE-1 measure from a Reporter

Precondition: The Reporter has appropriate data to produce the individual MeasureReport for the measure

Success Criteria: The Receiver receives a completed MeasureReport and verifies that it has the correct data and the calculated result is correct for the individual

Bonus Point: Use asynchronous result calculation (MeasureReport status = in-progress)


Summary Report Scenario

Action: A Receiver uses $evaluate-measure to request the results for a Summary MRP, COL, or VTE-1 measure from a Reporter

Precondition: The Reporter has appropriate data to produce the summary MeasureReport for the measure

Success Criteria: The Receiver recieves a completed MeasureReport and verifies that it has the expected result for the population

Bonus Point: Use asynchronous result calculation (MeasureReport status = in-progress)

TestScript(s)

Indicate any test scripts that will be used to help verify system behavior - coming soon

Security and Privacy Considerations

Identify any expectations around security (e.g. will TLS, mutual-TLS, OAuth, etc. be required to participate

  • No labels