Stream: finnish PHR
Topic: Server metadata
Mikael Rinnetmäki (Jun 19 2018 at 19:02):
Hi! It seems https://fhirsandbox2.kanta.fi/phr-resourceserver/baseStu3/metadata is not accessible without a valid access token. That's unfortunate for FHIR apps that would handle the authentication automatically, based on the metadata provided by the server. Another way to get the auth and token locations would be from the "well known" location at https://fhirsandbox2-auth.kanta.fi/.well-known/openid-configuration (based on OpenID specs), but that does not seem to be available either.
How should a FHIR app query for the auth and token locations of the server?
Pirjo Vuorikallas (Jun 27 2018 at 07:51):
Hi, thanks for question. We have to think about this from a whole Kanta PHR service architecture view, so we’ll get back to you later.
Juha Paasolainen (Jul 03 2018 at 10:01):
Hi,
not any client can use the PHR production environment. You have to go through the connection process to connect a client. Therefore the authorization can not be done automatically, even though the endpoint information were available.
Mikael Rinnetmäki (Jul 10 2018 at 13:30):
I understand I need to go through the client registration process to get the client ID. The requirement is not to be able to do that automagically, although that would be awesome too.
The requirement is to reduce environment specific implementation in the application, both in the code and configuration. And to reduce the need for manual maintenance work.
I have a FHIR application that gets its client ID and potential client secret from a configuration file. However, in an attempt to be as dynamic as possible, it fetches and stores all other information dynamically, based on the iss parameter from the SMART on FHIR launch sequence. So that there is minimal need to update the configuration manually, even when the FHIR server the application uses decides to change a URL, for instance. In this case, the application notices that the previously fetched configuration is no longer valid, and fetches the new configuration (mainly auth and token urls) again, and uses those.
This is very nice and works with all other FHIR servers. However, I need to change this dynamic application logic in order to support the Finnish PHR, and only for that single FHIR server rely on static configuration or hard-coded URLs. That's not nice.
Juha Paasolainen (Aug 08 2018 at 09:53):
Thank you for the feedback. We will consider this when planning the Kanta PHR road map.
Last updated: Apr 12 2022 at 19:14 UTC
