FHIR Chat · docs / Issue #45 FHIRCast Prototype with Websocket client... · fhircast-github

Stream: fhircast-github

Topic: docs / Issue #45 FHIRCast Prototype with Websocket client...


view this post on Zulip Github Notifications (FHIRcast) (Nov 16 2018 at 17:04):

gkustas opened Issue #45

I am currently implementing a prototype FHIRCast implementation that includes:

1. A FHIR Hub.
2. A FHIRCast integration module for the Powerscribe360 Reporting solution (by Nuance)
3. A Test Client application (used to simulate other clients, such as PACS)

Items #1 and #3 are running, and item #2 is partially running. I'm hoping to have something ready for testing in a week or two.

At this point, I would like to share the technical specification details. Because this implementation supports Websockets, there are going to be several conformance issues that have been discussed in other issues on this forum. Particularly in how the FHIRCast(WebSub) subscription/publication model works with regards to callbacks.

My implementation proposes a solution that attempts to closely follow the FHIR and FHIRCast specifications for use with Radiology reporting context changes. The events supported by the hub include:

open-imaging-study
switch-imaging-study
close-imaging-study
user-logoff

I'm attaching a MS Word document which describes the implementation and specifications in more detail. I wold love to get feedback from all of you, particularly someone interested in implementing a FHIRCast client (like PACS).

There are several areas of the FHIR and FHIRCast specs that are unclear to me. Among them:
1. For studies, what are the standards for specifying an accession number identifier (what is the system value?).
2. For patients, what are the standards for patient MRN, etc.?
3. Error handling - so many things to discuss eventually, but at this prototype stage I am going to defer implementation. Discussion would be helpful though at this time.
4. Like error handling, authentication needs to be discussed, but is being deferred from implementation.
5. Topics: I view the topic as an identifier for a user session. User Joe logs into PACS, and then into Powerscribe360 to dictate a report for the study. The user session is defined as all of the software being used by user Joe. But if user Joe doesn't have identical user names on each of his software systems, what can be used to identify the user session (topic name)?

If anyone is interested, I can share source code, put our hub in the cloud, and perform unit testing with Powerscribe360.

FHIR Websockets.docx

view this post on Zulip Github Notifications (FHIRcast) (Nov 16 2018 at 17:22):

gkustas edited Issue #45

I am currently implementing a prototype FHIRCast implementation that includes:

1. A FHIR Hub.
2. A FHIRCast integration module for the Powerscribe360 Reporting solution (by Nuance)
3. A Test Client application (used to simulate other clients, such as PACS)

Items #1 and #3 are running, and item #2 is partially running. I'm hoping to have something ready for testing in a week or two.

At this point, I would like to share the technical specification details. Because this implementation supports Websockets, there are going to be several conformance issues that have been discussed in other issues on this forum. Particularly in how the FHIRCast(WebSub) subscription/publication model works with regards to callbacks.

My implementation proposes a solution that attempts to closely follow the FHIR and FHIRCast specifications for use with Radiology reporting context changes. The events supported by the hub include:

open-imaging-study
switch-imaging-study
close-imaging-study
user-logoff

I'm attaching a MS Word document which describes the implementation and specifications in more detail. I wold love to get feedback from all of you, particularly someone interested in implementing a FHIRCast client (like PACS).

There are several areas of the FHIR and FHIRCast specs that are unclear to me. Among them:
1. For studies, what are the standards for specifying an accession number identifier (what is the system value?).
2. For patients, what are the standards for patient MRN, etc.?
3. Error handling - so many things to discuss eventually, but at this prototype stage I am going to defer implementation. Discussion would be helpful though at this time.
4. Like error handling, authentication needs to be discussed, but is being deferred from implementation.
5. Topics: I view the topic as an identifier for a user session. User Joe logs into PACS, and then into Powerscribe360 to dictate a report for the study. The user session is defined as all of the software being used by user Joe. But if user Joe doesn't have identical user names on each of his software systems, what can be used to identify the user session (topic name)?

If anyone is interested, I can share source code, put our hub in the cloud, and perform unit testing with Powerscribe360.

FHIR Websockets.docx

view this post on Zulip Github Notifications (FHIRcast) (Nov 17 2018 at 19:27):

jeremysrichardson commented on Issue #45

Hey @gkustas I read your document and have similar concerns related to integration of reporting. We should connect and discuss.

Also, @lbergnehr has been doing some SignalR work, which fits your use cases, and mine, and apparently his, significantly better.

view this post on Zulip Github Notifications (FHIRcast) (Nov 17 2018 at 19:28):

jeremysrichardson {} a comment on Issue #45

Hey @gkustas I read your document and have similar concerns related to integration of reporting. We should connect and discuss. Are you or anyone concerned with context sync going to be at RSNA?

Also, @lbergnehr has been doing some SignalR work, which fits your use cases, and mine, and apparently his, significantly better.

