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. Entwicklungs-plattformen 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 de- veloped application and in particular the plugin system is given.

Inhaltsverzeichnis

Abbildungsverzeichnis   vii

Tabellenverzeichnis x   

1  Einleitung  1

1.1  Motivation  1

1.2  Aufgabenstellung  3

2  Stand der Technik  4

2.1  Krankenhausinformationssysteme  4

2.2  Medizinische Kommunikationsstandards  5

2.2.1  HL7  5

2.2.2  CDA  9

2.2.3  SCIPHOX  9

2.2.4  DICOM  10

2.2.5  VITAL  12

2.2.6  Zusammenfassung  13

2.3  Point of Care Testing  13

3  POCT1-A  16

3.1  Entstehung von POCT1-A  16

3.2  Überblick POCT1-A  17

3.3  Aufbau von POCT1-A  18

3.4  Nachrichten Profile  20

3.4.1  Basic Message Flow  21

3.4.2  Continuous Mode  24

3.4.3  Asynchronous Mode  26

3.4.4  Fehlerbehandlung  27

Inhaltsverzeichnis v

4  Bewertung von POCT1-A  29

4.1  Vorteile von POCT1-A  29

4.2  Vergleich zu HL7  29

5  Entwurfsmuster  31

5.1  Befehls Muster  32

5.2  Fabrik Methode  34

5.3  Singleton Muster  35

5.4  Beobachter Muster  35

6  Entwicklungsplattformen  38

6.1  Zaurus SL5500  38

6.2  Entwicklungsumgebung  40

7  POCT1-A Framework und Anwendung  41

7.1  Anforderungen und Entwurf  41

7.2  POCT1-AFramework  42

7.2.1  Architektur und Entwurf  42

7.2.2  XML-Parser  45

7.2.3  Schnittstellen  46

7.3  Pluginsystem  48

7.3.1  Bibliotheken  48

7.3.2  Entwurf eines Pluginsystems  49

7.3.3  SpO2- Plugin  53

7.4  Core  53

7.5  Device Interface  55

7.5.1  Anforderungen  55

7.5.2  Entwurf und Design  55

7.6  Observation Reviewer  56

7.6.1  Anforderungen  56

7.6.2  Entwurf und Design  56

7.7  Use-case Szenario  57

8  Zusammenfassung und Ausblick  59

Anhang 59   

A  POCT1-A  61

Inhaltsverzeichnis vi

A.1  Datentypen  61

A.2  Objekte  66

A.3  Nachrichten  74

A.4  UML Diagramme  77

Literaturverzeichnis   81

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 DICO-MStandard (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  

Abbildungsverzeichnis   

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-LA-NKarte, 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  

Abbildungsverzeichnis   

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 POCT1-ADatentypen . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Tab. A.2 Encapsulated Data (ED) . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Tab. A.3 Character String (ST) . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Tab. A.4 Coded Simple Value (CS) . . . . . . . . . . . . . . . . . . . . . . . . . 62 Tab. A.5 Coded Value (CV) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Tab. A.6 Coded with Equivalents (CE) . . . . . . . . . . . . . . . . . . . . . . 63 Tab. A.7 Person Name (PN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Tab. A.8 Person Name (PN) Child Elements . . . . . . . . . . . . . . . . . . . 64 Tab. A.9 Organization Name (ON) . . . . . . . . . . . . . . . . . . . . . . . . . 64 Tab. A.10 Integer Number (INT) . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Tab. A.11 Real Number (REAL) . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Tab. A.12 Physical Quantity (PQ) . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Tab. A.13 Point in Time (TS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Tab. A.14 Null Code Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Tab. A.15 POCT1-ANachrichten . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Abkürzungsverzeichnis

ACR . . . . . . . . . . . . . . . . American College of Radiology

ANSI . . . . . . . . . . . . . . . American National Standards Institute CDA . . . . . . . . . . . . . . . . Clinical Document Architecture CF . . . . . . . . . . . . . . . . . . Compact Flash CIC . . . . . . . . . . . . . . . . . Connectivity Industry Consortium CLSI . . . . . . . . . . . . . . . . Clinical and Laboratory Standards Institute D/R-MIM . . . . . . . . . . . Domain / Refined Message Information Model DICOM . . . . . . . . . . . . . Digital Imaging and Communications in Medicine DIM . . . . . . . . . . . . . . . . Domain Information Model EDI . . . . . . . . . . . . . . . . . Electronic Data Interchange EKG . . . . . . . . . . . . . . . . Elektrokardiogramm GOF . . . . . . . . . . . . . . . . Gang Of Four GUI . . . . . . . . . . . . . . . . . Graphical User Interface HL7 . . . . . . . . . . . . . . . . . Health Level 7 HMD . . . . . . . . . . . . . . . Hierarchical Message Definition IEEE . . . . . . . . . . . . . . . . Institute of Electrical and Electronics Engineers ISO . . . . . . . . . . . . . . . . . International Standards Organization KIS . . . . . . . . . . . . . . . . . KrankenkausInformationsSystem NCCLS . . . . . . . . . . . . . National Commmittee for Clinical Laboratory Standards NEMA . . . . . . . . . . . . . . National Electrical Manufacturers Association OSI . . . . . . . . . . . . . . . . . Open Systems Interconnect PACS . . . . . . . . . . . . . . . Picture Archiving and Communication System PDA . . . . . . . . . . . . . . . . Personal Digital Assistent POC . . . . . . . . . . . . . . . . Point Of Care POCT . . . . . . . . . . . . . . . Point Of Care Testing RIM . . . . . . . . . . . . . . . . . Reference Information Model RIS . . . . . . . . . . . . . . . . . . Radiology Information System

Tabellenverzeichnis xii

SCIPHOX . . . . . . . . . . . Standardized Communication of Information Systems in Physician

SSU . . . . . . . . . . . . . . . . . Small Semantic Units

UML . . . . . . . . . . . . . . . . Unified Modeling Language VITAL . . . . . . . . . . . . . . Vital Signes Information and Representation WLAN . . . . . . . . . . . . . . Wireless Local Area Network XML . . . . . . . . . . . . . . . . extensible markup language

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 Mikrofluidik 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.

1. Einleitung 2

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 ¹ , 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.

¹ 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.

1. Einleitung 3

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 ² durch eine POCT-Serverapplikation und als Gegenstelle eine POCT-Deviceapplikation realisiert werden. Zur Verifikation der Implementierung soll auf Device-Seite ein Bluetooth Pulsoximeter (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.

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.

² Kommunikationsweg zwischen einem Gerät und einem Empfänger für POCT1-A Nachrichten.

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].

2. Stand der Technik 5

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 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 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

2. Stand der Technik 6

Anwendungsschicht zugeordnet sind und der Standard auf dieser aufsetzt (Abb. 2.1). Er spezifiziert Kommunikationsinhalte und Austauschformate und ist seit 1987 ANSI akkredierter 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.

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,

2. Stand der Technik 7

- 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.

• 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

2. Stand der Technik 8

- 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.