Konzeption der Übernahme von Daten aus medizinischen Informationssystemen und medizinischen Geräten in ein Intensiv- und Anästhesiedokumentationssystem (IADS)

Inhaltsverzeichnis

I. Abbildungsverzeichnis

II. Abkürzungsverzeichnis

1 Motivation und Zielsetzung
1.1 Ausgangssituation
1.2 Ziel der Arbeit

2 Theoretische Grundlagen
2.1 Intensiv- und Anästhesiedokumentationssysteme
2.1.1 Begriffsdefinition
2.1.2 Probleme des Datenmanagements in der Intensivmedizin und Anästhesiologie
2.1.3 Geschichtliche Entwicklung von Intensiv- und Anästhesiedokumentationssystemen
2.1.4 Bausteine eines Intensiv- und Anästhesiedokumentationssystems
2.1.5 Das Intensiv- und Anästhesiedokumentationssystem COPRA
2.2 Datenaustauschvereinbarungen zwischen medizinischen Informationssystemen
2.2.1 Health Level Seven
2.2.2 Digital Imaging and Communications in Medicine
2.2.3 Extensible Markup Language
2.2.4 Die Initiative Integrating the Healthcare Enterprise
2.3 Integration von Intensiv- und Anästhesiedokumentationssystemen in Krankenhausinformationssysteme
2.3.1 Krankenhausinformationssysteme
2.3.2 Datenintegration im Krankenhausinformationssystem
2.3.3 Integration von Intensiv- und Anästhesiedokumentationssystemen .
2.4 Datenaustauschmöglichkeiten zwischen medizinischen Informationssystemen und medizinischen Geräten
2.4.1 Die Systemarchitektur der indirekten Anbindung
2.4.2 Die Systemarchitektur der direkten Anbindung
2.5 Konkrete Datenaustauschmöglichkeiten zwischen Intensiv- und Anästhesiedokumentationssystem und medizinischen Geräten
2.5.1 Anbindung von Medizintechnik über Gateway-Computer
2.5.2 Direkte Datenübernahme über die serielle Schnittstelle
2.5.3 Datenübernahme mit Hilfe von Geräteinterfaceboxen
2.5.4 Anbindung von Medizintechnik über serielle Multiplexer

3 Systemanalyse am Unfallkrankenhaus Linz
3.1 Allgemeines zum Unfallkrankenhaus
3.2 Analyse der vorhandenen Informationssysteme und Dokumentationsmethoden
3.2.1 Aufnahme und Erstuntersuchung
3.2.2 Notfall-, spezielle Wund- und Ambulanzversorgung
3.2.3 Intensivbehandlung
3.2.4 Anästhesiedokumentation im OP-Bereich
3.2.5 OP-Management und Dokumentation
3.2.6 Leistungsanforderung und Leistungsdokumentation
3.3 Analyse der neuen Infrastrukturen
3.3.1 Operationsbereich / Anästhesiologie
3.3.2 Intensivstation
3.3.3 Brandverletzte
3.3.4 Wachstation
3.4 Resultierende Anforderungen an das Intensiv- und Anästhesiedokumentationssystem COPRA

4 Integration des Intensiv- und Anästhesiedokumentationssystem COPRA am Unfallkrankenhaus Linz
4.1 Planung und Realisierung der Rechentechnik
4.1.1 Hardware für den Einsatz außerhalb der Patientenumgebung
4.1.2 Hardware für den Einsatz in der Patientenumgebung
4.1.3 Server für das Intensiv- und Anästhesiedokumentationssystem
4.1.4 Auswahl der geeigneten Geräteinterfacebox
4.2 Entscheidung und Realisierung der Integration des Intensiv- und Anästhesiedokumentationssystem COPRA
4.2.1 Integration in das Krankenhausinformationssystem Astra
4.2.2 Anbindung des Laborsystems
4.2.3 Datenübergabe an die Qualitätssicherung
4.2.4 Datenübernahme vom Patientenmonitoring
4.2.5 Datenübernahme von der Beatmungs- und Narkosetechnik
4.2.6 Datenübernahme von der Infusionstechnik
4.2.7 Integrationszustand nach Abschluss der Realisierungen

5 Test der Integration des Intensiv- und Anästhesiedokumentationssystem COPRA am Unfallkrankenhaus Linz
5.1 Ziel der Entwicklung und Durchführung von Tests
5.2 Auswahl der Testobjekte
5.3 Der Testprozess
5.3.1 Theorie
5.3.2 Manuelles Testen
5.3.3 Automatisiertes beziehungsweise teilautomatisiertes Testen
5.4 Entwicklung und Durchführung der Tests
5.4.1 Test der spezifisch entwickelten Formulare für das Unfallkrankenhaus Linz
5.4.2 Test der Schnittstellen zum Krankenhausinformationssystem Astra und Laborsystem
5.4.3 Test der Datenübernahme vom Patientenmonitoring
5.4.4 Test der Datenübernahme von der Beatmungs- und Narkosetechnik
5.4.5 Test der Datenübernahme von der Infusionstechnik
5.5 Übertragbarkeit der Tests auf weitere Integrationen des Intensiv- und Anästhesiedokumentationssystems COPRA

6 Diskussion der Ergebnisse
6.1 Bewertung der eingesetzten Hardware
6.2 Bewertung der Integration des Intensiv- und Anästhesiedokumentationssystem COPRA in das bestehende Krankenhausinformationssystem
6.3 Bewertung der Realisierung der Datenübernahme von der Medizintechnik
6.4 Bewertung der durchgeführten Tests

7 Zusammenfassung

III. Quellenverzeichnis

Literatur

Internetseiten

IV. Anhang

Darstellung der umgesetzten Vorschläge zur Konfiguration der Arbeitsplätze

Beispiele der spezifisch entwickelten Formulare des IADS COPRA für das

Unfallkrankenhaus Linz
Formulare der Intensivdokumentation
Formulare der Anästhesiedokumentation

Flow-Chart-Diagramme einer Arbeitsablaufanalyse am

Unfallkrankenhaus Linz

I. Abbildungsverzeichnis

ABBILDUNG 1: DATENFLUSS INNERHALB DES IADS COPRA

ABBILDUNG 2: DARSTELLUNG DER VITALPARAMETER IM IADS COPRA

ABBILDUNG 3: BEISPIEL EINER HL7-NACHRICHT

ABBILDUNG 4: BEISPIEL EINER NACHRICHT IM XML-FORMAT

ABBILDUNG 5: STRUKTUR EINES HOMOGENEN KRANKENHAUSINFORMATIONSSYSTEMS

ABBILDUNG 6: STRUKTUR EINES HETEROGENEN KRANKENHAUSINFORMATIONSSYSTEMS

ABBILDUNG 7: VERNETZUNG DER DATENVERARBEITUNGSSYSTEME EINES KRANKENHAUSES MIT EINEM KOMMUNIKATIONSSERVER

