Stream: inferno
Topic: Inferno requiring patient focus for non-patient resources
Jenni Syed (Feb 11 2021 at 16:23):
I noticed that Inferno is validating that scopes are of the format patient/... for a few resources that have no patient context. These should allow user/... : Organization, Location, and Practitioner
Jenni Syed (Feb 11 2021 at 16:23):
these also look like newer tests - is there a reason they were added?
Robert Scanlon (Feb 11 2021 at 18:53):
I believe these tests have been in place in their current form since v1.1 from July, with some minor updates when ONC provided guidance around PractitionerRole and RelatedPerson. And we regenerated some files with the move to US Core v3.1.1, which updated a few class names but that's about it. I can dig deeper if you'd like though.
Robert Scanlon (Feb 11 2021 at 19:36):
Is there a list of resources with no patient context, can it be inferred (e.g. if it has a direct reference to the patient in the resource) or is it completely up to the discretion of the server?
Jenni Syed (Feb 11 2021 at 20:10):
Ours typically is just resources that don't have references to patients
Jenni Syed (Feb 11 2021 at 20:10):
since there's no way to restrict it/meet that patient/... requirement in SMART
Robert Scanlon (Feb 11 2021 at 20:21):
If an app asks for patient/Organization.read do you change that to user/Organization.read when asking the patient for authorization? Or do you just ignore it as invalid (or return an error or something similar)?
Jenni Syed (Mar 02 2021 at 16:43):
@Robert Scanlon sorry, just saw this. We ignore it as invalid as this would/could change expectation by the app during runtime. The app would need to ask for the user/... scopes
Jenni Syed (Mar 02 2021 at 16:44):
There were previous discussions out on SMART about this, though it's been a while
Robert Scanlon (Mar 02 2021 at 17:34):
Thanks @Jenni Syed -- we've been looking at this on our side too. I just ask because I'm trying to understand how the flexibility here impacts app developers. It certainly would be nice for app developers if they can expect consistency (across all implementations) in the scopes that enable access to the complete set of patient data represented in USCDI/US Core.
Robert Scanlon (Mar 02 2021 at 17:38):
If an app asks for patient/Organization.read but you grant user/Organization.read, then the app wouldn't have to figure out ahead of time where your system decided to draw the "about/not-about the patient" line. My understanding is that this is allowed: "As with any requested scope, the scopes ultimately granted by the authorization server may differ from the scopes requested by the client! When dealing with wildcard clinical scope requests, this is often true."
Robert Scanlon (Mar 02 2021 at 17:57):
Doing that patient/Organization.read to user/Organization.read switch isn't a requirement, obviously, but it seems like it would be a nice solution to this problem. Unless I'm misunderstanding.
Jenni Syed (Mar 02 2021 at 19:44):
I don't know why any EHR would allow for patient/... scopes as there is no way to enforce that
Jenni Syed (Mar 02 2021 at 19:44):
cc @Josh Mandel as well, I know we've talked about this (and I think talked about it more with SMART 2.0)
Jenni Syed (Mar 02 2021 at 19:44):
there is no patient on these resources in FHIR
Jenni Syed (Mar 02 2021 at 19:46):
requiring the auth server to know which scopes can be "switched out" requires a pretty specifically built auth server, and I know many use off the shelf ones
Jenni Syed (Mar 02 2021 at 19:46):
(our server uses the change in scope for when the patient removes scopes or when the app wasn't authorized to request them - it isn't smarter than that)
Jenni Syed (Mar 02 2021 at 19:50):
Also the test fails b/c it doesn't see patient/Location.read (I can update the test to ask for different scopes already) so I think it would fail the same way if an auth server "swapped the scope out"
Josh Mandel (Mar 02 2021 at 20:26):
there is no patient on these resources in FHIR
Currently scopes like patient/Organization.read are allowed/valid in SMART with the interpretation of something like "Organizations the EHR determines you need access to in order to make in-context patient record".
Josh Mandel (Mar 02 2021 at 20:27):
I don't know how testable this is or should be though; to Jenni's point, I understand Cerner doesn't support scopes like this.
Robert Scanlon (Mar 02 2021 at 21:40):
Currently scopes like patient/Organization.read are allowed/valid in SMART with the interpretation of something like "Organizations the EHR determines you need access to in order to make in-context patient record".
I think the benefit on the EHR side is that you don't have to expose all Organizations/Practitioners/etc that a user has access to, to an app that only really needs information relating to the patient in context. The benefit on the app side is that they can expect consistency between implementations regarding what scopes to request if they really just want a single patient's data.
Josh Mandel (Mar 02 2021 at 21:58):
Agreed @Robert Scanlon!
Jenni Syed (Mar 03 2021 at 16:46):
It is very hard for an EHR to determine what practitioners a patient "should" have access to
Jenni Syed (Mar 03 2021 at 16:47):
IE: If I limited a practitioner by id lookup to only the practitioners that existed somewhere in the patient's history... I would basically be preventing them from scheduling new appointments or finding new providers. Or, from an app side, from recommending a referral etc
Jenni Syed (Mar 03 2021 at 16:47):
that also doesn't abide with how patient/... is defined in SMART today
Jenni Syed (Mar 03 2021 at 16:47):
same issue for organization and location. Why would I prevent the doctor from seeing all their orgs if they're trying to do a referral for a patient? Just because the patient hasn't been there? I think that would be surprising
Jenni Syed (Mar 03 2021 at 16:48):
But more to the root here, can we fix the assumption in inferno? This isn't required by any spec or CEHRT
Robert Scanlon (Mar 03 2021 at 17:08):
If I limited a practitioner by id lookup to only the practitioners that existed somewhere in the patient's history... I would basically be preventing them from scheduling new appointments or finding new providers. Or, from an app side, from recommending a referral etc.
Those seem to valid uses of user/Practioner.read (find practitioner near you or something), but that those are different capabilities than just "give me my full patient record", right?
Jenni Syed (Mar 03 2021 at 17:33):
our APIs are used for far more than just patient record access. The provider use cases ONC requires are for provider workflows, not just "give me my record"
Jenni Syed (Mar 03 2021 at 17:36):
Again, I think we've established that it's reasonable that an EHR doesn't support patient/... for resources that have no patient record tied to them. @Josh Mandel if we think this is a "valid" scope for SMART, we likely need to clarify what it means to enforce a "patient" specific limitation on resources that have no patient associated
Jenni Syed (Mar 03 2021 at 17:36):
I just would like inferno to be able to deal with this given that it's not clear what a patient restriction should even do here
Robert Scanlon (Mar 03 2021 at 17:57):
Could you also submit feedback to ONC @Jenni Syed? I've been looking for a clearcut reason I can use to justify relaxing this check here, and I was pushing back a bit because I do think the scope patient/Pracitioner.read makes sense at least. Whether or not you need to support that in order to satisfy the requirements of the rule which layers requirements from USCDI, US Core, SMART, etc isn't completely cut and dry to me. It seems like there isn't enough justfication for us keep this, and we should remove it. But removing it may have some ramifications of what can test at all (e.g. can I justify requiring systems to use any patient/* scopes at all?)
Robert Scanlon (Mar 03 2021 at 18:00):
(maybe we can't justify any testing around the shape of scopes, but that would be disappointing given how much content there is describing what scopes should look like)
Jenni Syed (Mar 03 2021 at 19:58):
@Josh Mandel what would your expectation be if a system was supposed to enforce patient/Location.read? IE: what does that mean?
Jenni Syed (Mar 03 2021 at 19:58):
and do we know what other systems are doing today?
Josh Mandel (Mar 03 2021 at 20:22):
It means "allow the client to see the Location resources that the server deems relevant for the in-context patient"
Josh Mandel (Mar 03 2021 at 20:22):
(To my mind, a "nice" implementation might be: locations where this patient has received care or locations otherwise mentioned by resources in this patient's compartment... but an "acceptable" implementation might be: no locations.)
Jenni Syed (Mar 03 2021 at 20:25):
the math to find all locations/orgs a patient has access to seems excessive. Do we know how any of the reference servers deal with this?
Jenni Syed (Mar 03 2021 at 20:25):
@Isaac Vetter or @Cooper Thompson how does Epic deal with this?
Jenni Syed (Mar 03 2021 at 20:25):
(note: inferno will also fail today if the location lookup fails when patient/Location.read has been issued)
Robert Scanlon (Mar 03 2021 at 20:54):
@Jenni Syed -- which test are you talking about specifically?
Alexander Zautke (Mar 03 2021 at 21:37):
Jenni Syed said:
the math to find all locations/orgs a patient has access to seems excessive. Do we know how any of the reference servers deal with this?
In Firely Server, we essentially treat patient/Location.read as a user/Location.read. We check the patient compartment definition and if the resource is outside of it, all resources are returned if the patient/user has access to the resource type.
Robert Scanlon (Mar 03 2021 at 21:51):
Jenni Syed said:
(note: inferno will also fail today if the location lookup fails when patient/Location.read has been issued)
I think I now realize what you meant. If you grant patient/Location.read but do not allow access to all location references that Inferno comes across in the 'Single Patient API' tests, then the test will fail (e.g. USCPROC-11: Every reference within Procedure resources can be read: Fail: location did not resolve: Server returned 401). This is intentional because a prerequisite of the test is a token that grants access to all resource types we know need to be supported/granted because of USCDI.
Jenni Syed (Mar 03 2021 at 22:27):
The one that fails for not seeing a specific patient/Location.read (seeing user/Location.read instead, or user/Practitioner.read, user/Organiztion.read) scope is SPB-OSLS-10. AVU-01 also will fail if not ll scopes are issues/the user scopes above are in place instead.
Jenni Syed (Mar 03 2021 at 22:27):
And then yes, those are the "per call" fails if we didn't issue user/Location.read and instead issued patient/Location.read
Jenni Syed (Mar 03 2021 at 22:27):
(same for Practitioner and Organization)
Josh Mandel (Mar 03 2021 at 22:31):
One way to reconcile app requests could be for Cerner, when an app requests patient/Location.read, to prompt the user about granting user/Location.read -- rather than requiring apps to ask for this "in just the right way". I expect you've already considered this though (and possibly are already doing this?) @Jenni Syed.
Robert Scanlon (Mar 03 2021 at 22:39):
We discussed this earlier in the thread, they are not currently doing this. I think this would be a great solution because it allows client developers to ask for what they want in the same way across all implementations, but allows the EHR to grant more than was asked (with user's permission) if they do not support that fine a level of granularity. My understanding is this is similar to how wildcard scopes can be handled for systems that do not want to grant a wildcard scope.
Robert Scanlon (Mar 03 2021 at 22:40):
Though, there are challenges with doing this as well, because it requires some more intelligence on the auth server side than may be supported out-of-the-box for 3rd party auth software.
Jenni Syed (Mar 04 2021 at 14:51):
Correct, that would require our auth server to be very specifically knowledgeable about the FHIR specification specifics. Also, we don't prompt all users (like practitioners) - so that's also an interupt to workflow that wouldn't be good. Again, the tests still fail in inferno if we did that because it doesn't like that we issued user/Location... instead of patient/...
Jenni Syed (Mar 04 2021 at 14:54):
We haven't had an issue with apps needing to get these scopes before, it's something that is obvious as soon as they start testing in our public sandbox since it fails fast (the FHIR server fails the request since it doesn't recognize those scopes/can't enforce them). They typically get the failure, and then update the app to request user/... instead
Jenni Syed (Mar 04 2021 at 14:55):
This is consistent with past conversations we've had around SMART for these issues
Josh Mandel (Mar 04 2021 at 16:50):
We haven't had an issue with apps needing to get these scopes before, it's something that is obvious as soon as they start testing in our public sandbox since it fails fast
just to be clear though, these are the kinds of "paper cuts" that add up for developers, they need to maintain exception files or other special case handlers describing different behaviors required to make each different server happy. I'm not saying this is terrible (these are small details to be sure); but it does add up and contribute to a perception that interoperability is weaker.
Jenni Syed (Mar 04 2021 at 16:56):
I think, before we did this, SMART would need to describe what should happen. Since we're dealing with things that have security effects, my goal has been making sure we only support enforceable things based on past discussions we've had. If an app, for example, thinks that patient/Location.read is going to do what was described above (limit to only locations the user has ever had access to) that is a huge difference both in describing consent to the user as well as what the app expects to happen
Jenni Syed (Mar 04 2021 at 16:57):
this is the same issue as the wildcard discussion :) The spec describes a behavior. It should be a behavior that is consistently enforced (and well understood)
Jenni Syed (Mar 04 2021 at 16:57):
having 2 different systems implement a scope 2 different ways is more impactful, I would think
Jenni Syed (Mar 04 2021 at 16:58):
And the "compartment" rule is what we've been using to determine if a patient/.. scope should be supported for a resource, since it can't be limited in that way. IE: if it's not in the patient compartment, the patient/... scope isn't enforceable as defined by SMART
Robert Scanlon (Mar 04 2021 at 16:59):
Jenni Syed said:
Again, the tests still fail in inferno if we did that because it doesn't like that we issued user/Location... instead of patient/...
Yes, the tests today set a higher bar (we ask for patient scopes for all USCDI-relevant resources, you grant us patient scopes for all USCDI-relevant resources). This would involve us changing the test to be a lower bar -- one of many potential lower bars. I'd be happy to put up a build that allows for this, but if it has other technical issues that make it a non-starter then it probably wouldn't be worth the effort.
Jenni Syed (Mar 04 2021 at 17:00):
We're reaching out to ONC for clarification on this. If they come back and say we still have to support this my next ask is going to be to clarify this in the SMART spec so we all have a good understanding of what's expected :/
Jenni Syed (Mar 04 2021 at 17:00):
we've already seen several possible behaviors described above :)
Robert Scanlon (Mar 04 2021 at 18:31):
Jenni Syed said:
We're reaching out to ONC for clarification on this. If they come back and say we still have to support this my next ask is going to be to clarify this in the SMART spec so we all have a good understanding of what's expected :/
Thanks @Jenni Syed -- I appreciate your help sorting this out. This one is a real pain because I recognize it is a paper-cut level issue for developers given where you have drawn the line. But it's not nothing, and I'm having trouble defining exactly what the minimum expectation here is for "permission-patient" and "permission-user". If there is no minimum expectation (e.g. you can just support patient/Patient.read and user/Patient.read and do whatever you want elsewhere), then I think other implementers are free to turn it into a more than a paper-cut level issue.
Robert Scanlon (Mar 04 2021 at 19:00):
I think it would be helpful to ONC if there was some kind of consensus in SMART community on what the accepted minimum expectation is. Maybe there is consensus there and I just missed it. Patient compartment for patient-level scope? Or is it just not possible to define a minimum expectation, and ONC needs to decide what they think it should be given the goal of their certification program (which could very well be no minimum expectation -- I don't know).
Robert Scanlon (Mar 04 2021 at 19:02):
Again, I appreciate the help.
Jenni Syed (Mar 04 2021 at 20:06):
I've always understood it as patient/... really only can apply to patient compartment resources
Jenni Syed (Mar 04 2021 at 20:06):
but yes, agree that SMART would need a stance
Jenni Syed (Apr 06 2021 at 22:23):
The CCG was updated today with the clarification here: https://www.healthit.gov/test-method/standardized-api-patient-and-population-services#ccg
Jenni Syed (Apr 06 2021 at 22:24):
For demonstration of the SMART IG "Standalone Launch" steps, health IT developers are permitted to scope US Core IG resources that do not exist in either the standard adopted at § 170.213 (USCDI version 1) or the "Compartment Patient" section of the standard adopted at § 170.215(a)(1) (HLY FHIR Release 4.0.1) as either patient/[Resource] or user/[Resource]. These resources include “Encounter,” “Device,” “Location,” “Medication,” “Organization,” “Practitioner,” and “PractitionerRole.” Health IT developers must document their supported scopes according to the technical documentation requirements at § 170.315(g)(10)(viii)(A) and § 170.404(a)(2).
Jenni Syed (Apr 06 2021 at 22:24):
This seems to be in line with allowing user/Practitioner.read and not patient/Practitioner.read (for example)
Jenni Syed (Apr 06 2021 at 22:25):
Same question as the other thread: do we know how long it might take to get inferno tests updated to account for this, knowing there are several changes likely that will come from this clarification.
Robert Scanlon (Apr 07 2021 at 13:00):
Yes, same answer as the other thread :). We'll only require demonstration of the intersection of patient compartment + USCDI-mapped resources under the patient scope, which means we'll allow user/Practioner.read, user/Location.read etc. It will be in our next release, which will be in a week or two.
Jenni Syed (Apr 07 2021 at 13:35):
Thanks for the help on this!
Last updated: Apr 12 2022 at 19:14 UTC
