- Created by Ulrike Merrick, last modified by Vanessa Candelora on Apr 27, 2022
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.
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
Eric M Haas; Riki Merrick
Track Lead Email(s)
R4.0.0 ( 4.3.0 for Subscriptions)
Specification(s) this track uses
For unsolicted notifications: http://hl7.org/fhir/us/davinci-alerts/STU1/index.html
For subscriptions; http://build.fhir.org/ig/HL7/fhir-subscription-backport-ig/
Artifacts of focus
Base Da Vinci Notification Profiles
Da Vinci Admission/Discharge Notification Profiles
NEW TOPICS = though no specific track for it this round
Surescripts has interest in testing at connectathon 1) Working with Providers, 2) Direct Trust / direct message, 3) Network traffic
Track Kick Off Call
Wednesday April 27, 2022 12 -1 PM ET
Notifications Track May Connectathon Kick Off Orientation Recording 2022-04-27
The following actors have been defined:
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)
For Notification Sender
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
For Notification Sender
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.
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.
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:
Other errors may need to be communicated back to the Notification Sender and SHOULD be transmitted in the OperationOutcome
401 Error (see Authorization and Authentication below)
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 :http://build.fhir.org/ig/HL7/davinci-ehrx/smart-app-reg.html
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.
( 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)
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
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: