Stream: implementers
Topic: Filtering approaches for FHIR Search
Cooper Thompson (Dec 02 2021 at 19:27):
I've recently run across an interesting FHIR search design, and I'm interested if folks have opinions on this.
Normally, when I think of searching for a patient's allergies, I think of something like this (I'm assuming an OAuth2 auth layer):
Option A:
GET /AllergyInterance?patient=<patient ID>
Authorization: Bearer <access token>
With this approach, you first find the allergies for the patient, then apply any authorization rules (based on claims associated with the access token) that may further limit the results.
However, this is something that was proposed as an alternative:
Option B:
GET /AllergyInterance
Authorization: Bearer <JWT access token with a claim identifying the patient via a business identifier>
This approach uses a server wide search, and relies on authorization rules to filter data for the patient. Here, the server has two options for handling the search:
- Find all allergies in the system, then use authorization rules associated with the token to filter down to just the allergies that are authorized.
- Pre-process the access token claims to determine the patient, then find allergies for that patient. Then apply authorization rules.
Assuming that authorization rules are defined and applied correctly, the results returned for both Option A and Option B queries should be identical. The Alissa Knight report makes me nervous here, but really BOLA issues probably have similar impact for all options. The performance for B1 and B2 may be very different, but performance for B2 should be similar to A.
The context here is a patient-facing app (PHR) ecosystem. The reason this second option is being proposed is because the authorization server is not aware of the patient FHIR ID at the time the authorization flow occurs.
I have two questions:
- Do folks have any general opinions about doing the system-wide search and relying on access token based authorization filtering to limit the response to data about a specific patient?
- For other server implementers that have both a SMART auth server and FHIR API server, how do you manage the FHIR patient ID such that you can return it as the "patient" context parameter alongside the access token in the /token response? Epic's authorization and API servers are very tightly coupled, so we "just have it". But if anyone has an authorization server that is decoupled from the API server, it seems like you'd need to have something in place to populate the SMART patient context param with the FHIR ID from your API server at the time you issue access tokens.
Grahame Grieve (Dec 02 2021 at 19:57):
in my system, I inspect the token before performing any search to decide what the compartment limitations associated with it are - if any - and restrict search results accordingly. So it's kind of a bit of half way between your approaches
Grahame Grieve (Dec 02 2021 at 19:58):
like your system, my resource server and authorization server are tightly bound, so the authorization server asks the user to agree to a scope (though they may be constrained in their choices) when they go through the OAuth process, and the scopes are informed by the resources available
Grahame Grieve (Dec 02 2021 at 19:58):
Smart App Launch says that the details of this are a private negotiation between resource and authorization server
Grahame Grieve (Dec 02 2021 at 19:59):
the Heart/UMA specs standardise this interface (and do other things too) so you should look at what that does
Jens Villadsen (Dec 02 2021 at 19:59):
same here (as Grahame's setup)
Paul Church (Dec 02 2021 at 20:26):
The Google implementation is pretty similar to Grahame's setup. Our reference configuration is one where all access using SMART auth goes through a proxy that ensures the requests reach the resource server with a SMART patient context. The resource server limits the search to the specified patient context. I don't think we have a pattern yet where the OAuth scopes available are directly informed by the resources on the server - we assume that the auth server knows those patient IDs out of band.
Last updated: Apr 12 2022 at 19:14 UTC
