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

Einwilligung und Zugriffsmodell

Wer sieht was: Projektisolation, paarweise IDs, Berechtigungen, Schreibrechte, Herkunftsnachweis und was der Patient über jede Anwendung mit Zugriff sieht.

Regel: Mit Zustimmung des Patienten sieht eine Organisation den gesamten Datensatz – einschließlich dessen, was andere Kliniken geschrieben haben –, kann aber nur ändern oder löschen, was sie selbst geschrieben hat. Jede Version jeder Ressource zeichnet das Projekt auf, das sie geschrieben hat, und die Organisation, in deren Auftrag sie geschrieben wurde.

Wer sieht was

• Ein Projekt (API-Schlüssel) sieht die von ihm erstellten Patienten. Unter einer Berechtigung (OAuth-Token) sieht eine Anwendung genau einen Patienten, über alle Schreiber hinweg, beschränkt auf die gewährten Scopes und Kategorie-Filter. Alles andere gibt 404 zurück, niemals 403, sodass IDs nicht abgefragt werden können.
• Paarweise IDs: Jedes Projekt erhält seine eigene ID für dieselbe Person; interne IDs verlassen niemals die Plattform. Referenzen auf Patienten außerhalb Ihres Scopes werden mit einem undurchsichtigen, projektspezifischen Token maskiert.
• Verzeichnis (Organization, Practitioner, PractitionerRole): lesbar per ID über die gesamte Ebene hinweg, damit Referenzen aufgelöst werden können; nur innerhalb Ihres Projekts durchsuchbar; verwendbar als X-Anpheros-Acting-As / X-Anpheros-On-Behalf-Of nur, wenn es Ihre sind.
• Sandbox und Produktion sind unterschiedliche Datenbanken. Ein Sandbox-Schlüssel kann physisch keine echten Patienten erreichen.

Schreibrechte und Eigentümerschaft

• project_id bei jeder Ressourcenversion = der Schreiber. Update/Delete durch ein anderes Projekt → 403 mit Erklärung; schreiben Sie Ihre eigene Ressource stattdessen.
• Provenance.agent.onBehalfOf = die Klinik/Organisation zum Zeitpunkt des Schreibens: X-Anpheros-On-Behalf-Of, andernfalls die Organisation der handelnden PractitionerRole, andernfalls die Organisation des Projekts.
• Jeder Schreibvorgang erzeugt eine Provenance-Ressource und eine Audit-Zeile (wer, was, wann, unter welcher Berechtigung, welche Anwendung, von welchem Quell-Fingerabdruck).

Was der Patient sieht

/me/patients/{id}/grants listet jede Anwendung mit Zugriff auf, deren Scopes und Ablaufdatum; …/access-log listet auf, was jede Anwendung gelesen oder geschrieben hat – unter der Zustimmung und mit dem eigenen Schlüssel des Projekts. Der Widerruf wird bei der nächsten Anfrage wirksam; die Anwendung kann sich nicht erneut authentifizieren. Mit format=fhir wird das Zugriffsprotokoll als Bundle von FHIR R4 AuditEvent Ressourcen zurückgegeben, geformt nach IHE Basic Audit Log Patterns (Typ rest, die Interaktion als Subtyp, die Anwendung und die Person, die durch sie handelt, als Agenten, der Patient und die Ressource als Entitäten, keine klinischen Daten), sodass ein anderes System es in die Ansicht der Person integrieren kann, wer auf ihre Aufzeichnungen zugegriffen hat.

Was jede Provenance-Ressource aufzeichnet und wie man sie einstellt: Erklärung der Provenienz von medizinischen Daten.

SMART Health Links (Teilen per QR oder Link)

Eine Person kann ihren Datensatz ohne eine zwischengeschaltete Anwendung teilen: POST /me/patients/{id}/shl erstellt einen SMART Health Link für die Notfall-Untermenge (Allergien, Medikamente, Probleme, Impfungen – keine Ergebnisse oder Historie) oder die vollständige International Patient Summary, mit einem optionalen Passwort und Ablaufdatum. Die Antwort enthält die shlink:/… URI (für einen QR-Code) und eine Betrachteradresse auf /shl/view, die sie in jedem Browser öffnet. Wer ihn scannt, postet an die Manifest-URL und erhält die Zusammenfassung als JWE (dir + A256GCM), verschlüsselt mit dem Schlüssel im Link; jeder SMART Health Link Reader funktioniert.

• Der Inhalt wird bei jeder Öffnung generiert (Flag L, Status can-change), sodass eine auf dem Telefon gespeicherte Karte aktuell bleibt.
• Ein Passwort (Flag P) wird auf dem Server geprüft; nach 10 falschen Versuchen funktioniert der Link nicht mehr.
• GET /me/patients/{id}/shl listet die Links mit der Häufigkeit und dem Zeitpunkt ihrer Öffnung auf; …/shl/{link}/revoke schaltet einen Link sofort aus. Jede Öffnung wird im Zugriffslog erfasst.
• Die interne ID der Person verlässt niemals die Plattform: Das Dokument benennt sie mit einem Pseudonym des Links.

KI-Agenten schlagen vor, die Person entscheidet

Unter der Zustimmung einer Person wird eine Änderung durch einen KI-Agenten (eine als Agent registrierte Anwendung, z. B. ein über MCP verbundener Assistent) oder jede Änderung mit author_type ai nicht sofort angewendet. Die Plattform validiert sie und antwortet 202 Accepted mit der Vorschlags-ID (Header Anpheros-Proposal); es ändert sich nichts im Datensatz. Die Person sieht dies in GET /me/patients/{id}/proposals – was es ist, welche Anwendung es gesendet hat – und akzeptiert oder lehnt es ab (…/proposals/{proposal}/accept oder …/reject). Ein akzeptierter Vorschlag wird exakt so geschrieben, wie er gesendet wurde, und als KI-generiert markiert (HL7 AI Transparency). Projekte, die den Datensatz einsehen können, erhalten einen dünnen proposal.created Webhook. Änderungen, die mit dem eigenen Schlüssel eines Projekts vorgenommen werden, auf Datensätzen, die das Projekt erstellt hat, werden nicht zurückgehalten.

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