201705 Clinical Reasoning Track
Clinical Reasoning Track
This track defines several scenarios related to clinical quality that exercise the resources defined by the Clinical Decision Support and Clinical Quality Information Work Groups, as well as profiles and usage guidance defined in the Clinical Quality Framework Implementation Guide.
Participant Pack
This document provides the latest information for connectathon participants including server links and example resources:
Zulip Chat
The Zulip Chat will be used to coordinate among participants during the connectathon:
Submitting WG/Project/Implementer Group
- Clinical Decision Support Work Group
- Clinical Quality Information Work Group
- Clinical Quality Framework Initiative
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
- National Comprehensive Cancer Care Network (NCCN)
- Evinance
- ESAC, Inc.
- HarmonIQ Health Systems Corporation
- University of Utah
Roles
CDS Service
The CDS Service role provides real-time clinical decision support services. This component enables a consumer to request clinical decision support based on the current context. The consumer provides relevant contextual information as part of the request, and receives clinically relevant guidance as a set of resources describing potential actions to be taken.
EHR
The EHR role consumes real-time clinical decision support services. The client integrates decision support at appropriate points in clinical workflow, allowing users of the system to respond to the guidance presented by the decision support system.
Knowledge Management Repository
A FHIR Server that implements search and retrieval functionality for the various quality artifact resources.
Knowledge Artifact Consumer
A system that consumes knowledge artifacts from a knowledge management repository
Order Set Service
A service capable of evaluating order set definitions to produce order sets applicable to a specific patient and/or context.
Order Set Client
A client capable of requesting the evaluation of an order set definition for a specific patient and/or context, and consuming the resulting order set instance.
Measure Reporting Service
A system that provides measure evaluation results
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:
CDC Opioid Guidelines Scenario
The Centers for Disease Control and Prevention (CDC) have issued guidelines relating to the prescription of opioids:
An implementation guide is being produced that represents portions of this guideline as computable artifacts using the FHIR Clinical Reasoning Module:
Opioid Prescribing Support Implementation Guide
This scenario will focus on recommendation #5 from the guideline, that providers should take additional precautions when prescribing dosages at or above 50 morphine milligram equivalents (MME/day):
- Action: A patient is being prescribed opioids for chronic pain that result in a total MME/day of >= 50 and < 90. The EHR calls a CDS Service to evaluate the medication being prescribed and receives a message that the patient is at high risk for opioid overdose, and tapering dosage should be considered.
- Success Criteria: An EHR user is provided appropriate guidance when prescribing opoids
- Bonus Point: The service returns a recommended reduced dosage and the user is able to accept that modification to the order
For the purposes of this scenario, long-term opioid therapy is defined as use of opoids 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
NCCN Chemotherapy Regimen Scenario
In this scenario, a Knowledge Artifact Provider defines and distributes an NCCN Chemotherapy Regimen to a Knowledge Artifact Consumer.
This scenario is part of the ONC Tech Lab NCCN Order Templates Project.
Retrieve an Order Template
- Action: An Artifact Consumer retrieves the latest version of a specific order template
- Precondition: An Artifact Repository has appropriate order templates defined to support the retrieval
- Success Criteria: A participant can successfully use the FHIR Server to retrieve the PlanDefinition resource describing the order template
- Bonus point: The service supports searching by indications in addition to disease
- Bonus point: The consumer can successfully validate the PlanDefinition using the NCCN Profile
Ingest an Order Template
- Action: An Order Set Service imports a simple Order Template definition that contains no optionality
- Precondition: A PlanDefinition has been retrieved from an Artifact Repository
- Success Criteria: The Order Set Service can now apply the imported plan definition
- Bonus point: The Order Set Service ingests a plan definition with optionality
Apply an Order Template for a specific patient
- Action: An Order Set Client applies a given order template to a specific patient
- Precondition: The Order Sset Service has an appropriate operation defined to support application (this may be $apply on PlanDefinition, or it may be a ServiceDefinition/$evaluate)
- Success Criteria: The Order Set Client receives an appropriately built CarePlan resource
- Bonus point: The service returns a CarePlan with a RequestGroup to support describing optionality at different levels
Determine Adherence (On/Off Protocol) (TBD)
- Action:
- Precondition:
- Success Criteria:
- Bonus point:
Payer Extract Scenario
In this scenario, a Payer uses a Measure Processing Component to extract relevant data from an EHR to enable computation of payer quality measures.
Three cohort definition measures are supported for these scenarios:
- Controlling Blood Pressure (Observation resources conforming to the DAF-Vital Sign profile, blood pressure measurements)
- Adult BMI Assessment (Observation resources conforming to the DAF-Vital Sign profile, height and weight measurements)
- Colorectal Cancer Screening (Condition, Procedure, and Observation resources)
Single Measure Individual Open Access
- Action: A Payer issues an $evaluate-measure operation to a Measure Processor to determine required patient information. The inputs to this operation are:
- Measure to be evaluated (this is part of the url of the request)
- Patient Id
- Last Retrieved On (the date the data was last retrieved, only data that is new/updated since this date should be returned)
- Precondition: The EHR must be prepopulated with information for the given patient that satisfies the requirements of the measure being evaluated.
- Success Criteria: The Payer receives a MeasureReport with the url to a Bundle containing the required patient information.
- Bonus point: Use the Last Retrieved On parameter in successive executions to demonstrate incremental data exchange
Multiple Measures
- Action: A Payer issues an $evaluate-measure operation to a Measure Processor to determine required patient information for multiple measures in a single request. The results are combined in a single bundle to minimize bandwidth usage.
- Precondition: The EHR must be prepopulated with information for the given patient that satisfies the requirements of the measures being evaluated.
- Success Criteria: The Payer receives a MeasureReport with the url to a Bundle containing the required patient information.
- Bonus point: Demonstrate that a patient resource that was involved in multiple measures is communicated only once in the results.