Veränderung der Dokumentation in der klinischen Forschung durch XML, EDC und CDISC-Standards

Inhaltsverzeichnis

Abkürzungsverzeichnis

Abbildungsverzeichnis

Danksagung

1. Zielstellung und Aufbau der Diplomarbeit
1.1 Zusammenfassung (Deutsch)
1.2 Summary (English)

2 Einführung in XML
2.1 Hintergrund: Entstehung und Nutzen von XML
2.1.1 Wandlung des Datenaustauschs im Internet
2.1.2 Ein einführendes Beispiel-Szenario
2.1.3 Was HTML leistet
2.1.4 Was HTML nicht leistet
2.1.5 Idee und Entstehung von XML
2.1.6 Charakteristische Eigenschaften und Vorteile von XML
2.1.7 Anwendungsbereiche von XML
2.2 Codierung: Erstellung & Weiterverarbeitung von XML-Dokumenten
2.2.1 Der Aufbau von XML-Dokumenten
2.2.2 Definition von eigenen Tags in XML-DTD’s
2.2.3 Kooperation und Einbindung fremder DTD’s
2.2.4 Validierung von Daten in XML
2.2.5 Darstellung von XML-Dokumenten
2.2.6 Datenabfrage in XML-Dokumenten und Datenbanken
2.2.7 XML-Datenaustausch in Netzen
2.2.8 XML-Editoren und Publikationsumgebungen
2.3 Ausblick: Anwendungen & Verbreitung von XML im E-Business
2.3.1 Der Nutzen von Standards im Allgemeinen
2.3.2 Vision und Nutzen von XML als Standard im E-Business
2.3.3 Einflussfaktoren auf die Verbreitung von XML-Standards
2.3.4 Aussichtsreiche XML-Standardisierungsinitiativen im E-Business

3 Einführung in die klinische Forschung und den Pharmamarkt
3.1 Einführung in die klinische Forschung
3.1.1 Zweck der klinischen Forschung
3.1.2 Ablauf und Phasenmodell der klinischen Prüfung
3.1.3 Beteiligte Institutionen und Daten-Management
3.1.4 Grundsätzliche rechtliche und ethische Rahmenbedingungen
3.1.5 Die Rolle der Behörden und der Zulassungsantrag
3.2 Kosten und Erträge der Arzneimittelentwicklung
3.2.1 Kennzahlen der deutschen Pharmaindustrie und des Marktes im weltweiten Vergleich
3.2.2 Unternehmenslandschaft und Struktur der Pharmabranche
3.2.3 Dauer und Kosten der Arzneimittelentwicklung
3.2.4 Rationalisierungspotentiale durch standardisierte elektronische Datenerfassung

4 Das Clinical Data Interchange Standards Consortium (CDISC)
4.1 Das CDISC-Projekt
4.1.1 Idee, Herausforderung und Chancen
4.1.2 Die Entstehung von CDISC und die Rolle von Konsortien
4.1.3 Aufbauorganisation und CDISC-Mitglieder
4.1.4 Die CDISC-Internetseite als Kommunikations-Portal
4.1.5 Evolution der Datenerfassung in der klinischen Forschung
4.1.6 Der Lösungsansatz und die Datenstandards von CDISC
4.1.7 Aktueller Stand der Modelle (März 2004) und Ausblick
4.2 Akzeptanz von CDISC in der Branche
4.2.1 CDISC in der Welt der Standards und Richtlinien
4.2.2 Die Rolle von CDISC bei den Behörden
4.2.3 Strategische Handlungsalternativen der Unternehmen
4.2.4 Haltung der Unternehmen zu EDC und zu CDISC
4.2.5 Strategie von CDISC zur weiteren Expansion

5 Der deutsche Bildungsmarkt für die klinische Forschung
5.1 Spezieller Ausbildungsbedarf in der klinischen Forschung
5.1.1 Von veränderten Prozessen zu veränderten Qualifikationsanforderungen
5.1.2 Versuch und Problematik der Quantifizierung des Bildungsbedarfs
5.1.3 Stellungnahmen, Konkretisierungen und weitere Indikatoren des Bildungsbedarfs
5.2 Die klassischen Ausbildungsangebote der Hochschulen
5.2.1 Relevanz der klassischen Studiengänge für die Arzneimittelforschung
5.2.2 Studiengang MEDIZIN
5.2.3 Studiengang Pharmazie
5.2.4 Studiengang Medizinische Informatik
5.3 Die erweiterten Ausbildungsangebote der Hochschulen
5.3.1 Tendenzen im Hochschulwesen
5.3.2 Aufbaustudiengang Pharmazeutische Medizin
5.3.3 Master-Studiengang Clinical Trial Management
5.3.4 Studiengang Medizinische Dokumentation und Informatik
5.3.5 Aufbaustudiengang Drug Regulatory Affairs
5.3.6 Postgraduelle Ausbildung BIOMETRIE
5.4 Alternative Ausbildungsangebote
5.4.1 Tendenzen im privaten Bildungsmarkt
5.4.2 KKS-Fortbildung Arzt für Klinische Studien
5.4.3 PAREXEL Fortbildung Klinischer Monitor & Datenmanager
5.4.4 PAREXEL Fortbildung Klinischer DB-manager & SAS-Programmierer
5.4.5 KKS- Fortbildung Study Nurse (Studienassistent/in im Prüfzentrum)
5.4.6 KKS- Fortbildung Klinische Evaluation (für Studienleiter)
5.4.7 PROFIL GmbH Fortbildung Fachkraft für Klinisches Monitoring
5.4.8 Exemplarische Intensivkursangebote und Seminare

6 Vorteile und Ansätze eines E-Learning gestützten Schulungsangebotes
6.1 Nutzen des E-Learning
6.1.1 Einführung und Erläuterung der Begriffe E-Learning, Blended Learning, Lernplattform
6.1.2 Vorteile und Einsparungspotentiale durch E-Learning
6.1.3 Besondere Eignung des E-Learning für Schulungen in der klinischen Forschung
6.1.4 Ein beispielhaftes E-Learning gestütztes Schulungsangebot
6.2 Ansatzpunkte zur Angebotsplanung für E-Learning-Anbieter
6.2.1 Mögliche Formen des Bildungsangebotes
6.2.2 Kosten des Angebotes, Marktpreise und Margen
6.2.3 Möglichkeiten der Kooperation und finanziellen Förderung

7 Schlussbemerkung

V. Quellenverzeichnis

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

Abbildung 2.1.3-1: Beschreibung von Daten durch Tags in HTML

Abbildung 2.2.1-1: Beschreibung des Inhalts durch Tags in XML

Abbildung 2.2.1-2: Beschreibung des Layouts durch Tags in HTML

Abbildung 2.2.2-1: Definition von XML-Tags in einer DTD

Abbildung 2.2.3-1: Einbinden einer externen DTD

Abbildung 2.2.3-2: Definition von Elementen innerhalb eines XML-Dokumentes

Abbildung 2.2.3-3: Einführung von Namensräumen zur Nutzung mehrerer DTD’s

Abbildung 2.2.5-1: Die drei Komponenten eines Dokumentes

Abbildung 2.2.5-2: Transformation von XML nach HTML durch XSLT

Abbildung 2.2.7-1: Auszug aus einem XML-RPC-Quelltext

Abbildung 2.2.7-2: Auszug aus einem JAVA-Quelltext in Verbindung mit XML-RPC

Abbildung 2.2.8-1: Screenshot eines XML-Quelltextes mit eingebundener DTD in EMACS

Abbildung 2.2.8-2: Screenshot aus dem Cocoon Publishing Framework

Abbildung 2.3.2-1: Schematische Darstellung von Informations- und Warenflüssen

Abbildung 3.1.2-1: Phasen der klinischen Prüfung

Abbildung 3.1.3-1: An klinischen Studien beteiligte Institutionen

Abbildung 3.1.5-1: Internationaler Vergleich der Zulassungsbehörden

Abbildung 3.2.1-1: Gesamtumsatz im Arzneimittelmarkt weltweit

Abbildung 3.2.1-2: Anteile am weltweiten Umsatz im Arzneimittelmarkt

Abbildung 3.2.1-3: Arzneimittelumsatz pro Kopf

Abbildung 3.2.1-4: Entwicklung des Arzneimittelumsatz pro Kopf

Abbildung 3.2.1-5: Entwicklung des Umsatz in In- und Ausland

Abbildung 3.2.1-6: Entwicklung der F&E-Ausgaben weltweit

Abbildung 3.2.1-7: Anteile an den F&E-Ausgaben

Abbildung 3.2.1-8: Nettowertschöpfung pro Beschäftigter im Jahr 2000

Abbildung 3.2.2-1: Anteile der Betriebe nach Beschäftigten

Abbildung 3.2.2-2: Anteile am Produktions-wert der Betriebe nach Beschäftigten

Abbildung 3.2.3-2: Wachstum der F&E-Gesamtkosten pro Arzneimittel

Abbildung 3.2.4-1: Zu erwartende Reduzierung der Bearbeitungszeiten

Abbildung 3.2.4-1: Einsatz von EDC in klinischen Studien

Abbildung 4.1.1-1: Vereinheitlichung der Schnittstellen durch CDISC-Standards

Abbildung 4.1.3-1: Organisationsstruktur und Arbeitsgruppen von CDISC

Abbildung 4.1.4-1: Screenshot der CDISC-Internetseite

Abbildung 4.1.5-1: Vom Papier zum hoch strukturierten Dokumentformat

Abbildung 4.1.6-1: Bisheriger Prozess der Datenübertragung

Abbildung 4.1.6-2: Nahtloser Datenfluss vom Patient bis zum Reviewer

Abbildung 4.1.7-1: Quelltextauszug mit Metadaten aus dem ODM

Abbildung 4.2.1-1: Wo steht CDISC in der Welt der Standards?

Abbildung 4.2.4-1: Anteil der Studien die EDC nutzen / voraussichtlich nutzen werden

Abbildung 4.2.4-2: Anteil der Sponsoren für die EDC ein Hauptstrategieinstrument ist

Abbildung 4.2.4-3: Bedeutung von Standards für einen effizienten Datenaustausch

Abbildung 4.2.4-4: Verwendung von CDISC-Standards (zum Zeitpunkt der Umfrage)

Abbildung 5.1.3-1: Bildungsinhalte des IFAPP

Abbildung 6.1.1-1: Entwicklung der Anteile verschiedener Lernformen

Abbildung 6.1.2-1: Kostensenkung als wichtigster Grund für den Einsatz von E-Learning

Abbildung 6.1.3-1: Anwendungen zur fallbasierten und problemorientierten Wissensvermittlung

Abbildung 6.1.4-1: Aufbau der Ausbildung

Danksagung

Die vorliegende Diplomarbeit wurde an der Teles European Internet Academy (TEIA) AG sowie an der Technischen Fachhochschule (TFH) Berlin erstellt und von verschiedenen, sowohl internen als auch externen Personen, begleitet, für deren Unterstützung ich mich an dieser Stelle herzlich bedanken möchte:

