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.

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_tokens 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.