ABBILDUNG 8: SYSTEMATISCHE ÜBERSICHT DER INDIREKTEN ANBINDUNG

ABBILDUNG 9: SYSTEMATISCHE ÜBERSICHT DER DIREKTEN ANBINDUNG

ABBILDUNG 10: ANBINDUNGSSCHEMA BEI VERWENDUNG EINER GERÄTEINTERFACEBOX

ABBILDUNG 11: ANBINDUNGSSCHEMA BEI VERWENDUNG EINES SERIELLEN MULTIPLEXERS

ABBILDUNG 12: DER ALTBAU DES UNFALLKRANKENHAUS LINZ

ABBILDUNG 13: DER NEUBAU DES UNFALLKRANKENHAUS LINZ

ABBILDUNG 14: SCREENSHOT DES STARTBILDSCHIRMS DES KIS ASTRA

ABBILDUNG 15: MEDICAL-PC DER FIRMA ACL GMBH

ABBILDUNG 16: VERÄNDERUNG DER DOKUMENTATIONSMETHODEN MIT DEM IADS COPRA IM INTENSIVBEHANDLUNGSBEREICH

ABBILDUNG 17: VERÄNDERUNG DER DOKUMENTATIONSMETHODEN MIT DEM IADS COPRA IM OP-BEREICH

ABBILDUNG 18: STANDARD-PC DER FIRMA HP-COMPAQ (D530 ULTRA-SLIM-LINE-DESKTOP)

ABBILDUNG 19: OP-PC 17 DER FIRMA ACL GMBH, MONTIERT AN EINEM NARKOSEARBEITSPLATZ ...

ABBILDUNG 20: HP-COMPAQ „PROLIANT ML350 G4“ 19-ZOLL SERVER

ABBILDUNG 21: MOXA NPORT 5410 - GERÄTEINTERFACE MIT VIER SERIELLEN ANSCHLÜSSEN

ABBILDUNG 22: MAßNAHMEN ZUR ABSICHERUNG DER PATIENTENSICHERHEIT BEI EINSATZ EINES MOXA NPORT IN DER PATIENTENUMGEBUNG

ABBILDUNG 23: ÜBERSICHT DER DATENFLÜSSE VON UND ZUM IADS COPRA

ABBILDUNG 24: HL7-NACHRICHT VOM KIS ASTRA AN DAS IADS COPRA (ANONYMISIERT)

ABBILDUNG 25: SCHEMA DES DATENFLUSSES DER LABORBEFUNDE

ABBILDUNG 26: HL7-NACHRICHT VOM LABORSYSTEM AN DAS IADS COPRA (ANONYMISIERT)

ABBILDUNG 27: SCREENSHOT DER STATUSANZEIGE DES MEDIBUS-DEAMON

ABBILDUNG 28: INHALT DER KONFIGURATIONSDATEI DD_DRÄGER.INI

ABBILDUNG 29: INHALT DER KONFIGURATIONSDATEI DD_ARGUS.INI

ABBILDUNG 30: AUSSCHNITT AUS DEM DATENSTROM VON DER INFUSIONSTECHNIK ZUM IADS COPRA

ABBILDUNG 31: STAND DER REALISIERUNG DER DATENÜBERTRAGUNG

ABBILDUNG 32: SCHEMATISCHER ABLAUF AUTOMATISIERTER TESTS

ABBILDUNG 33: UMGESETZTER VORSCHLAG DES VERFASSERS ZUR KONFIGURATION EINES ARBEITSPLATZES IM INTENSIVBEHANDLUNGSBEREICH

ABBILDUNG 34: UMGESETZTER VORSCHLAG DES VERFASSERS ZUR KONFIGURATION EINES ANÄSTHESIEARBEITSPLATZES X

ABBILDUNG 35: FORMULAR 1 - TAGESKURVE

ABBILDUNG 36: FORMULAR 2 - BILANZEN ERNÄHRUNG

ABBILDUNG 37: FORMULAR 5 - ANAMNESE

ABBILDUNG 38: FORMULAR 10 - WUNDMANAGEMENT

ABBILDUNG 39: FORMULAR 4 - OP-VERLAUF

ABBILDUNG 40: FORMULAR 8 - POSTOPERATIVE SCHMERZBEHANDLUNG

ABBILDUNG 41: IST-ANALYSE - AUFNAHME, ERSTUNTERSUCHUNG

ABBILDUNG 42: IST-ANALYSE - NOTFALL-, WUND- UND AMBULANZVERSORGUNG

ABBILDUNG 43: IST-ANALYSE - STATION, INTENSIV- UND OP-BEREICH

ABBILDUNG 44: IST-ANALYSE - LABOR, TAG- UND NACHTBETRIEB

ABBILDUNG 45: IST-ANALYSE - UNTERSUCHUNGS- UND LEISTUNGSANFORDERUNG

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Motivation und Zielsetzung

1.1 Ausgangssituation

Die konventionelle, handgeführte Dokumentation im medizinischen Bereich stößt mit der ständig zunehmenden Menge an Informationen, die dokumentiert werden müssen, an ihre Grenzen. Deshalb werden stufenweise computergestützte Systeme für die Dokumentation in allen Bereichen eines Krankenhauses eingeführt. Die schrittweise Digitalisierung im Krankenhaus führt oft zu Medienbrüchen, die es sukzessive abzubauen gilt. An einem Unfallkrankenhaus in Linz, Österreich, soll ein Intensiv- und Anästhesiedokumentationssystem für die Unterstützung der Dokumentation auf der Intensivstation und im Operationsbereich von Grund auf eingeführt und installiert werden. Dieses Krankenhaus ist bereits mit anderen medizinischen Informationssystemen ausgestattet, die es bei der Integration zu berücksichtigen gilt.

Eine extra formierte Projektgruppe, bestehend aus Pflegekräften und Ärzten des Unfallkrankenhauses, hat sich für das Intensiv-und Anästhesiedokumentationssystem COPRA der Firma COPRA-System GmbH entschieden. Den Vertrieb und die Installation des Systems übernimmt die medipart GmbH. Die medipart GmbH hat die Aufgabe, den Aufbau des Intensiv- und Anästhesiedokumentationssystem von der Beschaffung der Hardware bis zur Realisierung der Datenübermittlung zwischen den vorhandenen medizinischen Informationssystemen und der Medizintechnik zu realisieren.

1.2 Ziel der Arbeit