Herr Professor Dr. Faehling leitete seitens der TFH Berlin als betreuender Professor diese Diplomarbeit. Als Mitinitiator und Leiter des jüngst angebotenen Studiengangs Clinical Trial Management waren sein fachspezifisches Wissen und seine Ratschläge sehr hilfreich.

Auf Seiten der TEIA AG ermöglichte Eva Maria Paaß-Nielsen als leitender Vorstand diese Diplomarbeit. Ulrich Kühn, als fachlicher Ansprechpartner, gab mir immer wieder interessante Anregungen.

Dr. Stefanie Heins, als Head of Global Clinical Data Dictionary bei der Schering AG in Berlin, gilt mein ganz besonderer Dank: Ohne ihre ständige Hilfsbereitschaft sowie ihr umfassendes Fach- und Praxiswissen, hätte diese Diplomarbeit in vielen Punkten wesentlich oberflächlicher bleiben müssen.

Nicht zuletzt bedanken möchte ich mich bei meinen lieben Eltern, die mich über die gesamte Dauer des Studiums in jeder Hinsicht unterstützt haben und mir so auch beim Anfertigen dieser Arbeit immer zur Seite standen.

1. Zielstellung und Aufbau der Diplomarbeit

1.1 Zusammenfassung (Deutsch)

Die vorliegende Diplomarbeit verfolgt zwei Zielstellungen: Erstes Teilziel ist, die Veränderung der Dokumentationsprozesse und des Datenmanagements in der klinischen Forschung durch die verstärkte Integration von Electronic Data Capture (EDC) - Technologien darzustellen. Hierbei wird verstärkt auf die Bedeutung eines einheitlichen, Datenstandards für die Branche sowie die diesbezüglichen Entwicklungsarbeiten des Clinical Data Interchange Standards Consortium (CDISC) eingegangen. Zweites Teilziel ist, den speziellen, veränderten Bildungsbedarf in der klinischen Forschung sowie das diesbezügliche Ausbildungsangebot in Deutschland darzustellen und dementsprechend Ansatzpunkte zur Planung einer E-Learning gestützten Schulung zu geben. Die Diplomarbeit ist aufbereitet sowohl für branchenfremde Betriebswirtschaftler, als auch für nicht auf die klinische Forschung spezialisierte Mediziner und Pharmazeuten ohne Programmiervorkenntnisse.

- Im ersten Abschnitt werden zunächst der Bedarf, die Nutzenpotentiale und die Perspektiven der Extensible Markup Language (XML) zur technischen Realisierung von Datenstandards im allgemeinen erläutert sowie eine kurze Einführung in die Codierung von XML-Dokumenten und Dokumenttypbeschreibungen gegeben.
- Im zweiten Abschnitt werden der Arzneimittelforschungsprozess in seinen verschiedenen Phasen sowie grundlegende ethische und rechtliche Rahmenbedingungen beschrieben. Hierauf aufbauend werden die Kosten von klinischen Studien sowie ebenfalls die Entwicklung des deutschen im Vergleich zum internationalen Pharmamarkt behandelt. Als eine mögliche Rationalisierungsmaßnahme im kostenintensiven Forschungsprozess wird am Ende dieses Abschnitts die Integration von EDC herausgestellt, welche wiederum die Grundlage für den Bedarf nach einem brancheninternen Datenstandard für die klinische Forschung bildet.
- Der dritte Abschnitt beschäftigt sich mit den Arbeiten, den XML-basierten Standards sowie dem aktuellen Entwicklungsstand von CDISC. Während im ersten Teil dieses Abschnittes das Konsortium selbst, dessen Arbeitsweise und dessen Lösungsmodelle genauer beschrieben werden, wird im zweiten Teil auf die Akzeptanz von CDISC bei den relevanten Stakeholdern eingegangen. Dabei werden grundsätzliche Handlungsoptionen der Pharmaunternehmen hinsichtlich CDISC ebenso thematisiert wie die Haltung der Behörden zur Einreichung elektronischer Zulassungsanträge.
- Aufbauend auf den Erkenntnissen der ersten drei Abschnitte wird im vierten Kapitel die Diskrepanz zwischen Bildungsangebot und dem veränderten Bildungsbedarf speziell für die klinische Forschung in Deutschland gegenübergestellt. Hierbei wird sowohl auf die klassischen Ausbildungsmöglichkeiten für klinisches Studienpersonal bzw. Management eingegangen als auch auf aktuelle Entwicklungstendenzen zur Erweiterung des Angebotes im Hochschulwesen und bei privaten Ausbildungsunternehmen.
- Im fünften Abschnitt schließlich wird eine kurze Einführung in das Thema E-Learning, dessen Nutzen und Kosten sowie dessen spezielle Eignung für Schulungen in der Arzneimittelforschung gegeben. Hierauf aufbauend werden abschließend einige wichtige Ansatzpunkte bei der Planung eines adäquaten diesbezüglichen Schulungsangebotes für einen möglichen E-Learning-Anbieter behandelt.

1.2 Summary (English)

The goal of this thesis is two-fold: the first goal is to describe how documentation processes and data management in clinical research will change as a result of the increased integration of Electronic Data Capturing (EDC) technologies. It focuses in particular on how this common data standard will affect the industry as a whole as well as the work of the Clinical Data Interchange Standards Consortium (CDISC). The second goal is to provide an overview of the changed need for special education in clinical research as well as the current opportunities for training in Germany in this area. This overview will serve accordingly as a starting point for planning e-learning training programs. The analysis is primarily aimed at business people and interested parties who are not working in this industry as well as at health care and pharmaceutical professionals with little or no experience in the field of clinical research and no programming skills.

- Chapter one provides an overview of the need for potential uses of and opportunities offered by the Extensible Markup Language (XML) to achieve a data standard from a technical standpoint. A short introduction also deals with XML source codes and Document Type Definitions.
- Chapter two describes the different phases of the typical research process for new medications and therapies as well as fundamental ethical and legal considerations. This is followed by an examination of the cost of clinical trials and the development of the German pharmaceutical market vs. the international one. The end of the chapter focuses on the integration of EDC technologies as a way to streamline the cost-intensive research process which, in turn, serves as the foundation of the need for a common data standard for the industry.
- The third chapter deals with the work, the XML-based data standards and the progress (current level of development) of CDISC. While the first part of this chapter concentrates on the consortium itself and its developments methods, the second part addresses the acceptance level and integration of CDISC standards among the relevant stakeholders. This section deals not only with the various options the pharmaceutical companies have to take action but also with the authorities’ stand (the FDA in particular) on the CDISC standards and electronic submissions.
- In the fourth chapter the findings of the first three chapters serve as a basis for a discussion of the discrepancy that exists between supply and demand in the educational opportunities for qualifyingboth personnel responsible for carrying out clinical research studies as well as managers of clinical research projects in Germany. Within this context, traditional educational models are described as well as current trends both at institutes of higher learning as well as in the private education sector with a view to expanding the educational opportunities offered for acquiring a professional qualification in clinical research.
- The fifth and final chapter provides a short introduction to e-learning, the benefits and costs associated with it as well as how it is particularly suited for use in training in the area of pharmaceutical research. Finally, using this as a basis, several approaches a potential e-learning provider could pursue in planning training programs designed to meet these needs are addressed.

2. Einführung in XML

In diesem Kapitel sollen einleitend der Bedarf, der Nutzen und die Entstehung der eXtensible Markup Language, kurz XML, dargestellt werden. Den zweiten Schwerpunkt bildet die Entwicklung und Bearbeitung (Codierung) von XML-Dokumenten sowie Methoden zum Austausch und zur Präsentation der in den Dokumenten beschriebenen Daten. Im dritten Teil des Kapitels sollen schließlich der Nutzen von Standards im Allgemeinen sowie Anwendungsmöglichkeiten und Perspektiven von XML –Standards, speziell auf das E-Business bezogen, aufgezeigt werden.

Somit soll in diesem Kapitel das Grundverständnis für den Nutzen und die Beschaffenheit eines Datenstandards erarbeitet werden. Dies geschieht explizit in Hinblick auf das dritte Kapitel, für welches dieses erste Kapitel das benötigte technische Basiswissen zum besseren Verständnis eines XML-Datenstandards liefert. Es soll also keinesfalls als Tutorial für Programmierer dienen, sondern richtet sich vielmehr an eine Lesergruppe mit geringen bis überhaupt keinen Vorkenntnissen im Bereich der angewandten Informatik, wie z.B. klassisch ausgebildete Ärzte oder Wirtschaftswissenschaftler.

Unter dieser Zielsetzung kann das folgende Kapitel zur „Demystifizierung“ einer Sprache beitragen, deren Verwendung zur Zeit in weiten Kreisen bzw. Branchen unterschiedlichster Art in Erwägung gezogen wird oder bereits realisiert worden ist.

2.1 Hintergrund: Entstehung und Nutzen von XML

2.1.1 Wandlung des Datenaustauschs im Internet

Die Wurzeln des Internet reichen bis in die 60er Jahre zurück. Das World Wide Web (WWW) als einer der heutzutage wichtigsten Internetdienste entstand erst vergleichsweise spät Anfang der 90er Jahre. Bis zu diesem Zeitpunkt war das Internet noch zu unbekannt, zu teuer und zu wenig benutzerfreundlich, um den Anforderungen an ein Massenmedium, wie es das WWW heute ist, zu genügen.

Sich rasant weiterentwickelnde und somit leistungsfähigere, preisgünstigere Technologien zum einen sowie Wachstum und Kommerzialisierung des WWW zum anderen, welche sich in gegenseitiger Wechselwirkung immer weiter verstärkten, sollten bereits wenige Jahre später zu einem explosionsartigen Ansteigen der Nutzerzahlen führen.

Damit sollte sich auch die Art der Nutzung des Mediums Internet stark verändern: Anders als in seinen ersten Jahren dient das WWW heute dazu, Informationen nahezu jeden beliebigen Typs und Inhalts auszutauschen, und zwar:

- von Mensch zu Mensch,
- von Mensch zu Maschine und
- von Maschine zu Maschine [1, Wittenbrink, S.18f.].

Die ursprüngliche Konzeption der Hypertext Markup Language (HTML), als Beschreibungssprache bzw. als so genannte Auszeichnungssprache für den Quelltext (das Grundgerüst) von Internetseiten, kann diesen gewachsenen Anforderungen inzwischen nur noch teilweise gerecht werden. Neue Konzepte für erweiterbare Auszeichnungssprachen, die den Anwendungsbereich von HTML übersteigen bzw. individuell ergänzen, lassen sich als die unmittelbaren Folgen des Wandels der Internetnutzung deuten. Sie sehen eine weitaus größere Funktionalität für die Entwickler vor und werden dazu beitragen, bislang brachliegende Potentiale der Vernetzung erschließen zu können [2].

Im folgenden Abschnitt soll zunächst zum besseren Verständnis an einem praxisbezogenen Fallbeispiel veranschaulicht werden, in welcher Form HTML bei der Abwicklung des internetgestützten Datenaustausches verwendet werden kann und wo die Grenzen dieser Sprache liegen.

