2020-05 Clinical Reasoning

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

Justification and Objectives: The purpose of the clinical reasoning connectathon track is to continue testing electronic clinical quality measures (eCQMs) and clinical decision support (CDS) artifacts, tooling, and test cases. 

1. Continue testing of Quality Measurement use cases
   1. R4 measures (CMS104v8, CMS105v8, CMS108v8, CMS124v8, CMS125v8, CMS130v7 (2019), CMS165v8, CMS349v2, CMS506v2, CMS529)
   2. STU3 measures (CMS104v8, CMS105v8, CMS108v8, CMS117v8, CMS124v8, CMS125v8, CMS130v7 (2019), CMS161v8, CMS165v8, CMS349v2)
   3. Test use of QI-Core R4 using CMS124v8
   4. Expressing QI-Core in FHIR shorthand
   5. Document incremental update examples
   6. Document Provenance examples, possibly working on changes to align usage of Provenance for identifying submitting Organization
   7. Continued investigation of Bulk Import support: https://github.com/DBCG/connectathon/tree/master/fhir4/fhir-bulk-proxy
      
2. Test and validate the use of the QICore model in CQL authoring, and contrast it with the use of a QUICK prototype model and toolchain for CQL authoring
3. Test ExecutableLibrary profile
4. Test the new `order-select` hook using CDC Opioid Prescribing (in coordination with the CDS Hooks track)
5. Test FHIR Clinical Guidelines example content (in coordination with the Care Planning and Public Health tracks)

This track will use R4 and STU3 versions 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.

Related tracks

Bulk Data

Care Planning

CDS Hooks

Public Health

Gaps in Care

Proposed Track Lead

Bryn Rhodes, bryn@databaseconsultinggroup.com

Expected Participants (the Clinical Reasoning Track typically has between 20 and 40 participants)

Apelon

Apervita

Cerner (via CDS Hooks)

Dynamic Content Group

Dynamic Health IT

EBSCO (via EBM-on-FHIR)

Epic (via CDS Hooks)

ESAC

Flexion

HLN Consulting, LLC

HQR

iParsimony LLC

Lantana Consulting Group

Mathematica

Mettle Solutions

Medisolv 

MITRE

NCQA

Optum

Oregon Urology Institute/ Large Urology Group Practice Association

Philips

PJM Consulting LLC

SemanticBits

The Joint Commission

University of Pittsburgh Department of Biomedical Informatics

Track Orientation

 Join a debrief session on Tuesday, May 19th at 10:00 AM (ET), meeting details are posted on the CQI Workgroup FHIR Quality Project Sub-Group site. 

• Track Orientation Slides (4/28): Clinical Reasoning Connectathon 24 Track Orientation 4-28-2020 FINAL.pptx
• Track Orientation Recording (4/28): https://fccdl.in/gx3iLopgtL
• Track Planning Sessions (5/5 and 5/12): FHIR Quality Project Sub-Group
• Please fill out Pre-Connectathon Survey: https://www.surveymonkey.com/r/HNQ96MY
• Sign-up for Connectathon Manager: http://conman.clinfhir.com/connectathon.html?event=hl7online
• We will use the Clinical Reasoning connectathon stream in Zulip for communication before, during, and after the connectathon:
  • Zulip Connectathon Stream: Zulip Chat for participants
    