view this post on Zulip Github Notifications (FHIRcast) (Nov 18 2018 at 08:43):

mbellehumeur commented on Issue #45

Hi @gkustas,
I have the same issue with the “session-id/hub.topic”. In my mind, the hub has to resolve session assignment through some mechanism (same user id, if not same hostname,..).
Regarding the need for the client to listen on a socket, I had a different understanding. To me, only the application servers needs to receive notification and they would take care to notify their clients with whatever is convenient for their app. I tried to convey that in the JS sandbox (https://github.com/fhircast/sandbox.js).
That said I am interested in your proposal of websockets directly to the hub and would like to prototype something to that effect. Could we have a chat early this week? I’m on Frankfurt time . Thanks, Martin

view this post on Zulip Github Notifications (FHIRcast) (Nov 18 2018 at 14:24):

gkustas commented on Issue #45

@jeremysrichardson , @mbellehumeur
Thanks for posting.

I will not be at RSNA, but my manager Dave Rubin will be in the Nuance booth (and around) all week. He is the engineering manager for this project and all of Powerscribe360. Over the last 15 years or so, we've both been working on radiology reporting interfaces (HL7) and desktop integrations. We currently have over a dozen different flavors including our standard XML file, our proprietary COM API, and several other vendor proprietary integrations (GE, Mckesson, Sectra, etc.). We're really hoping FHIRCast can eventually replace them all.

Concerning SignalR, I don't have a strong feeling about it. I chose Websockets because it is now supported in all common browsers and web servers. I was thinking SignalR would be overkill. My Websocket implementation is incredibly simple - especially in this "context" (pun intended).

Before going in this direction, I did pursue the idea of creating an "application server" as you describe @mbellehumeur. I read your post just the other day. Our product is a thick client (Windows Forms) and our application server is essentially a web service used for data access (SQL DB). There currently is no unsolicited messaging to the app. We would have to create all that, and probably do it the same way I'm doing it in our hub (via Websockets). In my mind it just creates another layer (message router) into the equation - another point of failure. It also means that every player involved would have to implement both a FHIRCast client and a FHIRCast application server which is more work, obviously, than just the client. Not just implementation, but installation and support.

That said, if Websockets aren't going to be accepted in the FHIRCast specification, then we'll have to consider falling back to that approach.

I would like to connect with both of you this week prior to RSNA if possible. I can be reached best via email at george.kustas@nuance.com

view this post on Zulip Github Notifications (FHIRcast) (Nov 19 2018 at 15:12):

gkustas closed Issue #45

I am currently implementing a prototype FHIRCast implementation that includes:

1. A FHIR Hub.
2. A FHIRCast integration module for the Powerscribe360 Reporting solution (by Nuance)
3. A Test Client application (used to simulate other clients, such as PACS)

Items #1 and #3 are running, and item #2 is partially running. I'm hoping to have something ready for testing in a week or two.

At this point, I would like to share the technical specification details. Because this implementation supports Websockets, there are going to be several conformance issues that have been discussed in other issues on this forum. Particularly in how the FHIRCast(WebSub) subscription/publication model works with regards to callbacks.

My implementation proposes a solution that attempts to closely follow the FHIR and FHIRCast specifications for use with Radiology reporting context changes. The events supported by the hub include:

open-imaging-study
switch-imaging-study
close-imaging-study
user-logoff

I'm attaching a MS Word document which describes the implementation and specifications in more detail. I wold love to get feedback from all of you, particularly someone interested in implementing a FHIRCast client (like PACS).

There are several areas of the FHIR and FHIRCast specs that are unclear to me. Among them:
1. For studies, what are the standards for specifying an accession number identifier (what is the system value?).
2. For patients, what are the standards for patient MRN, etc.?
3. Error handling - so many things to discuss eventually, but at this prototype stage I am going to defer implementation. Discussion would be helpful though at this time.
4. Like error handling, authentication needs to be discussed, but is being deferred from implementation.
5. Topics: I view the topic as an identifier for a user session. User Joe logs into PACS, and then into Powerscribe360 to dictate a report for the study. The user session is defined as all of the software being used by user Joe. But if user Joe doesn't have identical user names on each of his software systems, what can be used to identify the user session (topic name)?

If anyone is interested, I can share source code, put our hub in the cloud, and perform unit testing with Powerscribe360.

FHIR Websockets.docx

view this post on Zulip Martin Bellehumeur (Visage Imaging) (Dec 03 2018 at 15:59):

Hi George, I updated the sandbox.js code and readme with websocket channel option:
https://github.com/fhircast/sandbox.js/blob/master/README.md#try-the-websocket-channel-proposed-addition
it's not clear however how the client should publish events *websocket or JSON post like websub?). So I left websub for sending event to the hub for now.


Last updated: Apr 12 2022 at 19:14 UTC