Stream: fhircast-github
Topic: docs / Issue #59 Subscription: hub.topic is the session i...
Github Notifications (FHIRcast) (Jan 12 2019 at 21:33):
gkustas opened Issue #59
The hub.topic parameter on the subscription request should contain the session identifier, which will be termed the "topic". This value will be created in one of two ways:
1. The launching application will generate and pass this topic value to the launched application in some manner (url query string, command line parameter, etc.). Example:
https://www.hospital.com/reportingapp?topic=jgfkjsafgjaskfghasdsf
2. In the case of no "launching" application, but one application that drives the work list ("_driver_") and each other application launching independently:
The collaborating applications (clients) 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. Example to follow:
Github Notifications (FHIRcast) (Jan 12 2019 at 21:35):
gkustas edited Issue #59
The hub.topic parameter on the subscription request should contain the session identifier, which will be termed the "topic". 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.). Example:
https://www.hospital.com/reportingapp?topic=jgfkjsafgjaskfghasdsf
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. Example to follow...
Github Notifications (FHIRcast) (Jan 13 2019 at 17:40):
gkustas edited Issue #59
FYI @isaacvetter, @wmaethner, @martinbellemeur
Some noted from connectathon discussions...
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) (Jan 13 2019 at 17:41):
gkustas edited Issue #59
FYI @isaacvetter, @wmaethner, @martinBellehumeur
Some noted from connectathon discussions...
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) (Jan 13 2019 at 17:42):
gkustas edited Issue #59
FYI @isaacvetter, @wmaethner, @mbellehumeur
Some noted from connectathon discussions...
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) (Jan 13 2019 at 21:33):
gkustas edited Issue #59
FYI @isaacvetter, @wmaethner, @mbellehumeur
Some notes/issues from connectathon discussions...
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) (Jan 13 2019 at 21:36):
gkustas edited Issue #59
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) (Feb 05 2019 at 16:43):
isaacvetter commented on Issue #59
Hey @gkustas - if you have a chance, would you mind taking a look at PR #63 ?
I _think_ that it resolves most of this issue.
Github Notifications (FHIRcast) (Feb 05 2019 at 16:43):
isaacvetter assigned 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) (Feb 09 2019 at 02:32):
gkustas commented on Issue #59
I think so. When you have a chance, please review my proposal for our
prototype which is a non-oauth implementation. Martin and I will likely be
implementing this as soon as he is back from his holiday and can take a
look at it. It's in the FHIRCast-Websockets thread, and I believe I sent
you an email. Thanks Isaac!On Tue, Feb 5, 2019 at 11:43 AM Isaac Vetter <notifications@github.com>
wrote:Hey @gkustas <https://github.com/gkustas> - if you have a chance, would
you mind taking a look at PR #63
<https://github.com/fhircast/docs/pull/63> ?I think that it resolves most of this issue.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<https://github.com/fhircast/docs/issues/59#issuecomment-460710354>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AFw87kf57yVUECRXesDq9dTTEtZoD7_9ks5vKbScgaJpZM4Z82_C>
.--
George Kustas
Last updated: Apr 12 2022 at 19:14 UTC
