FHIR Chat · WebSockets · FHIRcast

Stream: FHIRcast

Topic: WebSockets

Bas van den Heuvel (Jan 14 2019 at 17:49):

I took a look at the WebSocket proposal on github (https://github.com/fhircast/docs/pull/57/commits/2cc6c907cdeb7e69369bd58f8af9b00a896f9633?short_path=1a523bd#diff-1a523bd9fa0dbf998008b37579210e12). I was wondereing, when using websockets, why do you need to initialize the connection using the rest-api? Couldn't you just open a websocket and send the subscripe overr that channel?

Bas van den Heuvel (Jan 14 2019 at 17:50):

Other question on websockets -- what protocol are we using on top of Websockets? STOMP (https://stomp.github.io/stomp-specification-1.2.html)?

Isaac Vetter (Jan 14 2019 at 17:57):

Hey Bas! Your two questions/points are nicely interrelated. Our current prototype implementations and the PR to the spec that you cite is intended to specify the use of raw Websockets (no sub-protocol above websockets). We spent some time loking at the common websocket libraries, each of which also tends to define its own sub-protocol, typically in a proprietary way. This means that SignalR clients really only work with SignalR servers, same with socket.io, etc. Here's some background.

Isaac Vetter (Jan 14 2019 at 17:58):

Use of the REST API to established the subscription (and the other client -> Hub API calls) makes sense for two reasons:

Isaac Vetter (Jan 14 2019 at 17:58):

1) Compatibility between websub/rest-hooks and websockets. I wanted to minimize the divergence between these two comm methods as much as possible

Isaac Vetter (Jan 14 2019 at 18:00):

2) _raw_ websockets, when implemented in a browser, doesn't support the sending of HTTP headers in the HTTP->websocket upgrade. Since we're encouraging the use of OAuth2, we really want to send the Authorization HTTP header with a bearer token when establishing the subscription.

Isaac Vetter (Jan 14 2019 at 18:00):

I hadn't actually seen STOMP. Do you have a sense of how widely deployed it is?

Bas van den Heuvel (Jan 14 2019 at 18:01):

I hadn't actually seen STOMP. Do you have a sense of how widely deployed it is?

It is the default protocol in Java Spring Boot appliactions - I do not have figures but Spring is used a lot

Bas van den Heuvel (Jan 15 2019 at 16:54):

Isaac and I took another look at the spec and it might be a good idea to reformat it; split the specification into three layers:
1. channel protocol - indicates that we are supporting multiple protocols (websub, webhoos, rest access to context, ...)
2.Define subscribe/unsubscribe pattern and event type
3. Event definitions

The channel protocols we currently have are:
1. WebSub (exisiting spec)
2. Websockets (see below)
3. pull based context
These could each be described in a separate document with its own lifecycle.

In order to separate the channels, I suggest to access them on different end-points:
WebSub <baseurl>/<topic>/websub
WebSocket <baseurl>/<topic>/websocket
Context <baseurl>/<topic>/context

<baseurl>/<topic> will give you a list of the supported protocols.

Bas van den Heuvel (Jan 15 2019 at 16:58):

A first proposal for a STOMP based websocket protocol - please comment:Use STOMP 1.2.
Some functionality is not required for FHIR CAST. Clients and server SHALL implement the required functionality and SHOULD implement the other.

STOMP subset
We will be using STOMP 1.2 over WebSocket. Not all functionality from STOM is required.
The table below indicates the functionality that MAY be unsupported. It is RECOMMENDED that the client and server implement the other functionality required by STOMP although it will not be used by this specification.

The following table shows the support requirements for the different STOMP messages.
Message Source Status Description
CONNECT Client REQUIRED Connect to websocket
SUBSCRIBE Client REQUIRED Subscribe to channel
UNSUBSCRIBE Client REQUIRED Unsubscribe from channel
BEGIN Client OPTIONAL Start transaction
COMMIT Client OPTIONAL Commit transaction
ABORT Client OPTIONAL Abort transaction
ACK Client REQUIRED Acknowledge
NACK Client REQUIRED Not Acknowledge
DISCONNECT Client REQUIRED Disconnect websocket
MESSAGE Server REQUIRED Send message to client
RECEIPT Server REQUIRED Indicate receipt content
ERROR Server REQUIRED Indicate error occurred

