Stream: FHIRcast
Topic: Content exchange
Bas van den Heuvel (Sep 24 2020 at 17:29):
Isaac indicated that it would be wise to bring this to the FHIRcast github repo. What would be a good place to put the different proposals and discussion items in this repo? A new page in the wiki?
Isaac Vetter (Sep 24 2020 at 22:42):
Hey Bas, the wiki would work fine. I'd actually recommend it as a new .md file in the repo, so that we get actual version control, though.
Bas van den Heuvel (Oct 01 2020 at 14:43):
I've uploaded a first version of a potential spec text based on the presentation discussed during the connecthaton to the wiki: https://github.com/HL7/fhircast-docs/wiki/Data-storage-and-content-synchronization-----FHIR-server-option
Martin Bellehumeur (Visage Imaging) (Oct 12 2020 at 08:57):
Hi Bas, thanks for the proposal. I am in general agreement.
I would prefer to use REST to create FHIR resources but I have tried to implement REST over SSL for posting user commands and gave up. it is simply too sluggish for desktop integration. For every action, you need a new connection, go through the ssl handshake - exchange and verify certificate chain - and then the command is sent. This takes 500ms to 1000ms. When I send the same FHIRcast command over the secure websocket, it takes less than one millisecond because the connection is already established. The user experience is much better over websocket than rest and I can’t justify using rest.
Are you having the same issue?
From my perspective, I would need to focus on using FHIR messaging instead of rest), if we are to deliver a responsive user experience. Perhaps by adding scratchpad-update and scratchpad-search to FHIR message events?
http://www.hl7.org/fhir/stu3/valueset-message-events.html
Vassil Peytchev (Oct 12 2020 at 19:01):
For every action, you need a new connection, go through the ssl handshake - exchange and verify certificate chain - and then the command is sent.
Is this something specific in FHIRcast? HTTPS allows for the Keep-Alive, is that not usable here?
Martin Bellehumeur (Visage Imaging) (Oct 13 2020 at 10:55):
For me, the https connection drops after 3 minutes. Then it’s a reconnect with TLS client/server hello. The websocket connection stays up and it has a heartbeat and reconnect method. Maybe the hub can do set something to maintain https socket open. I’ll give it another try.
Bas van den Heuvel (Oct 13 2020 at 19:58):
Taking 500ms to 1000ms for a simple PUT or POST is indeed long. If 500ms to 1000ms are typical values for such interactions, than this will impact other, non FHIRcast, use cases as well. They are longer than my experience with calls on the Cerner and Epic sandboxes. Which server did you use?
Bas van den Heuvel (Oct 13 2020 at 20:00):
If I understand your proposal correctly, you propose to use FHIR events to address this issue. In FHIRcast sending events is done using the RESTfull API. Websockets are only used for receiveing events. I do not understand how using FHIRcast events for updating the scratchpad would solve this issue. Do I miss anything?
Martin Bellehumeur (Visage Imaging) (Oct 14 2020 at 06:34):
The hub is somewhere in the US and I am in Frankfurt.
This is what I see in wireshark for a FHIRcast event (https post):
image.png
Martin Bellehumeur (Visage Imaging) (Oct 14 2020 at 06:35):
In the first iteration of websockets for FHIRcast, events were sent over the websocket connection and early hubs did it that way.
I was thinking using FHIR messaging (not FHIRcast events) to create FHIR resources in the scratchpad since we cannot do rest on the websocket directly.
The solution to the https connect latency could be to keep the https socket to the hub open and send the rest/event commands without reconnect for the whole session. But then I would need to add a heartbeat and reconnect to the http connection; similar to what websocket has natively. The PACS application survives a network bounce and the integration has too as well to pass the test protocols.
Last updated: Apr 12 2022 at 19:14 UTC
