Stream: fhircast-github
Topic: fhircast-docs / Issue #59 Subscription: hub.topic is the ...
Github Notifications (FHIRcast) (Mar 05 2019 at 14:37):
isaacvetter milestoned Issue #59(assigned to isaacvetter)
FYI @isaacvetter, @wmaethner, @mbellehumeur
Some notes/issues from connectathon discussions. Heavily relates to https://github.com/fhircast/docs/pull/57
The hub.topic parameter on the subscription request should contain the session identifier, which will be termed the "topic". The cast-session This value will be created in one of two ways:
1. The launching application (client) will generate and pass this topic value to the launched application in some manner (URL query string, command line parameter, etc.). The Hub (or AS) must generate this topic based on the user(s) subscribed in order for a single radiologist to share context between multiple applications (PACS/Reporting/EHR). Note: this is not possible (or practical) when applications are running on different workstations. Example launch:
https://www.hospital.com/reportingapp?topic=1b83cc8cf4ba4ead876bd7040230ea31
2. In the case of no "launching" application, but one application that drives the work list (_driver_) and the other applications launching independently:
The collaborating applications will develop a protocol which enables the _driver_ to generate a topic and share it with the other clients. This topic is then used by each client when subscribing to the hub (via hub.topic parameter). This protocol may have to be proprietary, or at least differ between collaborating vendors. We are currently investigating a solution using oAuth.
Other thoughts...
1. Unlike a typical WebSub application, a topics are not a semi-static list of values. For example, a simple chat application may have the topics:
(a) Weekly newsletter
(b) Daily status
(c) emergency broadcasts
A chat client can obtain the list of available topics from the server and subscribe as needed.
In the FHIRCast scenario, a topic is more dynamic, in that it represents a single user (radiologist or clinician) that uses multiple applications. This topic needs to be generated whenever a user logs into the driver (work list) application. The hub (or AS) needs to be able to identify this user on each application so that it can generate a common topi.2. The topic is a full URL which will contain randomly generated value as the ending portion of the path. This URL will be used by the websocket client as a endpoint for receiving context change notifications (such as ws://hub-fhircast/azurewebsites.net/1b83cc8cf4ba4ead876bd7040230ea31. In this way the client can be assured that it is not receiving rogue notifications from an unauthroized application.
Github Notifications (FHIRcast) (Mar 11 2019 at 17:44):
isaacvetter closed Issue #59(assigned to isaacvetter)
FYI @isaacvetter, @wmaethner, @mbellehumeur
Some notes/issues from connectathon discussions. Heavily relates to https://github.com/fhircast/docs/pull/57
The hub.topic parameter on the subscription request should contain the session identifier, which will be termed the "topic". The cast-session This value will be created in one of two ways:
1. The launching application (client) will generate and pass this topic value to the launched application in some manner (URL query string, command line parameter, etc.). The Hub (or AS) must generate this topic based on the user(s) subscribed in order for a single radiologist to share context between multiple applications (PACS/Reporting/EHR). Note: this is not possible (or practical) when applications are running on different workstations. Example launch:
https://www.hospital.com/reportingapp?topic=1b83cc8cf4ba4ead876bd7040230ea31
2. In the case of no "launching" application, but one application that drives the work list (_driver_) and the other applications launching independently:
The collaborating applications will develop a protocol which enables the _driver_ to generate a topic and share it with the other clients. This topic is then used by each client when subscribing to the hub (via hub.topic parameter). This protocol may have to be proprietary, or at least differ between collaborating vendors. We are currently investigating a solution using oAuth.
Other thoughts...
1. Unlike a typical WebSub application, a topics are not a semi-static list of values. For example, a simple chat application may have the topics:
(a) Weekly newsletter
(b) Daily status
(c) emergency broadcasts
A chat client can obtain the list of available topics from the server and subscribe as needed.
In the FHIRCast scenario, a topic is more dynamic, in that it represents a single user (radiologist or clinician) that uses multiple applications. This topic needs to be generated whenever a user logs into the driver (work list) application. The hub (or AS) needs to be able to identify this user on each application so that it can generate a common topi.2. The topic is a full URL which will contain randomly generated value as the ending portion of the path. This URL will be used by the websocket client as a endpoint for receiving context change notifications (such as ws://hub-fhircast/azurewebsites.net/1b83cc8cf4ba4ead876bd7040230ea31. In this way the client can be assured that it is not receiving rogue notifications from an unauthroized application.
Last updated: Apr 12 2022 at 19:14 UTC
