Generic Coding mittels XML in der medizinischen Dokumentation

S.P.Endres

Abstract: Generic Coding by XML in Medical Documentation:

Generic Coding is a description of textual documents regardless of their explicit representation, e.g. on paper or computerscreen. The usage of this form causes advantage of processing of documents: Access, storage, retriev and reuse can be enhanced, because the semantic structure of the document is preserved. Generic Coding is usually realized by Markup Languages like SGML or the Extensible Markup Language (XML).

A special generic coding Markup Language for clinical purposes, called Munich Medical Report (MucMedRep), has been developed. The basic criteria for its definition are the following rules:

1. The description is formal, its correctness can be checked by a simple and deterministic algorithm. 2. The description is structured, references are maintained. 3. The description is independent of the choose of media, it is independent of the selected presentation form 4. The description is independent of the choice of transmission protocol. 5. The description is independent of the choice of a special product. 6. The description allows an exchange of data beyond the the boundaries of an institution. 7. The description can be used with a lot of different document types.

The description has been formulated in XML. Equivalant formulations are given in CORBA/IDL and in a relational data model. Its relations to international standards are shown. Concept and design of a system using the MucMedRep are presented.

1. Einleitung

	Real software engineers work from 9 to 5, because that is the way the job is described in the formal spec. Working late would feel like using an undocumented external procedure.

1.1 Generic Coding

Der Begriff Generic Coding steht für die Beschreibung von Dokumenten in einer Form, die sich auf den Inhalt beschränkt und die gestalterische Darstellung offen lässt. Das Wort Generic betont dabei, dass überflüssige Informationen, die normalerweise in Dokumenten enthalten sind, weggelassen werden. Überflüssig sind dabei die Bestandteile, die einen Autor bei der Erstellung eines Dokuments nicht beschäftigen. Diesen interessiert gewöhnlich das Layout des Endprodukts nicht, oft hat er nicht einmal Einflussmöglichkeiten darauf, oder es handelt sich um ein Dokument einer bestimmten Art, dessen Layout einmalig festgelegt wird.
Diese Trennung von Semantik und Layout bietet eine Reihe von Vorteilen: Das Ausgabeformat muss zum Zeitpunkt der Erstellung noch nicht vorliegen, und Informationen können aus dem Dokument wiedergewonnen werden, weil sie nicht in Redundanz und Layout versteckt sind. Der Anwender wird vom Layout entbunden, das ihn bei einem Routinedokument nicht interessiert und oft auch überfordert.
Der Dokumenteninhalt erhält losgelöst von seiner Darstellungsform eine eigene Existenz. Diese Information kann in einer ihr entsprechenden (ihrer generischen) Form bearbeitet, verteilt und gespeichert werden. Erst wenn ein Mensch auf diese Information zugreift, wird sie in adäquater Form visualisiert. Die adäquate Form hängt dabei von der Situation, der Person und dem Darstellungskanal (z.B. Papier, Monitor, Sprachübermittlung) ab.

1.2 Geschichte

Der Begriff Generic Coding wird im Verlagswesen seit vielen Jahrzehnten verwendet. Er geht wohl auf William Tunnicliffe zurück, der 1967 bei einer Tagung der Graphic Communications Association einen Vortrag über die Trennung von Dokumenteninhalt und -format hielt.
Im Verlagswesen bestehen seit jeher arbeitsteilige Strukturen zur Erzeugung von Dokumenten, z.B. Zeitschriften und Bücher. Autor, Redaktion, Layout und Druckerei bearbeiten jeweils unterschiedliche Aspekte eines Dokuments und bedienen sich dabei diverser Sprachen. So gibt es eine eigene Sprache mit eigenen Symbolen, in der Korrekturen [DUDEN] an einem Text formuliert werden. Diese sind auch in der DIN 5008 aufgeführt. In der DDR gab es bis 1990 einen abweichenden, aber den gleichen Bereich überdeckenden Standard, die TGL 0-16511. Ebenso gab es Beschreibungssprachen, sogenannte redaktionelle Markierungen, die die formale Stellung von gewissen Textteilen beschreiben, wie z.B. Titel, Autor oder Überschriften, um dem Setzer die Zusatzinformation zu liefern, die in einen entsprechenden Schriftsatz umgesetzt werden muss. Diese Beschreibung wird in der amerikanischen Verlagstradition "mark-up" genannt. Mit zunehmender Einführung von elektronischen Hilfsmitteln in Druck und Layout sind solche Markups inzwischen vereinheitlicht. 1989 wurde die Standard Generalized Markup Language (SGML) als ISO-Norm 8879 [ISO8879] für diese Zwecke verabschiedet.
Die Geschichte von SGML geht in die späten sechziger Jahre zurück. Charles F. Goldfarb leitete damals als Jurist bei IBM ein Forschungsprojekt, das sich mit einem Informationssystem über Behörden- und juristische Dokumente beschäftigte. Goldfarb war mit den Möglichkeiten der damaligen Textverarbeitung unzufrieden. Diese sahen so aus, dass der Autor den Text mit Befehlen zur Druckgestaltung durchmischte. Dies ist genau das, was heutige Textverarbeitungssysteme dem Autor anbieten. Der Unterschied ist nur, dass heutzutage die Druckkommandos mit moderneren Eingabetechniken (z.B. Maus) in den Text eingefügt werden und man ihre Auswirkung sofort am Bildschirm beobachten kann. Das bedeutet, dass der heutige Anwender zwar das Ergebnis seiner Kommandos schneller sieht, er aber ansonsten mit den gleichen Mitteln arbeitet, die Goldfarb vor 30 Jahren zu einem entscheidenden Schritt veranlassten. Er wünschte zwar hohe Qualität seiner Druckwerke, wollte aber als Autor nicht die visuelle Form selbst gestalten müssen. Andererseits wollte er nicht auf die Möglichkeiten der elektronischen Textverarbeitung verzichten. So begann er Druckbefehle zu Makros zusammenzufassen, die logische Textabschnitte kennzeichneten. Damit konnten Texte mitsamt ihrer Textlogik (Überschriften, Aufzählungen, Fußnoten) erstellt werden, ohne Bezug auf ihre typographische Realisierung nehmen zu müssen. Daraus entstand in Zusammenarbeit mit E.J.Mosher , R.Lorie und T.Peterson die Generalized Markup Language [GML] (GML). Solche Ansätze werden auch von den meisten heutigen Textverarbeitungssystemen mit sogenannten Formatvorlagen unterstützt.
Es zeigte sich ein weitergehender Vorteil einer solchen Dokumentenbeschreibung. Da der Text frei von typographischen Teilen ist, muss zum Zeitpunkt der Dokumentenerstellung noch gar nichts über die Form bekannt sein, in der sich das Dokument präsentieren soll. Es kann auch ein und dasselbe Dokument in verschiedenen Formen dargestellt werden, z.B. einmal als eigenständige Broschüre und einmal in einer Sammlung in Buchform, jedes Mal mit einem eigenständigen Layout. Auch neuere Präsentationsformen wie z.B. Online-Darstellungen im Internet mit eigenen Layoutkriterien sind möglich. So erstellte Dokumente sind besser wiederverwendbar, weil sich logische Teile darin auch automatisch identifizieren lassen.
Allgemein lässt sich sagen, dass mit der Ausgestaltung von Layout und Typographie eines Dokuments eine Umsetzung von logischer Struktur in visuelle Struktur geschieht. Dieser Schritt ist aber unumkehrbar, da nicht eindeutig. Die generische (logisch strukturierte) besitzt somit gegenüber herkömmlichen (visuell strukturierten) Beschreibungen von Dokumenten die größere Allgemeinheit. Dies gilt zumindest für Dokumente, deren Inhalt übertragen werden soll. In Fällen, in denen das Layout einen eigenständigen Informationsgehalt darstellt, gilt das nicht mehr. Typisches Beispiel wären hierfür Werbebroschüren, deren visuelle Wirkung unter Umständen den inhaltlichen Teil in den Hintergrund treten lässt. Im Kontext dieser Arbeit werden Dokumente betrachtet, auf die derartiges nicht zutrifft. Ein korrektes, ansprechendes Layout wird zwar gefordert, aber nicht individuell für das einzelne Dokument. Das Layout wird einmalig für eine Dokumentenklasse und ein bestimmtes Ausgabeformat festgelegt und ist dann nicht mehr Bestandteil des einzelnen Dokuments.
Die größere Allgemeinheit der generischen Kodierung spiegelt sich auch in der Tatsache wider, dass sich die gesamte Kommunikation auf eine Datenrepräsentation beschränken kann. Es entfällt Umsetzarbeit beim Wechsel zwischen den einzelnen Medien (Sprache->Diktiergerät->Schreibkraft [ Diese Arbeit beschäftigt sich erst ab diesem Schritt mit der Dokumentenbeschreibung. Spracherkennung und mündliche Informationsverteilung werden nicht weiter untersucht. ] ->Textverarbeitung->Drucker->Postversand), die fehlerträchtig ist. Falls als letzter Schritt eine elektronische Archivierung erfolgen soll und das Ausgedruckte mittels Scanner und OCR wieder in eine unstrukturierte, aber computerlesbare Form gebracht werden muss, wird das enorme Potential dieser Art von Informationsrepräsentation deutlich. Information kann ohne Medienbruch verteilt und archiviert werden.
In der Folgezeit wurde GML zu SGML [SGML] weiterentwickelt. SGML ist eine Metasprache, die es erlaubt, Markup-Sprachen für beliebige Anwendungen zu definieren. Die Association of American Publishers brachte 1987 eine Reihe von solchen Dokumentarten heraus, so Markup-Sprachen für Bücher (BK-1), Artikel (ART-1) und weitere [EMP] . 1989 fand SGML seine Definition als ISO-Norm.
Während SGML heute im Verlagswesen eine erhebliche Bedeutung hat, konnte es im Bereich der Alltagsdokumente wie z.B. Brief, Aktennotiz, Vertrag nicht Fuß fassen. Eine der möglichen Ursachen dafür ist die nicht unerhebliche Komplexität von SGML, die erhebliches Vorwissen benötigt, wenn man eine Markup-Sprache für einen speziellen Bereich formulieren möchte. So entstand Ende der achtziger Jahre die heute wohl am weitesten verbreitete Markup-Sprache HTML zunächst aus einer eigenständigen Entwicklung. Mit ihr werden heute nahezu alle Dokumente im Internet formuliert. Erst im Nachhinein wurde sie in SGML definiert. Mitte der neunziger Jahre begann sich abzuzeichnen, dass HTML den kommenden Anforderungen im Internet nicht mehr gewachsen sein wird. Man begann mit der Entwicklung der Extensible Markup Language (XML). XML ist eine vollständige Untermenge von SGML, ist aber durch den Verzicht auf selten verwendete SGML-Elemente wesentlich einfacher in der Handhabung. XML wird in Abschnitt ausführlicher behandelt.
Ein anderer wichtiger Zweig der Geschichte von Generic Coding ist mit dem Namen von Donald E. Knuth verbunden. SGML richtet sich hauptsächlich auf die Beschreibung des Dokuments, die Erzeugung eines korrekten Layouts für das Dokument wird nicht weiter betrachtet. Es genügt zu zeigen, dass ein solches Dokument erzeugt werden kann. Knuth leistete mit seinem Textsatzsystem TeX (ausgesprochen Tech) genau diesen konkreten Schritt. Als er 1977 die Druckfahne eines digital gesetzten Buchs sah, fiel ihm auf, wie wenig es nach "echtem" Buchsatz aussah:
Mir wurde klar, dass ein zentraler Aspekt des Druckens auf Bitmanipulationen reduziert worden war. Als Informatiker konnte ich nicht der Versuchung widerstehen, diese Bits besser zu handhaben. [KNUTHLIT]
Dies führte zur Entwicklung des Programms TeX, einem Satzsystem, das "alle (typographischen) Erkenntnisse kodifizieren sollte, die man seit Gutenberg zu diesem Thema gewonnen hat". TeX kennt dabei ca. 300 verschiedene Anweisungen, die in den eigentlichen Text eingestreut werden. Mit diesen Anweisungen werden die Darstellung der einzelnen Textteile und die Seitengestaltung gesteuert. Da TeX es erstmals einem Durchschnittsanwender ohne spezielle Vorkenntnisse ermöglichte, typographisch korrekte Textdokumente zu erzeugen, verbreitete es sich sehr rasch, besonders im technisch-wissenschaftlichen Bereich. TeX bietet aber auch die Möglichkeit, Makros zu definieren und damit die layoutbezogenen Anweisungen zu logischen Kommandos zusammenzufassen. Dies führte Anfang der achtziger Jahre zu dem Makropaket LaTeX von Leslie Lamport . LaTeX bietet einen Satz Makros, die die logische Struktur eines Dokuments beschreiben und erzeugt daraus druckfähige Dokumente. Die Beschreibung eines Dokuments in LaTeX entspricht weitgehend der Sichtweise des Generic Coding . Die einzige Einschränkung ist noch die Möglichkeit, auf geometrische Parameter wie z.B. Seitengröße Einfluss zu nehmen, ansonsten wird das Dokument in seiner logischen Struktur beschrieben. Mit der Erweiterung von TeX nach LaTeX wurde auch in diesem eigenständigen Entwicklungszweig der Schritt vom visuellen Markup zum logischen Markup vollzogen.
Eine gewisse Zusammenführung der beiden Entwicklungen findet sich darin, dass heute viele SGML-Systeme zum Erzeugen von druckfähigem Layout als Zwischenschritt TeX-Kode generieren und dann die korrekte typographische Aufbereitung dem Knuthschen System überlassen.
Parallel zu der Entwicklung von SGML wurde seit 1982 im europäischen Raum die Office Document Architecture (ODA) entwickelt, die 1989 ISO-Norm [ISO8613] wurde. Obwohl ODA nie eine weitere Verbreitung gefunden hat, ist es in mehrerer Hinsicht interessant im Vergleich zu SGML. Es setzt auf den gleichen Konzepten wie SGML auf, bietet jedoch einen expliziten objektorientierten Ansatz, der sich bei SGML nur indirekt ergibt. SGML ist eine allgemeine Meta-Markup-Sprache, ODA eine objektorientierte Sprache zum Beschreiben von Dokumenten. ODA unterscheidet explizit logische Struktur und Layoutstruktur. SGML ermöglicht jede Form von Markup, auch visuelles. ODA beschränkt sich nicht nur auf die Dokumentenbeschreibung, sondern auch auf den Dokumentenaustausch mit dem Office Document Interchange Format (ODIF). Zusätzlich beschreibt es auch ein Processing Model , das den Prozess der Dokumentenerzeugung und -verarbeitung beschreibt. Insgesamt nimmt sich ODA wesentlich detaillierter der Dokumentenbearbeitung an. So bezieht sich ODA explizit auf logische Objekte wie z.B. Kapitel, Absatz, Abbildung. SGML stellt dagegen nur die Werkzeuge, um solche logischen Objekte zu definieren. Aber diese umfassende Beschreibung und Einbeziehung von ISO-Normen könnte auch der Grund sein, warum sich ODA nie durchsetzen konnte, da es die Entwicklung von Systemen zu sehr einschränkte.

1.3 Elektronische Kommunikation

Der Ansatz, der dem Generic Coding zugrunde liegt, findet bei näherer Betrachtung seine Entsprechung in der Art, auf welcher in der Informatik jeder Datenaustausch beschrieben wird. Es wird zunächst die Menge der möglichen Daten betrachtet und diese in eine strukturierte Form gebracht. Der Grad der Strukturierung ist dabei abhängig vom Anwendungsbereich. Es wird versucht, sie auch für zukünftige Erweiterungen und Verfeinerungen offen zu halten. Ist die Struktur einmal festgelegt, wird sie formal beschrieben und eine Kodierung definiert, wie so strukturierte Daten zu repräsentieren sind. Dann werden das Protokoll und das Medium festgelegt, mit dem die kodierten Daten transportiert werden. Will man elektronische Kommunikation beschreiben, kommt man damit auf folgende drei Punkte:

Formale Datenstruktur
Datenrepräsentation
Transportprotokoll

Dies soll kurz an einem Beispiel verdeutlicht werden. DICOM ist ein im radiologischen Bereich weit verbreiteter Standard zum Austausch von Untersuchungsdaten. DICOM-Daten werden aus Elementen zusammengesetzt. Jedes Element wird durch eine Gruppennummer, eine Unternummer und seinen Datentyp beschrieben. Die Interpretation des Werts eines jeden Elements ist festgelegt. So hat das Element aus der Gruppe 16 (Patientendaten) mit der Unternummer 16 den Datentyp "Zeichenkette" und die Bedeutung "Name des Patienten" . Weitere Elemente sind z.B.:

Gruppe 8, Nummer 48, Typ Datum, Bedeutung "Untersuchungsdatum"
Gruppe 16, Nummer 48, Typ Datum, Bedeutung "Geburtsdatum des Patienten"
Gruppe 24, Nummer 4161, Typ Zahl, Bedeutung "Volumen des Kontrastmittelbolus"

Mit diesen Elementen, von denen es weit über 1000 gibt, werden Objekte definiert. Objekte können dabei z.B. sein: konventionelles Röntgenbild, eine CT-Serie, Nachricht über eine Änderung einer Untersuchung, Suchanfrage nach anderen Objekten. Dabei wird immer festgelegt, welche Elemente ein bestimmtes Objekt enthalten muss und welche es zusätzlich enthalten darf. Dieser Teil des Standards beschreibt die formale Datenstruktur . In einem weiteren Teil wird die Datenrepräsentation festgelegt. Dort wird definiert wie und wo die Gruppen- und Elementnummern gespeichert werden, mit welchem Zeichensatz die Zeichenketten abgespeichert werden usw.. Als weiterer Teil wird dann noch das Transportprotokoll definiert, wobei für die unteren Protokollschichten bestehende Standards erlaubt werden, so z.B. TCP/IP als Netzwerkprotokoll. Für die höheren Schichten wird ein eigenes Protokoll definiert.
Diese Beschreibung elektronischer Kommunikation wurde hier dargestellt, um den Unterschied zu zeigen, mit dem heute vielerorts Dokumente elektronisch erzeugt und ausgetauscht werden. In der obigen Beschreibung wurde an keiner Stelle eine Applikation, d.h. ein konkretes Programm erwähnt. Dies ist auch sinnvoll, da die Struktur der Daten immer die gleiche ist, die Anforderungen an eine Anwendung aber nahezu beliebig sein können. Um beim Beispiel DICOM zu bleiben, können dies Programme zur Darstellung von Bildern für Befundungszwecke sein, die multiple Möglichkeiten zur Bildnachbearbeitung bieten, komplexe Abfragewerkzeuge für statistische Zwecke oder einfache Programme zur Erfassung von Patientendaten an der Konsole von radiologischen Geräten.
Im Bereich der medizinischen Dokumente sieht die Welt genau umgekehrt aus. Das typische Szenario stellt sich so dar: Das Einzige was festgelegt ist, ist eine Applikation, üblicherweise ein Textverarbeitungsprogramm aus den verbreiteten Office-Paketen, z.B. Microsoft-Word in einer bestimmten Version. Diese Programme sind heute angesiedelt zwischen klassischen Textverarbeitungsprogrammen und Desktop Publishing (DTP). DTP steht dabei für eine Programmart, die dem Anwender erlaubt, am Computer das Layout von Druckseiten zu gestalten. An Funktionalitäten einer Textverarbeitung, die in diesem Zusammenhang erwähnenswert sind, gibt es das Erstellen von Inhaltsverzeichnissen, Referenzen innerhalb eines Dokuments, Fußnoten- und Abbildungsverwaltung. Das führt zu folgendem:

Datenmodell und -repräsentation sind undefiniert, häufig nur teilweise dokumentiert. Sie unterscheiden sich selbst bei funktionell nahezu gleichen Programmen vollständig und differieren auch bei Programmen eines Herstellers zwischen den Versionen erheblich.
Es wird das falsche Datenmodell verwendet. Eine Struktur zur Modellierung von Seitenlayout entspricht nicht der Struktur eines medizinischen Dokuments.

Während der erste Punkt durch die Verwendung des Datenformats Rich-Text , als kleinster gemeinsamer Nenner zwischen den Textverarbeitungsprogrammen, etwas entschärft wird, ist der zweite Punkt ein prinzipieller, da in der Konzeption der Textverarbeitungsprogramme verankert. Dies führt zu dem typischen Szenario, dass der Einsatz der elektronischen Datenverarbeitung am Arbeitsplatz der Schreibkraft anfängt und aufhört. Diese schreibt den Text in ihr Textverarbeitungsprogramm und druckt ihn aus. Der Computer wird zur Schreibmaschine mit erweiterter Korrekturfunktion degradiert. Welche Möglichkeiten über diese hinaus ein adäquates Design bietet, soll Thema dieser Arbeit sein.

1.4 Zielsetzung

Das Ziel dieser Arbeit ist, eine Dokumentenbeschreibung zu finden, die folgenden Forderungen genügt:

Die Beschreibung ist formal. Die Korrektheit eines Dokuments lässt sich maschinell überprüfen.
Die Beschreibung ist strukturiert. Referenzen auf andere Objekte (Patient, Bild, Adresse) bleiben erhalten. Damit ist eine Integration in ein unternehmensweites Gesamtkonzept möglich.
Die Beschreibung ist medienneutral. Sie ist unabhängig von der gewählten Präsentationsform.
Die Beschreibung ist protokollneutral. Sie ist unabhängig von konkreten Protokollen.
Die Beschreibung ist produktneutral. Sie ist unabhängig von konkreten Softwareprodukten.
Die Beschreibung ist interinstitutionell. Sie erlaubt einen sinnvollen Austausch über Institutsgrenzen hinweg. So muss z.B. die Angabe einer korrekten postalischen Adresse möglich sein.
Die Beschreibung einer großen Anzahl unterschiedlicher Dokumentarten ist möglich.

Die ersten fünf Punkte ermöglichen die Integration eines auf dieser Dokumentenbeschreibung basierenden Systems in ein unternehmensweites Gesamtkonzept. Die letzten beiden Punkte sollen ein ausreichend großes Anwendungsgebiet sicherstellen.
Bevor diese Beschreibung aufgestellt wird, werden bestehende Konzepte und Standards dargestellt. Dann folgt die Formulierung eines Datenmodells. Dafür wird XML verwendet. Als Bezeichnung für diese Beschreibung wird der Name MucMedRep gewählt, eine Abkürzung für Munich Medical Report . Danach wird das Dokumentenmodell in unterschiedlichen Beschreibungen formuliert. Es werden Formulierungen als Markup-Sprache, in einer objektorientierten Sprache und in einem relationalen Datenmodell vorgestellt. Die Gleichwertigkeit dieser Beschreibungen wird gezeigt. Der Bezug, Übereinstimmungen und Differenzen zu bestehenden Standards werden untersucht.
Auf Basis dieses Datenmodells wird das Design eines Dokumentenverwaltungssystems formuliert. Teile davon sind real implementiert und produktiv im Einsatz. Andere Teile sind derzeit nur exemplarisch realisiert.
Die Vorteile des hier beschriebenen Vorgehens gegenüber kommerziellen Produkten und insbesondere üblichen Textverarbeitungslösungen werden aufgezeigt.

2. Grundlagen: Zeichensätze und Kodierungen

	I have made this letter longer than usual because I lack the time to make it shorter.
	Blaise Pascal

Die verwendeten Zeichensätze sind die Basis jeglicher textuellen Darstellung. Deshalb sollen die wichtigsten hier kurz beschrieben werden. Alle konkreten Anwendungen dieser Arbeit beschränken sich auf die Verwendung des Zeichensatzes ISO-8859-1 [ISO8859] (Synonym: Latin-1), der die benötigten Zeichen der meisten westeuropäischen Schriften zur Verfügung stellt. Die hier gemachten Überlegungen gelten jedoch auch für alle anderen aufgeführten Zeichensätze, insbesondere Unicode, womit sich nahezu jede beliebige Schrift auf der Welt beschreiben lässt.

2.1 American Standard Code for Information Interchange

ASCII [ASCII] ist der am längsten verwendete Zeichensatz in der Computertechnik. Er verwendet 7 Bits eines Bytes zur Beschreibung von Zeichen. Er wurde aus pragmatischen Gründen ohne theoretischen Unterbau definiert und enthält deshalb eine Vermischung von Zeichenkode und Protokollfunktionen. Letztere werden häufig nicht darstellbare Zeichen genannt und enthalten z.B. Steuerzeichen für die serielle Kommunikation mit Terminals. Für Textverarbeitung ist er heute nicht mehr verwendbar, da er für Schriftsysteme außerhalb der USA keine Unterstützung bietet. Aber praktisch alle heute gültigen Zeichensätze enthalten 7-Bit ASCII als Untermenge in einem fortlaufenden Kodebereich.

2.2 Extended Binary Coded Decimal Information Code

Extended Binary Coded Decimal Information Code (EBCDIC) ist historisch der einzige Zeichensatz, der unabhängig von ASCII eine gewisse Bedeutung gehabt hat. Heute spielt er nur noch auf einigen Großrechnern der Firma IBM eine Rolle und ist ansonsten aus der Informatiklandschaft verschwunden.

2.3 ISO 8859

Die ISO 8859 wurden Mitte der 80er Jahre von der European Computer Manufacturer's Association (ECMA) entworfen. Sie enthält eine Gruppe an Zeichensätzen, deren erste 128 Zeichen dem 7-Bit US-ASCII Zeichensatz entsprechen. Durch Verwendung des 8. Bits können weitere 128-Zeichen kodiert werden. Die restlichen Zeichen sind an regionale Gegebenheiten angepasst. Es werden unter anderem nationale Besonderheiten wie z.B. die deutschen Umlaute, Zeichen mit unterschiedlichen Akzenten (à, ã, â) und einige mathematische Sonderzeichen abgebildet. Es gibt für den westeuropäischen Schriftraum die ISO-8859-1 (Latin-1), für kyrillische Schriften die ISO-8859-5 (Cyrillic), für den Bereich der Türkei die ISO-8859-9 (Latin-5). Die deutschen Umlaute "äöü" und der Buchstabe "ß" stehen bei den Zeichensätzen Latin-1 bis Latin-6 immer an der gleichen Stelle. Die ISO-8859-1 Zeichenkodierung ist für Standardanwendungen in Europa weit verbreitet. Bei ISO-8859-kodierten Texten besteht der Nachteil, dass die einzelnen ISO-8859-Formen nicht ineinander umgeformt werden können.

2.4 Unicode 2.0

Unicode ist ein 16-Bit Zeichensatz, d.h. jedes Zeichen wird mit zwei Bytes kodiert. In der Version 2.0 [UNICODE] sind 38885 Zeichen alloziert. Die Ziele beim Design des Unicode-Standards waren:

Universalität: Jedes Zeichen kann kodiert werden.
Uniformität: Jedes Zeichen wird auf gleiche Art und Weise kodiert.
Eindeutigkeit: Jeder Unicode repräsentiert genau ein Zeichen.
Effizienz: Rohtexte ohne Steuerzeichen etc. sind effizienter zu handhaben.

Diese Ziele ergaben sich aus der Anforderung der Softwareindustrie, Applikationen für einen weltweiten Markt zu entwickeln und den Aufwand für nationale Besonderheiten zumindest in der Zeichendarstellung zu minimieren. Die Anforderungen wurden weitgehend erreicht, jedoch gibt es einige Ausnahmen bei der Eindeutigkeit. So kann der deutsche Umlaut Ä einmal als einzelner Buchstabe (U+00C4) oder als Kombination aus A (U+0041) mit einer Diaresis ¨ (U+0308) dargestellt werden. Weitere Probleme gibt es im Bereich der Schreibrichtung und der Unterscheidung zwischen Zeichen und Glyphen [ISHIDA] . Dies betrifft hauptsächlich den arabischen Schriftraum. Insgesamt bietet aber der Unicode die Möglichkeit eines weitgehend schriftunabhängigen Zeichensatzes, der auch den gesamten asiatischen Raum abdeckt. Moderne Softwarekonzepte (z.B. JAVA) basieren daher auf diesem Zeichensatz.

2.5 Universal Character Set

Das Universal Character Set (UCS) ist ein Multibyte [ Der Standard spricht hier von Multioktett. ] Zeichensatz. Seine Definition erfolgt in der ISO 10646-1 [ISO10646] . Es sind derzeit zwei Kodierungsschemata definiert. Ein Schema verwendet zwei Bytes je Zeichen und wird UCS-2 genannt. Es kann nur die ersten 64K [ 1K entspricht 1024. ] Zeichen des UCS adressieren, die sogenannte Basic Multilingual Plane . Die 4 Bytes verwendende Kodierung UCS-4 kann weitere Planes adressieren. In diesen Bereichen sind jedoch derzeit noch keine Zeichen definiert, so dass UCS-2 und UCS-4 gleichwertig sind. Der Zeichensatz, der in UCS definiert wird, ist mit dem in UNICODE definierten identisch. Änderungen in den Standards werden gegenseitig mitgeführt.

2.6 UCS Transformation Format

Der UTF-8 Kode [RFC2279] sei hier aufgeführt, da die XML-Spezifikation (siehe Abs. ) fordert, dass alle XML-Prozessoren diese Kodierung akzeptieren müssen. Bei diesem Kode handelt es sich um ein UCS transformation format (UTF). Das bedeutet, es wird der gesamte UCS (und damit auch Unicode) Zeichensatz kodiert, jedoch mit einer anderen binären Repräsentation [UTF8] . Die Kodierungslänge eines einzelnen Zeichens ist beim UTF-8 unterschiedlich. Die US-ASCII-Zeichen sind mit dem gleichen Kode abgebildet, für weitere Zeichen werden mehrere Bytes verwendet. Dabei wird ein möglichst kompaktes Kodierungsschema verwendet. ASCII wird eins zu eins abgebildet, die meisten alphanumerischen Zeichen benötigen nur zwei Bytes, alle Basisunicodezeichen werden mit maximal drei Bytes abgebildet und kein Unicodezeichen benötigt mehr als 4 Zeichen. Damit benötigt UTF-8 niemals mehr Speicherplatz als UCS-4. Beispielsweise wird dem Buchstabe L der hexadezimale ein Byte Wert 0x4C zugeordnet, dem Buchstaben Ç der zwei Bytes umfassende Wert 0xC48D.
Der Vorteil dieses Zeichensatzes ist die Möglichkeit, abwärtskompatible Software zu schreiben, die auch US-ASCII Daten bearbeiten kann und eine sanfte Migration zu neuen Multioktett-Zeichensätzen ermöglicht. Der Nachteil dabei ist, dass Zeichen oberhalb des maximalen 7-Bit Werts 127 anders kodiert sind als in den ISO-8859 Zeichensätzen. Dies gilt insbesondere auch für die deutschen Umlaute.

3. Methodik 1: Markup Sprachen

	Portable: Survives system reboot.

3.1 Standard Generalized Markup Language

Die Standard Generalized Markup Language (SGML, ISO 8879) [ISO8879] wurde entwickelt, um Markups für große komplexe Dokumente zu entwerfen. Die große Allgemeinheit, die von SGML unterstützt wird, birgt aber auch eine gewisse Komplexität in sich, die ihrer Verbreitung in manchen Bereichen hinderlich war. Die Gesamtheit von SGML ist im Rahmen dieser Arbeit nicht von Interesse. Deshalb wird im weiteren Verlauf dieser Arbeit nur die Untermenge von SGML betrachtet werden, die von der Extensible Markup Language erfasst wird.

3.2 XML-Spezifikation

Die Extensible Markup Language (XML) ist eine Teilmenge der heute gültigen Definition von SGML, die durch den WebSGML Adaptions Annex erweitert wurde. Sie ist in den Empfehlungen des W3C [XML] definiert. Das Ziel war es, die Auslieferung von SGML über das Web zu ermöglichen, wie es heute mit HTML möglich ist. XML ist vor allem eine Vereinfachung des kompletten SGML-Standards. Es ist ein Anwendungsprofil (application profile) von SGML, das bedeutet eine eingeschränkte Form von SGML. XML beschreibt eine Klasse von Datenobjekten, sogenannte XML-Dokumente und beschreibt teilweise auch das Verhalten von Applikationen, die solche Dokumente verarbeiten. Aus dem oben Gesagten folgt, dass XML-Dokumente automatisch auch konforme SGML-Dokumente sind, jedoch nicht umgekehrt. XML-Dokumente sind aus Einheiten aufgebaut, die auch Entities genannt werden. Diese sind entweder parsed (analysiert, z.B. Markups und deren Argumente) oder unparsed (nicht analysiert: z.B. freier Text). XML bietet einen Mechanismus an, um Beschränkungen der Aufteilungen und logischen Strukturen zu formulieren. Das bedeutet:
XML ist kein Sprache, sondern eine Metasprache. Markup-Sprachen wie z.B. HTML werden in XML definiert.
Die Ziele von XML sind laut der XML-Arbeitsgruppe:

XML soll sich im Internet auf einfache Weise nutzen lassen.
XML soll ein breites Spektrum von Anwendungen unterstützen.
XML soll zu SGML kompatibel sein.
Es soll einfach sein, Programme zu schreiben, die XML-Dokumente verarbeiten.
Die Zahl der optionalen Merkmale in XML soll minimal sein, idealerweise Null.
XML-Dokumente sollen für Menschen lesbar und verständlich sein.
Der XML-Entwurf sollte zügig abgefasst sein.
Der Entwurf soll formal und präzise sein.
XML-Dokumente sollen leicht zu erstellen sein.
Die Knappheit von XML-Markup ist von minimaler Bedeutung.

Neben den im XML-Standard beschriebenen Spezifikationen wird auf folgenden Standards aufgebaut:

ISO/IEC 10646 [ISO10646] beschreibt Zeichensätze, die zur Verwendung kommen (Unicode).
Der Internet RFC 1766 [RFC1766] regelt die Kodes für die Identifikation von Sprachen.
ISO 639 [ISO639] gibt Kodes für Sprachnamen an.
ISO 3166 [ISO3166] gibt Kodes für Ländernamen an.

Im Sinne von XML wird ein Datenobjekt ein Dokument genannt, wenn es wohlgeformt [ Original: well-formed ] ist. Ein Dokument besteht dabei aus einem oder mehreren Elementen. Ein Element ist immer von Markups eingeklammert. Jedes Start-Tag (öffnende Markupklammer) hat genau ein entsprechendes End-Tag (schließende Markup Klammer). Zwischen diesen "Klammern" steht der Inhalt eines Elements (Elementwert), der z.B. aus Text und weiteren Elementen bestehen kann. Ein Element eines XML-Dokuments ist ausgezeichnet, das sogenannte Wurzel- oder Dokument-Element. Dies ist nicht Bestandteil eines anderen Elements. Für alle anderen Elemente gilt, dass wenn das Start-Tag im Inhalt eines Elements enthalten ist, dann ist auch das End-Tag enthalten. Dieser Sachverhalt wird in Abb. an einem Beispiel verdeutlicht.

Beispiel a) ist ein wohlgeformtes XML-Dokument. Es enthält das Wurzelelement ROOT, das seinerseits in korrekter Verschachtelung weitere Elemente enthält. In Beispiel b) sind die Start- und End- Tags fehlerhaft. In Beispiel c) ist die Verschachtelung falsch. Das Tag EM liegt teilweise innerhalb des Elements TEXT und teilweise außerhalb.

Tags sind zwischen spitzen Klammern " < ... > " eingeschlossen, dazwischen steht der Elementname, der beim End-Tag zusätzlich noch mit einem vorangestellten " / " versehen wird. Nach dem Elementnamen können optional noch Attribute folgen. Für ein Element ohne Wert, das nur aus Start- und Endtag besteht, ist die Kurzschreibweise " < NAME/ > " erlaubt. Aus dem Gesagten folgt, dass die öffnende spitze Klammer " < " eine Sonderrolle erhält und im normalen Textfluss nicht vorkommen darf. Nur so kann der Beginn eines Tags eindeutig und allgemein identifiziert werden. Will man im normalen Text eine solche Klammer angeben, muss man dies mit der Zeichenfolge " & lt; " formulieren. Diese Schreibweise ist in XML allgemein erlaubt und wird Entity-Referenz genannt. Sie besteht aus dem Zeichen " & ", einem Entity-Referenz-Namen und einem abschließenden Semikolon " ; ". Hieraus ergibt sich, dass auch das Zeichen " & " eine Sonderbedeutung hat und im normalen Textfluss nicht [ Dies gilt genaugenommen nur mit Einschränkungen. In sogenannten CDATA-Abschnitten dürfen ] [ < ] [ und ] [ & ] [ in ihrer literalen Form verwendet werden. ] vorkommen darf. Es wird dort mittels der Zeichenkette " & amp; " umschrieben. Die Entity-Referenzen eröffnen die Möglichkeit auch Zeichenfolgen zu kodieren, die in dem verwendeten Zeichensatz nicht repräsentiert sind.
Vor dem Wurzelelement steht ein Prolog, der auch leer sein darf. Der Prolog beginnt optional mit einer XML-Deklaration, die Version, Zeichensatz und externe Referenzen deklarieren kann. Dann können Kommentare, Processing Instructions (PI) und Dokumententyp-Deklarationen folgen.
Kommentare beginnen mit der Zeichenfolge " < !-- " und werden mit der Zeichenfolge " -- > " abgeschlossen. Die Zeichenkette "--" (zwei Trennzeichen) darf innerhalb des Kommentars nicht vorkommen.
Processing Instructions sind eine Möglichkeit, in XML Anweisungen vom Dokument an ein Anwendungsprogramm weiterzugeben. Sie beginnen mit der Zeichenfolge " < ? Name " und enden mit " ? > ". Name steht dabei für einen Bezeichner, der die Anwendung identifiziert, an die sich die folgenden Anweisungen richten. Namen, die mit " XML " oder " xml " beginnen, sind dabei im Rahmen des Standards reserviert.
Dokumententyp-Deklarationen (DTD) sind eine Methode, um eine Grammatik für eine Klasse von Dokumenten zu definieren. Die DTD steht im Dokumentprolog, oder es wird dort auf eine externe DTD verwiesen. So ist es möglich, eine DTD nur einmal zu vereinbaren und dann in allen Instanzen dieser Dokumentenklasse nur noch auf sie zu verweisen. Mit der DTD wird festgelegt, wann und an welcher Stelle welches Element stehen darf. Ein XML-Dokument, das eine DTD besitzt und dessen Elementstruktur sich aus den Produktionsregeln seiner Grammatik (DTD) herleiten lässt, nennt man gültig [ Original: valid ] . Anders formuliert, hält sich das Markup eines gültigen Dokuments an Beschränkungen, die in seiner DTD vorgegeben sind. Diese Beschränkungen legen fest, welche Elemente vorkommen dürfen und an welchen Stellen sie stehen dürfen. Beispiele für gültige und ungültige XML-Dokumente werden in Abb. gegeben.

Beide Beispiele stellen wohlgeformte XML-Dokumente dar, aber nur Beispiel a) ist auch gültig. In Beispiel b) erscheint vor dem optionalen Floskel-Element ein nicht deklariertes Element, das mit "nachname" bezeichnet ist. Dies ist hier nicht erlaubt. Gleichzeitig fordert die Grammatik, dass an dieser Stelle ein Element mit dem Namen "name" steht. Wegen dieser beiden Fehler ist Beispiel b) nicht gültig.

3.3 Präsentation: Document Style Semantic and Specification Language

Die Document Style Semantic and Specification Language (DSSSL, ausgesprochen "dissel") [ISO10179] ist eine Sprache, um SGML-Dokumente zu transformieren. Da in SGML-Dokumenten die Darstellung nicht festgelegt ist, ist ein weiterer Schritt erforderlich, um zu der Präsentationsform des Dokuments zu kommen. Dieser Schritt kann mit Hilfe der DSSSL beschrieben werden, eine Scheme [SCHEME] -ähnliche Sprache, die für die Aufgabe, SGML Dokumente in andere Darstellungsformate zu wandeln, speziell entwickelt wurde. Das Zielformat ist dabei nicht festgelegt. Oft sind auch verschiedene Zielformate gleichzeitig gewünscht. Man spricht dabei auch von verschiedenen Sichten auf ein Dokument, in Anlehnung an den Begriff "Sicht" (View), wie er bei relationalen Datenbanksystemen Verwendung findet. Dabei verdeckt eine Abfrage die darunterliegende (normalisierte) Datenstruktur und präsentiert die Daten in einer oft unnormalisierten, aber der Fragestellung adäquaten Sicht.
Zielformate, die häufig Verwendung finden, sind für die gedruckte Form Postscript und TeX. Bei letzterem wird ein Großteil der Layouterzeugung dem TeX-Programm überlassen. Entsprechendes gilt für die Erzeugung einer Web-Sicht, die durch Umwandlung in HTML geschieht. Dabei übernimmt das eigentliche Layout der darstellende Browser.

3.4 Präsentation: Cascading und Extensible Stylesheets

Der einfachste Weg, um aus einer XML-Instanz eine Präsentationsform zu erhalten, ist die Verwendung von Cascading Style Sheets, Level 2 (CSS2) [CSS2] . CSS2 ist eine Formatierungssprache, die es erlaubt, bestimmte Formate wie z.B. Fonts, Zeichenabstand, Farbe, Hintergrund mit strukturierten Dokumenten zu verbinden. CSS2 verwendet medienabhängige Formate, so dass die Darstellung an das jeweilige Ausgabegerät (Drucker, Monitor, ...) angepasst werden kann. Neben diesen Funktionen, die weitgehend schon in der Vorgängerversion Level 1 zur Verfügung standen, unterstützt CSS2 auch das Erstellen von Inhaltsverzeichnissen, Tabellenlayout, automatische Zähler (z.B. zur Kapitelnummerierung) und ladbare Fonts.
Ein weitergehende Möglichkeit zur Formatgestaltung bietet die Extensible Stylesheet Language (XSL). Sie ist eine Sprache, um Formatvorlagen zu beschreiben. Sie besteht aus zwei Teilen:

Eine Sprache um XML-Dokumente zu transformieren. Diese Sprache heist XSL Transformations (XSLT) und beschreibt die Transformation von XML-Dokumenten in andere XML-Dokumente.
Ein XML-Vokabular, um Formatierungsanweisungen formulieren zu können.

Mittels XSL wird beschrieben, wie Instanzen einer Klasse von XML-Dokumenten in eine Folge von Formatierungsanweisungen umgewandelt werden können. Diese sind ihrerseits ebenfalls in XML beschrieben. XSL baut dabei auf CSS2 und DSSSL auf. Die meisten Formatanweisungen aus CSS2 finden sich in XSL wieder. In der derzeitigen Version liegt das Augenmerk vor allem in der Unterstützung von seitenweiser Formatierung (Papierausgabe) und Ausgabe in scrollbaren Fenstern (Computer-/Browserausgabe). Sie erreicht nicht die Flexibilität und Mächtigkeit von DSSSL. Das verwendete Modell von XSL erlaubt Erweiterungen. XSL ist vollständig auf DSSSL abbildbar, wie bereits real existierende Werkzeuge [XSLJ] zeigen konnten.

3.5 Ein erstes XML-Beispiel

Um die eben gemachten Ausführungen zu verdeutlichen, wird ein konkretes Beispiel vorgestellt. Es wird eine Beschreibung für einen simplen Aufsatz erstellt. Dieser Aufsatz soll aus vier Teilen bestehen, dem Titel, dem Autor, einem Abstract und dem eigentlichen Text. Dies beschreibt noch keinen bestimmten Aufsatz, sondern eine Klasse aller möglichen Aufsätze, die dieser Struktur genügen. Zusätzlich soll noch die Möglichkeit für Hervorhebungen innerhalb des Textes bestehen. Die formale Definition einer solchen Dokumentenklasse zeigt der erste Teil von Abb. . Sie zeichnet jeden Elemententyp dieser Klasse mit einem Namen aus und legt fest, an welcher Stelle welche Elemente stehen dürfen. Die Dokumentenklasse trägt den Namen DOC . Dies ist auch das Wurzelelement. Dieses kann vier verschiedene Elemente enthalten. Ein " ? " hinter dem Elementennamen gibt an, dass das Element optional ist, ein " * ", dass es beliebig oft wiederholt werden darf. Die Reihenfolge der Elemente ist festgelegt. Ein DOC-Dokument besteht also aus einem TITLE , dem AUTHOR , einem ABSTRACT und dem eigentlichen TEXT . Die ersten drei Elemente dürfen dabei auch weggelassen werden. Die ersten drei Elemente können als Wert nur Zeichenketten enthalten. Weitere Elemente innerhalb sind nicht erlaubt. Die Zeichenkette wird dabei lexikalisch analysiert ( parsed ), was durch das Schlüsselwort PCDATA ausgedrückt wird. Das bedeutet konkret, dass Entity-Referenzen (z.B. " & gt; ") aufgelöst werden. Das letzte Element mit dem Namen TEXT kann neben solchen analysierten Zeichenketten auch die Elemente EM und STRONG enthalten. Diese drei möglichen Wertinhalte können sich in beliebiger Reihenfolge wiederholen. Dies wird durch die Verwendung der alternativen Aufzählung mit dem Oder-Symbol " | " in Zusammenhang mit dem Wiederholungssymbol " * " erreicht.
Im zweiten Teil von Abb. steht dann eine konkrete Instanz dieser Dokumentenklasse. Diese zeigt einige Möglichkeiten, wie ein Dokument im Rahmen der zuvor vereinbarten Grammatik formuliert werden kann.
Im dritten Teil wird eine Präsentationsform dieses Dokuments gezeigt. Dies ist nicht mit einer der zuvor aufgezählten Standardwerkzeuge, wie z.B. DSSSL oder XSL, entstanden. Es wurde ein speziell für diese DTD entwickelter kleiner Parser verwendet, der als Ausgabeformat HTML erzeugt. Dieser Parser setzt nicht nur die logischen Markups in HTML-Markups um, sondern fügt z.B. auch vor dem eigentlichen Abstrakt-Text den Text Zusammenfassung: ein. Dies geschieht hier nur, um zu demonstrieren, dass sich die Umsetzung von der generischen auf eine Präsentationsform nicht nur auf reine Layoutkommandos beschränken muss. Dieser HTML-Quelltext wird hier nicht dargestellt. Er wurde mit einem Standard Web-Browser (Netscape 3.0) aufgeladen und damit visualisiert. Hier dargestellt wird die vom Browser erzeugte Postscript-Ausgabe.

Ein einfaches Beispiel: Eine DTD, die eine Grammatik definiert, eine konkrete Instanz dieser DTD, also ein Dokument und eine mögliche Präsentationsform, hier ein HTML-Output, der mit Netscape 3.0 gerendert wurde.

3.6 Document Type Definition

Es folgt eine kursorische Beschreibung einiger Document Type Definitions (DTD). Zunächst einige weit verbreitete und bekannte DTD's.

GENERAL DTD [ISO8879] Die "Ur-DTD", die im Anhang E der ISO-Norm veröffentlicht wurde und den Bereich Buch und Bericht abdecken sollte. Sie diente zur Veranschaulichung des Standards, war aber durchaus auch für praktische Anwendungen [ In der Urfassung hatten sich jedoch zwei nicht standardkonforme Fehler in das Manuskript eingeschlichen. ] brauchbar.
DocBook DTD Die Davenport-Gruppe bemüht sich um die Verbreitung von SGML bei Computerdokumentation. Die DocBook DTD wurde von ihr speziell zur Dokumentation von Computerhandbüchern und Programmierreferenzen entwickelt.
HTML DTD [HTML92] HTML ist die verbreitetste SGML-DTD und wird derzeit auch als XML-DTD [HTMLXML] formuliert. Näheres siehe in Abschnitt .
TEI DTD [TEI] Die Text Encoding Initiative (TEI) hat für ein breites Spektrum an Dokumententypen eine SGML-Kodierung entwickelt. TEI ist ein internationales Forschungsprojekt, das von der Association for Computing in the Humanities (ACH), der Association for Literary and Linguistic Computing (ALLC) und der Association for Computational Linguistics (ACL) unterstützt wird.
Open eBook DTD (OEB) [OEB] legt eine Struktur fest, mittels der Bücher auf papierlosem Weg übermittelt und dargestellt werden können. Während die OEB bereits in Version 1.0 veröffentlicht ist, ist der damit assoziierte kommerzielle Standard der EBX Working Group [EBX] derzeit erst in der Version 0.5. Dieser Standard regelt die Veröffentlichung, Verteilung und Auslieferung elektronischer Bücher.

Einige speziellere DTD's, die gezielt Bedürfnisse in einem ganz spezifischen Umfeld abdecken, dafür aber auch nicht so weit verbreitet sind.

QWERTZ DTD Eine Dokumentations-DTD, deren Name auf die Reihenfolge der linken oberen Tasten einer deutschen DIN-Tastatur anspielt. Sie wird oft für Softwaredokumentation im Bereich des Open Source verwendet.
ATA DTD Die Air Transport Association of America (ATA) wurde 1936 von einer Gruppe von 14 Fluglinien gegründet. Die Zielsetzung der ATA ist, technologischen Fortschritt, Kosteneffektivität und Sicherheit ihrer Mitglieder zu fördern. Für die Fülle von Spezifikationen und Handbüchern im Bereich der ATA wurde eine Familie von DTDs entwickelt, z.B. die ATA Aircraft Maintenance Manual DTD version 3.2 vom 15. März 1994.
RIF-EPC DTD Das Railroad Industry Forum (RIF) beschäftigt sich mit der Entwicklung von Standards zum Austausch von Nachschlagwerken über elektronische Bauteile innerhalb der amerikanischen Eisenbahnindustrie. Die von ihnen mitentwickelte RIF-EPC DTD unterstützt die Versendung von Katalogen auf elektronischem Weg.
Elsevier Science DTD Elsevier Science ist ein Verleger, der sich mit SGML-Werkzeugen beschäftigt, die direkt vom Autor verwendet werden. Dazu wurde eine Reihe von DTD's entwickelt.

Sprachen, die ein besonderes Ausgabeformat in den Brennpunkt ihres Interesses stellen, sind:

Speech Synthesis Markup Language (SSML) [SSML] , die neben dem eigentlichen Text in den Markups Information über Betonung, Sprechstil, usw. enthält.
Elektronisches Literaturverzeichnis - Informatik für Sehgeschädigte (ELVIS) [ELVIS] beschäftigt sich mit der blindengerechten Darstellung von elektronischen Dokumenten.

Die nächsten beiden XML-Applikationen (DTD + XML-Prozessor) gehen über die übliche Vorstellung eines "Text"-Dokuments erheblich hinaus. XML sagt nichts über die Darstellung der Daten aus. Trotzdem spielt bei Textdokumenten immer die Darstellung am Ende des Bearbeitungsprozesses eine gewichtige Rolle. Bei den folgenden Beispielen aus Chemie und Astronomie tritt dies in den Hintergrund. Hier wird XML primär zur objektorientierten Modellbildung von Daten verwendet. Es zeigt die enormen Möglichkeiten von XML auf, die in Bereiche gehen, die sonst nur Programmiersprachen vorbehalten bleiben.

Chemical Markup Language (CML): [CML] [ECML] CML war eine der ersten XML-Anwendungen. Sie wurde in den Jahren 1996 und 97 entwickelt und dient zu einem vereinheitlichten Austausch von molekularchemischen und technischen Daten. Dabei sollten als Transportmedium Inter- und Intranet zum Einsatz kommen. Mittels des objektorientierten Ansatzes auf Basis von XML (Beschreibung) und Java (Implementation) konnten viele Bereiche der Chemie überdeckt werden. Ähnliche Ansätze verfolgt auch das frühere CORE Projekt (Chemistry Online Retrieval Experiment) [CORE] , das noch SGML-basiert ist und eine elektronische Datenbank des vollständigen Inhalts des American Chemical Society Journal aufbauen soll.
Astronomical Markup Language (AML): [AML] ist eine auf die Bedürfnisse der Astronomie zugeschnittene Markup-Sprache, die es erlaubt, Objekte und Beobachtungen zu beschreiben.

Die Anzahl der SGML/XML Vorschläge aus dem Bereich der Medizin ist derzeit noch gering. Erwähnt werden sollen hier die Medical Markup Language [MML] , die in Japan erhebliche Verbreitung gefunden hat, die Clinical Practice Guidlines CPG96.DTD, die von Bob Dolin 1996 initiiert wurde, und ein Vorschlag von Kurzweil Applied Intelligence für Rezepte und Verschreibungen mit der Prescription-DTD. Eine überregionale Verbreitung dieser DTD's hat bisher nicht stattgefunden.
Dieser kleine Ausschnitt an DTD's zeigt den weiten Bereich, den XML überdecken kann. Sie kann verwendet werden für:

Objektorientierte Datenmodellierung
Beschreibung von Kommunikationsprotokollen auf OSI Level 7 zum elektronischen Datenaustausch (EDI)
Traditionelle Textverarbeitung mit variablen Ausgabeformaten

Damit werden historische Trennungen zwischen Datenbanken, Programmiersprachen und Textverarbeitung durchlässiger. Ein System zur Verarbeitung von strukturierten Dokumenten jenseits von proprietären Standards wird durch XML erst möglich.

3.7 HTML

Aus der breiten Forschung über Hypertext [NEL67] [SMISH88] in den 80'er Jahren entstanden die ersten Ursprünge der Hypertext Markup Language (HTML) im März 1989. Damals stellten T. Berners-Lee und R. Cailliau im Internet ein Projekt mit dem Titel WorldWideWeb: Proposal for a HyperText Project vor. Die einführende Beschreibung lautete wie folgt:
HyperText stellt eine Möglichkeit dar, Verbindungen zwischen Informationen zu schaffen, die ein Anwender wie bei einem Netz über einzelne Knoten besuchen kann und nach Belieben zu den benachbarten weitergehen kann. Mit HyperText gibt es eine einheitliche Anwenderschnittstelle zu einer großen Klasse an gespeicherter Information, wie z.B. Berichte, Notizen, Datenbanken, Dokumentation und Hilfesysteme. ...
Die bestehende Inkompatibilität zwischen Systemen und Anwendungen macht es unmöglich, auf vorhandene Information durch eine einheitliche Schnittstelle zuzugreifen. Dies führt zu Zeitverlust, Frustration und überflüssigen Antworten bei einfachen Datenrecherchen. Es gibt ein großes Nutzungspotential von der Integration verschiedener Systeme in der Form, dass der Anwender von einem Teil über einen Verweis zu einem nächsten übergehen kann. Im Gegensatz zu hierarchischen Konzepten wie z.B. Listen oder Bäumen, ist das Grundkonzept von HyperText ein Netz aus Informationsknoten.
Am CERN sind auf diese Weise bereits eine Reihe von Daten verfügbar gemacht worden: Berichte, Messergebnisse, Beschreibungen von Experimenten, Personenregister, Adresslisten, Computerdokumentation, und vieles mehr, das bisher ungenutzt auf Festplatten herumliegt. (...) Bisher musste man an unterschiedlichen Computern auch unterschiedliche Suchmethoden unter unterschiedlichen Programmen verwenden. Wenn einmal eine Information gefunden wurde, war es schwierig, eine private Notiz darüber zu machen oder es in einer Form zu speichern, die ein späteres Wiederfinden schnell ermöglicht.
Aus diesem ersten Ansatz, die vielfältigen Informationen an einem Institut für die Forschergemeinde einfach zur Verfügung zu stellen, entstand am 3. November 1992 der erste Entwurf von HTML. Zu diesem Dokumentenformat folgte im Juli 1993 ein erster Vorschlag für ein zugehöriges Übertragungsprotokoll, das HTTP genannt wurde.
In diesem Projekt wurden zwei Schwerpunkte angestrebt. Der eine war die Möglichkeit, Verweise (Hyperlinks) auf andere Dokumente in einem Text unterzubringen und mit einem direkten Zugriff diesen Verweisen zu folgen. Der zweite Schwerpunkt war die logische Strukturierung von Texten mittels Markups. Das zugrunde liegende Dokumentenmodell ging von einer einfachen Artikelstruktur aus, mit Überschriften, Unterüberschriften und einigen Markierungen zum Hervorheben eines Textes. Dieses Konzept war nicht neu und bereits vollständig in SGML beschrieben. Durch die Einführung in HTML und dessen rasante Verbreitung gelangte es zu einer weltweiten Bekanntheit, insbesondere nachdem das CERN am 30. April 1993 die WWW-Technologie in die Public Domain gab.
Heute werden die Nachfolgeversionen, die inzwischen die Versionsnummer 4.0 erreicht haben, häufig als einfaches, plattformübergreifendes Interface, für einen Zentralrechner verwendet. Es ist aber immer noch eine Stärke von HTML, Textdokumente in einer Form zu verteilen, die unabhängig von der Zielplattform ist, die grafische Oberflächen genauso gut bedient wie einfache ASCII-Terminals oder Drucker. Dies ist nur möglich, weil das Dokument keine Festlegung der Darstellungsform enthält und auf jeder Plattform mit den dort zur Verfügung stehenden Mitteln optimal dargestellt werden kann. Dies ist Aufgabe eines Browserprogramms, das die abstrakte Dokumentenstruktur in ein gutes geometrisches Layout umsetzt.
Heute ist HTML keine eigenständige Sprache mehr, sondern ist nur noch eine von vielen SGML-DTD's, wenn auch sicher mit Abstand die populärste. Da es für komplexere Strukturen zu wenig Flexibilität bietet, wurden verschiedenste Lösungsmöglichkeiten vorgeschlagen. Eine davon formulierte Sperberg 1994 folgendermaßen [SPERB94] :
HTML zeigt, dass SGML-Markup-Sprachen für den Informationsaustausch im Netz nützlich sind. Wie kann man diesen Nutzen vergrößern? Eine Möglichkeit ist, die Menge an erlaubten Elementen mit jeder HTML-Version zu erweitern. Wir vertreten hier einen radikaleren Ansatz: vollständige SGML-Unterstützung im WWW. Wir glauben, dass die Schwierigkeiten gering, der Aufwand vertretbar und die Vorteile überwältigend sind.
SGML ist eine Metasprache um Markup-Sprachen zu definieren. HTML ist nur eine Instanz dieser unbegrenzten Klasse. Zur Zeit müssen Dokumente in anderen SGML-Instanzen erst in HTML übersetzt werden, um sie mit einem Browser darstellen zu können, was bisweilen zu einem nicht vertretbaren Informationsverlust führt.
In gewisser Weise ist XML die konsequente Antwort auf diese Forderung.

3.8 Abstraktionsebenen

Der Bezug von XML zu anderen Beschreibungsformaten soll an Hand der Abb. gegeben werden. In ihr wird versucht, die einzelnen Formate bezüglich ihrer Abstraktheit einzuordnen.

Die unterschiedlichen Ebenen der Beschreibung eines Dokuments. Zur Veranschaulichung wird in Klammern eine traditionelle Berufsgruppe im Verlagswesen angegeben, die sich um diesen Abschnitt der Dokumentenerstellung kümmert. Dateiformate sind rechts auf der Höhe angegeben, die ihrer Modellierung entsprechen. Umformungen sind meist nur von Formaten weiter oben nach unten möglich. Word-X steht für die Gruppe der üblichen Textverarbeitungsformate.

An oberster Stelle steht das Generic Coding . Bei dieser Repräsentation werden nur inhaltliche Dokumententeile kodiert. In dieser Sicht gibt es nur die logische Struktur des Dokuments. Bei Verwendung von Markup-Sprachen spricht man auch von logischem Markup . Logisches Markup lässt sich gut mit XML realisieren. Um Missverständnissen vorzubeugen, sei hier jedoch betont, dass die Verwendung von XML in keiner Weise logisches Markup garantiert; HTML ist ein Beispiel, das dies verdeutlicht. LaTeX ist eine konkrete Sprache (die auch hauptsächlich mit Markups arbeitet, aber auch weitergehende Eigenschaften hat, wie z.B. Kontrollkonstrukte usw.). Verwendet man LaTeX im Sinne des Entwicklers, handelt es sich um eine rein logische (generische) Dokumentenrepräsentation. Da es jedoch konzeptionell nicht verhindert, auf tiefere Schichten (das darunterliegende TeX) zurückzugreifen, wird es in Abbildung unterhalb von XML dargestellt.
Einen Zwitter zwischen generischer und visueller Kodierung stellt HTML dar. Es kennt rein logische Markupelemente, z.B. die hierarchischen Überschriften, bietet aber auf der anderen Seite auch visuelle Markupelemente, die z.B. Fonts und Farben betreffen.
Ein typischer Vertreter einer visuellen Markup-Sprache ist das Rich Text Format (RTF), das oft als Speicherformat gewählt wird, wenn Daten zwischen Textverarbeitungsprogrammen verschiedener Hersteller oder Versionen ausgetauscht werden sollen. Mittels RTF können Schriftarten und multiple geometrische Parameter eines Textes beschrieben werden.
Soll ein Dokument auf Papier dargestellt werden, kommen sogenannte Seitenbeschreibungssprachen zum Einsatz. Sehr weit verbreitet ist die Sprache Postscript . Aus Sicht einer solchen Sprache besteht ein Dokument aus Punkten, Linien und Zeichen bestimmter Schriftarten [ Postscript ist darüber hinaus eine turingmächtige vollständige Programmiersprache. Prinzipiell lassen sich alle hier vorgestellten Ebenen in Postscript implementieren. So könnte man einen XML-Parser in Postscript schreiben. Dieser Aspekt soll hier jedoch nicht weiter vertieft werden. ] .
Als letzter Schritt muss ein Dokument konkret auf Papier gebracht werden. Im Falle von Postscript übernimmt diesen Schritt ein sogenannter Raster Image Processor (RIP), der üblicherweise in Druckern fest als Firmware realisiert ist. Ein solcher RIP kann dann direkt die Hardware ansteuern, also eine Tintendüse zu einem bestimmten Zeitpunkt zur Farbabgabe veranlassen oder die Belichtertrommel eines Laserdruckers an einer bestimmten Stelle entladen. Historisch gibt es neben rasterorientierten Ausgabegeräten auch vektororientierte, so z.B. Plotter oder Vektorterminals. Für sie gilt das gleiche wie für RIPs, mit dem einzigen Unterschied, dass das Ausgabeelement nicht Punkte, sondern Linien sind.
Die unterschiedliche Abstraktheit soll noch auf eine andere Weise verdeutlicht werden. Um den Informationsgehalt von Daten zu untersuchen, kann man sich folgende Frage stellen: Was ist erkennbar, wenn man den Datensatz in den unterschiedlichen Formen ansieht? Dies sei an dem Beispiel des Textes dieses Absatzes aufgeführt:

generisch: Eine Abschnittsüberschrift lautet Abstraktionsebenen .
visuell: Die Zeichenkette Abstraktionsebenen kommt in dem Text vor.
Grafikprimitive: Die einzelnen Buchstaben sind den Worten nicht mehr sicher zuzuordnen. Sie werden geometrisch positioniert.
Rasterbild: Es gibt schwarze und weiße Punkte.

