201809 FHIR Subscriptions
FHIR Subscriptions
All Registration and tracking will be done in the connectathon managment app: http://conman.fhir.org/connectathon.html?event=baltimore2018
Dedicated Zulip chat stream for this track.
- Track orientation slides: https://docs.google.com/presentation/d/1Qh8ZxVJ6aIelYhklz1y-agPXpzohc9MNiOVOIU_w4Sc/edit?usp=sharing
Previous Subscriptions Connectathons
- 201709 FHIR Subscriptions, September 2017, San Diego, CA
- 201801 FHIR Subscriptions, January 2018
Submitting WG/Project/Implementer Group
FHIR-I
Justification
This track is an important step in advancing the maturity of the interactions and resources associated with FHIR Subscriptions.
The subscription pub/sub pattern enables FHIR clients to retrieve data from a server without performing a more expensive periodic polling queries.
Proposed Track Lead
See Connectathon_Track_Lead_Responsibilities
FHIR version
R4 (September 2018 Ballot): http://hl7.org/fhir/2018Sep/subscription.html
Expected participants
Cerner, Jenni Syed & Max Philips
Roles
FHIR Server
The FHIR Server supports the Subscription resource and notifying subscribed clients of changes.
- Must expose a Subscriptions resource supporting read, create and update.
- Must also act as a client to send notifications.
Subscribing client
Subscribes to FHIR server and gets updates.
- Must create a Subscriptions instance on external FHIR server.
- Must expose an endpoint to accept notifications.
Scenarios
Create FHIR Subscription
- Action: Subscribing client creates a Subscription instance on FHIR Server.
- Precondition: n/a
- Success Criteria: Subscribing client POSTs new subscription resource to FHIR server specifying a criteria and a channel.type of rest-hook. FHIR Server persists active subscription resource. Subscribing client can read newly created Subscription.
- Bonus point: Subscribing client updates Subscription instance's status element to _off_ once the subscription is no longer needed. FHIR server respects this setting.
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.
Argonaut Patient Scheduling prefetch
Subscribe to Schedule using Argonaut extension
- Action: Client subscribes to Schedule per Argonaut Patient Scheduling IG.
- Precondition: n/a
- Success Criteria: Subscribing client POSTs new subscription resource, including Schedule identifier in _criteria to FHIR server. Subscription.channel.type is rest-hook and Subscription.channel.payload is application/fhir+json. FHIR Server persists active subscription resource. Subscribing client can read newly created Subscription.
Notify client of Slot change
- Action: FHIR Server notifies subscribers by POSTing a Schedule resource to the endpoint identified in the subscription, according to Argonaut Patient Scheduling.
- Precondition: FHIR Subscription created.
- Success Criteria: FHIR server POSTs a FHIR Schedule for the modified Slot, to the subscribing client when the criteria is met in the FHIR server.
- Bonus point: Subscriber subsequently fetches Slots associated with Schedule from notification.
Notes
Please discuss/explore this tracker issue: [1]
Outcomes
Participants
- David Barnet (NHS Digital)
- Naresh Jaganathan (Aegis)
- Max Philips (Cerner)
- Brian Reinhold (Lamprey)
- Jenni Syed (Cerner)
- Ben Winters (Mayo Clinic)
Observers
- Richard Ettema
- Roland Hartich
- Aleksandr Ivanov
- Christiaan Knaap
- Christopher Kundra
- Sagy Mintz
- John Moehrke
- Michele Mottini
- John Rhoads
- Cooper Thompson
- Abigail Watson
Achievements
The biggest outcome came from discussion and learning. For example, we discussed benefits of using compartments to enable population monitoring, and the backing FHIR concepts that exist to support this (eg: _list). General discussion of security and challenges around this as well which covered both permissions and data access (right provider, right data) as well as web security challenges that the subscription model may present. There were use cases brought up that we hadn't discussed before including EpisodeOfCare monitoring (and all the resources relating to them) and how servers need to handle Subscriptions that include references to sets that may change (_list, code:in type queries). Finally, the discussion around what a server should do when it can't immediately process a subscription to indicate this to scenario to a subscriber.
We had participants that were able to test against a FHIR server, set up a mock environment based around MSMQ that helped visualize what challenges a real system would face, and a server that was receiving updates from devices to trigger subscription notifications.
Issues
We discussed several issues or challenges during this connectathon:
- [Detecting data that no longer qualifies for a subscription|https://chat.fhir.org/#narrow/stream/75-subscriptions/subject/Detecting.20data.20that.20no.20longer.20qualifies]
- [Validation of subscription: realtime vs. delayed|https://chat.fhir.org/#narrow/stream/75-subscriptions/subject/Subscription.20Validation]
- [GForge 14646 discussed a bit|https://chat.fhir.org/#narrow/stream/75-subscriptions/subject/Gforge.2014646]
- Logged [GForge 18990|https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=18990] to suggest removing Subscription.tag and suggest use of CommunicationRequest/Communication (or other) for this type of need.
- Logged [GForge 18991|https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=18991] to clarify payload value set (make a value set instead of a string) and possibly add an invariant around email/SMS.
- Logged [GForge 18992|https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=18992] that is somewhat related to above, but allowing SMS and EMail subscribers to provide some default text to be sent with the notification.
- Logged [GForge 18993|https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=18993] to address subscriber-side security concerns and impacts that could have to the FHIR server they're subscribed to.
- Logged [GForge 18994|https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=18994] to suggest adding more detail and concerns to the security section of the Subscription resource.
Now What
The 3 ongoing zulip discussions need to be tracked and have trackers logged with conclusions (or have trackers updated for the case of 14646). Need to watch and discuss other trackers as necessary. We also recommend indicating that the SMS, Email, and (perhaps) Messaging sections have had less feedback than the Hook and WebSocket sections. We didn't have anyone at the table that did SMS and Email, and only one that was tangentially thinking about the messaging aspect.
