This wiki has undergone a migration to Confluence found Here

Difference between revisions of "201701 Clinical Reasoning Track"

From HL7Wiki
Jump to navigation Jump to search
Line 72: Line 72:
*[ RequestGroup]
*[ RequestGroup]
*[ ServiceDefinition]
*[ ServiceDefinition]
===Scenario Step 1 Name===
:Action: <!--Who does what?  (Use the role names listed above when referring to the participants -->
:Precondition: <!-- What setup is required prior to executing this step? -->
:Success Criteria: <!-- How will the participants know if the test was successful? -->
:Bonus point: <!-- Any additional complexity to make the scenario more challenging -->
===NCCN Chemotherapy Regimen Scenario===
===NCCN Chemotherapy Regimen Scenario===

Revision as of 21:01, 10 November 2016

Return to January 2017 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 Quality Framework Implementation Guide.

This track will coordinate with:

Submitting WG/Project/Implementer Group


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

  • National Comprehensive Cancer Care Network (NCCN)
  • Evinance
  • ESAC, Inc.
  • HarmonIQ Health Systems Corporation
  • University of Utah
  • Prime Dimensions


Guidance Service

The Guidance 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.

Guidance Client

The Guidance Client 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


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:

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.

Search for and Retrieve an Order Template

Action: An Artifact Consumer searches for an order template based on appropriate criteria (disease, for example) and retrieves the latest version of a specific order template
Precondition: An Artifact Repository has appropriate order templates defined to support the search and 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

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)

Success Criteria:
Bonus point:

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.

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.

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

Three cohort definition measures are supported for this scenario:

  • 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)