Page tree
Skip to end of metadata
Go to start of metadata

Short Description

Planning for the future of Da Vinci Notifications  the  project is planning to adopt the updated FHIR Subscriptions framework - alternatively we can explore NEW use case of death reporting, if desired using the unsolicited notifications.

Long Description

Current ADT exchange approaches typically use an HL7 V2 ADT message. This is a legacy EDI-style technology that uses HL7 specific protocols over ports that are not typically exposed to the internet. While HL7 V2 works well within the confines of a hospital system's intranet, it is not particularly well suited to cross-enterprise data exchange.

FHIR resources can be use to transport patient admission and discharge information to improve care coordination, in the form of ADT notifications. An ADT notification from the provider to the health plan can help track where care has been delivered and help ensure timely follow-up care is delivered as needed since healthcare stakeholders are increasingly responsible for knowing what care their patients have received and what care they need, regardless of where their patients sought care. FHIR-enabled provider systems can support functionality to send admission, discharge, and transfer information to a system with a FHIR API to receive the notification via an Encounter resource and its associated resources. The information can be sent to a pre-determined end-point or, optionally, an end-point or Direct Address that is determined by looking up the information recipients.

There are 2 ways this can be accomplished by sending unsolicited notifications using FHIR bunlde or subscriptions.


NOTE THIS Track is Limited to 5/4 Only.


Test an Implementation Guide

Submitting Work Group/Project/Accelerator/Affiliate/Implementer Group  


Track Lead(s)

Eric M Haas; Riki Merrick

Track Lead Email(s);

Related Tracks

FHIR Version

R4.0.0 ( 4.3.0 for Subscriptions)

Specification(s) this track uses

For unsolicted notifications: 

For subscriptions;

  • Terminology Servers this track users? - none
  • Specific Terminology Code Systems and Value Sets needed for this track?

Artifacts of focus

Base Da Vinci Notification Profiles

  • Da Vinci Notifications MessageHeader Profile
  • Da Vinci Notifications Bundle Profile

Da Vinci Admission/Discharge Notification Profiles

  • Da Vinci Admit Notification MessageHeader Profile
  • Da Vinci Discharge Notification MessageHeader Profile
  • Da Vinci Transfer Notification MessageHeader Profile
  • Da Vinci Admit/Transfer/Discharge Notification Condition Profile
  • Da Vinci Admit/Transfer/Discharge Notification Coverage Profile
  • Da Vinci Admit/Transfer/Discharge Notification Encounter Profile

NEW TOPICS = though no specific track for it this round

Expected participants

Surescripts has interest in testing at connectathon 1) Working with Providers, 2) Direct Trust / direct message, 3) Network traffic 


Zulip stream

Track Kick Off Call

Wednesday April 27, 2022 12 -1 PM ET 

Notifications Track May Connectathon Kick Off Orientation Recording 2022-04-27


Track Details

System roles:

The following actors have been defined:

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


Scenario 1: Unsolicited Notifications (Currently Use Case Described in Da Vinci Notification Implementation Guide)

Scenario Step 1 Assemble Notification Bundle


An event such as an inpatient admission or discharge triggers the Da Vinci Notifications Technical Workflow (step 1 above). Note that the actual trigger details is out of scope for the Notifications Guide.  See the Subscription's track for more information on the triggering workflows.


Based on the type of event, the Notification Sender assembles the Notification Message Bundle and all the included FHIR resources.  (step 2 in the workflow diagram)

Success Criteria:

For Notification Sender

  1. Creation of a conformantMessage Bundle containing the following resources and references.   Refer to the Implementation Guide for graphical, tabular and formal definitions of the Bundle contents. 

Scenario Step 2 Notification Sender Initiates FHIR Operation


Notification Sender  initiates the $process-message operation to the notification recipient/Intermediary's $process-message endpoint (step 3 in worflow diagram)


Notification Sender POSTs Da Vinci Notification Message payload body to the known notification recipient/Intermediary's $process-message endpoint

Success Criteria:

For Notification Sender

  1. POSTS to correct  [base]/$process=message endpoint

Scenario Step 3Notification Recipient/Intermediary Response to FHIR Operation


 Notification Recipient/Intermediary responds to transaction with http response (step 4 above)


Upon successful delivery of Da Vinci Notification Message payload body to the recipient/Intermediary's $process-message endpoint, it returns a response code of 200.

  • 200 PREFERRED ,202,204 +/- OperationOutcome all ok for successful transaction

Success Criteria:

Notification Recipient/Intermediary