2.1.2 Ein einführendes Beispiel-Szenario

Eine Musterbranche für den Austausch von umfassenden und komplexen Datenmengen ist das Gesundheitswesen. Gerade hier eröffnen neue Technologien in Verbindung mit dem Internet ungeahnte Perspektiven der maschinellen Unterstützung bei den vielfältigen Kommunikationsprozessen. Im folgenden Beispiel-Szenario sollen diese Prozesse auf den Datenempfang einer Hauskrankenpflege-Einrichtung von einem Krankenhaus eingeengt werden.

Der typische Patient, der sich zur Hauskrankenpflege angemeldet hat, wird zunächst im internen EDV-System in einer umfassenden elektronischen Patientenakte registriert. Diese enthält u.a. seine Krankheitshistorie, Abrechnungsdaten und Vermerke diverser behandelnder Ärzte, Spezialisten und Versicherungsgesellschaften, Informationen über Krankenhausaufenthalte, Verabreichungen von Medikamenten, Röntgenaufnahmen sowie Daten zur Person.

Meist müssen diese Daten erst noch beschafft werden und liegen dann oft lediglich in Papierform bereit, was den aufwendigsten Teil der Dokumentationsarbeiten für das Hauskrankenpflege-Unternehmen mit sich bringt: Das manuelle Abtippen und Scannen des Materials zur Aufbereitung im eigenen EDV-System. Dabei ist ein präzises und fehlerfreies Informationsmanagement hinsichtlich der Patientendaten ein kritischer Erfolgsfaktor für Hauskrankenpflege-Einrichtungen, welche hinsichtlich Vorgaben von Gesundheitsbehörden und Krankenversicherungen strenge Auflagen zu erfüllen haben.

Was also liegt näher, als zumindest für den Transport der Daten die mittlerweile weite Verbreitung des Internets als Übertragungsmedium von bereits elektronisch gespeicherten Patientendaten zu nutzen? Die Lösung, die HTML-basierte Internetseiten hierzu anbieten, sähe in Einzelschritten folgendermaßen aus.

1.) Die Hauskrankenpflege verschafft sich einen registrierten Internetzugang zu den Patientendaten, z.B. bei einem Krankenhauses (Nutzername, Passwort).
2.) Die Hauskrankenpflege meldet sich als autorisierter Benutzer mit exakt definierten Abrufrechten im Datenmanagementsystem des Krankenhauses an.
3.) Die Hauskrankenpflege lässt sich die gewünschten Daten im Browser anzeigen.
4.) Die Hauskrankenpflege druckt die Daten aus.
5.) Die Hauskrankenpflege tippt die Daten vom Ausdruck ins eigene System ab.

Ebenfalls denkbar wäre natürlich, dass die Daten direkt vom Browser-Fenster aus in ein vorgefertigtes Eingabeformular abgetippt oder kopiert werden. Allerdings würde dadurch der Gesamtprozess nur teilweise beschleunigt bzw. Papier gespart werden. Eine echte Lösung, welche auch das aufwendige Abtippen der Patientendaten mit berücksichtigt, also das eigentliche Problem bei der Wurzel packt, sähe eher folgendermaßen aus:

1.) Die Hauskrankenpflege verschafft sich einen registrierten Zugang zu den Patientendaten z.B. eines Krankenhauses.
2.) Die Hauskrankenpflege meldet sich als autorisierter Benutzer mit definierten Abrufrechten im Datenmanagementsystem des Krankenhauses an.
3.) Die Hauskrankenpflege ruft die Daten des gewünschten Patienten ab.
4.) Das Datenmanagementsystem der Hauskrankenpflege kann die abgerufenen Daten des Krankenhauses interpretieren und überträgt sie selbständig in der festgelegten Dokumentationsform in die Patientenakte der Hauskrankenpflege.

Auf diesem Wege könnte sowohl wertvolle Arbeitszeit gespart als auch Fehlerquellen, wie sie beim Abtippen generell mit einzukalkulieren sind, von vornherein ausgeschlossen werden. Jedoch ist dieses zweite Szenario mittels Beschreibung der Daten auf HTML-Basis nicht möglich, da das Vokabular dieser Sprache zu eingeschränkt ist, um die Art der Daten sowie den Bezug, den sie zueinander haben, für den Computer als Maschine interpretierbar zu machen [3, Bosak].

2.1.3 Was HTML leistet

Zentrale Aufgabe von HTML ist es, die logischen Bestandteile eines Dokumentes zu definieren und auszuzeichnen, also Dokumente zu beschreiben. Auf diese Weise kann ein Dokument in Abschnitte bzw. Elemente aufgeteilt werden, denen ein jeweils unterschiedliches, elementspezifisches Layout zugewiesen werden kann, wie z.B. eine fett gedruckte Überschrift, ein linksbündiger Text in der Schriftart Arial, ein rechtsbündiges Bild mit Rahmen etc.

Zu diesem Zweck werden in HTML die einzelnen Dokument-Elemente mit so genannten Tags (sprich: „Täcks“) beschrieben. Diese Tags enthalten prinzipiell Daten, die Informationen über andere Daten, auch Meta-Informationen genannt, liefern. So kann z. B. die erste Zeile einer Patientenakte lauten: „Personenbezogene Angaben“. Der zugehörige Tag zu dieser ersten Zeile könnten dann lauten: „Typ=Überschrift“. Durch diese Zusatzinformation über die Daten in der ersten Dokumentzeile ist nun die verarbeitende Software in der Lage, die Art der Daten zu erkennen und diese für den menschlichen Leser des Dokumentes automatisch in einem Schriftbild darzustellen, welches sich von den folgenden Zeilen deutlich abhebt (z.B. größere Schrift, fett gedruckt) und damit impliziert, dass es sich um eine Überschrift des Textes handelt.

Die Tags markieren dabei als Markup (Hypertext Markup Language) als in eckigen Klammern geschriebener Text in HTML-Dokumenten die eigentlichen Informationen für den Leser, wie der folgende kommentierte Auszug aus einem HTML-Dokument veranschaulicht:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1.3-1: Beschreibung von Daten durch Tags in HTML

Der Browser, als verarbeitende Software, wird mittels der Tag-Informationen in die Lage versetzt, selbständig die Überschrift zu erkennen, sie von dem darauf folgenden Absatz zu unterscheiden und somit beide Elemente entsprechend ihrer individuellen Layout-Festlegungen auf dem Ausgabemedium darzustellen.

Zusammenfassend sei gesagt, dass HTML es einer verarbeitenden Software zwar ermöglicht, zwischen den Bestandteilen eines Dokumentes zu differenzieren, dieses aber vorwiegend zur Unterscheidung von abschnittsspezifischem Layout geschieht. Tags mit Informationen über die einzelnen Textelemente selbst, wie etwa für Name und Anschrift im oberen Quelltextauszug, sind in HTML nicht definiert. Zweck der Markup-Sprache ist vielmehr die Bereitstellung eines Tag-Vokabulars zur übersichtlichen, leserfreundlichen und individuellen Darstellung von Internetseiten im Browser.

2.1.4 Was HTML nicht leistet

HTML als Auszeichnungssprache zur Beschreibung von einzelnen Dokumentelementen stößt schnell an seine Grenzen bei der maschinellen Unterstützung hinsichtlich Verwaltung, Verarbeitung und Übertragung größerer, komplexerer Datenmengen. Diese bestehen im Wesentlichen in den folgenden drei Problempunkten:

- Erweiterbarkeit: HTML bietet dem Entwickler nicht die Möglichkeit, sein Tag-Vokabular für eigene Bedürfnisse und Anforderungen anzupassen oder gar zu erweitern. Inhaltsspezifische Dokumentelemente (z.B. die Adresse im obigen Quelltextauszug) sind somit nicht individuell definierbar und können deshalb auch nicht von der verarbeitenden Software automatisch weiterverarbeitet werden.
- Strukturierung: HTML unterstützt nicht die Spezifizierung von individuellen, fixen Strukturen, wie sie beispielsweise benötigt werden, um den Aufbau von Datenbanken (Tabellen-, Spaltenstrukturen, Schlüssel) hierarchisch in einzelnen Textdokumenten abzubilden.
- Validierung: HTML verfügt über kein spezielles Tag-Vokabular oder eigene Validierungsmechanismen, die es anderen Anwendungen ermöglichen würden, beim Import die Daten auf strukturelle Korrektheit und Vollständigkeit zu überprüfen. Somit kann nur nachträglich, auf manuellem Wege, sichergestellt werden, dass bei der Datenübertragung von einem System, bzw. einer Anwendung in die andere, alle Daten unverfälscht empfangen worden sind [3, Bosak].

Vor allem aufgrund dieser Mängel an Erweiterbarkeits-, Strukturierungs-, und Validierungsmöglichkeiten stellt HTML als Auszeichnungssprache keine befriedigende Lösung für den maschinell gestützten Austausch sowie die anschließende Verarbeitung komplexerer Datenmengen innerhalb eines Dokumentes dar.

2.1.5 Idee und Entstehung von XML

Im Februar des Jahres 1998 verabschiedete das World Wide Web Consortium (W3C) die eXtensible Markup Language (XML) als einheitlich spezifizierten Standard in der Version 1.0. Ziel war es, einen einfach zu implementierenden Standard zur logischen Dokumentauszeichnung bereitzustellen, dessen Funktionalität weit über den Umfang von HTML hinausgeht [1, Wittenbrink, S.16].

XML gehört wie HTML zur Familie der Markup-Languages. Beide entstanden auf Basis der Standard Generalized Markup Language (SGML) und bilden jeweils Teilmengen dieser Auszeichnungssprache. Die „Geburt“ von SGML geht ins Jahr 1974 zurück. Im Jahr 1986 wurde sie als offizieller Standard ISO 8879 umgesetzt. Zweck von SGML ist es u.a., Vorschriften und Regeln bereitzustellen, um Auszeichnungssprachen formal definieren zu können.

Problematisch war und ist die Komplexität von SGML, welche die Entwicklung und Nutzung von SGML-Programmen nicht nur kompliziert, sondern vor allem auch unnötig kostenintensiv macht. Dies hat bis heute Akzeptanz und Verbreitung von SGML negativ beeinflusst – ganz im Gegensatz zur großen Popularität ihrer Tochtersprachen.

Während also SGML auf der einen Seite sich wegen seiner hohen Komplexität nur als begrenzt einsetzbar erwiesen hat, ist HTML auf der anderen Seite aufgrund der fehlenden Erweiterbarkeit für komplexere Anwendungen ungeeignet. Und genau hier setzt das Konzept von XML an:

Das „X“ in XML steht für „extensible“, was übersetzt „erweiterbar“ bedeutet und sich u.a. auf das Markup dieser Sprache, also auf die Tags bezieht. Diese können den eigenen Anforderungen entsprechend definiert und angepasst werden, um Dokumentelemente exakt und inhaltsspezifisch beschreiben zu können.