Diese Arbeit beschäftigt sich mit der Integration des gewählten Intensiv- und Anästhesiedokumentationssystems COPRA am Unfallkrankenhaus Linz. Die Aufgabe umfasst die Analyse der Situation, in der das System integriert werden soll, bis hin zur praktischen Umsetzung und Test der Integration. Das Ziel besteht darin, geeignete Kommunikationsverbindungen für den Datenaustausch mit den vorhandenen Informationssystemen zu empfehlen und zu realisieren. Des Weiteren sollen die Daten verschiedener medizintechnischer Systeme automatisch im neuen System dokumentiert werden. Für diese automatische Dokumentation gilt es die möglichen Anbindungswege zu bestimmen und umzusetzen. Der Test der Integration bildet den Abschluss der Arbeit.

2 Theoretische Grundlagen

2.1 Intensiv- und Anästhesiedokumentationssysteme

2.1.1 Begriffsdefinition

Ein Intensiv- und Anästhesiedokumentationssystem (nachfolgend IADS) ist ein elektronisches Datenverarbeitungssystem, das speziell in den Bereichen der Intensivmedizin^[1] und Anästhesiologie^[2] in einem Krankenhaus Anwendung findet. Diese Systeme dienen der Dokumentation von patientenbezogenen oder therapeutischen Daten zur genauen Darstellung des medizinischen Verlaufes und weiterhin zur Erhebung von Qualitäts- und Kostenparametern. Die konventionelle handgeführte Dokumentation in Intensiv- und Operationsabteilungen umfasst in der Regel Vitalparameter, Beatmungswerte, Laborbefunde, das Flüssigkeitsmanagement, also Ein- und Ausfuhr von Flüssigkeiten, die Verordnung und Gabe von Medikamenten, Pflegeverlauf und -planung. Medizinische Dokumentation dient primär der Darstellung medizinischer Leistungen aber auch zur Sicherung der Versorgungsqualität und zur Hilfe bei forensischen^[3] Fragestellungen. [vgl.FEUERSTEIN00:S.5]

IADS werden oft auch als Patientendatenmanagementsysteme (PDMS) bezeichnet; dieser Begriff beschreibt die Funktion allerdings zu allgemein.

2.1.2 Probleme des Datenmanagements in der Intensivmedizin und Anästhesiologie

[FEUERSTEIN00:S.6] beschreibt, „Alleine die Dokumentation aller erfassten klinischen Parameter eines Pflegetages eines instabilen Intensivpatienten generiert mehr als 2000 Messwerte und zusätzlich bis zu 1000 daraus abzuleitender weiterer Daten. Eine umfassende Dokumentation sämtlicher relevanter Parameter stellt für das ärztliche Personal und das Pflegepersonal auf Intensivstationen einen erheblichen Arbeitsaufwand dar.“ Im Bereich der Anästhesiologie fehlt oft die Zeit für eine ausreichende Erfassung der Daten, bedingt durch Notfallsituationen.

Die Entscheidungsprozesse im Krankenhaus werden durch die stetig wachsende Menge erfasster Parameter immer komplexer. Das Personal verlangt von der Visualisierung der Reaktionen eines Patienten auf therapeutische Veränderungen Nachvollziehbarkeit sowie eindeutige Aussagen. Diese Anforderung ist mit manuellen Methoden der Dokumentation nicht zu erfüllen, denn die enorm große Zahl von anfallenden Daten und Parametern ist von Hand kaum korrekt zu erfassen. [vgl.FEUERSTEIN00:S.6] „Nach einer Untersuchung österreichischer Autoren gehen schätzungsweise bis zu 30% aller generierter bzw. erfasster Daten im Rahmen einer herkömmlichen (handschriftlichen) Pflegedokumentation verloren.“, belegt [FEUERSTEIN00:S.6] die Aussagen. Aufgrund dieser Tatsache ist die forensische Verwertbarkeit der handgeführten Patientendatendokumentation stark zu hinterfragen. An der Universitätsklinik Regensburg wurde in einer internen Untersuchung errechnet, dass bei zehn Intensivpflegebetten circa vier bis fünf ärztliche und schätzungsweise acht bis zehn pflegerische Arbeitsstunden pro Tag für die Dokumentation aufgewendet werden müssen. Eine weitere Fehlerquelle ist in der Größe und der damit umständlichen Handhabung der heute üblichen Patientenkurven zu finden. Beim Schichtwechsel ist mangelhafter Informationsaustausch und unzureichende Übergabe der Dokumentation die Regel. Aus den genannten Aspekten begründet sich die Notwendigkeit des Einsatzes eines IADS in der heutigen Intensivpflege und Anästhesie. [vgl.FEUERSTEIN00:S.6f.]

2.1.3 Geschichtliche Entwicklung von Intensiv- und Anästhesiedokumentationssystemen

Der erste klinische Einsatz von elektronischen Dokumentationssystemen ist Ende der 60er und in den frühen 70er Jahren in den USA zu verzeichnen. Diese Systeme wurden entwickelt, um die wachsende Anzahl der medizinischen Parameter aus Überwachung der Patienten und Leistungen am Patienten zu erfassen. Ab dem Jahr 1995 gab es bereits mehrere kommerziell erhältliche computergestützte IADS. In Europa wurden zu diesem Zeitpunkt noch wenige derartige Systeme tatsächlich in Krankenhäusern eingesetzt. Als Gründe dafür werden die Skepsis der Mediziner gegenüber der Informationstechnologie sowie die hohen Anschaffungskosten gesehen. Ein weiterer Grund für die geringe Akzeptanz von digitalen Dokumentationssystemen war zu dieser Zeit der fehlende Nachweis ihres tatsächlichen Nutzens. Die Befürchtung, dass die vermeintliche Ersparnis von Arbeitszeit als Argument für Einsparungen beim Intensivpflegepersonal verwendet werden könnte, verhinderte ebenfalls eine positive Einstellung gegenüber IADS. Die Forcierung der Integration von IADS an großen Kliniken in den letzten Jahren ist hauptsächlich auf die Umstrukturierung der Gesundheits- und Sozialsysteme im finanziellen Bereich zurückzuführen. Damit stiegen auch die Anforderungen an die Qualität der medizinischen Dokumentation zur Leistungserfassung. Die Bedeutung der Qualitätssicherung in pflegerischen und ärztlichen Bereichen und vor allem die Ausschöpfung der Möglichkeiten der handgeführten Dokumentation und die damit auftretenden Probleme zwangen zu einer anderen Einstellung des Krankenhauspersonals gegenüber der elektronischen Dokumentationsmethode. [vgl.FEUERSTEIN00:S.8]

2.1.4 Bausteine eines Intensiv- und Anästhesiedokumentationssystems

