FHIR Chat · Smart Framework Supported by Patient Apps · smart

Stream: smart

Topic: Smart Framework Supported by Patient Apps

---

Aju Jacob (Aug 19 2020 at 15:24):

I apologize if this is a redundant question. What authentication framework does patient-centric apps like Apple Health follow? Is it the SMART App Launch framework #1 (Patients apps that launch standalone), where the app expects the Patient FHIR ID in the JWT response token?

Michele Mottini (Aug 19 2020 at 15:44):

Yes, they use patient stand-alone launch. Note that the FHIR patient ID is not _inside_ the token (that does not have to be a JWT by the way), it is in the token response

Jenni Syed (Aug 19 2020 at 18:42):

I will stress a point in Michele's response above, since there's confusion there: in OAuth the token is opaque to the app and you don't want to break that open/expect any format :) Make sure you're looking at the claims returned during token issuance instead (in their own fields in the token response)... otherwise you'll get broken

Aju Jacob (Aug 19 2020 at 19:18):

Thanks @Michele Mottini and @Jenni Syed. This is very helpful. You're right, I meant including the FHIR Patient ID in the claims returned during token issuance.

Ryan Harrison (Sep 01 2020 at 16:38):

Thanks so much for the "stressed point." I've read "3.3. Launch context arrives with your access_token" dozens of times, and I've been confused. On a careful reading with your access_token, not in your access_token, but it's easy to miss.

For launch/patient, I understand that the Auth server will include the PatientId in the token response. This is possible because the PatientId can be linked to the login identity; for example, with a custom attribute.
URL: /token?scope=launch/patient
{
access_token: <jwt>
Patient: 123
}

However, for launch/encounter and the pending launch/appointment PR, how would the Auth server know which encounter or appointment to use?

Is the encounter or appointment supposed to be passed in the token request URL?
URL: /token?scope=launch/encounter&encounter=123
{
access_token: <jwt>
Encounter: 123
}

Michele Mottini (Sep 01 2020 at 17:30):

It is up to the server. It can ask the user to select one, or pick it up from current context in the case of embedded apps (that is the common use cases for those kind of scopes I guess)

Robert Smayda (Oct 07 2020 at 19:25):

If the patientId is not within the access_token how will the Resource Server know what this user has access to?

If the patientId is not in the access_token I presume the Resource Server must query the AuthZ Server to get further required user information

Toy example: I get an access token from my AuthZ server and the SMART client app queries the Resource Server with /Patient/{yourId} instead of /Patient/{myId}. How does the Resource server 'block' the SMART client from doing this?

Josh Mandel (Oct 07 2020 at 19:29):

as far as the standardization is concerned, smart is entirely about the relationship between the app and the EHR. We don't try to provide any requirements about how the different components of the EHR interact with each other.

Josh Mandel (Oct 07 2020 at 19:29):

These components might agree on a token format such as json web tokens, or they might share a database where the resource server can look up information.

Josh Mandel (Oct 07 2020 at 19:30):

We do recommend that the authorization server support a token introspection endpoint; and indeed this has become a requirement for any certified EHR under onc rules.

Josh Mandel (Oct 07 2020 at 19:30):

We are working on some guidance to make it clear how the patient ID can be discovered from this token introspection endpoint.

Josh Mandel (Oct 07 2020 at 19:30):

let me share a link to the draft guidance...

Josh Mandel (Oct 07 2020 at 19:32):

https://github.com/HL7/smart-app-launch/pull/306/files?short_path=c16e67a#diff-c16e67ab61d8d337cea376b288ffdf99

Robert Smayda (Oct 07 2020 at 20:18):

Got it just to confirm - from SMART client point of view the contract is:

• When user is authorized the SMART client will have an access_token and any required context (i.e. patient id for launching patient information)
• This required context will live outside of the access_token from the AuthZ response, but it may also be inside of the access_token (based on discretion of AuthZ server).
• When SMART client makes request to Resource Server they add the access_token as the auth header and that additional context is either in the FHIR url (/Patient/{id})or not provided to the Resource Server

Thanks for looking this over!

Josh Mandel (Oct 07 2020 at 20:27):

That's right! To be specific

• the patient context is communicated to the client in a "patient" property, which is a sibling of the "access_token" property of the access token response. And

• the access token is included in an authorization header (but it's not the whole header; it's prefixed with Bearer )

Josh Mandel (Oct 09 2020 at 20:26):

Given that this is a kind of frequently asked question, I've recorded a video explaining some of this: https://www.youtube.com/watch?v=X2lmbHAeOMg

(I know some people really like this kind of video format and some people really don't! If you prefer text, please note that the expanded video description includes a write-up of the important takeaways under "TL;DR".)

Michele Mottini (Oct 09 2020 at 21:49):

Nitpick: can you avoid 'EHR'? ...because then we fall into the 'I am a payer, this stuff does not apply to me' kind of deal

Michele Mottini (Oct 09 2020 at 21:50):

(Also: thanks for doing this!)

Josh Mandel (Oct 09 2020 at 21:52):

it's a good point. I can update the description and in the video itself I talk about EHR or Health Data system when I first bring it up, but it's just such a mouthful to say every time. Maybe I could try to settle on words like fhir server instead.

---

Last updated: Apr 12 2022 at 19:14 UTC