Da Vinci Unsolicited Notifications Implementation Guide (Release 0.2.0 STU1 Ballot)

This page is part of the Da Vinci Unsolicited Notifications (v0.2.0: STU 1 Ballot 1) based on FHIR R4. The current version which supercedes this version is 1.0.0. For a full list of available versions, see the Directory of published versions

Da Vinci Unsolicited Notifications

This Implementation Guide was originally named Da Vinci Alerts Implementation Guide - after review by several HL7 workgroups, it was felt that the term “alerts” has a specific meaning to many people that was not the same as the contents of this guide. Therefore the title of this IG has been changed to Da Vinci Unsolicited Notifications Implementation Guide. Be aware that there are several technical artifacts such as the canonical base, the npm package name and the history page url that cannot be changed and still retain the word “alerts” in their paths.

The communication of relevant notifications to support the real-time exchange of information that impacts patient care and value based or risk based services. Providers and Payers may need to be alerted when activities occur that impact a patients care. This may be as traditional as a notification of an admission to or a discharge from a care setting. It also includes notifications about changes in treatment such as a new or different medication, or changes in patient status like a new diagnosis. These notifications provide information that can improve care management and care coordination as well as act as the trigger for quality programs and other patient focused activities (for example, risk adjustment). By allowing the patient’s healthcare providers to be better informed and able to take actions and intervene earlier, the twin goals of better patient care and reduced cost of care may be met.

The 2019 CMS 45 CFR Part 156 NPRM focuses on hospitalization notifications due to significant issues that can occur if a patient is not followed appropriately after acute care. The HL7 Da Vinci Project has responded to this need by supporting the effort to provide a FHIR based standard for adoption by both providers and payers. It is anticipated that the burden of communicating the notification is also reduced by using FHIR. This Guide defines a FHIR messaging based paradigm and framework to establish consistently adoptable and reproducible methods to exchange notifications. This framework is demonstrated using the patient admission and discharge event use case to generate unsolicited notifications to the care team.

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 a general framework to enable unsolicited notifications to careteam members.
  • Admit/Discharge Use case: The Admission/Discharge use case is used to show how to implement an unsolicited notification using the framework.
  • FHIR Artifacts: These pages provides detailed descriptions and formal definitions for all the FHIR objects defined in this guide.
    • Profiles: This page lists the set of Profiles that are defined in this guide to exchange quality data.
    • Terminology: This page lists the value sets and code system defined for this guide.
    • 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 Unsolicited Notifications 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 goal of this Implementation Guide is define a technical framework for sending unsolicited notifications to the appropriate actors when triggered by an event or request. The notifications should provides enough information to understand what the notification is about and to enable the Recipient to determine if and what addition steps they need to take in response to the notification. For example, additional steps may include:

  • a request for more information from the Sender through a FHIR RESTful query
  • creation of an encounter record in the receiving system with appropriate provenance
  • making the information available to CDS and other local services.

The following table summarizes the technical scope of this guide:

In Scope

  • Define a common FHIR messaging Bundle that is exchanged for all Notifications.
  • Define the FHIR transactions and minimum operational behavior for the relevant Actors
  • Define how to define and share the minimal data elements needed to support the information needs for an initial set of Use Case starting with the patient admission and discharge event use case.
  • Define a how users requiring more data may follow up with additional queries.
  • Describe basic Security and Privacy considerations

Out Of Scope

  • 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 notification that requires workflow management such as Task
  • Complex content
  • Besides the standard http response, the Alert Recipient’s workflow upon receipt of alert.


Notifications can be generated for many scenarios.

The initial version of this Implementation Guide will focus on Admission and Discharge Scenarios, in other words, anything that would create an encounter in a patient care record. However, this framework is intendend to support other scenarios such as those listed below. Work is planned to document them in future publications in collaboration with domain experts such as public health.

Initial Scenarios

  • 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

  • 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


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


There are many potential actors for the roles listed above:


  • Hospital Information System (HIS) at Acute/Inpatient Facility
  • EHR or Practice Management (PM) system at an Ambulatory/Outpatient (Specialist/PCP) office
  • Post Acute Facility EHR or PM
  • Health Plan and Contracted Entities


  • Health Information Exchange (HIE)
  • Clinically Integrated Network (CIN) systems
  • National Networks (CareQuality, CommonWell, etc.)
  • Specialized Alert Aggregators
  • Health Plan and Contracted Entities


  • Hospital Information System (HIS) at Acute/Inpatient Facility
  • EHR or Practice Management (PM) system at an Ambulatory/Outpatient (Specialist/PCP) office
  • Post Acute Facility EHR or PM
  • Population Health Management systems
  • Care Management/Care Coordination systems
  • Health Plan and Contracted Entities

Workflow Overview

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

Figure 1 below illustrates the general notification workflow of a Sender sending an unsolicited notification to a Receiver or Intermediary when triggered by an event or request.

Figure 1

  1. An event or request triggers a notification to be sent from a Sender (aka source application) to a Recipient or Intermediary (aka destination application). The notification includes common information shared across all Da Vinci notifications and use case dependent information.
  2. The Sender notifies the Recipient by sending an “unsolicited” notification to the Recipient’s FHIR endpoint.
  3. The notification is processed according the Receiver or Intermediary internal business rules.

Figure 2 shows the process where the Sender sends an unsolicited notification to an Intermediary which in turn forwards the notification to the Recipient. In this case, the Intermediary is responsible for the redistribution of the data. Note that it may customize the data based on end user needs. Although not represented in the figure, there may be multiple Intermediaries.

Figure 2