Ablauf einer Anfrage

Eine Belegungsanfrage durchläuft eine feste Folge von Schritten, von denen sich die mittleren wiederholen können. Dieser Abschnitt beschreibt sie im Zusammenhang; die Details stehen jeweils auf der verlinkten Seite.

sequenceDiagram
    actor Z as Zuweiser
    participant B as Belegungsportal
    participant K as Klinik

    Z->>B: POST /api/v1/token/login
    B-->>Z: Access-Token

    Z->>B: POST Bundle (intent proposal), Stammdaten (Maskierung optional), eine oder mehrere Kliniken
    B-->>Z: 202 Accepted

    opt Dokumente einreichen
        Z->>B: POST Bundle (DocumentBundle)
        B-->>Z: 202 Accepted
    end

    B->>K: Anfrage je Klinik
    Note over K: Prüfung, ggf. Befundprüfung
    K->>B: Stand (zugesagt / abgelehnt / Rückfrage / weitere Daten)
    B->>Z: Webhook AdmissionResponse (businessStatus)

    loop bei Rückfrage oder weiteren Daten
        Z->>B: POST Bundle (gleiche ServiceRequest-ID), ergänzte Daten oder Dokumente
        B-->>Z: 202 Accepted
        B->>K: ergänzte Daten oder Dokumente
        Note over K: Prüfung, ggf. Befundprüfung
        K->>B: neuer Stand
        B->>Z: Webhook AdmissionResponse
    end

    Z->>B: POST Bundle (intent order, selected-provider), vollständige Stammdaten
    B-->>Z: 202 Accepted
    B->>K: Übermittlung Stammdaten, Aufnahmeentscheidung

    opt Auswahl zurückziehen
        Z->>B: POST Bundle (selected-provider-cancelled)
        B-->>Z: 202 Accepted
        B->>K: Benachrichtigung über Rückzug der Auswahl
    end

Zum Vergrößern auf das Diagramm klicken.

1. Anmelden

Der Zuweiser erhält Benutzername und Passwort von MEDIAN und tauscht sie über POST /api/v1/token/login gegen ein Access-Token. Das Token gilt eine Stunde und wird bei jedem weiteren Aufruf mitgeschickt. Siehe Authentifizierung.

2. Kapazitätsanfrage senden

Der Zuweiser sendet ein AdmissionRequestBundle mit intent: proposal an POST /api/v2/fhir/Bundle, mit Alter, Geschlecht, Fachrichtung und Aufnahmetermin. Die Patientenstammdaten kann er dabei aus Datenschutzgründen maskieren, muss es aber nicht. Vorhandene Befunde reicht er als eigenes DocumentBundle ein. Das Portal bestätigt jedes angenommene Bundle mit 202 Accepted. Siehe AdmissionRequestBundle und DocumentBundle.

3. Antwort der Klinik

Jede angefragte Klinik entscheidet und antwortet. Das Portal stellt das Ergebnis als Webhook-Event an die hinterlegte Adresse zu. Der fachliche Stand steht im businessStatus des Task: zugesagt, abgelehnt, eine Rückfrage oder weitere Daten erforderlich. Kliniken, die auf Nachfrage entscheiden, antworten erst nach ihrer internen Prüfung. Siehe Webhooks.

4. Rückfragen beantworten

Bei einer Rückfrage oder der Bitte um weitere Daten schickt der Zuweiser ein neues Bundle unter derselben ServiceRequest-Kennung mit den ergänzten Angaben. Zusätzliche Dokumente gehen als eigenes DocumentBundle ein. Darauf antwortet die Klinik erneut. Diese Runde kann sich mehrfach wiederholen.

5. Klinik auswählen

Der Zuweiser wählt am Ende eine Klinik aus, die zugesagt hat. Dazu sendet er ein Bundle mit intent: order und orderDetail: selected-provider. Spätestens jetzt übermittelt er die vollständigen Patientenstammdaten. Die übrigen Anfragen werden storniert.

6. Zurückziehen und Stornieren

Die gesamte Anfrage lässt sich jederzeit mit status: revoked zurückziehen, etwa wenn der Patient nicht mehr verlegungsfähig ist. Eine bereits getroffene Auswahl hebt der Zuweiser mit orderDetail: selected-provider-cancelled wieder auf, ohne die Anfrage zu beenden. Danach kann er insbesondere eine andere Klinik auswählen.