Stream: implementers
Topic: Multi-Tenant FHIR Server
Joe Paquette (Nov 07 2019 at 18:22):
We are looking to build a FHIR server facade in front of an existing multi-tenant system. Clients will be given access to 1 or more tenants to be enforced by standard authorization. When a client wants to create a data object (i.e., a specific FHIR resource), we need the client to provide the desired TenantID to properly insert the new data.
Is there a recommended approach for providing this TenantID?
We also expect to allow searching across tenants to which they have access. This implies that the TenantID probably needs to reside within the resource.
One thought is to include it as an Identifier. Another is to include it as an Extension in the modifierExtension field (because they are Extensions that cannot be ignored).
Thoughts, ideas, recommendations...
Thanks
Grahame Grieve (Nov 07 2019 at 20:08):
it seems from your description that you anticipate that the client must know about the multi-tenancy and you depend on it acting correctly in order to enforce proper system behavior?
John Moehrke (Nov 07 2019 at 20:22):
why would a client want to choose the TenantID? This seems to indicate that the client is aware of the backend architecture. If so, then why not just address the backend like one would a multi-tenant system? Each service has their own http root that they build upon. The tenantID is built into the URL root.
What I am confused by is the facade function if the clients need to know tenantID anyway.
Grahame Grieve (Nov 07 2019 at 20:27):
search across the the tenants... but presumably the tenant cannot be inferred from the context... so the client must know, and generic clients need not apply. If I've read it right, the least worst option is a header functionally like the host: http header
Joe Paquette (Nov 07 2019 at 21:02):
Yes, the client will always know the TenantIds (1 or more) to which they have access and will need to "pass in" the desired specific TenantId to the REST API calls. Embedding the TenantId in the "base" URL would work except for the scenario where we want to search across multiple tenants.
Gino Canessa (Nov 07 2019 at 21:18):
I would tie the tenant to the user (e.g., a claim in a token) so that tenants cannot trivially see across boundaries. If you have access to multiple tenants, it could ask as part of the auth process which one(s) you want access to.
Josh Mandel (Nov 08 2019 at 02:14):
Do you allow resource references, search, _include, etc across tenants? If so, I am not sure what isolation the tenancy provides. And if not, you might consider making the different tenants visible at different FHIR base URLs.
Joe Paquette (Nov 08 2019 at 14:37):
We already include the TenantIDs (1 or more) a user has access to as claims in the auth token to prevent crossing the tenant boundaries. The question is about a case where a user has access to multiple TenantIDs but wants to access specific FHIR endpoints for a single specific tenant. Adding the TenantID in the URL will work in this case but not when I want to search across a subset of Tenants that I have access to (e.g., I have access to TenantIds 1,2,3,4,5 but want to search across TenantIds 2,3,4). To do that search, I need to use an appropriate query parameter.
My understanding is that the query parameter must reference some data element in the resource; hence, my original question. Maybe a better question is can I document (capability statement) the use of a specific query parameter that the endpoint will always understand (TenantID(s)) but does not represent an actual data element within the resource?
Courtenay Farquharson (Nov 11 2019 at 03:52):
Curious as to what the thoughts might be here so far.
I think best case is the claims define the locations you have access to (as you alluded to) and any Id's should then take location into account to ensure uniqueness. Any request to a resource (eg. /Patient) should really search across locations and be seamless to the client.
This doesn't help for writing though.
Michael Lawley (Nov 11 2019 at 23:20):
Are the different TenantIds related to any real-world constructs? Locations, etc? Or are they purely a technical architecture thing? I ask because this (clients knowing about tenant ids) sounds like a leaky abstraction.
Grahame Grieve (Nov 12 2019 at 02:05):
all abstractions are leaky but only some leaks are useful
Michael Lawley (Nov 13 2019 at 01:48):
If it's a leak, I'm looking for the source, but it could always be a (water) feature
Last updated: Apr 12 2022 at 19:14 UTC
