31.10.2012
Seite 4 von 8
teway-Rechner ruft die Daten gemäß dem IHE-Protokoll oder anhand anderer proprietärer
Verfahren ab. Da das System auf einer Service-orientierten Architektur basiert, ist es denkbar,
dass ein Medizingerät selbst zum Gateway wird. Somit ist nicht zwangsweise eine zentrale
Komponente erforderlich, die den Datenabruf organisiert.
Nach dem Abruf des KIS-Systems befinden sich die Daten „im OP-Saal“, so dass eine Kon-
vertierungseinheit sie in einen DPWS-konformen Dienst umwandeln kann. Die Konvertie-
rungseinheit, in
Abbildung 1
als DPWS-Konverter bezeichnet, ist entweder ein weiterer
„schlanker“ Computer, dessen einziger Job darin besteht, die Nachrichten aus einem Format
in ein anderes zu überführen, oder wird zusammen mit dem Gateway-Rechner respektive ei-
nem Medizingerät ausgeliefert.
Der dritte Schritt besteht darin, den Patienten zu bestätigen, der als nächstes operiert wird.
Dies erfordert die Teilnahme eines menschlichen Akteurs, wodurch impliziert ist, dass ein
grafisches Bedienelement für die Mensch-Maschine-Interaktion vorhanden sein muss. Der
menschliche Akteur authentifiziert sich gegenüber dem System und wählt den zu operieren-
den Patienten aus einer gefilterten Liste aus. Die grafische Interaktion sollte entweder am OP-
Management-System, an einem separaten Rechner oder an einem der Medizingeräte erfolgen.
Zu beachten ist, dass keine Patienteninformation
automatisch
verwertet werden darf, so lange
nicht die Bestätigung eines Menschen vorliegt. Die Liste mit den Patientendaten könnte durch
zusätzliche technische Hilfsmittel auf einen Datensatz reduziert werden, beispielsweise mit-
hilfe von Barcodes und
Near-Field-Communication (NFC)
. Es ist auch denkbar, dass mobile
Einheiten, die bereits eine Patientenzuordnung erhalten haben, einen Patienten vorschlagen. In
jedem Fall ist eine Bestätigung durch das Personal notwendig.
Alle Geräte, die Patientendaten abfragen möchten, benötigen abschließend noch direkten oder
indirekten Zugriff auf das Netzwerk, in dem sich die Konvertierungseinheit befindet. Jedes
Gerät sucht bei Beginn nach dem Datenlieferanten, um sich anschließend über Datensätze
passiv informieren zu lassen oder aktiv Datensätze abzufragen.
Ein robustes Kommunikationsprotokoll
Der oben beschriebene Prozess spiegelt nicht die realen Abläufe im OP wider. In der Realität
ist davon auszugehen, dass Geräte eingeschaltet werden, bevor die Patientendaten aus dem
KIS abgerufen worden sind; dass Geräte während der OP ausfallen und ggf. ausgetauscht oder
neu gestartet werden müssen; dass mehrere Geräte als Lieferanten von Patientendaten in Fra-
ge kommen; dass Geräte einen gemeinsamen Kontext (vgl. Patientenkontext) benötigen, um
schon vorab einem Operationssaal bzw. einer Operation zugeordnet werden zu können. Dies
gilt insbesondere dann, wenn sich LAN-Subnetze über mehrere OP-Säle erstrecken (z.B. an-
hand von Switch-Geräten oder Drahtloskommunikation). Unterm Strich sind keine linearen
Abläufe zu erwarten, weshalb alle Ausnahmen abgefangen und behandelt werden müssen.
Zur Diskussion steht die Akquise der Patientendaten unter Berücksichtigung folgender As-
pekte:
1.
Ein oder mehrere Geräte möchten Daten abrufen, obwohl noch keine Patientendaten
vorliegen
2.
Ein oder mehrere Geräte möchten Daten abrufen, obwohl noch keine akkreditierte Pa-
tientenstammakte vorliegt
3.
Ein oder mehrere Geräte werden (re-)aktiviert, nachdem die Patientenstammakte be-
reits ausgewählt wurde