This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "201809 Clinical Reasoning"

From HL7Wiki
Jump to navigation Jump to search
 
(25 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
[http://wiki.hl7.org/index.php?title=Category:201809_FHIR_Connectathon_Track_Proposals Return to September 2018 Proposals]
 
[http://wiki.hl7.org/index.php?title=Category:201809_FHIR_Connectathon_Track_Proposals Return to September 2018 Proposals]
 +
 +
[http://wiki.hl7.org/index.php?title=FHIR_Connectathon_19 Connectathon 19]
 
[[Category:201809_FHIR_Connectathon_Track_Proposals|September 2018 Proposals]]
 
[[Category:201809_FHIR_Connectathon_Track_Proposals|September 2018 Proposals]]
 
=Clinical Reasoning Track=
 
=Clinical Reasoning Track=
Line 7: Line 9:
 
# Running CMS eCQM Program Measures expressed with QDM directly against a FHIR Server
 
# Running CMS eCQM Program Measures expressed with QDM directly against a FHIR Server
 
# Using the new $care-gaps operation to produce Care Gap reports for patients
 
# Using the new $care-gaps operation to produce Care Gap reports for patients
−
# Sharing Quality Data using the $collect-data operation and Measure Subscriptions
+
# Sharing Quality Data using the $collect-data and $submit-data operations as well as Measure Subscriptions
  
−
For this track, we will be using the balloted STU4 version of FHIR.
+
For this track, we will be using both the STU3 and the balloted STU4 versions of FHIR.
 +
 
 +
BREAKOUT: Note there will be a breakout on Saturday from 2:00-3:00PM in the President's Room to discuss approaches to and challenges with reporting quality measurement results using FHIR.
 +
 
 +
PARTICIPANT: We will use the Connectathon Manager for tracking track participants, please register with the [http://conman.fhir.org/connectathon.html?event=baltimore2018 Connectathon Manager] and indicate you are participating in the Clinical Reasoning track.
  
 
==Orientation==
 
==Orientation==
Line 44: Line 50:
 
<!-- List of the individuals and/or organizations that have indicated a desire to attend the connectathon and implement this track -->
 
<!-- List of the individuals and/or organizations that have indicated a desire to attend the connectathon and implement this track -->
  
 +
* Apelon
 +
* Cerner
 +
* Dynamic Health IT
 +
* ESAC
 
* HarmonIQ Health Systems Corporation
 
* HarmonIQ Health Systems Corporation
−
* Apelon (pending)
+
* MITRE
−
* Motive Medical Intelligence (pending)
+
* Motive Medical Intelligence
 +
* NCQA
 
* Zynx Health (pending)
 
* Zynx Health (pending)
  
Line 56: Line 67:
 
===Measure Reporting Service===
 
===Measure Reporting Service===
 
A system that can evaluate Measures expressed in CQL using FHIR as the data source.
 
A system that can evaluate Measures expressed in CQL using FHIR as the data source.
 +
 +
Test server for connectathon support: http://measure.eval.kanvix.com/cqf-ruler/baseDstu3
  
 
==Scenarios==
 
==Scenarios==
Line 82: Line 95:
 
The scenario will use the same patient bundle used to test the HEDIS measures in previous runs. Note that due to differences in value sets between the HEDIS and eCQM measures, there may need to be some updates to the test data:
 
The scenario will use the same patient bundle used to test the HEDIS measures in previous runs. Note that due to differences in value sets between the HEDIS and eCQM measures, there may need to be some updates to the test data:
  
−
* [https://github.com/cqframework/hedis-ig/tree/master/resources Patient Bundles]
+
* [https://drive.google.com/open?id=12FKDLgawDBuuAOcRUfSdLp9i71Dja787 Measure Test Data]
  
 
:Action: A Measure Reporting Service performs an $evaluate-measure operation to calculate the results of a quality measure for a single patient. The inputs to this operation are:
 
:Action: A Measure Reporting Service performs an $evaluate-measure operation to calculate the results of a quality measure for a single patient. The inputs to this operation are:
Line 98: Line 111:
 
:Bonus point: Run the measure on a population, rather than a single patient:
 
:Bonus point: Run the measure on a population, rather than a single patient:
  
−
===Measure Data Collection===
+
===Measure Data Submission/Collection===
 +
 
 +
This scenario will test the new $submit-data and $collect-data operations defined for Measure:
 +
 
 +
  GET [base]/Measure/measure-mrp/$collect-data?patient=Patient-1234&lastUpdated=2018-06-11
 +
 
 +
This scenario will use the Data Exchange for Quality Measures profiles:
 +
 
 +
http://hl7.org/fhir/us/davinci-deqm/2018Sep/STU3/index.html
 +
 
 +
Specifically, we will use the 30-day Medication Reconciliation Post-discharge (MRP) use case. In this use case, we will use Da Vinci reference implementation. The scenario will test the $submit-data operation against a payer end-point. The Da Vinci EHR reference application will create the FHIR based on the measure-mrp profile and resource requirements.
  
−
This scenario will test the new $collect-data operation defined for Measure:
+
#DaVinci #DEQM
 +
This is the EHR Reference Implementation server endpoint for the Da Vinci Medication Reconcilation use cast to test the DEQM $submit-data operation - https://api-v5-stu3.hspconsortium.org/DaVinciEHRDemo2/open
  
−
GET [base]/Measure/measure-mrp/$collect-data?patient=Patient-1234&lastUpdated=2018-06-11
+
This is the Payer Reference Implementation server endpoint for this use case - https://api-v5-stu3.hspconsortium.org/DaVinciDemoPayer/open/
  
 
===Measure Subscription===
 
===Measure Subscription===
Line 108: Line 132:
 
This scenario will evaluate the ability to "subscribe" to a measure. To enable this functionality, a subscriber uses the FHIR Subscription resource to register interest in the data for a particular measure. The subscriber posts the Subscription to the EHR, and the EHR then notifies the subscriber when any changes are made to the data involved in the calculation of that measure.
 
This scenario will evaluate the ability to "subscribe" to a measure. To enable this functionality, a subscriber uses the FHIR Subscription resource to register interest in the data for a particular measure. The subscriber posts the Subscription to the EHR, and the EHR then notifies the subscriber when any changes are made to the data involved in the calculation of that measure.
  
−
1. The subscriber posts a Subscription resource to the EHR, indicating interest in the data for the measure for a patient
+
# The subscriber posts a Subscription resource to the EHR, indicating interest in the data for the measure for a patient
−
2. When data is changed that matches the subscription (as determined by manual development, or programatically by analysis of the DataRequirements for the Measure), the EHR notifies the subscriber
+
# When data is changed that matches the subscription (as determined by manual development, or programatically by analysis of the DataRequirements for the Measure), the EHR notifies the subscriber
−
3. The subscriber receives the notification and issues a $collect-data operation to the EHR, using the lastUpdated parameter to indicate when the last data collection was performed
+
# The subscriber receives the notification and issues a $collect-data operation to the EHR, using the lastUpdated parameter to indicate when the last data collection was performed
−
4. The EHR responds with a Bundle containing the data of interest for the requested measure.
+
# The EHR responds with a Bundle containing the data of interest for the requested measure.
  
 
===Care Gap Report===
 
===Care Gap Report===
Line 123: Line 147:
 
Whether the MeasureReport represents a gap in care for the patient is determined by the ImprovementNotation of the Measure and the calculated score for the patient.
 
Whether the MeasureReport represents a gap in care for the patient is determined by the ImprovementNotation of the Measure and the calculated score for the patient.
  
−
GET [base]/Measure/$care-gaps?patient=Patient-1234&topic=Preventive&20Care&20and&20Screening&periodStart=2018-01&periodEnd=2018-12
+
  GET [base]/Measure/$care-gaps?patient=Patient-1234&topic=Preventive&20Care&20and&20Screening&periodStart=2018-01&periodEnd=2018-12
  
 
===Prior Scenarios===
 
===Prior Scenarios===

Latest revision as of 18:40, 30 September 2018

Return to September 2018 Proposals

Connectathon 19

Clinical Reasoning Track

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

  1. Running CMS eCQM Program Measures expressed with QDM directly against a FHIR Server
  2. Using the new $care-gaps operation to produce Care Gap reports for patients
  3. Sharing Quality Data using the $collect-data and $submit-data operations as well as Measure Subscriptions

For this track, we will be using both the STU3 and the balloted STU4 versions of FHIR.

BREAKOUT: Note there will be a breakout on Saturday from 2:00-3:00PM in the President's Room to discuss approaches to and challenges with reporting quality measurement results using FHIR.

PARTICIPANT: We will use the Connectathon Manager for tracking track participants, please register with the Connectathon Manager and indicate you are participating in the Clinical Reasoning track.

Orientation

Clinical Reasoning Orientation Slides

Clinical Reasoning Orientation Recording

Zulip Chat

The Zulip Chat will be used to coordinate among participants during the connectathon:

Zulip Chat

Submitting WG/Project/Implementer Group

Justification

The CDS and CQI Work Groups are incorporating feedback from previous ballots, prior connect-a-thons, as well as other work groups to refine and improve the structures used to enable the representation and evaluation of quality artifacts using FHIR. These efforts have resulted in the FHIR Clinical Reasoning Module. The scenarios in this connect-a-thon track proposal exercise key resources and use cases of this module.


Proposed Track Lead

  • Bryn Rhodes
    • Email: bryn at databaseconsultinggroup dot com
    • Skype: bryn.rhodes

See Connectathon_Track_Lead_Responsibilities

Expected participants

  • Apelon
  • Cerner
  • Dynamic Health IT
  • ESAC
  • HarmonIQ Health Systems Corporation
  • MITRE
  • Motive Medical Intelligence
  • NCQA
  • Zynx Health (pending)

Roles

EHR

The EHR role in these scenarios functions as the system-of-record for clinical information.

Measure Reporting Service

A system that can evaluate Measures expressed in CQL using FHIR as the data source.

Test server for connectathon support: http://measure.eval.kanvix.com/cqf-ruler/baseDstu3

Scenarios

The Clinical Reasoning Module provides documentation for the resources that will be exercised by the above roles. Specifically, the following resources are utilized as part of those scenarios:

QDM Mapping

The 2018 Annual Update for CMS Quality Reporting Programs includes electronic Clinical Quality Measures (eCQMs) specified using Clinical Quality Language (CQL) and Quality Data Model (QDM). This scenario will use the QDM-to-QI-Core mappings described in the QI-Core Implementation Guide to evaluate eCQMs directly against a FHIR server.

Tooling required to support this evaluation will be provided in the form of a QDM-to-FHIR plug-in for the Java-based CQL engine.

The scenario will focus on 3 eCQM program measures:

The scenario will use the same patient bundle used to test the HEDIS measures in previous runs. Note that due to differences in value sets between the HEDIS and eCQM measures, there may need to be some updates to the test data:

Action: A Measure Reporting Service performs an $evaluate-measure operation to calculate the results of a quality measure for a single patient. The inputs to this operation are:
 Measure to be evaluated (this is part of the url of the request)
 Patient Id
 PeriodStart - The start of the measurement period
 PeriodEnd - The end of the measurement period

 GET [base]/Measure/cms125v7/$evaluate-measure?patient=Patient-1234&periodStart=2018-01-01&periodEnd=2018-12-31
Precondition: The EHR must be prepopulated with information for the given patient that satisfies the requirements of the measure being evaluated.
Success Criteria: The operation produces a MeasureReport for the patient.
Bonus point: Run the measure on a population, rather than a single patient:

Measure Data Submission/Collection

This scenario will test the new $submit-data and $collect-data operations defined for Measure: 

 GET [base]/Measure/measure-mrp/$collect-data?patient=Patient-1234&lastUpdated=2018-06-11

This scenario will use the Data Exchange for Quality Measures profiles:

http://hl7.org/fhir/us/davinci-deqm/2018Sep/STU3/index.html

Specifically, we will use the 30-day Medication Reconciliation Post-discharge (MRP) use case. In this use case, we will use Da Vinci reference implementation. The scenario will test the $submit-data operation against a payer end-point. The Da Vinci EHR reference application will create the FHIR based on the measure-mrp profile and resource requirements.

  1. DaVinci #DEQM

This is the EHR Reference Implementation server endpoint for the Da Vinci Medication Reconcilation use cast to test the DEQM $submit-data operation - https://api-v5-stu3.hspconsortium.org/DaVinciEHRDemo2/open

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

Measure Subscription

This scenario will evaluate the ability to "subscribe" to a measure. To enable this functionality, a subscriber uses the FHIR Subscription resource to register interest in the data for a particular measure. The subscriber posts the Subscription to the EHR, and the EHR then notifies the subscriber when any changes are made to the data involved in the calculation of that measure.

  1. The subscriber posts a Subscription resource to the EHR, indicating interest in the data for the measure for a patient
  2. When data is changed that matches the subscription (as determined by manual development, or programatically by analysis of the DataRequirements for the Measure), the EHR notifies the subscriber
  3. The subscriber receives the notification and issues a $collect-data operation to the EHR, using the lastUpdated parameter to indicate when the last data collection was performed
  4. The EHR responds with a Bundle containing the data of interest for the requested measure.

Care Gap Report

In this scenario, a new operation has been defined to support producing a Gaps-in-Care report for an individual patient. This report is returned as a FHIR Document, structured as follows: 

 Bundle
   Composition - The first entry in the bundle will be a composition resource describing the overall document
   MeasureReport - The bundle then contains measure reports for each measure that was calculated for the patient.

Whether the MeasureReport represents a gap in care for the patient is determined by the ImprovementNotation of the Measure and the calculated score for the patient. 

 GET [base]/Measure/$care-gaps?patient=Patient-1234&topic=Preventive&20Care&20and&20Screening&periodStart=2018-01&periodEnd=2018-12

Prior Scenarios

Note that the content is still available for scenarios run during previous connectathons including

  • CDC Opioid Guidance
  • CDC Zika Virus Management Guidance
  • Diabetes Management
  • PlanDefinition Exchange
  • CarePlan Integration
  • HEDIS Measure Evaluation



TestScript(s)

Retrieved from "https://wiki.hl7.org/w/index.php?title=201809_Clinical_Reasoning&oldid=161869"