XML bietet somit wesentlich weitreichendere Möglichkeiten hinsichtlich Vokabular und Funktionen als HTML. Um aber gleichfalls des höheren Komplexitätsgrades Herr zu werden, wurden alle für das Internet als überflüssig angesehenen SGML-Eigenschaften sowie eine Vielzahl zu selten genutzter und als zu kompliziert erachteter Features nicht in XML übernommen. Schon der ausgedruckte Umfang der formalen Definition von XML, welcher auf nur 33 Seiten Platz findet, bildet einen klaren Kontrast zur Anwenderfreundlichkeit der SGML-Definition von mehr als 500 Seiten. Der XML-Standard wird kontinuierlich weiterentwickelt; die jeweilige aktuelle, offizielle Spezifikation findet sich auf den Seiten des W3C unter http://www.w3c.org/XML/.

2.1.6 Charakteristische Eigenschaften und Vorteile von XML

Ein universelles, neutrales, weithin akzeptiertes und verwendetes Format, um Daten für die unterschiedlichsten Anwendungen allgemeinverständlich zu beschreiben, hatte es bisher noch nicht gegeben. XML konnte sich inzwischen zumindest in einigen Bereichen als ein solches Format durchsetzen und bringt sehr gute Voraussetzungen für einen zukünftigen, universell verwendeten Datenauszeichnungsstandard mit. In Aussicht stellen dies seine folgenden charakteristische Eigenschaften [4, Hintermeier]:

- XML ist frei verfügbar und unabhängig von proprietären Hersteller-Standards.
- XML ist plattformunabhängig, d.h. die Dokumente können auf unterschiedlichen Geräten z.B. auf PC, Handy, Kühlschrank, Fertigungsanlage etc. eingesetzt werden.
- XML ist unabhängig vom verwendeten Betriebssystem, so spielt es keine Rolle, ob z.B. Windows, Linux, UNIX etc. installiert ist.
- XML ermöglicht somit Interoperabilität, d.h. sowohl system- und plattformunabhängige als auch übergreifende Zusammenarbeit mehrerer vernetzter Teilnehmer mit unterschiedlichen Hard- und Software-Voraussetzungen.
- XML trennt strikt zwischen Speicherung und Verarbeitung der Daten, damit bleibt offen, welche Software zur Verarbeitung der Daten verwendet werden soll.
- Standardwerkzeuge zur Bearbeitung bzw. Weiterverarbeitung und Validierung von XML-Dokumenten sowie umfassende Tutorials sind frei erhältlich.
- XML-Dokumente sind sowohl für Maschinen als auch für Menschen lesbar und verständlich, was erhebliche Vorteile bei ihrer Entwicklung und Pflege bietet [1, Wittenbrink, S.17ff.]

Der Aufbau von XML-Dokumenten sowie Datenaustausch und Datenausgabe auf XML-Basis sollen in den Unterkapiteln 1.2 und 1.3 noch ausführlicher dargestellt werden. Vorher sei im anschließenden Abschnitt ein Überblick über die Haupteinsatzbereiche gegeben, für die XML konzipiert worden ist.

2.1.7 Anwendungsbereiche von XML

XML wurde als ein Format entwickelt, mit dem sich hochstrukturierte Inhalte austauschen lassen. Hieraus ergeben sich vielfältige Anwendungsmöglichkeiten, die sich im Wesentlichen einem der drei Kernbereiche zuordnen lassen, welche im Folgenden näher beschrieben werden sollen:

1.) Publishing von Dokumenten
2.) Management von Dokumenten
3.) Web-Services

Unter Publishing versteht man die Aufbereitung von in Dokumenten enthaltenen Informationen für menschliche Empfänger. XML ermöglicht hier:

- die angepasste Darstellung der Informationen auf verschiedenen Ausgabemedien, wie z.B. Monitoren und Druckern, aber auch Mobiltelefonen, Geräte-Displays, und akustischen Medien - kurzum auf jeglichen vernetzungsfähigen Endgeräten mit Wiedergabemöglichkeit;
- die Darstellung und Gestaltung von komplexen Graphiken, wie etwa mathematische Formeln, Vektorgraphiken oder auch EKG-Ergebnisse, welche im Quelltext nach bestimmten Konventionen beschrieben werden und aus dem dann die graphischen Konstrukte generiert bzw. weiterverarbeitet werden können.

Beim Management von Dokumenten wird XML verwendet, um Inhalte unabhängig von ihrer Präsentationsform zu strukturieren, zu editieren und zu verwalten. In der Praxis sind dies meist Inhalte, die sehr speziellen Anforderungen genügen müssen. Beispiele hierfür sind:

- FAQ’s (Frequently Asked Questions = Häufig gestellte Fragen), wie sie sich auf Support-Internetseiten von Unternehmen mit einer breiten Palette an Service-intensiven Produkten finden;
- Inhalte von ganzen Büchern oder komplexen technischen Dokumentationen, die gewöhnlich stets dieselbe Grundstruktur besitzen;
- Inhalte (bzw. Wissen) innerhalb von Content-Management-Systemen, aus denen je nach Bedarf Dokumente für die Präsentation generiert werden können;
- Umfangreiche Datenmengen, welche häufig sowie zwischen einer Vielzahl von Beteiligten ausgetauscht und individuell aufbereitet werden müssen (wie es etwa im Gesundheitswesen der Fall ist).

Web-Services werden mittels XML entwickelt, um die Kommunikation zwischen prozessorgestützten, vernetzten Systemen zu realisieren. Sie umfassen die Festlegung von Austauschformaten und Botschaftstypen auf XML-Basis, welche beispielsweise die gesicherte Verständigung zwischen PCs an prinzipiell jedem Ort der Welt ermöglichen. In diesen Formaten ist u.a. festgelegt,

- welche Dienste ein potentieller Sender anbietet und
- auf welche Weise diese Dienste abgerufen werden können.

Hierbei kommunizieren die beteiligten Systeme weiterhin innerhalb des XML-Sprachraums, die Programmierer brauchen also nicht in eine andere Sprache überwechseln, um den Austausch realisieren zu können - was Zeit - und Kostenvorteile bei der Entwicklung mit sich bringt.

Darüber hinaus erlaubt XML im Rahmen von Web-Services den verschiedenen Kommunikations-partnern, definierte Schnittstellen mit Validierungsmechanismen zu vereinbaren. Über diese können dann Anwendungsprogramme, die intern ganz unterschiedlich funktionieren und die evtl. auf grundsätzlich verschiedenen Betriebssystemen aufsetzen, Informationen miteinander austauschen, wobei selbige gleichzeitig auf Korrektheit und Vollständigkeit überprüft (= validiert) werden [1, Wittenbrink, S.20ff.].

So können sich z.B. zwei Pharma-Forschungseinrichtungen, die kooperieren und auf digitalem Wege ihre Daten austauschen wollen, unabhängig von ihrer - oftmals schon intern heterogenen - EDV-Landschaft vorab auf Schnittstellen einigen, welche mittels XML spezifiziert werden und über die dann zuverlässig Informationen ausgetauscht werden können. Dabei kann der gewöhnlicher Weise erhebliche Zeitaufwand, der für die Konvertierung und Überprüfung der Daten anfällt (siehe Beispiel in Kap. 1.1.2), stark reduziert werden.

Da sich das Problem heterogener, inkompatibler EDV-Landschaften immer wieder von neuem stellt, wenn zwei unterschiedliche Systeme zusammenarbeiten müssen, sollte es im Interesse aller Beteiligten liegen, sich auf ein universelles Austauschformat zu einigen, welches dann auch von allen Partnern auch konsequent unterstützt wird und den Anpassungsaufwand minimiert.

Dies kann branchenspezifisch – aber auch branchenübergreifend geschehen. Der Wert eines solchen Austauschformates steigt in jedem Fall mit der Zahl der beteiligten Partner. Proprietäre, kostenpflichtige Formate, sind allgemein hin nicht universell akzeptiert und einsetzbar. Langfristig gesehen sind sie unter diesem Aspekt zwangsläufig einem offenen, weiter verbreiteten Standard unterlegen.

XML, oder genauer gesagt der Bereich der Web-Services, bietet die technische Basis für solch einen universellen Standard und stellt damit die Vision einer weltweit einheitlichen Infrastruktur zur gesicherten Kommunikation und Transaktion bei der Abwicklung von Geschäfts- und Informationsaustauschprozessen in Aussicht[1, Wittenbrink, S.593].

2.2 Codierung: Erstellung & Weiterverarbeitung von XML-Dokumenten

2.2.1 Der Aufbau von XML-Dokumenten

Wie HTML bedient sich auch XML des Tag-Konzeptes zur Beschreibung von Dokumentelementen. Während in HTML die Tags jedoch verwendet werden, um Abschnitte zu definieren, denen ein bestimmtes Layout zugewiesen werden soll, dienen sie in XML vordergründig der Beschreibung des Inhaltes selbst. Dementsprechend könnte in XML der Beispielquelltext im Vergleich zu dem HTML-Auszug aus Kapitel 1.1.3. folgendermaßen aussehen:

XML

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2.1-1: Beschreibung des Inhalts durch Tags in XML

HTML

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2.1-2: Beschreibung des Layouts durch Tags in HTML

Obwohl beide Beispiele rein inhaltlich gesehen für den menschlichen Leser dieselben Informationen enthalten (nämlich dass es sich um eine Patientenakte des Patienten Schmidt handelt, dessen Anschrift in dieser Akte notiert ist), weist der XML-Quelltext eine ganze Reihe signifikanter Unterschiede zu seinem HTML-Pendant auf:

- Charakteristisch für XML-Dokumente ist ihre hierarchische Struktur. So ist im oberen Beispiel der Tag „Patientenakte“ definiert worden. Zwischen Start- und End-Tag „<Patientenakte>...</Patientenakte>“ wiederum befindet sich Start- und End-Tags von „<Adresse>“, welche ihrerseits die Tags zu <Strasse>, <Wohnort> und <Telefon> einschließen.
- Auf diese Weise werden jedoch nicht nur die Hierarchiestufen der Daten beschrieben, vielmehr werden letztere auch noch zueinander in Beziehungen gesetzt. Was dem menschlichen Leser unbewusst schon von vornherein klar ist, kann nun auch vom Computer bzw. einer Maschine „erkannt“ werden. In XML ist <Patientenakte> das Elternelement von <Adresse> und <Untersuchung>. Diese beiden wiederum sind Geschwisterelemente, denn sie stehen im Dokument hierarchisch gesehen auf der gleichen Stufe bzw. besitzen dasselbe Elternelement. Die Elemente <Strasse>, <Wohnort> und <Telefon> sind demnach Kinderelemente von <Adresse>, welches sich bezogen auf seine drei Kinderelemente wiederum als Elternelement verhält. Diese Art der Beschreibung mag für den menschlichen Leser auf den ersten Blick etwas verwirrend klingen – ist aber für die Maschine eine exakt formulierte und damit verständliche Methode zur Definition von Beziehungen.
- Weiterhin dienen die Tags der Beschreibung des Inhalts von Datenelementen. Somit werden die Daten als maschinell interpretierbare Informationen ausgezeichnet. Man spricht hier auch von sich selbst beschreibenden Dokumenten. Beispielsweise könnte im obigen XML-Beispiel - gegenüber dem HTML-Quelltext - gezielt die Adresse oder aber auch lediglich die Strasse des Patienten „Müller“ maschinell abgefragt werden. Angaben zum Layout werden nicht gemacht. Die Darstellung von Informationen aus XML-Dokumenten soll in Kapitel 1.2.3 noch aufgezeigt werden.

