Stream: smart
Topic: launch context for standalone
Sagar Shah (Sep 21 2020 at 14:24):
I am reading through the links related to smart on fhir for ehr and standalone sequences.
https://hl7.org/fhir/smart-app-launch/index.html and https://hl7.org/fhir/smart-app-launch/scopes-and-launch-context/index.html
I am more or less on clear on EHR sequence, where patient or encounter value is returned as well by token endpoint from Auth server depending on launch.
Can anyone clarify, what's the expected behavior for stadnalone launch (when launch parameter is not passed by the app to auth server)? What does auth server need to return in the response for launch context?
Robert Scanlon (Sep 21 2020 at 15:18):
In the standalone case, the app may request a patient or encounter context by requesting the "launch/patient" or "launch/encounter" scope. The authorization server then needs to establish a context (identify a patient id or encounter id to send back to the client, if authorized). If the user of the app has access to multiple patients and the app has requested a patient context, then the authorization server can present a 'patient picker' to the user prior to redirecting back to the app in this case. Then the patient/encounter value gets returned during token exchange in the same way as the EHR launch. Does that help?
Sagar Shah (Sep 21 2020 at 15:30):
Robert Scanlon said:
In the standalone case, the app may request a patient or encounter context by requesting the "launch/patient" or "launch/encounter" scope. The authorization server then needs to establish a context (identify a patient id or encounter id to send back to the client, if authorized). If the user of the app has access to multiple patients and the app has requested a patient context, then the authorization server can present a 'patient picker' to the user prior to redirecting back to the app in this case. Does that help?
Thank for clarifying!
It does help in a way, but triggered some additional questions. :-)
- 'patient picker' - Can you elaborate what does patient picker mean here? How does auth server return patient picker in the token response? Or is it some sort of a redirect to 3rd party app url?
Also, how does it work, if the end user of app is a patient or representative? Or is this SMART on FHIR requirement applicable only to provider facing apps?
Also do we need patient picker flow when an authorized representative logs in 3rd party app so that he can choose one patient from many that he/she may be representative for?
Robert Scanlon (Sep 21 2020 at 15:45):
Sorry for the lack of clarity. The 'patient picker' is generally a term for a UI element presented to the user in the 'Authorize App' step that lets the user pick which patient is in context for this app. It isn't something that alters the flow at all. And it isn't necessarily a requirement. Just in practice, if a standalone app asks for a single patient id to work with, and the user of that app has access to multiple patients, the authorization server needs to figure out somehow what patient the user wants.
Sagar Shah (Sep 21 2020 at 16:15):
Robert Scanlon said:
Sorry for the lack of clarity. The 'patient picker' is generally a term for a UI element presented to the user in the 'Authorize App' step that lets the user pick which patient is in context for this app. It isn't something that alters the flow at all. And it isn't necessarily a requirement. Just in practice, if a standalone app asks for a single patient id to work with, and the user of that app has access to multiple patients, the authorization server needs to figure out somehow what patient the user wants.
Thanks for making it more clear. It makes sense now. so taking it further :), depending upon the requested scope (by 3rd party app)
- launch/patient - oauth server offers patient picker UI so as to enable patient selection
- launch/encounter - should oauth server offer encounter picker UI so as to enable encounter selection? Does it require patient selection to happen first before encounter selection?
Also referring to your statement - "Just in practice, if a standalone app asks for a single patient id to work with...."
App by itself cannot request the patient id without showing patient picker UI component, correct? Basically how would standalone app flow asks for single patient id on the user login (as it cannot pass launch parameter, correct)?
Appreciate your suggestions!
Robert Scanlon (Sep 21 2020 at 16:45):
For your launch/encounter question - I would think for standalone apps you would need to have some kind of 'encounter picker' if you were to support the context-standalone-encounter capability. But the guide doesn't require it. It is up to the server to figure out the best way given its situation & users to associate an authorization request with an encounter (same with patient). And similarly, there are no requirements around what that picker might look like (if for encounters you need to choose a patient first, etc).
Robert Scanlon (Sep 21 2020 at 17:12):
App by itself cannot request the patient id without showing patient picker UI component, correct? Basically how would standalone app flow asks for single patient id on the user login (as it cannot pass launch parameter, correct)?
Do you mean, how can an app ask an authorization server to be authorized very specifically for a context of 'patientid=12'? If so, that's outside of the standard. The way it works is the app simply states that it needs a patient context (by requesting the launch/patient scope), and the authorization server interacts directly with the user to work that out (in the Authorize App box), and then the app is given a patient id in the token exchange step. In this case, with 'context', it is the authorization server showing the user the patient picker, not the app.
Sagar Shah (Sep 21 2020 at 17:17):
Thanks a lot for making it more clear. I think I got the correct understanding of flow.
Appreciate your inputs on this. Just a question, that you mentioned encounter selector and patient selector both are not mandatory as per guide? If that's not implemented by OAuth server, then auth server just returns with standard token response without patient context (for ehr launch) or the patient picker (for standalone app)?
Robert Scanlon (Sep 21 2020 at 17:27):
For EHR launch, if the app expects patient context, it should be launched while the user is looking at a patient record in the EHR (for example). And that info is associated with the launch parameter so the authorization server knows what patient is in context, and therefore no picker is needed. If the EHR somehow launches the app without a patient in context, but the app needs a patient in context, I'd think that is a config error.
Robert Scanlon (Sep 21 2020 at 17:43):
Regarding the existence of a 'picker' -- that is just one mechanism that an authorization server could use to take a request for a patient/encounter context and resolve a specific patient/encounter to it can pass that back to the client during token exchange. In the EHR launch, the authorization server figures it out simply by that 'launch' parameter. In the standalone case, as an example, if your system only ever deals with users that are patients without access to any other patient data, the authorization server probably can infer the patient context automatically without showing the user a patient picker. So SMART doesn't say "make a patient picker", because then you may end up situations where implementers create a patient picker where one isn't needed.
Robert Scanlon (Sep 21 2020 at 17:47):
It just says, if an app requests the launch/patient scope, then you will want to pass a patient id back to the client at the end of the process. Figure out how to choose which patient id yourself.
Robert Scanlon (Sep 21 2020 at 17:49):
(this is all somewhat informally described, obviously see the standard for the formalisms :)
Sagar Shah (Sep 21 2020 at 17:49):
Thanks for getting it very clear now. So objective is to get patient id in the access token response at minimum from Auth server. Encounter is optional though.
Robert Scanlon (Sep 21 2020 at 17:52):
I just used 'launch/patient' as a shortcut to 'launch/patient and launch/encounter' -- it is the same concept. If 'launch/patient' requested by standalone app, the goal is to get a patient id back to the app (that user authorized the app to use). if launch/encounter requested by standalone app, the goal is to get a encounter id back to the app (that user authorized the app to use).
Sagar Shah (Sep 21 2020 at 17:55):
Robert Scanlon said:
I just used 'launch/patient' as a shortcut to 'launch/patient and launch/encounter' -- it is the same concept. If 'launch/patient' requested by standalone app, the goal is to get a patient id back to the app (that user authorized the app to use). if launch/encounter requested by standalone app, the goal is to get a encounter id back to the app (that user authorized the app to use).
Understood. so launch/patient and launch/encounter both needs to be supported from Auth server for SMART at minimum
Robert Scanlon (Sep 21 2020 at 17:59):
Well, yes, if you wanted to support all of SMART App Launch 'capabilities'. But you don't have to support all capabilities from the SMART App Launch Guide perspective. See http://hl7.org/fhir/smart-app-launch/conformance/index.html#launch-context-for-standalone-launch
Robert Scanlon (Sep 21 2020 at 18:03):
Depending on the context of your application, you may have requirements to support a certain subset of the capabilities, or perhaps all of them.
Sagar Shah (Sep 21 2020 at 18:12):
Thanks a bunch for your inputs!
Last updated: Apr 12 2022 at 19:14 UTC
