# Security, privacy and data residency

> How patient data is protected: EU data residency, project isolation, pairwise ids, credentials, consent, provenance, an audit visible to the patient, and the limits of the private beta.

Source: https://developers.anpheros.com/guides/security

Medical data is the most sensitive data an application can hold. This page lists how Anpheros Platform protects it today — only what is implemented — and what is still limited during the private beta.

## Data residency

- All platform data is stored and processed in the European Union: the service and its databases in Google Cloud `europe-west4` (Netherlands), the webhook delivery queue in `europe-west3` (Frankfurt) and the append-only export of the access log in the BigQuery EU location.
- Documents are stored in an EU storage bucket encrypted with a customer-managed encryption key (CMEK). Originals are immutable after finalisation; their SHA-256 checksum and size are recorded.

## Isolation between applications

- Every API key belongs to one **project**. A project sees only the patients it created — in the sandbox, including its own copy of synthetic patients, which no other project can see.
- **Pairwise identifiers:** each project receives its own id for the same person; internal ids never leave the platform, so ids cannot be correlated between applications.
- A record you cannot reach answers `404`, never `403`, so the existence of a patient cannot be probed.
- **Sandbox and production are separate databases.** A sandbox key (`sk_test_`) physically cannot reach real patients.
- With the patient's consent an organisation reads the whole record, including what other organisations wrote, but can change or delete only what it wrote itself.

## Credentials

- API keys are shown once and stored only as a SHA-256 hash. Keys have `read` / `write` scopes and never cross their environment.
- OAuth 2.1 with mandatory PKCE (S256); the `redirect_uri` must be registered exactly. Access tokens last 30 minutes, refresh tokens 30 days and rotate on every use.
- **Refresh-token reuse detection:** presenting a refresh token that was already used revokes the whole token chain.
- Token responses carry `Cache-Control: no-store`. OpenID Connect `id_token`s are signed with RS256; public keys are published at `/oauth/jwks`.

## Consent, provenance and audit

- A patient grants an application access on a hosted consent page, choosing the record and the duration (30, 90, 180 or 365 days). Scopes are per resource type and action, optionally filtered by category. Every grant is mirrored as a FHIR `Consent` resource.
- Revocation takes effect on the next request; the application cannot refresh back in.
- **Every write** produces a `Provenance` resource: who wrote it (patient, practitioner, device, import or AI), for which organisation, from which source system.
- **Every read is logged and visible to the patient**, including reads made with a project's own API key, and including context built for AI models.

## Transport and web security

- HTTPS only, with HTTP Strict Transport Security. API responses carry a restrictive Content-Security-Policy, `X-Content-Type-Options: nosniff`, `X-Frame-Options: DENY` and a strict referrer policy.
- Webhook deliveries are signed with HMAC-SHA256 over the timestamp and body; receivers should reject signatures older than 5 minutes. Events carry ids and versions, never clinical content.
- Rate limits: 600 requests per minute per credential and per IP; JSON bodies up to 2 MiB; documents up to 25 MiB.

## Search engines and AI crawlers

Public pages (anpheros.com, the platform presentation and this documentation) are open to search engines and AI crawlers. The API, the dashboard, the OAuth and consent pages and the patient app (`app.anpheros.com`) are excluded with `noindex` and `robots.txt` rules; none of them return patient data without authentication.

## Current limits (private beta)

- Single-zone hosting without automatic failover; no contractual SLA yet.
- Production keys are issued to verified organisations with a signed data processing agreement; beta partners start with synthetic data.
- SMART EHR launch and the OpenID `nonce` parameter are not supported yet.

## Related

- [Consent and access model](https://developers.anpheros.com/guides/consent)
- [Authentication and OAuth](https://developers.anpheros.com/guides/authentication)
- [Limits and rate limits](https://developers.anpheros.com/guides/limits)
- [Architecture](https://developers.anpheros.com/guides/architecture)