Implementierung des medizinischen Kommunikationsprotokolls POCT1-A auf einem embedded Linux Device

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

1 Einleitung
1.1 Motivation
1.2 Aufgabenstellung

2 Stand der Technik
2.1 Krankenhausinformationssysteme
2.2 Medizinische Kommunikationsstandards
2.2.1 HL7
2.2.2 CDA
2.2.3 SCIPHOX
2.2.4 DICOM
2.2.5 VITAL
2.2.6 Zusammenfassung
2.3 Point of Care Testing

3 POCT1-A
3.1 Entstehung von POCT1-A
3.2 Überblick POCT1-A
3.3 Aufbau von POCT1-A
3.4 Nachrichten Profile
3.4.1 Basic Message Flow
3.4.2 Continuous Mode
3.4.3 Asynchronous Mode
3.4.4 Fehlerbehandlung

4 Bewertung von POCT1-A
4.1 Vorteile von POCT1-A
4.2 Vergleich zu HL7

5 Entwurfsmuster
5.1 Befehls Muster
5.2 Fabrik Methode
5.3 Singleton Muster
5.4 Beobachter Muster

6 Entwicklungsplattformen
6.1 Zaurus SL5500
6.2 Entwicklungsumgebung

7 POCT1-A Framework und Anwendung
7.1 Anforderungen und Entwurf
7.2 POCTl-AFramework
7.2.1 Architektur und Entwurf
7.2.2 XML-Parser
7.2.3 Schnittstellen
7.3 Pluginsystem
7.3.1 Bibliotheken
7.3.2 Entwurf eines Pluginsystems
7.3.3 SpO2- Plugin
7.4 Core
7.5 Device Interface
7.5.1 Anforderungen
7.5.2 Entwurf und Design
7.6 Observation Reviewer
7.6.1 Anforderungen
7.6.2 Entwurf und Design
7.7 Use-case Szenario

8 Zusammenfassung und Ausblick

Anhang

A POCT1-A
A.1 Datentypen
A.2 Objekte
A.3 Nachrichten
A.4 UML Diagramme

Literaturverzeichnis

Kurzreferat

Der Schwerpunkt dieser Arbeit liegt in der Entwicklung eines Frameworks zur draht­losen Übertragung von Messwerten unter Nutzung des POCT1-A Standards. Es wird zunächst ein Überblick gegeben über medizinische Kommunikationsstandards im All­gemeinen, um dann im Detail auf den POCT1-A Standard einzugehen. Entwicklungs­plattformen und Implementierungstechniken, die bei der Umsetzung verwendet wur­den werden vorgestellt, um abschließend noch ein Überblick über die Komponenten der erstellten Anwendung und insbesondere dem Pluginsystem zu geben.

Abstract

The emphasis of this thesis is on the development of a framework for the wireless trans­mission of measurments using the POCT1-A standard. First an overview of medical com­munication standards in general is given, to present the POCT1-A standard in detail af­terwards. Development environment and implementation techniques, which are used in jthe implementation, are introduced. Concluding, a survey of the components of the de­veloped application and in particular the plugin system is given.

Abbildungsverzeichnis

Abb, 1.1 Europamarkt für WLANs in Krankehäusern [7]

Abb, 1.2 Drahtlose Übertragung von Vitalparametern

Abb, 2.1 ISO/OSI Schichtenmodell

Abb. 2.2 HL7 Kommunikationswege [10]

Abb, 2.3 Erlanger Kommunikationsdrehscheibe [11]

Abb, 2.4 DICOM-Standard (ENV 12052): Bestandteile und Zusammenhang

Abb, 2.5 Blutgasmessgeraet [12]

Abb. 2.6 PTN, APTT, ACT Bestimmung [6]

Abb, 3.1 Entwicklung des Point-of-Care Standards [13]

Abb. 3.2 Aufbau von POCT1-A [13]

Abb, 3.3 Aufbau von POCT1-A

Abb, 3.4 Beispiel für CE Datentyp

Abb. 3.5 HEL.R01 Nachricht, XML und UML Ansicht

Abb, 3.6 POCT1-A Verbindungsaufbau

Abb, 3.7 Anfrage einer Observation

Abb, 3.8 Anfrage eines Device Events

Abb, 3.9 Empfang einer Operator / Patient List

Abb, 3.10 Empfang einer Directive

Abb, 3.11 Keep Alive Message

Abb, 3.12 Empfang einer Terminate-Message

Abb, 3.13 Versenden einer Observation Message (Continuous Mode)

Abb, 3.14 Versenden einer Device Event Message (Continuous Mode)

Abb, 3.15 Empfang einer Operator / Patient List Message (Continuous Mode)

Abb, 3.16 Vergleich von synchronisierter / asynchronisierter Übertragung

Abb. 4.1 Aufbau von POCT1-A (vgl.: [13])

Abb, 5.1 Befehls Muster

Abb, 5.2 Befehls Muster Ablaufdiagramm

Abb. 5.3 Factorymethode

Abb, 5.4 Singelton Muster

Abb, 5.5 Beobachter Muster

Abb, 5.6 Beobachter Muster Ablaufdiagramm

Abb, 6.1 Sharp Zaurus SL5500

Abb, 6.2 Buffalo CF Wireless-LAN-Karte, AIRcable

Abb, 7.1 Architektur und Entwurf

