Organizations

Palamond is multi-tenant. A single deployment serves many tenants, and each tenant is a FHIR Organization resource. Every clinical record belongs to exactly one organization, and that boundary is what keeps one tenant's patients out of another's view.

How data is partitioned

Every patient, and everything in that patient's record, is assigned to an Organization through the platform's account/compartment mechanism. A new patient's record is homed into its organization once, and every resource the platform creates for that patient inherits the assignment.

You never set the organization on anything. The workflow endpoints stamp tenancy server-side on everything they create, and the record plane only ever shows you the signed-in patient's own record, which lives entirely inside one tenant.

Enforcement is server-side

Every API call runs as a signed-in patient session, and the platform's access policies scope it to that patient's record inside their organization. A search cannot return another tenant's rows, and no request parameter can widen the view. This is the real security boundary, and it is enforced for you.

That leaves your app with exactly one tenancy job: home the patient once. A self-registered patient is tied to their organization with a single call to POST /v1/onboarding after registration. From then on, every call carries the right tenant implicitly.

Reading the patient's organization

When the UI needs the clinic (a name in the header, contact details, a support link), read it from the record like anything else:

import type { Organization } from '@palamond/sdk/fhir';

const [clinic] = await palamond.searchResources('Organization', { _count: '1' });

The patient's compartment contains their own organization, so this returns the clinic they belong to. Treat it as read-only context.

Next

• Organization Scoping - The short practical version for app code.
• Roles and Access - The access model behind the enforcement.