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

Home

This implementation guide describes a method for 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 notified when activities occur that impact a patient’s care. This may be as traditional as a notification of an admission or transfer to or 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 applied to the patient admission, transfer, and discharge events to generate unsolicited notifications to the care team.

About This Guide

This Implementation Guide is supported by the Da Vinci initiative which is a private effort to accelerate the adoption of Health Level Seven International Fast Healthcare Interoperability Resources (HL7® FHIR®) as the standard to support and integrate value-based care (VBC) data exchange across communities. Like all Da Vinci Implementation Guides, it follows the HL7 Da Vinci Guiding Principles for exchange of patient health information. The guide is based upon the prior work from the US Core and Da Vinci Health Record Exchange (HRex) Implementation Guides. Changes to this specification are managed by the sponsoring HL7 Infrastructure and Messaging (INM) workgroup and are incorporated as part of the standard HL7 balloting process. You can suggest changes to this specification by creating a change request tracker by clicking on the Propose a Change link at the bottom of any page.

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 Unsolicited Notifications 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 care team members.
• Admit/Transfer/Discharge Use Case: Unsolicited notifications for the Admission/Transfer/Discharge use cases are defined using the framework.
• FHIR Artifacts: These pages provide 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.
  • 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 Da Vinci Notification actors.
• Security: General security requirements and recommendations for 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 to define a technical framework for sending unsolicited notifications to the appropriate actors when triggered by an event or request. Note that what is being communicated is a notification and not an alert which often has the expectation that something needs to be done. The assumption is that data is being transferred but not the responsibility. The data recipient determines the action it takes based upon the information it receives. The notifications should provide enough information to understand what the notification is about and to enable the Recipient to determine if and what additional 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:

Scenarios

Notifications can be generated for many scenarios.

This Implementation Guide focus is the Admission Transfer and Discharge Scenario. However, the framework defined in this guide is intended to support other scenarios such as those listed below. There is no plan to publish additional use cases in this implementation guide. Additional scenarios may be published as supplemental non-balloted informative documents or use case specific Implementation Guides.

Roles and Actors

There are many potential actors for the roles listed above:

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.

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 an Intermediary, having previously received a notification, 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.

—

This Implementation Guide was made possible by the thoughtful contributions of the following people and organizations:

• The twenty-two founding Da Vinci Project member organizations.

• Eric Haas, Health eData Inc
• Riki Merrick Vernetzt, LLC
• Linda Michaelsen, Optum
• Lloyd Mckenzie, Gevity
• Robert Dieterle, EnableCare
• Viet Nguyen, Stratametrics
• Jocelyn Keegan, Point of Care Partners

---