Diese Aufstellung verdeutlicht, warum der Weg von konkreten zu abstrakten Darstellungsformen nicht automatisch möglich ist. Der Weg von oben nach unten ist möglich und mit Hilfe von festgelegten Umsetzungsregeln exakt beschreibbar.

4. Methodik 2: Medizinische Standards

	Your true value depends entirely on what you are compared with.

Die in Kap. zu definierende DTD soll verträglich mit bestehenden Datenmodellen sein. Diese Forderung wird benötigt, um eine Interoperabilität mit bestehenden Systemen herstellen zu können. Sie ist aber auch notwendig, damit Daten, die auf Basis dieser DTD erstellt wurden, auch in anderen Bereichen verwendbar sind.
Es werden im Folgenden eine Reihe von internationalen und international verbreiteten Standards vorgestellt. Das Message Standards Developers Subcomittee (MSDS) des Health Informatics Standards Planning Panel (ANSI HISPP) zählt dabei sieben Arbeitsgruppen (Joint Working Groups, JWG) auf:

Für medizinische Datenmodelle gilt IEEE/Medix [MEDIX] .
Für die interinstitutionelle Datenkommunikation gilt ANSI X12 [X12] .
Für die intrainstitutionelle Administration gilt HL7 [HL7] .
Für Anforderungen (Order) gilt ebenfalls HL7 .
Klinische Ergebnisse werden mittels ASTM [ASTM] formuliert.
Pharmakologische Informationen beschreibt NCPDP [NCPDP] .
Bildformate und Bilderübermittlung werden von ACR/NEMA mit dem DICOM-Standard [DICOM] beschrieben.

Im europäischen Raum spielen HL7, ASTM und DICOM eine bedeutende Rolle. Der Stellenwert von ANSI-X12 ist erheblich geringer wegen des europäischen Konkurrenzstandards EDIFACT [EDIFACT] .

4.1 HL7

Health Level Seven [HL7] (HL7) wurde nach einem Treffen an der Universitätsklinik Palo Alto, USA, 1987 in einer ersten Fassung entwickelt. Mittlerweile wird der Standard von einer kommerziellen Organisation gepflegt. Die letzte normative Version stammt aus dem Jahr 1996 und trägt die Versionsnummer 2.3. Auf diese wird im weiteren Bezug genommen. HL7 definiert Transaktionen, die im Alltag einer Klinik eine Bedeutung haben. Es unterscheidet dabei zwischen der grundlegenden Struktur einer Nachricht, der Abstract Message Definition , und der Repräsentation solcher Nachrichten, den Encoding Rules . Erstere ist nach dem OSI-Referenzmodell in der Schicht 7 (Applikationsebene) angesiedelt, während die Encoding Rules die tieferen Schichten betreffen. Eine OSI-konforme Schicht 6 (Präsentationsebene, z.B. ASN.1 Basic Encoding Rules) wird nicht definiert. Eine Nachricht wird in Segmente aufgeteilt, die ihrerseits wieder aus Feldern bestehen. In diesen Feldern stehen dann die eigentlichen Daten wie z.B. Name oder Geburtsdatum des Patienten usw.. Derzeit definierte Transaktionen betreffen z.B. Patientenerfassung, Aufnahme, Entlassung und Verlegung, Essensanforderungen, Anforderung und Übermittlung von Laboruntersuchungen (siehe dazu den Absatz über ASTM weiter unten), Beobachtungen von Ärzten und Schwestern und Medikamentenanordnungen. Um HL7-Nachrichten an länderspezifische Gegebenheiten anpassen zu können, gibt es Z-Segmente, die von den jeweiligen nationalen HL7-Gremien definiert werden. HL7 beschreibt in seiner jetzigen Form kein Datenmodell. Es ist im Wesentlichen eine Sammlung von Nachrichtentypen. In diesem Rahmen wird eine große Anzahl an Datenelementen definiert, die Relationen zwischen diesen Elementen werden nicht explizit definiert. Sie ergeben sich nur teilweise aus der Art und Weise, wie die Elemente in den Nachrichten verwendet werden.
Im Rahmen von HL7 gibt es derzeit Bemühungen, die Struktur einer Patientenakte in einer XML-konformen DTD zu beschreiben. Dies liegt derzeit in Form eines Diskussionsvorschlags [HL7XML] vor. Diese modelliert HL7-Nachrichten. Sie stellt also eine alternative Syntax für HL7-Nachrichten zur Verfügung.
Ein Datenelement, das für die Beschreibung von Texten von Bedeutung ist, ist neben dem reinen Text (Text data, HL7-Section 2.8.43) der formatierte Text (Formatted Text, HL7-Section 2.8.17). Bei diesem Datentyp können in den Text Formatierungskommandos (Markups) eingestreut werden. Ein solches Kommando beginnt immer mit einem Punkt " . " gefolgt vom Kommandonamen und eventuellen Parametern. Das Kommando wird dabei von Fluchtsymbolen eingeklammert. Es gibt Kommandos für Zeilenumbruch ( .br ), Wortumbruch ( .fi , .nf ), Einrückung ( .in , .ti ), Leerräume definierter Breite ( .sp , .sk ) und Textausrichtung (.ce Zeilenzentrierung). Es handelt sich dabei also um ein rein visuelles Markup.

4.2 ANSI ASC X12N

Das Accredit Standards Comitte (ASC) X12N entwickelt Nachrichtenformate und Transaktionstypen, u.a. für Berichte über Verletzungen, Krankheit oder Vorfälle (148).
Die Verwendung von X12 kodierten Nachrichten ist vor allem in Nordamerika weit verbreitet.

4.3 EDIFACT

Electronic Data Interchange For Administration, Commerce and Transport [EDIFACT] (EDIFACT) ist ein allgemeiner nachrichtenbasierter Kommunikationsstandard mit einer speziellen Untermenge für den Bereich des Gesundheitswesens. Im europäischen Umfeld spielt EDIFACT noch eine gewisse Rolle. Dabei wird es oft parallel zu X12 und HL7 angewendet, auch wenn diese Standards eine transaktionsbasierte Syntax verwenden. Auch für EDIFACT gibt es derzeit Bemühungen, eine XML-Transformation zu erstellen. Auch diese (wie bei HL7) beschränkt sich allerdings darauf, EDIFACT-Elemente auf XML-Tags abzubilden. Es erfolgt also keine XML-Abbildung der realen Objekte, die beschrieben werden, sondern eine Abbildung von EDIFACT-Nachrichten.

4.4 ASTM

Das Komitee E31 der ASTM ist eine bei der ANSI akkreditierte Organisation. Der Standard E1238 [ASTM] wird dabei von den meisten amerikanischen Laborbetreibern verwendet, wenn es um die Übermittlung von Labormesswerten geht. Der Standard E1394 [ASTM1394] wird für die Kommunikation zwischen Laboranalysegeräten und Computersystemen verwendet.
HL7 hat inzwischen diese Entwicklung integriert. Die in HL7 definierten Formate zur Laborwertübermittlung entsprechen denen in ASTM-E1238. Nur die in beiden Standards verwendete Nomenklatur unterscheidet sich noch.

4.5 MEDIX

Die IEEE-P1157 [MEDIX] Medical Data Interchange (MEDIX) definiert ein Protokoll auf Anwendungsebene mit einer ähnlichen Zielsetzung wie HL7. Im Gegensatz zu diesem baut es jedoch auf dem 7-schichtigen OSI-Referenzmodell auf und beruft sich wesentlich strenger auf darunterliegende Standards wie z.B. Remote Operation Service Element (ROSE) oder eine Syntaxbeschreibung nach der von der ISO normierten Abstract Syntax Notation 1, Basic Encoding Rules (ASN.1-BER). Unabhängig von diesen Unterschieden haben die Arbeitsgruppen Bestrebungen, sich gegenseitig anzunähern. So hat das HL7-Gremium ein Format eingeführt, das leicht in die ASN.1-Notation umgesetzt werden kann. Transaktionen, die auf diese Art beschrieben werden, können direkt in das MEDIX-Protokoll umgesetzt werden.

4.6 DICOM

Der Standard Digital Imaging and Communications in Medicine (DICOM) [DICOM] findet seit einigen Jahren im radiologischen Bereich weite Verbreitung. Er dient zum Austausch von Bildern und bildassoziierten Daten. Das Konzept von DICOM beruht auf einem objektorientierten Datenmodell. In diesem Datenmodell gibt es eine Reihe von Klassen, die typischerweise die Ausgabe von verschiedenen Arten von Bildgebern beschreiben, so z.B. Sonographie, Kernspin, CT usw.. Dem objektorientierten Ansatz entsprechend sind diesen Objekten Methoden zugeordnet, die in der DICOM-Nomenklatur services genannt werden.

So stellt sich aus der Sicht von Dicom die Welt dar. Die Darstellung verzichtet auf einige hier nicht relevante Entitäten zur besseren Übersicht.

Die grundlegende Informationseinheit ist das Attribut. Ein Attribut ist durch folgende Eigenschaften definiert:

eindeutiger Attributname
eindeutiges Tag, ein Nummernpaar, bestehend aus Gruppennummer und Elementnummer
die Beschreibung der semantischen Bedeutung
Form der Wertrepräsentation (Syntax der Wertbeschreibung)
Anzahl, wie oft ein solches Attribut vorkommen darf
Typklassifikation: Attribut muss einen Wert haben, Attribut muss vorkommen oder Attribut ist optional. Diese Klassifikation ist kontextabhängig, je nachdem in welcher Klasse das Attribut vorkommt.

In Zusammenhang mit dieser Arbeit ist neben dem Datenmodell auch die Ergänzung 23 [SUP23] wichtig, die sich mit strukturierten Berichtwesen beschäftigt.

4.7 CORBA und CORBAmed

CORBAmed wird der Bereich der Object Managment Group (OMG) [ Die OMG ist nach eigenen Angaben mit über 800 Mitgliedern das größte Softwarekonsortium der Welt. Dazu gehören z.B. 3M, IBM, HP, Sun Microsystems, Fujitsu, Oracle, Bank of America, Ford, Boeing, Lucent, Hitachi, Xerox, VISA, Microsoft, AT ] [ & ] [ T, usw.. ] genannt, der sich mit Aspekten des Gesundheitswesens beschäftigt. Die OMG wurde 1989 mit dem Ziel gegründet, Standards für die Portierbarkeit und Interoperabilität verteilter objektorientierter Anwendungen zu schaffen [VINOSKI] . Das Hauptprodukt der OMG ist die Common Request Broker Architecture (CORBA) [CORBA] . Ein entscheidender Teil von CORBA ist die Interface Definition Language (IDL) [ISO14750] . Diese Sprache erlaubt eine programmiersprachen- und plattformunabhängige Beschreibung von Objekten. Gleichzeitig werden sogenannte Mappings definiert, die in einer gewählten Zielprogrammiersprache eine in IDL definierte Klasse formulieren. Mappings sind inzwischen für alle gängigen Programmiersprachen verfügbar, so z.B. C, C++, JAVA usw.. Dies erlaubt, dass eine Klasse, die in IDL definiert ist, in nahezu jeder relevanten Programmiersprache formuliert und damit auch implementiert werden kann. CORBA definiert außerdem, wie verteilte Instanzen derartiger Klassen miteinander kommunizieren können. CORBAmed ist eine Sammlung an Klassen, die medizinische und klinische Objekte beschreiben. Teilweise sind diese so formuliert, dass sie mit den Definitionen in HL7 konform sind.

5. Systemdesign

	If you have a difficult task, give it to a lazy person - they will find an easier way to do it.
	Hlade's Law

Im folgenden Kapitel soll das Design eines Dokumentenverwaltungssystems ausformuliert werden. Das verwendete Dokumentenformat ist dabei die MucMedRep -DTD, eine XML-DTD, die zur Beschreibung klinischer, patientenbezogener Routinedokumente hier entwickelt wird. Nach Definition und Erläuterung dieser DTD wird das Design eines Systems vorgestellt, das diese MucMedRep -Dokumente bearbeiten, verwalten und versenden kann.

5.1 Die MucMedRep DTD

Es folgt die Definition und Erläuterung einer konkreten Document Type Definition, die die bisher aufgeführten Anforderungen erfüllt. Sie wird mit MucMedRep bezeichnet. Dies ist die Kurzform von Munich Medical Report .
Folgende Grundregeln wurden beim Design eingehalten. Sie bewirken eine einfache Grammatik, eine performante, relationale Abbildbarkeit von XML-Instanzen in einer Datenbank und geben für die Applikationen eine strenge Benutzerführung vor, die den Anwender von visuellem Design und unnötigen alternativen Darstellungen ("Featuritis") entlastet.

Nur Informationen, die das Dokument im textuellen Sinn betreffen, werden in der MucMedRep DTD modelliert. Der Dokumentenzustand (Draft, Version, Freigabe, Archiviert), Authentifizierung und Historisierung werden außerhalb des Dokuments verwaltet.
Der Syntaxbaum sollte möglichst flach sein.
Processing Instructions werden nicht verwendet.
Die logisch gliedernden Elemente stehen alle auf oberster Ebene. Nur solche Elemente können Attribute haben.
Die Elemente ohne feste semantische Bedeutung (z.B. UL: Liste/Aufzählung beliebiger Dinge) und Elemente mit mehr visuellem Charakter (z.B. STRONG: hervorheben) stehen innerhalb der logisch gliedernden Elemente. Sie sind eine Untermenge aus dem HTML-Standard. Die Untermenge soll auf ein Mindestmaß beschränkt bleiben. Bei zu großer gestalterischer Freiheit besteht die Gefahr, dass semantische Elemente des XML-Dokuments weggelassen werden und dafür visuell im "HTML"-Teil formuliert werden (Beispiel: Unterschriften werden nicht im SIGN -Element angegeben, sondern im Text mit visuellem Markup untergebracht). Diese Gefahr besteht zwar immer, wird aber bei eingeschränkten gestalterischen Mitteln unwahrscheinlicher und ist in der Dokumentendarstellung meistens erkennbar.
Tagnamen sind groß geschrieben und maximal 16 Zeichen lang. Diese Einschränkung erleichtert ein performantes Design einer relationalen Datenbank, die XML-Instanzen der MucMedRep-DTD speichern soll. Dies gilt auch für die nächsten zwei Punkte.
Attributnamen bestehen nur aus kleinen Buchstaben, um sich visuell im XML-Source hervorzuheben. Sie bestehen ebenfalls maximal aus 16 Zeichen.
Ein Element hat maximal zwei Attribute. Der Wert des ersten Attributs ist maximal 16 Zeichen lang, die Anzahl der vorkommenden Werte soll klein sein. Der Wert eines zweiten Attributes kann maximal 256 Zeichen lang sein, der Wertbereich darf groß sein.
Ist ein Attribut optional, muss es das letzte sein, d.h. die Stelle, an der ein Attribut vorkommt, ist fix.
Der Wert eines Elements enthält maximal 65365 Zeichen.
Der Wert von XML-Elementen ist eine unstrukturierte Zeichenkette. In Anlehnung an internationale Standards gibt es aber für bestimmte Variablen bestimmte Schreibweisen. Eine Applikation soll solche strukturierten Werte erkennen und entsprechend behandeln (z.B. ein Datum nach ISO 8601 soll erkannt und der Anwendung entsprechend umformatiert werden). Werte, die nicht der Typisierung entsprechen, sind kein Fehler, können aber evtl. nicht mehr auf andere Standards abgebildet werden.

Das Entity Relationship (ER) Modell eines Dokuments aus Sicht der MucMedRep Document Type Definition (DTD).

Es folgt nun eine kurze Beschreibung der einzelnen Elemente und ihre inhaltliche Interpretation. Gleichzeitig werden die minimalen Anforderungen an eine XML-Applikation formuliert, die eine MucMedRep-DTD bearbeitet:

FROMORG Name der absendenden Organisation
FROMDIR Leiter/Direktor der Organisation
FROMNAME Name des Absenders
FROMADDR Adresse des Absenders
FROMPHONE Telephonnummer
FROMFAX Faxnummer
FROMMAIL E-Mail
ADDRESS Adressat, dem das XML-Dokument oder eine seiner Visualisierungen zugestellt werden soll. Bei einer postalischen Adresse werden die Teile mittels Komma oder Zeilenumbruch voneinander getrennt, die bei üblicher Schreibweise in eigenen Zeilen stehen. Das Attribut type kann den Wert TO oder CC annehmen. Es darf auch weggelassen werden, dann wird der Wert TO angenommen. TO kennzeichnet dabei den eigentlichen Adressaten, CC steht für das englische Carbon Copy und benennt Adressaten, die nur nachrichtlich das Dokument zugestellt bekommen. Von der Grammatik sind die beiden Attribute in beliebiger Anzahl und Reihenfolge aufführbar. Eine MucMedRep-Applikation darf jedoch Adressen von mehrfach auftretenden TO -Attributen ignorieren oder mit anderen nachrichtlichen Adressen gleichbehandeln.
PID Stellt den gültigen Primärschlüssel des Patienten des zugrunde liegenden klinischen Informationssystems dar. Führende und nachfolgende Leerzeichen [ Der Begriff Leerzeichen wird in diesem Zusammenhang synonym mit dem Originalbegriff "Whitespace" verwendet. Dies ist eine Gruppe von Zeichen, zu der das Leerzeichen im eigentlichen Sinn gehört, aber auch Tabulator, Zeilenumbruch usw.. ] werden dabei ignoriert.
PSEX Geschlecht des Patienten. M für männlich, F für weiblich, O für sonstige (other) und U für unbekanntes Geschlecht. Führende und abschließende Leerzeichen werden ignoriert. Die Darstellung entspricht der ISO-Norm 5218 [ISO5218] und damit auch der in HL7 verwendeten Kodierung. Bei einem fehlenden PSEX-Element soll die Applikation sich so verhalten, als ob ein U -Wert vorliegen würde.
PNAME Name des Patienten, zuerst Nachname, dann Vorname(n), Zwischennamensbestandteile (z.B. von, van), Suffix, Prefix und Titel. Die Teile werden mit jeweils einem Caret (^) voneinander getrennt, leere Namensbestandteile am Ende der Folge dürfen weggelassen werden. Die Namensrepräsentation entspricht der von der MSDS Subcommittee on Common Data Types der ANSI HISPP gestellten Forderung. Diese Namensrepräsentation ist auch in HL7 (Abschnitt 2.8.28 [HL7] ) und ASTM [ASTM] verwirklicht.
PDAT Geburtsdatum des Patienten, eine Datumsrepräsentation wie in SQL und HL7, Abschnitt 2.8.13 und der ISO 8601 [ISO8601] gefordert (JJJJMMTT) muss von der Applikation interpretiert werden können. Führende und abschließende Leerzeichen werden ignoriert.
DAT Untersuchungsdatum
TODAT Falls es sich um einen Untersuchungszeitraum handelt, wird hier das Enddatum angegeben. Ansonsten entfällt dieses Element.
KEY Gibt einen Schlüssel an, der das Dokument - nicht jedoch seine Version - eindeutig identifiziert. Dies entspricht normalerweise der Auftragsnummer oder in DICOM-Nomenklatur der Study-Id .
SUBJECT Beschreibt die Art der Untersuchung. In der Radiologie wird hier die Methodik angegeben, z.B. Kernspin, Computertomographie, Angiographie, ... . Im Labor ist dieses Feld für das untersuchte Material reserviert, also z.B. Blut, Liquor, Urin, ... .
KEYWORDS Hier können Schlagworte angegeben werden, unter denen das Dokument später wieder auffindbar sein soll.
AUTHOR Kennzeichnet die Person, die das XML-Dokument inhaltlich erzeugt hat. Eine Applikation darf dieses Element dazu verwenden, um zusätzliche Unterschriften zu generieren. Optional kann in einem Attribut date ein Zeitstempel angegeben werden.
WRITER Kennzeichnet die Person, die das XML-Dokument erzeugt und bearbeitet hat, üblicherweise ein Kürzel für die betreffende Schreibkraft. Falls das Dokument mittels Spracherkennung erzeugt wurde, sollte das hier vermerkt werden. Optional kann in einem Attribut date ein Zeitstempel angegeben werden. Es wird immer die Person vermerkt, die zuletzt das Dokument bearbeitet hat. Bei mehreren Bearbeitern übernimmt der Historisierungsmechanismus des Systems die Aufgabe, diese Schritte zu protokollieren. Sie sind nicht Inhalt dieser DTD.
DATE Dokumentendatum, üblicherweise das Datum, an dem das Dokument erstellt wurde.
DIAG Diagnose. Das erste Attribut sys gibt das verwendete Schlüsselsystem an. Dabei finden die von der ANSI HISPP MSDS [HISPP] angegebenen Abkürzungen Verwendung. In diesem Zusammenhang von Interesse sind: I9 (ICD9), I10 (ICD-10), SNM (SNOMED), S3 (SNOMED III) und UML (Unified Medical Language). Das zweite Attribut key gibt den Schlüssel an. Der Wert des Elements ist optional eine individuelle Ausformulierung der Diagnose, die dem speziellen Fall angemessen ist und die von der offiziellen Formulierung des Diagnosenschlüssels abweichen darf.
Beispiel:
In der ICD-10 lautet die Bezeichnung für den Schlüssel Z51.1: "Chemotherapeutische Verabreichung wegen bösartiger Neubildung" . Eine sinnvolle Angabe innerhalb des Diagnosenelements sollte jedoch auch Zusatzinformation enthalten, die im Schlüsselsystem nicht abgebildet werden können, also z.B.:
< DIAG sys="I10" key="Z51.1" > Dritter Zyklus der Chemotherapie nach dem ACO-Schema < /DIAG >
Falls der Elementwert leer ist oder nur aus Nullzeichen besteht, sollte sich eine Applikation so verhalten, als wäre der offizielle Schlüsseltext als Elementwert vorhanden.
PIC Es können darüber andere Datenobjekte referenziert werden. Dieses Element verweist dabei üblicherweise auf ein Bild oder eine Grafik. Der Typ des referenzierten Objekts wird dabei im ersten Attribut type angegeben. Die Referenz steht im zweiten Attribut ref . Der Wert kann einen beschreibenden Text enthalten. Es ist erlaubt, dass eine MucMedRep-Applikation dieses Element ignoriert.
OPENING Anrede
TEXTQ Freier Text, beschreibt Motivation, Fragestellung und Einleitung.
TEXT Freier Text
TEXTR Freier Text, falls vorhanden werden hier Resultate zusammengefasst, gewertet und Empfehlungen ausgesprochen.
SIGN Name und Funktion eines Unterschreibenden, also derjenigen Person, die für den Inhalt verantwortlich ist. Es können mehrere Unterschriften aufeinanderfolgen. Eine MucMedRep-Applikation muss mindestens die ersten drei Unterschriften berücksichtigen. Die Funktion bzw. Position des Unterschreibenden wird im Attribut pos angegeben. Eine MucMedRep-Applikation kann eine gewisse Anzahl an Positionsattributen kennen und automatisch expandieren (z.B. für "OA" wird "Oberarzt der Klinik" eingesetzt), unbekannte Attributwerte werden als Text übernommen, sind also insbesondere kein Fehler.
AUTH kann dazu verwendet werden, die Dokumentenintegrität sicherzustellen. Die Daten, die betrachtet werden, sind Elemente der ersten Parse-Ebene vom " < " des eröffnenden Tags bis inclusive der ">" des schließenden Tags. Das AUTH-Element wird dabei selbst nicht berücksichtigt. Im Attribut method wird dabei die verwendete Methode angegeben. Es ist erlaubt, dass eine MucMedRep-Applikation dieses Element ignoriert.
Beispiel Methode MD5 [MD5] : Alle Zeichen der Elemente zwischen < REPORT> und < AUTH> werden zur MD5-Summenbildung herangezogen. Dabei werden Kommentare ignoriert, ebenso Zeichen und Leerzeilen zwischen den Elementen der obersten Stufe.
Es ist primär die Aufgabe des Frameworks, die Integrität und Authentizität der Dokumente sicherzustellen. Mit dem AUTH -Element ergibt sich die Möglichkeit in ungesicherten Umgebungen (Internet, portable Datenträger), die direkt mit XML-Dateien umgehen, eine einfache Sicherung innerhalb des Dokuments zu realisieren. Die Verwendung sicherer und authentischer Protokolle ist der Verwendung dieses Elements vorzuziehen.
EM, STRONG, BR, UL, LI Diese Elemente haben keine spezielle Bedeutung. Sie dienen der allgemeinen logischen Strukturierung der Textblöcke. Sie entsprechen den gleichnamigen Elementen des HTML-Standards. EM dient der Hervorhebung innerhalb eines Textes, STRONG beschreibt eine Hervorhebung am Anfang oder zwischen Abschnitten als eine Art "kleine Überschrift". Die Namensgebung STRONG ist aus Sicht des Generic Coding unglücklich gewählt, da sie ein visuelles Markup assoziiert. Um aber auf dieser Ebene HTML-konform zu bleiben, wurde dieser Tagname beibehalten. Von einer bestimmten Visualisierung dieses Markups kann im allgemeinen nicht ausgegangen werden.
BR trennt logische Abschnitte, die im üblichen Textlayout Absätzen entsprechen. Es steht zwischen den Abschnitten. Sein Wertbereich ist leer.
Mit UL und LI werden Aufzählungen beschrieben.