Destinations
Clients send messages to destinations, a destination is a directory like name on the server.
All FhirCast destinations are prefixed with /fhircast/ to separate them from other communication.

Client-->Server communication SHALL use the following pattern:
/fhircast/server/<clientid>/<event>
where
<clientid>: is a unique id of the client, e.g. the client-id used in OAUth
<event> is the event name/id the client sends a message to

Server ->Client SHALL use the following destinations:
/fhircast/client/<clientid>/<event>
where
<clientid>: is a unique id of the client, e.g. the client-id used in Oauth
<event> is the event name/id the client sends a message to

Implementations can distinguish on OAuth role, adding client-id makes it easier to filter who receives what.

Use cases
Client Subscribe/ Unsubscribe
All clients can register on each end-point - check that the client is really linked to <clientid> - prevent other clients from guessing it.

SUBSCRIBE /fhircast/server/<clientid>/<event>

server replies with message to  
    /fhircast/client/<clientid>/<event>
    {
        "message": "subscription-conformation"
        "secret": "<some-secret>"
        "event": <last-event>
    }

<some-secret> is included in all communication to this client - clients SHALL ignore messages that does not have the correct secret. This is added to prevent clients sending messages to incorrect channels.

UNSUBSCRIBE <destination>
Client-server
UNSUSCRIBE /fhircast/client/<clientid>/<event>
Server replies to RECEIPT /fhircast/client/<clientid>
{
"message": "unsubscribe"
"secret": "<some-secret> "
}
Allowing clients to detect that subscription has been done. This can only be done if the STOMP subscription id is known. If the unsubscribe is not intended, it can re-subscribe.
If unallowed, or incorrect -> ERROR will be returned.

Deny subscription
Server -> Client
MESSAGE /fhircast/client/<client-id>/<event>
{
"message": "subscription-deny"
"secret": "<some-secret>"
}

Sending events
Server sends event
Server->Client
MESSAGE /fhircast/client/<client-id>/<event>
{
"message": "event"
"secret": "<some-secret>"
"event": EVENT
}

Clients updates context
Server->Client
MESSAGE /fhircast/client/<client-id>/<event>
{
"message": "event"
"secret": "<some-secret>"
"event": EVENT
}

If server accepts it  - ok otherwise, error.

Josh Mandel (Jan 15 2019 at 18:52):

I'm having a hard time following the formatting here (e.g., to tell which messages are sent over WS, vs which messages are http calls, or where the breaks are. Maybe a quick markdown write-up would help?

George Kustas (Jan 15 2019 at 20:17):

Can we assume from this example that "WebSocket clients" will use the web socket for everything, and not just for receiving events from the Hub? @Josh Mandel - I think that Bas' example is ALL websockets which would answer your question, no?

Josh Mandel (Jan 15 2019 at 20:20):

That helps somewhat; still can't quite tell what's happening with the JSON bits, the "secret" values. An end-to-end example would probably help too.

George Kustas (Jan 15 2019 at 20:32):

I think the URL escaping that was done inadvertently (by Zulip?) does make the one sample difficult to read. I'll let @Bas van den Heuvel or @Isaac Vetter define how "secret" is being used.

By the way, I like the proposal. I never heard of STOMP, but when I proposed raw JSON, I didn't feel particularly good about it. It's nice how the destinations are modeled after URL endpoints, and having the ACK/NACK (How HL7-like) is a good idea.

@Martin Bellehumeur and I need to start working on our prototypes soon, which will include this change (if approved) and OAuth. Interested to hear more.

Bas van den Heuvel (Jan 15 2019 at 20:54):

I'll update and repost as soon as I have some time to generate the markdown. For those in present in San Antonio we could discuss it fac2face if ou want.

Bas van den Heuvel (Jan 15 2019 at 21:45):

@Josh Mandel thanks for the feedback. I'll take your feedback and update the document accordingly.

John Silva (Jan 16 2019 at 13:41):

@Bas van den Heuvel - this make sense and seems to follow the "separation of concerns" in the way IHE profiles are defined.

