Stream: implementers
Topic: Authorized representative and SMART-on-FHIR
Severin Skillman (Sep 21 2019 at 16:41):
I am reading the following section regarding SMART scopes:
It mentions
"Note that Person is only used if the other resource type do not apply to the current user, for example, the “authorized representative” for >1 patients"
While the Person resource enables linking of, in this case, an authorized representative + >1 patients, the Person specification states that
These linkages assert that all the records relate to the same individual.
Is the Person resource still applicable for this usecase?
Josh Mandel (Sep 21 2019 at 18:35):
Yes -- there's a difference between using the Person resource to atand in for the authorized representative (which is what we do in SMART) versus asserting that the a given Person resource is the same individual as one or more Patients (which we don't do -- and which seems to be the thing you are asking about above).
Severin Skillman (Sep 22 2019 at 08:49):
Ah that makes sense and would satisfy the condition for it to be the same individual.
Following on from that then, if a user logged in as a Person (the stand in) the assumption is they would have a combination of their own perms and the perms of the Patient(s) they represent. How would one a) associate the person to the patients and b) declare this persons relationship to be the auth individual for the patient(s)?
Michele Mottini (Sep 22 2019 at 19:07):
Typically internally in the system - not via FHIR or an API
Severin Skillman (Sep 22 2019 at 19:51):
I decided I'll add a "fhirPatient" scope/claim like how the "fhirUser" works and then give the authenticating Person following scopes:
patient/*.*
user/Person
user/RelatedPerson
where RelatedPerson is the authorized individual being referenced in the Person resource.
That should work right?
Michele Mottini (Sep 23 2019 at 01:03):
Not sure what you mean. Those would be non-standard scopes and no app would use / understand them
Severin Skillman (Sep 23 2019 at 04:33):
True. I suppose as an alternative the access control decision engine could determine which patient's data they have access to.
- Person abc123 is linked to RelatedPerson xyx123 (authorized individual) who is related to Patient asd456.
- User authenticates as Person abc123 and granted scopes patient/*.read, user/Person.*, user.RelatedPerson.*
- Access control decision engine determines the relationship in 1 above and applies ABAC rules to requests for data about Patient asd456
Michael Donnelly (Sep 23 2019 at 19:38):
Why does an app need to know whether the Person is the Patient? The server needs to know since it might have access to different information, of course.
Cooper Thompson (Sep 23 2019 at 20:54):
It might be one way for an app to detect that they want to abort the whole exchange. I.e. Apple Health could detect that the Person isn't the Patient and prevent mixing the proxy data they just got with patient data they might already have on the device. There are of course other ways to solve that.
Last updated: Apr 12 2022 at 19:14 UTC
