Stream: smart
Topic: system + patient scopes
Daniel Bonistalli (Oct 01 2019 at 22:07):
Good evening everyone,
We have a patient-facing app that collects patient entered data and relies on the EMR to manage identities. Therefore we need patient/* scopes and we need the authorization code grant type for identity reasons. Except, we also wish to post a monthly summary report note back to the EMR, and hit a roadblock since most EMRs do not accept patient/DocumentReference.write nor (IMO) should they.
The right solution here is probably to create a secondary app with its own client ID and register this secondary app with a single system-level scope (system/DocumentReference.write) and use its credentials to write back notes. Keeping the system/* scopes and the patient/* scopes separate in each app.
Or is it? Wanted to see if incorporating system scopes and patient scopes in the same application is lunacy :)
Grahame Grieve (Oct 01 2019 at 22:14):
if incorporating system scopes and patient scopes in the same application is lunacy
I don't see why you want a system level scope. Why not patient/DocumentReference.write?
Grahame Grieve (Oct 01 2019 at 22:14):
how is system level better than patient level?
Jenni Syed (Oct 02 2019 at 13:42):
One clarification: patient/DocumentReference.write doesn't mean that the patient is the user creating the document. It just means the token is scoped to a specific patient that was chosen at launch. Do you mean that most systems don't accept DocumentReferences that are authored by the patient themselves? If so, that's likely true. However, I question if that is what is going on here.
Jenni Syed (Oct 02 2019 at 13:43):
Where is that DocumentReference coming from?
Daniel Bonistalli (Oct 02 2019 at 18:40):
@Grahame Grieve We would prefer patient/DocumentReference.write, but have seen it not supported in some EHRs in their FHIR platforms. I think they are wary of including patient entered data in their EMR w/o clinician validation (understandable).
@Jenni Syed patient facing apps in Cerner aren't supporting any write scopes which means that an app that wishes to write back to the EMR may need to rely on some kind of system level access to post back a summary note.
Jenni Syed (Oct 02 2019 at 18:56):
Right. But there's a difference between not allowing "patient entered data" (when the patient is authenticated) and not allowing patient/DocumentReference.write (which we do allow - when the practitioner is authenticated and providing the data).
Jenni Syed (Oct 02 2019 at 18:57):
Who created the clinical note that is being sent back to the system? Did the patient themselves actually create it (eg: is it just a journal of something going on)?
Daniel Bonistalli (Oct 02 2019 at 20:40):
Patient enrolls for a study in which they enter some patient sourced data on a daily or weekly basis. Hospital systems are desiring that either A: scheduled summaries to be posted to the EHR or B: summaries to be posted to the EHR when the patient completes an action such as completing a pain score survey.
No practitioners are ever authenticated in this app. This is the root of the issue IMO - getting data into the EHR w/o practitioners needing to authenticate themselves and perform some action that triggers posting the note or observation.
My understanding is this is a case where introducing an additional system-level app might make sense because the note is not explicitly created by the patient or the clinician - it is generated by the application. I think this conversation answers my original question; it doesn't make sense to include system level scopes and patient level scopes within the same app, and instead these functions could be handled by two separate apps with separate scope levels.
Grahame Grieve (Oct 02 2019 at 20:50):
I think you are confusing different issues. a patient scope grants access to a particular patient record to some known user. Whether the source of any data being uploaded is the patient, a device, or some 3rd party, that's not related to the scope, it's a provenance issue
A system level scope grants access to the entire system, to upload documents for any patient (though a system typically will have additional permissions control)
I think that you want patient level access, and you want a further discussion with the vendors about provenance and permissions, which is not something that the scopes are baout
Daniel Bonistalli (Oct 02 2019 at 21:41):
Agreed - it's ultimately a permissions issue with the vendors and falls outside the bounds of scopes and probably this discussion stream. I imagine the use case is not unique and there may be other patient facing apps that need EHR write-back permissions for whatever reasons. Thanks!
Jenni Syed (Oct 02 2019 at 21:42):
I actually question, from a security perspective, why the study system would be writing back data on behalf of the patient. Does this mean the system is passing around and storing bearer tokens per patient long term?
Jenni Syed (Oct 02 2019 at 21:42):
Typically we try to isolate bearer tokens by use case, and if the systems are separate architectures, to isolate them to the purposes they have
Jenni Syed (Oct 02 2019 at 21:43):
The questionaire side seems to be more like patient contributed data, and actually tied to the patient's session
Jenni Syed (Oct 02 2019 at 21:44):
Other data that is produced by the study itself seems like a separate use case and could be contributed back directly by the study system itself
Daniel Bonistalli (Oct 02 2019 at 21:46):
Agreed on all accounts. Data produced by the study could be aggregated and pushed by the study system functioning as a system level application, isolating this bearer token from any patient-facing use case.
And questionnaire info would be patient contributed data and probably should be posted using the patient's session and bearer token. This use case is tough as bearer tokens issued to patients don't have write permissions for most EHRs (I could be totally mistaken though as my source of information is external facing EHR documentation).
Jenni Syed (Oct 02 2019 at 21:47):
Yes, that is a gap today :) I know it's one there's also interest in closing.
Daniel Bonistalli (Oct 02 2019 at 21:56):
It's an interesting discussion, the health systems we build FHIR apps for usually want some kind of write-back to the EHR; it fundamentally is the source of truth. But the .write scopes are quite broad and granting third party apps the freedom to let users write note after note after note comes with risk for the EHR.
Daniel Bonistalli (Oct 02 2019 at 21:57):
It'd be awesome to close that gap :) but I understand why it's not that simple
Grahame Grieve (Oct 02 2019 at 22:01):
I don't think that scopes are the question here. the scope is a authorization discussion between the record keeper, the application, and the user around what access the user wants to grant to the application. The discussion between the application and the record keeper is a different discussion that isn't limited to scopes and we shouldn't try and solve it with scopes
Jenni Syed (Oct 02 2019 at 22:04):
Sure, but when a patient authorizes an app to do something, they're authorizing the app to do it on behalf of them
Jenni Syed (Oct 02 2019 at 22:04):
They don't have the authority to authorize the app to do things as a clinical user
Jenni Syed (Oct 02 2019 at 22:04):
A practitioner doesn't typically authorize an app to act on their behalf (their system admin determines if that is an ok thing) - though there are exceptions
Grahame Grieve (Oct 02 2019 at 22:05):
of course. a user can only authorise an application to do things that the record keeper is going to allow them to do (well, I mean, they can authorise more but that won't mean it's possible)
Jenni Syed (Oct 02 2019 at 22:05):
Which means the app can have no more privs beyond the original authorizer
Jenni Syed (Oct 02 2019 at 22:05):
typically
Jenni Syed (Oct 02 2019 at 22:05):
(otherwise, in a web world, the user could likely just do it - without requiring server sides and signed bodies, etc)
Jenni Syed (Oct 02 2019 at 22:06):
I don't think he wants the clinical doc to follow the path we would follow if a patient handed us the same doc
Jenni Syed (Oct 02 2019 at 22:06):
from a trust and validation perspective
Grahame Grieve (Oct 02 2019 at 22:07):
indeed. but again, this is not a scope related issue
Jenni Syed (Oct 02 2019 at 22:07):
correct
Jenni Syed (Oct 02 2019 at 22:08):
Though an unfortunate side effect of doing B2B auth in SMART is that the system scopes are used. Which is confusing, and does cause a lot of this intermingling
Jenni Syed (Oct 02 2019 at 22:08):
because the patient/ and user/ scopes just are tied to any "on behalf of any user" workflow
Jenni Syed (Oct 02 2019 at 22:08):
So I can see where the confusion comes from
Grahame Grieve (Oct 02 2019 at 22:09):
y. on the system interface something totally different is required, but it's at app registration time.
John Moehrke (Oct 02 2019 at 22:24):
This has confused me, as I agree the app context can't have more rights than the user. So I have often wondered what the use of patient scope was.
Grahame Grieve (Oct 02 2019 at 22:31):
triggers a different pathway on the AS
Isaac Vetter (Oct 02 2019 at 23:44):
I heard the phrase "foreground SMART" yesterday used to make the distinction between b2b/backend/system/client_credentials and auth code/provider/patient-authorized.
I thought it was an interesting (and useful) term.
Jenni Syed (Oct 03 2019 at 16:45):
@John Moehrke the patient scopes limit that bearer token to a specific patient that was chosen at launch or before launch
Jenni Syed (Oct 03 2019 at 16:45):
So even if the user can access 10,000 patients, the app can only access 1 of those
John Moehrke (Oct 03 2019 at 16:56):
as a security person, I would prefer that the specific Patient.id be included in the token. seems improper security to assume that the launch context is a security resource
Jenni Syed (Oct 03 2019 at 17:05):
In our implementation, it is, but token and how resources interact with the auth server are outside the scope of standards. The launch is just how that patient id gets chosen/the app requests it.
Jenni Syed (Oct 03 2019 at 17:05):
Other servers could choose to communicate token restrictions/scopes/etc in a different way and still enforce what is needed.
Josh Mandel (Oct 03 2019 at 17:31):
as a security person, I would prefer that the specific Patient.id be included in the token. seems improper security to assume that the launch context is a security resource
The token is bound to the patient ID in this case -- but the token itself is opaque the the client, so this information needs to be communicated in some standard way (either a launch context parameter that comes next to the token, or through a context resolution API call, like token introspection)
Grahame Grieve (Oct 03 2019 at 19:42):
at the moment the only way I know to do this is search patient, to see what you have access to
Jenni Syed (Oct 03 2019 at 19:48):
@Grahame Grieve are you talking about if it's a user level scope and NOT constrained to a single patient?
Jenni Syed (Oct 03 2019 at 19:49):
or for the app to choose the patient in order to fulfill the launch/patient (or launch) that is required for a patient level scope?
Grahame Grieve (Oct 03 2019 at 19:56):
no for the app to find out what patient it's actually dealing with with a patient level scope
Josh Mandel (Oct 03 2019 at 19:58):
Inspecting the launch context is the main way, right now (if you did a single-patient launch).
Grahame Grieve (Oct 03 2019 at 21:19):
what about stand-alone launch, which seems to me the more likely thing for patient/ access?
Michele Mottini (Oct 03 2019 at 21:25):
Use launch/patient, get back id in token response
Jenni Syed (Oct 03 2019 at 21:29):
it's always in the returned launch context to the app when a patient (or encounter) is requested
Jenni Syed (Oct 03 2019 at 21:30):
our auth server errors if you use patient scopes and don't request the patient (via launch or launch/patient)
Grahame Grieve (Oct 03 2019 at 21:31):
our auth server errors if you use patient scopes and don't request the patient
how do you connect if you don't know the patient id - depend on the patient to identify themselves ?
Michele Mottini (Oct 03 2019 at 22:01):
The patient has to login to authorize the app - then it picks up the patient if there are more than one he can access to (dependents etc) - and that is returned to the app and becomes the patient-in-context
Grahame Grieve (Oct 03 2019 at 22:06):
but that's not consistent with
our auth server errors if you use patient scopes and don't request the patient
Michele Mottini (Oct 03 2019 at 22:11):
? If the app does request patient scopes and do not specify launch/patient the auth server will complain, otherwise everything works
Michele Mottini (Oct 03 2019 at 22:12):
'pick up the patient' happens as part of the auth sequence, not via FHIR calls - if that's what you are asking
Grahame Grieve (Oct 03 2019 at 22:22):
I think I might have misunderstood
don't request the patient
Jenni Syed (Oct 04 2019 at 15:42):
yeah, by "don't request the patient" I mean the app doesn't include the request for the SMART launch or launch/patient scopes (which drive a patient being chosen via the auth process/launch process before the token is issued)
Jenni Syed (Oct 04 2019 at 15:42):
If it's "launch" - in our system, the patient would have been chosen before the app is launched. EG: in our native chart
Jenni Syed (Oct 04 2019 at 15:43):
If it's launch/patient, our authorization server will require the selection of the patient during the authorization process (the app itself is not involved in this, the auth server does this workflow)
Last updated: Apr 12 2022 at 19:14 UTC
