Use Cases

syapse-terry edited this page Jan 9, 2016 · 1 revision

This section is devoted to real-world use cases for CDS hooks. The goal is to inform not only future versions of the spec, but how vendors (such as EHRs) incorporate it into their applications, such as where and when cards are displayed within EHRs.

Synchronous, workflow-triggered CDS calls returning information and suggestions

In these use cases, the EHR calls out to the CDS system, which returns a card triggering some action in the EHR.

Action-Oriented/Required Action

Often the cards returned by the CDS system to the EHR should be acted on by the clinician immediately. These will likely be implemented with a modal window presented to the clinician for follow up; a clinician who declines to take action would have to consciously dismiss the notification.

Case: Opening patient record prompts action in CDS system

Actors

  • Clinician
  • EHR
  • CDS system

Preconditions

A patient record exists in both the EHR and CDS systems. The CDS system has new information on the patient relevant to care, such as a newly-opened clinical trial for which the patient is qualified.

Flow of Events

  1. The clinician opens the patient's chart in the EHR, triggering this workflow.
  2. The EHR queries CDS service with patient context. CDS service returns a card with a deep link to the trial match within the CDS application.
  3. The clinician evaluates whether the trial is a good fit for the patient. If so, the physician may initiate enrollment through the CDS application.
  4. The clinician returns to the EHR to continue patient care.

Postconditions

Patient enrolled in clinical trial, or match dismissed.

Case: Placing a medication order prompts CDS guidance in EHR

Actors

  • Clinician
  • EHR
  • CDS system

Preconditions

The CDS system provides a medication decision support engine more complex than the one available within the EHR.

Flow of Events

  1. The clinician opens the patient's chart in the EHR.
  2. The clinician selects a medication order for the patient, triggering this workflow.
  3. The EHR queries CDS service with patient and medication context. The CDS service uses FHIR to query the EHR for any additional information necessary to make a decision, such as current medications or genomic data (or the information was already present in the CDS system, if the additional API calls would cause a perfomance issue).
  4. The CDS service returns a suggestion card with a delete of the medication and an explanation of the rationale.
  5. The clinician reviews the warning and optionally decides on an alternate course of therapy.

Postconditions

N/A

In-line decision support or CDS-system-driven configurability in the EHR

In some cases, a CDS service may want to surface information to a clinician without interrupting a workflow (reducing alert fatigue). The EHR processes the response from the CDS system in a more subtle manner, such as by displaying an in-line warning or adding a new activity to the patient workspace.

Case: A CDS client provides a genomics-specific patient view that should be conditionally available in the patient profile

Actors

  • Clinician
  • EHR
  • CDS system

Preconditions

A patient record exists in both the EHR and CDS systems. The CDS system includes structured genomic data that is not available in the EHR. The CDS system provides a genomics-focused, patient-specific view designed to be embedded in an EHR as a reference. This view allows the clinician to drill-down into a patient's genomic results as well as provides reference information such as the patient's metabolizer status for various classes of medications. The EHR is configured to extend the patient profile upon response of [TBD (a specific type/parameter of information card?)].

Flow of Events

  1. The clinician opens the patient's chart in the EHR, triggering this workflow.
  2. The EHR queries CDS service with patient context. The CDS service returns a card indicating that the patient has genomic data recorded in the CDS system. The card may contain context for supported configuration parameters.
  3. The patient workspace is loaded with the additional view available to the clinician. Depending on the capabilities of the EHR, this may be something like an embedded browser window as an available activity, or adding to a list of available reports.
  4. No active notification is displayed to the clinician, but the clinician can open the view provided by the CDS system if desired.

Launching a user-facing SMART app when CDS requires deeper interaction

In some cases the CDS system needs more information from a user before making a concrete recommendation. The CDS service responds with an App Link card, prompting the user to open the CDS client and take action. Once the user returns to the EHR, the CDS service will (optionally) return a decision card, driving some action in the EHR.

Action-Oriented/Required Action

Case: Opening patient record prompts decision in CDS system

Actors

  • Clinician
  • EHR
  • CDS system

Preconditions

A rules engine in the CDS system is configured to recommend additional therapies indicated for a patient based on the patient's history and genomic profile. In this case, the patient matches at least one therapy.

Flow of Events

  1. The clinician opens the patient's chart in the EHR, triggering this workflow.
  2. The EHR queries the CDS service with patient context. The CDS service uses FHIR to query the EHR for any additional information necessary to make a decision, such as current medications or genomic data (or the information was already present in the CDS system, if the additional API calls would cause a perfomance issue).
  3. The CDS service returns a card with a deep link to the suggested therapies within the CDS application.
  4. The clinician reviews the therapy suggestions in the CDS system and optionally selects one to order.
  5. The CDS system returns a decision card to the EHR with the information required for the therapy to be ordered.

Postconditions

Order for relevant therapy queued in EHR, or guidance dismissed.

Long-running, non-modal CDS sessions that observe EHR activity in progress

This is not yet detailed in the specification.