Abgespeichert werden XML-Dokumente als Dateien mit der Endung „.xml“. Zusammenfassend gesagt ermöglichen sie das strukturierte Speichern von Daten im Textformat, wobei in ihnen sowohl die Daten selbst, als auch die Beziehung in der sie zueinander stehen hierarchisch beschrieben werden. XML stellt damit ein Format zur Verfügung, Informationen, die dem menschlichen Leser offensichtlich erscheinen mögen, auch für maschinelle Rezipienten interpretierbar zu machen.

Die großen Stärken dieser Methodik, kommen im obigen, simpel gewählten Beispiel sicherlich noch nicht zum Tragen. Der Mehraufwand, der betrieben werden muss, um die Daten maschinell weiterverarbeitbar zu beschreiben, zahlt sich jedoch gerade dann umso stärker aus, wenn Datenmengen so groß und komplex werden, dass sie für den Menschen unüberschaubar sind. Der Datenaustausch zwischen Gesundheitseinrichtungen, wie er im vorigen Kapitel beschrieben wurde, ist dabei nur eine von vielen möglichen Anwendungen, bei denen sich eine XML-gestützte Lösung anbietet.

2.2.2 Definition von eigenen Tags in XML-DTD’s

Jedes XML-Dokument besteht aus Inhalt und Tags, welche den Inhalt beschreiben. Während HTML bereits ein Tag-Set zur Beschreibung von HTML-Dokumenten zur Verfügung stellt bzw. vorschreibt, muss in XML zunächst jeder Tag zur Beschreibung eines Dokumentelements selbst definiert werden. Dies kann mittels der Dokument-Typ-Definition (DTD) geschehen.

In ihr wird zum einen festgelegt, wie die Dokumentelemente (bzw. Tags) heißen sollen, zum anderen, welche möglichen Kinderelemente sie haben können bzw. müssen, ob ggf. deren Anzahl beschränkt sein soll, ob es nur eine begrenzte, definierte Menge von möglichen Werten für die Elemente geben soll etc. Veranschaulichen soll dies der Quelltextauszug aus einer denkbaren DTD für das XML-Beispiel aus dem vorhergehenden Abschnitt:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2.2-1: Definition von XML-Tags in einer DTD

In der ersten Zeile des DTD-Auszugs wird das Elternelement Patientenakte definiert. In den Klammern dahinter werden die Kinderelemente Adresse und Untersuchung notiert, die zu dem Elternelement gehören. Das Sternchen-Zeichen hinter Untersuchung bedeutet, dass Untersuchung keinmal, einmal oder mehrmals innerhalb des Elementes Patientenakte in einem XML-Dokument vorkommen kann – je nachdem, ob es für den Patienten bereits eine oder mehrere Untersuchungen geben hat oder eben noch überhaupt keine.

In der zweiten Zeile wird das Attribut Name für das Element Patientenakte definiert. Im XML-Dokument soll dieses dann den Namen des Patienten erhalten und somit identifizieren, um wessen Patientenakte es sich handelt. Denkbar wäre auch ein XML-Dokument mit dem hierarchisch noch höher angesiedelten Elternelement „Patientenaktensammlung“ und dessen Kinderelementen Patientenakte, die sich jeweils durch den Patientennamen als Attribut voneinander unterscheiden lassen.

Entsprechend der Deklaration in Zeile 1 werden in der dritten Zeile weitere Kinderelemente für das Element Adresse definiert. Das Plus-Zeichen hinter Telefon bedeutet in diesem Zusammenhang, dass eine oder mehrere Telefonnummern möglich sind, schreibt jedoch vor, dass mindestens eine Telefonnummer eingetragen werden muss.

Als drittes Anhangszeichen (neben Sternchen und Plus-Zeichen) besagt das Fragezeichen (siehe Zeile 7), dass ein Element einmal oder keinmal, jedoch nicht mehrere Male vorkommen kann. So könnte beispielsweise zusätzlich zum Untersuchungsergebnis ein EKG-Ergebnis für jede Untersuchung gespeichert werden – sofern eine Aufzeichnung erstellt worden ist.

Weiterhin wird jedem Element, das keine Kinderelemente besitzt, ein Datentyp zugeordnet (wie z.B. von der Art „Zeichenkette“, „Datum“ oder „Zahl“). Im Beispiel ist dieser bei allen Elementen gleich, nämlich der XML-spezifische Datentyp „PCDATA“.

Auf weitere Syntax-Regeln und Konventionen für die Erstellung von DTD’s soll an dieser Stelle nicht eingegangen werden. Gezeigt werden sollte an diesem Beispiel lediglich, auf welche Weise das Tag-Vokabular für anwenderspezifische XML-Dokumente definiert bzw. erweitert werden kann.

DTD’s bilden insofern die Basis von XML-Dokumenten, als dass in ihnen die verwendeten Tags und deren Verhältnis zueinander definiert sowie Konventionen für den Gebrauch dieser Tags festgelegt sind. Somit stellen sie sicher, dass XML-Daten immer in derselben verbindlichen, zugrunde liegenden Form gespeichert werden.

2.2.3 Kooperation und Einbindung fremder DTD’s

Es liegt nahe, für größere Projekte die zugehörigen DTD's auszulagern und sie als zentrales Format möglichst häufig wiederzuverwenden, damit nicht mehrfach Dokumenttypen definiert werden, welche dieselbe Art von Inhalt gleichartiger XML-Dokumente beschreiben [5, Auer].

Unternehmen derselben Branche, beispielsweise Gesundheitseinrichtungen mit nahezu identischen Anforderungen an ein Dokument „Patientenakte“, sollten in Erwägung ziehen, die gleiche DTD als Grundlage für dieses XML-Dokument zu verwenden und die diesbezügliche Entwicklungsarbeit untereinander aufzuteilen oder gemeinsam zu finanzieren. Ein weiterer Vorteil bestünde darin, dass dann auch alle Daten in derselben Struktur gespeichert und somit unkomplizierter austauschbar wären, was Kooperationsvorhaben oder den Verkauf von Studiendaten enorm erleichtern würde. Eine derartige Zusammenarbeit wäre sowohl unternehmensübergreifend als auch firmenintern über mehrere Standorte hinweg denkbar.

DTD-Dateien besitzen die Endung „.dtd“ und müssen in den ersten Zeilen eines XML-Dokumentes, das die DTD verwenden soll entweder

a) mit dem genauen Pfad, an dem sie gespeichert sind, referenziert werden (welcher sowohl auf die lokale Festplatte als auch auf eine Domain im WWW verweisen kann):

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2.3-1: Einbinden einer externen DTD

b) oder direkt als Quelltext am Anfang des XML-Dokumentes eingebunden werden:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2.3-2: Definition von Elementen innerhalb eines XML-Dokumentes

Beiden Varianten gemeinsam ist die Einleitung des einbindenden Tags mit „!DOCTYPE“, welches anzeigt, dass an dieser Stelle Informationen zum Dokumenttyp gegeben werden.

Ebenfalls möglich ist die Kombination bzw. das Referenzieren mehrerer DTD’s in ein und demselben XML-Dokument. Damit auch dann noch die Eindeutigkeit der verwendeten Elementnamen gewährleistet werden kann, ist jeder DTD ein Namensraum (engl. „Namespace“) zugeordnet.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2.3-3: Einführung von Namensräumen zur Nutzung mehrerer DTD’s

Wie in der Abbildung gezeigt, erfolgt die Festlegung der Namensräume jeweils in den ersten beiden Zeilen des obigen Quelltextes mit dem Tag „xmlns“, gefolgt von einem Doppelpunkt, dem Kürzel für den jeweiligen Namensraum und dem Ort, an dem sich die DTD befindet.

Sämtliche Elemente können dann im XML-Dokument mit dem vorangestellten Kürzel adressiert werden, welches dem entsprechenden Namensraum bzw. der DTD zugeordnet ist (hier „pa:“ für patientenakte.dtd und „st“ für Studien in phase_3.dtd). Auf diese Weise lassen sich Konflikte für Elemente mit evtl. identischen Namen in den verschiedenen DTD’s von vornherein ausschließen. Dies kann leicht der Fall sein kann, denkt man nur an die Angaben zur Person oder zur Adresse, die gewöhnlich sowohl in einer Patientenakte als auch in einen Studienbogen mit aufgenommen werden.

Abschließend sei noch erwähnt, dass es neben den DTD’s inzwischen auch noch höher entwickelte Dokumenttypbeschreibungen in der Sprache XML-Schema (Plural = XML-Schemas; gespeichert in Dateien mit der Endung „.xsd“) sowie in weiteren Schema-Sprachen gibt, deren Funktionalität noch über die Möglichkeiten von DTD’s hinausgeht. Die bedeutsamste Innovation von XML-Schema in Bezug auf datenorientierte Anwendungen ist die Einführung eines erweiterten Typensystems für XML-Daten. Zwar gibt es auch in den DTD’s bereits Datentypen, jedoch erfüllen diese nicht immer die an sie gestellten Anforderungen [1, Wittenbrink, 510f.).

2.2.4 Validierung von Daten in XML

Die Tags und Regeln für einen Dokumenttyp werden, wie im vorangegangenen Abschnitt gezeigt, in der DTD festgelegt oder in einem XML-Schema beschrieben. Bei der Validierung eines XML-Dokumentes wird überprüft, ob es mit diesen Regeln konform ist, d.h.

- ob es der formalen Strukturdefinition in der DTD entspricht (z.B. Eltern- / Kinderelement „kann vorkommen“ / „muss vorkommen“);
- ob alle Elemente bzw. Tags in der DTD definiert und beschrieben sind;
- ob Namen und Typen von den in der DTD beschrieben Element-Attributen korrekt verwendet worden sind.

Somit stellt die Validierung (von „vality“ – engl. für „Gültigkeit“, also „Prüfung der Gültigkeit“) von XML-Dokumenten, eine Form der Qualitätskontrolle und -sicherung der in ihnen enthaltenen Daten dar. Eine exakt formulierte DTD allein kann noch nicht gewährleisten, dass ein XML-Dokument korrekt erstellt wird. Erst automatische Prüfmechanismen können Konformität der Daten und damit maschinelle Weiterverarbeitung bzw. Datenaustausch mit anderen Systemen ermöglichen.

Um nun ein XML-Dokument zu validieren, kann es gegen seine DTD „geparst“ werden, d.h. es wird auf seine logische Struktur sowie auf seine Datenzusammensetzung hin analysiert. Dieser Vorgang wird von einem Programm, einem so genannten XML-Parser, durchgeführt. Prinzipiell existieren zwei alternative Ansätze des Parsens:

a) Stapelverarbeitung der Daten im XML-Dokument: Parser überprüft ob das erste Tag-Paar DTD-konform ist; wenn ja: zum nächsten Tag-Paar gehen, wenn nein: Abbrechen und Fehlermeldung ausgeben. Die Essenz dieses Verfahrens lässt sich in einem Satz zusammenfassen: „Beginne am Anfang und arbeite dich durch, bis du zum Ende gelangst.“ [6, Boumphrey, S.57] Realisiert wird es über eine einfache Programmierschnittstelle für XML (Simple Application Programming Interface for XML = SAX). Dementsprechend handelt es sich hierbei um einen so genannten SAX-Parser.

b) Vollständige Umsetzung des Dokumentes in eine Baumstruktur, welche die Hierarchie der einzelnen Elemente abbildet. Erst danach Analyse des gesamten Baumes. Die Baumstruktur wird auch als Document Object Model (DOM) bezeichnet. Dementsprechend spricht man hierbei von einen so genannten DOM-Parser.

Beide Parser können XML-Dokumente auf zwei unterschiedliche Kriterien hin überprüfen:

a) Wohlgeformtheit, d.h. ob die XML-Syntax des Dokumentes in sich stimmig ist (z.B. ob alle Tags mit „<“ beginnen und mit „>“ enden).
b) Gültigkeit, d.h. ob das Dokument wohlgeformt und ob es gegenüber den in seiner DTD definierten Regeln valide (= gültig) ist.

2.2.5 Darstellung von XML-Dokumenten

XML selbst enthält keinerlei Aussage darüber, wie die Daten bzw. der Inhalt von XML-Dokumenten darzustellen ist. XML-Dokumente beinhalten zwar eine inhaltliche Selbstbeschreibung hinsichtlich der in ihnen vorkommenden Elemente. Alle Fragen der Ausgabe jedoch, also wie die Daten mittels verschiedener Wiedergabe-Medien (z.B. Bildschirm, Drucker, Mobiltelefon, Akustische Medien) dargestellt werden sollen, bleiben von dieser Beschreibung unberührt [7, Auer].

Dieser Umstand ist durchaus gewollt und zwar als Bestandteil eines grundlegenden Konzeptes, das in XML verfolgt wird, nämlich der strikten Trennung von Inhalt und Präsentationslogik. Generell lassen sich Dokumente (das können auch Zeitungsartikel, Bücher oder andere digitale Formate sein) in drei Komponenten unterscheiden: Struktur, Inhalt und Layout. Dies veranschaulicht die folgende Graphik [4, Hintermeier]:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2.5-1: Die drei Komponenten eines Dokumentes

1) Der eigentliche Inhalt sind die Texte, Bilder oder Graphiken in einem Dokument.
2) Die Anordnung dieses Inhalts wird durch die Struktur beschrieben.
3) Im Layout sind die Vorgaben zur optischen Präsentation der Struktur festgelegt.

Erst durch die Re-Kombination dieser drei Bestandteile wird das eigentliche Dokument zur Darstellung erzeugt. Diese Art der Aufteilung eines Dokumentes bringt hinsichtlich der digitalen Verarbeitung drei wesentliche Vorteile mit sich:

1. Layout und Struktur können separat, individuell für verschiedene Medien definiert werden.
2. Änderungen an Struktur oder Layout brauchen jeweils nur einmal pro Dokumenttyp vorgenommen werden und können dann bei gleichartigen Dokumenten auf alle verschiedenen Inhalte angewendet werden.
3. Die Datenübertragung in Netzen kann deutlich beschleunigt werden, wenn Layout-/ Strukturinformationen nur einmalig übertragen, die Inhalte von Dokumenten jedoch vielfach übertragen werden.

Ein Beispiel, bei dem diese Trennung ebenfalls durchgeführt wird, ist die Erstellung von PDF-Dateien, bei der beispielsweise ganze Bücher von weit über 1000 Seiten Umfang auf nur 10 Megabyte „komprimiert“ werden können. Der Grund ist, dass die Seiten in einem Roman gewöhnlich alle dasselbe Layout haben, welches jedoch nur ein einziges Mal beschrieben werden braucht und dann auf alle Seiten des Dokumentes angewendet werden kann.

In XML existieren deshalb – im Gegensatz zum darstellungsorientierten HTML - keinerlei spezifische Elemente wie <h1> für Überschriften oder <b> für Fettdruck. Das Layout der Elemente eines Dokumententyps kann stattdessen in einer separaten XSLT-Datei festgelegt werden. XSLT steht für e X tensible S tylesheet T ransformation L anguage, d.h.

- es handelt sich um eine Sprache (L anguage),
- die erweiterbar ist (e X tensible)
- hinsichtlich der Layout-Angaben, die in einer XSLT-Datei (S tylesheet) für alle gewünschten XML-Elemente festgelegt werden können,
- um diese Elemente für die medienspezifische Darstellung in eine andere, geeignete Sprache, wie z.B. in HTML, umzuwandeln (T ransformation).

Für die Darstellung im Browser könnte eine Umwandlung bzw. Einbettung der mit XML beschriebenen Informationen in HTML, wie im Folgenden veranschaulicht, aussehen:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2.5-2: Transformation von XML nach HTML durch XSLT

XSLT-Dateien stellen somit ein erweiterbares System von Transformationsregeln für beliebige XML-Elemente zur Verfügung. Diese Regeln können separat für verschiedenartigste Medien definiert werden, also Outputs in Abhängigkeit von der Art der Darstellung liefern, welche vom Anwender gewünscht werden.

So kann aus einem Text mit definierten Überschriften nicht nur eine komplette Druckversion, sondern z.B. auch ein kurzes Inhaltsverzeichnis erzeugt werden. Ebenso könnte derselbe Text auch in ein HTML-Dokument mit komplexen Formatierungen transferiert werden, während der bloße Inhalt zur Sprachausgabe verwendet wird.

Weiterhin sind die selbst definierten Transformationsregeln nicht vom jeweiligen XML-Dokumenttyp abhängig, sondern können auf alle XML-Dokumente angewendet werden, welche Elemente enthalten, auf die sich die spezifischen Regeln beziehen. Selbst wenn keines dieser Elemente enthalten ist, würde nicht eine Fehlermeldung sondern lediglich ein leeres Ausgabedokument erzeugt werden [7, Auer].

Neben XSLT existieren auch noch weitere Möglichkeiten, das Layout von ausgegebenen XML-Dokumenten festzulegen (z.B. XSL Formatting Objects), die innerhalb dieser Arbeit jedoch nicht weiter behandelt werden sollen.

2.2.6 Datenabfrage in XML-Dokumenten und Datenbanken

Ein XML Dokument ist vergleichbar mit einer Datenbank, welche nach einem bestimmten Schema geordnete Rohdaten enthält. Während in einer klassischen Datenbank jedoch Tabellen bzw. Zeilen und Spalten benutzt werden, um die Daten zu strukturieren, werden in XML die in der Dokumenttypbeschreibung definierten Tags zu diesem Zwecke verwendet.

Wenn einzelne Daten aus den Tabellen einer Datenbank extrahiert oder aggregiert werden sollen, wird gewöhnlich auf SQL (= Structured Query Language) als Abfragesprache zurückgegriffen. Um Abfragen in XML-Dokumenten durchzuführen, steht mit XQL (= XML Query Language) eine SQL nachempfundene Sprache zur Verfügung. Eine alternative Methode bietet XPath (engl. path = „Pfad“): Mittels der Ausdrücke dieser Sprache kann der Weg bzw. Pfad zu bestimmten Elementen im Baummodell des XML-Dokumentes beschrieben und so gezielt Werte abgefragt werden. Die abgefragten Werte können dann mittels XSLT für den Anwender aufbereitet und ausgegeben werden.

XML-Dokumente und Datenbanken schließen sich nicht gegenseitig aus. Vielmehr können sie, jeweils entsprechend ihrer Stärken, sich gegenseitig ergänzend eingesetzt werden, z.B.:

- Datenbanken als Repository, also Aufbewahrungsort, für ganze XML-Dokumente (So unterstützen u.a. das kommerzielle Datenbanksystem Oracle 9i sowie das frei verfügbare, Betriebssystem übergreifende XML-Repository XINDICE als Bestandteil des Open-Source-Projektes „Apache“ zusätzlich als Abfragesprache XPath, um innerhalb der verwalteten Dokumente navigieren zu können.);
- Datenbanken als Verwaltungssystem für XML-Dokument- Inhalte, bei dem die einzelnen Elemente, Attribute und Werte des Dokumentes auf Zeilen und Spalten von Tabellen abgebildet werden;
- XML als Austauschformat zwischen verschiedenen Datenbanken.

Eine leistungsfähigere Abfragesprache (SQL), die Kontrolle der referenziellen Integrität sowie die Minimierung von Redundanzen gehören zu den Hauptvorteilen von (relationalen) Datenbanken [1, Wittenbrink, S.669ff.].

Nachteilig bei Datenbanken ist jedoch die Bindung zwischen Datenbanksystem, Betriebssystem und Plattform (= Endgerät). Bei XML dagegen sind sowohl die Daten als auch die Abfrageskripte reine Textdateien, die bei Bedarf mit jedem Standardtext-Editor auf jedem Betriebssystem bearbeitet werden können. Somit ist der Entwurf eigener Dokumente (in DTD’s), das Speichern von Daten in den gewünschten XML-Dokumenten bzw. Datenbanken (z.B. XINDICE) sowie deren Abfrage (XQL, XQuery) und Ausgabe (XSLT) möglich, ohne betriebssystem-spezifische Besonderheiten beachten zu müssen [7, Auer].

2.2.7 XML-Datenaustausch in Netzen

Einer der Hauptvorteile von XML ist die Definitionsmöglichkeit bzw. die verbindliche Beschreibung von allgemeingültigen Dokumenttypen, welche die Grundlage für die unkompliziertere, maschinelle Abfrage sowie die Integration externer Daten in das eigene System bildet.

Für den Transport externer (und unternehmensinterner) Daten liegt die Nutzung des heute weit verbreiteten Internets nahe. Auch zu diesem Zweck sind XML-basierte Technologien entwickelt worden, welche den Bereich der Web-Services, also netzbasierte Dienste unterstützen sollen (siehe Kapitel 1.1.7). In diesem Zusammenhang seien drei Komponenten, nämlich XML-RPC’s, SOAP und die Programmiersprache JAVA sowie die Bedeutung, die ihnen bei der Realisierung von Web-Services zukommt, kurz dargestellt.

XML-RPC (XML Remote Procedure Calls) ermöglicht Funktionsaufrufe zwischen beispielsweise zwei PCs mit unterschiedlichem Standort über das Internet-Datenübertragungsprotokoll HTTP (welches auch beim Abrufen von Internetseiten benutzt wird). Für diese, so genannten „entfernten Funktionsaufrufe“ wird meist der Anglizismus „Remote Procedure Calls“, kurz RPC, verwendet.

