3. Standards (Teil 1)

Ausgangslage für den elektronischen Datenaustausch ist immer die Situation, dass ein System Daten benötigt, welche ein anderes System in elektronischer Form gespeichert hat. Die notwendigen Daten müssen somit von einem Quell-System zu einem Ziel-System übermittelt werden.

Für den reibungslosen elektronischen Austausch der Daten müssen unter den involvierten Parteien eine Fülle von Standards (Normen) definiert und durchgesetzt werden. Die Standards können von Behörden, Organisationen und Benutzern festgelegt werden und beziehen sich auf unterschiedliche Bereiche und Ebenen. Eine Möglichkeit zur Unterscheidung der verschiedenen Ebenen bietet das von der Internationalen Standard Organisation (ISO) entwickelte OSI-Modell. Das Modell unterscheidet sieben Schichten, wobei jede Schicht gewisse Aufgaben zu erfüllen hat und der nächst höheren Schicht Dienste zur Verfügung stellt, so dass die höhere Schicht auf diesen Diensten aufbauen kann. Die oberste Schicht ist die Applikationsschicht und stellt Anwendungsdienste zur Verfügung ([Tann97]).

Die Ausführungen in dieser Arbeit und insbesondere in diesem Kapitel konzentrieren sich auf diese Ebene; es wird davon ausgegangen, dass auf Dienste der unteren Schichten aufgebaut werden kann. Standards und Konzepte betreffend der Schichten 1 bis 6 werden deshalb nur in Ausnahmefällen behandelt.

Nachrichten werden vom Quell- zum Zielsystem geschickt und enthalten die auszutauschenden Daten. Bei den Nachrichten handelt es sich um Dateien, welche in einer definierten Form (Struktur) aufgebaut sind, so dass der Empfänger die Nachricht richtig interpretieren und weiter verarbeiten kann. Die im Folgenden vorgestellten Standards definieren die Struktur der Nachrichten und die Regeln für den reibungslosen Austausch der Dateien. Es werden ausschliesslich Standards beschrieben, welche sich im Hinblick auf Einsatzmöglichkeiten im Gesundheitswesen eignen.

Eng verbunden mit den Standards sind die Institutionen, welche sie definieren oder zu ihrer Verbreitung beitragen. Wichtige Institutionen im Zusammenhang mit den Standards werden deshalb ebenfalls genannt.

Häufig werden Daten aus Gründen der Effizienz oder Sicherheit in abgekürzter Form (® Codes) verwendet und übermittelt. Beispielsweise werden Diagnosen in verschlüsselter Form durch Diagnosecodes beschrieben. In solchen Fällen müssen zusätzliche Interpretationsregeln vorhanden sein. Nur so kann gewährleistet werden, dass durch die Verschlüsselung der Daten in den Feldern kein Informationsverlust entsteht und der Inhalt verstanden werden kann. Standards dieser Kategorie werden in diesem Kapitel ebenfalls kurz erwähnt.

Wenn Daten zwischen Systemen ausgetauscht werden, so stellen sich damit sofort auch Fragen bezüglich der Sicherheit. Den Bedrohungen "Verlust der Vertraulichkeit und der Integrität" sind beim Datenaustausch im Gesundheitswesen speziell Beachtung zu schenken. Sicherheitsaspekte können berücksichtigt werden, indem der Datenaustausch-Standard selbst entsprechende Möglichkeiten zur Verfügung stellt oder indem der Standard in Kombination mit "unabhängigen" technischen Möglichkeiten verwendet wird. Beispiele technischer Möglichkeiten sind symmetrische und asymmetrische kryptographische Verschlüsselungstechniken oder Authentifizierungsalgorithmen (vgl. [Schm92]).

Auf Sicherheitsaspekte wird im Folgenden nur eingegangen, wenn der Datenaustausch-Standard eigene Möglichkeiten anbietet und diese speziell auf das Gesundheitswesen ausgerichtet sind.

Eine Integration von Systemen kann auf verschiedene Arten erfolgen. Mit der oben erwähnten Technik werden die Daten redundant gehalten; die gleichen Daten sind an mehreren Orten gespeichert und werden via Nachrichten ausgetauscht. Verteilte Datenbanken gehen von einem anderen Ansatz aus: Applikationen stützen sich auf das Datenbankverwaltungssystem ab. Die Daten können durchaus an verschiedenen Orten (und sogar redundant) gehalten werden. In diesem Fall übernimmt aber das Datenbanksystem die Verwaltung und den Austausch der Daten.

EDI (Electronic Data Interchange) steht für den elektronischen Austausch von Daten. EDI ist jedoch kein Standard, sondern muss als umfassendes Konzept angesehen werden (vgl. [Schm92]).

Eine mögliche Definition von EDI ist die folgende:

"EDI steht für den elektronischen Austausch von Daten. So ermöglicht EDI den Informationsaustausch von Computeranwendungssystemen von unterschiedlichen Herstellern und Lokalitäten. EDI ist also eine Leitvorstellung weltweiter, branchenübergreifender, Wirtschaft und öffentliche Verwaltung einschliessender, standardisierter Geschäftskommunikation. Im Gegensatz zur elektronischen Post reicht es jedoch nicht, beliebige Daten in beliebigen Datenformaten auszutauschen. Es muss sich vielmehr um strukturierte Daten handeln, die so aufgebaut sind, dass die beteiligten Computer sie erkennen können; dies gestattet EDI. Die Übermittlung der Daten erfolgt über Telekommunikationsnetze, wobei die Übertragungsart unerheblich ist."

([BeMe91])

Im Zusammenhang mit EDI ist eine Fülle von Aspekten zu beachten, damit der elektronische Datenaustausch reibungslos und effizient durchgeführt werden kann. Neben einheitlichen Datenaustauschformaten (Standards) müssen weitere Aspekte berücksichtigt werden. Beispielsweise sind die Schnittstellen zu den Systemen zu implementieren, ein entsprechendes Netzwerk (® Clearing Center) wird benötigt, Sicherheitsüberlegungen müssen gemacht werden, und oft resultiert eine Reorganisation. Diese Aspekte werden im Folgenden nicht weiter behandelt. Es existiert aber ein grosses Angebot an Literatur zu diesen Themen. Beispielsweise eignet sich [Schm92] sehr gut für einen raschen Einstieg in die komplexe Materie und vermittelt einen guten Überblick.

