Stream: smart
Topic: Launch SMARTly
Shovan Roy (Aug 14 2019 at 22:41):
Hi All,
We are working on building a FHIR server and a SMART app for our project and would like to seek advice if our approach is complient with SMART framework
As per the requirement, once successfully authenticated, the logged-in user will be taken to a home page where he/she can access mulitple records. The logged in user may have different role for each of the records shown in the home page. For an example, a mother logged in to the app can see the records of all of her children (as Auth Rep) and additioanl records for which the mother is nominated rep. The mother can nevigate from one record to another without being asked to re-login.
Our solution approach is as follows (briefly):
1. App will follow SMART launch sequences (starting from accessing CapabilityStatement)
2. The scope in the request will be "patient/. openid fhirUser launch/patient"
3. AuthZ server will issue the token for the logged-in user.
4. We are establishing the relationship between the logged-in user and associated records using Person.link, Patient, RelatedPerson model and roles are being managed using Consent.
5. Successful launch will return reference to the Person resource as fhirUser. The scope will be returned as "patient/."
Once the access token is generated, the APP will call GET Patient using the token and FHIR server will return back all the records ( based on the Person.link) as applicable. The home page will be rendered based on this response.
Is this approach aligned with SMART framework?
With this approach we are unsure as to how we can inform the APP about what the logged in user is entitled to do for each records (except self record). One way is to hardcode the logic in APP based on the role returned (Person.link.RelatedPerson) or we can ask the APP to call Consent for each of the Patient instance? is there any better way? I saw some details around "URI representation of scopes". Is this applicable here?
@Josh Mandel , @Grahame Grieve, @Brian Postlethwaite any guidance will be extremely helpful..
Josh Mandel (Aug 15 2019 at 00:10):
If you're designing an app that can access multiple records on behalf of the user, then you should be looking at user/ scopes rather than patient/ scopes. When it comes to communicating information about what the user is allowed to do for each patient, you could explore Consent as you indicated; this is not something we have to tried to standardize, since it goes beyond the question of delegating permissions to the app (rather it is an issue about what the user has permission to do in the first place).
Shovan Roy (Aug 15 2019 at 00:33):
Thanks a lot @Josh Mandel , I'll update our design accordingly.
Brian Postlethwaite (Aug 15 2019 at 01:59):
And the usage of the Person to mask the identity isn't something that's standardized at present, and you could even have internally done without exposing to FHIR.
Shovan Roy (Aug 15 2019 at 03:06):
thanks @Brian Postlethwaite , does this mean we maintain the Person.link based logic internally ( which seems anyway we have to) But not to expose it as fhirUser? in that case what do you recommend to return as fhirUser or remove it from the scope?
Last updated: Apr 12 2022 at 19:14 UTC
