Hi all I'm evaluating medplum for a multi tenanted platform. There will be at least one web UI and later a mobile app, possibly some other services/servers later. If I've understood correctly the tenancy approach for multiple unrelated practices (tenants) is to use a project per tenant. Following documentation it appears that each new tenant must be issued a project having it's own copies of - ClientApplication for the web client - AccessPolicies for each role - OperationDefinitions for each bot On monorepo deployment via CICD pipeline we then have to: - run a migration script to maintain the template project that is cloned to create a new project/tenant - run a migration script to iterate over each existing project to maintain ClientApplication(s), AccessPolicies and OperationDefinitions Is that correct? At present the business has decided that: - each tenant logs in via their own subdomain - users must reauthenticate when switching tenant, and this is done only by navigating to the tenant's subdomain - no data crosses tenant boundaries, thus a user may be 'logged in' as 1 discrete tenant's Patient or tenant's Practitioner at a time. In effect I could be a surgeon with a Practitioner resource 'Dr Me' at the 'Sydney Gastro Clinic' Organization and a separate Practitioner 'Dr Me' at the 'Inner West GutsBGood' Organization, and I should not be able to see or write to Sydney Gastro Clinic's Patients when I have authenticated via gutsbgood.whatever.com

@sia No you should probably use orgs instead for multi tenancy , as for same doctor with diff id you can enforce it easily . Im a dev/ doc using medplum too . using a project instead introduces too much overhead but better separation . They have talked about this extensively in their blog as well . Using a org does require application side enforcement which should be doable .

To shard's point, we typically use projects for completely separate apps or different environments for the same app (ie staging/prod) and use a strategy below for multi-tenancy (which does allow for complete separation of all resources). https://www.medplum.com/docs/access/multi-tenant-access-policy

I'm really worried about misconfiguration and phi leak , the last time i wen through source it was well done and i ended up not using projects. I never realised i can use projects to make a staging env , thanks for this idea . When a new project is created we will receive a new secret and super user id right equalent to spinning up a new medplum server?

the system's conventions around users & compartmentalisation threw me off. An underlying assumption of the architecture appears to be that users are global & that a user with N practitioners & M organisations will be able to see a unified view of everything they're authorised to see all in one place. This is a reasonable capability but my client's requirement is that a tenant & it's users. must have complete separation between it's records & other tenants records that those users may have access to. Happily I discovered that a single user may have an arbitrary number of ProjectMemberships with arbirary organisation access. On that basis I believe that it's' possible to go 1 project, N orgs and have a login & client hard scoped to that org.. So I'm pursuing that approach now.

I initially started with the same idea of a single practioner multiple orgs and single patient multiple orgs only to realise thats not what my hospitals would want and had to change the whole architecture around that . Im glad you figured it out early . Can i ask you how you will be storing non patient data that may not be best suited for medplum or things medplum isnt really meant for

We haven't gotten that far to be honest, still in the risk identification phase of the project. I am concerned with the leakiness of the abstraction. It reminds me a lot of Hasura, which effectively makes one projection of the data 'the center of the world'. On one hand it wants to be everything, and if I let it be everything then it'll take care of access, audit, versioning, cohesion. But on the other hand it's put the specific data model implementation forward of the domain.... it's hard to know what the ideal thing to do is. If we pick medplum then it's likely that we'll try to use it maximally, but for stuff that doesn't fit well into a 'document store on postgres' pattern we'll have to work something out. Possibly a trpc server alongside it, or maybe the medplum bots are the only interface, the resource type is used for namespacing and the bot operations deal with a separate database. Not sure yet

I'll have to collect my thoughts , i have been building on top of medplum for the past year now as a solo dev doc basically in India , i will reply when i do

No worries

your replies have been really insightful to me

I have understood that medplum already does this 2 tier data management for Binary files, a metadata record in medplum & the actual data in a blob store, which can be thought of as a type of simple key value store. So I don't think it's a controversial approach.

@sia , are you planning to roll this out hosting Medplum yourself? You definitely have more flexibility in the tenancy approach if you do. If you are planning to host use Medplum hosted, then you would want to follow the advice above and use a Multi-tenant access policy within a single project. If you are hosting yourself, you will want to consider the trade-offs of project level data isolation with the costs of your CI/CD implementation and management of your per project configurations.

@Ian Plunkett it's not 100% clear yet, we are comfortable handling either scenario. I think it's decided at this point that we will not be going project per tenant, this is the wrong approach for sure. I'm fairly certain that we will go with global User +--< (ProjectMembership +-+ Practitioner/Patient +-+ AccessPolicy) >-+ Organisation. I have floated Medplum hosting with our team, we'll investigate further & take to the client. I think for the early phases of the project it may be the preference, we can always migrate out if necessary.