Stream: smart
Topic: does the launch/encounter scope limit data access?
Isaac Vetter (Jun 08 2020 at 13:42):
For a standalone launch, does the launch/encounter SMART scope limit the data that the resulting access_token can access to only information relevant to that encounter, or does it merely request the AS to return an encounter id alongside the access_token?
Josh Mandel (Jun 08 2020 at 13:56):
It just provides an encounter. Limitations are currently in coded in the resource level Scopes (either bound to a patient or bound to a user). The ability to share information about specific encounters could certainly be a useful practical way to impose limits -- we should take this up in are granular access discussion call this week.
Isaac Vetter (Jun 08 2020 at 14:37):
Josh, would you give the same answer regarding provider-facing, standalone launches and the launch/patient scope?
Josh Mandel (Jun 08 2020 at 14:41):
Yes -- like if a provider facing app asked launch/patient user/*.read" that'd be a request for access to all records available for the provider, and a single patient as context.
Isaac Vetter (Jun 08 2020 at 14:46):
@Jenni Syed - do you agree with this:
if a [standalone] provider-facing app asked for:
launch/patientuser/Patient.readthat'd be a request for access to all [patient] records available for the provider
?
Grahame Grieve (Jun 08 2020 at 18:46):
this is one of the things I would like to see clarified in the specification
John Moehrke (Jun 08 2020 at 19:17):
This means that there is a clear boundary between the start context, and the security token. That the start context is simply a start context, not a security mechanism, not a mechanism that limits the app.... except for the fact that patient scope is using the patient identified in the start context. right?
Jenni Syed (Jun 08 2020 at 19:17):
Yes, and we support that today @Isaac Vetter, though we don't generally see that combination in practice (using a launch type that requests patient in combination with user scopes) EXCEPT where patient scope doesn't apply (eg: user/Practitioner.read)
Jenni Syed (Jun 08 2020 at 19:18):
When apps at a "chart" level launch from our EHR go though functional validation, we generally catch and recommend they don't cross patients when in the context of a single chart for clinical data... very problematic.
Jenni Syed (Jun 08 2020 at 19:19):
@John Moehrke the start context and scopes interplay specifically only at the patient level because of the definition of the patient/... scopes
Jenni Syed (Jun 08 2020 at 19:19):
but we see many confused about the encounter not doing this :)
Jenni Syed (Jun 08 2020 at 19:19):
(I don't think encounter should, but it does surprise some)
John Moehrke (Jun 08 2020 at 19:31):
I think that is why people presume encounter acts similarly. I recommend we adjust this in future releases of smart. I would far prefer the patient identity be added to the security token/scope rather than this loose coupling between the start context in a single case.
Jenni Syed (Jun 08 2020 at 19:33):
@John Moehrke what are you wanting to change in the future release of smart? Today, the patient identity does get associated when you request it to, but would only apply in places the app requests it today.
Last updated: Apr 12 2022 at 19:14 UTC
