Stream: implementers
Topic: Combine chaining and reverse chaining in a search
Abel Enthoven (Nov 30 2021 at 14:24):
I would like to get all Observations belonging to Patients who are members of a Group. My initial thought was to use a combination of chaining and reverse chaining, like GET /Observation?subject:Patient:_has:Group:member:identifier=X. The server does not accept this, but should it be a valid query? If not, what would be a way to achive this?
Lloyd McKenzie (Nov 30 2021 at 14:26):
It may well be a valid query. That doesn't necessarily mean a server will support it. You need to look at the server's CapabilityStatement to understand what includes and revIncludes it can handle.
Abel Enthoven (Nov 30 2021 at 14:30):
Sorry, let me offer some context. To get what I described I could indeed start from /Patient and simply include the observations, using _has as a group filter. I would, however, like to use the above query (so with 'Observation' as the root) to construct a SMART v2 scope, like: system/Observation.rs?subject:Patient:_has:Group:member:identifier=X
John Moehrke (Nov 30 2021 at 14:34):
the SMART v2 scopes are just requests for an authorization token. Theory is that if you get that authorization scope, then you could ask for everything at the FHIR endpoint and the server would filter out everything that you are NOT authorized... This theory will run up against reality quickly. This is not likely to be supported by the authorization server or the resource server, as it is both a very complex authorization scope, and an unusual use of complex authorization scopes to result in a stateful search.
Theory - Yes.
Reality - Nope!
Alexander Zautke (Nov 30 2021 at 14:51):
GET /Observation?subject:Patient._has:Group:member:identifier=X should be the correct syntax. The chained parameter needs to be separated with a ".".
Alexander Zautke (Nov 30 2021 at 14:55):
I think SMART v2 enabled a new category of issues here. If your resource server does not know anything about users / systems and what they are allowed to access (i.e. most FHIR-native reference implementations), it becomes tempting to move this complexity by trying to express more complex scopes.
John Moehrke (Nov 30 2021 at 15:00):
An authorization server needs to be smart enough to not issue tokens that the resource server can't enforce.
Alexander Zautke (Nov 30 2021 at 15:15):
Some implementation tend to enforce only a patient level scope in combination with a patient claim in the token. If you have a user-level scope you could still enforce the Observation query listed above, but it wouldn't know what Observations belong to the user. That's why a simple scope might not be enough.
I fully agree that the resource server should filter it out.
Alexander Zautke (Nov 30 2021 at 15:16):
In the case above I could only imagine that the Group resource replaces the concept of "What is the user allowed to see".
Alexander Zautke (Nov 30 2021 at 15:17):
My point was just that this type of request is now only possible due to the new token syntax.
Josh Mandel (Nov 30 2021 at 15:24):
Agree with the point here that just because the syntax of the scope language allows, it does not mean anyone should expect every expression to work in real life. I expect a few hardcoded expressions to be supported in the context of US core, for example, to allow for access to vital signs versus lab results.
Abel Enthoven (Nov 30 2021 at 17:20):
Thanks for all your answers! And I agree with you guys that it is not to be expected that a server could apply these scopes. As @Alexander Zautke mentions, it is indeed a reference implementation I'm dealing with, which can not enforce user level scopes. Currently I know of no other way to restrict a user's access than by including narrow scopes in the token or by creating a server plugin of some kind
Last updated: Apr 12 2022 at 19:14 UTC
