Workflow

Zustandsdiagramm

Das folgende Zustandsdiagramm zeigt die möglichen Status eines Vermittlungscodes (in türkis), die Statusübergänge mit den jeweiligen Operationen (in dunkelblau) und Statusübergänge, die über den 116117 Terminservice prinzipiell möglich, aber nicht mit den Operationen der Terminschnittstelle für Dritte realisierbar sind (in orange).

TS_DRITTE_Workflow_Zustandsdiagramm

Erklärung

Dritte müssen als Erstes prüfen, ob ein Vermittlungscode vorhanden ist oder nicht.

Ist kein Vermittlungscode vorhanden, kann lediglich die Operation Vermittlungscode anfordern aufgerufen werden.
- Alle anderen Operationen benötigen zwingend einen Vermittlungscode.
Ist ein Vermittlungscode vorhanden, können über die Operation Vermittlungscodestatus abrufen Informationen über diesen Vermittlungscode abgerufen werden.
- Diese Operation kann immer aufgerufen werden, solange ein existenter Vermittlungscode vorliegt.
- Welche anderen Operationen aufgerufen werden können, hängt vom Status des Vermittlungscodes ab (siehe Tabelle).

Die folgende Tabelle gibt einen Überblick über die möglichen Status eines Vermittlungscodes und welche Operationen mit den einzelnen Status über die Terminschnittstelle für Dritte aufgerufen werden können. (Details zu den Status sind im Abschnitt Status auf der Seite Vermittlungscode beschrieben; nähere Informationen zu den einzelnen Operationen sind auf den jeweiligen, im Tabellenkopf verlinkten Seiten zu finden.)

Status	Termine suchen	Termin buchen	Terminbuchung absagen	Buchungsinformationen abrufen	Vermittlungscodestatus abrufen
`draft`	✅	✅	❌	❌	✅
`active`	❌	❌	✅	✅	✅
`on-hold`	❌	❌	❌	❌	✅
`revoked`	✅	✅	❌	❌	✅
`completed`	❌	❌	❌	❌	✅

Benachrichtigung des Patienten

Dritte müssen ihre Nutzer / die Patienten über Statusänderungen ihres Vermittlungscodes informieren und sollten Terminerinnerungen zu bevorstehenden Terminen versenden. Beide Arten von Benachrichtigungen erfordern die Zustimmung des Nutzers / Patienten per Opt-in.

Benachrichtigung über Statusänderungen

Aktuell stellt die Terminschnittstelle für Dritte keine Möglichkeit (bspw. mittels Web-Hook) zur Verfügung, um aktiv über Statusänderungen zu einem Vermittlungscode informiert zu werden. Das bedeutet, dass Drittanbieter nur durch regelmäßiges Abrufen der Informationen (Polling) eine mögliche Statusänderung feststellen können (siehe Operation Vermittlungscodestatus abrufen).

In folgenden Fällen sollte der Dritte den Patienten über eine Statusänderung benachrichtigen:

Beschreibung	vorherige(r) Status	aktueller Status	Anmerkung
Die Buchung eines Termins über das System des Dritten war erfolgreich.	`draft` `revoked`	`active`
Eine Buchung, die durch das System des Dritten erfolgt ist, wird ebenfalls über das System des Dritten abgesagt.	`active`	`revoked`
Eine Buchung, die durch das System des Dritten erfolgt ist, wurde durch ein anderes System abgesagt.	`active`	`revoked`	siehe Auflistung unterhalb der Tabelle
Eine Buchung, die durch das System des Dritten erfolgt ist, wurde durch ein anderes System abgesagt und anschließend wurde eine zweite Buchung ebenfalls über ein anderes System durchgeführt.	`active`	`active`	Um die zwischenzeitliche Terminabsage zu bemerken, muss der Dritte speichern, wann er in seinem System zuletzt den Status des Vermittlungscodes geändert hat. Diesen Zeitstemepl kann der Dritte dann mit dem letzten Änderungszeitpunkt der abgerufenen ServiceRequest-Instanz (`ServiceRequest.meta.lastUpdated`) vergleichen: Liegt der Zeitpunkt von `lastUpdated` zeitlich gesehen nach dem im System des Dritten gespeicherten Zeitstempel, wurde der Status von einem anderen System geändert. Beispiel: Ein Patient hat einen Termin über das System des Dritten gebucht, sagt diesen aber telefonisch direkt bei der Praxis ab und vereinbart gleich einen neuen Termin mit der Praxis.
Der Vermittlungscode ist abgelaufen.	`draft` `on-hold` `revoked`	`completed`	Für Dritte ist es nicht möglich, zu unterscheiden, aus welchem Grund der Status eingetreten ist (siehe hierzu Abschnitt Status auf der Seite Vermittlungscode), weshalb im Idealfall alle möglichen Gründe hierfür in der Benachrichtigung enthalten sein sollten.