Die formale Formulierung der DTD ist in dargestellt. Wie man sieht, besteht die kleinste valide Instanz aus Patientennamen (PNAME), Untersuchungsdatum (DAT), Primärschlüssel des Dokuments (KEY), Erstellungsdatum (DATE) und dem eigentlichen Textteil (TEXT). Die letzten drei Elemente finden dabei eine Entsprechung in der herkömmlichen Textverarbeitung. Der KEY entspricht dem Filenamen, DATE dem Fileerstellungsdatum und TEXT dem Fileinhalt. Jede valide MucMedRep-Instanz muss darüber hinaus aber mindestens noch einen Patientennamen und einen Zeitpunkt kennzeichnen, auf den sich das Dokument bezieht.

Die vollständige Formulierung der MucMedRep Document Type Definition.

Die optionalen Elemente WRITER und KEYWORDS werden von den meisten heute üblichen Textverarbeitungsprogrammen in sogenannten Infobereichen im Fileinhalt unterstützt. Alle anderen Elemente sind mit Textverarbeitungsprogrammen nicht abbildbar.

5.2 Systemdesign

Als Grundstruktur wurde eine heute übliche 3-tier Client-Server Architektur gewählt. Es entstehen dabei folgende Softwareteile:

Die Formulierung der MucMedRep-Struktur kann in verschiedenen formalen Sprachen erfolgen. Hinter jeder Sprache steckt eine eigenes Softwarekonzept. JAVA steht für die klassische objektorientierte Programmiersprache, CORBA für das Konzept der Objektverteilung und XML für objektorientiertes Dokumentenmarkup. Die generischen (logisch strukturierten) Formulierungen sind ineinander transformierbar. Die angegebenen Protokolle sind teilweise Vorschläge, die häufig Verwendung finden.

Server Tier: Dies ist ein konventionelles, relationales Datenbanksystem. Die MucMedRep -DTD erlaubt auf Ebene der semantischen Elemente keine Verschachtelung (Baumstruktur o.ä.). Dies erlaubt eine einfache Abbildung auf ein relationales Datenbankmanagementsystem (RDBMS). Ebenso denkbar wäre eine objektorientierte oder objektrelationale Speicherung. Auf diese wurde hier verzichtet, da die RDBMS heutzutage eine weitere Verbreitung, eine höhere Standardisierung und einen breiteren Markt an unterschiedlichen Produkten für jede Plattform bieten. Zur Kommunikation mit der RDBMS kommt Entry Level SQL 2 [SQLII] zum Einsatz. Dies ist der kleinste gemeinsame Nenner, der von nahezu allen RDBMS unterstützt wird und auch in einer ISO-Norm [ISO9075] standardisiert wurde.
Middle Tier: Der Applikationsserver ist ein validierender Parser, der ein Dokument auf Wohlgeformtheit und Gültigkeit bezüglich der MucMedRep-DTD überprüft und dabei das Dokument in eine interne Präsentation überführt. Von dieser aus kann es in beliebige andere Präsentationsformen überführt werden. Der Zugang zu diesem Server erfolgt über eine Reihe von standardisierten Protokoll-Stacks Über diese erfolgt die Kommunikation. Dies sind in der jetzigen Fassung CORBA [CORBA] und HyperText TransportProtokoll (HTTP) als weitverbreitete Protokolle. Derzeit nicht implementiert sind applikationsspezifische Schnittstellen wie Javas Remote Method Invokation (RMI) [RMI] oder Microsofts DCOM. Dabei wird das Dokument in das jeweilig zugehörige Format transformiert, wie IDL für CORBA, XML für HTTP und als Java-Klasse für RMI. Neben diesen externen Schnittstellen werden für die interne Kommunikation weitere Protokolle verwendet. Dazu gehört die Kopplung mit dem RDBMS über das datenbankspezifische Protokoll. Dabei werden die Dokumente in SQL formuliert. Als unidirektionaler Protokollstack dient das Berkeley-Spoolsystem. Über dieses werden Dokumente zum Ausdruck exportiert. Das Datenformat dabei ist Postscript. Ein Export in ein Mailsystem wie z.B. das Send Mail Transfer Protokoll (SMTP) wäre ebenfalls denkbar. Die Exportziele werden jedoch nicht innerhalb des XML-Dokuments angegeben. Sie sind als Argumente von Applikationsservices zu realisieren, wie es in den Designregeln der MucMedRep-DTD festgelegt wurde.
Client Tier: Hierfür kommt eine Menge möglicher Clients in Frage. Das Spektrum reicht dabei von der Konfiguration XML-fähiger kommerzieller Produkte bis hin zu kompletter Entwicklung eigenständiger Applikationen. Gängige XML-Werkzeuge erlauben meist einen vollständigen Blick auf die gesamte XML-Struktur. Dies ist für den anspruchsvollen XML-Autor zwar wünschenswert, aber behindert eine Schreibkraft, die sich auf das eigentliche Textschreiben konzentrieren will. Deshalb kommen nur frei programmierbare Werkzeuge in Frage, die erlauben, die Sicht auf ein XML-Dokument auf eine von einer Schreibkraft gewünschten Weise einzuschränken. Auf der anderen Seite ist eine vollständige Neuentwicklung mit erheblichem Aufwand verbunden. Deshalb werden die hier näher betrachteten Clients aus einer Kombination von bestehenden Produkten erstellt. Als Kommunikationsprotokoll wird HTTP verwendet. Mit zunehmender Verbreitung CORBA-fähiger Webbrowser kommt auch dieses Protokoll in Betracht.

Design des XML Dokumentensystems. Die Applikation wird im konkreten Fall in Python implementiert. Jeder andere DTD-konforme Editor wäre hier einsetzbar. Die Kommunikation erfolgt über das Standard-Internetprotokoll HTTP, wobei das POST-Kommando der CGI-Spezifikation Verwendung findet. Die Daten, die so übertragen werden, sind wohlgeformte und gültige XML-Dokumente. Der Applikationsserver behandelt je nach Anforderung das Dokument weiter und setzt es in das entsprechende Protokoll um.

5.3 Kodierung

Bei der Betrachtung, welche Werkzeuge zur Kodierung in Frage kommen, wurden folgende Kriterien herangezogen. Server- und Middle-Tier müssen in plattformunabhängigen Sprachen realisiert werden. Eine konzeptionelle Festlegung auf das Produkt eines Herstellers ist zu vermeiden. Damit kommen vor allem Lösungen aus dem Open Source Bereich in Frage oder Implementationen von internationalen Standards.
Da die Server-Tier als relationales Modell formuliert wird und mit dem Entry-Level von SQL2 auskommt (siehe nächster Abschnitt: Relationales Mapping), kommen nahezu alle relationalen Datenbanken in Frage. Für die verbreiteten Produkte gibt es Schnittstellen zu allen gängigen Entwicklungssystemen, entweder als ODBC-Schnittstelle realisiert oder als proprietäres Protokoll. Betrachtet wurden hier ORACLE als Marktführer, SYBASE als starker Mitbewerber, Adabas als stärkster Anbieter aus dem deutschen Raum und MySQL als stärkster Vertreter der nicht kommerziellen Systeme. Server wie z.B. Microsoft-SQL-Server wurden nicht näher betrachtet, wenn sie auf nur einer Plattform implementiert bzw. verbreitet sind.
Für die Entwicklung der Middle-Tier kamen Sprachen in Betracht, für die offene Implementationen von validierenden XML-Parsern zu Verfügung standen. Zusätzlich musste die gewünschte Protokollvielfalt implementierbar sein. Als erstes erfüllt JAVA die geforderten Eigenschaften. Es enthält in der heutigen Grundform bereits Corba- und RMI-Anbindung. Auch eine Realisierung in C oder C++ bietet sich an. Mit der libxml , die unter anderen von Daniel Veillard vom WWW-Konsortium entwickelt wurde, steht eine XML-Bibliothek aus erster Hand der XML-Entwickler zur Verfügung. CORBA kann z.B. mittels MICO realisiert werden, das am Fachbereich Informatik an der Universität Frankfurt entwickelt wurde und vollständig den Anforderungen des Corba 2.0 Standards genügt. Einzig eine RMI-Anbindung von C-Kode ist uns nicht bekannt. Auch unter Python [PYTHON] stand bereits sehr früh mit xmlproc von Lars Marius Garshol ein validierender XML-Parser zur Verfügung. Eine bekannte Python-CORBA Implementation ist FNORB .
Die HTTP-Anbindung kann über das Common Gateway Interface (CGI) eines Web-Servers erfolgen. Alle eben angesprochenen Lösungen bieten aber auch die Möglichkeit, Kommunikation entsprechend der HTTP-Spezifikationen aufzubauen.
Für die Entwicklung der Client-Tier gelten auf Protokollebene im Wesentlichen die eben angesprochenen Möglichkeiten. Neu hinzu kommt die Verbindung zwischen der internen Datenrepräsentation, der Anwenderschnittstelle und der Steuerung der Benutzerinteraktion. Dazu gibt es im Wesentlichen zwei denkbare Ansätze. Der erste betrifft Textverarbeitungsprogramme, die mittels spezieller Programmiersprachen anpassbar sind. Der zweite Ansatz geht von Script- oder Programmiersprachen aus und bedient sich dazugehöriger oder ergänzter Bibliotheken zur Erzeugung eines Graphic User Interface (GUI).
Zur ersten Gruppe gehören die Textverarbeitungen der großen Office-Pakete, z.B MS-Word mit seinen Makros oder mit Visual Basic, Staroffice mit seiner Basicimplementation, usw.. Das Problem bei diesen Vertretern ist, dass sie auf Protokollseite meist sehr eingeschränkt sind und in ihrer Kommunikation auf die Verbindung mit ihren Mitkomponenten des jeweiligen Pakets fokussiert sind. Auch die Möglichkeit, einen Parser zu realisieren, wird in diesem Umfeld nicht gesondert unterstützt.
Auch zu dieser Gruppe ist der Editor EMACS [EMACS] mit dem eingebauten Elisp -Interpreter zu rechnen. Da EMACS für eine Reihe von SGML-Anwendungen verwendet wird, gibt es bereits eine Menge Vorarbeiten im Bereich der Parser. HTTP wird im Bereich der Kommunikation unterstützt. Eine CORBA-Realisation mit Mapping von IDL nach EMACS-Lisp ist uns nicht bekannt.
In der zweiten Gruppe stehen die Programmiersprachen C, C++ und Java. Smalltalk und Scheme werden hier nicht näher betrachtet. Bei den Scriptsprachen sind Perl [PERL] , Python [PYTHON] und Tcl [TCLTK] zu nennen. Die Zahl der GUI-Libraries für C und C++ ist unüberschaubar und soll nicht weiter vertieft werden. JAVA enthält in seiner Standardform des JDK bereits mit AWT und Swing zwei große GUI-Bibliotheken. Bei den Scriptsprachen ist vor allen Dingen Tk zu nennen, das ursprünglich mit Tcl entwickelt wurde, aber inzwischen auf viele andere Sprachen übertragen wurde, so auch auf Perl und Python . Für die drei hier genannten Scriptsprachen existieren XML-Parser, es steht ein HTTP-Stack zur Verfügung und CORBA wird unterstützt.
Ein dritter Weg soll noch wegen seiner Einfachheit erwähnt werden: die reine HTML-Lösungen. Zwar läßt sich mittels HTML keine vollständige Clientapplikation erzeugen, für bestimmte einfache Aufgaben kann es aber durchaus ausreichend sein. Die Funktionalität muss dabei von der Middle-Tier zur Verfügung gestellt werden, die Client-Tier ist dann ein reines "HTML-Terminal", üblicherweise Webbrowser genannt. Strenggenommen handelt es sich deshalb bei diesem Ansatz nicht mehr um eine 3-Tier Client Server Architektur.

5.4 Mapping

Der Begriff Mapping wird in diesem Abschnitt in Analogie zu seiner Bedeutung im CORBA-Standard verwendet. Es wird hier die Beschreibung der in XML angegebenen Daten in anderen Paradigmen untersucht. In anderen Worten, es soll die MucMedRep-DTD in anderen Sprachen formuliert werden. Die betrachteten Paradigmen sind dabei relationale Algebren und objektorientierte Modellierung . Für ersteres soll die DTD in SQL beschrieben werden. Für den zweiten Fall wird die Interface Definition Language (IDL) [ISO14750] verwendet. Diese Sprache hat den Vorteil, dass für sie ihrerseits wieder Mappings für alle gängigen Programmiersprachen existieren. Dadurch kann man, sobald man die MucMedRep-DTD einmal in IDL beschrieben hat, sie auch in allen anderen gängigen Sprachen beschreiben und hat insbesondere bewiesen , dass sie sich darin beschreiben lässt.
Zunächst soll die relationale Beschreibung untersucht werden.

Relationale Modellierung einer vereinfachten DTD: Alternative Ansätze an einem vereinfachten Beispiel eines Dokuments. In der ersten Abbildung das ER-Modell und die zugehörige DTD. In der zweiten Abbildung ist die entsprechende normalisierte relationale Darstellung abgebildet. In der dritten Abbildung wird nicht das ER-Modell, sondern seine XML-Abbildung relational dargestellt. Dies führt zu einer vollkommen anderen Relation.

Sie ist technisch wichtig, da die Speicherung von Daten in relationalen Datenbankmanagementsystemen (RDBMS) heute immer noch die häufigste ist. Die Abbildung von einem objektorientierten Datenmodell auf ein relationales ist in voller Allgemeinheit nicht möglich. Deshalb ist die Angabe eines solchen Mappings auch aus theoretischer Sicht bedeutsam. Für die folgenden Überlegungen kommt dazu zunächst ein vereinfachtes Datenmodell zur Anwendung. Es wird im oberen Teil von Abbildung als ER-Modell angegeben. Es handelt sich dabei um ein verkürztes MucMedRep-Modell. Es entsteht aus diesem durch Weglassen der Relationen auf Diagnosen und Absender. Auch die Attribute [ Achtung Nomenklatur: Der Begriff Attribut hat im relationalen Kontext eine andere Bedeutung als im Kontext der Markup-Sprache XML. ] , die in dieser Abbildung nicht explizit aufgeführt sind, sollen auf das Wesentliche reduziert sein. So sollen die einzelnen Entitäten neben ihren Primärschlüsseln nur noch folgende Attribute enthalten. Der Adressat soll nur aus dem Namen bestehen, das gleiche gilt für die Unterschrift. Die Dokumentenentität soll aus Patientennamen und Text bestehen. Die vollständig normalisierte [ Es handelt sich um die dritte Normalform. Da dieses Modell nur einfache Zweierrelationen aufweist, ist dies automatisch auch die fünfte Normalform. ] , relationale Beschreibung ist im zweiten Teil der Abbildung angegeben. Es wurde dabei eine anschauliche tabellenorientierte Darstellung gewählt.
Es besteht aber nicht nur die Möglichkeit, das Datenmodell relational zu beschreiben. Eine andere Alternative ist im dritten Teil von Abbildung angegeben. Auch diese Relationalisierung beschreibt ein Dokument unserer "Mini-MucMedRep". Der Unterschied wird klar, wenn man betrachtet, dass auf einmal die Elementnamen der DTD nicht mehr als Attributnamen der Relation auftauchen, sondern als normale Werte in die Tabelle eingetragen werden. Es handelt sich hierbei um eine relationale Beschreibung der DTD und nicht ihres zugrunde liegenden Modells. Ob sie sich in Normalform [RDBMNORM] befindet, hängt von der Interpretation ab. Soll nur eine spezielle DTD relational abgebildet werden oder eine Menge unterschiedlicher DTD's, die den allgemeinen Designregeln der MucMedRep-DTD genügen? Im letzteren Fall befindet sich auch diese Darstellung in Normalform.
Bei dieser Form der Abbildung befindet man sich auf einer anderen Metaebene. Während sich das erstere relationale Modell und die XML-DTD auf gleicher Ebene befinden und das gleiche Modell beschreiben, beschreibt letzteres die XML-DTD. Das zweite Vorgehen entspricht dabei den heutigen Bemühungen alte medizinische Protokolle (HL7, EDIFACT) in XML zu beschreiben. Dabei werden auch nicht die zugrunde liegenden Modelle in XML beschrieben, sondern die Protokolle selbst in XML modelliert.
Für die Entwicklung einer Applikation, die XML-Dokumente relational speichert, stellt sich die Frage, welcher der beiden Ansätze verwendet werden soll. Hier wurde der Zweite gewählt. Der Grund dafür ist die größere Flexibilität. So können Änderungen (z.B. neue Attribute) im MucMedRep-Modell eingeführt werden, ohne das relationale Modell zu ändern. Es können auch verschiedene Versionen der MucMedRep in einer Datenbank gehalten werden, solange sich die Grundstruktur der DTD nicht ändert.
Die relationale Beschreibung wird in Anhang explizit angegeben. Sie ergibt sich in trivialer Weise, wenn man als weitere Spalten die Attributwerte der Elemente einfügt und bedenkt, das nach den Designrichtlinien in Kapitel die Anzahl der möglichen Attribute auf zwei begrenzt ist.
Es folgt nun das Mapping der MucMedRep-DTD auf IDL.

