|
Inhaltsverzeichnis:
|
| I |
Abbildungsverzeichnis |
v |
| II |
Abkürzungsverzeichnis |
|
| 1 |
Motivation und Zielsetzung |
1 |
| 1.1 |
Ausgangssituation |
1 |
| 1.2 |
Ziel der Arbeit |
1 |
| 2 |
Theoretische Grundlagen |
3 |
| 2.1 |
Intensiv- und Anästhesiedokumentationssysteme |
3 |
| 2.2.1 |
Begriffsdefinition |
3 |
| 2.1.2 |
Probleme des Datenmanagements in der Intensivmedizin und Anästhesiologie |
4 |
| 2.1.3 |
Geschichtliche Entwicklung von Intensiv- und Anästhesiedokumentationssystemen |
5 |
| 2.1.4 |
Bausteine eines Intensiv- und Anästhesiedokumentationssystems |
5 |
| 2.1.5 |
Das Intensiv- und Anästhesiedokumentationssystem COPRA |
6 |
| 2.2 |
Datenaustauschvereinbarungen zwischen medizinischen Informationssystemen |
9 |
| 2.2.1 |
Health Level Seven |
10 |
| 2.2.2 |
Digital Imaging and Communications in Medicine |
12 |
| 2.2.3 |
Extensible Markup Language |
13 |
| 2.2.4 |
Die Initiative Integrating the Healthcare Enterprise |
14 |
| 2.3 |
Integration von Intensiv- und Anästhesiedokumentationssystemen in Krankenhausinformationssysteme |
15 |
| 2.3.1 |
Krankenhausinformationssysteme |
15 |
| 2.3.2 |
Datenintegration im Krankenhausinformationssystem |
18 |
| 2.3.3 |
Integration von Intensiv- und Anästhesiedokumentationssystemen |
19 |
| 2.4 |
Datenaustauschmöglichkeiten zwischen medizinischen Informationssystemen und medizinischen Geräten |
20 |
| 2.4.1 |
Die Systemarchitektur der indirekten Anbindung |
21 |
| 2.4.2 |
Die Systemarchitektur der direkten Anbindung |
22 |
| 2.5 |
Konkrete Datenaustauschmöglichkeiten zwischen Intensiv- und Anästhesiedokumentationssystem und medizinischen Geräten |
24 |
| 2.5.1 |
Anbindung von Medizintechnik über Gateway-Computer |
24 |
| 2.5.2 |
Direkte Datenübernahme über die serielle Schnittstelle |
25 |
| 2.5.3 |
Datenübernahme mit Hilfe von Geräteinterfaceboxen |
25 |
| 2.5.4 |
Anbindung von Medizintechnik über serielle Multiplexer |
27 |
| 3 |
Systemanalyse am Unfallkrankenhaus Linz |
28 |
| 3.1 |
Allgemeines zum Unfallkrankenhaus |
28 |
| 3.2 |
Analyse der vorhandenen Informationssysteme und Dokumentationsmethoden |
29 |
| 3.2.1 |
Aufnahme und Erstuntersuchung |
30 |
| 3.2.2 |
Notfall-, spezielle Wund- und Ambulanzversorgung |
31 |
| 3.2.3 |
Intensivbehandlung |
32 |
| 3.2.4 |
Anästhesiedokumentation im OP-Bereich |
33 |
| 3.2.5 |
OP-Management und Dokumentation |
33 |
| 3.2.6 |
Leistungsanforderung und Leistungsdokumentation |
34 |
| 3.3 |
Analyse der neuen Infrastrukturen |
35 |
| 3.3.1 |
Operationsbereich / Anästhesiologie |
35 |
| 3.3.2 |
Intensivstation |
36 |
| 3.3.3 |
Brandverletzte |
37 |
| 3.3.4 |
Wachstation |
37 |
| 3.4 |
Resultierende Anforderungen an das Intensiv- und Anästhesiedokumentationssystem COPRA |
38 |
| 4 |
Integration des Intensiv- und Anästhesiedokumentationssystem COPRA am Unfallkrankenhaus Linz |
41 |
| 4.1 |
Planung und Realisierung der Rechentechnik |
41 |
| 4.1.1 |
Hardware für den Einsatz außerhalb der Patientenumgebung |
41 |
| 4.1.2 |
Hardware für den Einsatz in der Patientenumgebung |
42 |
| 4.1.3 |
Server für das Intensiv- und Anästhesiedokumentationssystem |
44 |
| 4.1.4 |
Auswahl der geeigneten Geräteinterfacebox |
45 |
| 4.2 |
Entscheidung und Realisierung der Integration des Intensiv- und Anästhesiedokumentationssystem COPRA |
47 |
| 4.2.1 |
Integration in das Krankenhausinformationssystem Astra |
49 |
| 4.2.2 |
Anbindung des Laborsystems |
51 |
| 4.2.3 |
Datenübergabe an die Qualitätssicherung |
53 |
| 4.2.4 |
Datenübernahme vom Patientenmonitoring |
53 |
| 4.2.5 |
Datenübernahme von der Beatmungs- und Narkosetechnik |
54 |
| 4.2.6 |
Datenübernahme von der Infusionstechnik |
57 |
| 4.2.7 |
Integrationszustand nach Abschluss der Realisierungen |
60 |
| 5 |
Test der Integration des Intensiv- und Anästhesiedokumentationssystem COPRA am Unfallkrankenhaus Linz |
61 |
| 5.1 |
Ziel der Entwicklung und Durchführung von Tests |
61 |
| 5.2 |
Auswahl der Testobjekte |
62 |
| 5.3 |
Der Testprozess |
63 |
| 5.3.1 |
Theorie |
63 |
| 5.3.2 |
Manuelles Testen |
64 |
| 5.3.3 |
Automatisiertes beziehungsweise teilautomatisiertes Testen |
64 |
| 5.4 |
Entwicklung und Durchführung der Tests |
66 |
| 5.4.1 |
Test der spezifisch entwickelten Formulare für das Unfallkrankenhaus Linz |
66 |
| 5.4.2 |
Test der Schnittstellen zum Krankenhausinformationssystem Astra und Laborsystem |
68 |
| 5.4.3 |
Test der Datenübernahme vom Patientenmonitoring |
69 |
| 5.4.4 |
Test der Datenübernahme von der Beatmungs- und Narkosetechnik |
70 |
| 5.4.5 |
Test der Datenübernahme von der Infusionstechnik |
71 |
| 5.5 |
Übertragbarkeit der Tests auf weitere Integrationen des Intensiv- und Anästhesiedokumentationssystems COPRA |
73 |
| 6 |
Diskussion der Ergebnisse |
74 |
| 6.1 |
Bewertung der eingesetzten Hardware |
74 |
| 6.2 |
Bewertung der Integration des Intensiv- und Anästhesiedokumentationssystem COPRA in das bestehende Krankenhausinformationssystem |
75 |
| 6.3 |
Bewertung der Realisierung der Datenübernahme von der Medizintechnik |
76 |
| 6.4 |
Bewertung der durchgeführten Tests |
77 |
| 7 |
Zusammenfassung |
78 |
| III |
Quellenverzeichnis |
vi |
|
Literatur |
vi |
|
Internetseiten |
vii |
| IV |
Anhang |
ix |
|
Darstellung der umgesetzten Vorschläge zur Konfiguration der Arbeitsplätze |
ix |
|
Beispiele der spezifisch entwickelten Formulare des IADS COPRA für das Unfallkrankenhaus Linz |
xi |
|
Formulare der Intensivdokumentation |
xi |
|
Formulare der Anästhesiedokumentation |
xiii |
|
Flow-Chart-Diagramme einer Arbeitsablaufanalyse am Unfallkrankenhaus Linz |
xiv |
|
Textprobe:
Kapitel 5.4.2, Test der Schnittstellen zum Krankenhausinformationssystem Astra und Laborsystem:
Der Test der Schnittstellen zu den beiden genannten Systemen kann zusammengefasst werden, da die Kommunikation zu beiden Informationssystemen im HL7-Standard über den Kommunikationsserver eGate realisiert wurde. Der Austausch der Stammdaten ist auch für das Laborsystem eine neu entwickelte Schnittstelle, sodass alle Testaktivitäten in Kooperation durchgeführt werden können. Wird der Test manuell durchgeführt, müssen Vergleiche zwischen den versendeten und empfangenen Daten angestellt werden. In jedem Fall sollen genau die versendeten Inhalte beim Empfänger auch verarbeitet werden. Ein Skript, das die gesendeten und empfangenen Daten vergleicht, kann hier eingeführt werden. Damit wäre eine Teilautomatisierung erreicht.
Zu den Tests der HL7-Schnittstellen zu den Systemen Astra und datalabX waren die Betreuer des KIS Astra, des Kommunikationsservers eGate, des Laborsystems datalabX und medipart GmbH als Vertreter für die Software COPRA anwesend. Automatisierte Tests konnten nicht eingeführt werden, da der Autor bis zu diesem Zeitpunkt keine anwendbaren Automatisierungen entwickelt hat. Die Zeit, die für solche Umsetzungen benötigt wird, wurde vom Verfasser falsch eingeschätzt und neben der Integrationsarbeit zu niedrig priorisiert. Jeder der Beteiligten dokumentierte die Ergebnisse der Tests in selbstentwickelten Testprotokollen. Die Systembetreuer des eGate protokollierten die Testsitzungen und übergaben allen Teilnehmern per e-Mail diese Protokolle. Testfälle die bei den Schnittstellentests durchgeführt worden sind a. Senden und Empfang einer ADT-Nachricht bei Aufnahme, b. Senden und Empfangen einer ADT-Nachricht bei Änderungen der Stammdaten, c. Senden und Empfangen einer ADT-Nachricht bei Verlegung des Patienten, d. Senden und Empfangen von Befundmitteilungsnachrichten, e. Senden und Empfangen von Diagnosenachrichten, f. Anfordern von Laborbefunden, g. Senden und Empfangen von Laborbefunden.
Die Software COPRA ist im Bereich der genannten Schnittstellen immer empfangendes System, daher musste die korrekte Verarbeitung der empfangenen Daten nachgewiesen werden. Problematisch war die Tatsache, dass vom LIS datalabX bis zuletzt die Bezeichnungen für die Laborbefundparameter geändert wurden, sodass das Mapping auf Seiten des IADS COPRA, wegen mangelnder Informationsweitergabe, oft veraltet war. Die Schnittstellen zum KIS Astra wurden im Vorfeld sehr genau definiert und arbeiteten durch gute Zusammenarbeit bei der Realisierung zum Zeitpunkt der Tests fehlerfrei.
Veränderungen an den Schnittstellen im laufenden Betrieb dürfen nur in Absprache mit allen Beteiligten stattfinden, sonst kann keine Datenintegrität gewährleistet werden. Diese Veränderungen müssen immer getestet werden. Treten Fehler bei der Datenübernahme aus dem KIS Astra oder dem LIS datalabX auf, sind diese nur für Systemadministratoren nachvollziehbar, denn nur diese Personen haben Zugriff auf die Prozesse der Datenübernahme. Nach Überprüfung der physikalischen Netzwerkverbindungen, können Fehler auch in einem Ausfall des HL7-Interface der Software COPRA liegen. Für die Übernahme der Laborbefunde ist ein Deamon verantwortlich. Fällt dieser aus, werden keine Laborbefundnachrichten verarbeitet.
Kapitel 5.4.3, Test der Datenübernahme vom Patientenmonitoring:
Die Daten des Patientenmonitoring werden als HL7-Daten vom Gateway der Firma Philips Medizinische Systeme an den Gerätetreiber der Software COPRA übergeben. Anhand einer Gegenüberstellung der versendeten Daten aus dem Philips- System und der empfangenen Daten des COPRA-Deamon ist der Erfolg der Datenverbindung ablesbar. Hierzu sollten die Werte am Patientenmonitor mehrmals geändert werden, um die Reaktion des IADS COPRA auf veränderte Monitoring-Daten zu untersuchen. Wird dieser Kommunikationsweg manuell getestet, muss eine Gegenüberstellungsliste, die die Ergebnisse der Datenübertragung dokumentiert, angelegt werden. Das automatisierte Testen ist zur Kontrolle dieser Datenübernahme aber vorzuziehen. Der Vergleich der Daten kann funktionell sehr gut in einem Skript umgesetzt werden.
Das korrekte Einlesen der übernommenen Daten in die zugehörige Patientenakte ist nur manuell nachzuvollziehen. Dazu müssen die angezeigten Vitalparameterwerte auf dem Patientenmonitor mit den dargestellten Werten in der COPRA-Akte verglichen werden.
Die Firma Philips Medizinische Systeme versicherte den einwandfreien Zustand der Datenübergabe und beteiligte sich nicht an ausführlichen dokumentierten Tests. Die medipart GmbH hat die Überwachungsmonitore, nach dem von Philips Medizinische Systeme vorgegebenen System, den IADS-Clients zugeordnet und die korrekte Datenübernahme in die Patientenakte getestet. Traten Fehler auf, konnte die Ursache nur im Mapping der Patientenmonitore zu den IADS-Clients oder in der fehlerhaften Zuordnung der Übergabedatei liegen. Fehler wurden sofort lokalisiert, beseitigt und das Ergebnis überprüft. Eine genaue Dokumentation dieser Tests fand nicht statt. Die Tests wurden oft durch den Ausfall des Netzwerkes im Neubau des UKH Linz behindert. Zur Übergabe des Systems waren alle fehlerhaften Zuordnungen identifiziert und beseitigt.
Werden falsche oder keine Daten in die IADS-Patientenakte übernommen muss zuerst überprüft werden, ob in der Akte die korrekte zugeordnete Bettnummer eingegeben wurde. Ist dies abgeklärt können Fehler in den physikalischen Netzwerkverbindungen gesucht werden. Ist der Fehler nach diesen Arbeiten nicht lokalisiert, muss der Systemadministrator den Fehler beim Gerätetreiber oder dem Mapping der Parameter suchen.
|