Einige Autoren setzen bei der Definition von EDI voraus, dass die Übermittlung der Daten von Computer zu Computer ohne manuelle Intervention und über ein Telekommunikationsnetz erfolgt. Diese Einschränkung wird in der folgenden Diskussion aufgehoben. Der elektronische Datenaustausch via CD-ROM, Diskette oder Patientenkarte wird somit ebenfalls berücksichtigt. Insbesondere im Gesundheitswesen könnte der elektronische Austausch von Daten via Patientenkarte eine echte Alternative sein. Aus diesem Grund werden zu dieser Art der Übermittlung im Anhang ("Patientenkarte") einige grundlegende Gedanken beschrieben.

3.1 Internationale Standards

3.1.1 Health Level Seven (HL7)

Überblick

Health Level Seven (HL7) ist ein Standard für den elektronischen Datenaustausch im Gesundheitswesen. Das Wort "Seven" des Namens verweist auf die siebte Schicht des OSI-Modells. HL7 ist in die Applikationsschicht einzuordnen und legt fest, wie eine Nachricht aufgebaut wird (abstract message definition). Weiter wird geregelt, wie bei gewissen Fehlern zwischen den Applikationen vorgegangen wird und wann die Nachrichten ausgetauscht werden.

Der Standard stammt von der HL7 Working Group, einem Komitee aus Benutzern, Herstellern und Beratern. Gegründet wurde das Komitee 1987 und zählt heute über 1500 Mitglieder aus unterschiedlichen Bereichen und Ländern. Im Juni 1994 wurde HL7 zu einer "ANSI Accreditied Standards Developing Organization" ernannt. Im Dezember 1994 wurde die Version 2.2 publiziert und zur Zeit wird an der Version 3.0 gearbeitet. Die folgenden Angaben beziehen sich auf die Version 2.3 (ballot draft #3), welche auf dem Internet für jedermann zur Verfügung steht und die in ihrer endgültigen Fassung demnächst publiziert werden soll ([http://www.mcis.duke.edu/standards/HL7/pubs/version2.3]).

Kommunikationsmodell und Konzepte

Es wird davon ausgegangen, dass aufgrund eines Ereignisses in der realen Welt ein Datenfluss zwischen Systemen benötigt wird. Ereignisse (trigger events) sind Auslöser für das Generieren von Nachrichten und das Verschicken an den Empfänger.

Eine Nachricht ist die kleinste auszutauschende Einheit zwischen zwei Applikationen. Mittels Nachrichten werden Daten aus der Datenbank einer Applikation in der Regel an die Datenbank einer anderen Applikation geschickt, so dass der Empfänger die notwendigen Daten besitzt, die er zur Erfüllung seiner Arbeit benötigt.

Beispielsweise kann das Ereignis "Patient eingetroffen" der Auslöser für das Generieren und Verschicken von Nachrichten vom Typ ADT (admission, discharge and transfer) sein, so dass bestimmte Daten über einen Patienten bei seinem Eintreffen (und nach Eingabe der Daten ins System) an definierte Systeme weitergeleitet werden.

Das zugrundeliegende Modell bei der Kommunikation entspricht dem eines Client-Server Systems; eine Partei schickt eine Nachricht an ein System und erhält anschliessend eine Antwort. Es lassen sich zwei Arten von Kommunikationsbeziehungen unterscheiden: Nachrichten und Anfragen.

Nachrichten: Ein System schickt aufgrund eines Ereignisses eine Nachricht an ihren Bestimmungsort. Um sicherzustellen, dass die Nachricht beim Empfänger eingetroffen ist, muss der Empfänger das Eintreffen quittieren. HL7 vertraut hier nur begrenzt auf Dienste der unteren Schichten (vgl. OSI-Modell) und fordert deshalb auf Applikationsebene eine Bestätigung. Zudem übernimmt der Empfänger durch die Quittierung die "Verantwortung" über die Daten und entbindet den Sender von einem nochmaligen Verschicken (® Fehlerprozedur). Wenn die Nachricht bestätigt wird, kann angegeben werden, ob Fehler und gegebenenfalls welche Fehler aufgetreten sind.

Neben der einfachen Quittierung einer Nachricht kann eine zweite, erweiterte Bestätigung verschickt werden, welche über den Verlauf der durchgeführten Arbeiten informiert.

Anfragen: Eine Anfrage ist syntaktisch genau gleich wie eine Nachricht aufgebaut. Die Anfrage unterscheidet sich jedoch bezüglich Bestätigung (acknowledge) und Semantik von den "normalen" Nachrichten.

Ein System kann aufgrund mangelnder Daten eine Anfrage an ein anderes System stellen, worauf der Empfänger die Frage beantwortet. Beispielsweise soll aufgrund des Ereignisses "Neues Treffen planen" eine Person einem bestimmten Termin und Ort zugeordnet werden. Wenn zur betreffenden Person wichtige Angaben fehlen, so kann das Planungssystem beim Verwaltungssystem eine Anfrage machen, worauf die benötigten Daten eventuell übermittelt werden.

Die Antwort auf eine Anfrage kann unmittelbar nach der Übermittlung oder nach einem bestimmten Zeitintervall zurückgeschickt werden. Weiter besteht die Möglichkeit, dass der Benutzer direkt Anfragen stellen kann und die Antwort auf dem Ausgabemedium dargestellt wird.

Obwohl sich HL7 am Client-Server Modell orientiert, stellt es trotzdem die Möglichkeit zur Verfügung, Nachrichten und somit Daten im Batch-Modus, off-line zu verteilen. Die Nachrichten werden nach den gleichen Regeln und Syntax erstellt und anschliessend in einem File zusammengefasst. Das File kann nun über verschiedene Wege an sein Bestimmungsort gelangen, wie zum Beispiel via FTP oder Diskette. HL7 stellt dabei eine Reihe von Optionen zur Verfügung, wie die Nachrichten in diesem Fall zu bestätigen sind.

Es werden generell keine Einschränkungen gemacht, wie lange die einzelnen Komponenten und die Nachrichten selbst maximal sein dürfen. Um die Fehleranfälligkeit zu reduzieren (Bsp. Lower-layer Protokoll unterstützt Kommunikation nur bis zu einer maximalen Länge), wurden Empfehlungen über Grössen abgegeben. HL7 erlaubt deshalb die Aufsplitterung einer Nachricht in kleinere Teile, welche wiederum Nachrichten sind. Der Empfänger setzt die einzelnen Nachrichten anschliessend wieder zu einer semantisch vollständigen Nachricht zusammen.

Meistens werden die Daten in den Nachrichten in die Datenbank des Empfängers eingefügt. Es kann allerdings vorkommen, dass die Daten lediglich auf dem Bildschirm benötigt werden. In diesem Fall stellt HL7 entsprechende Nachrichtentypen zur Verfügung und unterstützt Datentypen, in welchen die Darstellungsart festgelegt werden kann.

Die Working Group hat mit HL7 einen flexiblen Standard erarbeitet. Das bedeutet für den Benutzer, dass er eigene Nachrichtentypen, Triggers, Segment- und Feldtypen definieren kann. Weiter sind viele Felder optional und Konstanten müssen definiert werden. Dieser grosse Vorteil von HL7 ist zugleich seine Schwachstelle, denn wenn zwei Parteien den Standard einsetzen wollen, muss zuerst analysiert, spezifiziert, programmiert und getestet werden. HL7 ist nicht Plug and Play ([BaDa95]).

Nachrichtenstruktur

Eine Nachricht ist die kleinste auszutauschende Einheit zwischen zwei Systemen. Eine Nachricht setzt sich aus einer Menge von Segmenten zusammen, welche ihrerseits wiederum aus einer Menge von Feldern bestehen.

Alle Daten werden durch Zeichen eines ausgewählten Zeichensatzes repräsentiert, wie beispielsweise ASCII oder UNICODE. Zur Trennung der einzelnen Komponenten werden spezielle, teilweise selbst definierbare Zeichen verwendet.

Felder

Ein Feld ist eine Menge von Zeichen (getrennt durch Delimiters). HL7 kümmert sich bei der Übermittlung nicht darum, wie die Daten in den Applikationen gespeichert sind, sondern sendet alles in Form von Zeichenketten (Strings) an den Empfänger. Neben leeren Feldern können Nullwerte, gekennzeichnet durch "", übermittelt werden.

Felder werden zu Segmenten zusammengefasst, wobei bei jedem Segment definiert ist, welche Felder wann und wie vorkommen dürfen. Folgende Möglichkeiten stehen zur Verfügung:

Segmente

Felder werden als logische Einheit zu Segmenten zusammengefasst. Einzelne Segmente innerhalb einer Nachricht werden durch ein spezielles Zeichen (ASCII Carriage Return) getrennt. Jedes Segment beginnt mit einer 3-stelligen Zeichenfolge, welche es innerhalb einer Nachricht eindeutig identifiziert ist. Segmente können zwingend oder optional definiert sein und können sich wiederholen. Zu jedem Segmenttyp ist festgelegt, welche Felder an welcher Stelle wie vorkommen dürfen (vgl. Abschnitt "Felder").

Nachrichten und Triggers

Eine Nachricht ist die kleinste Einheit von Daten, welche zwischen zwei Systemen ausgetauscht wird. Sie setzt sich aus einer Menge von Segmenten zusammen, wobei die Reihenfolge dieser Komponenten genau definiert ist. Das erste Segment einer Nachricht ist das MSH-Segment (Message Header), welches Daten über Sender, Empfänger und andere, allgemein benötigte Angaben macht. Die weiteren Segmente sind je nach Typ der Nachricht unterschiedlich.

Jede Nachricht gehört zu einem Nachrichtentyp, der ihren Zweck festlegt. Zu einem Nachrichtentyp gehört zudem noch eine Menge von Triggern, welche den ganzen Ablauf in Gang setzen.

Auf konkrete Nachrichtentypen wird weiter unten genauer eingegangen.

Beispiel

Es soll eine Nachricht von einem System an ein anderes System geschickt werden, welche über das Eintreffen eines Patienten informiert.

Konkret soll übermittelt werden: Thomas A. Meier ist am 18. Juli 1997 um 11.23 Uhr von Doktor Klaus J. Brinkmann (#004777; = ID-Nummer) für Chirurgie-Untersuchungen eingeliefert worden. Er ist im Raum 2012, Bett 01 auf der Pflegestation (ID=2000) untergebracht.

Die Nachricht soll vom System ADT1 der Abteilung MCM an das System LABADT der gleichen Abteilung geschickt werden. Gesendet werden soll 3 Minuten nachdem die Einlieferung (und Dateneingabe) stattgefunden hat.

Der Nachrichtentyp ADT (Admission, Discharge and transfer) mit dem Trigger "Patient eingetroffen" drängt sich bei einer derartigen Aufgabenstellung auf. Der Aufbau einer entsprechenden Nachricht ist wie folgt definiert:

Die konkrete Nachricht könnte somit folgendermassen aussehen:

Nachrichtentypen

Jede Nachricht gehört zu einem Nachrichtentyp, wobei jeder Typ im Hinblick auf einen bestimmten Zweck definiert wurde. Im Folgenden werden wichtige Nachrichtentypen kurz beschrieben.

ADT - Admission, Discharge and Transfer

Mit Nachrichten des Typs "ADT" können Angaben über Patienten (demographisch) und deren Besuche im Krankenhaus gemacht werden. Da praktisch alle Systeme Patientendaten benötigen, wird dieser Nachrichtentyp sehr häufig benutzt und nimmt eine zentrale Stellung ein.

Aufgrund der verschiedenen Auslöser-Ereignisse (Triggers) werden die Nachrichten unterschiedlich aufgebaut. Unterstützt werden bei "ADT" über 50 Ereignisse, wobei die wichtigsten Vertreter sind:

Einlieferung, Austausch und Entlassung eines Patienten, Mutationen von Patientenangaben, Verschieben eines Patienten innerhalb des Krankenhauses, Verbinden von Patientendaten (Links), Zusammenfügen von Patientendaten und Verschieben von Patienten-Rechnungen.

Alle Nachrichten werden quittiert; die Bestätigungen gehören alle zum Nachrichtentyp "ACK" (General Acknowledgment).

Bestellungen

Es stehen verschiedene Nachrichtentypen zur Verfügung, um Bestellungen oder Informationen zu den Bestellungen zwischen Applikationen auszutauschen. In der Regel erfolgt eine Bestellung im Zusammenhang mit einem Patienten, und Sender und Empfänger sind Auftraggeber resp. Lieferant.

Der Nachrichtentyp "ORM" (Order message) wird verwendet, um Medikamente und Materialien innerhalb eines Krankenhauses oder bei einem externen Lieferanten zu bestellen. Weiter können mit "ORM" Bestellungen(Aufträge) zur Überwachung von Patienten und zum Diagnostizieren übermittelt werden. Als Antwort werden gegebenenfalls die gewünschten Ergebnisse übermittelt. Nahrungsmittel (und Diäten) sowie Behandlungsaufträge werden mit diesem Nachrichtentyp ebenfalls verschickt.

In die Kategorie "Bestellungen" fallen zudem vier Nachrichtentypen, welche den Austausch von Informationen über Impfungen erlauben.

Finanzen

Es steht eine Menge von Nachrichtentypen zur Verfügung, um Abrechnungsdaten (® Buchhaltung) zwischen den Systemen auszutauschen.

Beobachtungs-Reports

Mit den Nachrichtentypen dieser Kategorie können folgende Informationen ausgetauscht werden: Laborresultate, Ergebnisse von Bild-Analysen, EKG-Untersuchungen, Messwerte zu einem Patienten, Patientenzustand, Problem- und Diagnoselisten, Teile einer Kranken- und Pflegegeschichte usw.

Die Daten in den Reports sind textuell; mit den Nachrichten werden keine Bilder ausgetauscht.

Terminplanung

Die Terminplanung erlaubt die Zuteilung von Personen, Materialien und Dienste auf Zeitpunkte und Intervalle. Zu diesem Zweck stehen verschiedene Nachrichtentypen und Triggers zur Verfügung, und es können Termine abgefragt sowie neu eingetragen bzw. mutiert werden.

Bemerkungen

Es soll an dieser Stelle nochmals speziell darauf aufmerksam gemacht werden, dass HL7 keine Annahmen über Entwurf und Architektur der verwendeten Systeme macht. Der Standard konzentriert sich ausschliesslich auf die Spezifikation der Nachrichten, die Regeln für den Austausch und die Ereignisse, welche das Ganze auslösen.

International lässt sich heute kein vergleichbarer Standard finden, der den elektronischen Austausch innerhalb und zwischen Krankenhäusern in einer derart umfassenden Weise definiert ([Tres97]). HL7 ist nicht mehr nur ein "American national standard", sondern ist durch entsprechende Organisationen und Anwender international vertreten wie beispielsweise in den Ländern Australien, Deutschland, Frankreich, Japan, Niederlanden, Neuseeland und Kanada. Auch in der Schweiz wird über den Standard diskutiert; in den Interviews in den Spitälern wurde HL7 mehrmals erwähnt.

Eine spezielle Gruppe (IMSIG) befasst sich mit Aspekten bezüglich Handhabung und Austausch von Bildern. Das Ziel der Gruppe ist die Annäherung der Standards HL7 und DICOM. Mit einer Schnittstellen-Spezifikation sollen die Versionen 2.2 und höher von HL7 erweitert werden, um die "Interoperabilität" mit DICOM 3.0 zu gewährleisten. (Detaillierte Informationen und Diskussionen zu diesem Bereich lassen sich unter "ftp://www.mcis.duke.edu/standards/HL7/sigs" finden.)

Es wird versucht, wichtige Bereiche in HL7 aufzunehmen, um einen umfassenden Standard zur Verfügung zu stellen. Beispiele hierfür sind die Aufnahme von Nachrichtentypen zur graphischen Darstellung von Verläufen (Waveform) und die Zusammenarbeit mit DICOM. Heute wird HL7 aber vor allem für den Austausch von Text-Daten verwendet, und dort liegt derzeit seine Stärke.

Die Gruppe SIGSecure befasst sich mit Sicherheitsaspekten beim Datenaustausch mit HL7. Sie konzentriert sich dabei vor allem auf Mechanismen, um sichere Transaktionen gewährleisten zu können. Die Gruppe gibt entsprechende Vorschläge und Empfehlungen ab, so dass diesen Aspekten im HL7-Standard Rechnung getragen wird. Es wird auf bestehenden Standards und Konzepten im Bereich Sicherheit aufgebaut. (Genauere Angaben stehen unter "ftp://www.mcis.duke.edu/standards/HL7/sigs/secure" zur Verfügung.)

Quelle

Die Angaben beruhen vorwiegend auf dem Standard HL7 Version 2.3 (ballot draft #3), welcher unter "http://www.mcis.duke.edu/standards/HL7/pubs/version2.3" bezogen werden kann. Weitere Informationen rund um HL7 stehen in anderen Verzeichnissen derselben Adresse zur Verfügung. Im Artikel "Australian Implementation of the American National Standard, HL7" (M.D. Computing, Vol. 14, 1997) wird geschildert, wie HL7 in anderen Ländern eingesetzt werden kann und welche Erfahrungen mit HL7 in Australien gemacht wurden. Der Artikel "Health Level Seven / EDIFACT Communication Subsystem for Clinical Applications" (Cadorin M., IBM Zurich Research Laboratory, 1993) gibt eine kurze Zusammenfassung über den Standard und zeigt, wie HL7 in ein System eingebunden werden kann.

3.1.2 DICOM

Überblick

DICOM steht für "Digital Imaging and Communications in Medicine" und ist ein Standard für den elektronischen Datenaustausch von medizinischen Bildern. Der Standard stammt vom Komitee ACR - NEMA, einer Vereinigung vom "American College of Radiologie (ACR)" und der "National Electrical Manufactures Association (NEMA)". Das Komitee wurde 1983 gegründet und hat in den darauffolgenden Jahren drei Versionen des Standards veröffentlicht (1985 / 1988 / 1993).

Mit Hilfe des Standards soll es den Benutzern ermöglicht werden, digitale medizinische Bilder und dazugehörende Informationen unabhängig von den entsprechenden Geräten (und Herstellern) auszutauschen. Weiter soll mit DICOM eine Schnittstelle zu Systemen im Krankenhaus, welche auf anderen Standards basieren (z.B. HL7), zur Verfügung gestellt werden.

Um diese Ziele zu erreichen, macht der DICOM Standard eine Reihe von Spezifikationen: Es wird vorgeschrieben, welche Protokolle zwischen den Parteien eingesetzt werden müssen (Wer macht wann was?). Weiter werden Angaben zur Syntax und Semantik gemacht, und es wird festgelegt, welche Informationen benötigt werden und was dokumentiert werden sollte.

Der Standard besteht aus mehreren Teilen, welche jeweils einen abgeschlossenen Bereich abdecken und zu unterschiedlichen Zeitpunkten veröffentlicht wurden. Zum "Basis-Standard" (v3.0) gehören die Teile 1-9, welche 1993 als ganzes Paket veröffentlicht wurden. Der Standard ist in der Zwischenzeit in Form von Zusätzen und durch die Teile 10-13 erweitert worden ([ACNE94], [Merg97]).

Der "Basis-Standard" DICOM v3.0 kann als "Final Draft" kostenlos unter "ftp: // ftp.xray.hmc.psu.edu / dicom_docs / dicom_3.0" bezogen werden.

Kommunikationsmodell und Konzepte

Es werden zwei Typen von Austauschbeziehungen unterschieden: Benachrichtigungen und Aufträge.

Bei der Benachrichtigung informiert der Sender den Empfänger über das Eintreten eines Ereignisses oder Zustandswechsels. Im Gegensatz dazu wird bei Aufträgen der Empfänger veranlasst, Leistungen oder Operationen auf bestimmten Daten durchzuführen.

Sowohl Benachrichtigungen als auch Aufträge lehnen sich ans Client-Server Kommunikationsmodell an: Eine Partei verlangt eine gewisse Leistung oder informiert über ein Ereignis, worauf der Empfänger versucht, den Auftrag durchzuführen bzw. die Information zu verarbeiten. Anschliessend wird das Ergebnis zurückgeschickt. Im synchronen Modus wird jeweils auf eine Antwort gewartet, während im asynchronen Modus mehrere Anfragen verschickt werden können, ohne auf den Rückfluss zu warten.

Teile des Standards

Der Standard besteht aus mehreren, spezialisierten Teilen, welche in enger Beziehung zueinander stehen und teilweise aufeinander aufbauen. Im Folgenden werden die 13 Teile kurz vorgestellt, so dass ein vollständiger Überblick und ein umfassendes Verständnis für den Standard erhalten werden kann.

1. Teil: Einleitung und Übersicht

Wie der Name bereits sagt, dient der erste Teil des Standards der Einführung. Im Dokument beschrieben sind die Geschichte, der Hintergrund, grundlegende Definitionen, Ziele und ein Überblick über die Teile des Standards.

2. Teil: "Conformance"

Der DICOM-Standard enthält zwar eine Fülle von Definitionen und Vorschriften, aber wie bei allen anderen Standards sind auch hier bei einer Implementation eine Menge von Optionen vorhanden, so dass bei einer konkreten Umsetzung zusätzliche Sachen festgelegt und dokumentiert werden müssen. Beispielsweise können optionale Attribute gewählt werden, und es besteht die Möglichkeit, Klassen beizufügen oder zu spezialisieren. Je nach Einsatzort des Standards werden mit Vorteil nur die zwingenden und benötigten, optionalen Elemente implementiert.

Solche konkreten Implementationen müssen bei allen beteiligten Parteien bekannt sein, um die Kompatibilität innerhalb von DICOM zu gewährleisten und festzustellen, in welchen Bereichen mit den Partnern kommuniziert werden kann. Aus diesem Grund macht der zweite Teil des Standards Angaben, wie die konkreten Implementierungen zu dokumentieren sind. Das beinhaltet die Struktur, die zu verwendenden Techniken und vorkommenden Informationen.

Im Wesentlichen sind drei Bereiche betroffen: Welche "Informationsobjekte", welche Service-Klassen und welche Kommunikationsprotokolle werden unterstützt?

3. Teil: Definition der "Informationsobjekte"

Ein "Informationsobjekt" ist eine Abstraktion eines in der realen Welt vorkommenden Gegenstands oder einer Informationseinheit und wird anhand einer entsprechenden Klasse (IOD) formal beschrieben.

Der dritte Teil des Standards definiert eine Menge solcher Klassen, welche im Zusammenhang mit digitalen, medizinischen Bildern nützlich sein können. Dabei werden bei jeder Klasse der Zweck und die dazugehörenden Attribute beschrieben. Attribute können zu Gruppen zusammengeführt werden und als unabhängige Module in mehreren Klassen verwendet werden.

Beispiele solcher Klassendefinitionen sind: "Computed Radiography Image IOD", "Computed Tomography Image IOD", "Magnetic Resonance Image IOD", "Nuclear Medicine Image (IOD)", "Ultrasound Image (IOD)" usw.

4. Teil: Service-Klassen Definition

Der DICOM-Standard spezifiziert eine Menge von Service-Klassen. Eine Service-Klasse verbindet ein oder mehrere Informationsobjekte mit einem oder mehreren Befehlen, welche auf das Objekt angewendet werden. Die Definitionen legen fest, welche Befehle in einer Service-Klasse verwendet und wie die Befehle auf die Informationsobjekte angewendet werden. Zudem werden grundlegende Eigenschaften von Service-Klassen geregelt.

Als Beispiele für Service-Klassen können aufgelistet werden: "Storage Service Class", "Query Service Class", "Retrieval Service Class" und "Study Management Service Class".

5. Teil: Datenstruktur und Semantik

Dieser Teil des Standards definiert, nach welchen Regeln vorgegangen werden muss, um die in den Nachrichten oder Aufträgen enthaltenen Datensätze aufzubauen. Während Teil 3 und 4 Aussagen darüber macht, welche Daten von den Informationsobjekten und Service-Klassen benötigt werden, gibt dieser Teil also an, wie die einzelnen Daten in der Nachricht "verschlüsselt" werden und welche Syntaxen verwendet werden können.

Datensätze werden verwendet, um als geschlossene Einheit den Inhalt eines Informationsobjektes zu beschreiben. Jeder Datensatz besteht aus Datenelementen.

6. Teil: Datenelemente

In diesem Teil des Standards sind alle Datenelemente aufgelistet, welche in den Datensätzen verwendet werden dürfen. Datenelemente werden verwendet, um die Attribute der Informationsobjekte darzustellen, und können als die Grundbausteine zur Informationsdarstellung bezeichnet werden.

Zu jedem Datenelement ist dabei der Name, die Bedeutung, eine eindeutige Kennzeichnung (tag) und der Datentyp angegeben.

Beispielsweise gehören zur Informationsobjekt-Klasse "Computed Radiography Image IOD" unter anderem die Attribute "Pixel Data", " Patient's Name" und " Study Description", welche durch folgende Datenelemente dargestellt werden:

7. Teil: Nachrichtenaustausch

Der siebte Teil des DICOM-Standards spezifiziert Dienste und Protokolle, welche beim Austausch von Nachrichten zur Verfügung stehen. Es wird definiert, nach welchen Regeln ein Verbindungsaufbau und -abbau zu erfolgen hat und was beim Austausch von Befehlen zu beachten ist. Weiter wird festgelegt, wie Befehlsketten und Nachrichten - in Ergänzung zu Teil 5 - aufgebaut werden (vgl. dazu auch Abschnitt "Kommunikationsmodell und Konzepte").

Eine DICOM-Nachricht setzt sich immer aus Befehlssätzen und gegebenenfalls Datensätzen zusammen. Ein Befehlssatz enthält eine Menge von Befehlselementen, welche in diesem Teil des Standards genannt und den entsprechenden Diensten zugeordnet sind.

Abbildung 6 stellt den geschilderten Sachverhalt aus den Teilen 5 und 7 grafisch dar:

8. Teil:Netzwerkunterstützung

Hier wird definiert, auf welchen Diensten und Schichten aufgebaut wird, um in einem Netzwerk die DICOM-Nachrichten auszutauschen. Bei den genannten Diensten und Protokollen handelt es sich um generelle Kommunikationsstandards, und sie sind nicht auf DICOM spezialisiert (® OSI, TCP/IP).

9. Teil: Punkt-zu-Punkt Kommunikationsunterstützung für den Nachrichtenaustausch

In die gleiche Richtung wie der Teil "Netzwerkunterstützung" zielen die Ausführungen dieses Abschnitts. Es werden die Dienste und Protokolle erwähnt, welche für eine reibungslose Punkt-zu-Punkt Kommunikation notwendig sind.

10. Teil - 12. Teil

Jeder Teil wird zwar wieder als geschlossene Einheit vorgestellt, aber die Teile 10 bis 12 stehen in enger Beziehung zueinander und konzentrieren sich auf den Datenaustausch über "Offline-Medien". Es werden grundlegende Konzepte vorgestellt, geeignete Datenträger genannt, und festgelegt, welche Daten auf dem Datenträger vorhanden sein müssen.

13. Teil: Punkt-zu-Punkt Kommunikationsunterstützung fürs Drucken

Dieser Teil beschreibt Protokolle und Dienste, um die Kommunikation zwischen einem Print-Dienst-Anbieter und einem Print-Dienst-Nutzer zu ermöglichen.

Bemerkungen

Obwohl jeder Teil einen bestimmten Bereich beschreibt, stehen sie doch in enger Beziehung zueinander, und Änderungen in einem Teil haben Auswirkungen auf andere Teile zur Folge. Revisionen der einzelnen Teile werden auch von den Zusätzen erzwungen; zur Zeit befinden sich über 20 Supplements in unterschiedlichen Entwurfsphasen (vgl. [Merg97]).

Bei der Entwicklung des Standards arbeitet das Komitee mit anderen Normierungsgremien wie beispielsweise CEN/TC 251 (Europa), JIRA (Japan), IEEE und ANSI (Amerika) zusammen. Weiter sind Bestrebungen im Gange, um die "Interoperabilität" mit HL7 zu gewährleisten. Angesichts der Bedeutung und des Einsatzgebietes ist eine Annäherung dieser beiden Standards sehr zu begrüssen. Während DICOM auf dem Gebiet des "digitalen Bildaustausches" als führender Standard bezeichnet werden kann, deckt HL7 vor allem die Bereiche für den Austausch von "Text-Daten" ab.

In Schweizer Spitälern wird DICOM heute vereinzelt eingesetzt. Beispielsweise wurde an der XII. Jahrestagung der SGMI/SSIM berichtet, dass im Universitätsspital Zürich "1996 an sämtlichen Geräten der Nuklearmedizin sowie an allen CT- und MR-Geräten am Departement Medizinische Radiologie die DICOM-Protokolle aktiviert wurden" ([Voel97]) und dass im Inselspital Bern ein Pilotprojekt gestartet wurde, in dem DICOM und HL7 verwendet werden ([ToMä97]).

In Bezug auf Sicherheitsaspekte macht DICOM wenig Angaben. Lediglich im Teil "Media Storage and File Format" wird darauf hingewiesen, dass in künftigen Versionen diesen Aspekten Rechnung getragen werden sollte. Das bedeutet für den Anwender, dass für einen sicheren Datenaustausch auf andere Möglichkeiten zurückgegriffen werden muss.

Quellen

Angaben zum Standard wurden mehrheitlich aus den Homepages von ACR und NEMA entnommen (www.xray.hmc.psu.edu; www.nema.org). Entwürfe können via FTP kostenlos bezogen werden, und es stehen unter den genannten Seiten weitere Informationen rund um den Standard zu Verfügung. An der XII. Jahrestagung der SGMI/SSIM 1997 informierten verschiedene Vertreter über Erfahrungen und Meinungen zu DICOM ([ToMä97], [Voel97], [Offe97]).

3.1.3 UN/EDIFACT

Überblick

UN/EDIFACT steht für "United Nations/EDI for Administration, Commerce, and Transport". Neben der offiziellen Bezeichnung wird oft auch einfach das Kurzwort "EDIFACT" verwendet. Bei EDIFACT handelt es sich um einen Standard, welcher die Struktur der elektronisch auszutauschenden Daten (® EDI) definiert, so dass der Empfänger die Nachricht lesen, verstehen und weiterverarbeiten kann. Im Gegensatz zu den anderen, in diesem Kapitel vorgestellten Standards ist EDIFACT nicht speziell auf das Gesundheitswesen ausgerichtet, sondern unterstützt Nachrichtentypen für verschiedene Branchen.

Der Standard wird unter der Leitung der "Working Party 4 (WP.4)" der UN/ECE (United Nations / Economic Commission for Europe) entwickelt. Mitglieder der WP.4 sind vorwiegend Vertreter aus Ländern und internationalen Organisationen. Der WP.4 sind zwei Expertengruppen unterstellt, welche sich mit der Standardisierung der Syntax und den Nachrichtentypen befassen. Daneben existieren fünf Ministerien ("Boards"), um die Entwicklung des Standards in den verschiedenen Regionen zu koordinieren und zu fördern.

In folgenden Regionen wird EDIFACT durch Ministerien vertreten: Australien/Neuseeland, Osteuropa, Japan/Singapur, Nordamerika und Westeuropa (WEEB).

1986 begann die WP.4 aufgrund von fehlenden internationalen Standards mit der Entwicklung von EDIFACT. Ein Jahr später wurde der erste Nachrichtentyp verabschiedet, und seither kommen jedes Jahr neue Nachrichtentypen (und Komponenten) dazu. EDIFACT wird in vielen Ländern auf der Welt eingesetzt, und es wird erwartet, dass er zum führenden, internationalen Standard für EDI wird (vgl. [Emme93], [Medi96a]).

Nachrichtenstruktur

(vgl. [Emme93])

Datentypen, Datenelement und Datenelementgruppe

Die kleinsten Einheiten, um Informationen darzustellen, sind die Datenelemente. Jedes Datenelement wird durch einen eindeutigen, 4-stelligen Code identifiziert, trägt einen Namen und verwendet einen bestimmten Datentyp. Es stehen die Datentypen "numerisch", "alphabetisch", "alphanumerisch" und "ID" zur Verfügung, und die Länge des Datenfelds wird festgelegt. Bei der Verwendung des Datentyps "ID" werden die Informationen durch codierte ("abgekürzte") Daten dargestellt, so dass für eine korrekte Interpretation eine entsprechende Codeliste benötigt wird.

Datenelemente sind bei einem sachlichen und logischen Zusammenhang zu einer Datenelementgruppe zusammengefasst, welche ihrerseits wiederum eindeutig gekennzeichnet ist. Bei jeder Gruppe ist festgelegt, ob die betreffenden Datenelemente darin vorkommen müssen oder ob sie optional verwendet werden können.

Beispiel: Das Datenelement "Line Item Number" und die Datenelementgruppe "Product Identification" gehören zum EDIFACT-Standard. Der Wert in "Line Item Number" ist numerisch, maximal sechs Stellen lang, hat das Minimum bei "1" und das Maximum bei "3". Die Datenelementgruppe "Product Identification" besteht aus den Datenelementen "Article number" und "Article number ID", wobei beide Elemente einen Wert enthalten müssen.

Segmente

Jedes Segment wird durch einen alphabetischen, 3-stelligen Code identifiziert, und setzt eine Reihe von Datenelementen und/oder Datenelementgruppen zu einer logischen Einheit zusammen. EDIFACT stellt eine Menge solcher Segmente zur Verfügung, wobei zu jedem Segment definiert ist, welche Datenelemente (und Datenelementgruppen) in welcher Reihenfolge vorkommen können oder müssen.

Beispiel: Folgende Definition und somit folgender Aufbau für das Segment "Line Item" gilt:

Segmentgruppe

Segmente, welche in logischem Zusammenhang stehen, können ihrerseits zu Segmentgruppen zusammengefasst werden. Die Gruppen werden durch eine Nummer identifiziert, und es kann angegeben werden, wie oft die darin enthaltenen Segmente sich jeweils wiederholen dürfen. Neben Segmenten können auch Segmentgruppen selbst in einer anderen Segmentgruppe verwendet werden.

Nachricht

Nachrichten enthalten alle Daten, welche zu einer bestimmten Transaktion zwischen den involvierten Parteien benötigt werden. Nachrichten sind eine geschlossene, logische Einheit und können mit traditionellen Dokumenten, welche zwischen den Geschäftspartnern ausgetauscht werden, verglichen werden.

Eine Nachricht setzt sich aus einer Menge von Segmenten und -gruppen zusammen. Zu jedem Nachrichtentyp ist festgelegt, welche Segmente und Segmentgruppen in welcher Reihenfolge verwendet werden dürfen. Dabei wird zu jedem Segment beschrieben, ob dieses zwingend oder optional ist und wie viele Male es sich wiederholen kann.

Jede Nachricht beginnt mit dem Segment "UNH", dem Nachrichtenkopf, worin unter anderem der Nachrichtentyp angegeben wird. Das Segment "UNT" steht jeweils an letzter Stelle einer Nachricht und enthält Prüfinformationen.

Beispiel: Mit dem Nachrichtentyp "ORDERS" können Bestellungen beim Lieferanten gemacht werden. Der EDIFACT-Standard definiert den Aufbau dieses Nachrichtentyps wie folgt:

Nachrichtengruppe und Übertragungsdatei

Nachrichten vom gleichen Typ können zu einer Nachrichtengruppe zusammengefasst werden. Gekennzeichnet wird diese Bündelung durch die Segmente UNG und UNE. Eine Übertragungsdatei ergibt sich schliesslich durch das Zusammenfassen der Nachrichtengruppen (® UNB, UNZ).

Um Komponenten einer Übertragungsdatei voneinander zu trennen, werden sogenannte Delimiter verwendet. Im ersten Segment (UNA) einer Übertragungsdatei kann festgelegt werden, welche Delimiter eingesetzt werden. Normalerweise werden Datenelemente durch den Delimiter "+" getrennt, zur Unterscheidung von Datenelementgruppen wird das Zeichen ":" verwendet, und zur Kennzeichnung eines Segmentendes dient ein Apostroph (').

Beispiel

Die obigen Ausführungen erklären, welche Komponenten bei EDIFACT zur Verfügung stehen und wie daraus eine Übertragungsdatei aufgebaut werden kann. Im Folgenden wird gezeigt, wie eine konkrete Datei aussehen könnte, um eine Kaufbestellung zu übermitteln. Dabei wird auf den Nachrichtentyp "ORDERS" und einige Segmenttypen zurückgegriffen, welche nicht genauer erklärt wurden. Wie diese Komponenten im Detail aufgebaut werden müssen, interessiert in diesem Zusammenhang nicht; das Beispiel soll lediglich einen groben Eindruck vermitteln und den allgemeinen Aufbau der Datei veranschaulichen.

Ausgangslage: Peter Sender von der Firma "KaufAG" (Code: 98765) bestellt bei "Hans Empfaenger" (Firma "VerkaufAG") den Artikel mit der ID 6666. Dieser Artikel wird beim Verkäufer unter der Nummer 555 geführt.

Möglicher Inhalt einer EDIFACT-Übertragungsdatei:

Ausgewählte Nachrichtentypen

Der EDIFACT-Standard stellt zur Zeit über140 Nachrichtentypen zur Verfügung, welche in verschiedenen Bereichen und Branchen eingesetzt werden. Neue Nachrichtentypen sind zudem in Entwicklung und müssen etliche Stufen und Prozeduren durchlaufen, bis sie von der UN veröffentlicht werden.

Einige Nachrichtentypen sind speziell auf einen bestimmten Bereich/Branche zugeschnitten, während andere, wie beispielsweise Bestellungen (ORDERS) und Rechnungen (INVOIC), allgemein verwendet werden können.

Im Folgenden werden Nachrichtentypen vorgestellt, welche speziell auf das Gesundheitswesen zugeschnitten sind. Neben den bereits veröffentlichten Nachrichtentypen werden zudem Typen beschrieben, welche sich zur Zeit bei der EBES/EEG09 (vgl. Kapitel "Diverse ausländische oder internationale Institutionen und Standards") in Entwicklung befinden.

(vgl. [EBES97c])

(Die Namen der Nachrichtentypen sind vom Autor aus dem Englischen übersetzt worden und entsprechen nicht dem offiziellen Wortlaut).

Bemerkungen

Der EDIFACT-Standard definiert den Aufbau und die Struktur der zu übermittelnden Daten. Es wird davon ausgegangen, dass die Übertragungsdateien korrekt übermittelt werden und entsprechende Dienste zur Verfügung gestellt werden, so dass diese Protokolle nicht spezifiziert werden müssen. Beim Austausch von EDIFACT-Nachrichten ist normalerweise keine Bestätigung nötig. Einige Nachrichtentypen verlangen jedoch ausdrücklich eine Antwort, und aus Kontroll- und Sicherheitsgründen wünscht mancher Teilnehmer eine Bestätigung auf seine Nachrichten. Für solche Fälle stehen entsprechende Nachrichtentypen und Richtlinien (von der ECE) zur Verfügung; bei einer Implementierung müssen deshalb zwischen den beteiligten Parteien solche Fragen ebenfalls geklärt werden (vgl. [Medi96a]).

Im Gesundheitswesen der Schweiz wird für den elektronischen Datenaustausch immer häufiger EDIFACT eingesetzt. Der MediData-Standard für den Austausch von Kostengutsprachen, Rechnungen und Laboraufträgen basiert auf EDIFACT. Bei der Bestellung von Arzneimitteln und bei der Rechnungsstellung der Apotheken an die Krankenkasse über Abrechnungsstellen wird der Standard ebenfalls verwendet (ab einer gewissen Grösse der betreffenden Institutionen).

Je nach Zweck und Einsatzgebiet von EDIFACT-Nachrichten müssen Sicherheitsaspekte berücksichtigt werden. Die involvierten Parteien können sich dabei auf kryptographische Techniken einigen. [SJWG97] zeigt auf, was für Möglichkeiten bezüglich Sicherheit bei EDIFACT verwendet werden können. Wie Sicherheit von EDIFACT-Nachrichten implementiert werden kann, zeigt beispielsweise auch das Tool "EDIMED". Es verschlüsselt Meldungen mit dem DES-Algorithmus (in Kombination mit weiteren Sicherheitsmassnahmen) und verschickt sie per E-Mail (X.400). Einsatzgebiet ist primär das Gesundheitswesen, weshalb auch HL7 Nachrichten von EDIMED unterstützt werden (vgl. [Olne93]).

Quellen

Die Angaben stammen mehrheitlich aus [Emme93], "EDI - a total management guide". Die Beispiele wurden ebenfalls in Anlehnung an dieses Buch gemacht. Die ausgewählten Nachrichtentypen wurden aus [EBES97c] entnommen; diese Webseite informiert über den Stand der Entwicklung der Nachrichtentypen im Gesundheitswesen. [Medi96a] gibt dem Leser einen kurzen Einblick in den EDIFACT-Standard und beschreibt anhand der MediData-Nachrichtentypen, was es bei einer Implementierung zusätzlich zu beachten gilt (Standardablauf, Fehler,...). [Olne93] zeigt anhand von EDIMED eine Möglichkeit, wie Sicherheit bei EDIFACT-Nachrichten implementiert werden kann.