Stream: smart
Topic: Standalone launch/patient behavior
Dan Cinnamon (Nov 16 2020 at 19:25):
Hello everyone- I was wondering, from an implementation/best practices perspective- in a standalone launch flow, if there is an opinion on how an authorization server should decide how to obtain the in-scope patient id?
What i mean is whether or not the authz server should show a patient selection widget, or attempt to derive the patient id from the user's profile.
Currently the approach I've taken is- if only launch/patient is requested, then my authz server will assume that user==patient, and will attempt to derive the in-scope patient id based upon a lookup.
I've then added an additional scope called "patient_selection", that, if requested alongside launch/patient, it will cause the authz server to NOT assume that user==patient, and instead will present a patient selection widget that will allow the user to choose/consent among authorized patient records.
I can see in a provider app you'd basically always want to show a patient selection, but in a patient application i can see it going either way, and want to streamline the process by hinting at authz time whether i need a patient selection or not.
Is there a typical behavior that I should implement instead? Looks like the section on "intent" appears to be heading this direction, but wasn't sure. Thanks!
Michele Mottini (Nov 16 2020 at 19:38):
From then standard point of view the server can select the patient whichever way it prefers, so assuming user=patient and returning that is fine, but standard clients won't know about patient_selection, they will just use launch/patient, and so they would never be able to get data for other patients that the user might have access to - that's the reason why most (all?) implementation have a patient selector for that case.
Dan Cinnamon (Nov 16 2020 at 21:52):
Thank you Michele- and I did leave out the details on decisions that can easily be made just by looking at whether or not the user actually has access to >1 patient. So in reading your response I think I can simply look to the access data first, and display the picker in the scenario where patients >1 and hide if patients == 1.
I could see a potential for wanting something on top of that to streamline the authz process in the case where the user may have access to multiple patients, but is only interested in "their" record- but if that's not a common thing I can back off of it and cross that bridge down the road if there's demand. Thanks again!
Last updated: Apr 12 2022 at 19:14 UTC
