FHIR Chat · should a launch fail if `launch/encounter` can't be met?

Stream: smart

Topic: should a launch fail if `launch/encounter` can't be met?

Isaac Vetter (Sep 22 2020 at 22:19):

For example, if a user declines to select an encounter during the authorization process, should the AS return an error to the app's redirect_uri? Or rather, should the AS treat the authorization as successful and return an access token without an encounter value?

Robert Scanlon (Sep 23 2020 at 13:31):

I don't know what the correct answer here is, but I was wondering if there is precedent in OpenID Connect if the user authorizes some things but not authentication information (the openid scope). Consider the whole authorization request as an error or just don't return id_token? It seems like a similar situation.

Josh Mandel (Sep 23 2020 at 13:56):

Specifically for encounter: I think it makes sense to proceed, since none of our authorization logic is tied to the encounter. In other words, proceeding without selecting an encounter will not result in broader. So it seems reasonable to complete the process and allow the app to work with what it's got. (Note that for the patient launch context parameter, the situation could be different -- if the app is requesting patient/ scopes, then it does not make sense to complete the launch if no patient context has been established.)

Josh Mandel (Sep 23 2020 at 13:59):

The general principle here is to think about scopes as independent and allow a launch to succeed or fail on with any approved subset -- but we have a couple of places like {launch/patient context scope :: patient/Whatever.read access scope} where the logical dependency prevents these things from being approved totally independently.

Jenni Syed (Sep 23 2020 at 14:46):

I think we clarified this a bit on the recent PR into SMART... was going to look at the laanguage again

Jenni Syed (Sep 23 2020 at 14:47):

sometimes "launch/encounter" is a "hint" and I would definitely not expect that to fail (during "launch from EHR")

Jenni Syed (Sep 23 2020 at 14:49):

language @Isaac Vetter and let me know if we want to clarify more: "The application could choose to also provide launch/patient and/or launch/encounter as "hints" regarding which contexts the app would like the EHR to gather. The EHR MAY ignore these hints (for example, if the user is in a workflow where these contexts do not exist).

If an application requests a clinical scope which is restricted to a single patient (e.g. patient/*.read), and the authorization results in the EHR is granting that scope, the EHR SHALL establish a patient in context. The EHR MAY refuse authorization requests including patient/ that do not also include a valid launch, or it MAY infer the launch/patient scope."

Jenni Syed (Sep 23 2020 at 14:49):

I can infer what Josh recommended above from that text, but it doesn't flat out say it :)

Josh Mandel (Sep 23 2020 at 17:13):

If you think what I wrote above provides additional clarity and is consistent with the current language, then it might be worth adding to our spec some excerpts from my post above. (I'm not sure if I'm in a good position to judge ;-))