Stream: CARIN IG for Blue Button®
Topic: Authorized Reps
Neophytos Iacovou (Nov 09 2020 at 20:46):
Hello
I'm having a hard time wrapping my head around 'Authorized Reps' and how they will be able to access information. I see 2 scenarios:
1) I'm not a member, but I am authorized to view the information of 1 or more members
2) I'm a member, and I'm also authorized to view the information of 1 or more members
once an authorized rep logs in, and they can view more than 1 member's information, how do they pick which one to proceed with?
In my mind, if I give each authorized rep a new login, and associate the login to 1 member, I can make this work. But it breaks other scenarios.
Can someone steer me in the right direction please?
Michele Mottini (Nov 09 2020 at 20:50):
The client uses the launch/patient scope to request a specific patient, and the server prompts the user to select the member they want to share the data of (if the user has more than one), something like this:
image.png
Michele Mottini (Nov 09 2020 at 20:50):
The id of the selected patient (member) is returned to the client app in the token response
Neophytos Iacovou (Nov 09 2020 at 23:04):
I've also found this discussion extremely helpful, https://chat.fhir.org/#narrow/stream/204607-CARIN-IG.20for.20Blue.20Button.C2.AE/topic/Personal.20representative.20business.20rules
Neophytos Iacovou (Nov 09 2020 at 23:25):
Michele Mottini said:
The client uses the
launch/patientscope to request a specific patient, and the server prompts the user to select the member they want to share the data of (if the user has more than one), something like this:
image.png
that is a great example btw, may I ask:
a) The patient ID is part of the access token response (patient property). Are you returning a list of patientID? ? Are you doing patient/.read and not user/.read ?
b) What happens after i select a user and click 'allow access'? call the authorization endpoint for a new access token for the selected user?
Michele Mottini (Nov 09 2020 at 23:45):
Are you returning a list of patientID? ? Are you doing patient/.read and not user/.read ?
Only the id of the patient that was selected. Yes, typically the client would specify patient access scopes, patient/*.read
What happens after i select a user and click 'allow access'? call the authorization endpoint for a new access token for the selected user?
You are not selecting a user - the user is whoever logged in - you are just selecting the patients to use amongst all those the user can access.
Neophytos Iacovou (Nov 10 2020 at 02:54):
Michele Mottini said:
Are you returning a list of patientID? ? Are you doing patient/.read and not user/.read ?
Only the id of the patient that was selected. Yes, typically the client would specify patient access scopes,
patient/*.readWhat happens after i select a user and click 'allow access'? call the authorization endpoint for a new access token for the selected user?
You are not selecting a user - the user is whoever logged in - you are just selecting the patients to use amongst all those the user can access.
you are correct I used the wrong wording.
Does it work like this?
- as part of the launch the fhirUser is requested
- assuming it is provided, the application uses the claim as a url, retrieves the fhir resource the url is pointing to
- if the resource on the other end of the url is a Patient, then the user is the same as the patient information is requested of
- if, however, the resource is a Person, then the user is not guaranteed to be one of the patients they are able to ask for information about. In the Person resource the 'link' attribute is an array associating any number of targets (for example Patient) to the user. the client app can follow each of the targets to present a list of resources back to the user.
am I putting it all together correctly?
Michele Mottini (Nov 10 2020 at 14:11):
No, that is not correct. The authorization server handles the patient selection, not the client. The screen-shot I posted above is something the server has. The client app gets back just a token and a patient ID, and use those to get the data.
Neophytos Iacovou (Nov 10 2020 at 16:17):
clearly i'm the most uneducated person in this room regarding this topic. Is this spelled out someplace that I need to read to understand?
I really don't want my authorization server, for example okta, to have to understand the mandate nor my data
Michele Mottini (Nov 10 2020 at 16:45):
What the spec says is that clients can request a patient in context from the server (http://hl7.org/fhir/smart-app-launch/scopes-and-launch-context/index.html#requesting-context-with-scopes) - how that is accomplished is totally up to the server, but if the user that is logging in has access to multiple patient pretty much the solution everyone chose is for the server to ask the user to pick one, and I am not sure what other possibilities do exits.
This is the way FHIR-based patient access API have been working for years now. And yes, it does mean that the authorization server needs to know things about the data.
Spencer Kathol (Nov 16 2020 at 23:48):
I'm working on designing how the auth server will support authorized reps. The approach I have currently in mind pretty much lines up with the discussion above - member selection on the permissions screen. I'm trying to think through how to minimize impact to the end user and came up with the following:
- Client app would need to know to re-initiate the authorize workflow when the user wants to switch/add patient context
- Login cookie can be used to avoid the need to log in again
- User would be required to click through the permissions screen (and make a member selection)
I'm also a little apprehensive that client apps know the way to give their users access to other authorized members is to re-initiate the authorize workflow. Based on the discussion above, it sounds like this is the de facto way to do it. Are we pretty safe in moving in that direction?
Michele Mottini (Nov 17 2020 at 00:02):
Yes, that's the direction. Apps can mess up things on their side mixing data from different person, but not much that can be done about that server-side.
Last updated: Apr 12 2022 at 19:14 UTC
