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?

CIGNA, Audacious Inquiry

Contact NameEmailOrganizationRole 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.

Open Issues:

1.  Async vs Sync messaging and status codes

We have assumed these transactions are synchronous, but actually dodge the question by treating the the Receiver/Intermediary as a "black box" and not expecting a response beyond the http response.  The $process-message definition describe both synchronous and and async use cases and upon receiving a message, the Receiver/Intermediary may return one of several status codes which is documented in $process-message definition.

  • Currently the IG and RI specify using http 200 for a successful interaction.  However the 202 seems is more appropriate for synchronous messaging and 200 codes for asynchronous messaging.
  • 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.
  • Additionally we have not discussed sending multiple notifications in a single interaction using a transaction Bundle and whether this could be done using synchronous or asynchrononous messaging.

2: Follow up Queries for more information:

For the scenario where the Notification Recipient/IntermediaryQueries Notification Sender needs to fetch more information.  (e.g. medications) and 

Notification Sender returns an appropriate http response with the appropriate status code and conformant resources in the HTTP response as a searchset bundle.

How to 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

Reference Implementations

HealthLX Notifications RI:

logica home

Login to HSPCs Logica Sandbox at:

source code:

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

Philadelphia Connectathon Dec 11-12, 2019

Servers: (all open)

  1. Cigna:
  2. Ref implementation ( Logica ):$process-message
  3. WildFhir (Aegis):


  1. Ref implementation (HealthLX/Logica)
  2. Audacious Inquiry (Keith Boone): (converted ADT v2 to Da Vinci Notification Messages)
  3. Health eData Inc (Eric Haas): Flask app facade using Synthea generated data from FHIR reference Servers - pending


  1. Aegis (Richard Ettema): < to ts resources>

Message Successfully Sent to all Servers

Logica Reference Client UI


Audacious Inquiry ADT to FHIR Notification Transform

Cigna Server UI 

Client Issues: - Issue with Cigna server no metadata endpoint so some clients like Logica or hapi Java Client will not connect out of box. - Issue with Java Client expectation for http response for message without response message (see below) - discussion with Java client authors about this behavior


Sync v Async Messaging

  • Established that for notifications (vs for example requests) will be synchronous messaging with no response message ( just an http +/- OperationOutcome ).
  • 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.
    • However, for batching smaller number of messages can use transaction bundles synchronously.

Error paths:

Guide only covers the "happy path". Errors are covered in the $process-message documentation in the FHIR specification. Polled the participants to determine if more guidance is needed.

In addition to basic guidance in FHIR specification for $process-message:

  • 200,202,204+/- OperationOutcome all ok for successful transactions
    • Issue : what does widely use Java client want?
  • 401,404+/- OperationOutcome no point in retry
  • 429 +/- OperationOutcome retry but slow down traffic
  • 500+ +/- OperationOutcome - server issues may retry a few times

FHIR Specification issues

  • definition mentions device, but choice of Device not available: Tracker pending
  • Messaging section states that all messages expect response message which is not how notifications is written. For notification - only expect either only an http response or an OperationOutcome Tracker pending

Encounter.type codes at time of notification

  • Encounter.type may not be known when send notification.
  • Keith review 1/2 million v2 ADT's only.
    • 10% had PV1-4 (Admission Type) codes
    • 20% had PV1-18 (Patient Types) codes
    FYI 'Encounter.reasonCode' codes at time of ADT
    • 4% had PV2-3 (admit reason) codes
    • ~50% had PV2-3 (admit reason) free text
    Preferred options if data is not available is to use the appropriate “unknown” concept code from the value set SNOMED
    • alternative is to create a new profile for Da Vinci Notifications

No Test Data

- good new is forced clients to create own
    - for next time will have some basic test data available
  • No labels