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


Submitting WG/Project/Implementer Group

FHIR-I

Argonaut

Justification and Objectives

This track is an important step in advancing the maturity of the interactions and resources associated with FHIR Subscriptions. Specifically, proposed changes to the Subscription model are coming in to R5 via previous work on this track. Argonaut is also building a profile off of these changes, and we would like to prove out the newer model to determine what gaps still exist. This track will focus on RestHooks and WebSockets (or Server Sent Events - some discussion may occur on this topic). We will also discuss the security of subscriptions: what can be sent to the subscriber? How does the subscriber know this is a valid alert?

The subscription pub/sub pattern enables FHIR clients to retrieve data from a server without performing a more expensive periodic polling queries.

This track will use the draft R5 (with Argonaut Subscription changes)  in the latest CI Build of FHIR: http://build.fhir.org/subscription.html, and http://build.fhir.org/topic.html

Related tracks

(used to help guide seating arrangements and possibly drive track consolidation)

Proposed Track Lead

Jenni Syed (https://chat.fhir.org/#narrow/pm-with/191356-jenni.syed)  

Expected participants

TODO

Track Orientation

A webinar will be hosted on TBD to share further participation information about this track.

An ics file can be downloaded and saved to your calendar: TODO

Join: TODO

Slides: TODO

Recording: TODO

System Roles

FHIR Server

The FHIR Server supports the Subscription and Topic resources, as well as notifying subscribed clients of changes.

  • Must expose a Subscriptions resource supporting read, create and update.
  • Must expose a Topic resource supporting read and search.
  • May expose a Topic create/update.
  • Must also act as a client to send notifications.
  • Should expose capabilities to use web sockets on the subscription.

Subscribing client

Subscribes to FHIR server and gets updates.

  • Should search or read the Topics
  • May support creating its own Topics on a FHIR Server.
  • Must create a Subscriptions instance on external FHIR server.
  • Must expose an endpoint to accept notifications.
  • Should be capable of using web sockets to receive updates.

Discussions

Subscriptions is changing in R5, due to feedback from previous connectathons. The major change is the breakout of Subscription and Topic, but there are also changes to the way notifications are done, enhanced error handling, and ongoing discussions regarding other aspects of the workflow that may need to change. Some discussion is expected at the connectathon to continue feedback into the new model for R5.

There has also been a lot of recent discussion around security - we would like to continue this conversation at the connectathon.

Web Sockets

Several challenges have been voiced about web sockets. Once example is the lack of well established standards to authenticate using web sockets. Another challenge that has been discussed is the way to scale and balance web sockets from many different clients to a server. Are web sockets something we want to continue supporting? Should we look at using server sent events instead?

Scenarios

Describe the different scenarios participating systems can engage in during the connectathon. Each scenario should provide sufficient description that participants can appropriately construct their software in advance to prepare to interoperate during the connectathon.

Create Subscription

Action: A subscribing client creates a subscription for a Topic on a FHIR server.

Precondition: A Topic must be read from the FHIR server.

Success Criteria: The subscription exists and is in an active status.

Bonus point: If the FHIR server supports it, the client may create its own Topic. The subscribing client may also update the Subscription status to off when it no longer needs the subscription (and server should honor)

Rest Hook Notifies Client

Action: FHIR Server notifies Subscribing client by POSTing to the endpoint identified in the subscription resource instance.

Precondition: Create FHIR Subscription scenario

Success Criteria: FHIR server POSTs when the criteria in the Subscription is met within the FHIR server.

Create Subscription with Auth (Bonus)

Action: A subscribing client creates a subscription for a Topic on a FHIR server.

Precondition: A Topic must be read from the FHIR server.

Success Criteria: Subscribing client POSTs new subscription resource to FHIR server specifying a topic, an Authorization header, and a channel.type of rest-hook. FHIR Server persists active subscription resource. Subscribing client can read newly created Subscription.

Bonus point: If the FHIR server supports it, the client may create its own Topic. The subscribing client may also update the Subscription status to off when it no longer needs the subscription (and server should honor)

Rest Hook Notifies Client with Auth (Bonus)

Action: FHIR Server notifies Subscribing client by POSTing to the endpoint identified in the subscription resource instance, including the requested authorization header.

Precondition: Create FHIR Subscription with auth scenario

Success Criteria: FHIR server POSTs when the criteria in the Subscription is met within the FHIR server.

Argonaut Scenarios

TODO: Update for Feb

Argonaut will also be testing two specific scenarios at this connectathon. Participants are encouraged to participate.

https://github.com/argonautproject/subscriptions/tree/master/connectathon-scenarios-201909#scenario-1-single-patient-encounter-notifications-via-rest-hook-eg-to-a-consumer-app

https://github.com/argonautproject/subscriptions/tree/master/connectathon-scenarios-201909#scenario-2-group-encounter-notifications-to-an-intermediary-or-clearing-house-via-rest-hook

TestScript(s)

Indicate any test scripts that will be used to help verify system behavior

Security and Privacy Considerations

Some scenarios require an Authentication header to be stored with the subscription and sent with the notification.

Outcomes




  • No labels