The article explains Smartbox approach for multitenancy
Smartbox is distributed as an aidbox configuration project on top of Aidbox. It follows Aidbox multitenancy approach on API constructor.
All data is stored in one Postgres database. Multitenancy is achived by Smartbox on couple of levels:
- on API level Smartbox introduced a FHIR API for every tenant, and
- on data level Aidbox expects every tenant resource is marked with tenant reference.
Smartbox introduced Tenant resource in Aidbox. By creating a Tenant resource you enable FHIR APIs with SMART on FHIR support for patients and providers.
name: My Clinic
You may be confused as you don't see Tenant resource on entities page in Aidbox Console. It happens because Tenant resource is defined in aidbox configuration project within zen-lang. You may follow profiles page and find Tenant resource definition in
Once you created Tenant resource, FHIR API, a dedicated authorization server with SMART on FHIR support and patient portal were enabled for the the tenant.
Patient portal is available on
Patient portal provides to patient an ability
- to authorize access to their EHI data for external SMART apps and revoke the access
- change and reset their password.
Read more about user registration in Smartbox. (link here)
FHIR API for patient-facing SMART apps is avaiable on
Patient doesn't have direct access to that API, but only via SMART apps, authorized by the patient.
Authorization server is available on
Why is there dedicated auth server for every tenant? If a person is a patient in two different clinics they should be able to be logged into both patient portals independently. Otherwise it may cause undesirable behaviour when patient wants to launch a SMART app and share their data from both clinics.
FHIR API for provider-facing SMART apps is avaiable on
Provider doesn't have direct access to that API, but only via SMART apps, authorized by the provider.
Authorization server for patients is available on
Bulk API is available on