Stream: smart
Topic: Fhir OAuth Scopes
Sagar Shah (Oct 15 2020 at 21:02):
Reading through this document - http://hl7.org/fhir/smart-app-launch/scopes-and-launch-context/index.html
My understanding is it makes sense to assign scopes differently for
- patient facing apps - patient/(resource).(read/write/*) - so that patient has access to his/her own data in fhir format?
- provider facing apps - user/(resource).(read/write/*) - so that user could have this privilege on any patient's data?
Is that a correct understanding?
Also, I think another use case for patient facing app is with representative accessing data on behalf of the patient, where I think, we should be assigning user level scopes?
- What's the general thought process behind these 2 different patient/user type of scopes?
- When do we use it considering provider facing app (for ehr or standalone) and patient facing apps?
- Do we see a situation when same client may be given both scopes as patient specific and user level?
Appreciate your views!
Josh Mandel (Oct 16 2020 at 13:48):
For your first question: at t a high level there's no strict attachment of user/ scopes to provider apps (e.g., any app that runs within a single chart inside the EHR should request the narrowest scopes appropriate for its job -- this typically means patient/ scopes). And in the other direction, consumers often have access to more than one patient record (e.g, self and a child) and it's powerful to pull all available data into a consumer facing app.
So the short answer is: no, the description you wrote isn't the right mental model.
Josh Mandel (Oct 16 2020 at 13:51):
Re: examples where one app might get patient- and user- level scopes, this is a bit atypical but one example would be user/Appointment.read patient/*. read which might help an app focused on one patient's chart to show a message like "your next appointment is coming up in 5 minutes".
Josh Mandel (Oct 16 2020 at 13:53):
(There's also ongoing discussion about what's the appropriate way for apps to request access to broader supporting data like ValueSet, Organization, Structure Definition, etc -- whether it makes sense to request these in a patient context or only in a user context; this came up earlier this week.)
Sagar Shah (Oct 16 2020 at 18:17):
Thank you for clarifying.
is that ongoing discussion's decision would be related to FHIR version 4 or for later version? Or is it something still to be identified?
Josh Mandel (Oct 16 2020 at 19:06):
It'd be appropriate for use with any version of FHIR for r2 and onward; that's generally where SMART applies.
Last updated: Apr 12 2022 at 19:14 UTC
