This wiki has undergone a migration to Confluence found Here
Difference between revisions of "201809 FHIR Subscriptions"
Jump to navigation
Jump to search
Isaacvetter (talk | contribs) m (→Scenarios) |
Jenni syed (talk | contribs) |
||
| (14 intermediate revisions by 3 users not shown) | |||
| Line 3: | Line 3: | ||
__NOTOC__ | __NOTOC__ | ||
=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 [https://chat.fhir.org/#narrow/stream/subscriptions/subject/Sept.20Connectathon.20track Zulip chat stream] for this track.''' | '''Dedicated [https://chat.fhir.org/#narrow/stream/subscriptions/subject/Sept.20Connectathon.20track Zulip chat stream] for this track.''' | ||
| + | * Track orientation slides: https://docs.google.com/presentation/d/1Qh8ZxVJ6aIelYhklz1y-agPXpzohc9MNiOVOIU_w4Sc/edit?usp=sharing | ||
'''Previous Subscriptions Connectathons''' | '''Previous Subscriptions Connectathons''' | ||
| Line 26: | Line 30: | ||
==FHIR version== | ==FHIR version== | ||
| − | + | R4 (September 2018 Ballot): http://hl7.org/fhir/2018Sep/subscription.html | |
==Expected participants== | ==Expected participants== | ||
<!-- List of the individuals and/or organizations that have indicated a desire to attend the connectathon and implement this track --> | <!-- List of the individuals and/or organizations that have indicated a desire to attend the connectathon and implement this track --> | ||
| − | Cerner, | + | Cerner, Jenni Syed & Max Philips |
| + | * https://github.com/MaxPhilips/wgm_sept_2018_notes/blob/subscription/subscription/test_server_faq.md | ||
==Roles== | ==Roles== | ||
<!-- Roles are sets of functionality (generally defined by a Conformance resource) that a single system can take on --> | <!-- Roles are sets of functionality (generally defined by a Conformance resource) that a single system can take on --> | ||
===FHIR Server=== | ===FHIR Server=== | ||
| − | The FHIR Server supports the Subscription resource and | + | The FHIR Server supports the Subscription resource and notifying subscribed clients of changes. |
* Must expose a Subscriptions resource supporting read, create and update. | * Must expose a Subscriptions resource supporting read, create and update. | ||
| − | * Must also act as a | + | * Must also act as a client to send notifications. |
===Subscribing client=== | ===Subscribing client=== | ||
| Line 48: | Line 53: | ||
:Action: Subscribing client creates a Subscription instance on FHIR Server. | :Action: Subscribing client creates a Subscription instance on FHIR Server. | ||
:Precondition: n/a | :Precondition: n/a | ||
| − | :Success Criteria: Subscribing client POSTs new subscription resource to FHIR server. FHIR Server persists active subscription resource. Subscribing client can read newly created Subscription. | + | :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. | :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 | + | ===REST Hook notifies client=== |
| − | :Action: FHIR Server notifies Subscribing client by | + | :Action: FHIR Server notifies Subscribing client by POSTing to the endpoint identified in the subscription resource instance. |
:Precondition: Create FHIR Subscription scenario | :Precondition: Create FHIR Subscription scenario | ||
| − | :Success Criteria: | + | :Success Criteria: FHIR server POSTs when the criteria in the Subscription is met within the FHIR server. |
=== Argonaut Patient Scheduling prefetch === | === Argonaut Patient Scheduling prefetch === | ||
| Line 60: | Line 65: | ||
:Action: Client subscribes to Schedule per [http://www.fhir.org/guides/argonaut/scheduling/patient-scheduling.html#usage-5 Argonaut Patient Scheduling IG]. | :Action: Client subscribes to Schedule per [http://www.fhir.org/guides/argonaut/scheduling/patient-scheduling.html#usage-5 Argonaut Patient Scheduling IG]. | ||
:Precondition: n/a | :Precondition: n/a | ||
| − | :Success Criteria: Subscribing client POSTs new subscription resource | + | :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==== | ==== Notify client of Slot change==== | ||
| − | :Action: FHIR Server notifies subscribers by | + | :Action: FHIR Server notifies subscribers by POSTing a Schedule resource to the endpoint identified in the subscription, according to [http://www.fhir.org/guides/argonaut/scheduling/patient-scheduling.html#usage-7 Argonaut Patient Scheduling]. |
| − | :Precondition: FHIR Subscription created | + | :Precondition: FHIR Subscription created. |
| − | :Success Criteria: FHIR server | + | :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. | :Bonus point: Subscriber subsequently fetches Slots associated with Schedule from notification. | ||
==Notes== | ==Notes== | ||
Please discuss/explore this tracker issue: [https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=14646] | Please discuss/explore this tracker issue: [https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=14646] | ||
| + | |||
| + | ==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 | ||
| + | * Isaac Vetter | ||
| + | * 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: | ||
| + | * [https://chat.fhir.org/#narrow/stream/75-subscriptions/subject/Detecting.20data.20that.20no.20longer.20qualifies Detecting data that no longer qualifies for a subscription] | ||
| + | * [https://chat.fhir.org/#narrow/stream/75-subscriptions/subject/Subscription.20Validation Validation of subscription: realtime vs. delayed] | ||
| + | * [https://chat.fhir.org/#narrow/stream/75-subscriptions/subject/Gforge.2014646 GForge 14646 discussed a bit] | ||
| + | * Logged [https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=18990 GForge 18990] to suggest removing Subscription.tag and suggest use of CommunicationRequest/Communication (or other) for this type of need. | ||
| + | * Logged [https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=18991 GForge 18991] to clarify payload value set (make a value set instead of a string) and possibly add an invariant around email/SMS. | ||
| + | * Logged [https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=18992 GForge 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 [https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=18993 GForge 18993] to address subscriber-side security concerns and impacts that could have to the FHIR server they're subscribed to. | ||
| + | * Logged [https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=18994 GForge 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. | ||
Latest revision as of 20:11, 30 September 2018
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
- Isaac Vetter
- 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
- Validation of subscription: realtime vs. delayed
- GForge 14646 discussed a bit
- Logged GForge 18990 to suggest removing Subscription.tag and suggest use of CommunicationRequest/Communication (or other) for this type of need.
- Logged GForge 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 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 to address subscriber-side security concerns and impacts that could have to the FHIR server they're subscribed to.
- Logged GForge 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.