Bitte beachten: Erfolgt eine Buchung durch ein anderes System und wird dann über das System des Dritten abgesagt, darf keine Benachrichtigung an den Patienten geschickt werden; dies wird vom anderen System übernommen. Das System des Dritten muss sich also merken, ob eine Buchung durch das eigene oder ein anderes System durchgeführt wurde.

Aktuell gibt es keine Möglichkeit für Dritte, zu unterscheiden, durch wen bzw. welches andere System eine Statusänderung erfolgt ist. Neben den Dritten gibt es folgende Akteure und Systeme:

Der Patient kann über die Weboberfläche oder die App des 116117 Terminservice Termine reservieren, buchen und absagen.
Der Patient kann über die Terminservicestelle telefonisch Termine reservieren, buchen und absagen lassen.
Der Patient kann über die Praxis / medizinische Einrichtung (durch persönliches Erscheinen, telefonisch, per E-Mail o.ä.) Termine reservieren, buchen und absagen lassen.
Die Praxis / medizinische Einrichtung kann über ihr System Termine absagen (bspw. wenn der Arzt krank ist oder aus anderen betrieblichen Gründen).

Terminerinnerungen

Dritte sollten eine Terminerinnerung an den Patienten schicken, sofern dies vom Patienten gewünscht wird. Dabei ist zu beachten, dass eine in der Zukunft liegende Terminerinnerung bei Absage des Termins (egal, durch welches System) gelöscht werden muss; d.h., sobald ein Termin abgesagt wurde, darf der Dritte keine Terminerinnerung mehr für den abgesagten Termin an den Patienten verschicken.

Dies inkludiert auch die Terminerinnerung für die erste Buchung des in der Tabelle beschriebenen Falles, wenn nach der Terminabsage durch ein anderes System eine neue Terminbuchung ebenfalls durch ein anderes System erfolgt ist.

Keine Reservierung von Terminen möglich

Wurde mit einem Vermittlungscode ein Terminslot reserviert, hat ServiceRequest.status den Wert on-hold. Dies ist im 116117 Terminservice prinzipiell möglich, nicht aber über die Terminschnittstelle für Dritte. D.h., die Terminschnittstelle für Dritte erlaubt aktuell keine Reservierung von Terminen. Folglich wird ein Terminslot solange als freier Slot in den Suchergebnissen von entsprechenden Terminsuchen erscheinen, bis ein Nutzer die Terminbuchung für diesen Slot vollständig abgeschlossen hat. Unterbricht der Nutzer den Buchungsprozess, kann ein anderer Nutzer in der Zwischenzeit diesen Terminslot (erfolgreich) buchen. Entsprechend bekommt der Nutzer, der die Terminbuchung unterbrochen hat, dann einen Fehler zurück, wenn er versucht, die Buchung abzuschließen.

Beispielhaft veranschaulicht könnte ein solches Szenario wie folgt aussehen:

TS_DRITTE_Workflow_Terminbuchung

Beschreibung

Nutzer A führt eine Terminsuche durch und findet Termislot 1.
Nutzer A schließt die Terminbuchung aber noch nicht ab und führt auch keine neue Terminsuche aus. (Bspw. könnte er sich auf der Weboberfläche des Drittanbieters noch die Details zum Terminslot ansehen, länger für die Eingabe der Patientendaten für die Buchung benötigen o.ä.)
- Es erfolgt keine Reservierung irgendeines Terminslots aus den Suchergebnissen.
Nutzer B führt indes ebenfalls eine Terminsuche durch und findet denselben Terminslot 1.
Nutzer B führt erfolgreich eine Terminbuchung für Terminslot 1 durch. Dadurch passiert systemseitig Folgendes:
- Terminslot 1: Slot.status wird von free zu busy geändert. Dadurch wird Terminslot 1 bei neuen Terminsuchen nicht mehr angezeigt.
- Vermittlungscode von Nutzer B: Für ServiceRequest.status wird der Wert active und für ServiceRequest.meta.lastUpdated der aktuelle Zeitstempel gesetzt.
- Terminbuchung: Es wird eine neue Ressource vom Typ Appointment für diese Terminbuchung erzeugt, die systemseitig mit dem Vermittlungscode von Nutzer B assoziiert wird.
Für Nutzer A wird Terminslot 1 weiterhin als frei angezeigt, solange er keine neue Terminsuche ausführt.
Nutzer A möchte nun ebenfalls eine Terminbuchung für Terminslot 1 durchführen bzw. diese abschließen, bekommt aber eine entsprechende Fehlermeldung zurück.