Das Kapitel 2.1.4 basiert auf den Ausführungen von [FEUERSTEIN00:S.14f.]. Das Kernstück eines IADS ist das Datenbanksystem (nachfolgend DBS), das die erfassten Daten archiviert und zur Verfügung hält. Die Flexibilität und die Zuverlässigkeit eines IADS hängen vom DBS ab. Von Vorteil ist die Verwendung eines offenen DBS, also einer Datenbanksoftware, die über offen gelegte Schnittstellen verfügt. Viele kommerzielle DBS sind heute als relationale Datenbanken ausgeführt. Dies bedeutet, dass die Daten in Tabellen gehalten werden, die über Relationen (Verknüpfungen) verbunden sind. Structured query language (nachfolgend SQL) ist eine Programmiersprache für relationale Datenbanken. Die Weiterentwicklungen gehen heute in Richtung objektorientierter Datenbanken. Diese sind noch flexibler und ermöglichen die Festlegung wesentlich komplexerer Zusammenhänge.

Ein handelsüblicher Computer, der bettseitig installiert ist, dient der Dokumentation der Daten und bildet die Benutzerschnittstelle.

Ein IADS ist in der Lage, klinische Parameter von medizinischen Geräten, die der Patientenversorgung und -überwachung dienen, automatisch zu übernehmen. Im Layout der Darstellung der Patientendaten liegt eine der Stärken des IADS. Die farbige Darstellung der klinischen Parameter ist im Vergleich zu einer papiergestützten Dokumentation visuell schneller zu erfassen und auszuwerten. Die Lesbarkeit der Patientenakte nimmt, bei Einsatz der elektronischen Dokumentation, deutlich zu. Pflegepersonal und Ärzte können am Computerarbeitsplatz eines IADS mit Zusatzinformation wie Lehrmaterial und Medikamenteninformation versorgt werden oder Zugriff auf medizinische Datenbanken sowie das Hausnetzwerk (Intranet) erhalten.

2.1.5 Das Intensiv- und Anästhesiedokumentationssystem COPRA

Im Folgenden soll die Software COPRA so genau und umfassend wie möglich beschrieben werden. Dieser Beschreibung liegt das Wissen aus der bisherigen Arbeit des Verfassers mit dem System COPRA und den Ausführungen in [COPRA03:S.1f.], [COPRA04:S.2,4] sowie [COPRA05] zu Grunde.

COPRA ist das Akronym für Computer-Organized-Patient-Report-Assistent. Diese Software ist ein Dokumentationshilfsmittel. Sie ist nicht zur Diagnosestellung bestimmt und unterliegt damit nicht dem Medizinproduktegesetz (MPG). Dies ist so festgelegt und begründet durch den Hersteller des IADS COPRA, der COPRA-System GmbH.

Die Software COPRA, eine 32-Bit-Windows-Applikation, entwickelt mit C++^[4], besteht aus der Basissoftware, einem veränderbaren Datenpräsentator und anpassbaren Geräte- und Datenbankschnittstellen. Die Anpassungen werden nach Analysen und Absprachen mit den zukünftigen Anwendern vorgenommen. Um mit dem IADS COPRA arbeiten zu können, wird an jedem Ort der Patientenversorgung, wie Intensivbett oder Operationstisch, ein Computer benötigt. Diese Computer übernehmen automatisch die Daten der Beatmungsgeräte oder Patientenmonitore etc. Zentrale Arbeitsplätze sind keinem Bett oder Eingriffsort zugeordnet und übernehmen keine Werte von medizinischen Geräten. Sie dienen der Präsentation, zum Beispiel bei Besprechungen. Das Einsatzgebiet vom IADS COPRA in sensiblen medizinischen Bereichen fordert gerade von der Datenbank neben einer großen Flexibilität und Zugriffsgeschwindigkeit eine extrem hohe Zuverlässigkeit. Aus diesem Grund wurde von der COPRA-System GmbH die objektorientierte ATROPOS-Datenbank entwickelt. Die Datenbank ATROPOS ist in jedem Zustand ihrer Existenz konsistent und selbststrukturierend. „Mögliche Zerstörungen der Datenbank, z.B. durch Stromausfall zum Zeitpunkt eines Schreibzugriffes, werden dadurch verhindert, dass die Daten letztendlich durch einen atomaren Schreibzugriff (Schreiben eines Sektors) vorgenommen werden. Ein Dateneintrag ist entweder gültig oder das Schreiben scheitert vollständig. Im genannten schlimmsten Fall scheitert der Schreibzugriff für das betreffende Datenfeld, ohne Inkonsistenzen zu hinterlassen.“ [COPRA04:S.4] Die Datenbank ermöglicht gleichzeitige Lese- und Schreibzugriffe auf die Daten eines Patienten. Alle in der Datenbank ATROPOS erfassten Daten werden in zyklischen Abständen in eine SQL-Datenbank, bezeichnet als ANACONDA, geschrieben und sind so leicht statistisch auswertbar oder an andere Systeme verteilbar.

ABBILDUNG 1: DATENFLUSS INNERHALB DES IADS COPRA

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1 zeigt die Verknüpfung zwischen den Computern des IADS COPRA, der Primärdatenbank ATROPOS auf dem COPRA-Server und der Sekundärdatenbank ANACONDA. Jeder Client des IADS COPRA speichert die Daten zuerst auf der internen Festplatte, nach einem bestimmten Zeitintervall oder auf Anweisung des Anwenders, sendet der Client die neuen Daten automatisch an die Datenbank ATROPOS. Fällt die Primärdatenbank oder das Netzwerk aus, ist durch diese redundante Datenhaltung die Dokumentation weiter möglich. Ist die Datenbank wieder erreichbar, gleicht der bettseitige Computer die Daten automatisch mit dieser ab. Fällt ein Rechner im COPRA-System aus, so kann die Patientenakte an jedem anderen Computer des Systems geöffnet und bearbeitet werden. Von jedem Arbeitsplatz, ob zentral oder bettseitig, können alle mit dem IADS COPRA jemals erfassten Daten aufgerufen und eingesehen werden. Grundvoraussetzung hierfür ist die Vernetzung des Systems und eine zentrale Datenhaltung. Damit sind Dokumentationsvorgänge in einer Patientenakte zur gleichen Zeit an unterschiedlichen Orten mit Hilfe der Datenbank ATROPOS möglich. Der Knotenrechner, der die Daten bereithält, bildet gleichzeitig die Verbindung zum klinikweiten Informationsnetz und schafft so die technische Voraussetzung für den Datenaustausch zwischen dem IADS COPRA und anderen medizinischen Informationssystemen in einem Haus.

Mit dem IADS COPRA wird direkt in Formulare dokumentiert. Diese Art der Dokumentation folgt den Arbeitsschritten bei der Papierdokumentation und orientiert sich stark an dem Aussehen benutzter Formulare in Papierform. Die präsentierten Formulare sind nach den Wünschen der Anwender gestaltbar.

ABBILDUNG 2: DARSTELLUNG DER VITALPARAMETER IM IADS COPRA

Abbildung in dieser Leseprobe nicht enthalten

