Stream: smart
Topic: Mobile app data-sync
Bashir Sadjad (Oct 01 2021 at 15:34):
Hi everyone, consider a mobile app for health workers (“practitioners”) that is supposed to work offline too but also synchronizes its data with a central FHIR server when online. Each practitioner should have access only to their patients but multiple practitioners might have access to the same patient. So syncing data works both ways. I am trying to see if the sync can be done through the SMART on FHIR (SoF) framework. Here are some questions which I hope the community here can help with:
- IIUC, the patient ID that is being accessed is not tied to the
access_token. In other words, the app can get one access_token with somepatient/*.*scopes and use the same token to access different patients, correct? OR is it necessary to get different tokens for each patient, if we usepatient/scopes? - Now let’s assume that we want to use
user/scopes instead. Is there any standard and/or recommendation on what auser/scope access means in terms of FHIR resources that can be read/written? Or is this completely left to the server to decide. For example, withpatient/scopes, I think Patient Compartment is used to decide what resources can be accessed; is there any similar recommendation foruser/scopes? - In general, does it make sense to use SoF for this sync problem? Has anyone else done anything similar to this through SoF that they can share?
Michele Mottini (Oct 01 2021 at 15:42):
Practitioner apps usually use user/ scopes. user/*.read (or user/*.*) give access to all resources, otherwise specific copes like user/Patient.read user/Condition.read can be used to give access to only specific resources
Josh Mandel (Oct 01 2021 at 15:43):
1) It's possible to use patient-level scopes and user-level scopes together in this same access token, but it's probably not a good fit for what you're talking about. If your goal is to have a practitioner accessing multiple patient records in an offline scenario, you'll probably want then to get an access token with just user-level scopes, since there won't be a single patient in-context across all these interactions.
2) You can define user/Observation.read in SMARTv1, or things like user/Observation.cruds?category=... in SMARTv2. Keep in mind that the actual rules about what the end-user is allowed to do live in a layer below SMART authorization; SMART just defines a delegation protocol for sharing a user's access with apps. See http://build.fhir.org/ig/HL7/smart-app-launch/scopes-and-launch-context.html#smarts-scopes-are-used-to-delegate-access
3) SMART on FHIR will help with a piece of this problem (delegation to apps) but your authorization server and resource server still need some underlying way to know what roles and permissions each user has; SMART won't help with that part.
Bashir Sadjad (Oct 01 2021 at 16:11):
Thanks both for the quick responses. Yes, we are also inclined to use user/ scopes. However, the reason we are still considering patient/ scopes is that the underlying resource server has decent support for imposing access-controls for patient scopes which we like to get advantage of. So again, is it okay to fetch one access_token with some patient/ scopes and reuse it with different patients?
Also thanks @Josh Mandel for the link, that was useful. There are other interesting pieces in that version like separating search from read. How far is this newer version from being published as the new SoF spec?
Josh Mandel (Oct 01 2021 at 16:23):
No, that's not what patient Scopes means. Patient level Scopes are only relevant if you are requesting permissions about a single patient -- think of these as meaning "there is a single patient identified in the context of the launch and I want permissions on that record". If you don't have a single patient identified in the context of your launch, and patient level Scopes are not for you. (In my answer to question one above, I noted the technically patient level Scopes can be combined with user level Scopes -- and that is correct, but it does not accomplish what you are ooking for here.)
Bashir Sadjad (Oct 01 2021 at 17:16):
I see, thanks. Now let's consider a case that the practitioner wants to use the app for accessing data of a single patient only. It seems to me that the general flow is to ask for launch/patient scope and then during the authorization, the user goes through a "patient picker" step to choose the patient (since practitioner has access to many patients). But what if we exactly know which patient we need in advance (using the local data on the app)? Is it possible not to ask for launch/patient but later provide patient context when the app uses the issued access_token? OR is the access_token for a patient/ scope supposed to be issued only when it is clear what the patient context is?
Michele Mottini (Oct 01 2021 at 18:43):
You are making things more complicated that they need to be. Just use user/... scopes, and have the practitioner select the patient they want from inside the app
Bashir Sadjad (Oct 01 2021 at 19:08):
The main reason I am still considering patient/ scope is to benefit from the support that the resource server provides. Otherwise we need to implement a lot of access control rules on top of that (with user/ scopes). With the patient/ scope I can simply check if the practitioner is allowed to access information about that particular patient and then leave everything else (e.g., what are the FHIR search parameters used, etc.) to the resource server to deal with.
Bashir Sadjad (Oct 04 2021 at 04:17):
So just to close the loop here, I think the answer to my last question is that patient context has to be included in the access token as an extra claim. Previously, I was looking at some JWT access tokens with patient/... scopes but no patient claim in them (I think I know why now) which confused me. So to summarize, I think patient context has to be known when a patient scoped token is issued.
Josh Mandel (Oct 04 2021 at 04:23):
Correct, patient context must be known when a patient scoped token is issued. See for instance http://build.fhir.org/ig/HL7/smart-app-launch/scopes-and-launch-context.html#standalone-apps --
Note on launch/patient: If an application requests a clinical scope which is restricted to a single patient (e.g. patient/*.rs), and the authorization results in the EHR granting that scope, the EHR SHALL establish a patient in context. The EHR MAY refuse authorization requests including patient/ that do not also include a valid launch/patient scope, or it MAY infer the launch/patient scope.
Last updated: Apr 12 2022 at 19:14 UTC