Eine Formulierung der MucMedRep-DTD in der Interface Definitionssprache IDL. Jede Instanz dieser DTD lässt sich eindeutig und verlustfrei auf die hier gegebene Struktur abbilden.

Dieses ergibt sich wesentlich unmittelbarer als das relationale Modell. Dies lässt sich auch dadurch verstehen, dass das zugrunde liegende Datenkonzept von IDL und XML relativ ähnlich ist. Eine mögliche Beschreibung ist in Abbildung angegeben. Die verwendete Zusammenfassung von ähnlichen Elementen in eigenen Strukturen hat dabei keine substanzielle Bedeutung und dient der besseren Darstellbarkeit der Datenstruktur. Die 1:n-Relationen werden dabei durch Sequenzen dargestellt. Die beiden Methoden " put " und " get " sind hierbei nur exemplarisch aufgeführt und ergeben sich natürlich nicht aus der DTD. Wenn man impliziert, dass nicht besetzte Elemente in XML mit dem Leerstring gleichzusetzen sind und gleiches für die in der IDL-Struktur nicht besetzten Elemente (mit Wert NULL) gilt, dann sind beide Darstellungen sogar in eineindeutiger Weise ineinander überführbar. Ansonsten bleibt es bei einer eindeutigen Abbildung von XML nach IDL. Das bedeutet, dass die XML-Repräsentation eine Untermenge der IDL-Repräsentation ist. Alle Instanzen der MucMedRep-DTD können in dieser IDL-Struktur beschrieben werden und daraus auch wieder rekonstruiert werden.

5.5 Transformationen

In diesem Abschnitt soll untersucht werde, inwieweit Dokumente, die mit der MucMedRep-DTD formuliert wurden, sich in andere, reportfähige medizinische Protokolle und Datenformate transformieren lassen und umgekehrt. Exakte Zahlen über die Verbreitung der unterschiedlichen Konzepte liegen nicht vor. Eine grobe Aufteilung lässt sich jedoch angeben. Das am weitesten verbreitete Konzept ist derzeit sicher die normale Textverarbeitung mit lokaler oder zentraler Datenspeicherung auf Filesystemebene. Bei strukturierten Ansätzen spielt im deutschen Raum neben proprietären Lösungen nur HL7 eine gewisse Rolle [ Diese Aussage beschränkt sich auf das Berichtswesen und sagt nichts über die Bedeutung von HL7 in anderen klinisch-medizinischen Bereichen. ] . Im radiologischen Bereich hat DICOM in den letzten Jahren eine weite Verbreitung beim Austausch von Bilddaten gefunden. Mit der Ergänzung 23 bietet DICOM jetzt auch die Möglichkeit innerhalb dieses Standards strukturierte Berichte zu beschreiben. Obwohl es derzeit noch keine Anwendungen gibt, ist dies der einzige Ansatz, der eine weitgehend strukturierte Berichterstattung ermöglicht und in ein einheitliches Datenmodell einbindet.
Deshalb sollen im folgenden die Transformationen in HL7, DICOM, und gängige Textverarbeitungssysteme betrachtet werden.
In HL7 werden die Berichte in Absatz 7.4.4 unter dem Stichwort Narrative Report behandelt. Die Frage, ob sich eine eineindeutige Abbildung von MucMedRep auf HL7 finden lässt, kann leicht mit nein beantwortet werden. Die augenfälligsten Gründe dafür sind, dass HL7 kein logisches Markup in formatierten Textelementen unterstützt (siehe Absatz ) und dass es kein differenziertes Urhebermodell besitzt, das in der MucMedRep mit den Elementen AUTHOR , WRITER und SIGN abgebildet wird. Mit diesen drei Elementen wird der in der Dokumentenerstellung wichtigen Arbeitsteilung Rechnung getragen. Es wird unterschieden, wer ein Dokument inhaltlich erzeugt, wer es formal erzeugt und wer es zu verantworten hat.
Nachdem klar ist, dass eine solche Abbildung nicht existiert, kann man versuchen, wie weit man sich einer annähern kann. Dabei wird im Folgenden das Dokument in thematische Teile unterteilt und die Abbildbarkeit dieser Teilbereiche untersucht:

Die Patientenzuordnung wird in der MucMedRep mit den Elementen PID , PSEX , PNAME und PDAT bechrieben. Diesen entspricht in HL7 das Patient Identifikation Segment (PID 3.3.2). Dieser Bereich ist eineindeutig abbildbar. Der einzige Unterschied besteht darin, dass in HL7 die Patienten-Identifikationsnummer zwingend vorgeschrieben ist.
Der Freitext wird in der MucMedRep mit den Elementen TEXTQ , TEXT und TEXTR beschrieben. Diese Felder können in HL7 mit einem Observation Result Segment (OBX 7.3.2) abgebildet werden. Als Observation Identifier kommen IMP (7.1.3.1 Diagnostic impressions) oder GDT (7.1.3.7 Gross or general description) in Frage. Die Abbildung eines Elements könnte dann unter Verwendung des Werttyps TX (Text) so aussehen:
OBX|3|TX| & GDT|1|Infiltrat in Projektion auf ...
Die Diagnosen (Element DIAG ) können mit dem Werttyp CE (Coded Element) als IMP (Diagnostic Impressions) abgebildet werden.
Referenzen auf z.B. Bilder (Element PIC ) werden mit dem Werttyp RP (Referenz Pointer) innerhalb eines OBX-Segments beschrieben:
OBX|4|RP|...
Der Absender (Element FROM... ) und die Adressaten (Element ADDRESS ) müssen in das OBX-Segment mit dem Werttyp AD (Address) eingepasst werden. Dabei ist die Unterstrukturierung der Werttypen im Falle des Absenders bei der MucMedRep höher, bei den Adressaten ist HL7 höher strukturiert. Die Art der Adresse wird von HL7 nicht definiert und muss über den Observation Identifier durch Konvention vereinbart werden.
Datumsangaben können in den zugehörigen OBX-Segmenten mitangegeben werden.
Die restlichen Elemente können am ehesten auf ein OBX-Segment abgebildet werden. Dabei verwendet man den TCM-Identifier (7.1.3.9 Technician comment), z.B.:
OBX|4|TX| & TCM^WRITER|1|spe

Mit diesen Abbildungsregeln lässt sich ein sinnvoller, unidirektionaler Datenexport nach HL7 realisieren, sie verdeutlichen aber auch die erheblich differenten Strukturen zwischen HL7's Narrative Report und einem klinischen Befundbericht, wie er von der MucMedRep dargestellt wird.
Das DICOM Supplement 23 fügt sich in die allgemeine Struktur des Datenmodells ein, wie es in Abb. dargestellt ist. So gibt es über einen Patienten mehrere Studien, die ihrerseits mehrere Serien enthalten können. Eine Serie setzt sich dabei aus Objekten zusammen. Das Supplement 23 definiert dabei einen neuen Typ an Objekten mit dem Namen Structured Reporting (SR). Ein solches SR-Objekt kann dabei wiederum mehrere sogenannte Findings enthalten, die dann auf einzelne Beobachtungen ( Observations ) verweisen können. Die Beobachtungen können verschiedene Ausformulierungen für Text, Audio, usw. annehmen. Innerhalb dieser 7-stufigen Objekthierarchie gibt es auf mehreren Ebenen Möglichkeiten, Verweise auf andere Objekte einzutragen. Neben dieser sehr tief strukturierten Modellierung sind auch die einzelnen Attribute der jeweiligen Objekte sehr detailliert ausformuliert. Ohne hier eine vollständige Aufzählung anzustreben, gibt es z.B. für den SR einen Interpretation Transcriber (Tag 4008,010A). Ein Bereich, der aber weitgehend ausgeklammert ist, scheint jedoch die Adresse zu sein. Sowohl für den Absender, als auch für den Adressaten gibt es nur Elemente, die allenfalls als Behelf dienen können ( Referring Physician ). DICOM kennt zwar multiple Möglichkeiten, Kommunikation zwischen Systemen zu beschreiben, ein Export auf andere, konventionelle Medien (Medienbruch) und ein Weitertransport oder eine Weiterverarbeitung sind aber konzeptionell nicht vorgesehen. Dies schränkt die Abbildungsmöglichkeiten auf einen unidirektionalen Export ein, wobei sich Patientenidentifikation und die eigentlichen Textteile problem- und entropielos auf DICOM-SR abbilden lassen.
Die im DICOM Supplement 23 beschriebene Möglichkeit, XML in SR einzubinden, bleibt zunächst unklar und ist in der gegenwärtigen Version [SUP23] vermutlich sogar fehlerhaft [ So wird in 3.10.107 von "Valid XML"-Dokumenten gesprochen, ohne dass an irgendeiner anderen Stelle über die Referenzierung der DTD gesprochen wird. Dies würde bedeuten, dass nur "standalone" XML Dokumente verwendet werden können? Oder sind vielleicht doch "wellformed XML"-Dokumente gemeint? ] .
Auf jede Form von Textverarbeitung kann die MucMedRep abgebildet werden, da es eines ihrer Designprinzipien ist, auf visuelle Darstellungsformen projeziert werden zu können. Ebenso klar ist aber auch, dass eine solche Abbildung niemals umkehrbar sein kann. Insbesondere geht bei diesem Vorgehen der Patientenbezug verloren.

5.6 Präsentation auf Papier

Solange es keine allgemein standardisierte und etablierte Datenkommunikation in der Medizin auf mindestens regionaler Ebene gibt, wird die strukturierte Datenübermittlung an der Grenze des Klinikums enden. Aber auch innerhalb einer Klinik sind meist die Strukturen nicht vorhanden, die für eine authentische, elektronische Dokumentenzustellung notwendig wären. Die rechtliche Seite von elektronischen Dokumenten wird in Deutschland ebenfalls frühestens im Laufe des Jahres 2000 geregelt. Das bedeutet, dass sowohl innerhalb der Klinik, als auch in der Kommunikation nach außen der Ausdruck auf Papier eine entscheidende Rolle spielt.
Über die Gestaltung des Layouts gibt es diverse Konventionen und DIN-Normen. In der hier beschriebenen Anwendung wurde im Wesentlichen das von der DIN vorgegebene Brieflayout übernommen und an einige lokal in der Abteilung bestehende Konventionen adaptiert. Zur Erstellung des Ausdrucks erzeugt ein XML-Prozess ein Ausgabeformat für das Programm LaTeX. Dieses erzeugt seinerseits dann das gewünschte Zielformat. Dies ist in den meisten Fällen Postscript, das so unmittelbar an entsprechende Drucker geschickt werden kann. Alternative, proprietäre Druckersteuerungssprachen sind aber bei Bedarf ebenso realisierbar.

Vorschlag für die Gestaltung eines Dokumentenformulars. Durch den Verzicht auf übliche Kopfzeilen lässt sich dieses Papier auch für Folgeseiten verwenden (kein Papierwechsel zwischen Seite 1 und 2). Es ist universeller einsetzbar, robust gegenüber personellen und organisatorischen Veränderungen und trotzdem durch das farbige Logo als Original erkennbar.

Um die Handhabung des eigentlichen Druckprozesses möglichst einfach zu gestalten, sollten einige Dinge beachtet werden. Bei den üblichen Briefpapieren sind meist große Teile von Absendername, Adresse, Telephon usw. vorgedruckt. Dies macht Sinn, solange unmittelbar mit der Schreibmaschine gearbeitet wird oder ein Computer als Speicherschreibmaschine (Textverarbeitung) verwendet wird. Sobald mit vom Computer erzeugten Ausdruckformaten gearbeitet wird, macht diese Art von vorgedruckten Briefköpfen keinen Sinn mehr, da das Briefformular sowieso einmal layoutet werden muss. Der zusätzliche Ausdruck von Absenderinformation lässt sich dabei nahezu ohne weitere Mehrarbeit durchführen. Hinzu kommen eine Reihe von Nachteilen bei vorgedruckten Briefbögen. Der gravierendste ist die Komplizierung des Druckprozesses bei mehrseitigen Dokumenten, da die Folgeseiten nicht auf das gleiche Papier gedruckt werden können wie die erste Seite. Dies führt zu höheren Kosten bei den Druckern, da zwei Druckschächte vorhanden sein müssen. Wenn der Drucker auch noch andere Formulare bedienen soll, kann es sein, dass man überhaupt nicht genügend Druckschächte bereitstellen kann und das Papier immer manuell gewechselt werden muss. Aber auch, wenn Druckermodelle mit ausreichender Anzahl an Papierzuführungsschächten zur Verfügung stehen, ist der Papierwechsel eine Quelle für Fehlbedienungen (falsches Formular im falschen Schacht) und erfordert zusätzliche Wartung (beide Schächte müssen immer mit Papier gefüllt sein). Dieser zusätzliche Aufwand bedeutet, dass die Person, die den Ausdruck initiiert, in unmittelbarer Nähe des Druckers sein muss, auf dem sie ausdruckt. Ein Ausdruck auf entfernten Druckern ist damit nicht sinnvoll möglich. Ein weiterer Nachteil solcher Formulare ist, dass jede Änderung im Briefkopf (Adresse, Telephon, Personen usw.) zur Notwendigkeit führt, neue Formulare zu erstellen.
Eine Alternative dazu wäre, nur noch auf Blankopapier auszudrucken. Dies ist ein Verfahren, das von manchen kleineren Firmen heute bereits verwendet wird. Bei größeren Institutionen besteht aber gegenüber einem solchen Vorgehen eine gewisse Hemmschwelle, da dadurch der "offizielle" Charakter eines solchen Dokuments verloren gehen könnte.
Ein sinnvoller Kompromiss könnte das in Abbildung vorgeschlagene Formular sein. Es trägt dem Bedürfnis nach einem speziellen Briefpapier Rechnung, ermöglicht aber gleichzeitig eine flexible Informationsgestaltung im Briefkopf und die Verwendung des gleichen Formulars für Titelblatt und Folgeblätter.

5.7 Fax

Das Faxlayout gleicht im Textteil im Prinzip dem eines normalen Briefes. Der Adressat steht jedoch nicht, wie beim DIN-Brief üblich, in einem eigenen Quadrat links oben auf der ersten Seite, sondern wird als eigenes Titelblatt getrennt übertragen. Dieses Titelblatt enthält zusätzlich üblicherweise auch noch Angaben über die Gesamtseitenzahl des Dokuments, die Faxnummer des Adressaten und eine Fax- und Telephonnummer für Rückmeldungen [ Weitere mögliche Angaben, die von der jeweiligen Dokumentenart abhängig sind z.B.: email-Adresse, Kontoverbindung usw.. ] .
Das Faxlayout wurde im Rahmen dieser Arbeit nicht weiter ausformuliert. Es werden zwar Faxe inzwischen als Dokumente juristisch anerkannt, jedoch werden in der Routine derzeit nur handschriftlich unterschriebene Befunde weitergereicht. Das Fax dient nur gelegentlich als Vorabinformation. In diesen Fällen wird das Fax von Hand vom normalen Drucklayout erzeugt.

6. Implementation und Realisation

	To err is human, to forgive, beyond the scope of the Operating System.

6.1 Entwicklungsumgebung

Als Entwicklungsumgebung kamen zwei handelsübliche PC's zum Einsatz. Diese waren mit AMD-K6 Prozessoren bestückt. Als Festplatten kamen EIDE-Platten zum Einsatz. Der erste Rechner lief unter 300 MHz mit 128 MB RAM, der zweite Rechner unter 450 MHz Taktfrequenz mit 256 MB RAM.
Auf diesen Rechnern ist Linux installiert mit der Kernelversion 2.0.36. Als Installationsquelle kam die Distribution der Firma SuSE in der Version 6.0 zum Einsatz. Als Compilerbasis dienen die mitgelieferten GNU-Werkzeuge [GNU] . Zusätzlich wurde die Originaldistribution von MySQL [MYSQL] in der Version 3.22.4 installiert. Als CORBA 2.0 konformer Object Request Broker (ORB) kommt MICO [MICO] in der Version 2.0.8 zum Einsatz.
Von allen verwendeten Werkzeugen und Bibliotheken ist der Quelltext verfügbar.

6.2 Implementation

Alle C++ Implementationen basieren auf einer Klasse, die aus dem Mapping der MucMedRep-IDL nach C++ entsteht. Da dies bedeutet, dass auch die nicht CORBA verwendenden Programmteile gegen die MICO-Bibliothek gebunden werden müssen, wurde überprüft, wie groß der Overhead ist, der sich durch dieses Vorgehen ergibt. Dazu wurde in einem kleinen Testprogramm die MucMedRep-Klasse instanziiert und zwei ihrer Felder mit kurzen Zeichenketten ausgefüllt. Dies wurde einmal mit dem IDL-generierten Quellkode durchgeführt. Zum Vergleich wurde ein Quellkode erzeugt, der die Strukturdeklarationen mit nicht ORB-spezifischen Datentypen (z.B. String an Stelle von CORBA::String_var ) formuliert. Beide Quellen wurden übersetzt und miteinander verglichen. Beide Versionen benötigten im Rahmen der Messgenauigkeit 15µs je Aufruf. Die entstandenen ausführbaren Programme differierten jedoch in der Größe um ca. 100 kBytes. Dies ist bei der Verwendung als CGI-Programm von Bedeutung. Große Programme stellen dabei einen Nachteil dar, da sie bei jedem CGI-Aufruf neu gestartet werden müssen. Dadurch ergibt sich ein Performancenachteil für die MICO-basierte Version. Der Vorteil einer durchgehenden Datenmodellierung für die Parser- und ORB-Teile wiegt das auf.
Die zweite zentrale Klasse bildet die Schnittstelle zum RDBMS und kapselt die relationale Sicht ab. Die Funktionen dieser Klasse stellen die eigentlichen Transaktionen dar. Sie verbergen explizite Locking-Logik und sorgen dafür, dass die einzelnen Tabellen systemweit konsistent geführt werden. Ein alternativer Ansatz wäre eine teilweise Verlagerung solcher Funktionalität auf das RDBMS. Dies hätte jedoch zwangläufig zu Herstellerabhängigkeiten geführt. Außerdem sollte der Wechsel vom relationalen zum objektorientierten Paradigma auf möglichst früher Ebene erfolgen, da die gesamte Konzeption objektorientiert ist. Die Transformation in eine relationale Sicht wird nur für Speicherzwecke durchgeführt. Die strenge Trennung zwischen Dokument, seinem Status und seiner Historie wird bis auf relationale Ebene durchgezogen und auch dort in getrennten Tabellen abgebildet. Ab der objektorientierten Ebene wird das Dokument in XML repräsentiert, Status und Historie stehen über Methoden und ihre Parameter zur Verfügung.
Als XML-Parser wird die libxml eingesetzt. Dieser ist ein nicht validierender Parser. Dies ist aber ausreichend, wenn man voraussetzt, dass der von Clients erzeugte Kode wohlgeformt und gültig ist. Für die ORB-Schnittstelle stellt sich das Problem sowieso nicht, da die Datenstruktur an sich bereits eine gültige MucMedRep-Instanz repräsentiert. Die kleineren Diskrepanzen, die sich aus nicht gesetzten Elementwerten (z.B. DAT ) oder fehlenden Attributwerten ergeben, können durch Definition von Defaultwerten umgangen werden. Falls ein Wert vorliegen muss, aber in der Struktur nicht gesetzt ist (Nullpointer), wird er implizit auf einen Leerstring gesetzt.
Für die anderen Fälle, die Instanzen in XML erzeugen ohne dass ihre Gültigkeit sichergestellt ist, steht mit xmlproc ein validierender XML-Parser in Python zur Verfügung.

6.3 Java-Client

In einer frühen Phase wurde 1996 eine erste Version der MucMedRep entwickelt. Sie war damals noch nicht als DTD formuliert, sondern war über ihre EBNF bzw. einen in YACC geschriebenen Parser definiert. Trotzdem stellen die damals definierten Dokumente, wenn sie mit einem entsprechenden Header und Trailer versehen werden, gültige Instanzen der MucMedRep-DTD dar.
Für diesen Dokumententyp wurde eine JAVA-Applikation entwickelt, die solche Ausgaben erzeugte. Die Anbindung erfolgte damals direkt an das Radiologie Informationssystem (RIS), wovon die Personal- und Untersuchungsdaten geholt werden und in dem die Befundungstexte abgelegt wurden. Seit Mitte 1997 werden mit diesem System ca. 30000 Befunde jährlich erzeugt, die sowohl in schriftlicher Form, als auch im Intranet abrufbar zur Verfügung stehen.
Dieses System war nicht als Dokumentensystem konzipiert. Es ist vielmehr ein strukturiertes Schreibsystem. Mit den erweiterten Möglichkeiten des hier formulierten Applikationsservers sollen sich Anwendungen jenseits des RIS erschließen. Außerdem ergeben sich weitere Vorteile aus der strukturierten Dokumentenverwaltung, wenn nicht nur der eigentliche Schreibprozess, sondern auch die Korrektur- und Bestätigungsschritte bis zum fertigen Befund unterstützt werden.