Eine besondere Rolle im IADS COPRA spielt die Darstellung zeitabhängiger Messwerte. Diese Messwerte werden grafisch oder auch als Zahlenwert dargestellt. In einer solchen Grafik, wie in Abbildung 2 gezeigt, sind alle wichtigen Parameter eines Patienten für einen wählbaren Zeitraum sichtbar. Viele Daten können sowohl manuell als auch automatisch in das IADS COPRA übernommen werden. Das System COPRA greift nicht in die Arbeitsweise der medizinischen Geräte ein, das heißt, es beeinflusst nicht die Funktionalität der angeschlossenen Geräte. Mit dem IADS COPRA werden die Informationen der Geräte mit Hilfe so genannter Deamonen (Gerätetreiber) lediglich entgegengenommen, gespeichert und in grafischer oder tabellarischer Form präsentiert.

Die COPRA-Applikation liest beim Start die Software-Konfigurationsdateien ein, in denen Pfade zu Programmen und Diensten, zu wichtigen Dateien usw. definiert sind. Auch das Aussehen und Verhalten der Applikation lässt sich in gewissem Ausmaß über diese Konfigurationsdateien bearbeiten. Es existiert eine globale Konfiguration in der Datei Co32_000.ini, in dieser werden Parameter definiert, die für jeden Clientcomputer im IADS COPRA gleichermaßen gelten. In der clientspezifischen Co32_0xx.ini werden Parameter eingestellt, die nur diesen Clientcomputer betreffen. Diese Dateien geben ebenfalls vor, welche Deamonen die Software laden muss und welche Parameter der Medizintechnik in den Formularen darzustellen sind.

2.2 Datenaustauschvereinbarungen zwischen medizinischen Informationssystemen

„Zwischen zwei kommunizierenden Anwendungsbausteinen [eines Gesamtsystems, der Verfasser] muss […] eine Vereinbarung über Syntax und Semantik der auszutauschenden Nachrichten bestehen. Aufwände für Implementierung und Betrieb von Kommunikationsbeziehungen können deutlich reduziert werden, wenn hierzu etablierte Kommunikationsstandards eingesetzt werden. Kommunikationsstandards leisten damit auch einen entscheidenden Beitrag zur Herstellung semantischer Integrität.“ [LEHMANN02:S.523]

Die am häufigsten akzeptierten Kommunikationsstandards und Kommunikationsbeschreibungen sind

- Health Level Seven (siehe Kap. 2.2.1),
- Digital Imaging and Communications in Medicine (siehe Kap. 2.2.2),
- die Beschreibungssprache extensible markup language (siehe Kap. 2.2.3), x die Initiative Integrating the Healthcare Enterprise (siehe Kap. 2.2.4). Nicht berücksichtigt werden sollen in dieser Arbeit
- xDT,
- EDIFACT,

da diese Standards hauptsächlich im Bereich der Praxiscomputersysteme der niedergelassenen Ärzte eingesetzt werden.

2.2.1 Health Level Seven

Die folgenden Darlegungen zum Kommunikationsstandard Health Level Seven stützen sich auf [LEHMANN02:S.524], [SCHADOW00:S.57f.] und [SCHMIDT04a].

Health Level Seven (nachfolgend HL7) hat seinen Ursprung in den USA, wo eine Organisation aus Kliniken, Softwareherstellern, Beratungsunternehmern und privaten Mitgliedern 1987 folgendes Ziel formulierte: „‚to provide standards for the exchange of data among healthcare computer applications that eliminates or substantially reduces the custom interface programming and program maintance that may otherwise be required‘“ [zit.in SHADOW00:S.57]. Dies bedeutet, einen Kommunikationsstandard für das Gesundheitswesen zu entwerfen, der keine Einschränkung auf ein medizinisches oder medizintechnisches Spezialgebiet oder auf bestimmte Organisationsformen im Gesundheitswesen enthält.

Der Name „Health Level Seven“ drückt aus, dass die Kommunikation auf der Ebene 7, der Anwendungsschicht des ISO/OSI-Referenzmodells^[5]. stattfindet. Die Literatur weist aber darauf hin, dass HL7 nie den Grundsätzen oder Terminologien des Modells entsprochen hat.

„HL7 beschreibt, zu welchen Ereignissen Nachrichten mit welchem Aufbau zwischen Anwendungsbausteinen im Gesundheitswesen und speziell im Krankenhaus ausgetauscht werden. […]“ [LEHMANN02:S.524] Der für die Nachricht verwendete Nachrichtentyp ist vom Typ des eingetretenen Ereignisses abhängig.

HL7-Nachrichten werden in Segmente unterteilt. Jede Nachricht beginnt mit dem so genannten Kopf, hier wird definiert, welche Krankenhausinformationssystemteile miteinander kommunizieren sollen und welcher Nachrichtentyp mit welchen Ereignissen vorliegt. Danach folgen die Segmente mit den Dateninhalten. Das HL7- Standarddokument definiert 66 Nachrichtentypen, 62 Segmente, über 700 Datenelemente und über 20 Datentypen, deren umfassende Darstellung und Untersuchung nicht Gegenstand dieser Arbeit ist.

Abbildung in dieser Leseprobe nicht enthalten

ABBILDUNG 3: BEISPIEL EINER HL7-NACHRICHT QUELLE: ABGEÄNDERT AUS [SCHADOW00:S.161]

Das Beispiel in Abbildung 3 zeigt eine HL7-Nachricht vom Typ ADT-A01, d.h. den Austausch von Stamm- und Bewegungsdaten (ADT) zu einem Patienten bei Aufnahme (A01). Hier versendet das System REGADT an das empfangende System LABADT. Im PID-Segment (patient id) werden Name, Vorname sowie Adresse zur Übermittlung bereitgestellt. Das NK1-Segment (next of kind) dient unter anderem zur Benennung von nächsten Angehörigen. Im PV1-Segment (patient visit) werden alle relevanten Daten zum aktuellen Aufenthalt des Patienten definiert.

In der neuen Version 3 baut HL7 auf einem hierarchischen System zur Definition der Kommunikationsvorgänge auf. Das übergeordnete Modell wird bezeichnet als Reference Information Model (nachfolgend RIM). Aus dem RIM werden die grundlegenden Kommunikationsvorgänge abgeleitet. In den folgenden, verfeinerten Modellen, den Refined Message Information Models (R-MIM), werden verwandte Nachrichten zu Gruppen zusammengefasst. Aus diesen Gruppen heraus werden die tatsächlichen Nachrichten in Hierarchical Message Definitions (HMDs) erklärt.

Dieses hierarchische System macht es möglich, konsistente Nachrichtenstrukturen für alle benötigten Kommunikationsfälle zu entwerfen und garantiert gleichzeitig noch die erforderliche Flexibilität, um allen Anforderungen gerecht zu werden. HL7 ist in den heute aktuellen Versionen geeignet für

