201601 CDS on FHIR Connectathon Track Proposal

CDS on FHIR

This Connectathon track has several goals.

First, this track aims to use the new KnowledgeModule resource and the accompanying Clinical Quality Improvement Framework (CQIF) IG to inform the direction of Clinical Quality work in FHIR. Specifically, we propose working with the various CDS-related initiatives currently being worked on in FHIR to help solidify the design of the KnowledgeModule and related resources and profiles.

Second, this track also aims to gather real-world implementer feedback on the CDS Hooks proposal from Josh Mandel to provide open clinical decision support using both FHIR and SMART.

The Connectathon facilitators have asked that all confirmed participants fill out the spreadsheet at the following link:

Connectathon Participant Spreadsheet

If you haven't already, and plan on attending (or participating remotely), please make sure you've entered your information there.

Submitting WG/Project/Implementer Group

Several groups have joined together in asking for this track:

• Clinical Decision Support Work Group
• Clinical Quality Information Work Group
• Clinical Quality Framework Initiative
• A group of vendors and developers whom support the CDS Hooks proposal.

Justification

There is currently a lot of interest in the clinical quality community in how best to use FHIR to advance the goals of improving patient care through the effective use of quality measurement and intervention. At the same time, there are currently multiple approaches being used within the FHIR community, motivated by different use cases. This connectathon track will provide a vehicle for exploring how best to approach the implementation of these use cases in decision support and quality measurement scenarios.

Additionally, CDS Hooks allow for a very important use of both FHIR and SMART that is outside of the normal transactional flow of data. With CDS Hooks, EHRs can further integrate FHIR and SMART into the workflow with clinical decision support. Today, CDS Hooks have a relatively small visibility by the FHIR community as it is a fairly new proposal. With a track at a Connectathon, CDS Hooks would be exposed to the larger FHIR community, allowing others to see how FHIR can be used to provide clinical decision support in the EHR.

Proposed Track Leads

CQIF

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

CDS Hooks

• Kevin Shekleton
  • Email: kevin dot shekleton at cerner dot com
  • Skype: kevin.shekleton

Track Skype Chat

The CDS-on-FHIR Track has a Skype chat to coordinate preparation and participation in the track:

CDS-on-FHIR Connectathon Track Skype Chat

Expected participants

The following individuals and organizations will take part in the CQIF portions of this track:

• MITRE (possibly) in connection with the quality measurement scenarios/resources
• Partners Healthcare [Guidance Service]

The following individuals and organizations will take part in the CDS Hooks portion of this track:

• Cerner (Kevin Shekleton) [EHR, CDS Service]
• SMART Health IT (Josh Mandel) [EHR, CDS Service]
• Intermountain Health Care (Craig Parker) [CDS Service]
• RxREVU (Peregrin Marshall) [CDS Service]
• Premier, Inc (Kalyani Yerra) [CDS Service]
• Premier, Inc (Bill Harty) [CDS Service]
• Elsevier (David Yoshikawa) [CDS Service]
• Gajen Sunthara (Boston Children's Hospital) [CDS Service]

Roles

Guidance Service

A FHIR Server that implements the $evaluate operation as defined on the DecisionSupportModule resource.

Guidance Client

A client that consumes guidance from a FHIR Server using the $evaluate operation.

EHR

The EHR will allow for the registration of interested CDS services on various CDS hooks, triggering each appropriately. The EHR will also display the CDS cards (obtained from the CDS services) to the user.

CDS Service

The CDS service will register themselves for the CDS hooks they are interested in and return CDS cards in response to trigger events as necessary.

Scenarios

CQIF

The Clinical Quality Improvement Framework Implementation Guide provides documentation for the resources that will be exercised by the Guidance Service and Guidance Client roles. Specifically, the following resources are utilized as part of those scenarios:

• ModuleMetadata
• DecisionSupportServiceModule
• GuidanceResponse
• $evaluate operation

IHE Radiology Guidance Request Scenario

Action: A Guidance Client issues an $evaluate operation to a Guidance Service against the IHE Radiology Appropriateness Knowledge Module

Precondition: The GuidanceService must have the $evaluate operation implemented and be able to process requests for the IHE Radiology Appropriateness Knowledge Module

Success Criteria: The Guidance Client receives an appropriately filled GuidanceResponse and the appropriate resources for the radiology request as described in the IHE Radiology Appropriateness IG.

Bonus point:

CDC Immunization Guidance Scenario

Action: A Guidance Client issues an $evaluate operation to a Guidance Service against the CDC Immunization Decision Support Service Module

Precondition: The GuidanceService must have the $evaluate operation implemented and be able to process requests for the CDC Immunization Decision Support Service Module

Success Criteria: The Guidance Client receives appropriate immunization guidance based on the patient information provided in the request. The service provides guidance using the current CDC Immunization Guidelines. The test script is written with a male infant and receives an appropriate immunization schedule as ImmunizationRecommendation resources.

Bonus point: Handle error scenarios including:

• Unauthorized: Perform the request with an invalid organization ID
• Incomplete: Perform the request without providing birth date or gender. The response will still provide an immunization schedule, but with appropriate warnings about the use of clinical judgement in administering immunizations.
• Malformed: Perform the request with invalid data. The response will be an OperationOutcome with an appropriate description of the error that occurred.

Price Check Guidance Request Scenario (cds-hooks)

Action: A Guidance Client requests a CMS Price Check from a Guidance Service

Precondition: The GuidanceService must have the $guidance operation implemented and be able to process requests for the CMS Price Check Knowledge Module

Success Criteria: The Guidance Client receives an appropriately filled GuidanceResponse and the appropriate actions describing the result of the price check as described in the CDS Hooks overivew.

Bonus point:

CDS Hooks

These scenarios exercise the three basic card types (information, suggestion, and app link) and three activity triggers (patient-view, medication-prescribe, and order-review).

Fill out our sign-up sheet!

Please sign up to participate using our sign-up sheet in Google Docs. Be sure to provide your basic contact details on the first tab, and then details about any EHR or CDS Services you'll be bringing to the table on the 2nd and 3rd tabs.

Display a CDS Information Card when opening a patient record (patient-view)

Action: The EHR triggers a patient-view hook to the subscribed CDS Service, which returns a CDS information card.

Precondition: N/A

Success Criteria: The EHR displays the resultant CDS information card.

Bonus point: The CDS information card contains contextually relevant data about the patient based upon information about the patient from the FHIR server.

Display a CDS App Link Card when opening a patient record (patient-view)

Action: The EHR triggers a patient-view hook to the subscribed CDS Service, which returns a CDS app link card.

Precondition: N/A

Success Criteria: The EHR displays the resultant CDS app link card and clicking the app link launches the desired SMART app.

Bonus point: The CDS app link card is only returned based upon contextually relevant data from the patient.

Display a CDS Information Card commenting on a prescription at prescribing time (medication-prescribe)

Action: The EHR triggers a medication-prescribe hook to the subscribed CDS Service, which returns a CDS information card to be displayed to the user in a non-modal view.

Precondition: An EHR user is in the process of writing a prescription

Success Criteria: The EHR displays the resultant CDS suggestion card to change the prescription-in-progress for the patient. If the user clicks to accept the suggestion, the prescribing screen is updated to reflect the change.

Bonus point: The CDS suggestion card is only returned when it is contextually relevant (i.e. no information card should say the equivalent "nothing to report").

Display a CDS Suggestion Card to Cancel a Medication at order review time (order-review)

Action: The EHR triggers an order-review hook to the subscribed CDS Service whom returns a CDS suggestion card to cancel the proposed order.

Precondition: A proposed order exists for the patient.

Success Criteria: The EHR displays the resultant CDS suggestion card to cancel the proposed order for the patient. If the user selects to accept the suggestion, the proposed order is canceled.

Bonus point: The CDS suggestion card is only returned based upon contextually relevant data from the patient. For instance, perhaps the medication is only suggested for cancellation if the patient is allergic to the medication.

Display a CDS Suggestion Card to Order an additional Medication at order review time (order-review)

Action: The EHR triggers an order-review hook to the subscribed CDS Service whom returns a CDS suggestion card to create a new medication.

Precondition: A proposed order exists for the patient.

Success Criteria: The EHR displays the resultant CDS suggestion card to replace the proposed order for the patient with a new order. If the user selects to accept the suggestion, the proposal is accepted.

Bonus point: The CDS suggestion card is only returned based upon contextually relevant data from the patient. For instance, perhaps the medication is only suggested for replacement if a cheaper suitable medication is found.