Stream: implementers
Topic: Definitive AuthoriZation specification
Merlyn Albery-Speyer (May 28 2021 at 16:40):
Hey folks. I'm implementing AuthZ for SMART on FHIR on the server-side (for the CMS Interoperability Rule). It's clear to me that authorization fails to access "/Practitioner" urls without a "patient/Practitioner.read" or "patient/*.read" scope. But how do I determine reliably _which_ Practitioner entities a logged in patient can read? All of them? I have this same question for all of the entities in FHIR (with the exception of the Patient entity). Is how this is to be implemented specified anywhere that I can follow? Thanks!
Lloyd McKenzie (May 28 2021 at 17:37):
You might ask on #smart. I'm not sure where the patient/Practitioner scope is formally defined.
Michele Mottini (May 28 2021 at 18:46):
patient/Practitioner scope is somewhat iffy because there is no association between practitioners and patients - usually it is interpreted as equivalent to user/Practitioner scope = can access all Practitioners
Michele Mottini (May 28 2021 at 18:47):
For the clinical resource the meaning of the patient access scope is well defined: the client can access only those associated with the patient in context
Merlyn Albery-Speyer (May 28 2021 at 18:51):
Thanks Lloyd, Michele. I browsed the last year of related activity in #smart and then posted my question here: https://chat.fhir.org/#narrow/stream/179170-smart/topic/Context-dependent.20authorization.20.2F.20authz.
Merlyn Albery-Speyer (May 28 2021 at 18:52):
@Michele Mottini - is it sufficient then to blacklist any response from the FHIR server that references any other Patient, and otherwise let everything through (e.g. all Practitioner results)? I find it hard to reason about the security implications of that (not saying it's wrong - just that it's unclear for me).
Michele Mottini (May 28 2021 at 18:54):
is it sufficient then to blacklist any response from the FHIR server that references any other Patient, and otherwise let everything through
Yes
Michele Mottini (May 28 2021 at 18:55):
For non-Patient associated resources like Practitioner, Organization, Location some server do not implement the patient access scopes at all and require using the user scopes - that is probably cleaner but results in some 'strange' mixed patient / user scopes
Merlyn Albery-Speyer (May 28 2021 at 18:58):
Here's a scenario that supports my FUD. Annotation does not reference a Patient, but appears as though it could perhaps contain sensitive PHI data in the text field: (https://www.hl7.org/fhir/datatypes.html#Annotation) - e.g. practitioner authors an annotation.
{doco
// from Element: extension
// author[x]: Individual responsible for the annotation. One of these 2:
"authorReference" : { Reference(Practitioner|Patient|RelatedPerson|Organization) },
"authorString" : "<string>",
"time" : "<dateTime>", // When the annotation was made
"text" : "<markdown>" // R! The annotation - text content (as markdown)
}
Michele Mottini (May 28 2021 at 19:00):
That's a data type and not a resource
Michele Mottini (May 28 2021 at 19:08):
having said that: it is surely possible that there are resources that are (1) not patient associated and (2) contain sensitive data, but when an app use patient scopes to get data about a patient it really need only patient-associated resources and those handful of resources referenced by them that are necessary for completeness: Practitioner, Organization, Location, PractitionerRole
Merlyn Albery-Speyer (May 28 2021 at 19:17):
(Ooops. Thanks for catching my blunder). Ahh. I see. There aren't patient scopes out there for resources that are sensitive that don't link to the patient. Got it. Thanks, Michele.
Michele Mottini (May 28 2021 at 19:50):
Scopes are just strings, they can always be made up - but a server decided which one to accept
Last updated: Apr 12 2022 at 19:14 UTC
