Stream: argonaut
Topic: Scopes for data access
Josh Mandel (Mar 09 2020 at 16:17):
Our project on more-granular scopes is going to be particularly important given that ONC's rule requires adoption of resource-level access as defined in SMART v1:
Specifically, this means patients would need to have the ability to authorize access to their EHI at the individual FHIR resource level, from one specific FHIR resource (e.g., “Immunization”) up to all FHIR resources necessary to implement the standard adopted in § 170.213 and implementation specification adopted in § 170.215(a)(2)
Isaac Vetter (Mar 09 2020 at 16:19):
Does this mean all, at the fhir resource or more granular than the fhir resource?
Josh Mandel (Mar 09 2020 at 16:19):
The current ONC language refers to resource-level scopes. But the standards advancement process means we can define better / more-granular scopes too, and if we do a good job, ONC can point to that and say "also acceptable".
Josh Mandel (Mar 09 2020 at 16:21):
Yeah, I think I agree with you @Michele Mottini -- this isn't something I asked for in my own comments, and I was surprised to see it.
Keith Boone (Mar 09 2020 at 16:30):
See http://motorcycleguy.blogspot.com/2020/01/fine-grained-access-control-with-smart.html for starters.
Keith Boone (Mar 09 2020 at 16:39):
Then, on scope syntax, I think adding a third layer will suffice that allows a user to request access to information that has certain values in meta.security. These are coding values, so they can be textually represented as system#code.
One could request the scope: {Resource}.read.system#code to request read access to resources with a specific tag.
One could request {Resource}.read.* to request all tags (the endpoint would enumerate tags allowed in the returned grant)
If no security tags are provided, the endpoint could determined tags to allow based on predetermined policy.
The implementation is free to figure out how tagging is done. It could be pattern based (e.g., a value set of sensitive observation codes), or through specific attributes of the backing data (e.g., a sensitive flag stored in a database), or through other means.
A base set of sensitivity tags can be identified for use in an exchange or region (e.g., US Core) which would be commonly understood.
Josh Mandel (Mar 09 2020 at 17:53):
I think supporting tag based rules is great, but actually tackling some semantics about putting decisions in-band (e.g., "yes share my weight history but not my HIV history") will also be important this year.
Josh Mandel (Mar 09 2020 at 17:55):
I totally agree that out of band restrictions are very practical, and at the very least we want to highlight that they are allowed, and that we encourage portal developers to experiment
Keith Boone (Mar 09 2020 at 17:55):
I won't argue that point, but I think that's a whole separate set of concerns that should be addressed separately from the access control scope negotiation. It's a different set of endpoints at least that the patient needs to be able to use to manage those sorts of decisions.
Josh Mandel (Mar 09 2020 at 20:01):
I'd love to put an hour on the calendar for the two of us to talk through some of this stuff if you are up for that?
Keith Boone (Mar 09 2020 at 20:02):
Yep.
Josh Mandel (Mar 09 2020 at 20:02):
(same offer stands for anyone here with a perspective -- I'm trying to take better advantage of one-on-one meetings to really understand where people are coming from on complex topics.)
John Moehrke (Mar 12 2020 at 14:53):
There is already some IG that have started within Security WG that intend to provide subsets of the large valueset of HCS code for specific use-cases. This effort is not clear it would address scope impact, but could. I think these use-case specific IG are the right approach as the use-cases we need to address are going to get more specific. Interactions between various IG must be built into this library of security/privacy IG
John Moehrke (Mar 12 2020 at 14:54):
The security WG is eager to get going on a new SMART... but we need more stakeholders, like those from the Argonaut group (and others). The security wg is the right place to host this, but doesn't tend to have sufficient stakeholder cohort. So please help me create a cohort that wants to work on this
Josh Mandel (Mar 12 2020 at 15:00):
We're planning to run an Argonaut project launching next week -- so at least we should have a good community driving requirements and sketching out guidance. The interaction between those meetings and Security WG calls is something we should talk through; I expect the general process flow will follow previous Argonaut projects.
John Moehrke (Mar 12 2020 at 15:04):
please encourage them to expand their thinking to security WG, not just argonaut. I very much understand the value of a smaller community, but we can't continue to have 'not invented here' around the standards community
Josh Mandel (Mar 12 2020 at 15:06):
Totally agree -- that's why this is an open community project hosted in HL7, by the Argonaut "standards accelerator". Would love to have your participation.
Douglas DeShazo (Aug 24 2020 at 20:53):
If I'm a payer and I have proprietary scopes defined for OAuth2 and retrieval of PHI, can I use those in the authorization process and be compliant with SMART Application Launch Framework or should I be using scopes that are resource specific as stated in the spec?
Josh Mandel (Aug 24 2020 at 20:54):
If you are hosting a fhir API, then the expectation is that you would support smart scopes. If you need to expose access to something other than fhir resources, you can always extend the scope set -- we recommend prefixing any such "extension" scopes with __ to ensure that your names never conflict with Scopes that we define in the future.
Douglas DeShazo (Aug 24 2020 at 21:04):
Thanks @Josh Mandel
John Moehrke (Aug 25 2020 at 12:52):
Josh Mandel said:
If you are hosting a fhir API, then the expectation is that you would support smart scopes. If you need to expose access to something other than fhir resources, you can always extend the scope set -- we recommend prefixing any such "extension" scopes with
__to ensure that your names never conflict with Scopes that we define in the future.
Correction. If you are declaring support for SMART-on-FHIR, then... SMART-on-FHIR is just one of many implementation guides on OAuth standard for use with FHIR. There might be a stronger desire to use SMART-on-FHIR in the argonaut community, but it is not absolute..... right @Josh Mandel ?
Josh Mandel (Aug 25 2020 at 13:40):
To be clear, the initial question was about how to be compliant with the SMART App Launch IG.
In the context of the Argonaut project and more broadly in the context of ONC's US EHR certification program, the SMART App Launch specification is a requirement, which of course drives wider interest. These requirements in turn flow out to payers, since CMS named the ONC-adopted SMART IG in their final rule as well.
Josh Mandel (Aug 25 2020 at 13:41):
(Even more broadly: John is correct that a FHIR server can implement any kind of security system it wants if no other constraints or obligations apply. We do encourage folks to take advantage of SMART or specific pieces that are useful -- like scopes -- rather than reinventing the wheel.)
Last updated: Apr 12 2022 at 19:14 UTC
