31.10.2012
Seite 7 von 8
Abbildung 4 zeigt die zweite Abweichung, in der bereits eine Patientenliste vorliegt, jedoch
noch kein menschlicher Akteur einen konkreten Datensatz designiert hat. Hier gibt es zwei
Optionen: entweder ignoriert das anfordernde Gerät die Liste mit Patienten, die vom Gateway
als Antwort geliefert wird oder es visualisiert eine Auswahl auf dem Geräte-Monitor, aus der
ein Akteur einen Datensatz bestätigen kann. Im Rahmen der ersten Option kann exakt so ver-
fahren werden wie bei Abweichung 1 aus Abbildung 3. Das Gerät verbleibt in einem passiven
Modus und wartet auf die Verteilung der Patientendaten durch die Datenquelle. Im zweiten
Fall kann der Datensatz am anfordernden Gerät bestätigt werden. Daraufhin wird der Daten-
quelle der bestätigte Datensatz mitgeteilt, so dass anschließend der Versand per
Publish/Subscribe an alle interessierten Netzwerkteilnehmer erfolgen kann. Die designierte
Patientenakte sollte immer nur von der Datenquelle an die Geräte transportiert werden, ob-
gleich sie auch von dem Gerät verschickt werden könnten, an dem die Bestätigung erfolgt ist.
So bleiben die Aufgaben der Netzwerkteilnehmer klar definiert.
Die dritte Abweichung besteht darin, dass ein Gerät gestartet bzw. reaktiviert wird, nachdem
die Verteilung der Patientendaten bereits erfolgt ist. Diese Ausnahme ist ein Spezialfall der
ersten Abweichung (vgl. Abbildung 3) und kann somit analog kompensiert werden. Zur Be-
handlung der ersten drei Abweichungen gilt: ein aktiviertes Gerät erfragt zunächst pro-aktiv
die Patientendaten. Bekommt das Gerät eine leere Antwort geliefert, verweilt es anschließend
in einem passiven Modus, bis eine Nachricht von der Datenquelle eintrifft. Im Fall einer Pati-
entendatenliste hat das Gerät die Möglichkeit, die Liste zu visualisieren und dem dienstha-
benden Personal einen Datensatz bestätigen zu lassen. Hierbei handelt es sich um einen Kom-
fortmechanismus, mit dem das Personal nicht gezwungen ist, die Patientendaten am Gateway
beziehungsweise an der Datenquelle zu bestätigen. Im Allgemeinen ist jedoch davon auszu-
gehen, dass der Patient im Rahmen des OP-Management-Systems bereits am Gateway-
Rechner designiert wird.
Der vierte Aspekt adressiert den Fall einer redundanten Anzahl an Patientendatenlieferanten
für einen OP-Saal. Auch wenn die Datenquelle aller Wahrscheinlichkeit nach für alle Patien-
tendatenlieferanten dieselbe ist (nämlich das zugrunde liegende KIS), kann es in einem
hete-
rogenen
OP-Saal passieren, dass es neben dem OP-Management-System auch Medizingeräte
gibt, die Patientendaten aus dem Netzwerk abrufen. Es liegt nahe, einen Lieferanten algorith-
misch zu bestimmen, jedoch ist diese Problemstellung vergleichbar mit der algorithmischen
Wahl eines Koordinatorrechners. Verteilte Algorithmen, die Koordinatoren festlegen, gehen