201801 Clinical Reasoning

Return to Jan 2018 Proposals

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 Reasoning Module.

For this track, we will be using the published STU3 version of FHIR.

This track will coordinate with:

• CDS Hooks

Participant Pack

This document provides the latest information for connectathon participants including server links and example resources:

Participant Pack

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

• Clinical Decision Support Work Group
• Clinical Quality Information Work 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
• ESAC, Inc.
• HarmonIQ Health Systems Corporation
• Michigan Health Information Network
• National Committee for Quality Assurance
• Optum
• University of Utah
• Zynx Health
• Motive Medical Intelligence

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.

For this role, the service is implemented using the CDS Hooks specification.

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.

For this role, the EHR uses the CDS Hooks specification to invoke decision support.

Knowledge Artifact Repository

A FHIR Server that implements search and retrieval functionality for the various knowledge artifact resources.

Knowledge Artifact Consumer

A system that consumes knowledge artifacts from a knowledge artifact 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:

• ActivityDefinition
• Library
• Measure
• PlanDefinition
• RequestGroup

In addition, the CDS Hooks specification is used to provide real-time provider-facing decision support integration with a guidance consumer:

• CDS Hooks

CDC Opioid Guideline Scenario

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

Opioid Prescription Guideline

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

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.

Zika Virus Reporting Scenario

The ability to quickly address newly emerging clinical hazards using clinical decision support is essential to assure providers and patients have useful and appropriate information in a timely fashion. Such an "all hazards approach" must identify appropriate triggers, determine presence or absence of exposure criteria and recommend testing and treatment. Zika virus exposure is an excellent example of a condition with highly significant impact for pregnant women and their developing children. Zika virus also represents an evolving clinical situation requiring content refresh frequently to evaluated and manage patients effectively to improve the care and recommendations provided. The scenario will address methods to implement triggers, and recommend timely and appropriate evaluation, testing, and follow up. Specifically, the laboratory test ordered varies baed on the timing and presence or absence of symptoms, and the time of exposure. The scenario will address the clinical workflow to provide patient care and to report accurate and complete information to public health.

In this scenario, a patient presents at the point-of-care, and Zika Virus management is triggered if the patient is a woman of child-bearing age. As an alternative, Zika Virus management may be triggered by a mobile application that detects travel to an area where Zika exposure is an identified risk.

This scenario is part of the ONC Tech Lab Zika Virus Project

Identify Zika Risk and Recommend Testing

Action: A pregnant patient presents for care, the system requests guidance for Zika reporting and collections information to identify non-frequent travel, no symptoms, returned 1 week ago, PCR negative, run IgM (positive), then PRNT (result Zika virus > 10)

Precondition: The system is configured to trigger the Zika guidance when a patient presents for care.

Success Criteria: The system recommends appropriate testing based on the Zika All Hazards Approach.

Recent Zika Virus Infection

Action: When recent Zika Virus Infection is detected for a pregnant patient, recommend ultrasound, consider amniocentesis, and consider reporting to the health department

Precondition: Lab results have been returned indicating presence of Zika Virus infection.

Success Criteria: The system recommends appropriate ultrasound and amniocentesis based on the recent infection

Bonus Point: The system creates an electronic Initial Case Report (eICR) for submission to RCKMS to determine reportability.

Quality Measure Evaluation Scenario

In this scenario, a Measure Reporting Service uses a Measure Processing Component to extract relevant data from an EHR and evaluate quality measures.

For this scenario, the National Committee for Quality Assurance has made the HEDIS Implementation Guide available. In particular, the following three HEDIS measures provide a focus for testing and evaluation:

• Colorectal Cancer Screening (Condition, Procedure, and Observation resources)
• Cervical Cancer Screening
• Breast Cancer Screening

The Measure Artifacts for these measures can be accessed on the following test server:

• Colorectal Cancer Screening
• Cervical Cancer Screening
• Breast Cancer Screening

Patient bundles to test these measures can be found here:

• Patient Bundles

The participant pack linked at the top of this track also contains more information about this scenario, including example request/responses that can be used to test measure evaluation.

Single Measure Individual Open Access

Action: A Quality Measure Data Consumer issues an $evaluate-measure operation to a Quality 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

Single Measure Population Open Access

Action: A Quality Measure Data Consumer issues an $evaluate-measure operation to a Quality Measure Processor to evaluate a measure for a population. The inputs to this operator are:

• Measure to be evaluated (this is part of the url of the request)

Precondition: The FHIR Server must be prepopulated with the information for the population

Success Criteria: The requester receives a MeasureReport containing the population level evaluation results for the measure

Bonus point: Use data from the Bulk Data API to perform the evaluation

Multiple Measures

Action: A Quality Measure consumer issues an $evaluate-measure operation to a Quality 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.

Diabetes Care Management for Population Health Management

Successful longitudinal care management for population health management requires the continuous delivery of the right care at the right time by the right role to each member of a population. It requires the contextual processing of clinical knowledge artifacts against patient-specific clinical data within a multitude of systems that are used to provide care and care management.

This scenario will focus on the delivery of recommendations for diabetes care management to a population health management platform other than the EHR. It will incorporate the use of HL7 standards to accomplish the following:

• Transmission of clinical data between systems using V2, V3, CDA, ADT, ORU, and other HL7 standards
• Authoring and publication of evidence-based rules and interventions using CQL and FHIR
• Invocation of real-time CDS guidance for diabetes care through a CDS service implemented using CDS Hooks

This scenario is part of ongoing work by Motive Medical Intelligence and Edifecs. The diabetes care guidance demonstrated in this scenario is excerpted from a diabetes mellitus, type 2, care management program developed by Motive.

Guidance for Initial Diagnosis of Diabetes Mellitus, Type 2

Action: When clinical data are received for an adult member, the population health management platform requests guidance for care management actions for a patient with newly diagnosed diabetes mellitus, type 2.

Precondition: New clinical data are received as HL7 messages and transformed to FHIR. The patient data in FHIR are sent to the CDS service as part of a CDS Hooks request. A new active problem of diabetes mellitus, type 2, is documented as part of the data included in this request.

Success Criteria: The CDS service recommends an initial assessment of diabetes diet management and a hepatitis B immunization to the practitioner.

Bonus Point: The CDS service will provide a list of the patient data that satisfy the criteria of the rule in the response.

Closure of Hepatitis B Immunization Gap and Guidance on Recent HbA1c Result

Action: When additional clinical data for the adult member are received by the population health management platform, the platform requests further guidance for ongoing diabetes care management.

Precondition: New clinical data are received as HL7 messages and transformed to FHIR. The patient data are sent to the CDS service as a FHIR bundle in a CDS Hooks request. These data contain an active problem of diabetes mellitus, type 2; documentation of a completed hepatitis B vaccine series; and the most recent HbA1c result reported in the past 30 days greater than 7%.

Success Criteria: The CDS service suppresses the hepatitis B immunization recommendation and notifies the care manager that the HbA1c value is out of range.

Bonus Point: The CDS service will provide a list of the patient data that satisfy the criteria of the rule in the response.