• Getting Started with Clinical Quality Language: Getting Started with CQL.pptx
  • NOTE: We'll be using CQL 1.4, which is included in the Atom language-cql plugin version 2.5.1
  • This version of the plugin requires Java 11 (recommended supporting Java install: https://adoptopenjdk.net/?variant=openjdk11&jvmVariant=openj9)
• Connectathon GitHub: https://github.com/dbcg/connectathon
• Quick Start: https://github.com/DBCG/connectathon/wiki/Quickstart
• Test Data for Quality Reporting Scenarios: https://github.com/projecttacoma/fhir-patient-generator

Track Schedule

All track webinar links can be accessed here

Track Running Notes: https://docs.google.com/document/d/18ZSaYBNYlFkx2UhRJusVANp24HD_sjhHOiZs2ak9gSg/edit?usp=sharing

Track Report-Out: https://docs.google.com/document/d/1B6FvP5IP83tuUPvOMQjZIR5jYyw4OSbahgRqnbkPZZ8/edit

System Roles (Quality Reporting)

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

A test instance of the CQF Ruler is available here: http://cqm-sandbox.alphora.com/

Scenarios

Describe the different scenarios participating systems can engage in during the connectathon. Each scenario should provide sufficient description that participants can appropriately construct their software in advance to prepare to interoperate during the connectathon.

Data Exchange Scenarios:

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

This is the EHR Reference Implementation server endpoint for the Medication Reconciliation 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

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 the screening information for a group of covered patients.

These scenarios will attempt to use the Bulk Data API as specified in the FHIR specification. In particular:

• $collect-data will use bulk data to communicate the response
• $submit-data will use an implementation of bulk data import to communicate the payload of the request

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 to 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: A 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 receives 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 receives a completed MeasureReport and verifies that it has the expected result for the population

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

Public Health Reporting Scenario:

System Roles (PHR)

Clinical System - A system that deals with health data and potentially reportable events
Reporting Application - A system that focuses on identifying and submitting potentially reportable events
Receiving System - A system that receives potentially reportable events

Negative Chlamydia Screening Report Scenario:

Action: A Reporting Application is notified by a Clinical System of a potentially reportable event, and uses the eRSD specification to:

1. Determine the jurisdiction of residence and jurisdiction of care for the event
2. Determine whether the event is potentially reportable, given condition-specific value sets and jurisdiction-specific criteria as specified in the rule filter portion of the eRSD specification
3. If the event is potentially reportable, submit a mock eICR to the receiving system

Precondition: The Clinical System has appropriate data representing a negative chlamydia screening result

Success Criteria: The receiving system is notified of and receives a potentially reportable eICR for a negative chlamydia screening result

Bonus Point: Demonstrate the pattern is effective for other conditions that exhibit similar potential to reduce the number of potentially reportable events submitted through jurisdiction-specific and condition-specific configuration

Decision Support Scenarios:

System Roles (CDS)

CDS Service - A system that provides decision support guidance via the CDS Hooks API
CDS Client - A system that consumes decision support via the CDS Hooks API

Systems capable of playing these roles should implement the CDS Hooks API. Systems may also support ingestion of computable decision support content as described in the Clinical Guidelines implementation guide.

Opioid Decision Support

The Centers for Disease Control and Prevention (CDC) have issued guidelines relating to the prescription of opioids:

[https://www.cdc.gov/drugoverdose/prescribing/guideline.html Opioid Prescription Guideline]

The Opioid Prescribing Support Implementation Guide represents several recommendations of this guideline as computable artifacts using the FHIR Clinical Reasoning Module:

[http://build.fhir.org/ig/cqframework/opioid-cds/ Opioid Prescribing Support Implementation Guide]

This scenario will focus on testing usage with the new order-select hook for recommendations #5, #10, and #11

Action: The chart is opened for a patient that is currently prescribed opioids and has not had the recommended urine drug screening, so the recommendation for a urine drug screening is displayed.
Success Criteria: An EHR user is provided appropriate guidance when viewing a patient that is currently prescribed opioids
Bonus Point: The logic accesses an extension as a first-class element of the model

For the purposes of this scenario, long-term opioid therapy is defined as use of opioids on most days for > 3 months, and the patient does not have metastatic cancer. To determine these, the CDS Service will need to access:

• Current Medication List
• Problem List
• Encounter Diagnoses within 12 months

For communicating medications, the service will expect information in a MedicationRequest or MedicationStatement, with at least the following supplied:

• Medication as an RxNorm code
• Dosage
• Frequency

The implementation guide provides computable artifacts describing the calculations for MME based on the CDC Guidance. The CDS Service can use these representations to provide the functionality described for this scenario.

TestScript(s)

All testing materials can be accessed from the Connectathon GitHub Repository: https://github.com/dbcg/connectathon

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.