Stream: smart
Topic: selecting a patient
David Hay (Mar 10 2016 at 23:14):
The SMART documentation defines the launch/patient scope as "When launching outside the EHR, ask for a patient to be selected at launch time". Assuming the Authz server approves, is it the responsibility of the EHR to provide the patient selection, or can the client application make FHIR based Patient queries? (Or, is this implementation specific?)
Josh Mandel (Mar 10 2016 at 23:15):
This scope, launch/patient, is the way for an app to say, "OK, EHR, I want you to handle patient selection for me".
Josh Mandel (Mar 10 2016 at 23:15):
If the app wants to handle patient selection itself, it shouldn't ask for launch/patient, and it should ask for user/Patient.read (at least).
David Hay (Mar 10 2016 at 23:21):
thanks! (Have added it to the documentation sample for the next person!)
Josh Mandel (Mar 10 2016 at 23:23):
Just saw and commented on https://github.com/smart-on-fhir/smart-on-fhir.github.io/pull/114
Josh Mandel (Mar 10 2016 at 23:24):
I think this point is a good one, but we need to figure out where it lives. Maybe it's in tutorial, rather than the scope definitions page. Or maybe it's in a side note, or explanatory comment. Hmm.
Josh Mandel (Mar 10 2016 at 23:25):
Oh, I take it back. You put it in exactly the right place.
Josh Mandel (Mar 10 2016 at 23:25):
Merged. Thanks @David Hay
David Hay (Mar 10 2016 at 23:57):
suppose I have an EHR launched app (with a patient in context), with a scope of user/Patient.read Does this mean I'm asking to be able to select any patient - not just the one in scope? and perhaps patient/*.read and patient/*.write, requesting to do anything with those patients (that the user is allowed to do - subject to any other EHR policies of course)?
Grahame Grieve (Mar 10 2016 at 23:58):
yes you're asking that. You might not be granted that - it depends on the model. Some servers or users may only grant you rights to the see the patient in scope, and others may grant you the right to see other patients.
Heath Frankel (Mar 11 2016 at 00:05):
On http://docs.smarthealthit.org/authorization/ the launch parameter is defined as "Opaque identifier for this specific launch, and any EHR context associated with it". How does this EHR context get associated with the launch id?
David Hay (Mar 11 2016 at 00:10):
afaik that's up to the implementation. It needs to store it somewhere so it can be found post successful authentication...
Grahame Grieve (Mar 11 2016 at 00:13):
Heath - the thing launching provides the parameter, and then it gets it back in the end
Heath Frankel (Mar 11 2016 at 00:13):
So the example access token response in section "SMART authorization sequence" that returns the patient ID is an example when the authorisation server has requested the patient ID as part of the "Authorize App" step?
Grahame Grieve (Mar 11 2016 at 00:14):
a more useful question is how the client determines what it's context is
David Hay (Mar 11 2016 at 00:19):
I read that to mean that if the app is launched from the EHR, and a patient is in context, THEN the 'patient' property is in the access token with the patient id as the value...
Grahame Grieve (Mar 11 2016 at 00:20):
yes but the auth token is opaque to the client
David Hay (Mar 11 2016 at 00:30):
sorry - I should have said 'access token' (not the auth code)
(this stuff hurts your head)
Heath Frankel (Mar 11 2016 at 00:51):
My confusion is how the auth server knows the app's select patient?
Grahame Grieve (Mar 11 2016 at 00:51):
for which workflow are you asking?
Heath Frankel (Mar 11 2016 at 00:58):
As I said, in the example access token response in section "SMART authorization sequence" that returns the patient ID. How did the Auth svr know about which patient is being launched?
David Hay (Mar 11 2016 at 00:59):
If it's an EHR launch the Auth server is part of the EHR and there's a 'back channel' communication I guess
Grahame Grieve (Mar 11 2016 at 01:00):
well, in the EHR initiated workflow, the EHR and the Auth server have a private agreement about how that's communicated, yes
Heath Frankel (Mar 11 2016 at 01:00):
OK, so the EHR registers some launch context against the launch ID and the Auth Svr retrieves this from the EHR?
Grahame Grieve (Mar 11 2016 at 01:00):
or they might be the same
David Hay (Mar 11 2016 at 01:03):
I was imagining that when the user clicks the 'go for it' link in the EHR, then the EHR saves the context where the Authz server can find it, indexed with an opaque key (the launch token) which is sent to the client. The Authz server picks it up from the same location using the same launch token...
David Hay (Mar 11 2016 at 01:04):
Here's what I wrote:
To support the ‘EHR launch’ (ie from within portal), there needs to be some way that the authorize endpoint knows the context of the caller. In the spec, this involves a token (the launch parameter) that acts as a key to this data. This implies that it is set when the app is loaded, so that it can retrieved by the authorize end point. So the starting sequence (after the user clicks the button will be something like:
• Save the current context (user and optionally patient) in some key/value store that is also accessible by the Authentication server. Need a strong key and likely a TTL.
• Include the value of the key as the launch parameter in the call to the client application.
David Hay (Mar 11 2016 at 01:04):
hopefully it's correct!
Heath Frankel (Mar 11 2016 at 01:07):
For me this is a big piece of the puzzle missing from this Guide
Heath Frankel (Mar 11 2016 at 01:07):
The above text would help assuming this is what is intended
David Hay (Mar 11 2016 at 01:08):
I'm actually writing a post as we speak - 'cause I had the same issues!
David Hay (Mar 11 2016 at 01:08):
and that way, if I get it wrong, then the community can correct me...
Heath Frankel (Mar 11 2016 at 01:08):
I would suggest we want to go one step further and actually define what this would look like when the EHR and Auth Svr are different
Heath Frankel (Mar 11 2016 at 01:10):
OAuth 1.0 has an Initialise interaction which I have used for this in one of my implementations
Grahame Grieve (Mar 11 2016 at 01:10):
Heath - for now. it's a private agreement. the UMA/Heart project want to standardlise this - we met with them last week - but that's way more complex than it sounds, so SMART is leaving that for the future
Heath Frankel (Mar 11 2016 at 01:12):
I can understand that, but I think we would want to get there at some stage so that we don't have too many variations of this.
Josh Mandel (Mar 11 2016 at 02:44):
To say it briefly: SMART's authorization spec aims to standardize the way an EHR talks to apps. We're not trying to standardize the way the internal EHR components (resource server, authz server) talk to each other.
Josh Mandel (Mar 11 2016 at 02:46):
There are, however, some common patterns for how your EHR's resource server and authz server might communicate context.
1. The "launch id" can actually contain the state (as long as it's encrypted for confidentiality and signed for integrity. For example the EHR can create a JWT that's created for the authz server to read, encoding the relevant context parameters.
2. The "launch id" can be a URL or parameter that the authz server uses to look up the context via an internal API .
3. The authz server might be the same thing as the resource server.
Heath Frankel (Mar 11 2016 at 03:31):
I think these patterns would be useful to include in the guide
Heath Frankel (Mar 11 2016 at 03:31):
otherwise it leave people wondering...
Grahame Grieve (Mar 11 2016 at 04:17):
could help, yes
Josh Mandel (Mar 11 2016 at 04:30):
Could go in our "be at practices for EHRs" page - would that be helpful? Somewhere else you'd expect to see it?
Heath Frankel (Mar 11 2016 at 04:34):
Not sure why you wouldn't have something in the Authorisation Guide page, but perhaps it is just a reference and link to more details in the Backend service page?
Josh Mandel (Mar 11 2016 at 05:10):
It's not about "backend services" for sure, since those have no launch id or context.
Josh Mandel (Mar 11 2016 at 05:12):
As for the authorization guide, I don't think this kind of list of patterns is a good fit, since it's not part of the authorization protocol we specify. We do have a server tutorial where it could fit. Or those best practices...
Heath Frankel (Mar 11 2016 at 06:15):
OK, I see now that the backend services is a different profile for a different use case.
John Moehrke (Mar 11 2016 at 18:00):
Im with Josh that this backend magic should need to be exposed to the app writer... except that it does need to be informatively explained so that they have confidence. This is what we did in IHE-IUA, and even there it wasn't yet well enough explained. I do like the KISS focus.
Last updated: Apr 12 2022 at 19:14 UTC