Abb, 7.2 Schnittstellen (rot gekennzeichnet)

Abb, 7.3 UML Diagramm: Message Flow

Abb, 7.4 UML Diagramm: XML Klassen

Abb, 7.5 SendMessage Ablaufdiagramm

Abb, 7.6 ProcessMessage Ablaufdiagramm

Abb, 7.7 PlugInBase.h

Abb, 7.8 PlugInExample.h

Abb, 7.9 PlugInExample.cpp

Abb, 7.10 loadPlugin(const char* pn)

Abb, 7.11 SpO2Fingerclip

Abb, 7.12 Core - Anwendungskern

Abb, 7.13 DeviceInterface

Abb, 7.14 ObservationReviewer

Abb, A.1 POCT1-A AccessControl Objekt

Abb, A.2 POCT1-A AccessPoint Objekt

Abb, A.3 POCT1-A Acknowledgement Objekt

Abb, A.4 POCT1-A Control Calibration Objekt

Abb, A.5 POCT1-A Device Objekt

Abb, A.6 POCT1-A Device Capabilities Objekt

Abb, A.7 POCT1-A Device Static Capabilities Objekt

Abb, A.8 POCT1-A Device Event Objekt

Abb, A.9 POCT1-A Device Status Objekt

Abb, A.10 POCT1-A Directive Objekt

Abb, A.11 POCT1-A End-Of-Topic Objekt

Abb, A.12 POCT1-A Escape Objekt

Abb. A.13 POCT1-A Header Objekt

Abb. A.14 POCT1-A Note Objekt

Abb. A.15 POCT1-A Observation Objekt

Abb, A.16 POCT1-A Operator Objekt

Abb. A.17 POCT1-A Order Objekt

Abb. A.18 POCT1-A Patient Objekt

Abb, A.19 POCT1-A Reagent Objekt

Abb, A.20 POCT1-A Request Objekt

Abb. A.21 POCT1-A Service Objekt

Abb, A.22 POCT1-A Specimen Objekt

Abb, A.23 POCT1-A Termination Objekt

Abb, A.24 POCT1-A Update Action Objekt

Abb, A.25 UML Diagramm: Datentypen

Abb, A.26 UML Diagramm: Objekte

Abb, A.27 UML Diagramm: Nachrichten

Abb, A.28 UML Diagramm: Command Pattern

Abb, A.29 UML Diagramm: Framework

Tabellenverzeichnis

Tab, A.1 POCTl-ADatentypen

Tab, A.2 Encapsulated Data (ED)

Tab, A.3 Character String (ST)

Tab, A.4 Coded Simple Value (CS)

Tab, A.5 Coded Value (CV)

Tab, A.6 Coded with Equivalents (CE)

Tab, A.7 Person Name (PN)

Tab, A.8 Person Name (PN) Child Elements

Tab, A.9 Organization Name (ON)

Tab, A.10 Integer Number (INT)

Tab. A.11 Real Number (REAL)

Tab, A.12 Physical Quantity (PQ)

Tab, A.13 Point in Time (TS)

Tab, A.14 Null Code Values

Tab, A.15 POCTl-ANachrichten

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1. Einleitung

1.1. Motivation

„The future is wireless". Innerhalb der letzten Jahre konnte man eine rasante Entwicklung auf dem Gebiet der drahtlosen Übertragungswege und deren Anwendungen beobach­ten. Heute gibt es eine Vielzahl von verschiedenen Techniken, Daten kabellos zu über­tragen, und genauso vielfältig sind die Anwendungsbereiche dafür. Kann man in man­chen Bereichen bereits von einem „Standard" sprechen, so beginnt sich die Technik der drahtlosen Übertragung auf dem Gesundheitssektor erst zu etablieren. Es eröffnen sich ungeahnte Möglichkeiten und Anwendungsgebiete, wie sie noch vor wenigen Jahren un­denkbar gewesen wären. (Abb. 1.1)

Zudem ermöglichten Fortschritte in den letzten Jahrzehnten in Bereichen der Mikroflui- dik und der Miniaturisierung eine neue Generation von Diagnosegeräten. Diese unter­stützt eine Vielzahl von Diagnosetests direkt am Patienten, dem sogenannten „Point of Care" (POC). Selbst anspruchsvolle Tests, welche bisher nur in speziellen Laboren mög­lich waren, können nun direkt vor Ort während der normalen Krankenhausaufenthalte oder sogar zu Hause durchgeführt werden. Diese Geräte ermöglichen es, die Wartezeiten auf bestimmte Tests zu reduzieren. Daraus resultieren kürzere Belegzeiten der Kranken­hausbetten und es lässt sich eine bessere Auslastung des Krankenhauses realisieren. Es werden so die entstehenden Kosten für Krankenkassen und Krankenhäuser gesenkt und somit deren Wirtschaftlichkeit gesteigert. Gerade heute, in einer Zeit, in der Krankenhäu­ser durch die aktuelle Gesundheitsreform gezwungen werden effizienter zu arbeiten, ist dies ein nicht zu unterschätzender Faktor.

Ziel dieser Arbeit ist es, diese beiden neuen Technologien miteinander zu verbinden. So kann man die Zeit zwischen Messung und Übermittlung in Krankenhausinformations­systeme (KIS) nochmals verkürzen bzw. vollständig vernachlässigen. Unmittelbar nach­dem das Gerät die Untersuchung abgeschlossen hat, sind die relevanten Daten bereits im KIS erreichbar.

