Stream: smart
Topic: Survey: `fhirUser` for patient proxies?
Isaac Vetter (Jun 14 2019 at 13:22):
How does your SMART server represent a parent granting an app access to their child's data in the SMART/OIDC fhirUser claim? :thumbs_up: your chosen method. cc/ @Weiyu Zhang
Isaac Vetter (Jun 14 2019 at 13:22):
Choices:
Isaac Vetter (Jun 14 2019 at 13:22):
- (A) Consumer SMART authentication always contains a
Personresource infhirUser.
Isaac Vetter (Jun 14 2019 at 13:22):
- (B) Consumer SMART authentication always contains a
Patientresource infhirUser.
Isaac Vetter (Jun 14 2019 at 13:22):
- (C) For proxy access, Mom's
fhirUserclaim is a link to aPersonresource. (For self access, Mom is aPatient).
Isaac Vetter (Jun 14 2019 at 13:22):
- (D) For proxy access, Mom's
fhirUserclaim is a link to aRelatedPersonresource. (For self access, Mom is aPatient).
Isaac Vetter (Jun 14 2019 at 13:22):
- (E) Something more complicated that I would recommend! (And explain in thread).
Isaac Vetter (Jun 14 2019 at 13:22):
- (F) Something more complicated that I would not recommend ... :(
Isaac Vetter (Jun 14 2019 at 13:22):
To learn more about the user, the app should treat the fhirUser claim as the URL of a FHIR resource representing the current user. This will be a resource of type Patient, Practitioner, RelatedPerson, or Person. 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.
Isaac Vetter (Jun 14 2019 at 13:23):
References:
- SMART ballot issue: https://github.com/HL7/smart-app-launch/issues/192
- GH, pre-ballot discussion: https://github.com/smart-on-fhir/smart-on-fhir.github.io/issues/148
- @Matt Randall 's proposed rules: https://groups.google.com/forum/#!msg/smart-on-fhir/1F0jcaKxGsg/3Ua3bRgqDAAJ
Isaac Vetter (Jun 14 2019 at 13:25):
@Jenni Syed , @Michele Mottini - mind weighing in on this? (since you commented on #148)
John Moehrke (Jun 14 2019 at 13:32):
SMART should certainly enable real-time accesses by a guardian, by the patient as authorized by a guardian, etc... but the actual legal authorization statement is outside the scope of SMART, meaning SMART is only representing the real-time facts of some contract/consent that is held elsewhere. As with other Privacy Consent vectors (sensitive data, restricted/authorized users, etc) these are recorded as a Consent. A Consent resource is used to record the facts of the ceremony of getting the Consent and its rules. But a Consent resource is not an active authorization decision engine. The AuthZ is one opportunity to have an authorization decision made that is informed by Consent, a server resident $consent operation is another.
John Moehrke (Jun 14 2019 at 13:34):
of course HEART is the opposite role, in that HEART does manage the consents and only exposes in UMA/OAuth tokens the decision of a specific run-time request for authorization. Thus HEART is complementary but explicitly covering this space....
John Moehrke (Jun 14 2019 at 13:35):
Therefore using cascading OAuth one could use HEART for consent based authZ decisions, and SMART for RBAC (organization business rules); and in theory get both.
Michele Mottini (Jun 14 2019 at 13:35):
We always use Person - that corresponds to our own internal users - and that link as needed to Patient or Practitioner
Jenni Syed (Jun 14 2019 at 14:32):
We use Person, more because we also allow "user" scope accesses (eg: I get access to all my family records) and then RelatedPerson won't work. This way, at least it's consistent. If a patient is accessing on their own behalf (only their records/self), then we use Patient.
Lloyd McKenzie (Jun 14 2019 at 14:33):
I'm nervous about this use of Person. Person is intended to be a linking resource - it's not permitted to be an actor in FHIR references, so to see it being referenced as an actor in SMART is concerning...
John Moehrke (Jun 14 2019 at 14:41):
Person also has no role... where RelatedPerson, Practitioner, and Patient all have clear role... If all you have is Person, you don't know what role the user is playing, they might be a Practitioner and RelatedPerson as well as a Patient... I am not surprised that Person is used this way, as it fits close with 'User'. but note that 'User' would always have a role when acting.
Jenni Syed (Jun 14 2019 at 14:43):
For SMART, it is only intended to get the "open id profile" for the signed in person
Jenni Syed (Jun 14 2019 at 14:43):
which has things like email
Jenni Syed (Jun 14 2019 at 14:44):
It isn't intended to be used on a resource directly or be expected to be returned outside of that
Lloyd McKenzie (Jun 14 2019 at 14:50):
There's expected to be only one Person record for the human-being across all their Practitioner, Patient and RelatedPerson roles - would they similarly have only one open id profile for all of those?
Jenni Syed (Jun 14 2019 at 14:53):
open id profiles are usually tied to the way you log in
Jenni Syed (Jun 14 2019 at 14:54):
In our system, your practitioner profile and your patient profile are different identity systems
Jenni Syed (Jun 14 2019 at 14:54):
or consumer profile...
Jenni Syed (Jun 14 2019 at 14:54):
This does bear the question on why use patient instead of person sometimes on the consumer side :)
Jenni Syed (Jun 14 2019 at 14:55):
(we did it because when we first started, Person wasn't part of the SMART spec, even though there was no other option when accessing with "user" scopes for a consumer)
Jenni Syed (Jun 14 2019 at 14:57):
I think confusing profile and role is a dangerous thing to do. There isn't really an intent to communicate the role you are playing for the entire authorization session
Jenni Syed (Jun 14 2019 at 14:57):
EG: you may act as a mom, spouse, and patient all with one sign in for SMART
Jenni Syed (Jun 14 2019 at 14:58):
Similarly, a practitioner's role isn't communicated (are you being a gp, specialist, etc)
John Moehrke (Jun 14 2019 at 15:03):
I would agree that OpenID identifiers are just identifiers of an entity; Those entity can act in many roles as Jenni explains. However OpenId does not try to force only one OpenID identifier per human. I personally have many, and even many at one identity provider (google).
Isaac Vetter (Jun 14 2019 at 15:20):
This does bear the question on why use patient instead of person sometimes on the consumer side :)
Jenni, it sounds like if you were starting over, you might choose to implement Michele's approach of always using Person in fhirUser (for consumer scenarios). Would you agree?
Isaac Vetter (Jun 14 2019 at 15:23):
OpenId does not try to force only one OpenID identifier per human. I personally have many,
Hey John, do note that this is specifically about the fhirUser OIDC claim, which is really just a FHIR-specific version of the standard OIDC profile claim which is just the url of the user's "profile page". I think that your point is exactly why Person makes sense - the Person resource is essentially just all the linkages for a user.
Jenni Syed (Jun 14 2019 at 15:26):
@Isaac Vetter probably - I haven't heard that SMART was intending that to be anything other than just details of the person signed in
John Moehrke (Jun 14 2019 at 15:36):
I am not against using Person in this way. Just poiting out that this is short of statements of context based role/agent... As Jenni points out, the Person resource is sufficiently abstract and contains the right elements... sorry, not strongly up or down from me.
Josh Mandel (Jun 14 2019 at 17:34):
Agreed that the goal of the OIDC profile claim here is authentication -- plus an entry point to discovering FHIR specific details about the person (like being able to traverse the links from a Person to a Practitioner, with assurance).
Josh Mandel (Jun 14 2019 at 17:35):
Perspective using person across the board would be a totally reasonable way to do it, as long as Person.link correctly populated in the case of a patient and/or a practitioner.
Josh Mandel (Jun 14 2019 at 17:35):
We evolved to using person slowly as more use cases became known, and I think the current specification reflects that evolution.
Isaac Vetter (Jun 18 2019 at 17:05):
How should an authorization server determine when to reference other resources from Person?
Isaac Vetter (Jun 18 2019 at 17:05):
For a patient app, where the user is the authorized patient A:
- Person.link -> Patient A
Isaac Vetter (Jun 18 2019 at 17:05):
For a patient app, where the user is a proxy for the authorized patient B, should the Person resource still reference the proxy's patient resource? Should the Patient resource identify other potential proxy relationships?
- Person.link -> RelatedPerson.patient -> Patient B
- Person.link -> Patient A ?
- Person.link -> RelatedPerson.patient -> Patient C ?
Isaac Vetter (Jun 18 2019 at 17:17):
Also, Person says:
Person instances are never directly referenced as actors (authors, subjects, performers, etc.)
Doesn't this substantially invalidate the use of the Person resource as a user?
Grahame Grieve (Jun 18 2019 at 17:46):
pretty much. If you want to use Person as a user, you'd need to follow the reference to Patient or Practitioner, and ask the user which mode they were wanting to be (given the Argonaut makes that distinction a binary and that it's driven by regulation/business practices)
Michele Mottini (Jun 18 2019 at 18:04):
On our server the Person link only to the 'self' Patient - not to other relationships like family members etc (because the spec say 'The resource to which this actual person is associated')
Michele Mottini (Jun 18 2019 at 18:05):
(In general trying to model users and related audit log entries does not work very well for us with the current FHIR resources)
Isaac Vetter (Jun 18 2019 at 18:09):
thanks, guys
Brian Postlethwaite (Jun 19 2019 at 00:37):
So yes, would have to link through the RelatedPerson for proxy usage.
All this does reflect that the user is separate to FHIR, and permissions are also outside, but informed by some FHIR content.
Josh Mandel (Jun 19 2019 at 03:57):
I'd think the Person resource wouldn't change based on context of use, though access to the relevant details of the linked Patient/RelatedPerson/Practitioner resources might be gated by user authorization.
Michele Mottini (Jun 19 2019 at 12:59):
would have to link through the RelatedPerson for proxy usage.
Sorry, don't understand how you would do that?
John Moehrke (Jun 19 2019 at 15:48):
The linkages between user as a proxy to a Patient would be found in the Consent. This is what Consent.provision.actor is used for. To authorize specific identities (possibly just business identity (aka userID)) as an authorized AGNT.
John Moehrke (Jun 19 2019 at 15:50):
The consent example is not very clean... but here is the Grantor example. I would rather see the actor identified a AGNT with a clear PERMIT privilege. http://build.fhir.org/consent-example-grantor.html
Michele Mottini (Jun 19 2019 at 16:23):
We do not have the Consent resource
Isaac Vetter (Jun 19 2019 at 16:47):
would have to link through the RelatedPerson for proxy usage.
@Michele Mottini , I'm not suggesting this is a good idea and clearly, to John's point, authorization ought to be acquired before sharing relationships. I'd think that a proxy relationship could be represented as either:
1. Person.link -> RelatedPerson.patient -> Patient B
2. RelatedPerson.patient -> Patient B
What am I missing?
Michele Mottini (Jun 19 2019 at 18:01):
Ah yes, I see now: Person can link a Patent (him/herself) and then one RelatedPerson for each relationship ('son', 'mother' etc) - with each of those referencing the corresponding Patient. Thanks Isaac
Last updated: Apr 12 2022 at 19:14 UTC