Bas van den Heuvel (Jan 17 2019 at 13:55):

I've updated the https://github.com/PhilipsOnFhir/fhir-cast repo to include context, websub and websocket functionality. It is still a little bit rough but it works.

Bas van den Heuvel (Jan 17 2019 at 16:31):

I've wrote down the proposal in a new github issue: https://github.com/fhircast/docs/issues/61

Isaac Vetter (Jan 17 2019 at 20:23):

@Bas van den Heuvel - wonderful writeup and thought!

Isaac Vetter (Jan 17 2019 at 20:23):

It looks like STOMP isn't a standard produced by an ANSI-accredited SDO. This would mean that us building on top of it would also make us responsible for justifying it's use if/when we went normative.

Josh Mandel (Jan 17 2019 at 20:24):

To be clear, this justification would just be a sentence or so, right?

Isaac Vetter (Jan 17 2019 at 20:26):

I think that we need some hardcore HL7 process perspective to explain to us the consequences of building on top of a non-ANSI standard. I usually (unfairly) lean on Elliot Silver for this for FHIRcast.

Josh Mandel (Jan 17 2019 at 20:37):

Well at least tag him @Elliot Silver ;-)

Elliot Silver (Jan 17 2019 at 20:57):

That's for tagging me -- I'll try to hook up with you guys to understand what we're talking about here -- I just skimmed this and need an orientation.

Isaac Vetter (Jan 17 2019 at 20:57):

can I buy you a cookie during cookie time in a little bit, @Elliot Silver ?

Elliot Silver (Jan 17 2019 at 20:59):

No, but we can talk anyhow. We're wrapping up in a couple of minutes.

George Kustas (Jan 18 2019 at 21:21):

@Isaac Vetter What is your take on the STOMP proposal being accepted? I ask because I wonder if it is worth my time to start implementing it on my end. There are STOMP client libraries for .NET, but I haven't seen anything for the server. We may have to implement that ourselves, so before I get too deep....

Martin Bellehumeur (Visage Imaging) (Jan 22 2019 at 13:07):

Websocket oAuth header handling possibility?
http://documentation.sas.com/api/docsets/espws/5.1/content/espws.pdf?locale=en

George Kustas (Jan 23 2019 at 15:03):

thanks @Martin Bellehumeur . on vacation this week but will look first thing over the weekend or on monday. At first glance, this looks like it may be an alternative to STOMP? Is it also proprietary spec?

Antti Kalliokoski (Jan 25 2019 at 07:31):

Hi! I came across FHIRcast documentation and GitHub repositories few weeks ago and I wanted to contribute to the project.

In order to familiarise myself with the topic, I implemented an experimental FHIRcast WebSocket client demo app using React. Source code, screen capture demo and links to online demo can be found on GitHub akalliokoski/fhircast-websocket-demo.

The implementation is based on WebSocket channel proposal described in sandbox.js. A fork of sandbox.js is used as a hub. As the specification of FHIRcast WebSocket channel is currently in development, the demo might already be outdated.

I would be happy to receive feedback and improvement ideas for the web app!

Martin Bellehumeur (Visage Imaging) (Jan 27 2019 at 08:36):

Wow!!! I love it. Would you consider having it hosted on the FHIRcast github? I think @Isaac Vetter would welcome that.

Antti Kalliokoski (Jan 27 2019 at 17:29):

Excellent, thanks for the positive feedback! Absolutely, I would happily transfer the ownership of the repository to FHIRcast.

Antti Kalliokoski (Jan 30 2019 at 08:17):

The repository of FHIRcast WebSocket client is now hosted on fhircast/reactclient.js. Thanks @Martin Bellehumeur and @Isaac Vetter for helping me!

George Kustas (Jan 30 2019 at 15:09):

@Antti Kalliokoski Your app looks great, and it's nice to have another participant using yet another development environment. I'm looking to get a prototype working with our radiology reporting system (Powerscribe360). Will this prototype of yours eventually be used in an existing radiology system (like PACS or RIS)? Also, what tool do you use to create the video? I'm kind of a newbie when it comes to github.

Antti Kalliokoski (Jan 31 2019 at 08:04):

I didn't plan to use the prototype in an existing radiology system but I could try to launch e.g. DWV using the prototype.

It would be nice to move the code that handles client's subscriptions and WebSocket to a separate module and create (UI framework agnostic) npm package for it. The npm package could then be used by any web app that needs FHIRcast client functionality. Would you find that kind of npm package useful, @George Kustas? Or is there anything else I could help you with your use case?

I used GIPHY Capture for creating the GIF on macOS. There are similar tools also for Windows (e.g. ScreenToGif), but I haven't used those.

George Kustas (Feb 06 2019 at 14:20):

@Antti Kalliokoski

Forgive me if you already know this, but I work for a company (Nuance) that provides radiology reporting services (and other things). Our reporting system is Powerscribe360 and we currently integrate with many other radiology apps, mostly PACS, using all sorts of various techniques such as COM, file drops, etc. We are hoping FHIRCast will consolidate that list.

By prototype, what we're really trying to do is help establish FHIRCast as a new standard by showing the industry that it works, works well, AND IS NOT HARD TO IMPLEMENT. We can do the latter by making certain parts of our code (maybe some libraries) publicly available and in different development environments. My stuff is mostly in C# (server and client). Others are using Java and/or Javascript(node).

If you work for a radiology vendor, can you share who it is? If not, we can always use the sample you provided as part of a demo, and I'm sure you can help us down the road.

By the way, I speak for me only. I'll let the other players speak for themselves :-)

Antti Kalliokoski (Feb 07 2019 at 12:03):

@George Kustas Cool, thanks for sharing what you are working on.

I work for a small Finnish software consulting company (Codeo) that is not specialized in healthcare, actually. I'm just an individual healthcare geek in the company. :) Projects that I have involved in during my career have related to radiology, patient monitoring and laboratory informatics.

Sure, I would be happy to help also in the future. I'm able to contribute to FHIRcast by taking time off from work or when I'm not working for a customer (which is almost the same thing as taking time off).

Bas van den Heuvel (Feb 21 2019 at 08:57):

I've a java implementation in https://github.com/PhilipsOnFhir/fhir-cast - I receommend that you look at the develop branch for the websocket work.

Antti Kalliokoski (Feb 21 2019 at 11:14):

Thanks @Bas van den Heuvel, I'll check your Java implementation and Angular clients out.

Antti Kalliokoski (Feb 25 2019 at 08:08):

Is the STOMP based websocket spec proposal currently the way to go? I was wondering if I should change the React client to use STOMP instead of plain websocket and use the Java implementation as a hub.

George Kustas (Feb 28 2019 at 19:55):

Hi @Antti Kalliokoski

Some of us are still using raw JSON because there seems to be an open question as to whether or not STOMP will be used. We simply created a simple wrapper around the schema and bind/unbind it to our applications data model. The wrapper simply adds a "header" and a "body" element that helps us keep with the HTTP model. See the doc for an example. I like the idea of STOMP, but given the limited amount of data that will be sent over the websocket, it may not be needed. We currently are only using websocket protocol for event notifications.

I am leading an effort to perform a prototype test of simple context sharing between applications. See attached document: FHIR-Websockets-Prototype-Spec.docx

I will provide a hub and will be implementing a test client, as well as my company's Radiology reporting system. I'm hoping to get it done by the end of March. You and everyone else is invited to participate! @Will Maethner @Bas van den Heuvel @Isaac Vetter @Martin Bellehumeur @Leo Bergnéhr

I assume some of you are already preparing for Montreal in May. It would be nice to go there already "bragging" of having a prototype under our belts.

Antti Kalliokoski (Mar 01 2019 at 10:48):

Excellent, thanks @George Kustas. I think I'll also start prototyping little bit based on your spec.

George Kustas (Mar 01 2019 at 13:02):

That would be great @Antti Kalliokoski . You mentioned something about DWV. It would be real sweet to have a test application using FHIRCast that actually displays reals images and uses meta data (MRN and accession numbers). I was thinking of looking into that once I finish implementing our own code. Have you actually done any work with this image viewer? I have an MRI of my elbow I got before surgery last week! we can use it for testing :-) Haha

Here is an updated spec. I've been meaning to do this and I've been putting it off: FHIR-Websockets-Prototype-Spec.docx

I am also going to (finally) post my prototype code in Github (pending permission is granted) - stand by. it's all .Net environment. .Net Core Hub, and Web Forms C# test app. This is because my programming shop is all Microsoft. It should still be somewhat helpful to other development environments. @Martin Bellehumeur has a Node.js implementation that you can use too.

Antti Kalliokoski (Mar 02 2019 at 10:49):

@George Kustas, it's great that you will provide some test images. :D I haven't tried to launch DWV yet but I'll do it next week. The spec for the WebSocket client (web app) prototype could be something like this:

• UI controls
  • log in/out
  • open/switch/close imaging study
• Image Viewer (DWV)
  • launched based on the context
• Functionality
  1) User logs in with username (secret is stored in the UI app for now)
  2) Get topic from the hub based on username and secret
  3) Automatically subscribe to events: open-imaging-study, switch-imaging-study, close-imaging-study, user-logout
  4) Establish the WebSocket connection to the hub
  5) Get current context from the hub
  5.1) If context exists, launch DWV
  6) React to user actions and FHIRcast events

Bas van den Heuvel (Mar 04 2019 at 14:55):

I've quickly tried the solution now proposed in the spec - there are some issues (see github). Maybe we should have a short telco on the whole web-socket thingy.

Antti Kalliokoski (Mar 07 2019 at 12:32):

@George Kustas, I started prototyping WebSocket client that maybe could be used with your hub implementation. The code and a screen capture demo is in reactclient.js develop branch. Based on the screen capture, would this kind of UI be useful for a demo?

The implementation is still very much WIP (uses test data, not connected to hub). It uses DWV and just a random DICOM file for displaying imaging study. I also try to simplify the logic and move it in one place. In the original prototype (master) the logic is pretty hardcoded and scattered around the components.

George Kustas (Mar 07 2019 at 16:19):

Wow... This would be VERY valuable to any of us looking to demo and as a proof of concept. I look forward to bringing you and this app into our hub environment. I am still in the process of publishing everything to our cloud server. I'll be posting it's availability here soon. Thanks Antti!

Antti Kalliokoski (Mar 08 2019 at 09:52):

Nice, I'll work on the client implementation again next week. And when you have the hub running on your cloud server, I'll change the client to use the hub, start fixing bugs, add new functionality if needed etc..

George Kustas (Mar 11 2019 at 14:29):

I've finally made my .Net hub and test client public on github. Please take a look: https://github.com/fhircast/.net.

I am in the process of installing the hub on an azure cloud server. I'll post back when it is ready. In the meantime, I hope the readme will explain what I'm hoping to accomplish with a collaboration of prototypes.

Bas van den Heuvel (Mar 11 2019 at 16:01):

Great, I've updated my implementation to also support the other web-socket proposal (https://github.com/PhilipsOnFhir/fhir-cast - develop branch). I did not get around to check them against each other yet.

Isaac Vetter (May 06 2019 at 18:46):

:electric_plug: We have three formal ballot comments about web sockets. If you think that this is an important issue, could you please comment on github issue #104 by tomorrow night? (shout out to Ron Parker & @Bas van den Heuvel ).

Isaac Vetter (May 06 2019 at 18:48):

@George Kustas, @Bas van den Heuvel, @Martin Bellehumeur, @Ashish Singh , @Wouter Devriendt

Bas van den Heuvel (May 07 2019 at 19:20):

I've added my analysis, comments and preference to the git-hub issue.

Bas van den Heuvel (May 08 2019 at 09:09):

I've added a comment to the github issue.

Isaac Vetter (May 09 2019 at 18:41):

We've got time dedicated during two upcoming Imaging Integration calls to specifically talk through how we can and should enable web sockets in FHIRcast. If you're interested and/or experienced with the use of web sockets, especially as part of context synchronization, please join!

Isaac Vetter (May 09 2019 at 18:41):

Upcoming II FHIRcast web sockets calls via this gotomeeting:

• Wednesday, May 22, 2019, 10:00-11:00 US ET
• Thursday, June 20, 2019, 10:00-11:00 US ET

Isaac Vetter (May 09 2019 at 18:42):

cc @Bas van den Heuvel , @George Kustas , @Ashish Singh

George Kustas (May 09 2019 at 21:23):

I'm in. Thanks @Isaac Vetter

Isaac Vetter (Jun 18 2019 at 18:46):

@George Kustas wrote up this websocket proposal: https://github.com/HL7/fhircast-docs/wiki/Websocket-proposal, which we'll be talking through on the Thursday HL7 call (details).

Isaac Vetter (Jun 18 2019 at 18:46):

Any early thoughts? @Bas van den Heuvel , @Ashish Singh

Bas van den Heuvel (Jun 19 2019 at 11:36):

George - great work.
My first early thought: is the acknowledge over websockets needed? I think we can do without. This would also remove the requirement for a header and body section (just the content of the body is enough).

Isaac Vetter (Jun 19 2019 at 14:14):

hey @Bas van den Heuvel - @George Kustas and I were talking about the header/body section being potentially unnecessary in #253. I just removed this concept from George's writeup in the wiki.

Isaac Vetter (Jun 19 2019 at 14:19):

is the acknowledge over websockets needed?

I'm not sure about this. This same idea came up in some FHIR Subscriptions conversations last month. There is a connection established request/response in FHIR Subscriptions websockets right now. They call it bind/bound. See https://www.hl7.org/fhir/subscription.html#2.46.7.2, george's websocket proposal uses a dynamically generated url for the websocket connection that it specific to the session. FHIR Subscriptions is using a single FHIR server-wide url for all websocket connections.

George Kustas (Jun 19 2019 at 17:11):

I can think of some good uses for the acknowledgements. I'm thinking, for instance, the case where one of the clients loses its connection with the hub or takes too long to acknowledge (a hang). If the hub detects this situation, it would be nice if the other subscribers of that same topic could either receive an event from the hub, or the hub could expose a method to get the status of all subscribers to a topic.

Ashish Singh (Jun 20 2019 at 13:18):

@Isaac Vetter I went through the proposal from @George Kustas . It looks great.

Just a thought, Will there be a use-case wherein a hub can accept only a subset of the events. For instance, if one of the event (among the set of events subscriber has requested for) is not addressed by the Hub. Then What should the response from the hub should contain? Will it be a failure?

Isaac Vetter (Jun 20 2019 at 13:47):

It looks great.

Awesome. Are you also able to join our call in 20 minutes?

Isaac Vetter (Jun 20 2019 at 13:47):

if one of the event (among the set of events subscriber has requested for) is not addressed by the Hub. Then What should the response from the hub should contain?

The client requested list of events is specified in the subscription request in the hub.events POST parameter. The accepted/granted/supported list of events for which the client is successfully subscribed is listed in the Intent Verification Request's hub.events parameter. Does that make sense. In every subscription, the hub informs the client which events the subscription is for. This list could be different from those requested.

Ashish Singh (Jun 20 2019 at 14:51):

This list could be different from those requested.

Thanks . That makes sense.

Bas van den Heuvel (Jun 26 2019 at 14:51):

I've updated our implementation to test the new FhirCast Websocket spec (https://github.com/PhilipsOnFhir/fhir-cast/tree/websocket).

Doing this, I had to make some assumptions that I would like to verify:
- A subscribe/unsubscribe that has the channel.endpoint, will update the existing websocket.
- Websocket exists, what happens when a second connection is made? I assume we do the handshake based on the last subscription secret.
- If we get a subscripe/unsubscribe on a websocket connection with multiple clients, does each of them respond with the handshake. Assumed: yes
- What happens if the last connection on a websocket is dropped? Assumed - nothing.
- A subscribe/unsubscribe that has the channel.endpoint, will update the existing websocket.

George Kustas (Sep 07 2019 at 18:42):

Hey @Bas van den Heuvel I was about to post something new when I saw your post above asking for verification. I'm not sure I'm answering your questions but here is the way I've implemented it. Basically, I don't understand how multiple clients would connect on the same websocket. Here's what I do:
1. The initial Subscribe does NOT contain the endpoint, because the endpoint is unknown. The hub returns the endpoint on the Subscribe request. The client then connects to a websocket on that endpoint. The endpoint will be unique for that client.
2. A new websocket is created by each client after subscription.
3. The hub keeps a list of all subscriptions, and in that list (right now an in-memory dictionary) it stores the unique endpoint in channel.endpoint.
4. The hub also keeps a list of websockets indexed by the channel endpoint, so there is a one-to-one relationship with some or all of the subscriptions (obviously not the subscriptions that are using REST).
5. Each time a client requests a websocket connection, the hub essentially instantiates a new thread that simply reads inbound messages until the websocket is closed.
6. If a client websocket is dropped, the hub (web socket reader thread) removes that subscription from its list, and it's associated websocket from the in-memory collection. The thread then terminates.
Eventually, both in-memory collections (lists) will be database tables.

If you want to see my Hub websocket implementation, most of it is in one file in my github: https://github.com/fhircast/.net. Look at websocketmiddleware.cs .

So... the new thing I was here to post: If you recall I think it was you Bas that suggested we don't really need the intent verification step any more, since the hub establishes the websocket endpoint (which is not guessable). I agreed, but I think we were at the close of the call and we didn't get a general consensus. @Isaac Vetter still has it in the spec. Personally, I don't see the need for it and planned on removing it from my implementation. What do you guys think?

Martin Bellehumeur (Visage Imaging) (Sep 11 2019 at 10:26):

Hi @George Kustas , my client can subscribe , get websocket and received subscription acknowledge.
Sending events seems to work has well but when I connect two clients, I am not receiving the events I publish from the other client.

John Silva (Sep 11 2019 at 12:51):

Has the sandbox code been updated to use/test the websocket implementation?

Martin Bellehumeur (Visage Imaging) (Sep 11 2019 at 12:52):

I have one here that mimics the one from George:
https://hub-fhircast.azurewebsites.net/websocket

George Kustas (Sep 11 2019 at 13:35):

I have a call in a few minutes. If it’s not to late for you, we can connect at around 10:30 my time?

I’ll look at the logs to see if I can spot any problems.

By the way… I haven’t removed the intent verification for web socket connections, but I intended to after getting some confirmation from Isaac and Bas. If you are expecting it now, then I’ll leave it alone.

Martin Bellehumeur (Visage Imaging) (Sep 11 2019 at 14:26):

In theory, we can talk at 10:30. But waiting for the plumber to show up any minute

Martin Bellehumeur (Visage Imaging) (Sep 11 2019 at 16:38):

I have a client online configured for your hub here:
https://reporting-fhircast.azurewebsites.net/websocket
YOu can see the subscription response and you can send message through the websocket but I have not seen receiving a message yet.

Isaac Vetter (Sep 13 2019 at 02:35):

Martin, George -- did you come to a joint agreement as to the presence of the intent verification step when using websockets? The rationale for keeping it is to simply verify that the websocket connection is functional during the subscription creation process. Also note that a similar project -- FHIR Subscriptions, kind of copied us, by including a bind :id step during their websocket subscription creation

Isaac Vetter (Sep 14 2019 at 19:36):

From testing and discussion during the sept connectathon --

Isaac Vetter (Sep 14 2019 at 19:36):

When using websockets, the intent verification step no longer serves the purpose of validating the hub's connectivity to the callback url.

Isaac Vetter (Sep 14 2019 at 19:36):

In theory, preserving the intent verification step and placing it within the websocket stream could have the benefit of informing the subscriber of the hub.events it was granted, in the case where the Hub granted access to different events than the subscriber requested. However, note the the spec implies/assumes that the Hub will always either grant the requested events or reject the subscription.

Isaac Vetter (Sep 14 2019 at 19:37):

Overall, it really does seem like the intent verification step has no purpose. @George Kustas, @Bas van den Heuvel , @Martin Bellehumeur - do you agree?

Isaac Vetter (Oct 25 2019 at 18:58):

I just moved our websocket proposal from the wiki to the spec. First draft of PR here: https://github.com/HL7/fhircast-docs/blob/50b1a8bfe03cfb227237cc77bfda0e7a4f5ff827/docs/specification/Feb2020Ballot.md
Feedback encouraged! Especially from the developers that implemented per the wiki.

Last updated: Apr 12 2022 at 19:14 UTC