EHR Launch where brokered identity is involved

[Raymond]

Hi 

I'm trying to understand the EHR Launch and launch context pattern better.

As I understand it the EHR system is responsible for generating the launch code and I presume the EHR also needs to be the authorisation server as its the only one that will understand the launch context.

What happens in the situation when the FHIR authorisation server is not the EHR system? i.e. the FHIR resources are independent of the launching EHR.

I've yet to find any apis or protocols that allow a launch context to be returned by an authorisation server. Not, I need to reuse the patient already selected within the EHR not pick again (like in standalone launch flow).

Our situation.
We have Keycloak which identity brokers to a regional IDP provider. That provider is the IDP for the FHIR servers in the region.

EHR systems want to launch our viewer application. Our presents data from the FHIR servers. 

Am I correct in assuming the launch context (opaque) code comes from the EHR, and I really need to get the Smart on FHIR access token from EHR otherwise I won't get the patient id. The independent IDP won't understand or know the launch context. Or is there away to pass that to the authorisation server?

In principle I need the access token from the regional IDP to access FHIR resources, not an access token issued from the EHR.

Appreciate the above is a complex flow. Is it something Smart on FHIR is meant to handle? Seems not.

Any pointers, clarifications, or suggestions appreciated.

Regards
Raymond

[Jason Salsiccia]

Hi Raymond,

In an EHR launch, the launch parameter is a representation of what the user is currently accessing in the EHR (e.g. what patient they are looking at).   If the FHIR authorization server is not part of the EHR, how could it possibly have this information?  It has to come from the EHR.

While the spec instructs app developers to treat the launch parameter as opaque, that doesn't necessarily mean it can't contain information that's meant to be understood and interpreted by an external FHIR authorization server.   For this to work, the EHR and the external FHIR authorization server/FHIR API (they are of course directly linked) must at least contain patient resources that have a shared identifier both systems understand. 

It should be possible, but it's certainly impossible for an external authorization server to provide you launch context, because it does not have that information.  The authorization server is showing you the patient selector in an attempt to get the patient context you requested in the launch.

- jason

[Raymond]

Thank you Jason, I did wonder how rigid the opaque requirement was. 

"that doesn't necessarily mean it can't contain information that's meant to be understood and interpreted by an external FHIR authorization server" - although this now means that the FHIR authorization server (which currently is just a OIDC provider) needs to generate a proper Smart on FHIR token rather than just a plain Oauth one, i.e. with the patient context claims. But thats a separate issue.

I do feel my use case is not what Smart on FHIR intended. i.e. authorising to other non EHR FHIR resources. Its a separate SSO, chain of trust problem. 

Something like:
User -> EHR -> launch viewer -> Viewer trusts EHR -> exchange trust with external IDP, or login again to external (not the desired) -> call external FHIR resources 

where EHR launch seems to be  limited to following:
User-> EHR -> launch viewer -> trust EHR user -> call EHR FHIR resources or internal resources app only.

Regards
Raymond

[Jason Salsiccia]

If the FHIR authorization server is just an OIDC provider, then it's not actually a FHIR Authorization server.   If the EHR is using it in this way, then it's configured incorrectly.   An OIDC provider only provides identity.  It cannot interpret or resolve the FHIR scopes your application is asking for.

Side-stepping the issue of why an EHR would allow you to launch an app like this, it seems possible.   The user in the scenario would have "an account" with this external FHIR API, and really what your app is asking in such a launch is for the user to permit you to access the external FHIR API on their behalf.   The EHR is just providing you a "window" to display your app UI in.

- jason

[Raymond Sellars]

Yes, that Side-stepping scenario.

The EHR is actually decoupled from the FHIR resources. I’m trying to figure out how Smart on FHIR overlays and I don’t think it does. That side-step flow is more accurate.

EHR user, has an account in the OIDC/Oauth provider, but authentications locally within the EHR from which they want to launch the viewer.
The FHIR resources trust Oauth tokens from the OIDC provider only. Hence why I may have incorrectly labelled it the FHIR authorisation server.
I don’t believe Smart on FHIR address the gap in the chain. – “launch is for the user to permit you to access the external FHIR API on their behalf” that is the bridge needed. Which I conclude is a different flow.

Thanks
Raymond

--
You received this message because you are subscribed to a topic in the Google Groups "SMART on FHIR" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/smart-on-fhir/Wqmre2UWNiY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to smart-on-fhi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/smart-on-fhir/773c8909-2698-4446-8a1d-258d32853a23n%40googlegroups.com.

This email (including attachments), may contain information which is confidential or subject to copyright. If you are not the intended recipient, please notify us immediately and then delete this email from your system.