Um jedoch all das erfolgreich in die Realität umzusetzen, muß eine Interoperabilität zwi­schen medizinischen Geräten und KIS gewährleistet sein. Es besteht die Notwendigkeit, gemeinsame Kommunikationsschnittstellen zur Übertragung der Daten zu definieren und einzusetzen.

Mit POCT1-A wurde ein Kommunikationsstandard für medizinische Laborgeräte ge­schaffen, die direkt am Klinikbett eingesetzt werden. Über eine Schnittstelle zwischen Gerät und einem sogenannten Observation Reviewer^[1], definiert das POCT-1A Kommu­nikationsprotokoll den Austausch von Nachrichten im XML-Format. Diese Nachrichten orientieren sich an einem neuen XML-Nachrichtenformat, welches zur Zeit des Entwur­fes von POCT1-A dem Stand der XML-Nachrichten in der HL7 Version 3 Verwendung entsprach. Dadurch ist es möglich, validierte Informationen ins Krankenhausinformati­onssystem einzuspeisen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1.1: Europamarkt für WLANs in Krankehäusern [7]

1.2. Aufgabenstellung

Im Rahmen dieser Studienarbeit wird das Kommunikationsprotokoll POCT1-A auf ei­nem embedded Linux Device implementiert. Hierfür soll das sog. Device-Interface^[2] durch eine POCT-Serverapplikation und als Gegenstelle eine POCT-Deviceapplikation realisiert werden. Zur Verifikation der Implementierung soll auf Device-Seite ein Bluetooth Puls- oximeter (Fingerclip/Armband) eingebunden werden und die Daten POCT-konform an die Serverapplikation per WLAN auf den PDA übertragen werden. Die Aufgaben lassen sich konkret in folgenden Punkten detaillieren:

- Implementierung des Kommunikationsstandards POCT1-A.
- Entwicklung einer Anwendung auf dem PDA, welche als „POCT-Interface" für vor­handene Geräte genutzt werden kann.
- Realisierung eines Plug-In Mechanismus zur Anbindung eines Pulsoximeters bzw. weiterer Geräte.
- Realisierung eines „Observation Reviewers" zur Visualisierung der Vitalparameter auf einem PC.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1.2: Drahtlose Übertragung von Vitalparametern

Ziel ist es insbesondere eine Lösung zu präsentieren, welche sich in ein reales Szenario im klinischen Umfeld einbetten lässt. Durch die Anbindung des Pulsoximeters ist eine praktische Anwendung im klinischen Alltag oder auch Homecare Bereich gegeben. Es soll möglich sein, die so gewonnen Daten auf einem PDA zu speichern, um sie später in ein Krankenhausinformationssystem einzuspeisen, oder alternativ auch direkt nach der Messung dorthin zu übertragen.

2. Stand der Technik

2.1. Krankenhausinformationssysteme

Ein Krankenhausinformationssystem (KIS) ist das Teilsystem eines Kran­kenhauses, das alle informationsverarbeitenden (und -speichernden) Prozes­se und die an ihnen beteiligten menschlichen und maschinellen Handlungs­träger in ihrer informationsverabeitenden Rolle umfasst. Das KIS dient da­zu, die Mitarbeiter des Krankenhauses bei der Erledigung der Aufgaben des Krankenhauses zu unterstützen. Es umfasst daher

- alle Bereiche des Krankenhauses,
- alle Gebäude des Krankenhauses und
- alle Personengruppen, die im Krankenhaus tätig sind.

(Definition nach [3])

In der heutigen Zeit haben Krankenhausinformationssysteme eine wichtige Funktion in Krankenhäusern und sind aus diesen auch nicht mehr wegzudenken. Eine genaue Be­schreibung über die Beschaffenheit eines Krankenhausinformationssystems lässt sich nur schwer formulieren. Die Vermutung, dass es sich hierbei um ein homogenes System han­delt ist nicht korrekt. Informationsverarbeitung in einem Krankenhaus besteht aus ei­ner heterogenen Welt, die auch in einem heterogenen System zusammengefasst werden muss. Um KIS beurteilen zu können muß eine Möglichkeit geschaffen werden ein sol­ches zu beschreiben. Mit Hilfe des 3-Ebenen-Meta-Modells sind diese Voraussetzungen geschaffen. Das Modell besteht aus drei Ebenen, der fachlichen, der logischen und der physischen Ebene. Ordnet man ein KIS in dieses Schema ein lässt sich eine Analyse über Stärken und Schwächen des KIS treffen. Jedoch sollte diese Analyse gewissenhaft auf allen drei Ebenen durchgeführt werden [3].

Nach van der Velde stellt ein Krankenhausinformationssystem nur einen „konzeptionel­len Rahmen" dar, in dem sich die EDV-Anwendungen eines Krankenhauses entwickeln und zu einem funktionierenden Ganzen integriert werden können [20][15]

Nach Prokosch [15] sind bis heute drei verschiedene Architekturvarienten von KIS ent­standen:

- Monolithische Konzepte: Lösungen aus einer Hand, in der Vergangenheit meist durch Eigenentwicklung, jedoch seit kurzem auch verstärkt durch kommerzielle Anbieter
- Heterogene verteilte Konzepte: auf Bereiche individuell zugeschnittene Lösungen, welche über Kommunikations und Informationsserver verbunden werden.
- Komponentenbasierte Konzepte: grundlegende Funktionen werden in Komponen­ten gekapselt, die über standardisierte APIs kommunizieren können.

