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

Submitting WG/Project/Implementer Group



Our Zoom link is https://zoom.us/j/7948763284

Contact Track Lead Contact: Eric Haas on the DaVinci Notifications Track Zulip Stream

Today's events:

The track report is here: 

  • Friday, May 15th 5:30pm Da Vinci Track Demos Notifications
    • Challenges due to low participation in track.
    • Participants 

 

      • CareEvolution Sender was successful in generation a Message Bundle a posting it the open Reference Implementation receiver  and the open EMR Direct Connectathon Server endpoint using the $process-message operation.
    • Brief discussion about what a JWT token would contain for authorization.  (Currently the RI is an open endpoint)
    • CareEvolution Sender posting notifications to the EMR Direct Connectathon Server but with authentication working with the FAST/DCR profiles for client registration
  • Friday, May 15th 6pm HL7 Connectathon HL7 Connectathon Wrap-Up


Schedule  (Eastern Times)

The Da Vinci Schedule is posted here: https://confluence.hl7.org/display/DVP/HL7+Virtual+Connectathon+-+May+2020

  • Wednesday, May 13th 4pm HL7 Connectathon HL7 Connectathon Kick-Off
  • Wednesday, May 13th 5pm Da Vinci General Kick-Off Da Vinci General
  • Thursday, May 14th 1pm Da Vinci Track Kick-Off Notifications / Risk Based Contracts Member Attribution List

  • Thursday, May 14th 5:30pm Da Vinci Track Sync-Up

  • Friday, May 15th 5:30pm Da Vinci Track Demos Notifications / Risk Based Contracts Member Attribution List
  • Friday, May 15th 6pm HL7 Connectathon HL7 Connectathon Wrap-Up

break-out  time  TBD

Connectathon Report:

  • Friday, May 15th 3PM ( Track Lead will be bugging you for individual summaries (wink))

DaVinci Notifications Track Chat on Zulip :

( navigate to https://chat.fhir.org/  to sign up if you have not already)

Place for general announcements on the DaVinci Notifications Track

Other Track streams and sidebars can be spawned ad hoc in the DaVinci Stream 

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 a simple FHIR messaging paradigm for notifications employing both the FHIR Messaging Bundle and RESTful interaction using the $process-message operation for  exchanging data.  Note that Da Vinci Notifications allow implementers to use only these FHIR messaging components in the same manner as a FHIR RESTful operation without having to fully implement the FHIR messaging framework.   But it is also compatible with FHIR messaging as implemented.   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/Transfer Use case is also documented in the IG to comply with part 485 of the CMS 21st Century Cures Act final rule.   This use case demonstrates how the Da Vinci Notifications IG framework is used to define the Da Vinci Notification Bundle for admissions, discharges, and transfers 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 requested (if any)

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, transer 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 track

2020-05 Subscriptions Track

Track Lead

Eric Haas (ehaas@healthedatainc.com)

Expected participants

Contact Name

Email

Organization

Role (Sender, Receiver, Intermediary

Client/Server URL/qEndpoint 

Yuriy Flyud

yuriy@healthlx.com

Sender/Receiver

RI Implementation.  see below:

open url = https://davinci-alerts-receiver.logicahealth.org/fhir/$process-message

Eric Haasehaas@healthedatainc.comHealth eData IncSenderSimple Demonstration Client: 

Da Vinci Notification Sender

Melissa Benziebenzie@careevolution.com

Sender

tbd

Luis Maaslcmaas@emrdirect.com

Receiverhttps://stage.healthtogo.me:8181/fhir/r4/stage/$process-message

Track Orientation

The recording of Track Orientation session given on April 15, 2020    


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:

Actor

server-mode

client-mode

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

Preconditions

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 synchronous $process-message operation on their system endpoint
    • including these http responses: 
      • 200,202,204 +/- OperationOutcome all ok for successful transactions
        • PREFERRED 200 OK: Indicates that the message has been fully processed. If an application-level response is expected for the submitted message, that response SHALL be returned as the body of the 200 response.
        • 202 Accepted: Indicates that the receiving system has accepted custody of the message
        • 204 No Content: Indicates that the message has been fully processed and would normally have had an application-level response, but because of instructions from the sender (e.g. the messageheader-response-request extension), no response is being provided - NOTE NO response is expected for Da Vinci Notificiations
      • 401,404 +/- OperationOutcome
      • 429 +/- OperationOutcome
      • 500+  +/- OperationOutcome
    • Although not required an OperationOutcome Message is preferred for ease of debugging.
    • Optionally the notification contents may be echoed back to the Sender.

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

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"




2 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  http://terminology.hl7.org/CodeSystem/discharge-disposition


3 Transfer from the ED to inpatient ICU

Storyboard: Patient Y has been transfered from Provider X ‘s ED to their inpatient ICU.  Acting in the role of Notification Sender Provider X notifies Payer Z who is acting in the role Notification Recipient of the transfer event.

event code = notification-transfer

encounter.hospitalization.dischargeDisposition  = any from  http://terminology.hl7.org/CodeSystem/discharge-disposition


4 Other types of admissions:

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

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


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

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


 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

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



Assumptions and Preconditions

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

General workflow : 


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


Link

Source Profile

Path

Target Profile

Min

Max

Must Support

1

Da Vinci Notification MessageHeader Profile

MessageHeader.focus

US Core Encounter Profile

1

1

true

2

US Core Encounter Profile

Encounter.location

US Core Location Profile

1

*

true

3

US Core Encounter Profile

Encounter.participant.individual

US Core Practitioner Profile

0

*

true

4

US Core Encounter Profile

Encounter.subject

US Core Patient Profile

1

1

true

5

Da Vinci HRex Coverage Profile

Coverage.beneficary

US Core Patient Profile

0

1

true

6

US Core Condition Profile

Condition.encounter

US Core Encounter Profile

0

*

true

7

Da Vinci Notification MessageHeader Profile

MessageHeader.sender

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

0

1

true

8

Da Vinci Notification MessageHeader Profile

MessageHeader.responsible

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

0

1

true

9

Da Vinci Notification MessageHeader Profile

MessageHeader.author

US Core Practitioner Profile|US Core PractitionerRole Profile

0

1

true

Notification Sender Initiates FHIR Operation

Description:

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

Action:

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

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 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: Authorization and Authentication:

Following the FHIR 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

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


Test data


"Examplitis": 3 admits/3 transfers/3 discharges

These examples follow the lifecycle of a three patient encounters and are the source for the Da Vinci Notification Sender

format:  FHIR Transaction Bundle

 "Examplitis": 100 admits/100 transfers/100 discharges

  • Admit Bundle (PUT resources to FHIR Server)
  • Transfer Bundle (Updates Encounter and adds Condition)
  • Discharge Bundle (Updates Encounter)

Reference Implementations

HealthLX Notifications RI:

logica home

Login to HSPCs Logica Sandbox at: sandbox.hspsconsortium.org/DaVinciALERTS/apps 


quick video demo

Testscripts:

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.

 Document

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.


5:30pm Da Vinci Track Sync-Up:


Challenges due to low participation in track.

Currently have a single active participating Sender from CareEvolution who was successful in generation a Message Bundle a posting it the RI receiver endpoint using the $process-message operation.

Brief discussion about what a JWT token would contain for authorization.  (Currently the RI is an open endpoint)

Next Step is to reach out to Connectathon participants to indicated interest in the track to see if they have systems ready for connecting.


  • No labels