Stream: smart
Topic: scopes
Kevin Shekleton (Mar 21 2016 at 22:00):
What does a scope of patient/Practitioner.* mean to everyone?
It would seem that there are a certain set of nonsensical patient-level scopes. Currently, SMART's clinical scopes must start with patient/ or user/. However, whether you can use patient/ (and perhaps user/) depends upon the FHIR resource
Kevin Shekleton (Mar 21 2016 at 22:03):
A related question: imagine a provider-facing SMART app that wants to provide the ability to read + write the authenticated provider's Practitioner record.
The app would request a scope of user/Practitioner.* to be granted the proper permissions. However, based upon the current SMART documentation, the app would get permissions to update *any* Practitioner record. The ideal state for this scenario is that SMART app is granted read/write permission on just the authenticated user's Practitioner record
Kevin Shekleton (Mar 21 2016 at 22:04):
I wonder if rather than patient/ and user/ prefixes, we should be using context/ and all/ (or something like that). context would mean something semantically depending on the FHIR resource (eg, the patient in context, the provider in context, etc).
Kevin Shekleton (Mar 21 2016 at 22:05):
I haven't thought through all of this but wanted to throw this out here to see if others have already thought about this
Josh Mandel (Mar 21 2016 at 22:16):
You're right that it doesn't make sense to request "patient/" scopes on a resource with no "patient" element.
Josh Mandel (Mar 21 2016 at 22:18):
As for user permissions: remember that our goal is not to model the whole system. "user/Practitioner.write" means "allow writing to any practitioner resources that I, as the user, am allowed to edit".
Josh Mandel (Mar 21 2016 at 22:19):
The ehr knows/sets/enforces policy to determine that I can't write to Dr. Jones's practitioner resource (unless I'm an administrator).
Josh Mandel (Mar 21 2016 at 22:20):
This feel like a reasonable balance to me. I'm not sure how much a generic "context" prefixed would improve expectations/understanding/consistency.
Grahame Grieve (Mar 21 2016 at 22:38):
well, it depends how much you care about context other than patient.
Grahame Grieve (Mar 21 2016 at 22:38):
I think there's a lot of uses for Smart on FHIR outside context = patient
Grahame Grieve (Mar 21 2016 at 22:38):
and so I think that Kevin's idea makes a lot of sense
Josh Mandel (Mar 21 2016 at 22:56):
But you'd need to define what it meant, is my point. I'm reluctant to add a generic prefix.
Josh Mandel (Mar 21 2016 at 22:57):
If we can establish uses that systems will support, sure.
Kevin Shekleton (Mar 21 2016 at 23:13):
Good points. I'll ammend my off the cuff thoughts to perhaps we just rename patient/ to context/ then (leave user/ as-is). So, it's not adding a generic prefix so much as changing patient to a word that isn't specific to a particular type of context
Josh Mandel (Mar 21 2016 at 23:29):
But that's just it: you'll want it to behave one way when there context is a patient, and a different way when the context is... something else? I'm saying let's describe "patient" for patient context, and other values when some other context is relevant. That will force us to confront the actual use cases rather than resorting to an underdefined generic value.
Grahame Grieve (Mar 21 2016 at 23:30):
well, ehr plug-ins should be expected in the following contexts:
- observation (/DR)
- medicationX
- care plan
- condition
- allergy
....
Grahame Grieve (Mar 21 2016 at 23:30):
and I expect to use it in the tooling framework with any of the non-patient related resources as context
Josh Mandel (Mar 21 2016 at 23:31):
I'll need to understand the intended use cases / semantics (since they're not obvious to me from you're list).
Josh Mandel (Mar 21 2016 at 23:34):
And when "context" implies multiple values (e.g. a patient and an encounter and a location), a single "context/" scope prefix doesn't make sense.
Grahame Grieve (Mar 21 2016 at 23:35):
well, that's an interesting case, yes. is the context is a particular observation, is access limited to the observation and related information, or to the patient and related information?
Grahame Grieve (Mar 21 2016 at 23:36):
out side of the patient space, there's probably less interest in preventing read, and less need to prevent write based on context
Kevin Shekleton (Mar 21 2016 at 23:43):
Good points, Josh
Kevin Shekleton (Mar 21 2016 at 23:55):
fyi, my questions were prompted by an internal discussion here on whether our authorization server shouldn't disallow scopes that don't make sense (like patient/Practitioner)
Kevin Shekleton (Mar 21 2016 at 23:56):
So, there are not specific/concrete needs or use cases from my end. Our internal discussion just spurred some thought on some what-ifs outside of the current resources we support today
Jonathan Ben-Hamou (Mar 27 2016 at 02:31):
Completely new here ... but looking to contribute. Would it be a correct assessment that the 'patient/' and 'user/' scopes, convey the realm for the authenticated user, and that SMART does not attempt to stipulate how the SMART scopes are mapped to access decisions? Have you seen a need to present different projections of data (e.g. different resource bundles for observations - prelim lab results, provider notes etc) so that only data that's approrpiate for consumption by the user (e.g. patient) is shared?
Jonathan Ben-Hamou (Mar 27 2016 at 02:34):
Also, consider for example delegated access from a young man caring for his elderly mother, leveraging a SMART app. Could this care giver, use an app that requests a 'patient' scope, even if this person is not necessarily a bona-fide patient of that institution, but more for the reason that the 'patient' scope would offer least-privilage access (non-provider)? If this person were a bona-fide patient in addition to caring for a parent who is also a bona-fide patient of the same healthcare organization, could the 'patient/Patient.read' provide contemporaneous access both his record and his parent's record?
Josh Mandel (Mar 27 2016 at 04:37):
The notion is that you ask for "patient/" scopes if you want to access "all of the (somethings) about the relevant patient". And you use "user/" scopes if you want to access "all the (somethings) that the authorizing user has access to to".
Josh Mandel (Mar 27 2016 at 04:38):
So for your caregiver example, the son would be able to grant "patient/*.read" on the mother's record.
Josh Mandel (Mar 27 2016 at 04:39):
The actual policy lives in the EHR; we only standardize how the sharing (delegation) happens.
Jonathan Ben-Hamou (Mar 27 2016 at 05:02):
Thanks for clarifying.
John Moehrke (Mar 27 2016 at 17:25):
There is some efforts outside of smart that are working on using a profile of OAuth called User Managed Access (UMA) to support these kinds of delegation functionality. These are quite bleeding edge, but could be very helpful if they can be shown to be both functional and effective. They are complementary and could plug into a smart infrastructure once they prove trustworthy. See http://openid.bitbucket.org/HEART/openid-heart-uma.html
David Hay (Mar 27 2016 at 19:05):
@Jonathan Ben-Hamou - I did a post on scopes that may be useful...
Josh Mandel (Apr 09 2016 at 03:08):
We've, for a while, been tossing around the notion that scopes like patient/Observation.read are too simple (e.g. you don't really wan to lump all observations together). The problem is that you try to "fix" this you get scopes like:
{"context":"patient","resource":"Observation","category":"laboratory","permissions":["read","create"]}
... which I've generally looked upon with fear. But maybe they're not so bad.
Grahame Grieve (Apr 09 2016 at 21:47):
there's a precipice here for sure. Cross the line, and whee.....
Grahame Grieve (Apr 09 2016 at 21:48):
but if people are going to be forced to cross the lines by themselves....
Grahame Grieve (Apr 09 2016 at 21:48):
but finer grained permissions might not be the right way to manage this?
John Moehrke (Apr 12 2016 at 11:57):
@Josh Mandel we should separate out the permissions needs from the scope needs. scope should focus on logical sub-sets that are likely to need to be segmented based on client needs. Meaning they don't need to be as fine-grain as permissions, but they do need to be powerful enough that one can authorize an app with a sub-set of the users permissions.
John Moehrke (Apr 12 2016 at 11:58):
I did propose a scope model http://healthcaresecprivacy.blogspot.com/2016/01/fhir-oauth-scope.html
Josh Mandel (Apr 12 2016 at 12:12):
@John Moehrke I think I understand that you're proposing different scopes, but your article doesn't mention "permissions". I typically use "scopes" and "permissions" as synonyms; how do you characterize the difference?
Josh Mandel (Apr 12 2016 at 12:14):
Also, you here described a desire for *coarser* grained scopes, but your article proposes much finer grained scopes than SMART uses today (e.g. your proposal includes not just resource but also sensitivity, purpose of use, etc).
Josh Mandel (Apr 12 2016 at 12:15):
For US use cases, it seems to me there would be clear value in defining read and write scopes for things like "medications", "vital signs", "lab results" (i.e. Generally aligned at the level of MU API requirements)
John Moehrke (Apr 12 2016 at 12:28):
The article was written a while ago, we have learned more.. Yes, scopes are generally going to be more coarse than permissions. I use a general term permissions to encompass all the Access Control space inclusive of the Resource types, Patient privacy consents, data tagging, etc.
John Moehrke (Apr 12 2016 at 12:30):
I do like your idea that scopes should likely be a very different vector that is more logical. We are struggling with the similar problem in the Consent work. In Consent we have the problem that a Patient might want to slice and segment their whole medical history to give some subset to one doctor, where this is a different vector than we generally have in the Resource types, or the user roles, or the data sensitivity.
John Moehrke (Apr 12 2016 at 12:32):
My blog yesterday on how to write a Consent that focuses on the Resource types is an example. It might be easy to encode but it is not necessarly useful. (Note it is not really easy to encoded today but that is a different problem).
Alexander Henket (Mar 21 2017 at 10:03):
I've just learned that UMA is a potential candidate for the Dutch national efforts around PHRs.
Alexander Henket (Mar 21 2017 at 10:04):
Anyone know if UMA complements SMART on FHIR, or overlaps it.
John Moehrke (Mar 21 2017 at 11:54):
UMA is a high-level specification, useful for all domains. There is a "HEART" workgroup that is working on how one might use UMA in Healthcare. There are various participants from healthcare. Josh has presented, I have presented, and others. Their work is useful as an alternative way of managing consent, that is the patient has a relationship with a UMA authority to set rules (in proprietary format), all accesses of that patients data is routed (UMA style) through that authority for a decision (Permit/Deny). The group is making progress, but is struggling with not focusing on realistic use-cases, not prioritizing, and not cutting off debate. http://openid.net/wg/heart/
John Moehrke (Mar 21 2017 at 11:54):
We do point at HEART, as well as SMART, and IHE-IUA on the FHIR security pages...
John Moehrke (Mar 21 2017 at 11:58):
The development of Scopes will take some experimentation. The SMART scopes are the best we have today, HEART somewhat followed them. I expect that healthcare data is going to stress the simplistic concept of OAuth scopes. I go into some initial dept, wanted to write more but didn't see any interest https://healthcaresecprivacy.blogspot.com/2016/08/controlling-big-data-feeding-frenzy.html
Alexander Henket (Mar 21 2017 at 13:11):
thanks, John!
Brian Postlethwaite (May 03 2018 at 03:52):
I'm finally adding this to my server and covering the "action" part as @John Moehrke described - the .(read|write|*)
Wondering if we've considered extending it to cover the other actions like operations.
I was contemplating
( 'patient' | 'user' ) '/' ( fhir-resource | '*' ) '.' ( 'read' | 'write' | $[AZaz-.]+ | '*' )
Where the $ covers operations too.
This would make a scope like these valid:
patient/Patient.$everything user/Observation.$lastn user/Questionnaire.$populate
Josh Mandel (May 03 2018 at 20:44):
I think this is definitely worth experimenting with!
Josh Mandel (May 03 2018 at 20:44):
Would love to get a sense of your experience with it.
Brian Postlethwaite (May 03 2018 at 22:00):
I'll do some experimentation and see how it looks.
Brian Postlethwaite (May 04 2018 at 02:28):
the other action that is notably absent here is delete
(makes sense that search and get are under GET, but DELETE under write seems wrong)
Brian Postlethwaite (May 04 2018 at 03:41):
Looking through the operations, I can't generalize the operation access to either read or write permission.
any operation that changes data would need write permission (metaAdd), and others are read (valueset expand)
Grahame Grieve (May 05 2018 at 05:01):
so my first rule is that the OAuth scopes are not a permissions model. Are we talking permissions or authorizations? I personally think that the coarse split into read/write makes perfect sense for authorizing an application, but doesn't begin to cover it for a permissions models, which are notoriously complicated.
Brian Postlethwaite (May 05 2018 at 06:51):
I think of the OAuth scopes as function/feature level security, not data level security.
A first pass filter before the tough stuff gets done.
(Though that's probably wrong too)
John Moehrke (May 05 2018 at 12:16):
you are both partially right, but partially wrong. Scopes only need to cover the space which is a declaration of what is authorized for this requesting actor. It does not cover all the rules used to make that decision. OAuth is optimized for REST. This works really well when the various patterns for this level of authorization are simple, hierarchical, and declarative. Hence why most scope models are compartment and CRUD based. We have mostly designed FHIR to this model, but health data is more complex than a wiki, blog, filesystem, etc... I think we have also missed the principle that all elements in a resource should be the same level of access control need, one should not mix sensitive data into a resource at needs normal access. The grouping of elements purely according to clinical need can make resources that are hard to have a binary permit/deny decision on.
Brian Postlethwaite (May 06 2018 at 02:37):
Do the scopes in the way that we're using them in SMART more cover the types that the APP is able to access, not the user of the app. The users permissions are still then evaluated after that... (which may be more restrictive, but not less)
Josh Mandel (May 06 2018 at 02:39):
Yes, this is how I have looked at things. Scopes convey what an app is authorized to do, but are always restricted by the permissions of the user running the app.
John Moehrke (May 06 2018 at 14:02):
In the case with SMART, where the AS is tightly bound to the RS, there can be many simplifying mechanisms that you use. You can even do nothing other than PERMIT vs DENY, and do all actual authorization decisions in the RS. Thus never exposing in a token anything useful for the app. The more likely is that you do expose gross authorizations, like are found in the SMART scopes. If this s a specific goal driving SMART, then it should be declared. That intent description will then help people understand better the use-case that will fit SMART best. I don't know that this changes much of anything, but is a very useful thing for the reader of SMART to see. Right?
John Moehrke (May 06 2018 at 14:06):
I am not saying it is a limitation of SMART, but rather that it is an intended deployment simplifying assumption.
Last updated: Apr 12 2022 at 19:14 UTC
