# Zustimmungs- und Zugriffsmodell

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

Source: https://developers.anpheros.com/de/guides/consent

**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](https://developers.anpheros.com/de/guides/medical-data-provenance).

## 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](https://hl7.org/fhir/uv/smart-health-cards-and-links/) 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.