This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "201801 FHIR Subscriptions"

From HL7Wiki
Jump to navigation Jump to search
Line 39: Line 39:
 
* 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 51:
 
: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.
  
−
<!-- Provide a description of each task -->
+
===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
  
−
==TestScript(s)==
+
===FHIRcast===
−
<!-- Optional (for initial proposal): Provide links to the TestScript instance(s) that define the behavior to be tested.
+
:Action: FHIR Server notifies Subscribing client by pushing a FHIR resource to the endpoint identified in the subscription resource instance.  
−
These should be committed to SVN under trunk/connectathons/[connectathon]
+
: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.
−
==Security and Privacy Considerations==
 
−
<!-- Optional (for initial proposal): Address the topic of Privacy and Security.  
 
−
* What Authentication/Authorization will be used (e.g. SMART on FHIR (OAuth), HEART (UMA/OAuth), IHE IUA (OAuth), generic OAuth, generic SAML, mutual-Auth-TLS), or explicitly indicate that it is out of scope and left to implementations.
 
−
* What Privacy Consent management will be used? When the Consent Resource is used, define how.
 
−
* What Audit Logging will be used? When the AuditEvent Resource is used, define expectations of what events will be logged and what each AuditEvent will contain.
 
−
* How will Provenance be used? Provenance use should be mandated when data is imported from other systems, so as to track that source of that data. Provenance should be used when data is authored by unusual sources, such as the Patient themselves or devices.
 
−
* How will security-labels be used? Security-labels are meta tags used to classify the data into various confidentiality, sensitivity, and integrity classifications. These security-labels are then available for use and available for access control decisions.
 
−
I am happy to help: JohnMoehrke@gmail.com -- security co-chair
 
−
-->
 

Revision as of 18:09, 17 October 2017


FHIR Subscriptions

Dedicated Zulip chat stream for this track.


Previous Care Plan Connectathons

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.

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.
Retrieved from "https://wiki.hl7.org/w/index.php?title=201801_FHIR_Subscriptions&oldid=147705"