201704 Clinical Reasoning Track

Return to April 2017 Value-Based Care FHIR Mini-Connectathon

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.

This track will coordinate with:

• Care Plan - Care Plan Creator Role

Participant Pack

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

Participant Pack

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
• 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 several resources and related implementation guides that will be balloted both as part of the FHIR STU 3 ballot and as separate implementation guides in the upcoming September 2016 ballot cycle. The scenarios in this connect-a-thon track proposal are intended to support that ballot by exercising key resources and use cases in the implementation guides.

Proposed Track Lead

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

See Connectathon_Track_Lead_Responsibilities

Expected participants

• ESAC, Inc.
• HarmonIQ Health Systems Corporation
• Transcend Insights?
• Optum?

Roles

Measure Reporting Service

A system that provides measure evaluation results

Provider System

A provider system (typically an EHR) that provides access to the patient information for a provider.

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:

• Measure
• MeasureReport

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.