6.4 Word-Client

Dirk Heiss [DHEISS] konnte zeigen, dass sich bereits mit einfachen Mitteln (auf Makroebene) eine Art logisches Markup mit Word realisieren lässt. Die Anbindung an die Datenbank geschieht durch eine weitere Ebene. Dazu arbeitet der Client auf einer Filesystem-basierten Version des Dokuments. Auch Korrekturen werden auf dieser durchgeführt. Diese Dateien werden asynchron von Hintergrundsprozessen über die normalen Schnittstellen in den Datenbestand eingeführt.
Ein Sonderfall ist die Erzeugung eines neuen Dokuments. Da Word weder CORBA- noch CGI-fähig ist, bleibt als einzige Schnittstelle der ODBC-Treiber zur Datenbank. Hierbei bekommt aber der Client bei Neuanlage nicht ein bereits korrekt angefülltes Template mit Name, Datum usw., wie es vom normalen Applikationsserver generiert wird. Um diese Funktionalität muss sich das Makro in diesem Fall selbst kümmern.

6.5 Mengengerüst

Für die Auslegung diente das Zahlengerüst der Radiologie am Standort Innenstadt der Universitätsklinik der Ludwigs-Maximilians-Universität München . Diese zerfällt im Wesentlichen in 3 große Bereiche, die teilweise den einzelnen Kliniken zugeordnet sind, teilweise sich aus dem Standort bestimmter Großgeräte ergeben. Am größten Standort werden jährlich ca. 30000 Untersuchungen durchgeführt, an den folgenden zwei je ca. 15000. In den restlichen Bereichen fallen nochmals ca 10000 bis 15000 Untersuchungen an. Insgesamt entstehen in dem angestrebten Bereich aus über 70000 Untersuchungen mindestens ebenso viele Befunde. Aus diesen Rahmendaten ergab sich ein Mengengerüst von ca. 100000 Befunden pro Jahr. Das angestrebte System sollte dies bewältigen können sollte.

6.6 Effizienz und Speicherbedarf

Um den Resourcenbedarf des MucMedRep-Servers abzuschätzen, wurde ein Test durchgeführt. Dazu wurden in ein frisch installiertes System Testbefunde eingespielt. Diese Testbefunde enthielten keinen eigentlichen Text, nur den Absender und 16 weitere Elemente, die in jedem gängigen Befund vorkommen (PID, PNAME, PDAT, KEY, TEXT, SIGN, usw.). Dieser Befund wurde unter verschiedenen Versionsnummern 200 mal in das System eingespielt. Dann wurde der gesamte von dem RDBM-System MySQL im Datenbereich gemessene Speicherbedarf ermittelt. Es ergaben sich 248K Bytes. Dies bedeutet, dass der gesamte Overhead von XML-Kodierung und relationaler Abbildung bei ca. 1.5K Bytes je Dokument liegt. Setzt man dann ca. 5K Zeichen für einen Befund an, erhält man einen Gesamtspeicherbedarf je Dokument von 6.5K Bytes. Dabei entsprechen 5K Zeichen bei dem von uns gewählten Layout ca. eineinhalb Seiten Text, also einem eher ausführlicheren Befund. Vergleichbare Textdokumente mit herkömmlicher Textverarbeitung benötigen den vier- bis über zehnfachen Speicherbedarf.

6.7 Antwortzeiten

Um die Antwortzeit des Systems abzuschätzen, wurden auf einem Entwicklungssystem (AMD K6-2, 300 MHz, 128 MB Speicher) aus sechs Dokumenten unterschiedlicher Größe insgesamt 100000 Einträge in die Datenbank erzeugt. Dabei entstanden ca. 2.2 Millionen XML-Elementeinträge. In diese so gefüllte Datenbank wurde ein exakt 5000 Bytes großes MucMedRep-Dokument 1000 mal eingetragen. Dieses Testdokument enthält dabei 33 XML-Elemente auf oberster Ebene und ist in seiner Postscriptfassung zwei Seiten groß. Die durchschnittliche Zeit je Transaktion betrug dabei 143 ms. Miterfasst ist dabei jedesmal die Zeit zum Starten und Parsen des XML-Dokuments. Ein echter Netzverkehr wurde dabei jedoch nicht verursacht, so dass diese Zeit in der realen Anwendung noch dazu käme. Unter der Annahme einer realen Übertragungsrate von 100 KBits/sec kämen nochmals ca. 20 ms hinzu. Insgesamt beträgt die zu erwartende Zeit für den Speichervorgang eines großen Befundberichts weniger als 0.2 Sekunden. Wenn man berücksichtigt, dass auf Datenbankseite keinerlei Optimierungsmaßnahmen durchgeführt wurden, der Systemausbau mit Speicher-RAM gering war, die der Datenbank zugewiesenen Bufferbereiche der Standardeinstellung für kleine Datenvolumina entsprachen und die Speicherzeit erst ab ca. 50000 Dokumenten die 50ms Grenze überschritt, kann man davon ausgehen, dass diese Werte noch wesentlich unterboten werden können.
Unter den gleichen Bedingungen wurde der lesende Zugriff getestet. Dabei wurden 1000 Dokumente wahlfrei aus dem Bestand von 101000 gelesen. Dabei ergab sich eine durchschnittliche Zeit für die lesende Transaktion von 49 ms. Auch hier muß noch die Zeit für Netzübertragung hinzugerechnet werden.
Auch auf einem schwach dimensionierten System wie dem oben beschriebenen ergeben sich damit Zugriffs- und Speicherzeiten, die im normalen Betrieb nicht wahrnehmbar sind.

7. Diskussion

	For every complex problem, there is a solution that is simple, neat, and wrong.
	H. L. Mencken

Die Konzepte zum Aufbau einer computergestützten Dokumentation wurden im vorigen Kapitel vorgestellt. Hier soll zunächst auf die zugrunde liegenden Überlegungen eingegangen werden, die zur Aufstellung solcher Konzepte geführt haben. Man könnte in diesem Zusammenhang auch von Metakonzepten oder, dem Zeitgeist etwas näherliegend, dem zugrunde liegenden Paradigma sprechen.
Eine der großen Stärken von elektronischer Datenverarbeitung ist die beliebige und nahezu kostenlose Möglichkeit, Information zu vervielfachen. Das eröffnet die Möglichkeit, Informationen, die bei konventionellen Arbeitsabläufen oft an verschiedenen Stellen mehrfach, also redundant, erfasst und bearbeitet werden müssen, bei Einsatz computergestützter Methoden einfach von anderer Stelle zu übernehmen. Dies ist jedoch nur möglich, wenn die Daten in einer Form vorliegen, in der sie auch weiterverarbeitet werden können. Dies ist kein Problem einer konkreten Kodierung von Daten, also wie ein bestimmter Datensatz im Speicher eines Computers abgebildet wird, sondern ein Problem des Datenmodells. Ein Datenmodell beschreibt dabei die Abbildung der Realität, oder genauer eines Aspektes der Realität auf eine formale Beschreibung. Eine häufig verwendete Beschreibungsform ist die Abbildung auf ein relationales Datenmodell. Andere Formen sind hierarchische und objektorientierte Datenmodelle. Um gleiche Information in unterschiedlichen Kontexten verwenden zu können, ist es notwendig, dass die Modellierung der Information kompatibel ist. Da dies ein zentraler Punkt ist, der auch heute noch in vielen konkreten Planungen nicht beachtet wird, soll das Problem an einem einfachen Beispiel verdeutlicht werden.
Es soll die Beschreibung eines Namens betrachtet werden. Exotische Namensräume mit anderen Schriftsystemen wie z.B. im arabischen und asiatischem Raum werden dabei außer Acht gelassen. Es werden als Vereinfachung nur Namen betrachtet, die sich mit einem gängigen Zeichensatz, z.B. ISO-Latin-1, beschreiben lassen.
Der Name eines Patienten spielt bei nahezu jedem klinischen Arbeitsvorgang eine zentrale Rolle. In der Vor-IT-Zeit bedeutete das, dass bei jedem Dokumentationsvorgang der Name [ In der Praxis ist der Name allein kein ausreichendes Merkmal. Es werden weitere Informationen zur Beschreibung einer Person verwendet, z.B. Geburtsdatum, im amerikanischen Raum häufig die Sozialversicherungsnummer, uvm.. Das ASTM E31.12 Subkomittee hat in seinem Standard E1714 eine Anleitung für Kriterien eines eindeutigen Patientenschlüssels gegeben. ] von Hand geschrieben werden musste. Zeitweise wurden auch einfache Drucksysteme mit Schablonen verwendet. Eine IT-Lösung könnte jetzt den Namen nur einmal erfassen und sich bei jedem weiteren Vorgang auf diesen Namen mit einer Referenz beziehen. Dadurch sind große Synergieeffekte in Hinblick auf Effizienz und Qualität denkbar, die die Effekte des IT-Einsatzes an einer einzelnen Stelle weit überschreiten. Damit wäre die einheitliche (wenn auch nicht notwendigerweise richtige) Schreibweise eines Namens sichergestellt. Nun wird aber selbst ein so banales Datum wie ein Name in unterschiedlichen Verwendungen sehr unterschiedlich modelliert. In manchen Fällen werden Titel, Vornamen, Nachnamen in einer einzigen Zeichenkette zusammengefasst. Selbst relativ moderne Modelle wie der DICOM-Standard kennen nur einen gemeinsamen String für Namen und Vornamen. In Verwaltungssystemen werden Vor- und Nachname üblicherweise getrennt beschrieben. Will man die Anrede in einem Brief formulieren, steht der Familienname meist allein, evtl. um einen Titel ergänzt. In einem Adressfeld steht der Vorname vor dem Familiennamen, in Adresslisten wegen der alphabetischen Reihenfolge dahinter.
Das bedeutet, dass der Name nur dann an allen Stellen verwendet werden kann, wenn seine Modellierung ausreichend detailliert ist. Die Umsetzung verschiedener Kodierung z.B. von Unicode auf ASCII ist meist nicht das Problem, sondern eine Beschreibung zu finden, die für alle Anwendungen ausreichend ist.
Solche Probleme sind seit langem bekannt und haben zu dem Ansatz des Unternehmensweiten Datenmodells geführt. Das bedeutet, dass alle unternehmensweit verfügbaren Daten einheitlich beschrieben werden. Dies impliziert nicht die einmalige, redundanzfreie Speicherung eines Datums. Dies ist vielmehr ein Problem eines konkreten Systemdesigns, in das Faktoren wie Zuverlässigkeit und Zeitverhalten eingehen. Es bedeutet nur, dass die Beschreibungsform eines Namens im gesamten Unternehmen Klinik(um) einheitlich ist. In diesem Zusammenhang sollen zwei Beschreibungen bereits gleich genannt werden, wenn sie eineindeutig ineinander übergeführt werden können.
Ein reales Beispiel, in dem das (Meta-)Konzept des Unternehmensweiten Datenmodells schon früh erfolgreich umgesetzt werden konnte, ist der Schweizerische Bankverein [VETTER] .
Im klinischen Umfeld ist die Realität leider eine nahezu vollständig andere. Bei Planung von IT-Projekten werden Applikationen untersucht. In den Pflichtenheften steht, was die Applikation machen muss, welche Buttons dem Anwender zur Verfügung stehen müssen. Das zugrunde liegende Datenmodell wird als Sache des Softwareproduzenten betrachtet. Die Folgen sind die bekannten: Applikationen arbeiten nicht zusammen. Daten stehen nicht oder nicht in ausreichender Präzision zur Verfügung. Die erwünschten Synergieeffekte bleiben aus. Daten werden vielfach erfasst. Briefe und Befunde werden zwar meist am Computer geschrieben, das Vorgehen unterscheidet sich aber nicht vom Arbeiten an einer Schreibmaschine mit Korrekturfunktion. Ein Entwicklungssprung im Vergleich zum Zustand vor 40 Jahren ist nicht erkennbar.
Ein Versuch, unternehmensweit ein einheitliches Datenmodell zu etablieren, ist, ein einheitliches Softwareprodukt in allen Bereichen einzusetzen. Ein konkretes Problem dabei ist, dass es derzeit kein einziges Produkt gibt, das alle Bereiche eines Krankenhauses auch nur ausreichend abdeckt. Aber selbst unter der Annahme, dass es irgendwann die Software aus einer Hand gibt, die alles Benötigte leisten kann, gibt es bei diesem Vorgehen eine viel größere Gefahr. Die Unternehmensleitung verliert bei einem solchen Vorgehen die Kontrolle über die Beschreibung ihrer Geschäftsprozesse und damit im gewissen Maße auch die Kontrolle über die Prozesse selbt. Sie überlässt die Beschreibung von unternehmenskritischen Bereichen einer externen Firma, deren Interessen in naheliegender Weise andere sind als die eigenen. Man könnte sich nun theoretisch überlegen, den Softwarepartner durch Vertragswerk zu verpflichten, das verwendete Datenmodell offenzulegen und jederzeit an eigene Bedürfnisse anzupassen. Dem Autor ist jedoch kein einziges solches Vorgehen einer Klinik, eines Krankenhauses oder einer Abteilung bekannt. Auch ist die Praktikabilität eines solchen Verfahrens, das alle Eventualitäten abdecken muss, fraglich. Auch ob ein Softwareunternehmen zu solchen Verträgen bereit wäre, ist fraglich. Viele Softwarehäuser betrachten ihre Datenmodelle als Betriebsgeheimnisse und geben sie auch nicht an Lizenznehmer weiter. Selbst weltweit verbreitete Formate wie MS-Word werden nicht offiziell dokumentiert. Dies ist auch ein Beispiel dafür, wie das Interesse eines Softwarehauses, Programme zu verkaufen, dazu führt, dass Formate ständig geändert werden, was eine einheitliche Speicherung von Daten über einen Zeitraum von mehreren Jahren unmöglich macht.
Das dieser Arbeit zugrunde liegende Paradigma will diesem Trend entgegenwirken. Zentrales Thema ist die Beschreibung eines Datenmodells eines Befundes. Die Beschreibung erfolgte als XML-DTD. Welche Applikation auf diesem Datenmodell operiert, ist beliebig. Es konnte hier zwar gezeigt werden, dass sich eine solche Applikation auch mit geringen Mitteln selbst erstellen lässt, aber ab einer bestimmten Komplexität lohnt sich die Eigenentwicklung sicher nicht mehr. Das Datenmodell aber bleibt. Es lässt sich nicht austauschen, ohne Altbestände an Daten zu verlieren. Programme, Hardware, Protokolle, das sind alles Dinge, die sich in der gegenwärtigen IT-Landschaft rasant ändern. Was bleibt, sind die Daten und damit ihre Modellierung. Deshalb ist es auch wichtig, sich bei der Modellierung auf das Notwendigste zu beschränken. Ein zu hoher Detailreichtum schließt evtl. künftige Neuerungen aus oder behindert die Anbindung an bereits etablierte Datenmodelle (DICOM, HL7, SAP-ISH), da die Daten nicht in kompatibler Form zur Verfügung stehen. Entscheidend für eine effektiven IT-Einsatz ist die Definition eines Datenmodells, das den eigenen Bedürfnissen entspricht und die Kontrolle über dieses Modell, es sich zeitlich ändernden Anforderungen anzupassen. Die benötigten Applikationen können dann nach üblichen Methoden (Marktrecherche, Ausschreibung, Entwicklungsauftrag, ...) erworben werden. Wer beim Systemdesign in Applikationen und nicht in Modellen denkt, verkauft bei Anschaffung eines Softwaresystems die Kontrolle seiner betrieblichen Struktur.
Insgesamt sind die über zweijährigen produktiven Erfahrungen mit inhaltlich strukturierenden, also generisch kodierenden Dokumentensystemen sehr gut, obwohl der nicht unerhebliche Entwicklungsaufwand momentan noch ein Nachteil ist. Kommerzielle Angebote auf dem klinischen Markt sind uns derzeit nichts bekannt. Dies mag daher kommen, dass sich die Hersteller jahrelang bei SGML auf große und hochkomplexe Dokumente (Bücher, Manuale) konzentriert haben. Es spielt auch eine Rolle, dass XML als abgespeckte, schlankere und damit auch wesentlich einfacher zu handhabende Form von SGML noch relativ jung ist und derzeit hauptsächlich in reinen Inter-/Intranetanwendungen Verwendung findet.
Im Vergleich zwischen dem MucMedRep-Modell mit anderen strukturierten Dokumentansätzen wie DICOM-SR und HL7 fällt zunächst einmal den Umfangsunterschied auf. Das rührt daher, dass diese Standards viele Befundteile wesentlich weiter strukturieren als in der MucMedRep geschehen. Dieses Vorgehen bereitet eine Reihe Nachteile. Oft lassen sich gleiche Inhalte unterschiedlich abbilden, die Vielzahl der Elemente erlauben unterschiedliche Möglichkeiten der Interpretation. Damit geht ein Teil der Vorteile eines strukturierten Ansatzes wieder verloren. Wenn man nicht weiß, ob die gesuchte Diagnose in einem OBX-Segment mit CE-Feld oder in einem DG1-Segement kodiert ist, ist man wieder bei dem Punkt von unstrukturierten Textverarbeitungsprogrammen, wenn man versuchen muss, mit Parsern und auf dem Boden probabilistischer Prozesse die Information wiederzufinden.
Ein weiteres Problem der besprochenen Standards ist, dass sie nicht formal definiert sind. Der große Vorteil demgegenüber ist bei XML, dass man eine Grammatik (eine DTD) in einer formalen Sprache angeben kann, und an dieser jede Instanz überprüfen kann. Ein validierender Parser, der auch die Datenstruktur erfasst, ist bei HL7 und DICOM nicht formal aus dem Standardtext ableitbar.
Eine der Konsequenzen der strukturierten Befunderstellung war, dass seit 1997 alle derart erzeugten Befunde in der Intranetlösung zusammen mit Bildern und Laborwerten patienten- und auftragsbezogen dargestellt werden können. Es wird bisweilen behauptet, dass HTML das Internet erst möglich gemacht hat. So könnte man auch sagen, dass die MucMedRep das klinische Intranet des Klinikums Innenstadt der LMU München erst möglich gemacht hat.

8. Zusammenfassung

	I took a course in speed reading and was able to read War and Peace in twenty minutes. It's about Russia.
	Woody Allen

Generic Coding ist eine Form, Dokumente nur in ihrer logischen Struktur zu beschreiben. Die passende Visualisierung auf Papier oder Bildschirm wird der Software überlassen. XML bietet eine geeignete Möglichkeit, Dokumente generisch zu kodieren. Die MucMedRep-DTD ist dabei ein spezielles Datenmodell, das auf den klinischen, patientenbezogenen Routinebericht ausgerichtet ist. Sie ist so gewählt, dass ein großer Teil der Befunde, die im klinischen Alltag anfallen, mit ihr beschrieben werden kann. Sie ist erweiterbar auf andere Befundarten wie z.B. Arztbrief oder Laborbefund.
Die Beschreibung der MucMedRep-DTD ist durch die Verwendung von XML formal und strukturiert. Ihre Markup-Sprache ist unabhängig von bestimmten Protokollen oder bestimmten Softwareprodukten. Bei der Wahl des Protokolls stehen auf allen Ebenen des OSI-Schichtmodells Alternativen zur Wahl. Sie ist auf andere Paradigmen abbildbar, so z.B. relationales Modell, objektorientiertes Modell und procedurale Programmiersprachen.
Die Grenzen bestehender Standards in Bezug auf die Beschreibung von klinischen Berichten werden im Vergleich mit den Anforderungen der MucMedRep deutlich. Eine erste Realisierung konnte sich in einer über zweijährigen Routinephase als tragfähig erweisen.
Da im Zentrum dieser Arbeit das verwendete Datenmodell und nicht eine spezielle Applikation steht, kann eine Einbindung in ein unternehmensweites Datenmodell und IT-Konzept erreicht werden. Es entstehen keine einzelnen Applikationen eines sogenannten Personal Productivity Desktops , wie sie oft mit Textverarbeitungsprogrammen aus den gängigen Office-Paketen realisiert werden, die nachträglich in ein Gesamtkonzept eingepasst werden müssen, sofern dies überhaupt möglich ist. Da bereits in der Konzeptionsphase die Integration und Verträglichkeit mit bestehenden Datenmodellen berücksichtigt wird, werden MucMedRep-Applikationen automatisch Teil des sogenannten Enterprise Desktops , der einen einheitlichen Zugang zu allen klinikweiten Daten bietet.
Mit Generic Coding als Konzept und XML als entsprechendes Werkzeug besteht ein Lösungsansatz für die Verwaltung von hunderttausenden von Dokumenten.

Anhang:

9. RDBMS-Darstellung

	Old stancher! You remain.
	Samuel Becket: Endgame

Die vollständige relationale Beschreibung der MucMedRep wird in den Abbildungen und gezeigt. Diese Beschreibung ist die Erweiterung der in Abschnitt vorgestellten vereinfachten Dokumentenbeschreibung. Sie kann alle Elemente von gültigen MucMedRep -Dokumenten beschreiben. Zusätzlich sind noch einige Tabellen definiert, die die Verwaltung solcher Dokumente ermöglichen. Dazu gehören:

