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

Zugriffsanfragen von Kliniken mit Zustimmung des Patienten (CIBA)

Der OpenID CIBA-Flow hinter Zugriffsanfragen von Kliniken: Die Rezeption gibt die E-Mail des Patienten ein, der Patient genehmigt in der App oder per E-Mail für 30, 90 oder 365 Tage, und die Anwendung der Klinik erhält Tokens.

Eine Klinik greift nur dann auf den Datensatz eines Patienten auf Anpheros zu, wenn der Patient dies genehmigt. Die Anwendung der Klinik sendet eine Anfrage, die die E-Mail-Adresse des Patienten und den benötigten Zugriff benennt. Der Patient erhält diese in der Anpheros-App und per E-Mail, sieht, wer und wofür anfragt, wählt aus, wie lange er dies zulässt, und genehmigt oder lehnt ab. Wenn er genehmigt, erhält die Anwendung der Klinik Tokens und kann den Datensatz lesen, bis der Zugriff abläuft oder der Patient ihn widerruft.

Der Flow ist der Standard-OpenID Connect Client-Initiated Backchannel Authentication (CIBA)-Flow im Poll-Modus. Er existiert, damit ein Rezeptionist dem Patienten kein Telefon oder keinen Link reichen muss: Die Anfrage geht an den Patienten, nicht über den Bildschirm der Klinik.

Schritt für Schritt

Die Rezeption gibt die E-Mail des Patienten ein. Die Anwendung der Klinik ruft POST /oauth/bc-authorize mit ihren Anmeldeinformationen, der E-Mail des Patienten als login_hint, dem benötigten scope und einer kurzen binding_message auf, die der Patient sehen wird.
Die Plattform antwortet für jede Adresse gleich. Die Antwort enthält eine auth_req_id, ein Ablaufdatum und ein Abfrageintervall, unabhängig davon, ob diese E-Mail über ein Anpheros-Konto verfügt. Es wird nicht offengelegt, wer einen Datensatz hat. Eine Anfrage für eine Person ohne Konto läuft einfach ab.
Der Patient entscheidet. Er erhält eine Benachrichtigung in der Anpheros-App und eine E-Mail. Die Anfrage zeigt die Organisation, den Umfang und die Nachricht an. Er wählt einen Zeitraum von 30, 90 oder 365 Tagen und klickt auf "Zulassen" oder "Ablehnen". Der Link in der E-Mail genehmigt nichts, wenn er geöffnet wird, da Mail-Scanner Links öffnen; der Patient muss auf die Schaltfläche klicken.
Die Klinik fragt ab. Die Anwendung ruft POST /oauth/token mit dem Grant-Typ urn:openid:params:grant-type:ciba und dem auth_req_id auf. Solange der Patient nicht entschieden hat, ist die Antwort authorization_pending. Nach der Genehmigung werden die Token einmal zurückgegeben. Eine Ablehnung gibt access_denied zurück und eine unbeantwortete Anfrage gibt expired_token zurück.
Die Klinik liest und schreibt innerhalb des gewährten Umfangs. Jeder Lesevorgang wird protokolliert und ist für den Patienten sichtbar. Eine Klinik kann nur ändern oder löschen, was sie selbst geschrieben hat.

Was schützt den Patienten

Nur verifizierte E-Mail. Eine Anfrage passt nur zu einem Konto, dessen E-Mail-Adresse verifiziert ist. So kann niemand die Anfragen einer anderen Person erhalten, indem er ein Konto mit deren Adresse erstellt.
Geltungsbereich und zeitlich begrenzt. Der Zugriff erfolgt pro Ressourcentyp und Aktion für einen angegebenen Zeitraum. Eine Anfrage, auf die niemand antwortet, verfällt standardmäßig innerhalb eines Tages und spätestens nach sieben Tagen.
Jederzeit widerrufbar. Der Widerruf wird bei der nächsten Anfrage wirksam. Die Klinik kann sich nicht wieder Zugang verschaffen.
Sichtbar. Der Patient sieht jede Verbindung und jeden Zugriff in der App. Siehe Zustimmungs- und Zugriffsmodell.

Was eine Klinik benötigt, um zu erstellen

Ein vertraulicher OAuth-Client, der auf der Plattform registriert ist, dessen Secret auf dem Server aufbewahrt wird.
Eine Polling-Schleife, die das Intervall berücksichtigt und die vier Ergebnisse verarbeitet.
Eine Möglichkeit, die Entscheidung des Patienten an der Rezeption anzuzeigen ("wartet auf den Patienten", "genehmigt bis …", "abgelehnt").
Handhabung der zurückgegebenen Token als kurzlebige Anmeldeinformationen: Zugriffstoken sind 30 Minuten gültig und Refresh-Token werden bei jeder Verwendung rotiert. Siehe Authentifizierung und OAuth.

Für eine Klinik, die es vorzieht, eine Zustimmungsseite vor dem Patienten zu öffnen, z. B. am Schalter, wird auch der Standard-Autorisierungscode-Flow mit PKCE und SMART on FHIR Standalone Launch unterstützt.

Häufig gestellte Fragen

Muss sich der Patient in der Klinik befinden?

Nein. Er kann die Zustimmung von seinem eigenen Telefon oder über den E-Mail-Link erteilen, wo immer er sich befindet. Eine Anfrage kann also vor dem Termin gesendet werden, und ein Patient, der sich im Ausland befindet, kann sie trotzdem genehmigen.

Was passiert, wenn der Patient kein Anpheros-Konto hat?

Die Anfrage wird akzeptiert und verfällt dann ohne Entscheidung, und die Klinik kann nicht feststellen, ob ein Konto existiert. Der Patient kann ein Konto erstellen und die Klinik kann eine neue Anfrage senden.

Wie lange dauert der Zugriff?

Der Patient wählt 30, 90 oder 365 Tage, wenn er zustimmt. Er kann ihn auch früher widerrufen.

Kann die Klinik alles in der Akte sehen?

Nur den Umfang, dem der Patient zugestimmt hat. Scopes werden pro Ressourcentyp und Aktion festgelegt und können nach Kategorie gefiltert werden.

Ist der Anfragefluss ein Standard?

Ja. Es handelt sich um OpenID Connect CIBA, sodass bestehende OAuth-Bibliotheken verwendet werden können. Weitere Informationen zum breiteren Modell finden Sie im Leitfaden Healthcare API mit Patienteneinwilligung.

Ist dies live?

Ja, auf der Plattform in der privaten Beta-Phase. Für den Produktionszugriff ist eine verifizierte Organisation und eine unterzeichnete Datenverarbeitungsvereinbarung erforderlich.