Mit einem RPC könnte z.B. von einem Krankenhaus die Funktion „Blutgruppe anzeigen“ auf dem PC des Hausarztes abgerufen werden (sofern natürlich diese Funktion dort installiert und zugänglich ist). Dabei müsste dann ein Parameter, der den gewünschten Patienten identifiziert, wie z.B. sein Name an die Funktion übergeben werden. Die korrekte Auszeichnung dieses Parameters sowie die Bestimmung der Funktion selbst wird wiederum mittels XML umgesetzt (siehe folgende Abbildung). Deshalb heißt diese Art des entfernten Funktionsaufrufes XML-RPC.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2.7-1: Auszug aus einem XML-RPC-Quelltext

Der XML-RPC beschreibt lediglich was mit welcher Funktion / Methode und welchen Parametern abgerufen werden soll. Für das Stellen der Anfrage selbst sowie das Speichern und Zurücksenden des Ergebnisses ist JAVA als weit verbreitete, plattform- und betriebssystem-unabhängige, frei verfügbare Programmiersprache geeignet. Oder genauer gesagt, XML ist ursprünglich sogar für die Umsetzung durch JAVA als objektorientierte Programmierschnittstelle (Application Programming Interface = API) zur Verarbeitung seiner Daten konzipiert worden [6, Boumphrey, S.31].

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2.7-2: Auszug aus einem JAVA-Quelltext in Verbindung mit XML-RPC

Das oben exemplarisch aufgeführte Prinzip, XML für die Beschreibung des „Welche?“ bzw. „Womit?“ bezogen auf Daten, Dokumente und Funktionen sowie JAVA für das „Wie?“, also die Ausführung zu verwenden, liegt auch anderen Anwendungen als RPC’s zugrunde – zumal Textdokumente per sé nicht in der Lage sind, Anweisungen selbständig auszuführen.

Ein weiteres Beispiel für solche JAVA-basierten Anwendungen, welche im Rahmen dieser Arbeit bereits vorgestellt wurden, sind XML-Parser, welche sich schon mit relativ wenig Aufwand in JAVA programmieren lassen. Hinsichtlich RPC’s sei an dieser Stelle das „Apache XML-RPC“ erwähnt, welches in der Lage ist, XML-RPC’s umzusetzen. Aufgrund seiner geringen Größe (als nur 57 Kilobyte umfassende JAVA-Datei) ist es auch für den Einsatz bzw. die Datenabfrage auf Mobiltelefonen geeignet [8].

Das Simple Object Access Protocol (SOAP), als dritte und letzte in diesem Abschnitt aufgeführte Komponente beim vernetzten Datenaustausch mittels XML, definiert ein Markup-Vokabular zur Strukturierung von Nachrichten in Umschläge und Nachrichtenrümpfe [9, Jeckle]. Es ermöglicht nicht nur genauere, anwendungsspezifische Beschreibungen für den Fernaufruf von Prozeduren, sondern erlaubt auch die Übertragung komplexer XML-Dokumente, welche an SOAP-Botschaften, ähnlich wie bei E-Mails, angehangen werden können [1, Wittenbrink, S.564ff.].

SOAP und XML-RPC benutzen ein XML-Tag-Vokabular. Die Metasprache XML selbst ist für die Umsetzung mittels der weit verbreiteten Programmiersprache JAVA konzipiert worden. Die Kombination dieser drei Komponenten ermöglicht die Entwicklung von Anwendungen für die standortübergreifende, maschinelle, hoch automatisierte Kommunikation. Und zwar ohne dass die Programmierer ein größeres Inventar an Sprachen (als XML und Java) verbinden und beherrschen müssen, was nicht zuletzt erhebliche Zeit- und Kostenvorteile realisierbar macht.

2.2.8 XML-Editoren und Publikationsumgebungen

XML-Dokumente lassen sich prinzipiell mit einem einfachen Texteditor, wie Notepad unter MS Windows, erstellen. Zur professionellen Entwicklung gibt es mittlerweile jedoch ein großes Spektrum von komfortableren XML-Editoren bis hin zu kompletten, integrierten Entwicklungsumgebungen.

Als Beispiel für einen weiterentwickelten, frei verfügbaren XML-Text-Editor sei an dieser Stelle EMACS genannt (siehe Abbildung unten [1, Wittenbrink, S.220]). Gegenüber einfachen Texteditoren bietet dieser zusätzliche Eingabe- und Verarbeitungsmöglichkeiten, z.B. die automatische Überprüfung eines XML-Dokumentes auf Wohlgeformtheit beim Laden, Unterscheidung zwischen Markup und einfachem Text durch unterschiedliche Farben auf dem Bildschirm sowie die kontextsensitive Auswahl von gültigen Elementen aus einer Liste [1, Wittenbrink, S.78f.].

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2.8-1: Screenshot eines XML-Quelltextes mit eingebundener DTD in EMACS

Ein komplettes, frei verfügbares Publishing-Framework (= „Veröffentlichungs-Rahmenwerk“; auch: Publikationsumgebung) für XML-Dokumente ist mit dem Apache-Cocoon-Projekt geschaffen worden. Hauptaufgabe dieses Frameworks ist es, die verschiedenen XML-Technologien zu integrieren, d.h. Schnittstellen für den Austausch zwischen diesen Technologien zu schaffen und es auf diese Weise zu ermöglichen, XML-Quelldokumente je nach Bedarf in beliebige Zielformate zu transformieren.

Beispielsweise kann ein Anwender mittels Browser über das Internet eine Anfrage an einen Server, auf dem Cocoon installiert ist, stellen. Cocoon ist dann in der Lage, nicht nur den Browsertyp zu erkennen, sondern auch, dass dieser Browser HTML bzw. XHTML als Datenformat zur Darstellung benötigt. Das Publishing Framework ist somit in der Lage, das verlangte XML-Dokument selbständig mittels vorgefertigtem XSL-Stylesheet in die gewünschte Darstellungsform zu transformieren und das Ergebnis an den Anwender zurückzusenden [10, Schmidt].

Weiterhin integriert Cocoon u.a. vorgefertigte JAVA-Prozeduren, Konvertierungsskripte für proprietäre Datenbankformate, graphische Oberflächen bzw. Eingabemasken zur Generierung von Quellcode sowie einen Sitemap-Editor zur automatischen Generierung von HTML-Seiten aus XML-Quellcode, wie ein Screenshot des Frameworks in der folgenden Abbildung [11] verdeutlichen soll:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2.8-2: Screenshot aus dem Cocoon Publishing Framework

In der Praxis werden die in diesem Abschnitt aufgeführten Applikationen genutzt, um komplexe XML-Technologien professionell entwickeln, organisieren, verwalten, dokumentieren und betreiben zu können. Ausgeschöpft wird das Nutzenpotential von XML nämlich erst dann, wenn die Vielzahl der sich bietenden Anwendungsmöglichkeiten und Technologien, die zur Verfügung stehen, sich gegenseitig ergänzend eingesetzt werden. Hierfür ist deren Integration durch professionelle Entwicklungsumgebungen notwendig.

2.3 Ausblick: Anwendungen & Verbreitung von XML im E-Business

2.3.1 Der Nutzen von Standards im Allgemeinen

Der Alltag der modernen Zivilisationsgesellschaften ist geprägt von Standards: Ob Maßeinheiten wie Gramm, Zentimeter oder Grad Celsius, Zeitzonen für die Abschnitte auf dem Globus, Papierformate wie DIN A4, die Buchstaben dieses Textes oder Steckdosen zum Stromnetz - Standards sind so allgegenwärtig und selbstverständlich, dass viele von ihnen bewusst gar nicht permanent wahrgenommen werden können.

Die Etablierung und Verwendung von Standards lässt sich bereits in fast allen frühen Hochkulturen beobachten. Der Bau der Pyramiden von Gizeh hätte ohne ein umfangreiches technisches Regelwerk, z.B. bezüglich der Kantenlänge der Steinquader, kaum realisiert werden können. Im kaiserlichen China wurden ebenfalls verhältnismäßig früh Radstand und Achsenlängen von Fuhrwerken sowie dementsprechend die Breite von Strassen vereinheitlicht. Ökonomisch betrachtet [12, Hesser, S.194ff.] konnte hierdurch eine Senkung der Transportkosten, -risiken und -zeiten herbeigeführt werden. Zudem konnten neue Märkte erreicht werden, die sich in solchen Regionen befanden, welche vormals nur schwer oder gar nicht beliefert werden konnten. Hinsichtlich der Produktion von vereinheitlichten Fuhrwerkteilen bot sich schließlich die Möglichkeit der Massenproduktion und somit der Ausnutzung von Skaleneffekten.

Offenbar profitierten schon damals alle Beteiligten von der Existenz dieses Standards, welcher zwar nicht den einzelnen Wettbewerber bevorzugte, jedoch ein verbilligtes Angebot von Gütern ermöglichte, welches seinerseits zu einer allgemeinen Erhöhung der Lebensqualität beitragen konnte. Bis heute hat sich eine kaum noch überschaubare Vielzahl von Standards und Normen in nahezu allen Lebens- bzw. Arbeitsbereichen entwickelt. Diese lassen sich unterscheiden in:

- Offizielle Standards, herausgegeben bzw. akkreditiert von Organisationen wie z.B. dem DIN (Deutsches Institut für Normung), der ISO (International Standards Organisation) oder dem ANSI (American National Standards Institute) sowie in
- De-Facto-Standards, welche durch den Markt selbst hervorgebracht werden [12, Hesser, S.75f.].

Klassische Beispiele für De-Facto-Standards sind u.a. die Compact Disc (CD), das Betriebssystem Microsoft Windows oder der VHS-Videostandard. Begründet liegt die Existenz von De-Facto-Standards oft in den von ihnen erzeugten Netzwerkeffekten [12, Hesser, S.209f. ] , d.h. der individuelle Nutzen für den Nutzer des jeweiligen Produktes steigt mit der Anzahl der Gesamtnutzer des Produktes: Das Speichern und der Austausch von Daten im MS-Word-Format beispielsweise, oder auch das Telefon mit seinen offiziell standardisierten Schnittstellen weisen aufgrund ihres hohen Verbreitungsgrades starke Netzwerkeffekte auf.

Generell dienen Standards zur Umsetzung der folgenden technischen Funktionen [12, Hesser, S.40ff.]:

- Festsetzung der Struktur eines technischen Systems und dessen Schnittstellen
- Gewährleistung von Interoperabilität bzw. Kompatibilität mit anderen technischen Systemen
- Reduzierung der Vielfalt und somit der Komplexität
- Festlegung von Qualitäts- und Sicherheitsniveaus
- Speicherung und Dokumentation routinisierbarer Tätigkeiten
- Speicherung von zeitinvariantem Wissen

Aufgrund dieser technischen Funktionen lassen sich die folgenden ökonomischen Effekte der Standardisierung erzielen [12, Hesser, S.194f.]:

