Stream: smart
Topic: OAuth 2 with Smart on FHIR App
Sagar Shah (Sep 22 2020 at 14:42):
As I read through documentation, I see that we may need to support "patient" and "encounter" context information in the access token response. and the patient level scope applies to that patient. In view of that, as per SMART on FHIR, do we need to present patient (also encounter, if supported) field as a separate field other than access_token, refresh_token , scope fields in response to OAuth token endpoint response? Can it not be put as a claim as part of access_token field itself?
Josh Mandel (Sep 22 2020 at 14:44):
The "access token response" is the JSON payload that the authorization server returns to the client. In that response is an access token (opaque to the client) and other launch context properties like "patient" which are intended for the client to read and use.
Josh Mandel (Sep 22 2020 at 14:45):
Because the access token itself is opaque to the client, it might just be a random number or database key; SMART can't (and so doesn't) try to specify anything about contents or "claims" inside the token (string) itself.
Sagar Shah (Sep 22 2020 at 14:55):
Thanks for clarifying. So that means in general, we may have to provide this additional capability on top of Auth server (Keycloak, Okta, Ory Hydra, etc. which is being used) in order to support additional fields in the access token response, as none of the tools to my knowledge supports this out of the box.
Is that a correct understanding?
Sagar Shah (Sep 22 2020 at 15:02):
And once EHR launch is done and 3rd party App displays the relevant patient information, can the access token used in that flow be used to access other patient's data as well Or does that have to be restricted only for that patient which was returned as part of access token response?
Josh Mandel (Sep 23 2020 at 14:35):
Yes the functionality needs to be implemented inside your authorization server. The scope of access for a given token will depend on what has been approved, as well as on the underlying permissions of the user doing the approving. For scopes like patient/Condition.read, these would be limited to a single patient; for scopes like user/Condition.read, these would provide access to any patients that the approving user has access to
Sagar Shah (Sep 23 2020 at 16:36):
Correct! but once access token is obtained by the user having access to multiple patient, in that case App wont require to get another Access token when switching the patient, correct? Same patient level scope which was obtained earlier "patient/Condition.read" will be applicable to another patient, if user has access to that patient and that does not require App to obtain another access token, correct?
Thanks again for your response!
Josh Mandel (Sep 23 2020 at 17:12):
I'm not sure I understand the question. There are two levels of permissions: user level and patient level. If an app is using patient level permissions, it will need a new access token for every patient it accesses. If the app is using user level permissions, it can use one access token to fetch data about different patients.
Sagar Shah (Sep 23 2020 at 18:09):
That clarified my question, I think. We are planning on supporting both patient facing app (patient level access) and provider facing app (user level access to multiple patients). My questions was mainly on later scenario where healthcare provider logs into to app and has access to multiple patient, but during EHR launch it acquired a token with a specific patient in context of EHR application. Can he use that same token in 3rd party app to access other patient related information as well? I believe answer to that scenario is yes reading from your previous post.
Josh Mandel (Sep 23 2020 at 19:26):
Cool! Keep in mind that patient facing apps just like provider facing apps can be designed with patient levels permissions or user level permissions. The permission model isn't determined by the type of end-user.
Erez Shalom (Mar 27 2022 at 20:15):
The current authorization method in our non-FHIR patient/provider apps is 2fa (hospital policy).
Now we moving to FHIR and want to change the app to be smartonfhir. Is there a way to keep the 2fa process in the new smart process, or we need to change it?
Josh Mandel (Mar 28 2022 at 01:08):
SMART on FHIR spec is silent on how users authenticate to the underlying EHR. If you're building an EHR, you should use what works for you.
Josh Mandel (Mar 28 2022 at 01:09):
If you're building an app, you can perform your own authentication or use whatever authentication mechanism the EHR exposes to you by asking for OpenID Connect scopes when you launch.
Last updated: Apr 12 2022 at 19:14 UTC
