Da Vinci Alerts Implementation Guide (Release 0.1.0 STU1 Ballot)

This page is part of the Da Vinci Unsolicited Notifications (v1.0.0: STU1) based on FHIR R4. This is the current published version. For a full list of available versions, see the Directory of published versions

Da Vinci Alerts

The HL7 Da Vinci Project has recognized a need for communication of Alerts between payers, providers and other actors in the healthcare space. Alerts are defined as a need to notify another party of an event that would affect patient care. Alerts allow actors participating in the patient’s healthcare to take actions and intervene earlier to assure the patient is better cared for. This can also result in reduced costs.

How to read this Guide

This Guide is divided into several pages which are listed at the top of each page in the menu bar.

  • Home: The home page provides the introduction and background for the Da Vinci Alert Project.

  • Framework: These pages provide guidance on the set of FHIR transactions and the FHIR artifacts used in to provide a general framework to enable alert notifications.
  • Use cases: The Admission/Discharge example shows how to implement an alert use the framework.
  • Profiles: This page lists the set of Profiles that are defined in this guide to exchange quality data.
  • Operations: This page lists the standard FHIR and DEQM defined Operations that are used in the DEQM transactions to exchange quality data.
  • Capability Statements: This set of pages describes the expected FHIR capabilities of the various DEQM actors.
  • Security: General security requirements and recommendations for Da Vinci Alerts actors.
  • Examples: List of links to all the examples used in this guide.
  • Downloads: This page provides links to downloadable artifacts.

Scope and Usage

The work of this Implementation Guide is to:

  1. Define a technical framework for sending alert data to the appropriate actors when triggered by an event or request.
  2. Define the minimal data elements needed to support the information needs that are appropriate for 80% of users. Users requiring more data may follow up with additional queries.
  3. Define a FHIR Bundle that is a common data model exchanged for all alert transactions.

It is important that the framework allow for only appropriate alerts to be sent at the appropriate time and with just the right amount of information. This will serve to reduce alert fatigue. It is anticipated that the burden of communicating the alert is also reduced by using FHIR.

Out Of Scope

The following items are out of scope for this implementation guide:

  • What constitutes a trigger (nature of the event as defined in your organization)
    • Including alerts without an event
  • “Endpoint Discovery” and maintenance
  • Creation of the FHIR equivalent of v2 Messaging
  • Distribution beyond FHIR Endpoints (e.g. SMS, email)
  • Bidirectional Work, such as Gaps in Care
  • Any alert notification that requires workflow management such as Task
  • Complex content
  • Besides the standard http response, the Alert Recipient’s workflow upon receipt of alert.
    • Note, the Alert Recipient may initiate a FHIR RESTful query for additional data.

Scenarios

Alerts can be generated for many scenarios. The 2019 CMS 45 CFR Part 156 NPRM focuses on hospitalization due to significant issues that can occur if a patient is not followed appropriately after acute care. The initial version of the Alert Implementation Guide will focus on the Admission and Discharge Scenarios, basically anything that would create an encounter in a patient care record. The framework as defined may support the other scenarios as listed below and work will continue on this in future versions of the Implementation Guide in collaboration with domain experts for each scenario.

Initial Phase:

  • Emergency and Inpatient Admissions
  • Admission for Observation
  • Admission for special services, such as outpatient surgery
  • Encounter/Visit Notification for ambulatory services
  • Discharges/Visit ends

Potential Future Scenarios

These scenarios may be defined in cooperation with the appropriate HL7 International Working Group for inclusion in a future version of this guide:

  • Lab Results
  • Problem with Treatment – such as drug recall, device recall/issue
  • Public Health Notification
  • Scheduled Appointment/Pre-Admit
  • Referral
  • Ordered Device/Biometric/Patient (i.e. Fit Bit)
  • Treatment Start/End
  • Change in Social Determinants of Health
  • Birth/Death
  • Coverage Start/End
  • Notification of Prior Authorization (Pended to Approved/Denied)
  • Pharmacy (Pickup, Restock, Dispense)
  • Notification of New Condition
  • Work Comp Initial/Visits/Services
  • Changes in Care Team

Roles and Actors

Alert Roles

  • Alert Sender - the system responsible for sending the alert, typically operated by the facility or organization where the event occurred
  • Alert Recipient – the system responsible for receiving generated alerts from Alert Senders
  • Alert Intermediary (e.g. ClearingHouse or HIE/HIN)– a system that can act as a central point to receive alerts from multiple Alert Senders and distribute alerts to Alert Recipients based on previously defined subscription policies

Alert Actors

There are many potential actors for the roles listed above:

Figure 1
alert_actors.svg

Workflow Overview

  • See the Framework page for a detailed description of the technical workflow and API guidance

An event or request triggers an Alert Sender to notify either an Alert Intermediary or Recipient with an “Alert Bundle” object. This version of the guide defines a single type of push alert notification: a named operation to a FHIR endpoint. The basic process diagrams in Figure 2 shows the process where the Alert Sender transacts directly with the Alert Recipient. Figure 3 shows the process where the Alert Sender transacts with the Alert Intermediary (aka clearinghouse) which in turn interacts with the Alert Recipient. Although not represented in the figure, there may be multiple Alert Intermediaries.

Figure 2
basic_process.svg

  1. A specific event or request by patient or Healthcare Facility triggers an alert to be sent to an Alert Recipient.
  2. The Alert Sender notifies the Alert Recipient by pushing an “Alert” bundle which includes common resources across all Alerts and use case dependent supporting resources.
Figure 3
basic_process_int.svg

  1. Event or request by patient or Healthcare Facility triggers an alert to be sent to an Alert Intermediary ( e.g. clearinghouse).
  2. The Alert Sender notifies the Alert Intermediary by pushing an “Alert” bundle which includes common resources across all Alerts and use case dependent supporting resources.
  3. The Alert Intermediary is responsible for the redistribution of the data. Note that it may customize the data based on end user needs.