Multitenancy Design Proposal

Goal

This page attempts to document the initial design for a scalable multitenancy strategy. This strategy will have several goals:

• It can be used to provide logical secure segregation of data (i.e. user performs a search for "find all patients in tenant 123 with name = 'smith'", they should receive only results that actually belong to this tenant
• It can be used to create logical partitions of data for partition-based archiving. Note in this scenario, some prep work may be required to resolve resource references into the archived partition before the partition is removed.

The following tables are all related to an individual resource instance in the database:

• HFJ_RESOURCE
• HFJ_RES_VER
• HFJ_RES_TAG
• HFJ_FORCED_ID
• HFJ_IDX_CMP_STRING_UNIQ
• HFJ_SPIDX_COORDS
• HFJ_SPIDX_DATE
• HFJ_SPIDX_NUMBER
• HFJ_SPIDX_QUANTITY
• HFJ_SPIDX_STRING
• HFJ_SPIDX_TOKEN
• HFJ_SPIDX_URI

Proposed Design

Each of these tables would add a new Integer discriminator column called "tenant". hapi-fhir clients can populate this column by setting resource.setUserData("TENANT", value) in a PRESTORAGE interceptor. When persisting all the records associated with that resource, hapi-fhir will set the TENANT to this value from the populated userData. If no TENANT is provided, hapi-fhir will default the value to 0.