Consent and access model
Who sees what: project isolation, pairwise ids, grants, write ownership, provenance and what the patient sees about every application with access.
Rule: with the patient's consent an organisation sees the whole record — including what other clinics wrote — but can change or delete only what it wrote itself. Every version of every resource records the project that wrote it and the organisation on whose behalf it was written.
Who sees what
- A project (API key) sees the patients it created. Under a grant (OAuth token) an application sees exactly one patient, across all writers, limited to the granted scopes and category filters. Everything else returns 404, never 403, so ids cannot be probed.
- Pairwise ids: each project receives its own id for the same person; internal ids never leave the platform. References to patients outside your scope are masked with an opaque, per-project token.
- Directory (Organization, Practitioner, PractitionerRole): readable by id across the plane so references resolve; searchable only within your project; usable as
X-Anpheros-Acting-As/X-Anpheros-On-Behalf-Ofonly when yours. - Sandbox and production are different databases. A sandbox key physically cannot reach real patients.
Writes and ownership
project_idon every resource version = the writer. Update/delete by another project → 403 with an explanation; write your own resource instead.Provenance.agent.onBehalfOf= the clinic/organisation at the time of writing:X-Anpheros-On-Behalf-Of, else the acting PractitionerRole's organisation, else the project's organisation.- Every write produces a Provenance resource and an audit row (who, what, when, under which grant, which application, from which source fingerprint).
What the patient sees
/me/patients/{id}/grants lists every application with access, its scopes and expiry; …/access-log lists what each read or wrote — under the consent and with the project's own key. Revocation takes effect on the next request; the application cannot refresh back in.