- Reduzierung von Transaktions-, Kommunikations-, und Koordinationskosten bei der Interaktion
- Rationalisierung der Leistungserstellung (kostengünstiger und schneller)
- Allgemeine Akzeptanz und damit Verringerung externer Effekte
- Entlastung von Routinetätigkeiten und somit freiwerdende Ressourcen für produktivere bzw. kreative Arbeitsprozesse
- Konstitution von Märkten und damit Markterschließungsmöglichkeiten für weitere Akteure

Letztlich kommt ein „guter“ Standard mit den aufgezählten ökonomischen Effekten den Endverbrauchern zugute, da er sich beispielsweise in verkürzten Entwicklungs- und Lieferzeiten sowie niedrigeren Preisen niederschlägt.

2.3.2 Vision und Nutzen von XML als Standard im E-Business

Als Mitte/Ende der 1990er Jahre das Internet zum Massenmedium avancierte, erkannte eine Vielzahl von Unternehmen und Organisationen der unterschiedlichsten Branchen dessen großes Potenzial als Absatzmedium. Die Definition von universell verwendbaren Standard-Formaten und harmonisierten Schnittstellen für den automatisierten Austausch von Geschäftsdaten und zur Realisierung einer weltweit zugänglichen „Marktplatzes“ für den spontanen Handel gehört seit dieser Zeit zu den wichtigsten Anwendungsgebieten von XML. Dabei kann positiv hervorgehoben werden, dass gerade dieser universelle Anspruch an einen Datenstandard die Erschließung seines gesamten Nutzenpotenzials für alle Beteiligten, wie er generell im vorangegangenen Abschnitt beschrieben worden ist, in Aussicht stellt.

Der diesbezügliche Realisierungsprozess gestaltet sich jedoch komplex: Um Handelsprozesse, an denen mehrere Partner von verschiedenen Orten der Welt aus teilnehmen, durch Computer zu unterstützen oder gar zu automatisieren, werden exakte, rechtlich verbindliche Beschreibungen dieser Prozesse benötigt. Die Rollen und Berechtigungen von Transaktionspartnern (z.B. Käufer / Verkäufer), die Reihenfolge und Art von Teilprozessen (z.B. Warenbestellung / Versand / Erhaltsbestätigung / Reklamation) sowie Schnittstellen und Datenübertragungsmethoden müssen dazu genauestens definiert werden. Man spricht in diesem Zusammenhang auch von der Modellierung der Geschäftsprozesse. Dabei werden die Informations- und Warenflüsse zunächst schematisch als Szenario dargestellt, wie die folgende Abbildung eines Ausschnitts [1, Wittenbrink, S.608] aus einem solchen Geschäftsprozess zeigt:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.3.2-1: Schematische Darstellung von Informations- und Warenflüssen

Die Digitalisierung von Geschäftsprozessen zwischen Partnern unterschiedlichen Standortes sowie die Organisation des zugrunde liegenden Datenflusses ist wesentlich älter als XML: Bereits in den 1960er Jahren wurde EDI (Electronic Data Interchange) zur Beschreibung von Dokumenttypen für den rein digitalen Kommunikationsfluss zwischen verschiedenen, verteilten Anwendungen entwickelt.

Heutzutage wird mittels EDI immer noch ein wesentlich höherer Umsatz als auf anderen, internetbasierten Handelsplattformen erzielt. Die Entwicklung von EDI, die im Einsatz benötigte Software und Hardware sind allerdings ausgesprochen kostspielig. Aus diesem Grunde wurde und wird EDI fast ausschließlich von Großunternehmen verwendet, welche einerseits über genügend Ressourcen sowie andererseits über ausreichende Marktmacht verfügen, um ihre Lieferanten und Geschäftspartner dazu zwingen zu können, die von ihnen „diktierten“ Verfahren und Standards gleichfalls zu übernehmen [1, Wittenbrink, S.598].

XML ist dagegen - zumindest perspektivisch gesehen – auf Grund seiner technischen Voraussetzungen sowie seiner freien Verfügbarkeit in der Lage, einem ganz anderen, viel weiter reichenderem Anspruch gerecht zu werden: nämlich ein offenes, gemeinsam entwickeltes, plattform- und anwendungsunabhängiges Vokabular für weltweite Geschäftsprozesse sowohl branchenintern als auch -übergreifend bereitzustellen.

Rein technisch gesehen wäre dies mit EDI ebenfalls möglich – jedoch könnte aufgrund der zu hohen Entwicklungs- bzw. Implementierungskosten nie das Gros der kleinen bis mittelständischen Unternehmen integriert werden. Netzeffekte können deshalb nur sehr begrenzt auftreten, da die Teilnehmerzahl niemals die Ausmaße annähme, die prinzipiell möglich sind. Aus diesem Grunde sollte eine allgemein integrierte Lösung, für welche XML immerhin die grundsätzlichen Voraussetzungen bietet, auf lange Sicht den proprietären EDI-Formaten von einzelnen Großunternehmen überlegen sein.

Zahlreiche Großunternehmen und Standardisierungsorganisationen engagieren sich daher hinsichtlich der Definition so genannter Frameworks für den rechnergestützten Handel. Zu deren Komponenten gehören XML-Technologien wie ebXML (Electronic Business XML) und UBL (Universal Business Language)

- zur Modellierung der Geschäftsprozesse;
- zur Festlegung von Formaten für Geschäftsdokumente, Verträge und Vereinbarungen;
- zur Definition von Botschaften;
- sowie zur Publikation von Diensten [1, Wittenbrink, S.601ff.].

In Aussicht stellen lassen sich mit fortschreitender Entwicklung und Verbreitung dieser Systeme beispielsweise Online-Verzeichnisse, in denen Produkte mittels Tags sowohl für Menschen als auch Maschinen verständlich und eindeutig beschrieben sind. Die Beschaffungslogistik könnte somit nahezu automatisch von Computern übernommen werden, welche dann nämlich in die Lage versetzt sind, automatisch weltweit das optimale Angebot zu finden und bei Bedarf (z.B. bei Unterschreitung eines Sicherheitsbestandes im Lager) selbständig nachzubestellen.

Der in diesem Kapitel beschriebenen Vision stehen jedoch trotz des unbestritten hohen Nutzenpotentials für alle Beteiligten auch größere Hürden entgegen, die von den Entwicklern und Akteuren auf den Märkten erst einmal genommen werden müssen und auf welche im folgenden Abschnitt eingegangen werden soll. Beispiele für die erfolgreich vorgenommene Standardisierung von Datenaustauschformaten für Kommunikation und Handel sollen zuletzt im abschließenden, übernächsten Abschnitt kurz umrissen werden.

2.3.3 Einflussfaktoren auf die Verbreitung von XML-Standards

Maßgeblich für den Grad der Akzeptanz, Integration und Verbreitung von Standards ist eine Vielzahl von Einflussfaktoren, deren Ausprägung einerseits von unternehmensinternen Gegebenheiten sowie andererseits extern, also durch die Beschaffenheit des Unternehmensumfelds, bestimmt wird.

Zu den internen Faktoren zählen beispielsweise

- die Existenz von bereits bewährten und einstmals entwicklungsaufwendigen, unternehmenseigenen Standards;
- Unsicherheit über den oftmals monetär nur schwer messbaren Vorteil eines neuen Standards;
- Widerstand gegen Veränderungen sowohl auf Führungsebene als auch seitens der Angestellten.

Zu den externen Faktoren zählen dagegen:

- Unsicherheit über allgemeine Verbreitung und Akzeptanz des Standards in der Branche;
- die neutrale Haltung (bzw. Ignoranz) von engen Geschäftspartnern gegenüber dem Standard;
- mangelnde Ausreifung des Standards bzw. wenig dokumentierende Berichte und Analysen über dessen Einsatz in der Praxis;
- Unsicherheit über die Haltung der Behörden oder des Gesetzgebers zum Standard, sofern der Standard nicht von diesen selbst vorgeschrieben wird [13, Rozwell, S.16ff.].

Hauptvoraussetzung für eine reibungslose Kommunikation zwischen verschiedenen Geschäftspartnern im E-Business ist, dass sich alle Beteiligten über die Bedeutung sämtlicher Bestandteile der auszutauschenden Botschaften einig sind. Diese Voraussetzung stellt eine essentielle Grundlage für die Interoperabilität zwischen den verschiedenen Systemen dar und lässt sich nur durch konsequente Standardisierung in kompletten Branchen erfüllen. In Bezug auf die Verbreitung von standardisierten XML-Technologien für E-Business-Anwendungen in kompletten Branchen lassen sich die folgenden Tendenzen zusammenfassen:

Trotz der Anstrengungen von Standardisierungsgremien kann man noch nicht davon sprechen, dass sich auf dem Gebiet des E-Business bereits ein universaler, branchenübergreifender, internationaler XML-Standard durchgesetzt hat. Dies ist offenbar zurückzuführen auf:

- die Komplexität des Gegenstands (schon einfachste Geschäftsvorgänge werden von sehr vielen unterschiedlichen Faktoren bestimmt);
- die Vielzahl an Organisationen, die sich mit solchen Standards befassen;
- den divergierenden Interessen der beteiligten Unternehmen und Konglomerate, die nicht selten versuchen, bei der Entwicklung angeblich offener Standards eigene Lösungen durchzusetzen;
- die erschwerte Orientierung für die Anwender (zumal die Marketingabteilungen involvierter Entwicklungsunternehmen oftmals versuchen, die eigentlichen Probleme in einem komplexen technologischen Umfeld durch Werbung für angeblich bereits vorhandene Lösungen zu vernebeln);
- die Überlappung und Inkompatibilität zu anderen Standards;
- die Abhängigkeit zu anderen Standards bzw. Basistechnologien (z.B. XML-Schema, SOAP), welche selbst relativ jung sind bzw. sich noch in der Entwicklung befinden.

Hinzukommt, dass Großunternehmen intern oft proprietäre Formate für automatisierte Geschäftsprozesse verwenden und wenig Anlass haben, zu XML-basierten Verfahren überzugehen, solange diese nicht vom gesamten Markt akzeptiert werden.

Trotz der Vielzahl der in diesem Abschnitt aufgezählten Hürden, ist man sich generell des allgemeinen Mehrwerts bzw. der Rationalisierungspotentiale von Standards (so auch auf Basis von XML) bewusst und arbeitet engagiert an viel versprechenden Lösungen. Einige Standardisierungsbemühungen haben sogar beste Aussicht auf Erfolg, zumal sie sich auf die bereits seit den siebziger Jahren gesammelten Erfahrungen stützen können und darüber hinaus von vielen, einflussreichen und interessierten Firmen gesponsert werden [1, Wittenbrink, S.657f.].

Der Erfolg einer Standardisierungsmaßnahme bzw. deren Aussicht auf Erfolg lässt sich auch bei XML nur im Einzelfall beurteilen. Wenngleich auch bisher noch kein universeller XML-Standard für E-Business-Anwendungen etabliert werden konnte, sei im folgenden Abschnitt zumindest eine kleine Auswahl viel versprechender, sich teilweise bereits im Einsatz befindlicher, Implementierungen exemplarisch vorgestellt.

[...]