2022-05 DaVinci Notifications

NOTE THIS Track is Limited to 5/4 Only.

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

Scenarios

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

Scenario Step 1 Assemble Notification Bundle

Description:

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.

Action: 

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

Scenario Step 2 Notification Sender Initiates FHIR Operation

Description:

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

Action:

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

Description:

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

Action:

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

• Create a new message bundle with a newBundle.idand newMessageHeader.id
• 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.

Bonus

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.

notificationShape defines related resources that MAY be included in notifications.

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

TestScript(s):

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.  Please feel free to contactTouchstone_Support@aegis.netfor any questions about testing using Touchstone.

Security and Privacy Considerations:

http://build.fhir.org/ig/HL7/davinci-ehrx/security.html