FHIR Chat · Sending Observations to VONK Server with Swift-SMART · implementers

Stream: implementers

Topic: Sending Observations to VONK Server with Swift-SMART


view this post on Zulip Yannick Börner (Feb 06 2020 at 13:59):

I would like to send my ECG Observations to a local VONK Server using SWIFT-SMART but I am having trouble grasping the concept on how to do it.

I started off creating a client according to the official SWIFT-SMART documentation (https://github.com/smart-on-fhir/Swift-SMART/wiki/Client) but I am now stuck on how to actually transmit the data. I don't have a lot of experience in Client-Server communication but usually I would create an object for the server and then perform operations with this very object. However, in SWIFT-SMART it looks like the operations are performed on the resources, which I don't really seem to understand. My question precisely is:

How do I transmit resources (regardless of whether they are a patient or observation) to a local VONK-Server in Swift using SWIFT-SMART?

I got as far as this (https://gist.github.com/ylboerner/10be4373780a870d2dd5e014e9f7062a) but can't seem to find a way to transmit resources using the client or server when looking at the documentation. (http://docs.smarthealthit.org/Swift-SMART/Classes/Client.html)

view this post on Zulip Lloyd McKenzie (Feb 06 2020 at 18:40):

@Pascal Pfiffner

view this post on Zulip Pascal Pfiffner (Feb 06 2020 at 20:22):

Your thoughts are correct. You create a Client instance that represents the server you connect to. Then you call resourceInstance.create(server: client.server). See https://github.com/smart-on-fhir/Swift-SMART/wiki/Resources#type-level linked from https://github.com/smart-on-fhir/Swift-SMART/wiki.

view this post on Zulip Yannick Börner (Feb 07 2020 at 12:08):

Thank you so much! Works like a charm now.

view this post on Zulip Yannick Börner (Apr 17 2020 at 16:07):

I'm currently struggling to send observations to an open VONK server via Swift-SMART.

This is my current code: https://gist.github.com/ylboerner/25f55d11ef8833e2419ab4acaa699494

The error apparently happens in line 23 and the error output is the following: "Optional(“Location” header resource type mismatch. Expecting “CapabilityStatement” in “serveraddress/metadata”)"

I suspect that I am not initiating my client correctly. The server is open and should not require any authentication. Any suggestions?

Thank you in advance!

view this post on Zulip Lloyd McKenzie (Apr 17 2020 at 16:09):

@Ward Weistra

view this post on Zulip Ward Weistra (Apr 17 2020 at 17:58):

Thanks @Lloyd McKenzie. Let me loop in Vonk experts @Mirjam Baltus @Christiaan Knaap

view this post on Zulip Michele Mottini (Apr 17 2020 at 18:10):

Which FHIR version is the open Vonk server using?

view this post on Zulip Mirjam Baltus (Apr 17 2020 at 18:33):

Vonk uses STU3 on the regular endpoint (https://vonk.fire.ly/), but if you need R4, you can use https://vonk.fire.ly/r4.
Both endpoints do respond to the /metadata request with a CapabilityStatement, but I do see that we have <endpoint>/metadata in the Location header of the response. It seems that the client does not expect that?

view this post on Zulip Mirjam Baltus (Apr 17 2020 at 19:17):

@Yannick Börner The Swift client looks at the headers of the response, and if it finds a Location header, it expects the resource type to be part of the url. In this case, our Vonk server does not send the resource type as part of that url, so your client generates an error. I do think that the client should not inspect that header, but I've found that other servers do not send that header at all. I'll discuss this internally to see if we need to eliminate the Location from our response.
In the meantime, could you do without the smartConnection.ready call to avoid the request to /metadata, and just start sending the Observations?

view this post on Zulip Yannick Börner (Apr 18 2020 at 08:42):

Michele Mottini said:

Which FHIR version is the open Vonk server using?

The server is using version 3.5.0.0.

view this post on Zulip Yannick Börner (Apr 18 2020 at 08:55):

Mirjam Baltus said:

Yannick Börner The Swift client looks at the headers of the response, and if it finds a Location header, it expects the resource type to be part of the url. In this case, our Vonk server does not send the resource type as part of that url, so your client generates an error. I do think that the client should not inspect that header, but I've found that other servers do not send that header at all. I'll discuss this internally to see if we need to eliminate the Location from our response.
In the meantime, could you do without the smartConnection.ready call to avoid the request to /metadata, and just start sending the Observations?

Thank you for your thorough explanation! The location header with the resource type included would be responsible for confirming the transaction right? If I send my request via Postman, the resource type is included within the location header.

I did try to send my observations without the smartConnection.ready() call but received the following error:

Optional(Error 423: [error] unknown)

Oddly enough, when I simply ran the application again with breakpoints enabled, the observations were successfully sent! This is a kind of behaviour which I observed before, where the first call simply failed and the second one succeeded without any changes made on my end.

view this post on Zulip Mirjam Baltus (Apr 20 2020 at 10:02):

@Yannick Börner The 423 Locked error is sent by Vonk when it is still starting up and loading conformance resources. Some platforms like IIS stop the server when it has been idle for some time, and start it again when a request comes in. This results in the 423 on the first request, but subsequent requests succeed since Vonk has started by then. How are you running your Vonk server?

view this post on Zulip Yannick Börner (Apr 20 2020 at 11:33):

@Mirjam Baltus I assume that the server is an instantiation on MS Azure without any additional configurations. Your answer makes sense, as I am the only one using that server every other day. Azure is likely putting it into an idle state because of that. Thank you so much!

view this post on Zulip Christiaan Knaap (Apr 22 2020 at 08:19):

Yannick Börner said:

Michele Mottini said:

Which FHIR version is the open Vonk server using?

The server is using version 3.5.0.0.

Just to avoid confusion: Version 3.5.0.0 is the version of Vonk. There is no FHIR version 3.5.0.0. The FHIR Version in use is 3.0.2. (Or , on the /R4 endpoint: 4.0.1).

view this post on Zulip Yannick Börner (Apr 22 2020 at 11:41):

Christiaan Knaap said:

Yannick Börner said:

Michele Mottini said:

Which FHIR version is the open Vonk server using?

The server is using version 3.5.0.0.

Just to avoid confusion: Version 3.5.0.0 is the version of Vonk. There is no FHIR version 3.5.0.0. The FHIR Version in use is 3.0.2. (Or , on the /R4 endpoint: 4.0.1).

You're absolutely right! I read that question too quickly :-)


Last updated: Apr 12 2022 at 19:14 UTC