Note: Since these actors are considered a  'Black box'  in the context of processing an operation there is no prescribed behavior.  However for the purpose of the Connectathon, the Notification Recipient/Intermediary should display the contents of the Notification FHIR message bundle to demonstrate the transaction was successful.

  1. Notification Recipient/Intermediary responds to transaction with http response
  2. Notification Recipient/Intermediary display the contents of the Notification FHIR message bundle to demonstrate the transaction was successful.

Bonus point:

Bonus 2: Error Conditions:

Technical errors are typically handled by lower level protocols or manual processes.   Typically the Sender would simply resubmit the Notification after correcting the issue.

The Guide only covers the "happy path".   In addition to the basic guidance in FHIR specification for $process-message operation:

  • 400,401,404+/- OperationOutcome no point in retry
  • 429 +/- OperationOutcome retry but slow down traffic
  • 500+ +/- OperationOutcome - server issues may retry a few times

Other errors may need to be communicated back to the Notification Sender and SHOULD be transmitted in the OperationOutcome

400 Error

  • Sender/Intermediary: Create an invalid message
  • Receiver:  return a 400 error +OperationOutcome detailing the error

401 Error (see Authorization and Authentication below)

  • Sender/Intermediary: Send message without proper authorization
  • Receiver:  return a 401 error -/+ OperationOutcome

404/429/500 Error out of scope for this connectathon

Bonus 3: Authorization and Authentication:

Following theFHIR Bulk Data IG's SMART Backend Services:Authorization Guide authorization and authentication details to access the Intermediary/Recipient FHIR Endpoint for POSTING the Notifications.

Consider using the “custom" system scope:  system/process-message.write

Also using dynamic registration as described in Da Vinci HREX :

Bonus 4: Intermediary Forwarding Messages (Acting as Sender with Provenance)

Following the updated guidance in theFrameworksection of the guide, forward a message bundle to a Recipient/Intermediary.

  • Create a new message bundle with a newBundle.idand
  • Update theMessageHeader.senderto reflect the Intermediary as the new Sender
  • Replace the resource in the Bundle with the resource referenced by the updatedMessageHeader.senderelement.
  • Update theMessageHeader.destinationto reflect the new Recipient/Intermediary.
  • Add the appropriate US Core Provenance Resource to the message Bundle as outlined in the guide.

( this is demonstrated in the Da Vinci Notification Sender Simulation)

Bonus 5: Follow up Queries for more information:

Notification Recipient/IntermediaryQueries Notification Sender to fetch more information.  (e.g. medications). For additional guidance refer to the US Core IG 

How do they identify the proper endpoint and launch the proper oauth 2.0 credentials to get access to the patient data. ( see the SMART Application Launch Framework Implementation Guide Release 1.0.0)

  • Registering a SMART App with an EHR
  • FHIR endpoint
  • auth endpoint
  • scopes

Notification Sender.

  1. Returns an appropriate http response with the appropriate status code
  2. returns conformant resources in the HTTP response as a searchset bundle

Scenario 2: Subscription Notifications

Subscription Notifications are documented in the Subscriptions R5 Backport Implementation Guide and some features require the FHIR version R4B.

2.1 REST-hook Channel + id-only payload of Encounter Resource

The subscription notification include a URL which can be used to access the Encounter resource using a FHIR RESTful GET. Supplied with references from the Encounter resource, related resources (such as the Patient, Location, Practitioner and Condition) can subsequently be retrieved.

Justification for this approach is that it is the simplest and most secure since the Receiver needs to authenticate with the data source for each resource request.

This use case is covered in the FHIR Subscriptions track.


2.2 REST-hook Channel + id-only payload of all the resources that define a notification bundle

In contrast to the 2.1 scenario above,the subscription notification supplies the Receiver with references to a "graph" of resources that make up the DaVinci Notification Bundle. This workflow is identical to 2.1 but the Notification Bundle would contain multiple entries, one for each resource type each containing an id. Supplied with these references the resources can be retrieved directly.

Similar to 2.1 the justification of this approach is that it is and most secure since the Receiver needs to authenticate with the data source for each resource request. In addition, instead of relying on the Receiver to choose what to query,the Server is able to provide the same information to each Receiver that would be transacted in using messaging. it is also more efficient for the Receiver eliminating the need to make to multiple queries.

How the "graph" of resource ids is defined in the Subscription Back Port IG.  Namely the FHIR 4b SubscriptionTopic element

notificationShape defines related resources that MAY be included in notifications.

This use case is not specifically covered in the FHIR Subscriptions track.



Please create a Touchstone user account (free) associated to the DaVinci organization if you have not already in order to run your systems through the test scripts.  Please feel free to contactTouchstone_Support@aegis.netfor any questions about testing using Touchstone.

Security and Privacy Considerations: