Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card

Sicherheit, Datenschutz und Datenresidenz

Wie Patientendaten geschützt werden: EU-Datenresidenz, Projektisolation, paarweise IDs, Anmeldeinformationen, Zustimmung, Herkunft, ein für den Patienten sichtbares Audit und die Grenzen der privaten Beta.

Medizinische Daten sind die sensibelsten Daten, die eine Anwendung enthalten kann. Diese Seite listet auf, wie die Anpheros Platform diese heute schützt – nur das, was implementiert ist – und was während der privaten Beta noch eingeschränkt ist.

Datenspeicherung

Alle Plattformdaten werden in der Europäischen Union gespeichert und verarbeitet: der Dienst und seine Datenbanken in Google Cloud europe-west4 (Niederlande), die Warteschlange für Webhook-Zustellungen in europe-west3 (Frankfurt) und der unveränderliche Export des Zugriffsprotokolls am BigQuery EU-Standort.
US-Datenregion: Auf Anfrage für Produktionskunden unter einer HIPAA Business Associate Agreement (siehe unten) verfügbar; US-Patientendaten verlassen dann niemals die US-Region.
Dokumente werden in einem EU-Speicher-Bucket gespeichert, der mit einem kundenseitig verwalteten Verschlüsselungsschlüssel (CMEK) verschlüsselt ist. Originale sind nach der Finalisierung unveränderlich; ihre SHA-256-Prüfsumme und Größe werden aufgezeichnet.

Isolation zwischen Anwendungen

Jeder API-Schlüssel gehört zu einem Projekt. Ein Projekt sieht nur die Patienten, die es erstellt hat – in der Sandbox, einschließlich seiner eigenen Kopie synthetischer Patienten, die kein anderes Projekt sehen kann.
Paarweise Identifikatoren: Jedes Projekt erhält seine eigene ID für dieselbe Person; interne IDs verlassen niemals die Plattform, sodass IDs nicht zwischen Anwendungen korreliert werden können.
Ein Datensatz, den Sie nicht erreichen können, antwortet mit 404, niemals mit 403, sodass die Existenz eines Patienten nicht abgefragt werden kann.
Sandbox und Produktion sind getrennte Datenbanken. Ein Sandbox-Schlüssel (sk_test_) kann physisch keine echten Patienten erreichen.
Mit der Zustimmung des Patienten liest eine Organisation den gesamten Datensatz, einschließlich dessen, was andere Organisationen geschrieben haben, kann aber nur ändern oder löschen, was sie selbst geschrieben hat.

Anmeldeinformationen

API-Schlüssel werden einmal angezeigt und nur als SHA-256-Hash gespeichert. Schlüssel haben read / write Scopes und überschreiten niemals ihre Umgebung.
OAuth 2.1 mit obligatorischem PKCE (S256); die redirect_uri muss exakt registriert werden. Zugriffstoken sind 30 Minuten gültig, Refresh-Token 30 Tage und rotieren bei jeder Verwendung.
Erkennung von Refresh-Token-Wiederverwendung: Die Präsentation eines bereits verwendeten Refresh-Tokens widerruft die gesamte Token-Kette.
Token-Antworten enthalten Cache-Control: no-store. OpenID Connect id_tokens werden mit RS256 signiert; öffentliche Schlüssel werden unter /oauth/jwks veröffentlicht.

Zustimmung, Herkunft und Audit

Ein Patient erteilt einer Anwendung auf einer gehosteten Einwilligungsseite Zugriff und wählt den Datensatz und die Dauer (30, 90, 180 oder 365 Tage). Scopes sind pro Ressourcentyp und Aktion, optional gefiltert nach Kategorie. Jede Erteilung wird als FHIR Consent Ressource gespiegelt.
Der Widerruf wird bei der nächsten Anfrage wirksam; die Anwendung kann sich nicht erneut anmelden.
Jeder Schreibvorgang erzeugt eine Provenance Ressource: wer ihn durchgeführt hat (Patient, Praktiker, Gerät, Import oder KI), für welche Organisation, aus welchem Quellsystem.
Jeder Lesevorgang wird protokolliert und ist für den Patienten sichtbar, einschließlich Lesevorgängen, die mit einem eigenen API-Schlüssel eines Projekts durchgeführt wurden, und einschließlich des für KI-Modelle erstellten Kontexts.

Transport- und Websicherheit

Nur HTTPS, mit HTTP Strict Transport Security. API-Antworten enthalten eine restriktive Content-Security-Policy, X-Content-Type-Options: nosniff, X-Frame-Options: DENY und eine strikte Referrer-Policy.
Webhook-Lieferungen werden mit HMAC-SHA256 über den Zeitstempel und den Body signiert; Empfänger sollten Signaturen ablehnen, die älter als 5 Minuten sind. Events enthalten IDs und Versionen, niemals klinische Inhalte.
Ratenbegrenzungen: 600 Anfragen pro Minute pro Anmeldeinformation und pro IP; JSON-Bodies bis zu 2 MiB; Dokumente bis zu 25 MiB.

Suchmaschinen und KI-Crawler

Öffentliche Seiten (anpheros.com, die Plattformpräsentation und diese Dokumentation) sind für Suchmaschinen und KI-Crawler zugänglich. Die API, das Dashboard, die OAuth- und Consent-Seiten sowie die Patienten-App (app.anpheros.com) sind mit den Regeln noindex und robots.txt ausgeschlossen; keine von ihnen gibt Patientendaten ohne Authentifizierung zurück.

HIPAA (US-Kliniken)

Für eine Klinik in den Vereinigten Staaten ist Anpheros ein Business Associate. Was im Einklang mit der HIPAA Security Rule umgesetzt ist:

Safeguard	Wie Anpheros es umsetzt
Zugewiesene Verantwortung, Risikoanalyse, schriftliche Richtlinien (§164.308)	Ein benannter Security Officer; eine jährliche Risikoanalyse; zehn schriftliche Richtlinien (Zugriff, Verschlüsselung, Protokollierung, Incident Response, Benachrichtigung bei Datenschutzverletzungen, Aufbewahrung und Backup, Schulung, Geräte, Notfallzugriff, Anbieter), sechs Jahre aufbewahrt
Eindeutige Benutzeridentifizierung, Zugriffskontrolle (§164.312(a))	Jeder Schlüssel, jedes Token und jede Person hat eine eigene Identität; Projekte sehen nur ihre eigenen Patienten; Zustimmungsumfänge werden bei jedem Lesevorgang durchgesetzt; MFA oder SSO ist für Organisationen mit einem Produktionsprojekt erforderlich; automatische Abmeldung im Dashboard
Audit-Kontrollen (§164.312(b))	Jeder Lese- und Schreibvorgang wird protokolliert, hash-verkettet, append-only exportiert; für den Patienten sichtbar
Integrität (§164.312(c))	Versionierte Ressourcen, Provenienz bei jedem Schreibvorgang, unveränderliche Dokumente mit SHA-256
Übertragungssicherheit (§164.312(e))	TLS 1.2+, HSTS, signierte Webhooks, HTTPS-only-Lieferungen
Verschlüsselung im Ruhezustand	Datenbank und Backups verschlüsselt; Dokumente unter einem kundenseitig verwalteten Schlüssel
Notfallplan (§164.308(a)(7))	Tägliche Backups, Point-in-Time-Recovery, Wiederherstellungsübung alle 90 Tage mit aufgezeichneten Zeiten
Benachrichtigung bei Datenschutzverletzungen (§164.410)	Die Covered Entity wird innerhalb von 5 Werktagen durch unseren BAA benachrichtigt (60 Tage gesetzlich)
Business Associate Chain (§164.308(b))	Google Cloud unter seinem BAA; die Liste der Subprozessoren befindet sich im Anhang des BAA

Ein Business Associate Agreement und eine US-Datenregion sind auf Anfrage für Produktionskunden verfügbar (schreiben Sie an [email protected]); die Produktion für US-Patientendaten wird nach Unterzeichnung des BAA freigeschaltet. Die Sandbox enthält nur synthetische Patienten, sodass Entwickler in den USA noch heute ohne BAA entwickeln können. Anpheros ist nicht nach SOC 2 oder HITRUST zertifiziert; ein SOC 2 Type II Audit ist geplant, wenn ein Krankenhauskunde dies wünscht.

Aktuelle Limits (private Beta)

Single-Zone-Hosting ohne automatische Failover; noch kein vertraglicher SLA.
Produktionsschlüssel werden an verifizierte Organisationen mit einem unterzeichneten Datenverarbeitungsvertrag ausgestellt; Beta-Partner starten mit synthetischen Daten.
SMART EHR-Start und der OpenID nonce-Parameter werden noch nicht unterstützt.