Einleitung

Die MEDIAN Belegungsportal-API bietet eine Schnittstelle, um Belegungsanfragen an MEDIAN-Kliniken zu richten. Ein Zuweiser, etwa eine Akutklinik oder ein Zuweiserportal, fragt darüber an, ob eine MEDIAN-Klinik einen Patienten zu einem gewünschten Termin aufnehmen kann, und erhält nach Prüfung eine verbindliche Zu- oder Absage.

Die Schnittstelle ist FHIR-basiert. Anfragen und Antworten sind FHIR-Ressourcen; die zentrale Ressource jeder Anfrage ist ein ServiceRequest, der über alle Schritte hinweg stabil bleibt.

Ablauf im Überblick

Eine Belegungsanfrage läuft in mehreren Runden. Der Zuweiser richtet die Anfrage an eine oder mehrere Kliniken und übermittelt die Angaben für die Entscheidung: Alter, Geschlecht, die gewünschte Fachrichtung, der Aufnahmetermin, Befunde und sonstige Dokumente. Jede Klinik antwortet mit ihrer Entscheidung: Zusage, Absage, eine Rückfrage oder die Bitte um weitere Daten. Auf eine Rückfrage schickt der Zuweiser ergänzte Angaben unter derselben Kennung nach, worauf eine neue Antwort folgt.

Am Ende wählt der Zuweiser eine der Kliniken aus, die zugesagt haben; die übrigen Anfragen werden storniert. Eine getroffene Auswahl kann er danach noch zurückziehen.

Den ausführlichen Ablauf mit Sequenzdiagramm zeigt Ablauf einer Anfrage.

Datenschutz

In der frühen Phase kann der Zuweiser aus Datenschutzgründen die Patientenstammdaten maskieren. Das ist nicht in allen Fällen sinnvoll, daher ist dieser Schritt nur optional. Für die Einhaltung der notwendigen Einverständniserklärung des Patienten ist der Zuweiser selbst verantwortlich.

Verlangt eine Klinik im Rahmen einer Rückfrage Befunde oder weitere Angaben zur Entscheidung, stützt sich deren Übermittlung auf das berechtigte Interesse der Klinik an der Aufnahmeprüfung. Dieselbe Grundlage gilt für die vollständigen Patientenstammdaten, die spätestens mit der Auswahl einer Klinik vorliegen müssen.

Kommunikationsmodell

Die API kombiniert synchrone HTTP-Aufrufe mit asynchronen Webhooks.

Der Zuweiser sendet jede Anfrage als FHIR-Bundle per POST an das Portal. Das Portal nimmt das Bundle an, prüft es und bestätigt den Empfang mit 202 Accepted. Die fachliche Antwort der Klinik entsteht erst später, etwa nach einer Befundprüfung. Sie kommt deshalb als Webhook-Event an eine Adresse, die der Zuweiser vorab als Subscription hinterlegt.

Alternativ zum Webhook kann der Zuweiser den aktuellen Stand einer Anfrage jederzeit über GET /api/v2/fhir/Task selbst abfragen.

Zentrale Konzepte

Jede Anfrage enthält einen ServiceRequest mit einem stabilen, global eindeutigen identifier. An diesem Identifier erkennt das Portal, ob ein eingehendes Bundle eine neue Anfrage anlegt oder eine bestehende fortschreibt. Den Identifier vergibt der Zuweiser selbst, als eigene stabile Kennung der Anfrage; sein Wert muss mit der für den Zuweiser hinterlegten FHIR-Basis-URL beginnen, Anfragen mit abweichendem Präfix werden abgelehnt.

Alle Bundles gehen an einen einzigen Eingangsendpunkt. Bundle.meta.profile gibt an, ob ein Bundle eine Aufnahmeanfrage oder ein Dokument ist.

Ressourcen verweisen aufeinander über fachliche Identifier: Kliniken über ihre IK-Nummer, ServiceRequest und Patient über eine globale URI. Diese Identifier gelten auch über Systemgrenzen hinweg.

Überblick der Endpunkte

Zweck	Endpunkt
Token anfordern und erneuern	POST /api/v1/token/login, POST /api/v1/token/refresh
Teilnehmende Kliniken abrufen	GET /api/v1/kliniken
Webhook-Adressen verwalten	GET, POST, PUT, DELETE auf /api/v1/subscriptions
Anfrage oder Dokument senden	POST /api/v2/fhir/Bundle
Stand einer Anfrage abfragen	GET /api/v2/fhir/Task