- die Administration von Stamm- und Bewegungsdaten, x die Erteilung von Aufträgen,
- Anfragen an Informationssysteme, x die Befundberichterstattung, x die Dokumentenverwaltung, x die Termin- und Ressourcenplanung, x die Patientenüberweisung,
- die Therapie- und Pflegeplanung.

2.2.2 Digital Imaging and Communications in Medicine

Digital Imaging and Communications in Medicine (nachfolgend DICOM) wurde 1993 von einem gemeinsamen Komitee des American College of Radiology (ACR) und der National Electrical Manufacturers Association der USA (NEMA) als offener Standard zum Austausch von Bilddaten in der Medizin vorgestellt. [vgl.SCHMIDT04b]

DICOM ist für die Integration bildgebender Systeme in der Medizin über Standardnetzwerkschnittstellen in das Informationssystem eines Krankenhauses entwickelt worden. Durch DICOM werden Bilddaten mit diagnostischen Informationen zwischen verschiedenen Systemen austauschbar. Der Austausch ist über das Netzwerk sowie über Speichermedien, wie CD oder DVD, realisierbar. Zum Versenden der Daten per e-Mail ist ein eigener Multimedia-Typ, bezeichnet als, MIME-Type, definiert. Der Einsatz des DICOM-Standards stellt sicher, dass die auf den Medien gespeicherten Daten auch für Systeme anderer Hersteller lesbar sind. Der aktuelle DICOM-Standard stellt 27 Transfersyntaxen und 110 Objektklassen zur Verfügung, die der Darstellung von medizinischen Bilddaten dienen. [vgl.SCHMIDT04b]

In Arbeitsgruppen wird der Standard ständig weiterentwickelt, „um mit technischen Innovationen Schritt zu halten, neue Vorschriften und Bestimmungen umzusetzen, fehlende Funktionalitäten in einem laufenden Prozess zu ergänzen und den Standard kontinuierlich zu verbessern.“ [SCHMIDT04b] Bietet ein Hersteller von bildgebenden medizinischen Geräten DICOM als Zusatzoption an, muss der Standard dabei nicht in vollem Umfang implementiert, aber die unterstützten Funktionen müssen vom Hersteller dokumentiert sein. Diese Dokumentation, bezeichnet als Conformance Statement, zeigt auch, welche Funktionen über den Standard hinaus eingebettet sind. [vgl.SCHMIDT04b]

2.2.3 Extensible Markup Language

Die extensible markup language (nachfolgend XML) entstand 1996 durch die Arbeit des W3-Konsortiums. Der Internet Explorer 4 unterstützte im Herbst 1997 bereits in begrenztem Umfang XML. Dadurch begann eine neue Form der Web- Sprachen, denn XML bietet die Möglichkeit, eigene Tags, „Ein von spitzen Klammern umschlossener Elementname, der zur Auszeichnung eines Dokuments verwendet wird.“ [DEF01], oder Attribute selbst zu definieren und zu nutzen. XML ist damit die Basis für weitere Sprachen, die aus ihr heraus erstellt werden können. Die Anzahl der Tags ist in XML nicht begrenzt, hier wird die Sprache sehr viel flexibler als die statische hypertext markup language (nachfolgend HTML). Im Gegensatz zur HTML trennt XML zwischen den Daten und der Darstellung dieser Daten im Browser. Die Darstellung der Daten wird über die extensible stylesheet language (XSL) realisiert. XML versteht sich eindeutig als Erweiterung von HTML. [vgl.SEEBOERGER03:S.22ff.]

XML ist durch seine hohe Flexibilität auch für die Kommunikation zwischen medizinischen Informationssystemen interessant. Durch das freie Definieren von Tags können Lücken in vorhandenen Standards geschlossen werden. Im Beispiel einer Nachricht im XML-Format in Abbildung 4 wird die eigene, frei definierte Anweisung (Tag) Adresse deklariert, die zum Austausch der Informationen mit den ebenfalls frei definierten Attributen genutzt wird.

Abbildung in dieser Leseprobe nicht enthalten

ABBILDUNG 4: BEISPIEL EINER NACHRICHT IM XML-FORMAT QUELLE: ABGEÄNDERT AUS [SEEBOERGER03:S.55]

2.2.4 Die Initiative Integrating the Healthcare Enterprise

Die Initiative Integrating the Healthcare Enterprise (nachfolgend IHE) entwickelt keine neuen Standards, sondern schreibt jährlich ein technisches Rahmenwerk fort, dessen Ziel es ist, eine maximale Kommunikationsfähigkeit digitaler Systeme zu erreichen. Dazu werden bestehende Standards, hauptsächlich DICOM und HL7, konsequent genutzt und neue Eigenschaften für IHE-Systeme formuliert. Sinnvolle, durch Evaluation entstandene Standardwerte werden diesen Eigenschaften zugewiesen und entsprechende Profile definiert. Den Prozess begleiten Anwender und Anbieter gleichermaßen. [vgl.IHE05] Die Ergebnisse aus der Arbeit der Initiative IHE finden ihren Einsatz hauptsächlich im Bereich der Informationssysteme der Radiologie^[6].

2.3 Integration von Intensiv- und Anästhesiedokumentationssystemen in Krankenhausinformationssysteme

„Integration ist der Zusammenschluss von Teilen zu einem Ganzen, das gegenüber seinen Teilen eine neue Qualität aufweist. Ein integriertes KIS [=Krankenhausinformationssystem, der Verfasser] besteht nicht nur aus einer Menge unabhängiger Komponenten, sondern die Komponenten arbeiten auch eng zusammen. Unterschiedliche Arten der Zusammenarbeit können zu unterschiedlichen Qualitäten der Integration führen.“ [zit.in LEHMANN02:S.517]

2.3.1 Krankenhausinformationssysteme

Der Begriff Krankenhausinformationssystem (nachfolgend KIS) wird wie folgt definiert: „Ein Krankenhausinformationssystem ist das Teilsystem eines Krankenhauses, welches alle informationsverarbeitenden (und -speichernden) Prozesse und die an ihnen beteiligten menschlichen und maschinellen Handlungsträger in ihrer informationsverarbeitenden Rolle umfasst.“ [R. Haux, 1995 zit.in DUGAS03:S.83]

Das KIS soll den Mitarbeitern eines Krankenhauses bei der Abarbeitung ihrer Aufgaben helfen und ist dadurch ausgedehnt auf alle Bereiche, alle Gebäude und alle Personengruppen eines Krankenhauses. [vgl.LEHMANN02:S.476] Ziel eines KIS muss es sein, patientenbezogene Daten korrekt und aktuell zu erfassen und am richtigen Ort der berechtigten Person bereit zu stellen.

[DUGAS03:S.84] sieht die Hauptaufgaben eines KIS in

- der Unterstützung der Patientenbehandlung,
- dem Führen der Krankenakte
- der Arbeitsorganisation und Ressourcenplanung,
- dem Krankenhausmanagement
- der Unterstützung von Forschung und Lehre.

