Stream: bulk data
Topic: Backend Services
Grahame Grieve (Jan 26 2018 at 20:29):
Based on feedback that I have had about this, we very definitely need a very clear statement about why back-ends services authentication is recommended rather than Mutual TLS.
Grahame Grieve (Jan 26 2018 at 20:30):
also, we need to explain how the client can pass an openid token to identify the end-user (if one is known / relevant) as part of using backend services
Josh Mandel (Jan 26 2018 at 20:48):
Agreed that it's useful to define a way to pass in information about user identity.
Josh Mandel (Jan 26 2018 at 20:49):
re: mutual TLS, these aren't exclusive; no reason you can't also do mutual TLS, but the goal here is an application-level protocol so we can work with richer claims (like user identity, target scopes, etc) directly, rather than just knowing a client's identity.
Grahame Grieve (Jan 26 2018 at 20:54):
I understand the value proposition - but it needs to be stated clearly, because everyone asks this question
Grahame Grieve (Jan 26 2018 at 20:54):
and 'rather than' was meant in terms of 'why define this rather than just say use mutual tls'. I agree that you can use both - and it's worth being clear about that as well
Grahame Grieve (Jan 27 2018 at 14:32):
I have rescinded the requirement that authentication is required before client registration for at least this weekend. You can hit the registration end point directly at http://test.fhir.org/auth/register
Phil Langthorne (Jan 28 2018 at 18:20):
For anyone working on implementing the Backend Services auth protocol, I pushed a client to https://github.com/plangthorne/python-fhir - example API usage is here: https://github.com/plangthorne/python-fhir/blob/master/demo/BulkDataDemo.ipynb
Note the client will fail if your server implementation does not yet support auth. I hope this is useful! =)
Amogh Thali (Feb 27 2020 at 16:46):
I am in the process of integrating with Epic as a backend service to get in the bulk of patient demographic data for my app to register those patients. My app will run independently on a separate platform ( web/mobile ) and not the iframe in the Epic's EHR. I find this (https://open.epic.com/Home/DeveloperTerms) documentation a bit confusing. Is this what I would have to adhere to irrespective if it is a standalone app (mobile or web) just to use the backend service ? After reading this (http://www.hl7.org/fhir/smart-app-launch/), it shows that my app is a SMART app and would have to follow all the TnC's necessary for a SMART app launch on the EPIC platform but if someone would conform this, it will be helpful.
Also, do we have any non SMART apps that would use FHIR and integrate with EPIC?
Lloyd McKenzie (Feb 27 2020 at 16:49):
@Danielle Friend
Danielle Friend (Feb 28 2020 at 15:57):
Hi @Amogh Thali those are some good questions. We do support EHR and standalone SMART on FHIR launches. However, the open.epic.com sandbox and developer terms are centered around patient facing access which doesn't sound like the use case you're describing. I just sent you an pm so we can chat more indepth about what it is you're looking for/want to do for this use case.
Last updated: Apr 12 2022 at 19:14 UTC