Eventlog: Es werden alle Aktionen, die an dem Datenbestand ausgeführt werden, protokolliert.
Historisierung: Die geschichtliche Entwicklung des Dokumenteninhalts bleibt gespeichert.
Diverse Statusinformationen.

10. Radiologischer Befund

	There exist tasks which cannot be done by more than 10 men or fewer than 100.
	Steele's Law

Die Möglichkeiten, die sich aus der MucMedRep ergeben, sollen an einem einfachen Beispiel gezeigt werden. In den Abbildungen und ist der Quelltext eines MucMedRep-Dokuments und eine mögliche Visualisierung dargestellt. Man beachte, dass auch auf einem nicht grafikfähigen Endgerät sich ein sinnvoller Befund aus der original XML-Datei erzeugen lässt. Dies ist bei der Postscriptdruckform im Allgemeinen nicht mehr möglich. Man sieht auch, dass sich nicht alle Elemente in der Darstellung wiederfinden, so ist z.B. das Element KEYWORDS in der Darstellung nicht mehr repräsentiert. Andererseits wird aus den Elementen PNAME , PDAT und DAT ein vollständiger Satz gebildet, der so im Quelltext nicht vorkommt. Das Element PSEX steuert dabei die Auswahl des Relativpronomens des Nebensatzes.

Eine Beispielinstanz der MucMedRep-DTD eines Radiologischen Befundes.

Der Beispielsbefund in seiner Postscriptvisualisierung.

11. Laborbefund

	Software: Formal evening attire for female computer analysts.

In Abb. wird ein Laborausdruck gezeigt, wie er derzeit im Zentrallabor am Standort Innenstadt Verwendung findet. In der jetzigen Form kann die MucMedRep-DTD einen solchen Befund noch nicht erzeugen, da ihr die entsprechenden Markups für Verfahren/Wert/Vorwert fehlen. Aber bereits jetzt liegen während der Erzeugung des Befundausdrucks die Daten intern in einer Form vor, die sich in eine erweiterte Form der MucMedRep-DTD überführen lassen. Dazu müßte ein Element definiert werden, mit dem sich Werte, Vorwerte und deren Beschreibung definieren lassen. Eine Wertbeschreibung könnte dann so aussehen:
< VALUE type="CRP" >
< VAL date="200001020344" > 7.0 < /VAL >
< VAL date="200001012356" > 6.5 < /VAL >
< NAME > C-Reaktives Protein < /NAME >
< NORM > < 5.0 < /NORM > < UNIT > g/l < /UNIT >
< /VALUE >
In Zukunft könnte so diese DTD die zentrale Kommunikationsplattform werden, über die patientenbezogene Daten ausgetauscht werden.

Der Laborbefund, wie er im Zentrallabor des Klinikums der LMU verwendet wird.

12. Die DTD dieses Dokuments

	Whenever people agree with me I always feel I must be wrong.
	Oscar Wilde

Schon früh in der Planungsphase dieser Arbeit war klar, dass auch dieser Text mit dem hier vorgestellten Instrumentarium erstellt werden sollte. Da sich das Thema dieser Arbeit mit Erzeugung und Verarbeitung von Dokumenten beschäftigt, es sich aber bei diesem Entstehungsprozess dieser Arbeit ebenfalls um die Erzeugung und Verarbeitung eines Dokuments handelt, war der Gedanke naheliegend. Ebene und Metaebene fallen teilweise zusammen. Zwar ist die Art dieses Dokuments in vielen Dingen anders als ein Befundbericht oder ein Arztbrief. Dennoch erscheint das Vorgehen sinnvoll, da es einen Hinweis auf die Robustheit der hier eingesetzten Verfahren geben kann. Wären die vorgestellten Konzepte zu schwach gewesen, könnten sie diese Zeilen nicht lesen.
Die Vorteile, die sich aus diesem Vorgehen ergaben, waren die problemlose Erzeugung unterschiedlicher Ausgabeformate (im Web und auf Papier) und einfacher Einsatz des Satzprogramms TeX, ohne sich mit seinen Eigenheiten auseinandersetzen zu müssen. Das Textlayout beruht auf dem book -Stil. Es wurden einige Anpassungen übernommen, die zur Erstellung meiner Diplomarbeit [DIPLOM] Verwendung gefunden hatten. So stehen z.B. Kapitelanfänge immer auf der rechten Seite. Die einführenden Mottos am Kapitelanfang, meist Zitate, die in losem Zusammenhang mit dem Kapitelinhalt stehen, werden in der Textausgabe nicht dargestellt. Sie stehen nur in der HTML-Sicht zur Verfügung. Der XML-Kode dieser Arbeit und die HTML-Sicht sind auch auf elektronischem Weg [MYWEB] verfügbar.

Ein Beispiel aus dem XML-Kode dieser Arbeit.

Als angenehm wurde die Möglichkeit empfunden, Kommentare in den Text einzustreuen. Dies erlaubt es, vorläufige Ideen und Zitate in den Text einzufügen, ohne die bestehende Struktur zu beschädigen. Das gleiche gilt für Zitate in Originalsprache, die so im Quelltext neben ihrer Übersetzung stehen bleiben können und bei Korrekturen jederzeit zur Verfügung stehen. Der Idee der generischen Informationsrepräsentation hätte die Erweiterung der DTD um ein Korrekturelement eher entsprochen. In diesem Korrekturelement könnten dann solche Informationen untergebracht werden, die in einem speziellen Korrekturausdruck miterscheinen, in der Endfassung jedoch unsichtbar sind. Im Rahmen dieser Arbeit wurde darauf verzichtet. Sollte diese DTD jedoch wiederverwendet werden, wäre ein derartiges Vorgehen sehr empfehlenswert.

Die vollständige Formulierung der Document Type Definition, mit der dieser Text erstellt wurde.

Die Docu-DTD erlaubt keine vollständig generische Formulierung dieser Arbeit, da das Grafikformat darstellungsabhängig ist.
Alle Referenzierungen erfolgen im Quelltext symbolisch und werden bei der Visualisierung adäquat umgesetzt. Das bedeutet, dass in Textformaten Referenznummern erzeugt und angegeben werden; im HTML-Format werden Hyperlinks gesetzt.
Die Grafiken und Zeichnungen wurden hauptsächlich mit dem Programm xfig erstellt. Von dort wurden sie für die Druckausgabe in Embeded Postscript Dateien umgewandelt. Für die HTML-Visualisierung wurde aus diesen Dateien Rastergrafiken im GIF-Format erzeugt. Die Umwandlung von Vektorgrafiken in Rasterbilder stellt immer einen Kompromiss dar. Deshalb wurden die Skalierungsparameter für die Umwandlung einer jeden Grafik von Hand ermittelt.
Die Bibliographie wird alphabetisch bezüglich des Erstautors geordnet. Bei Quellen ohne Autor wird nach dem Ursprung (BSRC) sortiert. Diese Funktionalität wird durch einen kleinen getrennten Parser realisiert.

Verzeichnis der Akronyme:

ACH	Association for Computing in the Humanities
ACL	Association for Computational Linguistics
ACR/NEMA	American College of Radiology / National Electrical Manufacturing Asociation
ALLC	Association for Literary and Linguistic Computing
AML	Astronomical Markup Language
ANSI	American National Standards Institute
ASCII	American Standard Code for Information Interchange
ASTM	American Society for Testing and Materials
AWT	Abstract Window Toolkit
ATA	Air Transport Association of America
CERN	Conseil Européen pour la Recherche Nucléaire
CGI	Common Gateway Interface
CML	Chemical Markup Language
CORBA	Common Request Broker Architecture
CORE	Chemistry Online Retrieval Experiment
CSA	Client Server Architektur
CSS	Cascading Style Sheets
DBMS	Datenbank Management System
DCOM	Distributed Component Object Model
DICOM	Digital Imaging and Communications in Medicine
DIN	Deutsche Industrie-Norm
DTD	Document Type Definition
DSSSL	Document Style Semantic and Specification Language
DTP	Desk Top Publishing
EBCDIC	Extended Binary Coded Decimal Information Code
EBNF	Erweiterte Backus Naur Form
ECMA	European Computer Manufacturer's Association
EDI	Elektronic Data Interchange
EDIFACT	Electronic Data Interchange For Administration, Commerce and Transport
ER	Entity Relationship
GML	Generalized Markup Language
GUI	Graphic User Interface
GNU	GNU is not UNIX
HISPP	Health Informatics Standards Planning Panel
HL7	Health Level Seven
HTML	Hypertext Markup Language
HTTP	HyperText TransportProtokoll
IDL	Interface Definition Language
ICD	International Classification of Disease
IEEE	Institute of Electrical and Electronic Engineers
ISO	International Standards Organization
IT	Informations Technologie
KIS	Klinik Informations System
MD5	Message Digest 5
MEDIX	Medical Data Interchange Standard
MSDS	Message Standards Developers Subcomittee
NCPDP	National Council of Prescription Drug Programs
ODA	Office Document Architecture
ODBC	Open DataBase Connectivity
ODIF	Office Document Interchange Format
OEB	Open eBook
OMG	Object Managment Group
ORB	Object Request Broker
OSI	Open Systems Interconnect
PI	Processing Instructions
RDBMS	Relationales DBMS
RFC	Request For Comments
RIF	Railroad Industry Forum
RIP	Raster Image Processor
RIS	Radiologie Informations System
RMI	Remote Method Invokation
RTF	Rich Text Format
SGML	Standard Generalized Markup Language
SMTP	Send Mail Transfer Protokoll
SNOMED	Systematized Nomenclature of Human and Veterinary Medicine
SQL	Structured Query Language
SR	Structured Reporting
SSML	Speech Synthesis Markup Language
TCP/IP	Transmission Control Protocol / Internet Protocol
TEI	Text Encoding Initiative
XML	Extensible Markup Language
XSL	Extensible Stylesheet Language
XSLT	XSL Transformations
UCS	Universal Character Set
UML	Unified Medical Language
UTF	UCS Transformation Format
YACC	Yet Another Compiler Compiler

Bibliographie:

Digital Imaging and Communications in Medicine, Supplement 23: Structured Reporting ACR-NEMA DICOM Frozen Draft
DICOM ACR-NEMA DICOM Version 3.0
Database Language SQL2 ANSI X3.135
Standard Specification for Transferring Clinical Observations Between Independent Systems ASTM E1238 Subcommitte E31.11
A Standard Guide for Description of Reservation/Registration-A/D/T Systems for Automated Patient Care Information Systems ASTM E1239 Subcommitte E31.14
A Standard Spezification for Transferring Information Between Clinical Instruments and Computer Systems ASTM E1394 Subcommitte E31.14
Standard for Electronic Manuscript Preparation and Markup Association of American Publishers, Electronic Manuscript Series
SSML Project Centre of Speech Technology Research, University of Edingburgh
Chemistry Online Retieval Experiment Cornell University
Health Level Seven HL7 Version 2.1
Standard for Scheme Programming Language IEEE 1178-1990, ISBN 1-55937-125-0
Electronic data interchange for administration, commerce and transport (EDIFACT) ISO TC 154
Code for the representation of names of languages / Alpha-3 code ISO 639-1/2
US-ASCII. Coded Character Set - 7-Bit American Standard Code for Information Interchange ISO 646, Standard ANSI X3.4-1968
Code for the representation of names of countries ISO 3166
Information Interchange-Representation of Human Sexes ISO 5218 - Information Interchange
Information Interchange-Representation of Dates and Times ISO-8601 - Information Interchange
Office Document Architecture (ODA) ISO-8613 - Information Processing
8-bit Single-Byte Coded Graphic Character Sets - Part 1: Latin Alphabet No. 1 ISO-8859 - Information Processing
Text and Office Systems -- Standard Generalized Markup Language (SGML) ISO/IEC 8879
Database Language SQL ISO/IEC 9075
UN/Edifact ISO/IEC 9735
Text and office systems - Document Style Semantics and Specification Language (DSSSL) ISO/IEC 10179
Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane. ISO/IEC 10646
Hypermedia/Time-based Structuring Language (HyTime). ISO/IEC 10744
Interface Definition Language (IDL) ISO/IEC 14750
The Common Object Request Broker: Architecture and Specification OMG TC Document Number 91-12-01 Revision 1.1
GNU Open Software Foundation http:///www.gnu.org
The Unicode Consortium. The Unicode Standard: Version 2.0. Reading, Mass.: Addison-Wesley Developers Press
Data Interchange Standard Standard ANSI ASC X12
MySQL Database Server TCX, Schweden http://www.tcx.se
Elektronisches Literaturverzeichnis - Informatik für Sehgeschädigte TU Dresden
National Council for Prescription Drug Programs Telecommunication Standard Format, Version 3, Release 2
Alschuler Liora, Bidgood Dean, Biron Paul, e.a.: Patient Record Architecture HL7 Document, DRAFT
Alvestrand H.: Tags for the Identification of Languages RFC 1766, UNINETT
Berners-Lee T., Connolly D.: Hypertext Markup Language Specifications - 2.0 RFC 1866 http://www.w3.org/hypertext/WWW/MarkUp/html-spec/html-spec_2.html
Berners-Lee T.J., Cailliau R., Groff J-F., Pollermann B.: World-Wide Web: An Information Infrastructure for High-Energy Phsyics CERN, Presented at "Articicial Inteligence and Software Engineering for High Energy Physics" in La Londe, France
Bidgood W. Dean (Editor), Wayne R. Tracy: ANSI HISPP MSDS: Common Data Types Health Informatics Standards Planning Panel, Message Standards Developers Subcommitee
Bos Bert, Wium Lie Håkon, Lilley Chris, Jacobs Ian: Cascading Style Sheets, level 2 (CSS2) Specification World Wide Web Consortium. http://www.w3.org/TR/REC-CSS2
Boyer John, Bray Tim, Gordon Maureen: Extensible Forms Description Language (XFDL) 4.0 World Wide Web Consortium. Initial Draft. http://www.w3.org/TR/NOTE-XFDL
Bray Tim, Hollander Dave, Layman Andrew: Namespaces in XML World Wide Web Consortium. http://www.w3.org/TR/REC-xml-names
Bray Tim, Paoli Jean, Sperberg-McQueen C.M.: HTML 4.0 Specification World Wide Web Consortium. http://www.w3.org/TR/REC-html40
Bray Tim, Paoli Jean, Sperberg-McQueen C.M.: Extensible Markup Language (XML) 1.0 Specification World Wide Web Consortium. http://www.w3.org/TR/REC-xml
Clark James, Deach Stephen: Extensible Stylesheet Language (XSL) World Wide Web Consortium. Working Draft. http://www.w3.org/TR/REC-xsl
Codd E.F.: Further normalization of the relational model Data Base Systems, Courant computer science symposium 6
Date C.J., Darwen H.: A Guide to the SQL Standard Addison-Wesley Publishing Company, U.S.A.
Della Mea Vincenzo, Roberto Vito: HTML Generation and Semantic Markup for Telepathology Fifth International World Wide Web Conference
Drosdowski G. (Hrsg.): Duden, Rechtschreibung der deutschen Sprache Dudenverlag, ISBN: 3-411-04011-4
Endres S.P.: Führung von Experimenten zur Ertragsvorhersage für Solaranlagen Diplomarbeit Sektion Physik der LMU München
Endres S.P.: MucMedRep Homepage /
Ensign Chet: Sgml : The Billion Dollar Secret Prentice Hall Computer Books; ISBN: 0132267055
Farley J.: Java Distributed Computing O'Reilly, ISBN 1-56592-206-9
Fionn Murtagh, Damien Guillaume: Distributed Information Search and Retrieval for Astronomical Resource Discovery and Data Mining LISA III Conference
Goldfarb C.F., Mosher E.J., Peterson T.I.: An Online System for Integrated Textprocessing Proceedings of the American Society for Information Services, 7, 147-150
Goldfarb C.F.: The SGML Handbook Oxford University Press
Harrington J.J.: A Standard for Open Systems Medical Data Interchange (MEDIX) IEEE P1157
Heiss D.: Logisches Markup mit Word unveröffentlicht /
Hopcroft J.E., Ullman J.D.: Einführung in die Automatentheorie, Formale Sprachen und Komplexitätstheorie Addison-Weseley
Ishida Richard: Non-Latin Writing Systems: Characteristics and Impacts on Multinational Product Design. 9. International Unicode Konferenz, Tutorials, C1/C2
Knuth Donald E.: Literate Programming Center for the Study Of Language and Information, Stanford
Krol Ed: The Whole INTERNET User's Guide and Catalog Associates. ISBN 1-56592-025-2.
Langendoen, Terence D., Simons Gary F.: A Rationale for the TEI Recommendations for Feature-Structure Markup.
Lie H., Bos B., Lilley C.: The text/css Media Type RFC 2318, W3C
Maler Eve, El Andaloussi Jeanne: Developing SGML DTDs : From Text to Model to Markup Prentice Hall; ISBN: 0133098818
Murray-Rust Peter, Rzepa Henry: Chemical Markup, XML and the WWW, Part I: Basic principles J.Chem.Inf.Comp.Sci
Murray-Rust Peter: The complete chemical E-publication Abs.Papers Amer.Chem.Soc. Vol.216, pp.33-
Murtagh F.D.: The technologies which underpin electronic publishing A. Heck, Ed., Electronic Publishing for Physics and Astronomy, Kluwer, pp. 31-40.
Nelson, T.H.: Getting it out of our system Thomson Books, Washington D.C., 191-210
Ousterhout J. K.: Tcl und Tk Addison Wesley, ISBN 3-89319-793-1 http://www.scriptics.com
Nussbacher H.: Handling of Bi-directional Texts in MIME RFC 1556, Israeli Inter-University
Paoli J.: Creating SGML objects for End-Users - Establishing SGML in an interactive world Proceedings of SGML 94 , GCA, ed., pp. 323-333
Potash Steve: The Electronic Book Exchange System EBX Version 0.5 EBX Working Group
Potash Steve: Open eBook Initiative: A Common Denominator For Electronic Publishers Electronic Book 99, Second Annual Workshop by National Institute of Standards and Technology, Gaithersburg, Maryland
Raggett Dave, Boumphrey Frank, Altheim Murray, Wugofski Ted: Reformulating HTML in XML World Wide Web Consortium. http://www.w3.org/TR/WD-html-in-xml
Raggett Dave: A Review of the HTML+ Document Format First International Conference on the World-Wide Web
Rivest R.: The MD5 Message-Digest Algorithm RFC 1321, MIT Laboratory for Computer Science and RSA Data Security
Römer Kay: Mico Is Corba, CORBA 2.0 Implementation Universität Frankfurt, FB Informatik http://www.vsb.cs.uni-frankfurt.de/~mico
Rössler B., Schlieper H.: UN/EDIFACT Organisation und Ansprechpartner in Deutschland und Westeuropa Normenausschuß Bürowesen, DIN
Roisin C., Vatton I.: Formatting Structured Documents Rapport de Recherche, INRIA
Rossum Guido van: Glue It All Together With Python Position paper for the OMG-DARPA-MCC Workshop on Compositional Software Architecture in Monterey, California
Rousseau B., M.Ruggier M.: Writing Documents For Paper And WWW: A strategy based on FrameMaker and WebMaker First International Conference on the World-Wide Web
Sakamoto N., Ohe K., Yoshihara H. et al.: Medical Markup, Language (MML)
Simonsen K.: Character Mnemonics and Character Sets RFC 1345, Rationel Almen Planlaegning, Rationel Almen Planlaegning
Smish J.B, Weiss S.F: An Overview of Hypertext Communications of the ACM, Vol 31, No. 7
Sperberg-McQueen C.M., Goldstein Robert F.: HTML to the Max A Manifesto for Adding SGML Intelligence to the World-Wide Web http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/Autools/sperberg-mcqueen/sperberg.html
Spinellis D.: Greek Character Encoding for Electronic Mail Messages RFC 1947, SENA S.A.
Stallman R.M.: EMACS Manual for ITS users Artificial Lab memo 554
Stephenson Jon, von Tetzchner: Converting formatted Documents to HTML First International Conference on the World-Wide Web
Thompson Henry S.: xslj: An XSL to DSSSL Translator HCRC, University of Edinburgh
Travis Brian E., Waldt D.C.: The Sgml Implementation Guide : A Blueprint for Sgml Migration Springer Verlag; ISBN: 0387577300
Vetter Max: Aufbau betrieblicher Informationssysteme Teubner Stuttgart, ISBN 3-519-12495-5
Vinoski Steve: Distributed Object Computing With CORBA C++ Report magazine
Wahl Mark, Kille Steve, Howes Tim: UTF-8 String Representation of Distinguished Names Request for Comments 2253
Wall L., Schwartz R.L.: Programming Perl Assocaites
Walsh L., Norman, Muellner: DocBook in a Nutshell Associates, Inc, Sebastopol, CA
Williams Nick, Wilkinson Tim: Experiences With A WYSIWYG Editor for HTML First International Conference on the World-Wide Web
Yergeau F.: UTF-8, A Transformation Format of ISO 10646 RFC 2279, Alis Technologies