Diese Aufgaben werden von [DUGAS03:S.84ff.] genauer erklärt. Die Patientenbehandlung bildet den Kernprozess in einem Krankenhaus und das KIS sollte diesen Prozess von der Aufnahme bis zur Entlassung, möglichst in allen Teilprozessen, unterstützend begleiten. Krankenakten von Patienten bestehen aus einer Vielzahl von zum Teil unterschiedlichen Dokumententypen. Diese Typen müssen flexibel definierbar sein. Die Übernahme von bereits erfassten Daten in diese Dokumente soll erleichtert werden. Die zeitnahe und komplette Dokumentation wird durch ein KIS kontrolliert, sodass Mängel früh zu entdecken und zu korrigieren sind. Die Übersicht über Verfügbarkeit des Personals, der Räume und Materialien soll von einem KIS gegeben werden können. Das KIS hilft hier bei der Planung und Bestellung der Ressourcen. Auch terminliche Aufgaben, wie zum Beispiel der Hinweis auf anstehende sicherheitstechnische Kontrollen von medizinischen Geräten, können über das KIS kontrolliert werden. Im Bereich des Krankenhausmanagement werden über das KIS Statistiken und Berichte erstellt, deren Daten vom Controlling gesammelt und zur Auswertung bereitgestellt werden. Auch die Abrechnung erbrachter Leistungen nach Außen und die innerbetriebliche Abrechnung kann über ein solches System realisiert werden. Das KIS spielt weiterhin bei der Bereitstellung von Aus- und Weiterbildungsmaterial, Forschungsstudien oder dem Zugriff auf Literatur in elektronischer Form eine Rolle. Die Struktur von Krankenhausinformationssystemen wird heute unterschieden in homogene KIS, also in sich geschlossene Softwarelösungen, oder heterogene, dezentrale KIS. [vgl.LIPINSKI99:S.331f.]

Abbildung in dieser Leseprobe nicht enthalten

ABBILDUNG 5: STRUKTUR EINES HOMOGENEN KRANKENHAUSINFORMATIONSSYSTEMS QUELLE: VERFASSER NACH [LIPINSKI99:S.333]

Homogene Lösungen bieten eine komplette Abdeckung aller Aufgaben eines KIS mit nur einem Softwareprodukt an. Die Kommunikation der einzelnen Abteilungsbereiche erfolgt nach internen Strukturen, es kann daher von vollständiger Integrität ausgegangen werden. Durch die Datenhaltung in nur einem Datenbanksystem ist eine übergreifende Sichtweise auf die Daten möglich. Diese homogenen Systeme sind kaum erweiterbar und decken oft nicht den kompletten Bedarf ab, da die Spezialisierung auf jeden einzelnen Bereich einer Klinik nicht gewährleistet wird. Abbildung 5 zeigt die Struktur eines homogenen KIS. [vgl.LIPINSKI99:S.331f.]

Abbildung in dieser Leseprobe nicht enthalten

ABBILDUNG 6: STRUKTUR EINES HETEROGENEN KRANKENHAUSINFORMATIONSSYSTEMS QUELLE: VERFASSER NACH [LIPINSKI99:S.334]

Heterogene KIS entstehen aus einem führenden System, für die Administration der Patientendaten und die Leistungsabrechnung, und dezentralen Subsystemen, die über ein Netzwerk zu einem Gesamt-KIS zusammengefasst werden (siehe Abbildung 6). Der Vorteil der heterogenen Lösung ist eine umfassende Abdeckung und individuelle Anpassung spezieller Abteilungsaufgaben. Die Verantwortung für die Datenhaltung unterliegt der jeweiligen Abteilung. Verändert sich eine Abteilung, so ist das Teilsystem schnell anpassbar. [vgl.LIPINSKI99:S.331f.]

2.3.2 Datenintegration im Krankenhausinformationssystem

„Datenintegration […] ist in einem KIS dann gewährleistet, wenn ein Datum, das im Rahmen einer Aufgabe einmal erfasst wurde, innerhalb des KIS nicht wieder erfasst werden muss, auch wenn es im Rahmen dieser oder einer anderen Aufgabe wieder benötigt wird. Das bedeutet, dass einmal erfasste Daten immer dort verfügbar sind, wo sie gerade benötigt werden.“ [LEHMANN02:S.517]

Zur Sicherung der Integrität der Daten in einem KIS stehen Software-Lösungen zur Verfügung, die in heterogenen sowie homogenen KIS die Kontrolle und den Aufbau von Kommunikationsverbindungen übernehmen. Sie werden als Kommunikationsserver bezeichnet. Die in Kapitel 2.2 beschriebenen Kommunikationsmöglichkeiten werden akzeptiert und ermöglichen eine Strukturierung der Nachrichten, sodass die Verständigung zwischen sendendem und empfangendem System gewährleistet werden kann. Ein Kommunikationsserver ist in der Lage, Nachrichten im Format eines Standards in das Format eines anderen Standards zu ändern. Die asynchrone Kommunikation zwischen den Teilsystemen des KIS wird dadurch unterstützt und eine Datenintegration hergestellt. [vgl.LEHMANN02:S.521]

Abbildung in dieser Leseprobe nicht enthalten

ABBILDUNG 7: VERNETZUNG DER DATENVERARBEITUNGSSYSTEME EINES KRANKENHAUSES MIT EINEM KOMMUNIKATIONSSERVER QUELLE: VERFASSER NACH [LANGE97: S.3]

Die Aufgabe eines Kommunikationsservers besteht nicht in der Generierung von Nachrichten. Diese Aufgabe wird von den Subsystemen eines KIS übernommen. Ein Kommunikationsserver nimmt die Nachrichten von einem Subsystem entgegen und leitet diese nach definierten Regeln (colaborations) an ein oder mehrere Subsysteme weiter. [vgl.LANGE97:S.13] [LANGE97:S.13f.] beschreibt die Aufgaben eines Kommunikationsserver genauer. Nachdem die Nachricht vom Subsystem entgegengenommen wurde, also dateibasiert oder dateilos über ein Standard- Transportprotokoll vom Kommunikationsserver eingelesen wurde, muss der Empfänger dieser Nachricht ermittelt werden. Der Empfänger wird entweder durch den Typ der Nachricht bestimmt oder ist in der Nachricht selbst benannt. Sind die empfangenden Subsysteme ermittelt, wird die Nachricht an genau diese versandt. Gibt es die Regel vor, muss die Struktur der Nachricht in die erwartete Struktur des empfangenden Systems transformiert werden.

Eingehende Nachrichten werden in Bezug auf Kommunikationsserver InboundNachrichten genannt. Nachrichten, die den Kommunikationsserver verlassen, heißen Outbound-Nachrichten.

