Multi-tenancy role system

This chapter provides a role system that's suitable for an organization hosting a system that enables other organizations to provide care or providing a service for multiple customers. Examples are B2B2C systems such as providers of clinical study tools for multiple research hospitals or providers of outpatient services for hospitals and insurances.

The key criteria for this setup are that there is a single organization which has multiple organizations as customers, where each of the customer organizations provide care or related services to patients.

Role chart

Note: RootOrganization is an Organization and AdminRole is a PractitionerRole in the chart above. They have been given different names to improve visual clarity.

The setup is characterized as following:

• There is a single root Organization at the top (called RootOrganization in the chart) which represents the business itself.
• Each customer organization is also represented by an Organization resource.
• Each customer is linked to the root organization through the partOf property.
• Optionally, customer organizations can be partitioned further by creating department Organization entities that again link to the main customer Organization via the partOf property.
• Every patient user is represented by a Patient resource. Each patient's managingOrganization property points its corresponding care providing customer Organization.
• Every practitioner user is represented by a Practitioner resource. Every practitioner has at least one PractitionerRole at the customer Organization.
• Administrative staff working at the business and helping to run the entire system are represented as Practitioner resources in the system, having a PractitionerRole at the root organization (called AdminPractitioner and AdminRole in the chart)

Use of role codes

The use of role codes in PractitionerRole entities allows to establish different access privileges for different users. The code system in FHIR is bound to the Practitioner Role System which is based on SNOMED.

For the validation strategies below, the following values can be used:

• ict represents a technical user, someone who may add or remove Practitioner users but who must not be able to see patient data.
• doctor represents a medical user, someone who may access patient data but who must not be able to add or remove Patient users from the system.

Validation strategies

LegitimateInterest is the primary validator for this setup. The parameter role_inheritance_levels must be set to 1 or greater so that roles can be inherited from the root organization down to customer organizations:

config.json

{
    // ...
    "validators": {
        "legitimate_interest": {
            "role_inheritance_levels": 1
        }
    },
}

• For patients, each patient-specific resource can be validated using the PatientCompartment validator or LegitimateInterest, enabling every patient to access their own data but nothing else in the database.
• For practitioners, every resource can be validated using the LegitimateInterest validator, assuming that the resource is either tied to a Patient or to the Organization. Practitioners can see any resource in the database this way.
• Customer-specific admin users shall be given the ict role in their customer organization.
• Care-providing users shall be given the doctor role in their customer organization.
• Business-wide global admin users shall be given the ict role in the root organization.
• Do not assign a doctor role in the root organization to prevent users having global visibility to personal health data.