Difference between revisions of "201801 FHIR Subscriptions"
Isaacvetter (talk | contribs) |
Isaacvetter (talk | contribs) |
||
| Line 29: | Line 29: | ||
==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 |
==Roles== | ==Roles== | ||
Revision as of 17:56, 17 October 2017
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
Expected participants
Agfa, Applicadia, Epic
Roles
Please include information here regarding how much advance preparation will be required if creating a client and/or server.
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.
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.
