Organization Scoping
What multi-tenancy means for your app, and why you rarely think about it.
Palamond is multi-tenant: many organizations share one platform, and each patient's record belongs to exactly one organization. The API enforces this server-side; your app does not implement tenant isolation.
See Organizations for the model behind it.
The server is the boundary
Every call acts as the signed-in patient, and the platform's access policies scope it to their organization's compartment. A search cannot return another tenant's rows, and a workflow endpoint stamps everything it creates into the right compartment. Your app cannot cross the boundary, which also means you do not maintain it.
Two things remain yours:
- Home new registrations. A self-registered patient must be tied to their organization once, via
POST /v1/onboarding. See Authentication. - Do not invent tenancy. Never derive an organization from user input or a URL parameter, and never ask the user which clinic they belong to on a data screen. The session already knows.
Reading the active organization
When the UI needs it (a clinic name in the header, a support link), read it from the record:
import type { Organization } from '@palamond/sdk/fhir';
const [org] = await palamond.searchResources('Organization', { _count: '1' });The patient's compartment contains their own organization, so this returns the clinic they belong to.
If a search unexpectedly returns nothing, the answer is almost never "widen the query". Check that the patient is homed (POST /v1/onboarding ran) and that the session belongs to the patient you think it does (GET /v1/me).