[LEHMANN02:S.522] sagt zusammenfassend: „Ein Kommunikationsserver ist also ein Werkzeug, mit dem die Kommunikation und Datenintegration auch in einem großen KIS effizient unterstützt werden kann.“ Daraus ergibt sich für den Verfasser, dass sich auch die Datenintegration eines intensivmedizinischen Informationssystems über einen Kommunikationsserver am effizientesten gestalten lässt.

2.3.3 Integration von Intensiv- und Anästhesiedokumentationssystemen

Betrachtet werden soll die Integration eines IADS in ein heterogenes Krankenhausinformationssystem. Nach der Integration sollen zusätzliche informationsverarbeitende Methoden in dem betroffenen KIS zur Verfügung stehen oder vorhandene Methoden mit einer höheren Qualität angewendet werden können. Das IADS soll durch die Integration zu einem Bestandteil des KIS werden. [vgl.GMDS96:S.63]

Dazu müssen nach [GMDS96:S.63f.] folgende Schritte durchlaufen werden:

- Darstellung des Ist-Zustandes des KIS
- Ermitteln der Methoden, die neu realisiert oder verbessert werden sollen
- Ermitteln der Anwendungssoftware, die hierfür eingesetzt werden kann,/p> - Ermitteln der erforderlichen Hardware zur Umsetzung
- Beschaffung und Installation der gewählten Anwendungssoftware
- Ermitteln notwendiger Kommunikationsverbindungen
- Ermitteln notwendiger Datenübermittlungsverbindungen

2.4 Datenaustauschmöglichkeiten zwischen medizinischen Informationssystemen und medizinischen Geräten

Aufgrund der stetig wachsenden Verarbeitung digitaler Datenmengen zur Dokumentation in der Medizin sind die Hersteller von medizinischen Geräten in der Pflicht, eine Schnittstelle zur Verfügung zu stellen, die die Daten des Gerätes, zum Beispiel Messwerte oder Einstellungswerte, liefert und für die informationstechnische Verarbeitung verwertbar macht. Hier gibt es verschiedene Ansätze.

Die Gerätehersteller, deren Produkte bereits über Betriebssysteme aus dem Personalcomputer(PC)-Bereich betrieben werden, versenden die medizinisch relevanten Daten, oft als TCP/ IP^[7] -Pakete über ein Netzwerkinterface. Einige Hersteller sammeln die Daten der Einzelgeräte, um sie eventuell an zentraler Stelle einsehbar zu machen. Dafür werden meist Transportprotokolle aus dem PC-Bereich genutzt.

Viele Geräte bieten ihre Daten seriell an, entweder werden diese dann kontinuierlich an einer Schnittstelle des Gerätes ausgegeben oder auf Anfrage über diese Schnittstelle übermittelt. Hier gibt es keine Standards, die die Form der Daten beschreiben. Die Hersteller verwenden kryptische Umwandlungen ihrer Daten in Hexadezimal-Codes oder ähnliche Formate, deren Struktur offen zu legen ist. Es ist Aufgabe des IADS-Programmierers in Zusammenarbeit mit dem Gerätehersteller eine Software zu entwickeln, die diese Datenketten sinnvoll auswertet. Je nach Art der Datenübermittlung, die vom Hersteller vorgesehen ist, muss die Anbindung an das medizinische Informationssystem gestaltet werden. Es kann nicht erwartet werden, dass ein Gerätehersteller mehrere Möglichkeiten der Datenabnahme zur Verfügung stellt. Diese Verantwortung liegt beim Hersteller oder Vertreiber der medizinischen Software.

Generell kommen zwei Formen der Anbindung zum Datenaustausch zwischen medizinischem Gerät und dem medizinischen Informationssystem zum Einsatz, die indirekte oder direkte Anbindung.

2.4.1 Die Systemarchitektur der indirekten Anbindung

Viele aktuelle Geräteserien von Medizintechnikfirmen sind mit einer eigenen Netzwerkkarte ausgestattet und werden im Netzwerk über IP- und Hardwareadresse identifiziert. Diese Geräte sind in der Lage die Daten auf TCP/ IP-Ebene zu senden.

Abbildung in dieser Leseprobe nicht enthalten

ABBILDUNG 8: SYSTEMATISCHE ÜBERSICHT DER INDIREKTEN ANBINDUNG QUELLE: [COPRA04:S.3]

Aus technischen und Sicherheitsgründen wird das Medizintechniknetzwerk oftmals vom Hausnetzwerk getrennt. Ob die beiden Netzwerke im Einzelfall getrennt werden, entscheidet die Diskussion zwischen Medizingerätehersteller und Systembetreuern des Krankenhausnetzwerkes.

[...]

^[1] Intensivmedizin: „ärztliche Intensivbeobachtung und Intensivtherapie Schwerkranker, deren vitale Funktionen in lebensbedrohlicher Weise gestört sind und durch besondere Maßnahmen aufrechterhalten und wiederhergestellt werden müssen.“ [SEELOS90:S.252]

^[2] Anästhesiologie: „medizinisches Fachgebiet, das die allgemeine und lokale Anästhesie [„Unempfindlichkeit gegen Schmerz-, Temperatur- und Berührungsreize“, [SEELOS90:20]] einschließlich deren Vor- und Nachbehandlung, die Aufrechterhaltung der vitalen Funktionen während operativer Eingriffe, die Wiederbelebung und die Intensivmedizin in Zusammenarbeit mit den für das Grundleiden zuständigen Ärzten umfaßt.“ [SEELOS90:S.20]

^[3] forensisch: „gerichtlich […]“ [SEELOS90:S.202]

^[4] C++: objektorientierte Programmiersprache

^[5] ISO/OSI-Modell: ein von der International Organization for Standardization (ISO) vorgeschlagenes hierarchisches Schichtenmodell für die Normierung der Kommunikationsarchitektur in offenen Datenübertragungssystemen (OSI = open systems interconnection). Das OSI- Referenzmodell umfasst sieben Funktionsschichten (layers), unterteilt in Transportsystem (Schichten 1 bis 4) und Anwendersystem (Schichten 5 bis 7). [vgl.SEELOS90:S.256f.]

^[6] Radiologie: „medizinisches Fachgebiet, das die Erkennung von Erkrankungen mit Hilfe ionisierender Strahlen und kernphysikalischer Verfahren sowie den Strahlenschutz mit seinen physikalischen, biologischen und medizinischen Grundlagen umfaßt.“ [SEELOS90:S.416]

^[7] TCP/ IP: transmission control protocol (TCP) over internet protocol (IP). TCP zerlegt die Datenpakete vor der Übertragung und setzt diese beim Empfänger, nachdem die kleineren Pakete über IP versendet wurden, wieder zusammen. IP ist ein Protokoll der Schicht 3 des ISO/OSI-Modells, TCP ein Protokoll der Schicht 4 dieses Referenzmodells.