Stream: smart
Topic: fhirUser when >1 resource type applies
Marco Ramos (Jan 22 2021 at 20:05):
Happy Friday All!
I've got a question about a FHIR authorization server's implementation to support clients providing the fhirUser scope defined in the SMART Application Launch Framework Implementation Guide Release 1.0.0.
For some deployments, we may have a FHIR authorization server that uses a single identity provider for all users. This is regardless of whether the user is a patients, practitioner, or authorized representative. Our system currently allows a single user identity to be mapped to a patient AND a practitioner AND an authorized representative. Though this is rare, I'm trying to understand how the authorization server would decide which fhirUser reference is appropriate.
My initial thought is that a client meant for practitioners should prioritize the practitioner FHIR reference if it exists for the user over any other references that may exist for the user. This would appear to require some way of the authorization server understanding the target audience for the application which as far as I know isn't something that is standardized when using dynamic client registration. This approach also doesn't handle applications which target various audiences; of which I know none, but given that there is no explicit prohibition in FHIR, may need to be considered.
There are other approaches that suffer from usability concerns, such as prompting the user during the authorization flow.
Any input would be greatly appreciated.
Thanks,
Marco
Josh Mandel (Jan 22 2021 at 20:11):
Thanks for the question, Marco. I don't believe this has come up before, so I don't know if we have a very satisfying answer. Some thoughts:
- you could default to providing
Personresources, allowing the app to discover available links to other representations - for statically registered clients, you could preferentially pick a user type based on some kind of "app type" (practitioner facing, or patient facing, etc)
- if you support dynamic registration, you could ask for similar "app type" details; it's not standardized but could still be useful
- you could expose different FHIR endpoints associated with different audiences or types of access
Michele Mottini (Jan 22 2021 at 21:20):
We use Person (also because in some case our users is neither a practitioner nor a patient). I believe Cerner does the same
Josh Lamb (Jan 27 2021 at 00:00):
When I saw Google they used patient and person (if my memory is correct).
If practitioner and patient inherited from person I could see allowing all these types. It seems that people would want to know what the fhir user will serialize to and what to check for identity matching.
Josh Mandel (Jan 27 2021 at 00:02):
These types don't reflect an inheritance hierarchy; they do different jobs in FHIR (e.g., Person is all about linking)
Josh Mandel (Jan 27 2021 at 00:02):
"would want to know" -- yes, agreed. Currently the answer is: "one of these types," and an app should handle the set of types.
Josh Lamb (Jan 27 2021 at 00:09):
I am not keen to have one identity have 3 roles based upon fhir profiles. To the OPs question, person seems like a good fit since the concept that is being expressed is a person (one identity but three possible roles).
Josh Mandel (Jan 27 2021 at 00:11):
Topic we can raise for SMARTv2; a challenge is that for common scenarios, apps need to get a Patient ID and a Perosn ID and map between them. Would suggest creating a Jira item proposing a change.
Josh Lamb (Jan 27 2021 at 00:13):
I have some half baked ideas about how to use identity proofing but they fell apart when we use different fhir user types. I will keep in mind for v2.
Josh Mandel (Jan 27 2021 at 00:14):
I mean, I'd expect any idea that works with one resource type should work with 5; it just might be less ergonomic to implement.
Josh Lamb (Jan 27 2021 at 00:43):
The half-baked idea is to support search and a launch context based upon an identity proofed identifier (not a FHIR id). This would be useful when we are allowing trust between systems and they do not know how to determine the FHIR id. The FHIR id is becoming a point of contention to get data to flow.
Josh Mandel (Jan 27 2021 at 00:45):
Someone still needs to make rules about what fhir patient record ids that identity proofed Identity can access. So I'm not sure what the particular challenge is with fhirUser.
Josh Lamb (Jan 27 2021 at 00:51):
Assuming we have two systems that have solved the magic of trusting each other (we both agree Josh Lamb has an identifier of "system"|"123" and we agree to trust when one system says that Josh wants to share data).
If I have an identifier of "123", how do I get my FHIR patient ID without granting user-level access (launch/User)?
Josh Mandel (Jan 27 2021 at 00:53):
system A supplies and identifier to system B. System B performs a lookup and its own data system and maps the supplied identifier to a patient record. System B presents the smart on fhkr authorization screen associated with the record found. The app is oblivious to all this.
Josh Lamb (Jan 27 2021 at 01:07):
Yes, essentially to get the FHIR id we have to exchange (I send id and you return FHIR id).
When I have multiple sources and the consumer has provided System A with consent already I will not need the consumer to provide the consent again (or login again).
If I could including something like
'Patient': 'system|123' (between trusted systems) the receiver could do the lookup and not be required to send back the FHIR id or to gather consent again.
Josh Lamb (Jan 27 2021 at 01:08):
Anyway, ill keep mulling this over. Thanks for the help thinking through this.
[edit] This use case should use launch user scope.
Last updated: Apr 12 2022 at 19:14 UTC
