Der Schwerpunkt dieser Arbeit liegt in der Entwicklung eines Frameworks zur drahtlosen Übertragung von Messwerten unter Nutzung des POCT1-A Standards. Es wird zunächst ein Überblick gegeben über medizinische Kommunikationsstandards im Allgemeinen, um dann im Detail auf den POCT1-A Standard einzugehen. Entwicklungsplattformen und Implementierungstechniken, die bei der Umsetzung verwendet wurden werden vorgestellt, um abschließend noch ein Überblick über die Komponenten der erstellten Anwendung und insbesondere dem Pluginsystem zu geben.
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 drahtlosen Übertragung von Messwerten unter Nutzung des POCT1-A Standards. Es wird zunächst ein Überblick gegeben über medizinische Kommunikationsstandards im Allgemeinen, um dann im Detail auf den POCT1-A Standard einzugehen. Entwicklungsplattformen und Implementierungstechniken, die bei der Umsetzung verwendet wurden 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 transmission of measurments using the POCT1-A standard. First an overview of medical communication standards in general is given, to present the POCT1-A standard in detail afterwards. Development environment and implementation techniques, which are used in jthe implementation, are introduced. Concluding, a survey of the components of the developed 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 beobachten. Heute gibt es eine Vielzahl von verschiedenen Techniken, Daten kabellos zu übertragen, und genauso vielfältig sind die Anwendungsbereiche dafür. Kann man in manchen 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 undenkbar 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 unterstützt eine Vielzahl von Diagnosetests direkt am Patienten, dem sogenannten „Point of Care" (POC). Selbst anspruchsvolle Tests, welche bisher nur in speziellen Laboren möglich 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 Krankenhausbetten 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äuser 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 Krankenhausinformationssysteme (KIS) nochmals verkürzen bzw. vollständig vernachlässigen. Unmittelbar nachdem 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 zwischen 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 geschaffen, die direkt am Klinikbett eingesetzt werden. Über eine Schnittstelle zwischen Gerät und einem sogenannten Observation Reviewer[1], definiert das POCT-1A Kommunikationsprotokoll den Austausch von Nachrichten im XML-Format. Diese Nachrichten orientieren sich an einem neuen XML-Nachrichtenformat, welches zur Zeit des Entwurfes von POCT1-A dem Stand der XML-Nachrichten in der HL7 Version 3 Verwendung entsprach. Dadurch ist es möglich, validierte Informationen ins Krankenhausinformationssystem 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 einem 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 vorhandene 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 Krankenhauses, das alle informationsverarbeitenden (und -speichernden) Prozesse und die an ihnen beteiligten menschlichen und maschinellen Handlungsträger in ihrer informationsverabeitenden Rolle umfasst. Das KIS dient dazu, 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 Beschreibung über die Beschaffenheit eines Krankenhausinformationssystems lässt sich nur schwer formulieren. Die Vermutung, dass es sich hierbei um ein homogenes System handelt ist nicht korrekt. Informationsverarbeitung in einem Krankenhaus besteht aus einer heterogenen Welt, die auch in einem heterogenen System zusammengefasst werden muss. Um KIS beurteilen zu können muß eine Möglichkeit geschaffen werden ein solches 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 „konzeptionellen 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 entstanden:
- 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 Komponenten 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 Krankenhaus 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 medizinische Kommunikationsstandard HL7 entwickelt.
Mit diesem Standard und zwei daraus hervorgegangenen, der Clinical Document Architecture (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 Level 7 nennt, entwickelt und etabliert. Diese Organisation hat es sich zum Ziel gesetzt, eine Standardisierung der Kommunikation in Krankenhäusern und im gesamten Gesundheitswesen 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 Schnittstellen zwischen verschiedenen heterogenen Systemen wertvolle Hilfen zur Verfügung. Ein wichtiges Merkmal des Standards ist es, dass dieser unabhängig von Software, Hardware oder dem verwendeten Netzwerk einsetzbar ist. Die Konfiguration liegt allein in der Hand des Anwenders. Unterzieht man diese Freiheiten in der Konfiguration einer kritischen 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 diese 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 Datenaustausch 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 Inhalte und die damit verbundene Vereinheitlichung der Schnittstellen. Dadurch wird eine Verbesserung in der Effizienz und eine Reduktion der Zahl der Kommunikationswege/Schnittstellen erreicht (Abb.: 2.2). Der so verminderte Aufwand bei der Implementierung von Schnittstellen liegt zwischen 60% und 80% [10]. Standardisiert werden Nachrichtenstrukturen, die Darstellung der Nachrichten für die Übertragung und die Anwendungsereignisse, welche zur Auslösung von Nachrichten dienen. Der Standard bietet vielschichtige Einsatzmöglichkeiten und wird unter anderem bei der Patientenregistrierung, Aufnahme, Verlegung bzw. Entlassung, 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 pragmatischen Ansatz. Es existieren Methodologien zur Ableitung von Nachrichten und es wurde ein sogenanntes Reference Information Model, kurz RIM eingebunden. Desweiteren gibt es ein Domain / Refined Message Information Model (C/R - MIM) und eine Hierarchical Message Definition (HMD), auf die jedoch nicht weiter 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 Realisierung,
- Acts (Aktionen),
- Role Relationships (Rollenbeziehungen) zur Vermittlung der Interaktion zwischen 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 Kommunikationsserver verwendet. Unter einem solchen Server versteht man eine spezialisierte Middleware zur Integration von Subsystemen eines übergeordneten Informationssystems auf Anwendungsebene [11]. Durch den Einsatz von Kommunikationsservern kann eine Reduktion 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 anerkannter Standard für Gesundheitsinformationen auf der Basis von XML [4]. Dieser Standard 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 Framework.
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 Beobachtungen 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, sondern die Daten persistent in Dokumenten abgelegt werden.
2.2.3. SCIPHOX
Die Abkürzung SCIPHOX bedeutet Standardized Communication of Information Systems in Physician Offices and Hospitals using XML. Der Standard ist eine nationale Adaption der CDA Release 1. Es werden Bausteine, sogenannte Small Semantic Units (SSUs) entwickelt, mit welchen die unterschiedlichsten Patientendokumente im deutschen Gesundheitswesen 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 stationä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 spezifiziert Entlassungsbriefe mit Diagnosen, Therapien, Informationen zur Weiterbehandlung, 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äische 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 medizinischen 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 Anforderungen nur schwer gewachsen.
Eine gemeinsame Arbeitsgruppe des American College of Radiology (ACR) und der National Electrical Manufacturers Association (NEMA) startete 1983 den Versuch, ein Austauschformat 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 Communications 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 Daten, Netzwerkorientierte Dienste, Formate für den Datenträgeraustausch sowie Anforderungen an korrespondierende Geräte und Programme.
Damit reicht DICOM weit über die Definition eines reinen Austauschformates für medizinische Bilddaten hinaus. Ein DICOM - Bild besteht aus einer Liste von Datenelementen (sogenannten Attributen), die eine Vielzahl von bildbegleitenden Informationen enthalten, 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 Arbeitsaufträ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 Anwendungsprofile, die genau beschreiben, von welchen Modalitäten Bilder auf dem Datenträger gespeichert sein dürfen, welche Zahlenformate und Kompression verwendet werden dürfen 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üglich 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 hinzugefügt, um den Standard auch in Bereichen der Kardiologie zu verwenden. Es wurden bereits vorhandene DICOM Mechanismen verwendet und mit 16-bit waveforms[5] kombiniert. 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 Darstellung von Vitalparametern und einer geräteunabhängigen Übertragung dieser geschaffen [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 Messwerten 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 verwalteten 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 weiterführen lassen, jedoch sollte hier nur ein kurzer Überblick über die Aufgaben solcher Standards an einigen Beispielen gegeben werden. Durch die Vielzahl medizinischer Kommunikationsstandards 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 Vorteile, 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 notwendig 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 mehrtä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 solcher Geräte ist es nun auch möglich die Tests vor Ort direkt am Patienten, am sogenannten 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 kleinen handlichen Geräten, noch größeren Geräte, welche jedoch im Bezug auf die Datenkommunikation 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 Produktion von POCT Geräten begonnen. Momentan gibt es eine Vielzahl von verschiedenen 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 Papierausdrucken 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 Hauptproblem 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 Erfassung 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ätssicherung dieser Geräte. POCT Geräte müssen regelmässig gewartet und neu kalibriert werden. 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 geregelt. Um jedoch eine lückenlose Kontrolle zu gewährleisten ist ein zusätzlicher Mehraufwand notwendig. Zudem sind die aktuellen Geräte diesen Anforderungen nicht gewachsen, 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. Mitglieder in diesem Konsortium sind beispielsweise Philips Medical Systems, Bayer Diagnostics und Roche Diagnostics/AVL. Im ersten Entwurf wurde eine Beschreibung der Attribute eines Access Points[6], dem Kommunikationsprotokoll zwischen Gerät und Access Point und der Kommunikation zwischen einem Data Manager[7] und dem KIS gegeben. Aus diesen Anforderungen entwickelte sich in Zusammenarbeit mit Herstellern eine 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 globale, non-profit, ANSI akkredierte Standardisierungsorganisation, welche Medizinische Standards fördert und im speziellen POCT1-A veröffentlich hat, und mit der Weiterentwicklung des Standards beschäftigt ist.
Die aktuelle Version des Standards wurde im Dezember 2001 verabschiedet und ist mittlerweile 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 Interface und zum anderen das Observation Reporting (EDI) Interface. Der Focus dieser Arbeit 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 - Geräte repräsentiert. Nach aktuellem Stand existieren jedoch noch keine Geräte, welche 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 vorhandene Netzinfrastruktur des Krankenhauses genutzt werden. In letzter Zeit verfü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 einer 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 Entwicklung 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 Verbindungen 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
-
-
-
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen.