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

Submitting WG/Project/Implementer Group

***Break out with Subscriptions at 2PM on Tue Jan 6, to discuss Convergence and Triggering***

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 Payer / Provider Information Exchange Track

Proposed Track Lead

Stephen Hollifield (

Eric Haas as back up on site (

Can also contact Riki Merrick ( with questions

Expected participants

Who do you expect to be present?

(need to get sign up list...)

Contact Name



Role (Sender, Receiver, Intermediary

Client/Server URL/qEndpoint 

Jeff Brown

Patrick Haren

Jeff Brown

Patrick Haren


Maxim Abramsky

Artem Sopin

John Kelly


Submit alerts URL$process-message

Check alert URL

Eric Haasehaas@healthedatainc.comHealth eData IncSenderSimple Demonstration Client: 

Da Vinci Notification Sender

Stephen Hollifield stephen.hollifield@healthlx.comHealthLXSender/Receiver

RI Implementation.  see below:

open url =$process-message

Patrick Grennanpgrennan@onemedical.comOne MedicalReceiver

Receiver URL:$process-message

(Auth needed)

Keith Boonekboone@ainq.comAudacious InquirySender / Receiver

TBD for Reciever

Not Applicable for Sender

Ed Van

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).  Test data generated from synthea is also provided for each scenario in the links provided.

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

(Encounter.type may not be known when the notification is sent.  If data is not available  use the appropriate “unknown” concept code from the value set SNOMED SCTID: 261665006 | Unknown (qualifier value))

Encounter status = "in-progress"

Test data:  "Examplitis":

formats:  CSV, FHIR Transaction Bundle

 3 admits/ 3 discharges: - these examples are the source for the Da Vinci Notification Sender) and 

 and 100 admits/ 100 discharges

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

(Encounter.type may not be known when the notification is sent.  If data is not available  use the appropriate “unknown” concept code from the value set SNOMED SCTID: 261665006 | Unknown (qualifier value))

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

(Encounter.type may not be known when the notification is sent.  If data is not available  use the appropriate “unknown” concept code from the value set SNOMED SCTID: 261665006 | Unknown (qualifier value))

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

(Encounter.type may not be known when the notification is sent.  If data is not available  use the appropriate “unknown” concept code from the value set SNOMED SCTID: 261665006 | Unknown (qualifier value))

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

  • 200,202,204 +/- OperationOutcome all ok for successful transactions
    • Issue : what does widely use Java client want?

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.

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

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

Bonus 3: Batch Notifications:

The Guide only covers transaction of single 'real-time' synchronous notifications, however, implementers may choose to batch notification instead at regular intervals.  

Asynchronous case may arrive, if there is a need to batch a large number of messages (1000's). In that case, the bulk data guidance should be used.

  • For batching smaller number of (<1000 ?) messages can use transaction bundles synchronously.
  • If there is a need to batch a large number of messages (1000's), then the bulk data use case should be considered instead as an asynchronous alternative.

Bonus 4: Validation against the MessageDefinition and GraphDefinition:

MessageDefinition and GraphDefinition are relatively immature resources and may have breaking changes in future version of FHIR. However, defining the edges of a graph is useful in defining the Bundle contents and may be simpler computationally than profiling resources that make up the Bundle.   At the time of this publication, the implementation community, reference implementations, and validation tooling does not fully support them as conformance resource to validate the contents of a Bundle.  This Bonus goal is an important step in advancing these resources for the benefit of the FHIR community.

Reference Implementations

HealthLX Notifications RI:

logica home

Login to HSPCs Logica Sandbox at:

quick video demo


Touchstone Tests are found at: Touchstone_DaVinciNotification_Scripts

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.



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

(copied from pages 5 to 7 of googledoc here:  )

2020-01 Da Vinci Notification (aka Alerts)



  • Ed Van Baak (Audacious Inquiry)
  • Keith Boone (Audacious Inquiry)
  • Richard Ettema (Aegis)
  • RI tool ( HealthLX)
  • Eric Haas (FHIR Facade)


  • Richard Ettema (Aegis)
  • Jeff Brown (Cigna)
  • Patrick Haren (Cigna)
  • Artem Sopin (Edifecs)
  • John Kelly (Edifec)
  • Patrick Grennan (One Medical)
  • IBD ( not present )

Testing results:

RI Client and Flask App:

  • Successful connections to all servers by all clients
  • Edifecs server returning 400 errors due to extra server requirements - tracking down solutions.
  • IBC not present

AI results


  • error if send same message >1  - code? 400 or 409 + oo
    •  Add Ballot tracker to refer to the salient sections on messaging and require Bundle and MessageHeader ids.  and best practice is to have ids on all resources.

Breakout with Subscriptions to discuss convergence.

  • Main differences:

    •     Sub - asked
    •     Notifications - not asked
    • Notifications  - requires Graph of details.
      • Intent was to be able to give enough information to do something useful.
      • Should the graph be static, open or closed or end user  case specific?
    •  Sub - just the identifier

  • Want them to mesh together…
    • MH.focus vs Subscriptions topic
    • unifying principles that tie together
    • How and when to use Graph in Subscriptions?
      • Subscribe and then forward with notification 
      • Subscribe and then subscribe with Graph
      • Subscribe with graph

  • Subscription Topic defines state changes - can we use this for defining triggers for unsolicited Notification?

  •  IHE Mobile Access to Health Documents.  Yet another standard in this space
  • Can there be a single way to Notify?
    • Notifications Message Bundle with Message Header
      • Defined in FHIR R4
    • Subscriptions  Subscriptions? Bundle with SubscriptionStatus?   details yet tbd
    • Next step is to see if can find a common approach.

Next Steps

  • prep for  HIMMS

  • ensure that endpoints set up to work with RI:
    • Cigna 
    • Guidewell/Edifecs
    • IBC

  • Review test script to confirm that have all the information

  • No labels