Eine optimale Architektur für ein Krankenhausinformationssystem lässt sich jedoch nicht definieren. Es gilt zu beachten, dass man ein Krankenhausinformationssystems nicht kaufen kann [15]. Es wächst immer mit den Anforderungen und ist für jedes Kranken­haus ein individuell entstandenes System, welches genau den speziellen Anforderungen entsprechen sollte. Durch diese Gegenbenheiten ist es eine große Herausforderung neue Produkte oder Entwicklungen in die vorhandene Infrastruktur von KIS einzubinden. Oft ist dieser Prozess mit großem zeitlichen und auch finanziellem Aufwand verbunden. Um Integrationsprozesse zu vereinfachen und zu standardisieren, wurde der medizini­sche Kommunikationsstandard HL7 entwickelt.

Mit diesem Standard und zwei daraus hervorgegangenen, der Clinical Document Archi­tecture (CDA), welche sich mit klinischen Dokumenten beschäftigt, und einer nationalen Erweiterung der CDA (SCIPHOX), beschäftigen sich die nächsten Abschnitt.

2.2. Medizinische Kommunikationsstandards

2.2.1. HL7

Dieser Standard wurde Ende der 80iger Jahre durch eine Organisation, die sich Health Le­vel 7 nennt, entwickelt und etabliert. Diese Organisation hat es sich zum Ziel gesetzt, ei­ne Standardisierung der Kommunikation in Krankenhäusern und im gesamten Gesund­heitswesen zu erreichen. Der Name Health Level 7 oder kurz HL7 wurde im Bezug auf das ISO/OSI Schichtenmodell gewählt, in welchem der 7. Schicht die Aufgaben einer

Anwendungsschicht zugeordnet sind und der Standard auf dieser aufsetzt (Abb. 2.1). Er spezifiziert Kommunikationsinhalte und Austauschformate und ist seit 1987 ANSI ak- kredierter Kommunikationsstandard in der Medizin.

Mit diesem Standard stehen bei einer Implementierung von notwendigen Schnittstel­len zwischen verschiedenen heterogenen Systemen wertvolle Hilfen zur Verfügung. Ein wichtiges Merkmal des Standards ist es, dass dieser unabhängig von Software, Hardwa­re oder dem verwendeten Netzwerk einsetzbar ist. Die Konfiguration liegt allein in der Hand des Anwenders. Unterzieht man diese Freiheiten in der Konfiguration einer kriti­schen Betrachtung, erkennt man jedoch auch sofort die dadurch entstehenden Probleme. Hierdurch verliert der Standard mitunter an Genauigkeit und Eindeutigkeit. Obgleich dieser Lockerung des Standards lassen sich nahezu alle Institutionen und Bereiche des Gesundheitswesens mit HL7 verbinden. Durch die Einführung dieses Standards wurde die Effizienz aller Kommunikationsvorgänge entschieden verbessert.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1: ISO/OSI Schichtenmodell

Aktuell liegt der HL7 Standard in der Version 2.5 vor. In absehbarer Zeit jedoch soll die­se Version durch die Version 3 ersetzt werden, da die aktuelle Version nicht mehr den wachsenden Ansprüchen an den Standard gerecht wird. Im folgenden werden kurz die Merkmale und Unterschiede der beiden Versionen aufgezeigt.

- In den Versionen 2.x sollen Spezifikation von Syntax und Semantik für den Daten­austausch zwischen beliebigen Anwendungen unabhängig von

- deren Datenstruktur,
- der Anwendungsumgebung,
- den Systemvoraussetzungen,
- der Funktionalität etc.

gehalten werden. Es sind lediglich minimale Regeln für die Implementierung im Standard enthalten. Zu den wesentlichen Merkmalen und Zielen von HL7 zählen unter anderem die Bereitstellung von Formaten und Protokollen zum Austausch von Datensätzen im Gesundheitswesen, sowie eine Standardisierung der Inhal­te und die damit verbundene Vereinheitlichung der Schnittstellen. Dadurch wird eine Verbesserung in der Effizienz und eine Reduktion der Zahl der Kommuni­kationswege/Schnittstellen erreicht (Abb.: 2.2). Der so verminderte Aufwand bei der Implementierung von Schnittstellen liegt zwischen 60% und 80% [10]. Stan­dardisiert werden Nachrichtenstrukturen, die Darstellung der Nachrichten für die Übertragung und die Anwendungsereignisse, welche zur Auslösung von Nach­richten dienen. Der Standard bietet vielschichtige Einsatzmöglichkeiten und wird unter anderem bei der Patientenregistrierung, Aufnahme, Verlegung bzw. Entlas­sung, sowie in der Buchhaltung als auch bei Patientenvorsorge oder Klinischen Studien verwendet.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2: HL7 Kommunikationswege [10]

- Die Version 3 ist aktuell in der Entwicklungsphase und verfolgt bislang einen prag­matischen Ansatz. Es existieren Methodologien zur Ableitung von Nachrichten und es wurde ein sogenanntes Reference Information Model, kurz RIM eingebun­den. Desweiteren gibt es ein Domain / Refined Message Information Model (C/R - MIM) und eine Hierarchical Message Definition (HMD), auf die jedoch nicht wei­ter eingegangen werden soll. Das aktuelle RIM beschreibt sechs Kernklassen der Objekte im Gesundheitswesen, deren Assoziationen, sowie deren grundlegenden Spezialisierungen.
- Entities (Entitäten), d. h. die physischen Informationsobjekte in der Domäne,
- Roles (Rollen), die diese Entitäten spielen können und die ihnen Kompetenz für die Durchführung bestimmter Aktionen zuweisen
- Participations (Beteiligungen) an bestimmten Aktionen, d. h. deren Realisie­rung,
- Acts (Aktionen),
- Role Relationships (Rollenbeziehungen) zur Vermittlung der Interaktion zwi­schen Entitäten in ihren jeweiligen Rollen, sowie
- Act Relationships (Aktionsbeziehungen), um die Verknüpfung/Verkettung verschiedener Aktionen auszudrücken.

Eine detaillierte Beschreibung des aktuellen RIM ist dem Webdokument [18] zu entnehmen.

Oft wird im Zusammenhang mit HL7 - Kommunikation auch der Begriff Kommunikati­onsserver verwendet. Unter einem solchen Server versteht man eine spezialisierte Midd­leware zur Integration von Subsystemen eines übergeordneten Informationssystems auf Anwendungsebene [11]. Durch den Einsatz von Kommunikationsservern kann eine Re­duktion der Schnittstellen von n(n — 1) auf annähernd n erreicht werden. Als Beispiel ist in Abbildung 2.3 die aktuelle Situation an der Universitätsklink Erlangen zu sehen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.3: Erlanger Kommunikationsdrehscheibe [11]

2.2.2. CDA

Die Clinical Document Architecture CDA gilt als erster national verabschiedeter und aner­kannter Standard für Gesundheitsinformationen auf der Basis von XML [4]. Dieser Stan­dard wurde innerhalb der HL7 Gruppe erarbeitet und wurde Ende 2000 in der Release 1 ANSI akkredierter Standard und wird weltweit eingesetzt. In diesem Release wurde die damalige Version des RIM (Version 0.98) verwendet. Das Release 2 der CDA basiert auf einer neueren Version des RIM und nutzt vollständig das HL7 Developement Frame­work.

Ein CDA - Dokument ist ein klinisches Dokument, welches multimediale Objekte, wie Text, Bilder, Töne, etc. enthalten kann und in XML codiert ist. Es beinhaltet Beobachtun­gen und Maßnahmen und weist nach der Standardbeschreibung [17] und Heitmann [8] folgende Eigenschaften auf:

- Persistenz
- geregelte Verwaltung
- Möglichkeit zur Authentifizierung
- Ganzheit der Authentifizierung
- Lesbarkeit für das menschliche Auge (kein Binärformat)

Der Focus von CDA ist auf das Dokumentenparadigma gerichtet. Es soll also nicht wie bei einem Nachrichtenparadigma temporärer Datenaustausch vorgenommen werden, son­dern die Daten persistent in Dokumenten abgelegt werden.

2.2.3. SCIPHOX

Die Abkürzung SCIPHOX bedeutet Standardized Communication of Information Sys­tems in Physician Offices and Hospitals using XML. Der Standard ist eine nationale Ad­aption der CDA Release 1. Es werden Bausteine, sogenannte Small Semantic Units (SSUs) entwickelt, mit welchen die unterschiedlichsten Patientendokumente im deutschen Ge­sundheitswesen abgebildet werden können. So wird der CDA Standard nach nationalen Besonderheiten erweitert.

Das Projekt SCIPHOX, welches zu Beginn des Jahres 2000 enstanden ist, hat sich zum Ziel gesetzt, gewonnene Erfahrungen in den sich parallel entwickelnden Domänen HL7 und xDT1 in eine Neuentwicklung der Kommunikation zwischen ambulanten und sta­tionären Versorgungseinrichtungen zu bringen. SCIPHOX sieht vor, in einer öffentlichen Diskussion Vorgaben für Dokumentationsmodelle im Gesundheitswesen zu beurteilen und die daraus gewonnen Ergebnisse bereitzustellen. Die Entwicklung von SCIPHOX ist in mehrere Phasen eingeteilt. Die erste, bereits abgeschlossene Phase des Projekts spe­zifiziert Entlassungsbriefe mit Diagnosen, Therapien, Informationen zur Weiterbehand­lung, etc. nach Beendigung eines Krankenhausaufenthalts für den niedergelassenen Arzt sowie die Überweisung von Arzt zu Arzt oder eine Krankenhauseinweisung. In der zweiten Phase sollen weitere Dokumente für z.B. elektronische Rezepte, den europäi­sche Notfallausweis, Diabetes-Nachsorge sowie Mammakarzinom-Früherkennung und -Behandlung definiert werden. Auch die Thematik des elektronischen Transports von Dokumenten und Sicherheit soll als Empfehlung verabschiedet werden.

2.2.4. DICOM

Ein weiterer medizinischer Kommunikationsstandard hat sich aus dem Gebiet der me­dizinischen Bildverarbeitung etabliert. In dieser und auch in der Telemedizin besteht die Notwendigkeit digitale Bilder zwischen Geräten verschiedener Hersteller austauschen zu können. Jedoch sind klassische Bildformate wie BMP, TIFF oder GIF diesen Anforde­rungen nur schwer gewachsen.

Eine gemeinsame Arbeitsgruppe des American College of Radiology (ACR) und der Na­tional Electrical Manufacturers Association (NEMA) startete 1983 den Versuch, ein Aus­tauschformat für diese Zwecke zu schaffen. Das Produkt, der ACR-NEMA - Standard, war jedoch aufgrund konzeptioneller Schwächen nicht sehr erfolgreich und deshalb wurde auf diesem Standard aufbauend 1993 der DICOM Standard (Digital Imaging and Commu­nications in Medicine) verabschiedet, der seit diesem Zeitpunkt kontinuierlich erweitert wird und seit 1995 auch in Europa als formaler Standard akzeptiert ist [14].

Der Standard beschreibt Datenstrukturen für medizinische Bilder und bildbezogene Da­ten, Netzwerkorientierte Dienste, Formate für den Datenträgeraustausch sowie Anforde­rungen an korrespondierende Geräte und Programme.

Damit reicht DICOM weit über die Definition eines reinen Austauschformates für medi­zinische Bilddaten hinaus. Ein DICOM - Bild besteht aus einer Liste von Datenelementen (sogenannten Attributen), die eine Vielzahl von bildbegleitenden Informationen enthal­ten, wie Informationen zum Patienten, zu Modalitäten und Aufnahme. Der Standard de-^[3] finiert zudem einen Netzwerkdienst entsprechend dem Client/Server - Konzept. Neben dem grundlegenden DICOM - Dienst der Bildübertragung (Storage Service Class) gibt es noch eine Reihe weitergehender Dienste, wie z.B. den DICOM - Bildarchiv - Dienst, welcher die Suche nach bestimmten Kriterien in PACS - Systemen ermöglicht. Mit dem DICOM - Modality Worklist - Dienst lässt sich eine automatische Übernahme von Arbeits­aufträgen incl. Patientendaten einem KIS/RIS Systemen realisieren.

Ein zweiter Schwerpunkt von DICOM neben der Übertragung von medizinischen Bildern ist der Datenträgeraustausch. Um sicherzustellen, dass DICOM - Datenträger wirklich austauschbar sind, definiert der Standard (Ausgabe von 1996) sogenannte Anwendungs­profile, die genau beschreiben, von welchen Modalitäten Bilder auf dem Datenträger ge­speichert sein dürfen, welche Zahlenformate und Kompression verwendet werden dür­fen und welche Datenträger zu verwenden sind.

Neben den eigentlichen DICOM - Bildern enthält jeder DICOM - Datenträger noch ein DICOM - Directory. In dieser Datei befinden sich die wichtigsten Informationen bezüg­lich des Patientens. So kann der Datenträger schnell durchsucht werden, ohne komplett eingelesen werden zu müssen (Abb.: 2.4).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.4: DICOM-Standard (ENV 12052): Bestandteile und Zusammenhang

Im Jahr 2000 wurde durch die DICOM Herz- und Gefäß- Working Group die Möglichkeit eine Kodierung von 12-Kanal EKG und Hämodynamik^[4] Daten dem Standard hinzuge­fügt, um den Standard auch in Bereichen der Kardiologie zu verwenden. Es wurden bereits vorhandene DICOM Mechanismen verwendet und mit 16-bit waveforms^[5] kom­biniert. Der Standard wurde also um die zeitliche Dimension erweitert und es können somit nicht nur statische Daten sondern auch kontinuierliche Daten übertragen werden.

Ein weiterer medizinische Kommunikationsstandard, der sich mit der Übertragung von kontinuierlichen Daten befasst ist VITAL.

2.2.5. VITAL

Der Vital Signs Information and Representation Standard, kurz VITAL, wurde zur Dar­stellung von Vitalparametern und einer geräteunabhängigen Übertragung dieser geschaf­fen [22]. Durch eine Plug&Play Fähigkeit ermöglicht der Standard eine automatische Konfiguration und Integration vernetzter medizinischer Geräte. Diese Geräte lassen sich zu einem sogenannten Hybridgerät zusammenfassen. Dadurch ist es möglich, virtuelle medizinische Geräte zu erstellen und diese zu einer kombinierten Erfassung von Mess­werten einzelner Geräte zu verwenden.

Der VITAL Standard setzt sich aus drei Hauptbestandteilen zusammen [16]:

- Einem Domain Information Model (DIM), das ein objektorientiertes Modell als Grundlage für die Modellierung von medizinischen Geräten und Vitalparametern beschreibt.
- Einem Kommunikationsmodell, das Protokolle und Dienste auf Basis von ISO/OSI Standards bereitstellt und die Interoperabilität zwischen medizinischen Geräten garantiert.
- Einer Nomenklatur mit standardisierten Codes, die alle Objekte und Attribute im DIM eindeutig identifiziert.

VITAL unterscheidet drei Arten von Systemen, die untereinander kommunizieren und Vitalparameter verarbeiten können:

- Der Agent stellt ein medizinisches Gerät dar, das Vitalparameter erfasst und den Zugriff auf diese Informationen über seine bereitgestellten Dienste ermöglicht.
- Der Manager repräsentiert ein Monitor-Gerät, das die von einem Agent verwalte­ten Informationen abruft und weiterverarbeitet.
- Sogenannte Hybrid Systeme nehmen sowohl die Rolle eines Agents als auch eines Managers ein. Sie stellen Informationen bereit und rufen sie ab.

2.2.6. Zusammenfassung

Die Liste medizinischer Kommunikationsstandards würde sich durchaus noch weiter­führen lassen, jedoch sollte hier nur ein kurzer Überblick über die Aufgaben solcher Stan­dards an einigen Beispielen gegeben werden. Durch die Vielzahl medizinischer Kommu­nikationsstandards eröffnen sich oft ein neues Problem. Die Wahl des richtigen Standards und dessen korrekte Umsetzung erfordert eine genaue Betrachtung der vorhandenen Möglichkeiten. Dieses Problem sollte gewissenhaft gelöst werden, da sonst die Vortei­le, die durch einen Einsatz von Standards entstehen, nicht mehr gegeben sind. Dennoch gibt es Bereiche, in welchen die Einführung neuer Standards sinnvoll und auch notwen­dig ist. Ein solches Gebiet in dem Sektor der Medizintechnik ist Point of Care Testing, kurz POCT.

2.3. Point of Care Testing

In der Vergangenheit und auch teilweise noch heute mussten Proben von diagnostischen Tests in zentralen Laboren aufwendig analysiert werden. Dadurch entstanden oft mehr­tägige Wartezeite, v.a. wenn ein zentrales Labor zur Analyse nicht vor Ort vorhanden war. Durch Fortschritte in der Mikrofluidik und auch in der Miniaturisierung wurde für einen Teil der Geräte das Tor zu einer neuen Gerätegeneration für diagnostische Tests aufgestossen (Beispiele für solche Geräte sind Abb.: 2.6 und 2.5 zu sehen). Mit Hilfe sol­cher Geräte ist es nun auch möglich die Tests vor Ort direkt am Patienten, am sogenann­ten Point-of-Care durchzuführen. Messungen können nun unabhängig von Ort und Zeit absolviert werden. Nach wie vor gibt es natürlich auch in Laboren, neben diesen klei­nen handlichen Geräten, noch größeren Geräte, welche jedoch im Bezug auf die Daten­kommunikation und Qualitätssicherung, auf die damit verbundenen Probleme wird im folgenden noch genauer eingegangen, gleich zu behandeln sind.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.5: Blutgasmessgeraet [12]

Große Medizintechnik Firmen haben diesen Trend schon lange erkannt und mit der Pro­duktion von POCT Geräten begonnen. Momentan gibt es eine Vielzahl von verschiede­nen Herstellern, die auf dem Markt positioniert sind und POCT Produkte anbieten. Die Problematik, die sich hieraus ergibt liegt darin, dass bis zum heutigen Tag noch kein Standard Grundlage für die Entwicklung dieser Geräte war. Es gibt also eine nicht zu durchschauende Vielfalt von verschiedenen Protokollen für POCT Geräte. Von Papier­ausdrucken bis zu eigenen Protokollen und somit auch einer eigenen Auslesesoftware läßt sich alles finden. Hier ergeben sich jedoch schon die ersten, oder besser das Haupt­problem für das klinische Umfeld. Alle diese Geräte lassen sich nur durch zusätzlichen Arbeitsaufwand in ein KIS einbinden. Liefert das POCT Gerät einen Papierstreifen mit den Messungen ist immer noch eine Nachverarbeitung in Form einer elektronischen Er­fassung der Daten notwendig. Verfügt das POCT Gerät über ein eigenes Protokoll, so sind aufwendige Schnittstellen zu programmieren, um die Daten im KIS verwenden zu können. Das hat für Krankenhäuser erhebliche Kosten zur Folge, da eine Entwicklung solcher Schnittstellen in der Regel individuell erfolgen muß.

Ein weiteres Problem liegt in der Wartung und Dokumentation bzw. der Qualitätssiche­rung dieser Geräte. POCT Geräte müssen regelmässig gewartet und neu kalibriert wer­den. In der Bekanntmachung der Medizinprodukt Betreiberverordnung MPBetreibV [5] vom 21.08.2002 ist in § 4a die gesetzliche Verpflichtung für eine Qualitätssicherung bei Kontrolluntersuchungen und Vergleichsmessungen in medizinschen Laboratorien gere­gelt. Um jedoch eine lückenlose Kontrolle zu gewährleisten ist ein zusätzlicher Mehr­aufwand notwendig. Zudem sind die aktuellen Geräte diesen Anforderungen nicht ge­wachsen, da mit diesen keine nachvollziehbare und zu verifizierende Qualitiätskontrolle durchgeführt werden kann.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.6: PTN, APTT, ACT Bestimmung [6]

Um die Kommunikationswege zwischen POCT Geräten und KIS zu vereinfachen und eine lückenlose Qualitätssicherung, welche den gesetzlichen Anforderungen entspricht zu gewährleisten wurde der medizinische Kommunikationsstandard POCT1-A ins Leben gerufen.

3. POCT1-A

3.1. Entstehung von pocti-a

Der Standard ist in Folge dreier Spezifikationen entstanden. Als Grundlage diente die Spezifikation des Connectivity Industry Consortium CIC. Das CIC ist eine Vereinigung von 52 Organisationen, die aus Medizingeräteherstellern und -anbietern bestehen. Mit­glieder in diesem Konsortium sind beispielsweise Philips Medical Systems, Bayer Dia­gnostics und Roche Diagnostics/AVL. Im ersten Entwurf wurde eine Beschreibung der Attribute eines Access Points^[6], dem Kommunikationsprotokoll zwischen Gerät und Ac­cess Point und der Kommunikation zwischen einem Data Manager^[7] und dem KIS gege­ben. Aus diesen Anforderungen entwickelte sich in Zusammenarbeit mit Herstellern ei­ne Spezifikation, welche eine Fusion der Interessen und Vorgaben von CIC, NCCLS, HL7, IEEE ^[8], Herstellern und gesetzlichen Vorschriften darstellt (Abb. 3.1).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.1: Entwicklung des Point-of-Care Standards [13]

Bei der NCCLS, die sich erst kürzlich in CLSI umbenannt hat handelt es sich um eine glo­bale, non-profit, ANSI akkredierte Standardisierungsorganisation, welche Medizinische Standards fördert und im speziellen POCT1-A veröffentlich hat, und mit der Weiterent­wicklung des Standards beschäftigt ist.

Die aktuelle Version des Standards wurde im Dezember 2001 verabschiedet und ist mitt­lerweile ein IEEE und NCCLS Standard. Es sind zudem Bestrebungen im Gange POCT1-A in HL7 zu integrieren.

3.2. Überblick pocti-a

Der Standard besteht aus zwei Kommunikationsschnittstellen, zum einen das Device In­terface und zum anderen das Observation Reporting (EDI) Interface. Der Focus dieser Ar­beit richtet sich jedoch nur auf die erste der beiden Schnittstellen, das Device Interface, also dem Weg vom Gerät zum POC Data Manager. In dieser wird die Übermittlung von Messdaten über eine vorhandene Infrastruktur beschrieben. Der zweite Teil befasst sich mit der Weitergabe dieser Daten ins KIS (Abb. 3.2)

Abbildung 3.2: Aufbau von POCT1-A [13]

- Devices, Docking Stations:

Diese Geräte werden normalerweise laut Standard durch physikalische POCT - Ge­räte repräsentiert. Nach aktuellem Stand existieren jedoch noch keine Geräte, wel­che POCT1-A implementiert haben auf dem Markt. In dieser Arbeit übernimmt ein Sharp Zaurus PDA mit einer softwarebasierten Lösung deren Stelle, mit welchem sich beliebige Geräte an den Standard anpassen lassen.

- Access Points / Network:

Damit das Gerät mit dem POC Data Manager kommunizieren kann muß eine vor­handene Netzinfrastruktur des Krankenhauses genutzt werden. In letzter Zeit ver­fügen immer mehr Krankenhäuser über eine krankenhausweite WLAN Abdeckung, deshalb wird in dieser Arbeit diese Übertragungsmedium gewählt.

Eine drahtlose Anbindung von POCT Geräten birgt etliche Vorteile gegenüber ei­ner kabelgebundenen- oder Synchronisations Lösung. Der wichtigste Vorteil neben der Mobilität ist wohl die sofortige Verfügbarkeit der Messwerte im KIS.

- POC Data Manager:

Der POC Data Manager besteht aus einem Observation Reviewer41, welcher primär als Server fungiert. Mit Hilfe dieses Servers kann das POC Device konfiguriert, gewartet und abgefragt werden. Zudem bietet der Observation Reviewer auch die Möglichkeit die Daten weiter ins KIS zu verbreiten (Abb. 4.1)

3.3. Aufbau von pocti-a

Der POCT1-A - Standard sieht für die Kommunikation zwischen einem POCT Gerät und Observation Reviewer die Verwendung von XML - Nachrichten vor. Zu der Zeit, als der Standard spezifiziert wurde, wollte man den damals aktuellen Stand in der Entwick­lung der XML Funktionalität von HL7 Version 3.0 einbringen. Deshalb orientieren sich die POCT1-A XML Datentypen auch an den damaligen Entwürfen des HL7 Standards in der Version 3.0. Die POCT1-A Nachrichten setzen sich aus einzelnen POCT1-A - Objekten zusammen, welchewiederrum aus einzelnen POCT1-A - Datentypen bestehen (Abb. 3.3).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.3: Aufbau von POCT1-A

4Im folgenden Text ist hierunter eine Serveranwendung zu verstehen, welche eingehende Ver­bindungen von Geräten annimmt und verwaltet.

[...]

---

^[1] Der Begriff des Observation Reviewers ist hier vorerst als einfache Gegenstelle zum Empfang von Nachrichten welche von einem Gerät gesendet werden zu sehen und wird später genauer definiert.

^[2] Kommunikationsweg zwischen einem Gerät und einem Empfänger für POCT1-A Nachrichten.

^[3] xDT ist ein nationaler Standard, der in Deutschland bei Praxiscomputersystemen vor allem zum Austausch von Daten zur Abrechnung (ADT) und für Behandlungsdaten (BDT) eingesetzt wird.

^[4] Lehre von der Bewegung des Blutes im Gefäßsystem

^[5] Graphische Darstellung von Wellen an Hand der Amplitudenveränderung bezogen auf die Zeit.

^[6] Zugangspunkt in einem Netzwerk, dies wird im nächsten Absatz noch genauer erkläutert (Abb.:3.2)

^[7] Empfangsstelle für Nachrichten, dies wird im nächsten Absatz noch genauer erkläutert (Abb.:3.2)

^[8] Standardisierungsorganisation http://www.ieee.org