Stream: smart
Topic: Volume of Smart Scopes
Richard Braman (FLY.HEALTH) (Apr 21 2021 at 00:21):
Hi All, I do extensive development for real world APIs and I have repeatedly seen problems with various major vendors products (who shall rename nameless) when it comes to the volume of scopes required by Smart on FHIR for an API. Take a Patient Access API for example which supports CARIN and USCore (read only) Such an API requires around 58 scopes just to support .read operations on the required resources. I have seen oAuth servers limited to 30 scopes, I have seen refresh token minters fail on creating tokens with too many scopes, and I have seen proxy servers that need to have buffers increased to handle the amount of data that needs to go back and forth to support Smart on FHIR. Yes, I realize that there are wildcard scopes, but with those fine grained access control is lost. One question I have is around the need to have patient and user scopes. Interestingly, Inferno only tests patient/<Resource>.read and does not include user/<Resource.read> scopes in its default tests. Any ideas on how we could trim down the number of scopes? Are patient and user scopes redundant? The spec is clear on how patient and user scope differ in theory but how do they differ in practice? How are vendors dealing with two differently when evaluating scopes in their APIs?
Robert Scanlon (Apr 21 2021 at 01:14):
Are these oAuth servers limited to 30 scopes total, or 30 for a single authorization request? For a single request, I'm not aware of any good reason why you would need to be granted both patient & user level scopes for a single resource at the same time (e.g. "patient/Observation.read user/Observation.read"). But if real-world oAuth servers can only be configured with 30 scopes total, that's a different problem.
Richard Braman (FLY.HEALTH) (Apr 21 2021 at 01:17):
One server major vendor's server is in fact limited to 30 scopes total.
Robert Scanlon (Apr 21 2021 at 01:44):
Interestingly, Inferno only tests patient/<Resource>.read and does not include user/<Resource.read> scopes in its default tests.
This is beside the point (I think) and I don't want to sidetrack the topic, but the ONC standardized API certification tests in Inferno require demonstrating an app launched with patient scopes for all USCDI-relevant resources¹, and separately an app launched with user scopes. So you need to show both. Our 'Community' tests are more flexible, and it is more up to the tester to decide to try user scopes and patient scopes, if they expect the server to support both permission-patient and permission-user SMART capabilities.
¹ (technically also constrained to resources that are also in the patient compartment, soon!)
Richard Braman (FLY.HEALTH) (Apr 21 2021 at 02:34):
Robert, Can you tell me from an implementation perspective how a FHIR server handles patient scopes differently from user scopes? The spec is clear on the difference in theory, but not so much in practice, as in, how SHOULD they be used by the server to control access to resource?
Josh Mandel (Apr 21 2021 at 02:36):
patient-level scopes give you access to a single patient's data; user-level scopes can give access to more than one patient's data. Is this what you mean?
Richard Braman (FLY.HEALTH) (Apr 21 2021 at 02:49):
The patient scopes are straightforward. The user scopes not so much (to me at least). You are saying to view data for another patient, the app must request, and the user must approve user scopes, Correct?. How does the app know which patients it has access to? I was always under the assumption that the user session had a single patient context. Is that incorrect? Every token response I have ever seen only had a single patient, and the patient context in the documentation is not an array. In our smart on fhir flow, which allows the patient to approve scopes, the user is asked which data the user will grant access to. It also asks which patient the user would like to view. But only a single patient context is returned. I have attached a screenshot to make it clearer. patient_consent.png
Richard Braman (FLY.HEALTH) (Apr 21 2021 at 02:50):
Sorry but Amberly and Jann had bad hair days
Paul Church (Apr 21 2021 at 02:59):
User scopes assume that the server has some permissions model where a user identity (the usual example is a practitioner) has access to one or more patients for reasons that are not contained in the scope. This is normal for EHRs. It doesn't make a lot of sense for pure FHIR servers. It seems that in patient access use cases most implementers are going with a patient selection UI in the auth flow (e.g. for multiple family members) and granting a patient scope rather than teaching the fhir server all of those linkages necessary to make a user scope possible.
Josh Mandel (Apr 21 2021 at 03:01):
does the app know which patients it has access to?
The app can search for data, and it gets what it gets. e.g. GET /Patient.
Robert Scanlon (Apr 21 2021 at 03:05):
Unfortunately, GET /Patient is not required in US Core. Does anyone implement that?
Josh Mandel (Apr 21 2021 at 03:12):
You can pass in search parameters (for a clinician facing app, to search a population by name); this has been implemented by EHRs I believe.
Robert Scanlon (Apr 21 2021 at 03:16):
True -- search by name, and a few other options are required in US Core.
Michele Mottini (Apr 21 2021 at 13:06):
Does anyone implement that
Yes, we support it, I believe Cerner does: you need that if you want to support user scopes for patient apps to get all dependents in one go
Michele Mottini (Apr 21 2021 at 13:08):
There are going to be even more scopes in SMART v. 2!
Robert Scanlon (Apr 21 2021 at 13:13):
Yeah its a bit of a shame that the full /Patient query (bounded by user permission, of course) isn't required by us core, so there would be confidence for app builders that design the user experience around the availability of that query.
Robert Scanlon (Apr 21 2021 at 13:15):
But mandating that in all cases might be problematic
Michele Mottini (Apr 21 2021 at 14:59):
Yes, for providers app it would be pretty bad
Richard Braman (FLY.HEALTH) (Apr 21 2021 at 15:55):
Maybe they should just add Patient/$everything to USCore
Richard Braman (FLY.HEALTH) (Apr 21 2021 at 15:58):
is the patient context value capable of supporting more than one value? Can it be an array?
Josh Mandel (Apr 21 2021 at 16:01):
It is defined as the patient in context for the session; it's not designed to convey "patients you have access to". But I could see the utility of this (or a releated property). Would be worth sharing a comment in the SMARTv2 ballot (or just a regular Jira comment, and mention it here) for folks interested.
Last updated: Apr 12 2022 at 19:14 UTC
