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

Submitting WG/Project/Implementer Group

Justification and Objectives

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.

This Connectathon track is designed for implementing Da Vinci Unsolicited Notifications Implementation Guide

This is the first iteration of this IG and intent here is to have a minimally viable product to demonstrate utility for notifying care team members of important events in a patient's health.

This Guide defines a FHIR technical framework for sending unsolicited notifications to the appropriate actors when triggered by an event or request.  The notification 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,  While a notification may generate workflow on the recipient’s part, the notification is not a part of that workflow. As such, the sender of a notification should not expect any additional response outside of the standard FHIR functionality.

The notifications follow the FHIR messaging paradigm and the exchange object is a FHIR Messaging Bundle.  The Framework documents in detail how to:

  1. Assemble the necessary resources for a particular use case into a FHIR Messaging Bundle
  2. Send the notification to the receiver using the FHIR defined $process-message operation

The Admit/Discharge Use case is also documented in the IG. This use case demonstrates how the Da Vinci Notifications IG framework is used to define the Da Vinci Notification Bundle for admissions and discharge and how to send a notification between a Sender and a Recipient/Intermediary and will be the main focus of this connectathon.

This track will use R4 version of FHIR.

Clinical input required

For each of the use case,  the data elements that a care team is interested in knowing for meeting the notification purpose are needed.   One of the goals of this connectathon is to determine if the admit and discharge data elements meets the needs of the majority of different care team members.  Some may only be applicable to particular care team members, for example, primary care provider vs payor vs physical therapist vs meal on wheels support.   

Related tracks

2019-09 Subscription  ( historical )

2019-09 Payer / Provider Information Exchange Track

Proposed Track Lead

Stephen Hollifield (HealthLX),  ?

Eric Haas (Health eData Inc),

Expected participants

Who do you expect to be present?

(need to get sign up list...)

Contact Name



Role CignaPayer CignaPayer
Keith W. Boonekboone@ainq.comAudacious InquiryVendor - HIE

Track Orientation

The recording of Track Orientation session given on November 20 

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 notifications to Notification Recipients based on previously defined subscription policies

They correspond to these roles in the notification transactions:




SenderDa Vinci Notification Query ResponderDa Vinci Notification Sender
IntermediaryDa Vinci Notification Receiver,Da Vinci Notification Query ResponderDa Vinci Notification QueryRequester, Da Vinci Notification Sender
RecipientDa Vinci Notification ReceiverDa Vinci Notification Query Requester


Please review the Da Vinci Notifications Implementation Guide  and Capability Statements  for the supported  profiles, operation as well as the extensive guidance surrounding the transaction workflow.

  • Receiver and Intermediary must be able to support the the $process-message operation on their system endpoint

Admit and Discharge Use Case Scenarios

(Examples using this approach are available in the Implementation Guide and the Reference Implementation (see below))

1 Emergency and Inpatient Admissions

Storyboard: Patient Y has been admitted to Provider X ‘s facility. Acting in the role of Notification Sender Provider X notifies Payer Z who is acting in the role Notification Recipient of the admission event.

event code = notification-admit, notification-admit-er, or notification-admit-inpatient

encounter.class code = EMER or IMP

2 Admission for Observation

Storyboard: Patient Q has been admitted to Provider R ‘s facility for Observation. Acting in the role of Notification Sender Provider R notifies ClearingHouse C who is acting in the role Notification Recipient of the admission event.

event code = notification-admit-forobservation

encounter code = OBSENC

3 Admission for special services, such as outpatient surgery

Storyboard: Patient M has been admitted to Provider N ‘s facility for outpatient surgery to repair a broken collarbone. Acting in the role of Notification Sender Provider N notifies HIE I who is acting in the role Notification Recipient of the outpatient surgery.

event code = notification-admit-ambulatory or notification-admit-short-stay

encounter code = AMB or SS

4 Encounter/Visit Notification for ambulatory services

Storyboard: Patient K has arrives at to Provider A ‘s facility for an office visit. Acting in the role of Notification Sender Provider A notifies ClearingHouse C who is acting in the role Notification Recipient of the admission.

event code = notification-admit-ambulatory

encounter code = AMB

5 Discharges/Visit ends

Storyboard: Patient Y has been discharged from Provider X ‘s facility. Acting in the role of Notification Sender Provider X notifies Payer Z who is acting in the role Notification Recipient of the discharge event.

event code = notification-discharge

encounter.hospitalization.dischargeDisposition  = any from

Assumptions and Preconditions

 Please review the DaVinci Notification FHIR IG for preconditions and assumptions.

General workflow : 

Assemble Notification Bundle


An event such as an inpatient admission or discharge triggers the Da Vinci Notifications Technical Workflow (step 1 above)


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

Success Criteria: 

Notification Sender

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


Source Profile


Target Profile



Must Support


Da Vinci Notification MessageHeader Profile


US Core Encounter Profile





US Core Encounter Profile


US Core Location Profile





US Core Encounter Profile


US Core Practitioner Profile





US Core Encounter Profile


US Core Patient Profile





Da Vinci HRex Coverage Profile


US Core Patient Profile





US Core Condition Profile


US Core Encounter Profile





Da Vinci Notification MessageHeader Profile


US Core Practitioner Profile|US Core PractitionerRole Profile|US Core Organization Profile





Da Vinci Notification MessageHeader Profile


US Core Practitioner Profile|US Core PractitionerRole Profile|US Core Organization Profile





Da Vinci Notification MessageHeader Profile

US Core Practitioner Profile|US Core PractitionerRole Profile




Notification Sender Initiates FHIR Operation


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


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

Success Criteria: 

2. Notification Sender POSTS to correct  [base]/$process=message endpoint

Notification 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.

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 1: 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.

What if any guidance should be given if the Notification cannot be delivered  or processed due to.

  • 400 Bad Request - resource could not be parsed or failed basic FHIR validation rules (or multiple matches were found for conditional criteria)
  • 401 Not Authorized - authorization is required for the interaction that was attempted
  • 404 Not Found - resource type not supported, or not a FHIR end-point
  • 405 Method Not allowed - the resource did not exist prior to the update, and the server does not allow client defined ids
  • 409/412 - version conflict management - see below
  • 422 Unprocessable Entity - the proposed resource violated applicable FHIR profiles or server business rules

Other errors may need to be communicated back to the Notification Sender.  How this is done is not currently documented in the guide - A notification response message is one option to consider.

Bonus 2: Follow up Queries for more information:

Notification Recipient/IntermediaryQueries Notification Sender to fetch more information.  (e.g. medications)

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.

Reference Implementations

HealthLX Notifications RI:

logica home

Login to HSPCs Logica Sandbox at:

quick video demo




Security and Privacy Considerations

Refer to individual Server implementation details for authorization and authentication details. (e.g. will TLS, mutual-TLS, OAuth, etc.) required to participate.

Report Out

  • No labels