This wiki has undergone a migration to Confluence found Here
Difference between revisions of "201801 FHIR Subscriptions"
Jump to navigation
Jump to search
Isaacvetter (talk | contribs) |
Isaacvetter (talk | contribs) |
||
| (7 intermediate revisions by 2 users not shown) | |||
| Line 6: | Line 6: | ||
'''Dedicated [https://chat.fhir.org/#narrow/stream/subscriptions/subject/Jan.20Connectathon.20track Zulip chat stream] for this track.''' | '''Dedicated [https://chat.fhir.org/#narrow/stream/subscriptions/subject/Jan.20Connectathon.20track Zulip chat stream] for this track.''' | ||
| + | * [https://drive.google.com/open?id=1AHdYlBxWkEnW1XSpWvNdAEcfx84187M- FHIR Subscriptions Track Orientation Slides] | ||
'''Previous Care Plan Connectathons''' | '''Previous Care Plan Connectathons''' | ||
| Line 26: | Line 27: | ||
<!-- Name, email and Skype id of individual who will coordinate the track at the connectathon --> | <!-- Name, email and Skype id of individual who will coordinate the track at the connectathon --> | ||
See [[Connectathon_Track_Lead_Responsibilities]] | See [[Connectathon_Track_Lead_Responsibilities]] | ||
| + | |||
| + | [mailto:isaac@epic.com Isaac Vetter] | ||
| + | |||
| + | ==FHIR version== | ||
| + | STU3 | ||
==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 --> | ||
| − | Agfa, Applicadia, | + | Agfa, Applicadia, Epic, Sectra |
==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=== | ||
| Line 39: | Line 44: | ||
* Must also act as a FHIR client to send notifications. | * Must also act as a FHIR client to send notifications. | ||
| − | ==Subscribing client== | + | ===Subscribing client=== |
Subscribes to FHIR server and gets updates. | Subscribes to FHIR server and gets updates. | ||
* Must create a Subscriptions instance on external FHIR server. | * Must create a Subscriptions instance on external FHIR server. | ||
* Must expose an endpoint to accept notifications. | * Must expose an endpoint to accept notifications. | ||
| + | ==Scenarios== | ||
===Create FHIR Subscription=== | ===Create FHIR Subscription=== | ||
:Action: Subscribing client creates a Subscription instance on FHIR Server using the topic extension, as illustrated, below. | :Action: Subscribing client creates a Subscription instance on FHIR Server using the topic extension, as illustrated, below. | ||
| Line 50: | Line 56: | ||
: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 with payload of "payload": "application/fhir+json"=== | |
| − | + | :Action: FHIR Server notifies Subscribing client by pushing a FHIR resource to the endpoint identified in the subscription resource instance. | |
| − | + | :Precondition: Create FHIR Subscription scenario | |
| − | + | :Success Criteria: FHIR server pushes FHIR payload of relevant resource using REST Hook when the subscribed event occurs in the FHIR server.. | |
| − | + | :Bonus point: n/a | |
| − | |||
| − | == | + | ===FHIRcast=== |
| − | + | :Action: FHIR Server notifies Subscribing client by pushing a FHIR resource to the endpoint identified in the subscription resource instance. | |
| − | + | :Precondition: Previous two scenarios; FHIR Server publishes workflow-type EventDefinition named "patient-chart-open" as described by [http://fhircast.org/index.html#app-subscribes-to-usersession-changes FHIRcast]. | |
| − | + | :Success Criteria: FHIR server pushes UserSession using REST Hook when the subscribed event occurs in the FHIR server. Subscribing client changes its UI to match the patient-chart-open event. | |
| − | + | :Bonus point: FHIR Server detects error scenario and reacts according to its own configuration. | |
| − | |||
| − | |||
| − | |||
| − | |||
Latest revision as of 15:47, 23 January 2018
FHIR Subscriptions
Dedicated Zulip chat stream for this track.
Previous Care Plan Connectathons
- 201709 FHIR Subscriptions, September 2017, San Diego, CA
Submitting WG/Project/Implementer Group
Imaging Integration, FHIR-I, CDS
Justification
The Imaging Integration is sponsoring a project to create a new context synchronization profile using FHIR Subscriptions called FHIRcast (FHIR-I and CDS are co-sponsors).
This track is an important step in advancing the maturity of the interactions and resources associated with both FHIRcast and FHIR Subscriptions in general.
The subscription pub/sub pattern enables FHIR clients to retrieve data from a server without performing a more expensive periodic polling queries. This model also enables workflow event-based notifications that could keep two applications data in sync, but also synchronize their context. We're working within the RIS/PACS community to identify a common, lightweight application synchronization standard.
This track will attempt to prototype this event-based concept on top of the existing FHIR Subscription REST hook and criteria element and prototype this workflow synchronization using FHIR Subscriptions according to the draft FHIRcast specification.
Proposed Track Lead
See Connectathon_Track_Lead_Responsibilities
FHIR version
STU3
Expected participants
Agfa, Applicadia, Epic, Sectra
Roles
FHIR Server
The FHIR Server supports the Subscription resource and pushing relevant FHIR resources to client.
- Must expose a Subscriptions resource supporting read, create and update.
- Must also act as a FHIR 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 using the topic extension, as illustrated, below.
- 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.
- 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 with payload of "payload": "application/fhir+json"
- Action: FHIR Server notifies Subscribing client by pushing a FHIR resource to the endpoint identified in the subscription resource instance.
- Precondition: Create FHIR Subscription scenario
- Success Criteria: FHIR server pushes FHIR payload of relevant resource using REST Hook when the subscribed event occurs in the FHIR server..
- Bonus point: n/a
FHIRcast
- Action: FHIR Server notifies Subscribing client by pushing a FHIR resource to the endpoint identified in the subscription resource instance.
- Precondition: Previous two scenarios; FHIR Server publishes workflow-type EventDefinition named "patient-chart-open" as described by FHIRcast.
- Success Criteria: FHIR server pushes UserSession using REST Hook when the subscribed event occurs in the FHIR server. Subscribing client changes its UI to match the patient-chart-open event.
- Bonus point: FHIR Server detects error scenario and reacts according to its own configuration.
