Potential der elektronischen Datenübertragung im B2B Laborbereich

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Abkürzungsverzeichnis / Glossar

Kurzfassung

Executive Summary

1 EINLEITUNG
1.1 Problemstellung und Relevanz der Thematik
1.1.1 Medizinische Fehler
1.1.2 Kosten
1.2 Lösungsansatz: Elektronische Datenübertragung mittels standardisierter Datenformate
1.3 Zielsetzung
1.4 Anmerkung
1.5 Aufbau und Struktur

2 IST-SITUATION EINES LABORS
2.1 Einführung in den Laborbereich
2.2 Ist-EPG der Arztpraxis
2.2.1 Beschreibung der Ist-Prozesskette beim niedergelassenen Arzt
2.3 Ist-EPG des Labors
2.3.1 Beschreibung der Ist-Prozesskette im Labor
2.4 Wahrgenommene Probleme in der präanalytischen Supply-Chain
2.4.1 Problem 1: Inkorrekte Dateneingabe
2.4.2 Problem 2: Inkorrekte Auswahl der Probenröhrchen
2.4.3 Problem 3: Falsche Probenbeschriftung
2.4.4 Problem 4: Sortierung im Wareneingang
2.4.5 Problem 5: Klarheit über Daten
2.4.6 Problem 6: Dateninput
2.4.7 Problem 7: Barcodedruck und Beklebung
2.5 Resümee der wahrgenommenen Probleme

3 Gesetzliche Anforderung im Gesundheitswesen
3.1 Identität
3.2 Vertraulichkeit
3.3 Integrität
3.4 Dokumentationspflicht
3.5 Resümee

4 Grundlagen - elektronischeR Datenaustausch
4.1 EDI - Electronic Data Interchange
4.1.1 Vorteile von EDI
4.1.2 Nachteile von EDI
4.1.3 EDI-Standards
4.1.4 Funktionsweise von EDI
4.2 WEB-EDI
4.3 XML - Extensible Markup Language
4.3.1 Entwicklung von XML
4.3.2 Das Konzept von XML
4.3.3 Aufbau eines XML-Dokuments
4.3.4 Verarbeitung von XML-Dokumenten
4.3.5 Schemasprachen
4.4 XSLT – Extensible Stylesheet Language for Transformation
4.5 Architektur von Kommunikationssystemen
4.5.1 Das Internet
4.5.2 ISO/OSI-Referenzmodell
4.5.3 Schnittstellen
4.6 Sichere Datenübertragung und Informationssicherheit
4.6.1 Vertraulichkeit
4.6.2 Integrität
4.6.3 Authentizität
4.6.4 Verbindlichkeit

5 ELEKTRONISCHE DATENÜBERTRAGUNG E-HEALTH
5.1 E-Card als Wegbereiter
5.2 Health Level 7
5.3 Clinical Document Architecture
5.4 xDT
5.5 VCS
5.6 D2D

6 NUTZEN ELEKTRONISCHER DATENÜBERTRAGUNG
6.1 Soll-EPG der Arztpraxis
6.1.1 Beschreibung der Soll-Prozesskette beim niedergelassenen Arzt
6.2 Soll-EPG des Labors
6.2.1 Beschreibung der Soll-Prozesskette im Labor
6.3 Nettonutzen

7 FAZIT UND AUSBLICK

Literaturverzeichnis

8 EIDESSTATTLICHE ERKLÄRUNG

Abbildungsverzeichnis

Abbildung 1: Phasen im Prozess der Labordiagnostik

Abbildung 2: Wertschöpfungskette des Gesundheitswesens

Abbildung 3: Verwendete IT Standards im deutschen Gesundheitswesen

Abbildung 4: Ist-EPG des niedergelassenen Arztes Teil 1

Abbildung 5: Ist-EPG des niedergelassenen Arztes Teil 2

Abbildung 6: Ausschnitt aus dem Vacuette® Röhrchen Guide

Abbildung 7: Ist-EPG des Labors Teil 1

Abbildung 8: Ist-EPG des Labors Teil 2

Abbildung 9: Ausschnitt aus einem Anforderungsformular

Abbildung 10: EDI Begriffsdefinition

Abbildung 11: Ablauf Web-EDI

Abbildung 12: XML - Sprachkonzept

Abbildung 13: XML Baumstruktur

Abbildung 14: Konvertierungsprozess

Abbildung 15: Komponenten einer Transformation

Abbildung 16: Schutzziele für eine sichere Kommunikation

Abbildung 17: Asymmetrische Verschlüsselung

Abbildung 18: Kommunikation mit HL7

Abbildung 19: CDA Struktur

Abbildung 20: Soll-EPG des niedergelassenen Arztes Teil 1

Abbildung 21: Soll-EPG des niedergelassenen Arztes Teil 2

Abbildung 22: Vacuette Code System - Anforderungssoftware

Abbildung 23: Barcoderöhrchen

Abbildung 24: Kommunikationsfluss der Stakeholder

Abbildung 25: Soll-EPG des Labors Teil 1

Abbildung 26: Soll-EPG des Labors Teil 2

Tabellenverzeichnis

Tabelle 1: Informationen auf Blutproben laut CLSI-Richtlinien

Tabelle 2: Patienteninformationen im LIS des Ist-Prozesses

Tabelle 3: Spezifische Tätigkeiten im Labor

Tabelle 4: HTML versus XML

Tabelle 5: TCP/IP-Architektur

Tabelle 6: Schichten des ISO/OSI Referenzmodells

Tabelle 7: xDT Standards

Tabelle 8: VCS Sicherheitsmaßnahmen

Tabelle 9: Optimierung der Tätigkeiten im Labor

Abkürzungsverzeichnis / Glossar

Abbildung in dieser Leseprobe nicht enthalten

Kurzfassung

Das Gesundheitswesen befindet sich im Wandel. Einerseits wird versucht eine immer bessere Effizienz und Effektivität zu erreichen, andererseits werden Spar- und Reformpläne gegen die stetig steigenden Ausgaben geplant. So auch im Laborbereich, welchem eine zentrale Rolle im Gesundheitswesen zukommt.

In dieser Bakkalaureatsarbeit wird erhoben, ob der Einsatz elektronischer Datenübertragung im Laborbereich einen verbesserten Prozessablauf zulässt und die beschriebenen Problemstellungen lösen kann. Bei diesen Problemen handelte es sich beispielsweise um Fehler wie Blutprobenverwechslungen, inkorrekte Probenbeschriftungen, Verwendung falscher Probenröhrchen, den steigenden Kostendruck, erhöhten Verwaltungsaufwand usw.

Durch die Beschreibung eines Ist-Prozesses, welcher im Rahmen dieser Arbeit erhoben wurde, werden dem Leser viele dieser Probleme verdeutlicht. Im Anschluss werden die Grundlagen zum elektronischen Datenaustausch behandelt, wobei der Fokus auf die Extensible Markup Language (XML) gelegt wird. Die vorgestellten Möglichkeiten zur elektronischen Kommunikation fließen in einen Soll-Prozess, welcher dem Ist-Prozess gegenübergestellt wird. Dadurch wird ein Nettonutzen für das Labor sichtbar.

Das Ergebnis dieser Bakkalaureatsarbeit zeigt schlussendlich, dass im Laborbereich der Einsatz elektronischer Datenübertragung mittels XML in Verbindung mit vorbarcodierten Probenröhrchen einen durchgängigen Workflow erlaubt und die zu Beginn beschriebenen Probleme minimiert. Dies wird besonders am Beispiel der korrekten Identifizierung und durchgängigen Verfolgbarkeit von vorbarcodierten Blutentnahmeröhrchen ersichtlich.

Executive Summary

The healthcare sector is currently changing. Whilst on the one hand constant efforts are being made to improve efficiency and effectiveness, on the other hand cuts and plans for a reform are being made to counteract the constantly rising expenditure. This counts for the laboratory branch as well, which is beginning to play a central role in healthcare.

This bachelor thesis will examine whether the assignment of electronic data communication within the laboratory range permits an improved process cycle and thereby solve the described problems. Examples of these problems are mistakes like mixing up blood samples, incorrect labelling of samples, taking the wrong sample tubes, rising costs, increased administration expenditure and so on.

By describing an actual process, which was evaluated in the context of this work, many of these problems are clarified to the reader. Subsequently, the basics of electronic data interchange are dealt with, whereby the focus is on the Extensible Markup Language (XML). The described possibilities for electronic communication will be integrated into a target process, which is opposed to the actual process. The result of this shows a net benefit for the laboratory. This is made particularly clear with the example of correct identification and continuous traceability of pre-barcoded blood collection tubes.

The result of this bachelor thesis finally shows that within the laboratory field the adoption of electronic data communication by means of XML and use of a constant workflow in combination with pre-barcoded blood collection tubes minimizes the problems, which were described at the beginning. This is made especially clear with the example of the correct identification and continuous traceability of pre-barcoded blood collection tubes.

1 EINLEITUNG

Das Gesundheitswesen ist ein sehr wichtiger Bestandteil in unserem Leben. Menschen in diesem Bereich treten jeden Tag an um ihren Mitmenschen zu helfen. Dies geschieht zum Einen durch die Förderung und Erhaltung der Gesundheit, zum Anderen durch die Behandlung von Krankheiten und Verletzungen. Leider geschehen dort, wo Menschen arbeiten auch immer wieder Fehler. Auch im Gesundheitswesen kommt es passiert es, dass Patienten durch die vorgenommenen Behandlungen Schäden davon tragen. Während früher viele Fehler verschwiegen wurden, wird heutzutage versucht die Probleme anzusprechen. Dies wird durch Organisationen wie dem „Aktionsbündnis Patientensicherheit“ (APS) ermöglicht, indem für einen offeneren Umgang mit Irrtümern oder Beinahe-Irrtümern eingestanden wird. Es werden hierbei jedoch keine Schuldigen ausgeforscht, sondern vielmehr Strategien zur Vermeidung unerwünschter Ereignisse. Diese Bakkalaureatsarbeit behandelt ebenfalls Probleme im Laborbereich und setzt hierbei den Fokus auf die Evaluierung des möglichen Potential elektronischer Datenübertragung.

1.1 Problemstellung und Relevanz der Thematik

Das nachfolgende Kapitel 1.1 „ Problemstellung und Relevanz der Thematik “ behandelt in den nachfolgenden Punkten die Problemstellung und Relevanz der Thematik dieser Arbeit. Durch Beispiele auftretender Fehler im Gesundheitswesen sowie einer Darstellung der momentanen Kostensituation wird versucht dies zu untermauern.

1.1.1 Medizinische Fehler

Einer aktuellen Studie zufolge sterben alleine in Deutschland bis zu 17.000 Menschen aufgrund medizinischer Fehler.^[1] Diese lassen sich auf falsche Behandlungen und zu wenig sorgfältige Arbeit zurückführen. International liegt Deutschland damit im Durchschnitt. Laut einer Studie sterben in den USA jährlich sogar bis zu 98.000 Menschen aufgrund vermeidbarer Fehler. Dies würde bedeuten, dass dort mehr Menschen durch medizinische Fehler sterben, als durch Verkehrsunfälle.^[2]

Basierend auf einer Umfrage der europäischen Kommission werden medizinische Fehler von den Bürgern Eurpas als ein herausragendes Problem wahrgenommen.^[3] Doch wo treten solche Probleme auf?

Im Laborbereich, auf den der Fokus dieser Arbeit gelegt wird, kommen beispielsweise weit häufiger Fehler in der präanalytischen Phase vor, als durch analytische Messfehler entstehen.^[4]

Die präanalytische Phase, welche ein Teil des diagnostischen Prozesses ist, beginnt mit der Umsetzung der Fragestellung zur Testauswahl und endet mit der Probenvorbereitung. Der diagnostische Prozess beinhaltet weiters die analytische Phase sowie die postanalytische Phase. Die analytische Phase endet mit der Freigabe der Messergebnisse einschließlich der analytischen Qualitätskontrolle und geht mit der medizinischen Befundung und Interpretation in die postanalytische Phase über. In diesem Bereich wird der validierte Befund an den Anforderer übertragen. Dieser setzt den Befund mit seiner Erfahrung in eine ärztliche Handlung um.^[5]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Phasen im Prozess der Labordiagnostik^[6]

Laut einer Studie konnte aufgezeigt werden, dass beinahe 70% der nicht plausiblen Laborbefunde einer fehlerhaften Präanalytik nachzuweisen waren.^[7]

Fehler- und kostenintensiv sind hier vor allem jene Schritte, wo Daten manuell eingegeben werden. Dies beginnt bereits sehr früh beim niedergelassenen Arzt. Weiter sind jene Schnittstellenprozesse, welche in Abbildung 1 „ Phasen im Prozess der Labordiagnostik “ ersichtlich sind stark fehlerbehaftet. Angefangen mit dem Datenaustausch zwischen Arztpraxis und Kliniklabor, über die Probenannahme und Patientenerfassung im Labor, bis zur Befundübertragung.

Einige dieser Fehler sind^[8] :

- Falsche Patientenidentifikation
- Ungenaue oder unpassende Zeit der Blutabnahme
- Keine Abstimmung mit der Medikation
- Zu wenig Übung bei der Blutabnahme
- Verwendung des falschen Blutentnahmeröhrchens
- Falsche Reihenfolge bei der Verwendung der Röhrchen
- Unterfüllung der Röhrchen
- Prozessverzögerungen und zu lange Liegezeiten
- Keine Probenidentifikation möglich

Elektronische Durchgängigkeit wird hierbei kaum praktiziert. Während die persönlichen Daten des Patienten wie der Name, Sozialversicherungsnummer, Geburtsdatum, Versicherungsdienstleister, Geschlecht usw. noch elektronisch über die E-Card vom E-Card-Server abgerufen werden, schickt der niedergelassene Arzt die für den Patienten erforderlichen Parameter meist noch auf einem Papierformular an das Labor.^[9]

Für die im Labor stattfindenden Analysen müssen die Proben des Patienten, meist in Form von befüllten Blutentnahmeröhrchen mitgeschickt werden. Die folgenden Informationen sollten laut den internationalen Anforderungen auf dem jeweiligen Röhrchenetikett hinterlegt werden:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1: Informationen auf Blutproben laut CLSI-Richtlinien^[10]

Dies geschieht meist durch eine manuelle Beschriftung auf sehr kleinen Etiketten, wodurch es zu Leseschwierigkeiten und auch Verwechslungen kommen kann.

Um die Schwierigkeiten einzuschränken, können die Patientendaten auf dem Anforderungsdokument erfasst und mittels Barcode-Etiketten den Proben zugeordnet werden. Diese Art der Zuweisung wird durch ein spezielles Anforderungsdokument für das Blutprobenröhrchen ermöglicht, auf welchem sich Barcodeetiketten mit derselben Referenznummer befinden.

Nachdem die Daten des Patienten, sowie die notwendigen Parameter auf dem Anforderungsdokument schriftlich hinterlegt worden sind, muss das blutabnehmende Personal die angebrachten Barcodeetiketten abziehen und auf dem Blutentnahmeröhrchen korrekt aufbringen. Die Digitalisierung der Daten und elektronische Zuordnung der barcodierten Röhrchen zu den benötigten Parametern erfolgt wiederum im Labor bei der Probenannahme.

In einem interdisziplinären Forschungsprojekt im Bereich des Gesundheitswesens konnten aber selbst bei solchen Vorgängen wiederum folgende Fehler beobachtet werden^[11] :

- Falsche Zuordnung der Probe zu den Laboranforderungen
- Nicht etikettierte Proben
- Falsch etikettierte Proben

Der Verwaltungsaufwand und das durch diesen Prozess entstehende Fehlerpotential ist enorm, zumal handschriftliche Aufzeichnungen häufig unleserlich sind und keine computerunterstützte Überwachung vorhanden ist, um Fehler bei den Anforderungen an das Labor zu vermeiden. Der anwachsende Verwaltungsaufwand, welcher durch die gesetzlich vorgeschriebene Dokumentation verstärkt wird, wirkt sich wiederum in den Kosten aus.

1.1.2 Kosten

Weltweit steigen die Kosten im Gesundheitswesen sukzessive an. Pro österreichischem Einwohner sind beispielsweise die Kosten von 2.020 Euro im Jahr 1992 auf 2.740 Euro im Jahr 2001 angestiegen.^[12] Die letzten Zahlen von Statistik Austria sagen aus, dass 27.453 Millionen Euro insgesamt an Gesundheitsausgaben für das Jahr 2007 ausgegeben worden sind. Dies sind umgerechnet 10,1% des österreichischen Bruttoinlandsprodukts.^[13]

In Dänemark, kommen hingegen die Kosten des Gesundheitswesens unter anderem durch gekonnten Einsatz von Informations- und Kommunikationstechnologien, also mittels Anwendung von E-Health, auf 9% des Bruttoinlandsprodukts.^[14] Auf Österreich umgerechnet würde dieser Prozentsatz eine Einsparung von immerhin fast 3 Milliarden Euro im Jahr bedeuten.

In Deutschland wird durch eine Honorarreform, welche mit 01. Jänner 2009 in Kraft getreten ist, versucht Kosten einzusparen und dabei den maroden Krankenkasse zu helfen.^[15] Durch diese Einsparungen erhalten die Ärzte weniger Geld für Untersuchungen, müssen jedoch mehr Zeit für verwaltungstechnische Aufgaben, wie der direkten Abrechnung mit der Krankenkasse aufwenden.^[16]

Um den ständig steigenden Kostendruck, höherem Verwaltungsaufwand, steigenden Probenaufkommen, hohen Sicherheitsanforderungen uvm. gewachsen zu sein, ist eine Automatisierung sinnvoll. Diese Automatisierung ermöglicht einen erhöhten Probendurchsatz bei verringerter Personalbindung und verkürzt mittlere Bearbeitungszeit. Neben der Kosten- und Zeitersparnis kann durch Standardisierung das Laborpersonal von wiederkehrenden Routinetätigkeiten entlastet werden.^[17]

In der Schweiz wird seit kurzem periodisch überprüft, ob die Ärzte ihre Labors wirksam, zweckmäßig und wirtschaftlich führen. Weiters wurden die Tarife für die Analysen abgeändert, wobei diese noch immer markant höher sind als in Deutschland oder Österreich.^[18]

Die Analyse eines Kreatininwertes beispielsweise bringt in der Schweiz etwa 8 Franken (etwa 5,26 Euro), in Österreich 3,50 Euro, in Frankreich 3 Euro und in Deutschland nur noch 25 Cent.^[19]

Der Einsatz von modernen Medien und Technologien wird somit auch im Bereich des Gesundheitswesen immer mehr zu einem gewichtigen Faktor um Kosten zu senken, wirtschaftlich arbeiten zu können und schlussendlich auch Arbeitsplätze zu sichern. Die Patienten und deren Sicherheit dürfen dabei nicht vernachlässigt werden.

Hier wird vor allem auf das Rationalisierungspotential im Bereich der Datenerfassungs- und Kommunikationsleistungen gesetzt, zumal dies zwischen 20 und 40% der Leistungen im Gesundheitswesen ausmacht.^[20]

1.2 Lösungsansatz: Elektronische Datenübertragung mittels standardisierter Datenformate

“Improved communication between the end-user clinicans and the laboratory pathologists is one of the most important means of reducing what has been called laboratory errors.”^[21]

Die Labormedizin ist ein hochtechnisierter Bereich, indem die Nutzung moderner Kommunikationstechnik für interne und externe Abläufe sehr wichtig ist. Aus der Sicht der Wertschöpfungskette ist das Labor hierbei eindeutig ein Leistungserbringer, welcher mit Ärzten, Spitälern, Apotheken, Produzenten und Versicherern vernetzt ist und kommuniziert.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Wertschöpfungskette des Gesundheitswesens^[22]

Wie in der Abbildung 2 ersichtlich wird, findet ein durchgängiger Informationsfluss, angefangen vom Produzenten, über die Leistungserbringer im Gesundheitswesen bis zum Versicherungsträger statt. Die zunehmende elektronische Datenverarbeitung hilft dabei den administrativen Aufwand zu senken und medizinisches Personal zu entlasten. Voraussetzungen dafür sind jedoch einheitliche und genormte Formate.^[23]

Diese sind notwendig um medizinische Informationen rascher übermitteln zu können und weniger Bearbeitungsaufwand beim Austausch von Patienteninformationen zwischen den Partnern im Gesundheitswesen zu generieren. Berechtigte Dritte können die eingesetzten Nachrichten dadurch auch leichter warten. Der Einsatz von Standardnachrichten spielt somit für einen einheitlichen und ökonomischen elektronischen Datenaustausch eine wesentliche Rolle, damit in sich autonome Systeme miteinander einwandfrei kommunizieren können.^[24]

Im Gesundheitsweisen wurde die Notwendigkeit der Verwendung einheitlicher standardisierter Datenformate für die elektronische Datenübertragung bereits erkannt und existiert bereits in verschiedensten Lösungsansätzen. Im Laufe der Zeit haben sich, wie die nachfolgende Abbildung aufzeigen soll, unterschiedlichste Formen entwickelt. Diese werden jeweiligen Bereichen des Gesundheitswesens eingesetzt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Verwendete IT Standards im deutschen Gesundheitswesen^[25]

Der Einsatz von elektronischen Workflows und einheitlicher Datenformate im Laborbereich ist jedoch noch nicht durchgängig standardisiert worden.

1.3 Zielsetzung

Wie in der Einleitung beschrieben, entstehen im Bereich der Datenübertragung zwischen Labor und niedergelassenem Arzt viele Fehler und hohe Kosten. Durch diese Arbeit soll festgestellt werden, ob die Einführung eines vollständig EDV-gestützten Worfklows, basierend auf der elektronischen Datenübertragung mittels XML, das Potential besitzt, die erwähnten Fehler zu vermeiden oder zu mindern und dabei Kosten einzusparen.

Hierzu ist es notwendig die technologische Seite der elektronischen Datenübertragung näher zu betrachten. Da im Gesundheitswesen die Art der Datenübertragung und Kommunikation zwischen den Stakeholdern eine wesentliche Rolle spielt, sollen die bestehenden Möglichkeiten der elektronischen Datenübertragung für den Laborbereich näher beleuchtet werden, um feststellen zu können, ob bereits eine passende Technologie zum Datenaustausch vorhanden ist.

Weiters soll aufzeigt werden, ob sich die bestehenden Möglichkeiten mit den hohen Anforderungen der Datensicherheit und gesetzlichen Ansprüchen decken. Dazu soll ein Blick auf die gesetzlichen Anforderungen geworfen werden.

Zum besseren Verständnis soll eine Ist-Situation mittels eines ereignisorientierten Prozessgraphen dargestellt und erklärt werden. Diese Ist-Situation soll abschließend durch die elektronische Datenübertragung ergänzt werden, um somit das Potential dieser Technologie analysieren zu können.

Nicht-Ziel dieser Arbeit ist es, die Vor- und Nachteile der verschiedenen Technologien gegenüberzustellen. Auch auf die Implementierung eines Systems für die elektronische Datenübertragung soll nicht eingegangen werden.

1.4 Anmerkung

In dieser Arbeit wird auf eine bewusste geschlechtsspezifische Formulierung verzichtet, um eine leichtere Lesbarkeit zu erzielen. Verwendete maskuline Ausdrücke und Formulierungen sind daher immer an beide Geschlechter gerichtet.

1.5 Aufbau und Struktur

Kapitel 1, Einleitung

Die Einleitung behandelt die Problemstellung und Relevanz der Thematik. Neben

den medizinischen Fehlern und Kosten im Gesundheitswesen wird die momentane

Problematik der Datenübertragung im Laborbereich beschrieben.

Kapitel 2, Ist-Situation eines Labors

Zeigt auf Basis eines ereignisorientierten Prozessgraphen (EPG) eine momentane Labor Ist-Situation auf und beleuchtet dabei die Schwächen und Probleme des dargestellten Prozesses, wobei der Fokus auf den Datenaustausch mit etwaigen Stakeholdern gerichtet ist.

Kapitel 3, Gesetzliche Anforderung im Gesundheitswesen

Betrachtet die gesetzlichen Anforderungen, welche für den Datenaustausch zwischen Labor und niedergelassenem Arzt relevant sind.

Kapitel 4, Grundlagen – Elektronischer Datenaustausch

Dieser Teil behandelt die Grundlagen der elektronischen Datenübertragung und

stellt dabei die historische Entwicklung dieser dar.

Kapitel 5, Elektronische Datenübertragung E-Health

Erklärt welche Arten der elektronischen Datenübertragung im B2B Bereich und speziell im Gesundheitsbereich angewendet werden, sowie welche Standards hierfür wichtig sind.

Kapitel 6, Nutzen elektronischer Datenübertragung

Zeigt die Vorteile und Möglichkeiten der elektronischen Datenübertragung in einem Soll-Prozess auf. Der dadurch entstehende Prozess wird durch eine EPG dargestellt. Durch einen Vergleich mit dem Ist-Prozess kann der entstandene Nutzen herausgearbeitet werden.

Kapitel 7, Ausblick

Mit Fokus auf das Gesundheitswesen, wird hier ein Blick auf die zukünftige Entwicklung des elektronischen Datenaustausches geworfen.

2 IST-SITUATION EINES LABORS

Ziel dieses Kapitels ist es aufzuzeigen, wie momentan in vielen Laboren gearbeitet wird und dadurch die Probleme und Schwächen anhand einer Ist-Situation darzustellen. Die wahrgenommenen Probleme werden in Form eines Blitzes in der EPG dargestellt und im Kapitel 2.4 „ Wahrgenommene Probleme in der präanalytischen Supply-Chain “ erläutert.

2.1 Einführung in den Laborbereich

Noch ist der europäischen Laborbereich zersplittert. Während es in Frankreich etwa 4.500 Labore gibt, sind es in Deutschland bereits nur noch 50 bis 100. Dabei setzten die deutschen Einrichtungen rund 6 Milliarden Euro im Jahr 2007 um, wovon 3,35 Milliarden Euro die gesetzlichen Krankenkassen bezahlt haben.^[26]

Labore verdienen ihr Geld vor allem durch die Analyse und anschließende Bereitstellung von Messwerten. Die Erstellung eines Laborbefundes erfolgt nach Abschluss der analytischen Phase. Laborbefunde werden zur Diagnosefindung, zur Prognosebeurteilung und zur Therapiekontrolle angefordert und erstellt.^[27]

Wie der niedergelassene Arzt nun einen Laborbefund für seinen Patienten erhält, wird durch den folgenden ereignisgesteuerten Prozessgraph (EPG) dargestellt. Dieser basiert auf einem realen Vorgang in einem österreichischen Labor und einem dessen Zusender. Im Rahmen dieser Arbeit wurden die in der EPG dargestellten Prozesse vom Autor erhoben.

2.2 Ist-EPG der Arztpraxis

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Ist-EPG des niedergelassenen Arztes Teil 1^[28]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Ist-EPG des niedergelassenen Arztes Teil 2^[29]

2.2.1 Beschreibung der Ist-Prozesskette beim niedergelassenen Arzt

Der erste Teil der EPG beginnt mit dem niedergelassenen Arzt. Der Patient registriert sich zu Beginn mit seiner E-Card, wodurch dem niedergelassenem Arzt zahlungsrelevante Daten des Patienten bekannt werden. Da es bis jetzt in Österreich keine gemeinsame Datenbank mit den gesammelten Patientendaten und deren Krankengeschichte gibt, muss der Arzt auf die lokal abgespeicherte Patientenhistorie zugreifen. Nach dem der Arzt die Krankengeschichte sowie die Beschwerden des Patienten kennt, beginnt die eigentliche Untersuchung. Diese umfasst eine Blutabnahme, wenn der Arzt mehr Informationen über Zustand bzw. das Blutbild des Patienten erfahren möchte.

Für die Blutabnahme werden evakuierte Blutentnahmeröhrchen verwendet. Diese zeichnen sich durch verschiedenen Additive und Füllvolumen aus. Durch die Bezeichnung auf den Etiketten sowie durch Kappen- und Ringfarbe können diese differenziert werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Ausschnitt aus dem Vacuette® Röhrchen Guide^[30]

Nach der Blutabnahme, müssen die Röhrchen beschriftet werden um diese dem Anforderungsschein, auf welchem die benötigten Parameter händisch markiert worden sind, zuordnen zu können.^[31] Röhrchen und ausgefüllter Anforderungsschein werden nun zusammen in einen Beutel gesteckt und mittels Kurier zum Labor befördert.

2.3 Ist-EPG des Labors

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7: Ist-EPG des Labors Teil 1^[32]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 8: Ist-EPG des Labors Teil 2^[33]

2.3.1 Beschreibung der Ist-Prozesskette im Labor

Nach der Probenanlieferung durch den Kurier, werden die Röhrchen und Anforderungsscheine in Empfang genommen. Die Röhrchen werden in spezielle Aufnahmen (Racks) gestellt und die dazugehörigen Anforderungsscheine dazugelegt.

Anhand der Anforderungsscheine und markierten Parameter wird nun überprüft, ob alle Probenröhrchen vorhanden sind. Weiters werden die am Anforderungsschein hinterlegten Informationen auf Lesbarkeit und Vollständigkeit kontrolliert, um diese dann im Laborinformationssystem zu hinterlegen. Folgende Informationen werden dabei abgespeichert:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2: Patienteninformationen im LIS des Ist-Prozesses

Sind die Daten des Patienten bereits im System hinterlegt, müssen nur noch die Parameter eingegeben werden. Aufgrund der hinterlegten Informationen werden vom System Barcodeetiketten generiert. Diese werden auf die Probenröhrchen geklebt. Hierbei findet nochmals eine Überprüfung und Vergleich des Patientennamen am ursprünglichen Röhrchenetikett und dem im Labor ausgedruckten Barcodeetikett statt.

Werden zu viele oder zu wenige Proben angeliefert, falsche Röhrchen für gewisse Parameter eingeschickt, Anforderungsscheine unleserlich ausgefüllt oder Parameter nicht von der Krankenkasse gedeckt, wird eine Problembehandlungsstelle aktiv und kontaktiert den jeweiligen niedergelassenen Arzt.

Sind Probenröhrchen noch nicht zentrifugiert worden, so wird dies nun nachgeholt. Nach der Zentrifugation werden die Röhrchen in die für die jeweiligen Instrumente vorgesehenen Racks gestellt. Diese werden vom zuständigen medizinischen Personal abgeholt, um mit der Analyse an den Instrumenten beginnen zu können.

Nach der Analyse an den Instrumenten werden die Ergebnisse in Form einer technischen Validierung vom medizinischen Personal auf Plausibilität mit vorangegangenen Untersuchungen und Standardwerten überprüft.^[34]

Die Ergebnisse werden dem verantwortlichen Laborarzt zur medizinischen Validierung weitergeleitet. Danach werden die Resultate an den jeweiligen niedergelassenen Arzt via Post, E-Mail oder Fax geschickt. Mit diesen Informationen können die korrekte Behandlung und Medikation des Patienten festgelegt werden.

Bei diesem Prozess beträgt das Probenvolumen 1.266 Röhrchen am Tag (255 Arbeitstage). Die für die elektronische Datenübertragung relevanten Prozesse werden hierbei von durchschnittlich 9 Personen betreut. Dies setzt sich aus folgenden Tätigkeiten zusammen:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3: Spezifische Tätigkeiten im Labor^[35]

1.1 Wahrgenommene Probleme in der präanalytischen Supply-Chain

Die Identifikation des Patienten in Österreich und anderen Ländern funktioniert bereits seit einigen Jahren mittels E-Card, der elektronischen Krankenversicherungskarte. Während also die Überprüfung des Patienten auf dessen Versicherungsschutz auf elektronischem Wege stattfindet, wird bereits kurze Zeit später wieder analog kommuniziert. In den nachfolgenden Punkten, wird näher auf diese Probleme eingegangen, welche in den vorangegangenen Abbildungen zur Darstellung der Ist-Prozesse mittels Blitzen (Problemstellen) gekennzeichnet worden.

1.1.1 Problem 1: Inkorrekte Dateneingabe

Die kurz zuvor elektronisch abgefragten Patientendaten werden händisch auf einen Anforderungsschein übertragen und die notwendigen Parameter mittels Ankreuzen definiert. Durch das händische Auswahlverfahren und der Datenhinterlegung auf dem Anforderungsscheines kann es rasch zu Schreibfehlern kommen bzw. der Auswahl von falschen Parametern.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 9: Ausschnitt aus einem Anforderungsformular^[36]

Nachdem der Anforderungsschein ausgefüllt und die Parameter ausgewählt wurden, wird die Blutabnahme vorbereitet.

1.1.2 Problem 2: Inkorrekte Auswahl der Probenröhrchen

Für die Blutabnahme muss das blutabnehmende Personal die korrekten Probenröhrchen auswählen. Dabei kann es geschehen, dass die falschen Röhrchen für die benötigten Parameter verwendet werden. Sollten die Röhrchen abgelaufen sein würde dies dazu führen, dass zu wenig Unterdruck vorhanden ist und dadurch zu wenig Blut angesaugt wird. Auch dadurch kann es zu späteren Problem bei der Analyse kommen.

1.1.3 Problem 3: Falsche Probenbeschriftung

Die Blutentnahmeröhrchen werden händisch beschriftet, um somit die Grundlage für Laboranforderungen zu bilden. Da die durchschnittliche Etikettenfläche für das Namensfeld, das Geburtsdatum, die Referenznummer, das Datum, die Zeit der Abnahme sowie die Unterschrift des blutabnehmenden Personals in den meisten Fällen nur 50 x 27 Millimeter beträgt, kann es rasch passieren, dass Daten unleserlich hinterlegt werden bzw. Daten fehlen.

1.1.4 Problem 4: Sortierung im Wareneingang

Sind die Blutentnahmeröhrchen mit den Anforderungsscheinen im Labor angekommen, werden diese meist manuell sortiert, wobei sich das Laborpersonal auf die händisch hinterlegten Informationen verlassen muss. Die Sortierung und Zuordnung der Röhrchen im Wareneingang ist sehr zeitaufwändig und erfolgt über den ganzen Tag verteilt.

1.1.5 Problem 5: Klarheit über Daten

Sind die Daten nicht lesbar oder uneindeutig muss der niedergelassene Arzt kontaktiert werden und es erfolgt eine Klarstellung. Eine Rückfrage beim niedergelassenen Arzt wird auch im Falle von jenen Parametern durchgeführt, welche nicht von der Krankenkasse gedeckt sind und der Patient selbst finanzieren müsste.

1.1.6 Problem 6: Dateninput

Sobald die Korrektheit der Informationen mittels hohem Aufwand sichergestellt ist, werden die Daten zum Patienten und die erforderlichen Parameter in das Laborinformationssystem (LIS) eingepflegt, was wiederum einen hohen Zeitbedarf erfordert.

1.1.7 Problem 7: Barcodedruck und Beklebung

Durch die Eingabe der Parameter druckt das LIS die für die Analyseinstrumente notwendigen Barcodeetiketten aus. Diese müssen nun per Hand auf die Röhrchen geklebt werden. Dabei wird darauf geachtet, dass die richtigen Barcodeetiketten auf die dazugehörigen Blutröhrchen geklebt werden. Kommt es hierbei zu einer falschen Zuweisung, würden die Ergebnisse der Blutproben dem falschen Patienten zugeordnet werden. Dies würde wiederum zu falschen Diagnosen und Behandlungen führen, die sich schwerwiegend auf die Gesundheit des Patienten auswirken können. Die dabei entstehenden Kosten sind ebenfalls nicht zu vernachlässigen.

Eine Verwechslung tritt aufgrund von Stresssituation und ähnlichen Gründen jedoch immer wieder auf. Die verzögerte Informationsweitergabe und der verursachte Mehraufwand durch die erneute Datenerfassung, führt wiederum zu erwähnten Stresssituationen.^[37]

1.2 Resümee der wahrgenommenen Probleme

Identifikationsfehler spielen eine zentrale Rolle im Bereich der Blutabnahme und Präanalytik. Eine Vermeidung dieser Fehler kann dabei v.a. durch höhere Achtsamkeit, Verwendung verschiedener Identifikatoren, dem Einsatz moderner Technologien und Barcodes entgegengewirkt werden.^[38]

Auch die gesetzlichen Anforderungen werden dahingehend ausgerichtet. Fehler sollen vermieden, Durchlaufzeiten verkürzt und Kosten gesenkt werden. Dies wird in vielen Bereichen unseres Lebens bereits mittels durchgängigem elektronischen Datenaustausch realisiert. Im Gesundheitswesen muss sich die elektronischer Kommunikation dabei ebenfalls hohen Anforderungen stellen.

2 Gesetzliche Anforderung im Gesundheitswesen

Um die Anforderungen des Gesundheitswesens im Bereich des Datenaustausches besser verstehen zu können, wird in diesem Kapitel ein kurzer Überblick zu den gesetzlichen Forderungen gegeben. Um dies einzugrenzen, wird der Fokus auf die österreichische Gesundheitstelematikverordnung gesetzt.

Die neue österreichische Gesundheitstelematikverordnung, welche mit 1. Jänner 2009 in Kraft getreten ist, sieht vor, dass Gesundheitsdaten zukünftig nur noch über sichere Netze ausgetauscht werden dürfen. Dies bedeutet, das die Labore, Ärzte, Krankenhäuser und Kuranstalten gewisse Schutzmaßnahmen für die Patientendaten in der IT einführen müssen. Ab 2012 soll es beispielsweise als fahrlässig gelten, personenbezogene Gesundheitsdaten via Fax und unverschlüsselten E-Mail zu versenden.^[39] Die neue Ordnung orientiert sich an der international gültigen ISO Norm 27001 und basiert aus folgenden Schwerpunkten:^[40] :

2.1 Identität

Der Gesundheitsdiensteanbieter, welcher beispielsweise der Laborarzt sein kann, muss seine Identität nachweisen. Dies kann einerseits durch die Verwendung elektronischer Signaturen sowie bereichsspezifischer Personenkennzeichen erfolgen. Durch eine Einsichtnahme im E-Health-Verzeichnisdienst ist eine Überprüfung möglich.

Eine Abweichung der oben angeführten Identitätsüberprüfung ist möglich, wenn ein elektronischer Datenaustausch stattfindet und eine Verwechslung von Gesundheitsdiensteanbietern ausgeschlossen werden kann.

2.2 Vertraulichkeit

Die Vertraulichkeit beim elektronischen Datenaustausch soll dadurch sichergestellt werden, dass die verwendeten Netzwerke hinreichend gegenüber unbefugten Zugriffen abgesichert sind. Dies kann einerseits durch eine kryptographische Absicherung des Datenverkehrs, einen begrenzten Netzzugang sowie durch eine Authentifizierung der Benutzer erfolgen. Weiters können Verfahren und Protokolle verwendet werden, welche eine vollständige Verschlüsselung der Gesundheitsdaten ermöglichen.

2.3 Integrität

Die Integrität der elektronisch übermittelten Gesundheitsdaten, soll durch die Verwendung elektronischer Signaturen, welche auf qualifizierbare Zertifikate rückführbar sein müssen, nachgewiesen werden können und überprüfbar sein. Werden die Daten über ein gesichertes Netzwerk übermittelt, ist eine elektronische Signatur nicht notwendig.

2.4 Dokumentationspflicht

Die Dokumentationspflicht umfasst vor allem die Datensicherheitsmaßnahmen, welche vom jeweiligen Gesundheitsdiensteanbieter etabliert werden. Diese betreffen die wirksamen Mechanismen und Kontrollen zur Sicherstellung der Datenschutz- und Datensicherheitspflichten.

2.5 Resümee

Aufgrund der neuen Verordnungen im Bereich der Gesundheitstelematik werden erste Anzeichen sichtbar, dass eine elektronische Datenübertragung und Kommunikation im Gesundheitswesen eine immer größer werdende Rolle spielt. Besonders im Bereich der Datensicherheit und des Datenschutzes wird durch das Gesetz ein Rahmen und damit die Vorraussetzung für den geordneten Einsatz des elektronischen Datenaustausches geschaffen. Folglich wirkt sich dieser Einfluss auf die für den elektronischen wirkt.

3 Grundlagen - elektronischeR Datenaustausch

Das Ziel dieses Kapitels ist es, auf die Grundlagen des elektronischen Datenaustausches einzugehen und die geschichtliche Entwicklung von XML und dessen Eigenschaften darzustellen. Dadurch soll der Leser die Möglichkeit erhalten ein abgerundetes Bild zu dieser Thematik sowie ein technisches Grundverständnis für den später dargestellten Soll-Prozess zu erhalten.

3.1 EDI - Electronic Data Interchange

Die Erkenntnis, dass ein Großteil der zwischen- und innerbetrieblichen Kommunikation schriftlich über mehrere Stationen verläuft, dabei mehrmals ausgedruckt und wieder eingegeben wird, motivierte dazu einen durchgängig elektronischen Datenaustausch zu entwickeln.^[41] Der elektronische Datenaustausch erreichte dabei durch die gewollte Automatisierung der Geschäftsprozesse zwischen verschiedenen Unternehmen, Branchen und Ländern einen immer höheren Stellenwert. Seit den 1960er Jahren entwickelten die Vereinten Nationen aus diesem Grund den Standard EDI (Electronic Data Interchange), welcher einen Austausch von strukturierten Geschäftsdaten zwischen verschiedenen Anwendungen ermöglichte.^[42]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 10: EDI Begriffsdefinition^[43]

EDI ermöglicht eine automatische Weiterverarbeitung von Geschäftsfällen und Geschäftsnachrichten, wobei dies unabhängig von Hardware, Software und Kommunikationsnetzen funktioniert.

3.1.1 Vorteile von EDI

Geschäftspartner haben mit EDI die Möglichkeit, direkt zwischen ihren Systemen zu kommunizieren und somit Prozesse zu automatisieren. Die anfallenden Kosten der Dokumentenverarbeitung sowie Durchlaufzeiten können reduziert werden. Eine allgemeine Einsparung bei den Kommunikationskosten wird erreicht.^[44]

Da Informationen bereits digital am Rechner vorhanden sind, kommt es weiters zu einer Reduzierung des manuellen Erfassungsaufwandes. Auch die Fehlerhäufigkeit, welche unter anderem mit der wiederholten Dateneingabe verbunden ist, wird herabgesetzt.

Durch integrierte EDI-Abläufe wird erreicht Stoßzeiten effektiver zu bewältigen und dabei keine nennenswerten Mehrkosten zu schaffen.^[45]

Die sofortige Verfügbarkeit und automatisierte Verwendung der Daten ermöglicht auch eine Automatisierung der Abläufe verschiedenster Geschäftsprozesse. Ein Beispiel wäre hierbei eine Just-in-Time Produktion, bei der ein Unternehmen seine Lagerhaltung drastisch reduziert, die Kapitalbindung senkt, rascher auf Wettbewerbsverhältnisse reagiert und dabei noch die Kundenzufriedenheit steigert.

3.1.2 Nachteile von EDI

Trotz dieser genannten Vorteile nutzen relativ wenig Unternehmen tatsächlich EDI.

Der Hauptgrund liegt vor allem an den erheblichen Setup- und Betriebskosten der traditionellen EDI-Lösungen, welche für kleine und mittelständische Unternehmen anfallen würden. Auch die lange Zeit vorherrschende Unsicherheit über einen gemeinsamen Standard und die damit verbundenen Koordinationskosten bilateraler Implementierungsvereinbarungen bremsten den Einsatz von EDI.

Weitere Kosten fallen durch die aufwendigen Anpassungen an die jeweils verwendeten Standards der Kommunikationspartner bzw. an die eigenen Systeme an. Notwendige EDI-Konverter, welche Daten aus den firmeninternen Anwendungsprogrammen in genormte Datenformate wandeln, sind sehr teuer und oftmals nicht für die gewünschte Plattform verfügbar. Die Folge der aufgezählten Probleme ist, dass Geschäftsdokumente meist nicht durch die gesamte Wertkette hindurch elektronisch weiterverarbeitet werden können.^[46]

3.1.3 EDI-Standards

Um Geschäftsdaten elektronisch austauschen zu können, ist es notwendig Vereinbarungen zu treffen, wie der Aufbau einer solchen Nachricht auszusehen hat und in welcher Reihenfolge die Daten übermittelt werden. Der Computer kann dadurch über eine entsprechende Software die Struktur der Nachricht erfassen, korrekt interpretieren und verarbeiten. Die Komplexität und Schwierigkeit der EDI-Techniken führte aber zu einer Zersplitterung der EDI-Welt. Dabei entstanden viele Teilimplementierungen und Standards in bestimmten Branchen.^[47]

3.1.4 Funktionsweise von EDI

Die Funktionsweise von EDI funktioniert dadurch, dass über eine definierte Schnittstelle zwischen Anwendungssystem (z.B.: ERP-System) und EDI-System Nachrichten auf Basis gemeinsamer Regeln an das EDI-System übertragen werden. Die Nachrichten werden über einen EDI-Konverter in ein normiertes Format (z.B.: EDIFACT) gewandelt. Ist dies geschehen, wird eine Kommunikationsverbindung zum jeweiligen Partner aufgebaut und die Datenübertragung findet statt.^[48]

Diese Art der Datenübertragung von EDI-Nachrichten bedingt jedoch die bereits erwähnte Verwendung von VANs, die einen bedeutenden Kostenfaktor darstellen. Um eine Kostenreduzierung zu erreichen, wurde aus diesem Grund das Internet als neues Transportmedium entdeckt und eingesetzt.^[49]

3.2 WEB-EDI

EDI ist nun seit mehr als 40 Jahre im Einsatz. Die Verbreitung war aufgrund von hohen Kosten der EDI-Server-Systeme, wie auch hohen Preisen bei der Verwendung von VANs (Value added Netzworks) stets limitiert. Durch die Verwendung des Internet wurden einige dieser Nachteile eliminiert. Es ist kein VAN mehr notwendig und eine Verwendung von neuen Sprachen (Markup Languages), wie beispielsweise XML, ist möglich.^[50]

Bei Web-EDI bieten größere Handelsunternehmen zumeist kleineren Lieferanten die Möglichkeit, sich mittels eines Browsers auf einem speziell für das Web-EDI eingerichteten Web-Server einzuloggen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 11: Ablauf Web-EDI

Auf diesem Web-Server werden vom Kunden WWW-Server Formulare bereitgestellt, welche beispielsweise Bestellungen oder Rechnungen abbilden. Das Partnerunternehmen kann diese Formulare über das Internet in einen WWW-Browser runterladen, lesen, speichern und ausdrucken. Für eine Antwort werden die Formulare über den Browser ausgefüllt und an den Kunden zurückgeschickt. Bei diesem werden die Daten über eine EDI-Schnittstelle direkt in das ERP-System eingepflegt.

Die Datenintegration im Sinne von EDI wird somit im Grunde nur einseitig betrieben, da der Partner ohne EDI-System die zu versendenden Daten manuell einpflegen muss. Um die Informationen vor Dritten zu schützen, werden diese mit einem symmetrischen oder asymmetrischen Schlüssel verschlüsselt. Diese Verschlüsselung lässt sich nur vom Inhaber des passenden Schlüssel entschlüsseln. All dies basiert auf der Verwendung des Internets.

3.3 XML - Extensible Markup Language

„XML ist in aller Munde. Keine andere Technologie hat die IT-Welt so schnell erobert wie diese.“^[51]

XML wurde im Februar 1998 normiert und galt bereits 2000 als die neue Verkehrssprache des E-Business. Ein Grund für diesen Hype ist sicherlich jener, dass XML plattform-unabhängig verwendet werden kann. Ein anderer Grund wird jener sein, dass alle großen Stakeholder im EDV-Bereich mit dieser Sprache arbeiten können und arbeiten lassen.^[52]

3.3.1 Entwicklung von XML

Seinen Anfang nahm XML als Abkömmling von SGML. Bei SGML handelt es sich um ein reines Textformat, einer in der ISO 8870 festgelegten Sprache. Grundidee hinter dieser Sprache ist es die Dokumentenstruktur und Dokumentendarstellung zu trennen. Während die Dokumentenstruktur die logische Gliederung und gegenseitige Abhängigkeit beschreibt, geht die Dokumentendarstellung auf die Formatierung ein. Durch die Trennung des Layouts und der Struktur wird eine Wiederverwendbarkeit beider Komponenten erreicht was zu einer effizienteren Dokumentenerstellung führt.^[53]

SGML erlaubt den Austausch von großen und komplexen Datenmengen und vereinfacht den Zugriff darauf. Zusätzlich besitzen die SGML-Systeme ein Dokumentenmodell, welches eine Überprüfung der Gültigkeit eines Textelementes erlaubt.^[54]

Den größten Erfolg konnte SGML mit HTML, welches von Tim Burners Lee erfunden wurde, verbuchen. HTML stellt jenes standardisierte Format dar, in dem Text- und Hypertextinformationen im WWW gespeichert und übertragen werden können.^[55]

Es hat die Aufgabe die logischen Bestandteile eines textorientierten Dokumentes zu beschreiben und geht hierbei von einer hierarchischen Gliederung aus. Der eigentliche Inhalt besteht aus Elementen wie beispielsweise einer Überschrift, Textabsätzen, Tabellen und Grafiken. Auszeichnungen markieren Anfang und Ende solcher Elemente. Diese Auszeichnungsmarkierungen werden von Webbrowser aufgelöst und die HTML-Dateien können in optisch gut erkennbarer Form dargestellt werden. HTML wie auch XML stellen dabei eine Art Untermenge von SGML dar.^[56] Mit XML sollte eine einfachere Metasprache entwickelt werden. Es wird aus diesem Grund behauptet, das XML 80% der Mächtigkeit von SGML hat, aber nur 20% von dessen Komplexität.^[57]

3.3.2 Das Konzept von XML

XML stellt eine vom World Wide Web Consortium standardisierte Auszeichnungssprache für das Definieren von Dokumententypen dar, in denen textbasierte, hierarchisch aufgebaute Daten erfasst werden können und auch vom Menschen lesbar sind. Das bedeutet, dass XML die Regeln vorgibt, welche beim Definieren von Dokumententypen angewendet werden. Unter Dokumententyp versteht man Dokumente, welche eine ähnliche Struktur aufweisen und dadurch dem selben Typ angehören. HTML Dokumente gehören beispielsweise dem Dokumententyp HTML an.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 12: XML - Sprachkonzept^[58]

Prinzipiell basiert XML auf der Trennung von Inhalt, Struktur und Layout. Dabei unterscheidet sich XML auf den ersten Blick nicht von HTML-Dokumenten. Auf den zweiten Blick wird ersichtlich, dass bei XML-Dokumenten beliebig viele und frei benannte Tags (Wörter innerhalb von "" und "") verwendet werden können, während bei HTML die Anzahl und Benennung der Tags vorgegeben ist.^[59]

Durch XML wird dafür gesorgt, dass Dokumente nach gewissen Grundmustern aufgebaut sind und dadurch Programme geschrieben werden können, welche diese Dokumente automatisch verarbeiten. Bei Dokumenten, welche keinem Regelwerk folgen, ist eine solche Automatisierung schwierig umzusetzen, da es immer wieder zu Anpassungen kommen müsste.^[60]

3.3.3 Aufbau eines XML-Dokuments

Basierend auf dem Unicode-Zeichensatz, werden XML Dokumente als reine Textdateien gespeichert. Dadurch können diese Dateien mit jedem beliebigen Texteditor geöffnet und ggf. bearbeitet werden. Die Daten werden weiters mittels Auszeichnungen, den so genannten „Marken“ versehen. Aufgrund dieser Auszeichnungen können Computerprogramme interpretieren, um welche Daten es sich handelt. Ein einfaches Beispiel, welches den Unterschied im Aufbau zu HTML zeigt wird in Tabelle 4 „ HTML versus XML “ dargestellt.^[61]

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 4: HTML versus XML

XML Dokumente haben die Eigenschaft einer logisch aufgebauten Baumstruktur, welche auch hierarchisch gegliedert ist.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 13: XML Baumstruktur^[62]

Die Baumknoten einer solchen Struktur lassen sich wie folgt darstellen^[63] :

- Elemente : Die physische Auszeichnung erfolgt bei den Elementen mittels einem passenden Paar aus Start-Tag (Tag-Name) und einem Ende-Tag (/Tag-Name) wie auch einem Empty-Element-Tag (Tag-Name/).
- Attribute : stellen zusätzliche Informationen zu Elementen dar. Diese werden bei einem Start-Tag oder Empty-Element-Tag in Form eines geschriebenen Schlüsselwort-Werte-Paares (Attribut-Name = "Attribut-Wert") eingefügt.
- Verarbeitungsanweisungen : werden durch ?Ziel-Name Parameter? beschrieben.
- Kommentare : werden durch !-- Kommentar-Text -- beschrieben.

Ein XML-Dokument muss „wohlgeformt“ sein und alle XML-Regeln einhalten. Diese können zum Beispiel sein, dass nur ein Wurzelelement im Dokument vorkommen darf oder nicht mehrere Attribute mit dem selben Namen verwendet werden. Nur bei Einhaltung der Regeln und Strukturen können XML-Dokumente verarbeitet werden.

3.3.4 Verarbeitung von XML-Dokumenten

XML-Dokumente sind relativ anspruchslos. Um sie jedoch verarbeiten zu können werden verschiedene Tools benötigt. Angefangen von der Eingabe der XML-Daten mittels Editor bis zu den Konvertern, welche für Darstellung im richtigen Format sorgen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 14: Konvertierungsprozess^[64]

3.3.4.1 XML-Editoren

Für die Eingabe von XML kann jeder beliebige Editor verwendet werden. Die Auswahl des geeigneten Tools hängt dabei aber stark von der Anwendung der XML-Daten ab, da diese dann bei der Erstellung und Bearbeitung unterstützen können. Bei XML-Daten mit Dokumentencharakter ist beispielsweise ein Editor sinnvoll, welcher XML-Tags im Fließtext verarbeiten kann und somit keine Probleme mit Format- oder Strukturierungsanweisungen hervorruft.^[65]

3.3.4.2 Parser

Parser sind Programme durch welche die Struktur von XML-Dokumente überprüft wird. Weiters werden mittels Parser die Inhaltselemente interpretiert und extrahiert um diese den Anwendungen (z.B. Browsern) zur Verfügung zu stellen.^[66]

3.3.4.3 Konverter

XML zeichnet nicht nur der Datenaustausch zwischen verschiedenen Systemen, Plattformen, Datenbanken und Anwendungsprogrammen aus, sondern auch eine flexible Darstellung von Informationen in unterschiedliche Medien. Dafür müssen die ursprünglichen Daten in unterschiedliche Zielformate (HTML, CSV, RTF, PDF, etc.) konvertiert werden.^[67]

3.3.5 Schemasprachen

Die Regeln über erlaubte Elemente, Attribute und Verschachtelungsmöglichkeiten, also die Struktur und Inhalt, werden unabhängig von der eigentlichen XML-Datei definiert. Dies findet über so genannte Schemasprachen statt, welche es ermöglichen, domänenspezifische Datenformate zu erstellen. Dadurch kann spezifisch auf die jeweiligen Anforderungen jener Dateien eingegangen werden, welche elektronisch übertragen werden sollen. Zwei der bekanntesten Schemasprachen werden folgend kurz beschrieben.

3.3.5.1 DTD (Document Type Definition)

Die Daten mit den Definitionen stellen eine so genannte DTD (Dokumenttyp-Definition) dar. Eine XML-fähige Software sollte diese DTD´s auslesen können. Dadurch hat die Software Zugriff auf das in der DTD hinterlegte Regelwerk und die Daten, welche sich auf die DTD beziehen, können auf deren Gültigkeit überprüft werden. Die Überprüfung auf die Fehlerfreiheit einer XML-Datei wird dabei Validierung genannt. Dadurch kann wiederum sicher gestellt werden, dass eine interpretierende Software brauchbar bleibt.^[68]

Beispiel:

!ELEMENT BlutabnahmeZeit (#PCDATA)

Anhand dieses Beispiels wird die Zeit für die Blutabnahme beschrieben. Der Begriff (#PCDATA) legt lediglich fest, dass in der Blutabnahmezeit nur Zeichen aus einem bestimmten Zeichensatz vorkommen dürfen. Eine Einschränkung auf bestimmte Wertebereiche ist mit der DTD nicht möglich.^[69]

3.3.5.2 XSD (XML-Schema-Definition)

Das XML Schema-Dokument ist ein gültiges XML-Dokument und bietet eine wesentlich detailiertere Beschreibung als DTD. Beim XSD gibt es viele Elemente und Attribute und auch eine umfangreiche Syntax, welche zu erlernen ist. Es erlaubt die Definition von Datentypen, die Kombination von mehreren Schema-Dokumenten, die Entwicklung von komplexen Datenstrukturen und ermöglicht einen komponentenorientierten Aufbau von Schema-Dokumenten.^[70] Auch die Wertebereiche, welche die DTD nicht darstellen kann, können mit XSD definiert werden.

Beispiel:

element name=“BlutabnahmeZeit“ type=“datetime“ /

Hierbei wird ein Datum im Format YYYY-MM-DDThh:mm:ss beschrieben. Das XML-Element kann beispielsweise sein:

BlutabnahmeZeit2009-05-16T10:23:00/BlutabnahmeZeit

Eine Vorraussetzung für den Datenaustausch ist die Einigung auf eine gemeinsame DTD bzw. ein XML-Schema.^[71] Informationen können dann verpackt in der jeweiligen XML-Struktur, elektronisch übermittelt werden und mittels eines Parsers analysiert, identifiziert und an die jeweiligen benötigten Anwendungen extrahiert werden.

Informationen werden in der Praxis in verschiedenen Bereichen mit unterschiedlichen Dateiformaten benötigt. Hierbei kommt eine Erweiterungen von XML ins Spiel. Es handelt sich um die Transformationssprache XSLT (XSL Transformation Language), welche eine Subsprache von XSL (Extensible Stylesheet Language) darstellt. XSL ist eine in XML notierte Familie von Transformationssprachen zur Definition von Layouts für XML-Dokumente. Dies erlaubt ein Umordnen, Einfügen oder Weglassen von Elementen.^[72]

3.4 XSLT – Extensible Stylesheet Language for Transformation

„XSLT, die Extensible Stylesheet Language for Transformations, ist eine offizielle Empfehlung des World Wide Web Consortium (W3C). Sie bietet eine flexible, leistungsfähige Sprache, mit der sich XML-Dokumente in etwas anderes umwandeln lassen.“^[73]

XSLT bildet einen Teilbereich von XSL und gehört aufgrund seiner Eigenschaft als Verwandlungskünstler neben XPATH (XML Path Language) und XSL:FO (Extensible Stylesheet Language – Formatting Objects) zu den wichtigsten Erweiterungen von XML.

XPATH ist eine Art von Abfragesprache, womit vorrangig bestimmte Bereiche in einem XML-Dokument eindeutig identifiziert werden können. Weiters wird es von XSLT zur Navigation im Dokument und Selektion von Knoten verwendet wird. XSL:FO dient dazu, ein XML-Dokument in eine präsentierende Form zu bringen.^[74]

Mit XSLT hat der Benutzer die Möglichkeit eine Umwandlung von XML-Dokumenten in ein anders strukturiertes XML-Dokument, ein HTML-Dokument, eine PDF-Datei (Portabel Document Format), eine JPEG-Datei (Joint Photographie Experts Group), Java-Code, eine einfache Textdatei oder ein anderes beliebiges Format zu vollziehen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 15: Komponenten einer Transformation^[75]

Eine Vorraussetzung dafür ist, dass die Regeln für die Umwandlung eines XML-Dokuments in einem XSLT-Stylesheet, einer so genannten Abbildungsbeschreibung, festgelegt werden. Durch einen XSLT-Prozessor, einer Software, welche in der Lage ist XML-Strukturen zu lesen und mittels Style Sheets in ein gewünschtes Zielformat abzubilden, wird das XML-Dokument in das gewünschte textbasierte Dokument transformiert.^[76]

Sehr oft werden zwischen Partnern, unter Verwendung unterschiedlicher Datenbank-systeme, viele Daten ausgetauscht. Würde man sich auf ein gemeinsames XML-Datenformat festlegen bzw. dieses definieren, könnten diese Dokumente in die jeweils benötigten Import-Dateien transformiert werden.

Besitzt man beispielsweise Dokumente in mehreren unterschiedlichen Formaten, wobei alle Dokumente maschinenlesbar sind, wäre es mit einem großen Aufwand verbunden, Programme zu schreiben, welche diese ganzen Dokumente parsen und verarbeiten können. Durch XSLT könnten diese Dokumente in einem einzigen Format kombiniert werden um anschließend Zusammenfassungen und Reports auf Basis der angesammelten Dokumente erzeugen zu können.

XSLT kann man dabei als eine Art von Universal-Konverter sehen, welcher von einer Sprache in eine andere Sprache übersetzt. Daten können somit in einer XML-basierten eigenen Sprache gespeichert werden, zum Präsentieren dann beispielsweise im Web auf dem Server in HTML übersetzt werden.^[77] Auch andere Anwendungen wie beispielsweise SAP oder ein Laborinformationssystem können die XML-Dokumente mithilfe der Konvertierung in ein passendes Präsentationsformat mittels XSLT erkennen.^[78]

3.5 Architektur von Kommunikationssystemen

In den siebziger Jahren veranlasste die International Standard Organization (ISO) aufgrund der stark wachsenden Bedeutung der weltweiten Kommunikation, eine Arbeitsgruppe zu bilden, welche sich mit der Standardisierung der Rechnerkommunikation befassen sollte. Einer Rechnerkommunikation, mit dem Ziel Daten auszutauschen bzw. zu übertragen, liegt der Umstand zugrunde im Vorhinein zu vereinbaren, in welcher Art und Weise diese stattfinden soll.^[79]

Hierfür gibt es Protokolle, welche die Basis für Netzkommunikation im Internet bilden.

3.5.1 Das Internet

Die Anfänge des Internets entstanden in den 60iger Jahren, der Zeit des kalten Krieges zwischen den USA und der ehemaligen UdSSR. Es herrschte die Besorgnis vor einem atomaren Militärschlag. Um selbst bei einem solchen „Worst Case“ keine wichtigen Daten zu verlieren, wurden die Überlegungen angestellt ein dezentrales Netz zu schaffen, durch welches die selben Daten auf mehreren verschiedenen Standorten gespeichert sein sollten. Bei neuen oder geänderten Daten sollten alle angeschlossenen Rechner innerhalb kürzester Zeit auf den aktuellsten Stand gebracht werden. Damit dieses Prinzip auch bei einem Ausfall von einem der Rechner oder einer der Leitungen weiterarbeiten würde, sollten die Daten über mehrere Wege und Rechner geschickt werden. Dieses Projekt scheiterte, die Idee des „dezentralen Netzwerkes“ als Kommunikationssystem mit einer paketweisen Datenübertragung war jedoch geboren.^[80]

Eine wissenschaftliche Einrichtung mit dem Namen Advanced Research Projects Agency (ARPA) griff die Idee des „dezentralen Netzwerkes“ 1958 wieder auf. Ende 1972 waren bereits 40 Rechner an diesem „ARPA-Netz“ angeschlossen.

Die Wissenschaft erkannte neben den militärischen Einrichtungen ebenfalls, dass man durch diese Art der Datenübertragung viele neue Möglichkeiten schöpfen konnte. Durch die offene Architektur des ARPA-Net stand dem elektronischen Datenaustausch untereinander hierbei nichts im Wege.

Die Anzahl der angeschlossenen Rechner stieg im Laufe der 80iger Jahre sukzessive an und es entstand buchstäblich ein Netz der Netze, das Internet.

Da es sich hierbei aber unter anderem um Rechner mit nicht kompatiblen Betriebssystemen sowie unterschiedlichen Netzzugängen handelte, entstand die Notwendigkeit, ein neues Datenübertragungsprotokoll zu entwickeln. Dieses Protokoll sollte nicht an Betriebssysteme, Übertragungswege oder Übertragungsgeschwindigkeiten gebunden sein.

3.5.1.1 TCP/IP-Protocol

Es kam schlussendlich zur Entwicklung des TCP/IP-Protokolls (Transmission Control Protocol/Internet Protocol) und einem dafür spezifischen Referenzmodells. Dieses beschreibt den Aufbau und das Zusammenwirken der Netzwerkprotokolle aus der Internet-Protokoll-Familie und gliedert sie in vier aufeinander aufbauende Schichten.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 5: TCP/IP-Architektur^[81]

Das TCP/IP Referenzmodell ist auf die Internet-Protokolle zugeschnitten und ermöglicht die Kommunikation und den Datenaustausch über die lokalen Grenzen von Netzwerken hinaus.

Um die Probleme der Netzwerkkommunikation allgemein betrachten zu können, wird auf ein anderes Referenzmodell zugegriffen. Es handelt sich dabei um das Referenzmodell für Rechnerkommunikation, mit dem Titel „Basic Reference Model for Open System Interconnection (OSI)“.^[82]

3.5.2 ISO/OSI-Referenzmodell

Das ISO/OSI-Schichtenmodell ist ein Referenzmodell für herstellerunabhängige Kommunikationssysteme. Dieses Modell beschreibt abstrakt den Durchlauf der Kommunikation in 7 Schichten. Dabei sind die Funktionen und Protokolle definiert und einer bestimmten Aufgabe bei der Kommunikation zwischen zwei Systemen zugeordnet sind.^[83] Unter Protokoll wird eine formalisierte Verfahrensschrift für den Informationsaustausch und die Datenübertragung in einem Netzwerk bezeichnet.^[84]

Durch das Modell wird also eine standardisierte Vorgehensweise aufgezeigt, wie Nachrichten zwischen Sender und Empfänger nach einem festgelegten Protokoll transformiert, übertragen und wieder zurücktransformiert werden können.^[85]

Jede Schicht ist für eine bestimmte, klar definierte Gruppe von Teilaufgaben in der Kommunikation zuständig. So muss jede Schicht die Nachricht der darüber liegenden Schicht entgegennehmen, bearbeiten und unter Nutzung der Dienste der darunter liegenden Schicht weiterleiten.

3.5.2.1 Die siebte Schicht

Die so genannte Anwendungsschicht beinhaltet Funktionen, mit denen auf das Kommunikationssystem (Datenübertragung, E-Mail, etc.) zugegriffen werden kann. Dies geschieht unter anderem mittels Protokollen, welche dem Benutzer zur Verfügung gestellt werden und eine Dateiübertragung und Datenzugriff über Rechnergrenzen hinweg ermöglichen.^[86]

Die Anwendungsschicht ist aber auch auf die unteren Schichten angewiesen, zumal diese die Daten über das zugrunde liegende Netzwerk transportieren.^[87]

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 6: Schichten des ISO/OSI Referenzmodells^[88]

Kommunizieren nun 2 Rechner miteinander, so werden Daten zwischen den jeweils gleichen Schichten der Kommunikationspartner ausgetauscht. Beispielsweise steht die physikalische Schicht von Rechner A in Kontakt mit der physikalischen Schicht von Rechner B. Die Anwendungsschicht von Rechner A, auf der die Datenübertragungsdienste angesiedelt sind, steht wiederum in Kontakt zu den Anwendungsprogrammen von Rechner B und stellt damit eine Schnittstelle dar.

3.5.3 Schnittstellen

Der Datenaustausch erfolgt zumeist zwischen verschiedenen Applikationen. Dabei kommt es dazu, dass das originäre Datenformat in ein für die Empfängerapplikation lesbares Format gebracht werden muss und über eine geeignete Datenleitung übertragen wird. Die Verbindungsstelle zwischen verschiedenen Hardware- und Softwarekomponenten wird allgemein als Schnittstelle bezeichnet. Dieser Begriff trifft auch auf die Verbindungsstelle zwischen Mensch und Computer zu.^[89]

Wenn nun komplexe Anwendungsprogramme miteinander kommunizieren und Daten beispielsweise via XML austauschen, wird von Web-Services gesprochen. In XML-Formaten wird einerseits erfasst, welche Dienste ein Anbieter zur Verfügung stellt und auch wie diese Dienste abgerufen werden können. Andererseits kommunizieren die Rechner über XML-Nachrichten miteinander, wenn auf die bereitgestellten Dienste zugegriffen wird. Durch diese öffentlichen Schnittstellen können unterschiedlichste Anwendungsprogramme Daten miteinander austauschen.^[90]

Im ISO/OSI Schichtenmodell erfolgt die vertikale Kommunikation zwischen den Schichten ebenfalls über Schnittstellen. Diese Schnittstellen definieren dabei, welche Dienste und Verfahren die untere Schicht der oberen Schicht ermöglicht. Weiters wird darüber definiert, wie Daten zwischen zwei Schichten ausgetauscht werden sollen.^[91]

Da die Daten prinzipiell im (Klar-)Textformat übertragen werden, muss man auf anderer Ebene dafür sorgen, dass Sicherheit bei der Datenübertragung gegeben ist.

3.6 Sichere Datenübertragung und Informationssicherheit

Mit der rasanten Ausbreitung und Weiterentwicklung des Internet und des elektronischen Datenaustausches entstand auch das Bedürfnis diese Art der Kommunikation sicherer zu gestalten. Mittlerweile wurden auch seitens der Gesetzgebung, wie bereits in Kapitel 3 kurz beschrieben, Anforderungen erstellt, um die elektronische Datenübertragung und deren übertragene Informationen vor Risiken zu schützen.

Informationen bzw. Daten stellen einen wesentlichen Wert für jegliche Arten von Unternehmen und Personen dar und müssen angemessen geschützt werden. Unzureichend geschützte Informationen stellen einen häufig unterschätzten Risikofaktor dar, welcher sogar existenzbedrohende Ausmaße annehmen kann. Der Zugriff auf diese Informationen und Daten ist somit zu beschränken und zu kontrollieren, um zu gewährleisten, dass nur autorisierte Subjekte Zugriff darauf haben.^[92]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 16: Schutzziele für eine sichere Kommunikation^[93]

Hierfür müssen so genannte Schutzziele definiert werden, welche diese Anforderungen präzisieren. Es handelt sich dabei um Datenintegrität und Informationsvertraulichkeit.

Weiters müssen zugreifende Subjekte eindeutig identifiziert und die Identität verifiziert werden. Den fachspezifischen Ausdruck hierfür nennt man Authentizität von Subjekten.

Sobald das Subjekt authentifiziert und berechtigt bzw. autorisiert ist, einen Zugriff auf Informationen durchzuführen, muss das System gewährleisten, dass der Zugriff auch möglich ist. Oftmals wird im Nachhinein versucht die Urheberschaft des Zugriffs bzw. der Aktion eindeutig dem jeweiligen Subjekt zuzuordnen. Man nennt dies die Verbindlichkeit oder Zuordenbarkeit des Systems.^[94]

3.6.1 Vertraulichkeit

Ein Benutzer möchte, dass gewisse Informationen und Inhalte einer Kommunikation nur bestimmten Subjekten zugänglich sind. Dies kann angefangen vom Gespräch unter vier Augen, über einen Brief mit versiegelten Umschlag bis zur Kryptographie erreicht werden.

3.6.1.1 Kryptographische Verschlüsselung

Bei dieser kryptographischen Verschlüsselung von Informationen können symmetrische und assymetrische Schlüssel verwendet werden.^[95]

Beim symmetrischen Schlüssel handelt es sich hierbei um einen geheimen Schlüssel, welchen nur die Kommunikationspartner kennen. Dieser Schlüssel muss vor der vertraulichen Information über einen sicheren Weg ausgetauscht werden.

Der asymmetrische Schlüssel des jeweiligen Empfängers hingegen ist öffentlich bekannt und wird vom Sender zum Datenaustausch verwendet. Da nur der gewünschte Empfänger den privaten Schlüssel zum öffentlich bekannten Schlüssel besitzt, wird sichergestellt, dass nur dieser Empfänger die Informationen entschlüsseln kann.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 17: Asymmetrische Verschlüsselung^[96]

Die Asymmetrische Verschlüsselung wird vor allem im E-Mail-Verkehr (OpenPGP, S/MIME), bei digitalen Signaturen und bei kryptografischen Protokollen, wie beispielsweise HTTPS (Hypertext Transfer Protokoll Secure), ihre Anwendung.

Mittels OpenPGP (Open Pretty Good Privacy) ist es möglich überprüfbare elektronische Unterschriften zu erzeugen und zu verschlüsseln. Dadurch wird festgestellt, ob eine E-Mail tatsächlich vom angegebenen Empfänger kommt und das die Nachricht nicht verändert wurde. Weiters können Daten verschlüsselt werden, damit diese nur berechtigte Personen lesen können.^[97]

S/MIME (Secure / Multipurpose Internet Mail Extensions) erfüllt mit der Verschlüsselung und Signatur von E-Mails mittels eines asymmetrischen Kryptosystems dieselben Aufgaben wie OpenPGP. Den Unterschied zu OpenPGP findet man im Ansatz zur Sicherstellung der Authentizität, wobei ein „Web of Trust“ bei PGP verwendet wird und eine Zertifikat-Hierarchie bei S/MIME.

Da die asymmetrische Verschlüsselung jedoch den Nachteil hat, sehr langsam zu sein, wird in der Praxis mittlerweile eine Kombination aus asymmetrischen und symmetrischen Verfahren. Während das langsame asymmetrische Verfahren für den Schlüsselaustausch (Session Key) verwendet wird, werden mit dem schnelleren symmetischen Verfahren die eigentlichen Nutzdaten verschlüsselt.

3.6.1.2 Virtuell Private Network

Unter einem Virtuell Private Network (VPN) wird ein Netzwerk verstanden, welches einen verschlüsselten Transport von privaten Daten über ein öffentliches Netzwerk, wie dem Internet, bewerkstelligt. Dabei wird grundsätzlich zwischen zwei verschiedenen VPNs unterschieden:^[98]

Site-to-Site: Hierbei sollen zwei lokale Netzwerke verbunden werden. Die Rechner in den lokalen Netzen bauen untereinander eine VPN-Verbindung auf und senden Daten in das Netz. Dadurch wird es beispielsweise möglich 2 entfernte Standorte sicher miteinander zu verbinden.

Site-to-End: Diese Art von VPNs wird vor allem dann verwendet, wenn externe Mitarbeiter Zugriff auf das interne Netz bekommen sollen. Der Computer des Mitarbeiters baut dabei eine VPN-Verbindung zu dem ihm bekannten VPN-Gateway des Unternehmens auf. Dadurch hat der Mitarbeiter nun dieselben Möglichkeiten, als wenn er sich im lokalen Netz des Unternehmens wäre.

Die VPNs werden vor allem dann verwendet, wenn eine feste, garantierte Bandbreite erforderlich ist und Daten verschlüsselt oder gekapselt über ein öffentliches Netz wie das Internet ausgetauscht werden.

3.6.2 Integrität

Durch die Integrität weiß der Empfänger von Informationen, dass diese nicht verändert worden sind. Dies kann gewährleistet werden, wenn es Subjekten nicht möglich ist, die zu schützenden Daten unautorisiert und unbemerkt zu manipulieren.^[99]

Sollte es zu Manipulationen gekommen sein, so dürfen diese nicht unbemerkt bleiben. Hierfür sind gewisse Techniken erforderlich. Durch die Erkennung von Manipulationen, kann verhindert werden, dass manipulierte Daten weiterverarbeitet werden und der mögliche Schaden begrenzt wird.

„Zur Erkennung von durchgeführten Datenveränderungen werden kryptographisch sichere Hashfunktionen eingesetzt .“^[100]

Diese haben die Funktion eines Fingerabdruckes der jeweiligen Nachrichten. Dadurch kann die Authentizität des mit dem Hashcode gekennzeichneten Dokumentes, beim Empfänger überprüfbar gemacht werden.

3.6.3 Authentizität

Unter der Authentizität eines Subjekts bzw. Objekts wird die Echtheit und Glaubwürdigkeit des Subjekts oder Objekts verstanden. Dies wird anhand einer eindeutigen Identität überprüft.^[101] Nur damit erhält der Empfänger von Informationen die Sicherheit darüber, von wem die Information stammt bzw. ob der Kommunikationspartner tatsächlich jenes Subjekt ist, für den es sich aus gibt.

Um eine sichere Identifizierung zu erreichen, werden eindeutige Benutzererkennungen oder Benutzernamen benötigt. Dies kann beispielsweise mittels Passwort oder biometrischer Merkmale (Fingerabdrücke, usw.) geschehen, welche der Benutzer beim Systemzugang nachweisen muss.

Eine andere Möglichkeit Authentizität herzustellen ist es, mittels eines Schlüssels, eines Zertifikates oder einer Karte (Bsp. E-Card) die Echtheit eines Subjekts zu überprüfen und sicherzustellen.

3.6.4 Verbindlichkeit

Das System der Verbindlichkeit bzw. Zuordenbarkeit funktioniert dann, wenn es nicht möglich ist, dass ein Subjekt nach Durchführung einer Aktion abstreiten kann, diese durchgeführt zu haben. Diese Verbindlichkeitseigenschaften spielen vor allem im rasant wachsenden Bereich des elektronischen Handels eine große Rolle um die Rechtsverbindlichkeit durchgeführter geschäftlicher Transaktionen zu garantieren. Im Gesundheitswesen spielt die Verbindlichkeit ebenfalls eine große Rolle, da dadurch festgestellt werden kann, wer, im Falle von Fehlern, Schulungsbedarf benötigt bzw. zur Rechenschaft gezogen werden muss.^[102]

Dies erfordert ein gewisses Maß an Überwachung, welches durch Protokollierung der einzelnen Benutzeraktivitäten und die Verwendung digitaler Signaturen erreicht werden würde.

4 ELEKTRONISCHE DATENÜBERTRAGUNG E-HEALTH

Dieses Kapitel soll die Einsatzgebiete der elektronischen Datenübertragung im Gesundheitswesen behandeln und darstellen. Dadurch sollen die bereits vorhandenen Übertragungsformate für diesen spezifischen Bereich aufgezeigt werden.

4.1 E-Card als Wegbereiter

Im Gesundheitswesen werden mittlerweile viele Prozesse elektronisch abgehandelt, angefangen von der Identifikation des Patienten mittels E-Card bis zu der elektronischen Befundübermittlung mittels E-Mail. Besonders das Projekt zur Einführung der E-Card hat in Österreich entscheidend zur Verbesserung der Infrastruktur beigetragen. Es wurde dadurch beispielsweise eine elektronische Anbindung über eine Breitbandvernetzung (ADSL) an den Sozialversicherungsträger verwirklicht. Ein Router, ein Lesegerät sowie eine Gesundheitsinformationsnetzadapterbox wurden vom Hauptverband finanziert. Die Gesundheitsdienstleistungsanbieter wie Ärzte, Labore usw. mussten für die Anbindung an die Praxissoftware, für etwaige Umbaumaßnahmen sowie für die Wartungs- und Leitungskosten aufkommen.^[103] Die E-Card spielt für diese Arbeit eine wichtige Rolle, da mit der erstmaligen Verwendung dieser Authentifizierungskarte die eigentliche Kommunikation rund um den Patienten- bzw. Laborauftrag beginnt.

Auch in Deutschland hat die Gesundheitskarte den Grundstein für weitere Verbesserungen im Bereich der elektronischen Kommunikation für das Gesundheitswesen gelegt. Die Ziele, welche dort mit der Karte verfolgt werden, sind^[104] :

- Verbesserung der medizinischen Versorgungsqualität
- Verbesserung der patientenorientierten Dienstleistungen
- Steigerung der Wirtschaftlichkeit und Leistungstransparenz im Gesundheitswesen
- Optimierung von Arbeitsprozessen und Bereitstellung von aktuellen gesundheitsstatistischen Informationen

Mittlerweile ist die Arbeit am Computer im Medizinbereich kaum noch wegzudenken. Doch die standardisierte elektronische Kommunikation ist im Gesundheitswesen nicht erst seit kurzem erfunden worden.

So wurde bereits im Jahr 1987 eine Gruppe internationaler Standards, welche für den Austausch von Daten zwischen Organisationen im Gesundheitswesen und derer Computersysteme zuständig ist, gegründet. Es handelt sich dabei um Health Level 7 (HL7). Neben HL7 gibt es noch weitere Standards zur Datenübertragung wovon einige in diesem Kapitel kurz beschrieben werden.

4.2 Health Level 7

Health Level 7 ist ein einheitlicher Kommunikationsstandard, welcher von der HL7 Working Group, einer ANSI-akkreditierten Organisation, gepflegt wird. Diese befasst sich mit der Entwicklung von Standards im Bereich der klinischen und administrativen Daten aus dem Gesundheitswesen. Ihr Ziel ist es Standards für den Austausch, das Management und die Integration von Daten bereitzustellen.^[105] In Bezug auf diese Arbeit, spielt HL7 insofern eine Rolle, da dieser Standard im Soll-Prozess Anwendung findet.

Aufgrund des ständig wachsenden Informationsaufwandes, wird eine Automatisierung der Informationsverarbeitung angestrebt. Die abteilungsbezogene Sichtweise, welche in der Vergangenheit verwendet worden ist, hat jedoch zu einer Vielzahl an Schnittstellen geführt. Die Pflege dieser Schnittstellen ist sehr aufwendig, insbesondere dann, wenn unterschiedliche Kommunikationsstandards verwendet werden. Aus diesem Grund wurde der Kommunikationsstandard Health Level 7 ins Leben gerufen. Dieser sollte die Kommunikation zwischen Anwendungen vereinheitlichen und somit einen kostengünstigen und effizienten Datenaustausch ermöglichen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 18: Kommunikation mit HL7^[106]

An die Verwendung von HL7 sind sehr wenige Vorbedingungen an die Systemarchitektur verknüpft. Es muss somit nicht der gesamte HL7-Umfang implementiert werden.

Die wesentlichen Merkmale sind:

- Bereitstellung von Formaten und Protokollen für den Datenaustausch im Gesundheitswesen
- Verminderung und Standardisierung der Schnittstellen zwischen verschiedenen Anwendungen
- Effizientere Kommunikation zwischen den verschiedenen Anwendungen durch Optimierung der Kommunikationswege
- Vereinfachung der Schnittstellenimplementierung
- Anerkennung als internationaler Standard (ANSI und ISO)

Der Aufbau von HL7 wird in die Abstract Message Definition und die Encoding Rules aufgeteilt. In der Abstract Message Definition wird die Struktur und der Aufbau einer Nachricht beschrieben. Diese wird ab Version HL7 v2.xml auf dem XML-Standard basieren.^[107]

Die HL7-Dokumente umfassen die Patienten-Stammdaten mit Patienten ID, Anschrift und Geburtsdaten, die Krankenkasse, den Hausarzt sowie die zugewiesene Station und Fachrichtung des Krankenhauses.^[108]

Die Sicherheit ist hingegen nicht Teil des HL7. Da es sich hierbei um ein Layer 7 Protokoll handelt, wird der Sicherheitspart den darunter liegenden Schichten überlassen. Die offene Struktur lässt dabei zwei Grundprinzipien zu. Entweder werden gesicherte Mitteilung über ein unsicheres Netz übertragen oder eine ungesicherte Mitteilung wird durch einen sicheren Kanal übertragen.^[109]

Health Level 7 ist unter anderem auch damit beschäftigt, die Entwicklungen und Förderungen des HL7-Standards unter Berücksichtigung des XML-Standards und dessen Weiterentwicklung abzustimmen.^[110] Dabei werden insbesondere die Möglichkeiten des XML-Standards zur Definition, Spezifikation, Implementierung und Kommunikation von Inhalten und Funktionalitäten im Gesundheitswesen aufgezeigt.

Diese Möglichkeit wird mittels der Clinical Document Architecture umgesetzt, welcher als erster offizielle Standard im Gesundheitswesen auf der Basis von XML gilt.^[111]

4.3 Clinical Document Architecture

Die Architektur für klinische Dokumente (Clinical Document Architecture) basiert auf dem Reference Information Model (RIM) HL7 V.3 und XML. CDA-Dokumente bestehen aus einem Header mit Metadaten und einem Body mit dem eigentlichen Inhalt. Die Spezifikation erlaubt einen Detaillierungsgrad, der in drei aufeinander aufbauenden Levels den Einsatzbedingungen angepasst werden kann.^[112]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 19: CDA Struktur^[113]

Im ersten CDA Level wird der Fokus auf das Layout und die grundlegende Formatierung von Freitext gelegt. Dokumente können hierbei ordentlich angezeigt werden, sind jedoch nicht maschinenlesbar. Im CDA Level zwei wird zusätzlich Wert auf Interoperabilität gelegt, wobei einzelne Bestandteile des Dokumentes durch standardisierte Codes klassifiziert werden. Im dritten CDA Level werden maschinenlesbare Angaben durch Strukturen hinzugefügt, welche auf dem HL7-Standard basieren. Dies ermöglicht beispielsweise eine automatisierte Verarbeitung von Laborwerten nach deren Übermittlung. Eine CDA beinhaltet Maßnahmen und Beobachtungen und weist folgende Eigenschaften auf:^[114]

- Persistenz : Ein CDA-Dokument darf nicht geändert werden und muss für eine gewisse gesetzliche Dauer existieren.
- Verantwortlichkeit : Jedes CDA-Dokument muss einer verantwortlichen Person zugeordnet sein um eine geregelte Verwaltung zu ermöglichen.
- Echtheit : Die in einem CDA-Dokument angesammelten Daten müssen einer rechtlichen Prüfung standhalten.
- Vollständigkeit : Ein CDA-Dokument darf nicht geteilt werden und alle Informationen müssen im Zusammenhang wiedergegeben werden können.
- Lesbarkeit : Ein CDA-Dokument muss für Menschen lesbar sein und darf somit in keinem Binärformat dargestellt sein.

CDA-Dokumente sind im XML-Format kodiert und können Texte, Bilder, akustische Signale und andere multimediale Daten beinhalten. Bei dieser Methode werden die medizinischen Dokumente an sich nicht standardisiert, es zählt nur der Aspekt der Datenübertragung. Durch Einsatz von CDA kann dadurch beispielsweise eine hohe Kompatibilität mit vielen Programmen zur Dokumentenerstellung und dem Datentransfer erreicht werden.

Neben dieser formaleren Kommunizierbarkeit der Dokumente zwischen Anwendungssystemen gibt es noch folgende zwei entscheidende Vorteile^[115] :

Um eine dokumenten- und prozessorientierte Patientenakte zu erhalten, können alle Metadaten aus einem Bestand an CDA-Dokumenten extrahiert werden, da diese alle notwendigen Informationen beinhalten.

Werden neue CDA-Dokumente geschickt, können diese automatisiert registriert und in ein elektronisches Archiv eingefügt werden. Die darin enthaltenen Metadaten können in die entsprechenden Indexierungsstrukturen der elektronischen Patientenakte eingefügt werden. Das Institut, welches das Archiv zu den Patientenakten führt, erhält dadurch eine höhere Transparenz und Kontrolle.

CDA-Dokumente werden im Rahmen dieser Arbeit vorgestellt, da diese als klinische Dokumente verwendet werden und einen hohen Bekanntheitsgrad besitzen.

4.4 xDT

Ein möglicher Weg um effektiver und effizienter den Austausch von Informationen voranzutreiben, ist jener in Verbindung mit EDI und XML. Einen wesentlichen Anteil am Einzug von EDI in Arztpraxen hatte hierbei vor allem das Datenaustauschformat xDT.

Die hierfür verwendeten Protokolle bauen auf einer identischen Grundstruktur auf, woraus sich die zusammenfassende Bezeichnung xDT ableitet. Das „x“ steht hierbei als Platzhalter für die unterschiedlichen Protokolltypen.^[116] DT steht für Datentransfer.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 7: xDT Standards^[117]

Bei xDT handelt es sich im Unterschied zu HL7 um einen nationalen Standard, welcher überwiegend in Deutschland vor allem zum Austausch von Daten zur Abrechnung und für Behandlungsdaten eingesetzt wird. Die Behandlungsdaten entstanden durch die Erweiterung der Abrechnungsfunktion um bei einem Systemwechsel die in der Praxis-EDV abgespeicherten Daten übernehmen zu können.

Einen weiteren Unterschied zu HL7 stellt das Einsatzgebiet von xDT dar. Während HL7 in Krankenhäusern als standardisiertes Kommunikations- und Schnittstellenprotokoll eingesetzt wird, um unterschiedliche Abteilungs-, Stations- und Verwaltungssysteme zu verbinden wird xDT für den Datenaustausch zwischen Arztpraxis und Labor eingesetzt.^[118]

Wie bei HL7 hat sich auch für den xDT Standard eine Initiative gebildet, alle Protokolle in ein passendes XML-Format umzusetzen und zu erweitern.

xDT hätte das Potential als Abrechnungsdokument zwischen niedergelassenem Arzt bzw. Labor und Sozialversicherungsträger im dargestellten Soll-Prozess zu fungieren. Auf die Abrechnung mit dem Sozialversicherungsträger wird jedoch im Rahmen dieser Arbeit nicht näher eingegangen.

4.5 VCS

Bei dem Datenaustausch Standard VCS handelt es sich um ein Konzept, welches vom Verband Deutscher Arztpraxis-Softwarehersteller (VDAP) entwickelt worden ist. VCS steht hierbei für VDAP Communication Standard. Es soll eine sichere, verschlüsselte Kommunikation zwischen dem niedergelassenen Arzt und den Krankenhäusern ermöglichen.^[119]

VCS regelt einerseits den Kommunikationsweg, welcher auf Internet-Standards (XML, EDI, etc.) basiert. Andererseits werden Inhalte und Struktur für realisierte Geschäftsfälle realisiert. Um diesen Ablauf sicher zu gestalten, werden bei der E-Mail Übertragung gewisse Sicherheitsmaßnahmen getroffen:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 8: VCS Sicherheitsmaßnahmen^[120]

Die Verschlüsselung und die Signatur erfolgt mittels Chipkarten, welche in Form von Arzt- und Praxiskarten im Einsatz sind. VCS-Schnittstellen sind laut Angaben der VDAP bereits in mehr als 70% der Arztpraxen verfügbar. Über diese lassen sich Arztbriefe, Ein- und Überweisungen verschlüsseln, signieren, versenden und empfangen.^[121]

Dieser Standard findet bei den Arztpraxen großen Anklang, weshalb er in dieser Arbeit erwähnt wird. Eine Verwendung für den Soll-Prozess ist jedoch nicht vorgesehen.

4.6 D2D

Das Datenaustauschformat „D2D“ ist allgemein weniger geläufig und steht als Abkürzung für Doctor to Doctor. D2D soll einen sicheren elektronischen Datenaustausch zwischen den Ärzten und der kassenärztlichen Vereinigung ermöglichen, wobei eine bewusste Assoziation in Richtung E-Business geweckt werden soll. Dieser Standard wurde speziell für das deutsche Gesundheitswesen entwickelt, wobei die Kommunikation der Ärzte mit den hochsensiblen Gesundheitsdaten ihrer Patienten im Mittelpunkt steht.^[122]

Der Standard unterteilt sich dabei in 3 Bereiche der elektronischen Versandarten^[123] :

- Adressierte Datenübertragung (Arztbrief, Abrechnung, ...)
- Gerichtete Datenübertragung (Überweisung, Rezept, ...)
- Ungerichtete Datenübertragung (Patienten- oder Fallakte)

Eine der neuesten Anwendungen betrifft beispielsweise die Labordatenfernübertragung. Die Patienteninformationen, welche hier übertragen werden fallen wiederum unter Datenschutz und gehören dementsprechend geschützt. Dafür ist eine digitale Signatur für die Glaubwürdigkeit, die Verbindlichkeit, Berechtigungen und Nachvollziehbarkeit bereits inkludiert.

Die Messaging-Anwendungen von D2D bestehen aus server- und clientseitigen Komponenten, welche aus Sicherheitsgründen getrennt nicht funktionsfähig sind. Der Datenaustausch basiert dabei auf dem TCP/IP-Protokoll. Der hierbei verwendete Datenstandard ist die Extensible Markup Language, um die Inhalte sinnvoll im empfangenden System weiterverarbeiten bzw. in den bestehenden Datenbestand integrieren zu können.^[124]

D2D basiert ebenfalls auf XML mit Fokus auf die sichere Datenübertragung zwischen Ärzten und kassenärztlichen Vereinigungen. Aus diesem Grund wurde dieser Standard, wie auch VCS kurz beleutet.

5 NUTZEN ELEKTRONISCHER DATENÜBERTRAGUNG

Dieses Kapitel soll die Vorteile und Möglichkeiten der elektronischen Datenübertragung mittels XML in einem Soll-Prozess aufzeigen. Dabei werden die im Kapitel 2 „ Ist-Situation eines Labors “ dargestellten Prozesse und erwähnten Probleme als Grundlage verwendet. Durch einen Vergleich mit dem Ist-Prozess kann der durch den Einsatz von XML entstandene Nutzen herausgearbeitet werden.

5.1 Soll-EPG der Arztpraxis

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 20: Soll-EPG des niedergelassenen Arztes Teil 1^[125]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 21: Soll-EPG des niedergelassenen Arztes Teil 2^[126]

5.1.1 Beschreibung der Soll-Prozesskette beim niedergelassenen Arzt

Die ersten Schritte beginnen wiederum mit dem niedergelassenen Arzt und der Registrierung des Patienten durch die E-Card. Wie bereits im Laufe dieser Arbeit erwähnt, wird hierbei eine Breitbandverbindung zum Sozialversicherungsträger aufgebaut und die zahlungsrelevanten Aspekte des Patienten im Vorfeld überprüft.

Zusätzlich wird durch diesen Vorgang in der Arztsoftware die Patientengeschichte aufgerufen und der Arzt hat nun die Möglichkeit auf diese Einsicht zu nehmen. Im Falle einer Verwirklichung einer übergreifenden nationalen oder internationalen Patientendatenbank, könnte durch die Identifizierung und Authentifizierung mittels E-Card eine vollständige Patientenhistorie eingesehen werden.

Nachdem der Arzt die Untersuchung am Patienten abgeschlossen hat, können in der Arztsoftware weitere Informationen zum Gesundheitsbild des Patienten hinterlegt werden. Werden weitere Informationen über das Blutbild benötigt, müssen nun die jeweiligen Parameter in der Arztsoftware hinterlegt werden. Mit der Eingabe dieser Parameter erhält die Arzthelferin die Information über die notwendige Blutentnahme am Patienten.

Während der Arzt sich dem nächsten Patienten widmen kann, sieht die Arzthelferin welche Röhrchen am Patienten abgenommen werden müssen. Dies wird über das System mittels Bildern der Kappen- und Ringfarben ersichtlich.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 22: Vacuette Code System - Anforderungssoftware^[127]

Nachdem das blutabnehmende Personal weiß, welches evakuierte Blutentnahmeröhrchen verwendet werden muss, werden die passenden ausgewählt. Im Ist-Prozess ist es an dieser Stelle sehr oft zu Problemen in Form von Verwechslungen, falscher Beschriftung, falschem Bekleben usw. gekommen. Vorbarcodierte Blutentnahmeröhrchen schaffen bei diesen Problemen Abhilfe und unterstützen den durchgängig elektronischen Prozess. Diese sind bereits von diversen Herstellern evakuierter Blutentnahmeröhrchen (Bsp.: Vacuette®) zu beziehen. Diese vorbarcodierten Blutentnahmeröhrchen bringen jedoch nur den erwähnten Nutzen, wenn diese in Verbindung mit elektronischer Datenübertragung eingesetzt werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 23: Barcoderöhrchen^[128]

Die uniquen (einzigartigen) Barcodes dieser evakuierten Blutentnahmeröhrchen können bereits Informationen über dessen Artikelnummer, das Herstelldatum und den Hersteller selbst beinhalten. Zu letzterem hat das Health Industrie Business Communications Council (HIBCC) bereits mit ISO die international anerkannte Struktur UIM (Unique Identification Marks) zur einzigartigen Produktkennzeichnung entwickelt.^[129]

Das vorbarcodierte Blutentnahmeröhrchen wird am Patienten angewendet und nach erfolgter Blutentnahme mittels einfachem Scan dem Patienten und dessen, vom Arzt hinterlegtem, Laborauftrag zugeordnet.

Die Software übernimmt hierbei eine Überwachungsfunktion und verlangt neben der Identifikation des blutabnehmenden Personals immer das korrekte Röhrchen. Durch den Scan wird weiters der Blutabnahmezeitpunkt im System hinterlegt, um eventuell später aufkommende Probleme besser nachvollziehen zu können.

Nachdem die Software erkannt hat, dass alle notwendigen Röhrchen gescannt worden sind, wird ein elektronischer Auftrag an das Laborinformationssystem abgeschickt, während die Röhrchen mittels Kurier an das Labor gesendet werden.

5.1.1.1 Kommunikationsfluss

Der Kommunikationsfluss im Soll-Prozess beginnt somit beim niedergelassenene Arzt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 24: Kommunikationsfluss der Stakeholder^[130]

Hierbei werden die auf der E-Card hinterlegten Informationen an den Sozialversicherungsträger übermittelt. Es handelt sich hierbei um ausschließlich persönlichen Daten des Karteninhabers, wie der Name und der akademische Grad, das Geburtsdatum, die Versicherungsnummer sowie die Nummer der Karte. Da es sich bei der E-Card um eine Schlüsselkarte handelt, enhält diese Daten und Schlüssel für die Identifikation und Steuerung der Zugriffsberechtigung. Die Daten der E-Card können dabei nur in Kombination mit der Karte des Arztes abgerufen werden.^[131]

Im zweiten Schritt übermittelt der Sozialversicherungsträger der anfragenden Stelle Informationen über den jeweiligen Patienten wie beispielsweise die Krankenkasse und den Versicherungsstatus. Dadurch weiß der niedergelassene Arzt, wer der Patient ist und ob dieser versichert ist.

Der dritte Schritt ist die Übermittlung einer Laboranforderung mit den Patientendaten (Name, erforderliche Parameter, ...) vom niedergelassenen Arzt an das jeweilige Labor. Die Daten werden hierbei im Laborinformationssystem hinterlegt. Im 4. Schritt übermittelt das Labor dem niedergelassenen Arzt die Befunde des Patienten und rechnet seine Kosten im Schritt 5 mit dem Sozialversicherungsträger ab.

5.2 Soll-EPG des Labors

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 25: Soll-EPG des Labors Teil 1^[132]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 26: Soll-EPG des Labors Teil 2^[133]

5.2.1 Beschreibung der Soll-Prozesskette im Labor

Mittels einer Site-to-End VPN Verbindung werden die Daten sicher von der Arztsoftware an das Laborinformationssystem übermittelt. Die Verbindung findet jedes Mal dann statt, wenn sich die Arztpraxis (End) bei Bedarf mit dem Labor (Site) verbindet um somit die Daten sicher zu übermitteln. Durch das virtuelle private Netz (VPN) sowie ein asymmetrisches Verschlüsselungsverfahren kann vermieden werden, dass wichtige Informationen verloren gehen, unerlaubt gelesen oder manipuliert werden.

Bei der asymmetrischen Verschlüsselung benutzt der niedergelassene Arzt den öffentlichen Schlüssel des Labors. Da nur das Einsenderlabor den privaten Schlüssel besitzt, kann die Nachricht auch nur von diesem Labor entschlüsselt werden. Die Nachricht wiederum besteht aus dem im XML-Format hinterlegten Anforderungsschein mit den vertraulichen Patientendaten.

Durch eine hinterlegte elektronische Signatur kann das Labor sicherstellen, dass die Integrität der Nachricht gegeben ist und der niedergelassene Arzt der tatsächliche Absender ist. Dies stellt auch die Authentizität sicher und erfüllt damit gesetzliche Vorgaben im Bereich des Gesundheitswesens.

Der Patientenauftrag, welcher über die VPN Verbindung geschickt wird, wurde bereits im XML-Format erstellt, wodurch dieser vom Laborinformationssystem automatisch verarbeitet werden kann.

Beispiel:

Abbildung in dieser Leseprobe nicht enthalten

Sobald die Blutentnahmeröhrchen im Labor eingetroffen sind, werden sie einen automatisierten Sortierer gegeben, welcher über eine HL7-Schnittstelle mit dem Laborinformationssystem verbunden ist. Das System weiß nun, welche Röhrchen im Labor angelangt sind und kann im Falle einer Verspätung oder dem Fehlen von Proben eine sofortige Meldung an das medizinische Fachpersonal via E-Mail senden. Weiters informiert das LIS den automatischen Sortierer welche Blutentnahmeröhrchen zentrifugiert werden müssen. Anhand der hinterlegten Parameter werden die Röhrchen auch in der richtigen Reihenfolge den Analyseinstrumenten zugeordnet, welche die Daten über die notwendigen Tests wiederum vom LIS über eine HL7-Schnittstelle, ab Version HL7 v2.xml bereits in einer XML-Struktur verpackt, erhält.

Nach der technischen Validierung durch das medizinische Fachpersonal senden die Analyseinstrumente die Resultate zur medizinischen Validierung an den zuständigen Arzt. Dabei werden die in der XML-Struktur hinterlegten Informationen via XSLT-Prozessor und Anwendung von XSL-FO in ein gewünschtes Zielformat, beispielsweise PDF, zur besseren Lesbarkeit transformiert.

Nach der Freigabe durch den zuständigen Arzt, werden die Resultate dem niedergelassenen Arzt in Form einer E-Mail zugeschickt bzw. liegen am Server bereit.

Wird das Medium E-Mail verwendet, muss dies wiederum verschlüsselt werden, wobei die Zertifikate des Empfängers und Senders zur Verifizierung benutzt werden. Wird der Befund auf einem Server bereitgestellt, müssen die Informationen durch ein Sicherungsprotokoll geschützt werden. Hierbei ein Secure Socket Layer (SSL) verwendet.

Dessen Hauptaufgaben sind die Authentifikation der Kommunikationspartner unter der Verwendung von asymmetrischen Verschlüsselungsverfahren, die vertrauliche Ende-zu-Ende-Datenübertragung durch die Nutzung eines gemeinsamen Sitzungsschlüssels und die Sicherstellung der Integrität der transportierten Nachrichten.^[134]

Bei diesem Soll-Prozess, indem ebenfalls ein Probenvolumen von 1.266 Röhrchen am Tag (255 Arbeitstage) anfällt, beträgt der Personalaufwand durch den Einsatz durchgängiger elektronischer Datenübertragung sowie vorbarcodierten Probenröhrchen im Durchschnitt 4 Personen pro Tag.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 9: Optimierung der Tätigkeiten im Labor^[135]

5.3 Nettonutzen

Wenn man den Ist-Prozess mit dem Soll-Prozess vergleicht sieht man bereits einen beachtlichen Unterschied im Bezug auf den benötigten Arbeitsaufwand. Hierbei steht der Ist-Prozess mit durchschnittlich 64 Stunden pro Tag dem Soll-Prozess mit 26 Stunden pro Tag gegenüber. Die Differenz von 38 Stunden könnte hierbei für andere Tätigkeiten und ein erhöhtes Probenvolumen verwendet werden.

Geht man von einem durchschnittlichen Kostenaufwand von 18 Euro pro Mitarbeiter (geschätzter Wert) in der Stunde aus, beläuft sich der Kostenunterschied der beiden Prozesse auf 684,00 Euro am Tag. Auf die 255 Arbeitstage aufgerechnet stünden in unserem Beispiel jährlich umgerechnet 174.420,00 Euro zur Verfügung, welche anders investiert werden könnten.

Dem im Kapitel 1.1.2 „ Kosten “ beschriebenen Problem der steigenden Kosten könnte, durch die erhöhte Effizienz und Effektivität mittels Einsatz elektronischer Datenübertragung, teilweise entgegengewirkt werden.

Hinzu kommen die nicht weniger wichtigen Verbesserungen und Problembeseitigungen durch den durchgängigen Einsatz elektronischer Datenübertragung in Kombination mit vorbarcodierten Röhrchen und moderner Infrastruktur.

Die Prozessverbesserungen fangen hierbei bereits beim niedergelassenen Arzt an, da die notwendigen Parameter nicht mehr händisch auf dem Papier hinterlegt, sondern mittels IT-Unterstützung eingepflegt werden. Die verwendete Software kann dem Benutzer dabei mitteilen, welche Parameter vom Patienten privat finanziert werden müssen und welche Kosten von der Krankenkasse gedeckt werden. Somit ist der Patient von Beginn an über die entstehenden Kosten informiert.

Durch den Scan der vorbarcodierten Probenröhrchen werden diese dem Patienten und dessen notwendigen Parametern zugeordnet. Es findet eine Verlinkung statt, welche ein durchgängiges Track and Trace erlaubt. Die bisher am Etikett schriftlich hinterlegten Daten, können von der E-Card übernommen werden, womit es auch hier zu keinen falschen Informationen in der elektronischen Anforderung für das Labor kommt.

Das Laborinformationssystem erhält im dargestellten Soll-Prozess die Informationen zum Auftrag bereits vor den Probenröhrchen über eine VPN Verbindung in Form einer verschlüsselten XSL-Datei und kann im Falle eines Notfalls bereits beim Wareneingang dementsprechend reagieren. Im Wareneingang müssen die Röhrchen nach dem Scan nicht nochmals manuell überprüft werden, da durch den Scan des einzigartigen Barcodes auf den Röhrchen ein Abgleich mit dem Laborauftrag vorgenommen wird. Das Laborinformationssystem wird hierbei automatisch über Verspätungen, welche sich durch zu große Differenzen zwischen Blutabnahme und Wareneingang zeigen, informiert. Weiters wird auch aufgezeigt, ob Probenmaterial verloren gegangen ist. In diesen Fällen kann das Laborpersonal rasch reagieren.

Da alle notwendigen Informationen zum Patienten bereits über den Laborauftrag im LIS elektronisch angelangt sind, müssen auch keine zusätzlichen Daten mehr im System eingepflegt werden. Neben der Zeitersparnis können dabei wiederum Fehler in der Dateneingabe bzw. beim Bekleben von Barcodeetiketten auf den Probenröhrchen vermieden werden.

Durch diese gewonnenen Möglichkeiten im Bereich der Sicherheit können die im Kapitel 1.1.1 „ Medizinische Fehler “, behandelten Probleme ebenfalls minimiert werden.

6 FAZIT UND AUSBLICK

In der vorliegenden Arbeit wird aufgezeigt, dass der Datenaustausch im Gesundheits-wesen, speziell im Laborbereich viel Potential zur Verbesserung zulässt. Probleme wie die inkorrekte Dateneingabe durch Unlesbarkeit manuell beschrifteter Formulare oder Proben-röhrchen können durch vorhandene Technologien und Mittel bereits gelöst werden. Die Extensible Markup Language (XML) spielt hierbei eine herausragende Rolle, zumal diese nicht nur in der Industrie, sondern auch vermehrt im Gesundheitswesen eingesetzt wird.

Um dieses Potential auszuschöpfen ist es jedoch notwendig, die jeweiligen vorhandenen Prozesse zum Datenaustausch genau zu betrachten, da es keine generelle Lösung für ein Labor gibt. Zum Einen ist es daher wichtig auf die vorhandene Infrastruktur und den damit vorhandenen Möglichkeiten zum Datenaustausch einzugehen. Zum Anderen muss das Personal miteingebunden werden und rechtzeitig erkennen, dass der vorhandene Verwaltungsaufwand eingeschränkt und die freigewordenen Ressourcen sinnvoller eingesetzt werden können.

Eine sichere Kommunikation, welche auf den Faktoren Vertraulichkeit, Integrität, Authentizität und Verbindlichkeit aufbaut, ist hierbei unumgänglich. Nur damit können die gesetzlichen Anforderungen zum Schutz der vertraulichen Patientendaten sichergestellt werden.

Der elektronische Datenaustausch im Bereich des Gesundheitswesens hat durch die Einführung der E-Card kräftige Unterstützung erhalten. Ab 04.Juli 2009 soll in Österreich der politische Entschluss zur Einführung der elektronischen Gesundheitsakte (ELGA) fallen. Die Bürger erhalten damit vollen Zugriff auf die über sie gespeicherten Daten, welche über ein Gesundheitsportal übersichtlich und verständlich im Web aufbereitet werden sollen. Über eine Protokollierung werden die Bürger informiert, wer wann was in der jeweiligen Patientenakte eingesehen hat.^[136]

Der Datenaustausch bei ELGA, wie auch die internationalen Dokumentationsstandards HL7, CDA und xDT bauen auf dem internationalen Standard XML auf, welcher somit auch zukünftig eine zentrale Rolle im Gesundheitswesen spielen wird. Auch das eindeutige Urteil des Aktionsforums „Telematik im Gesundheitswesen“ (ATG) lautet einstimmig, dass der medizinische Datenstandard der Zukunft XML heißt.^[137]

Literaturverzeichnis

BÜCHER

Bärwolff, Hartmut / Viktor, Frank / Hüsken, Volker : IT-Systeme in der Medizin: IT-Entscheidungshilfe für den Medizinbereich – Konzepte, Standards und optimierte Prozesse; 1. Auflage, Wiesbaden/Germany, 2006.

Bitzer, Frank : XML im Unternehmen, Briefing fürs IT-Management; 1. Auflage, Bonn/Germany, 2003.

Bodendorf, Freimut : Daten- und Wissensmanagement; 2. Auflage, Heidelberg/Germany, 2006.

Born, Günter : Jetzt lerne ich XML: der einfache Einstieg in den führenden Dokumenten- und Web-Standard; München/Germany, 2005.

Eckert, Claudia : IT-Sicherheit: Konzepte – Verfahren – Protokolle; 4. Auflage, München/Germany, 2006.

Engelken, Gerhard / Wagner, Wolfgang : UNIGRAPHICS-Praktikum mit NX5: modellieren mit durchgängigem Projektbeispiel; 2. Auflage, Wiesbaden/Germany, 2008.

Ernst, Dennis J .: Applied Phlebotomy; Baltimore/USA, 2005.

Gläßer, Lothar : IT-Lösungen im E-Business: Technische Grundlagen; Erlangen/Germany, 2003.

Guder, Walter G. / Nolte, Jürgen : Das Laborbuch für Klinik und Praxis; 1. Auflage, München/Germany, 2005.

Haas, Peter : Gesundheitstelematik: Grundlagen, Anwendungen, Potentiale; Heidelberg/Germany, 2006.

Hunt, Craig : TCP IP, (deutsche Übersetzung von: Lichtenberg, Kathrin / Brodacki, Olaf: TCP IP – Netzwerk-Administration); 3. Auflage, Köln/Germany, 2003.

Jehle, Peter M .: Können wir uns Krankheit in Zukunft überhaupt noch leisten? Gedanken zur Gesundheitsreform aus der Sicht des Krakenhausarztes, in: Sleslina, Wolfgang (Hrsg.): Reformierung des Gesundheitssystems – oder: In welchem Gesundheitssysem wollen wir leben? Eine Disputation; 1. Auflage, Wiesbaden/Germany, 2005.

Johner, Christian / Haas, Peter : Praxishandbuch IT im Gesundheitswesen: erfolgreich einführen, entwickeln, anwenden und betreiben; München/Germany, 2009.

Koether, Reinhard : Taschenbuch der Logistik; 3. Auflage, München/Germany, 2008.

Lupik, Michael / Wiedemann, Bernhard / Schnell, Gerhard : Bussysteme in der Automatisierungs- und Prozesstechnik: Grundlagen, Systeme und Trends der industriellen Kommunikation; 6. Auflage, Wiesbaden/Germany, 2006.

Meinel, Christoph / Sack Harald : WWW: Kommunikation, Internetworking, Web-Technologien; Berlin/Germany, 2003.

Münz, Stefan / Nefzger, Wolfgang : HTML Handbuch; Poing/Germany, 2005.

Niedermeier, Stephan : Cocoon 2 und Tomcat: XML-Publishing mit dem Open-Source-Framework; 2. Auflage, Bonn/Germany, 2007.

Peters, Barbara J. : Medical Error and Patient Safety; Florida/USA, 2007.

Schurr, Michael / Kunhardt, Horst / Dumont, Monika : Unternehmen Arztpraxis – Ihr Erfolgsmanagement: Aufbau, Existenzsicherung, Altersvorsorge; Heidelberg/Germany, 2008.

Skulschus, Marco / Wiederstein, Markus : XML Schema; Berlin/Germany, 2008.

Sollbach, Wolfgang / Thome, Günter : Information Lifecycle Management: Prozessimplementierung; Heidelberg/Germany, 2008.

Swoboda, Joachim / Spitz, Stephan / Pramateftakis, Michael : Kryptographie und IT-Sicherheit: Grundlagen und Awendungen; 1. Auflage, Wiesbaden/Germany, 2008.

Tidwell, Doug : XSLT, (deutsche Übersetzung von: Lichtenberg, Kathrin / Brodacki, Olaf: XSLT – XML Dokumente transferieren); 1. Auflage, Köln/Germany, 2002.

Weitzel, Tim / Harder, Thomas / Buxmann, Peter : Electronic Business und EDI mit XML; 1. Auflage, Heidelberg/Germany, 2001.

Werner, Dieter / Schneider, Uwe : Taschenbuch der Informatik; 6. Auflage, München/Germany, 2007.

Zapotoczky, Klaus / Gampenrieder, Wilma / Schöppl, Ilona : Schnittstellenoptimierung im Gesundheitswesen; Linz/Österreich, 2002.

FACHARTIKEL, JOURNALE

CLSI Committee Membership : H3-A6 – Procedure for the Collection of Diagnostic Blood Specimens by Venipuncture; Approved Standard – Sixth Edition, 2007.

CLSI Committee Membership : AUTO7-A – Laboratory Automation: Data Content for Specimen Identification; Approved Standard, 2004.

Kachler, Marco : Validation von Laborergebnissen, in: MTA Dialog, 09/2006, Jahrgang 7, S. 668.

Österreichischer Berufsverband der Dipl. med-techn. AnalytikerInnen (ÖBV-MTA) : Berufsprofil der/des diplomierten medizinisch-technischen Analytikerin medizinisch-technischen Analytikers; 2003.

Wehrs, Hartmuth : Der Computerführer für Ärzte und EDV-Entscheider im Gesundheitswesen; 13. Auflage, 2005.

INTERNET-QUELLEN

Bauer, Torsten: Das ISO/OSI – Modell; 1997, online im WWW unter URL: http://www.torsten-bauer.de/referate/isoosi/index.html [Stand: 19.05.2009].

Bohsem, Guido : Erschreckende Selbstdiagnose; 02/2008, online im WWW unter URL: http://www.sueddeutsche.de/wissen/673/317547/text/ [Stand: 24.02.2009].

Hack, Günter : Der ELGA-Fahrplan; 05/2008, online im WWW unter URL: http://futurezone.orf.at/stories/276191/ [Stand: 03.07.2009].

Cadamuro, Janne : Von der Blutabnahme zum Befund – Häufige Fehler und Einflüsse; 11/2008, online im WWW unter URL: http://www.zentrallaborsalzburg.at/fileadmin/files/vorlesungen/praeanalytik.pdf [Stand: 26.03.2009].

Hauer, Philipp : Asymmetrische Verschlüsselung. Das Verfahren sowie die Vor- und Nachteile; 12/2006, online im WWW unter URL: http://www.philipphauer.de/info/info/asymmetrische-verschluesselung/ [Stand: 24.05.2009]

Heiny, Lukas : Lockruf der Labormedizin; 10/2008, online im WWW unter URL: http://www.ftd.de/unternehmen/gesundheitswirtschaft/:Gesundheitswirtschaft-Lockruf-der-Labormedizin/422934.html [Stand: 03.04.2009].

Heitmann, Kai U. : Zusammenfassung zur Clinical Document Architecture; 03/2001, online im WWW unter URL: http://sciphox.hl7.de/atwork/cda/ZusammenfassungCDA.pdf [Stand: 26.05.2009].

Ingenerf, Josef : Standards und offene Schnittstellen für einrichtungsübergreifende IT-Anwendungen im Gesundheitswesen; 09/2004, online im WWW unter URL: http://www.imi.uni-luebeck.de/~ingenerf/publications/Integrierte%20Versorgung%202004%20Ingenerf.pdf [Stand: 05.04.2009].

Kämpf, Rainer / Kathan, Nicole : EDI im Internet; 07/2008, online im WWW unter URL: http://www.ebz-beratungszentrum.de/organisation/themen/web-edi.html [Stand 28.04.2009].

Knobloch, Manfred : Einsatzgebiete von XSLT, 2001, online im WWW unter URL:www.xml-web.de/download/DIK2001_Knobloch.pdf[Stand: 17.05.2009]

Moechel, Erich : ISO 27001 - Mehr Sicherheit für Patientendaten; 12/2008, online im WWW unter URL: http://futurezone.orf.at/stories/1500609/ [Stand: 12.04.2009].

Moechel, Erich : ISO 27001 - Mehr Sicherheit für Patientendaten; 12/2008, online im WWW unter URL: http://futurezone.orf.at/stories/1500609/ [Stand: 12.04.2009].

Plebani, Mario / Carraro, Paolo : Mistakes in a stat laboratori: types and frequency; 1997, online im WWW unter URL: http://www.clinchem.org/cgi/reprint/43/8/1348 [Stand: 26.03.2009].

Renz, Burkhardt : Information und Struktur Einführung in XML; 12/1999, online im WWW unter URL: http://homepages.fh-giessen.de/~hg11260/mat/xml-einf.pdf [Stand: 08.05.2009].

Schaller, Tony : Was ist HL7? Eine kurze Einführung in den Standard; online im WWW unter URL: http://www.hl7.ch/downloads/kurzeinfuehrung.pdf [Stand: 24.05.2009].

Walser, Brigitte : Es geht nicht um Labortarife; 03/2009, online im WWW unter URL: http://www.tagesanzeiger.ch/meinungen/dossier/kolumnen--kommentare/Es-geht-nicht-um-Labortarife/story/15959234 [Stand: 03.04.2009].

Walser, Konrad / Egle, Ulrich : Intermediation im schweizerischen Gesundheitswesen; 01/2005, online im WWW unter URL: http://www.im.iwi.unibe.ch/publikationen/pdfs/Interm_eHealth_Arb_Ber.pdf [Stand: 04.04.2009].

Zürcher, Heini / Metzger, Karl : Positive Eindrücke vom dänischen Gesundheitssystem; 2007, online im WWW unter URL: http://www.argomed.ch/webmaster/displayimage.asp?file=pictures%2F354%2F210569%2FArtikel_SAEZ_Nr._3_07.pdf [Stand: 30.03.2009].

o.V.: Statistik Austria; online im WWW unter URL: http://www.statistik.at/web_de/statistiken/gesundheit/gesundheitsausgaben/019701.html [Stand: 29.02.2009].

o.V.: Welt Online; online im WWW unter URL: http://www.welt.de/wissenschaft/article829137/Jeder_1000_Todesfall_im_Krankenhaus_vermeidbar.html [Stand: 26.03.2009].

o.V.: Schelling will Reform der Krankenkassen; online im WWW unter URL: http://noe.orf.at/stories/337691/ [Stand: 30.03.2009].

o.V.: Karriere Medizin - Honorarreform 2009; online im WWW unter URL: http://www.karriere-medizin.com/index.php?id=1262 [Stand: 01.04.2009].

o.V.: Labor Praxis: Labor- und Analysetechnik mit neuen Lösungen auf Wachstumskurs; online im WWW unter URL: http://www.laborpraxis.vogel.de/index.cfm?pid=4706pk=172392print=trueprinttype=article [Stand: 01.04.2009].

o.V.: Informationsgesellschaft Deutschland 2006; 12/2003, online im WWW unter URL: http://www.bmbf.de/pub/aktionsprogramm_informationsgesellschaft_2006.pdf [Stand: 03.04.2009].

o.V.: Österreichisches Normungsinstitut; online im WWW unter URL: http://www.on-norm.at/publish/2080.html?L=0 [Stand: 05.04.2009].

o.V.: eCard – Die wichtigsten Fragen und Fakten; 02/2005, online im WWW unter URL: http://wwwnew.aekwien.at/media/eCard-HaeufigeFragen_aekvb.pdf [Stand: 08.04.2009].

o.V.: Arch Pathol Lab Med: Patient Safety in the clinical laboratory: a longitudinal analysis of specimen identification errors; 11/2006, online im WWW unter URL: http://www.ncbi.nlm.nih.gov/pubmed/17076528 [Stand: 09.04.2009].

o.V.: Bundesgesetzblatt für die Republik Österreich, Gesundheitstelematikverordnung; 12/2008, online im WWW unter URL: http://ris.bka.gv.at/Dokumente/BgblAuth/BGBLA_2008_II_451/BGBLA_2008_II_451.html [Stand: 13.04.2009].

o.V.: Greiner Bio-One: Vacuette® Röhrchen Guide; online im WWW unter URL: http://www.gbo.com/documents/V01_Roehrchen_Guide_000502_d.pdf [Stand: 13.04.2009].

o.V.: Come 2 XML; online im WWW unter URL: http://www.come2xml.de [Stand: 18.04.2009].

o.v.: Von EDI nach XML; online im WWW unter URL: http://www.teialehrbuch.de/Kostenlose-Kurse/XML/7897-Von-EDI-nach-XML.html [Stand: 23.04.2009].

o.V.: EDI Basics; online im WWW unter URL: http://www.edibasics.co.uk/ [Stand: 23.04.2009].

o.V.: EDI Business Austria; online im WWW unter URL: http://www.edi.at/kapitel2.htm [Stand: 23.04.2009].

o.V.: Advance for medical laboratory professionals; online im WWW unter URL: http://laboratorian.advanceweb.com/Editorial/Content/PrintFriendly.aspx?CC=123205 [Stand: 11.05.2009].

o.V.: Informationsstrukturierung / Elektronischer Datenaustausch; online im WWW unter URL: http://www.kodok.de/german/themen/edi/edi2.html [Stand: 23.04.2009].

o.V.: Extensible Markup Language; online im WWW unter URL: http://elib.at/www/wiki/index.php/XML [Stand: 08.05.2009].

o.V.: Einführung in XML; online im WWW unter URL: http://de.selfhtml.org/xml/intro.htm#validierung [Stand: 14.05.2009]

o.V.: XML im praktischen Einsatz; online im WWW unter URL: https://www.pcgo.de/praxis/cm/page/page.php?table=pgid=2104[Stand: 16.05.2009].

o.V.: ISO/OSI-7-Schichtenmodell; online im WWW unter URL: http://www.elektronik-kompendium.de/sites/kom/0301201.htm [Stand: 18.05.2009].

o.V.: HL7 (health level seven); online im WWW unter URL: http://www.itwissen.info/definition/lexikon/health-level-seven-HL7.html [Stand: 24.05.2009].

o.V.: HL7 Anwendergruppe Österreich – Glossar; online im WWW unter URL: http://www.hl7.at/index.php?option=com_rd_glossaryItemid=8 [Stand: 26.05.2009].

o.V.: E-Mail und Datensicherheit – gut geschützt?; 01/2003, online im WWW unter URL: http://www.med-online.de/archiv/2003/01/med0301_13.pdf [Stand: 25.05.2009].

o.V.: Die Telematik-Plattform der kassenärztlichen Vereinigung – Anwendungen; online im WWW unter URL: http://www.d2d.de/index.php?id=6 [Stand: 26.05.2009].

o.V.: HIBC solution – The World Wide Unique Identification Mark (UIM) for Medical Devices; online im WWW unter URL:http://www.fide-online.org/downloads/UIM_english_Dec_2002.pdf [Stand: 27.05.2009].

o.V.: eCard – Daten und Datenschutz; online im WWW unter URL: http://www.chipkarte.at/portal/index.html?ctrl:cmd=renderctrl:window=ecardportal.channel_content.cmsWindowp_menuid=51921p_tabid=5p_pubid=65659 [Stand: 05.06.2009].

o.V.: Honorarreform 2009 – Fakten und Argumente; online im WWW unter URL: http://www.kvsh.de/db2b/upload/downloads/Argumentationspapier%20Honorarreform%2027.04.2009.pdf [Stand: 08.06.2009].

7 EIDESSTATTLICHE ERKLÄRUNG

Ich erkläre an Eides statt, dass ich die Bachelor-Arbeit mit dem Titel „ Nutzenanalyse eines Online-Umfragetools bei der Entwicklung und Modifikation von Produkten “ selbständig und ohne fremde Hilfe verfasst, andere als die angeführten Quellen und Hilfsmittel nicht benutzt und alle wörtlich oder inhaltlich entnommenen Stellen als solche gekennzeichnet habe.

___________________ ___________________

Ort, Datum Unterschrift

[...]

^[1] Vgl. URL: http://www.sueddeutsche.de/wissen/673/317547/text/ [Stand: 24.02.2009].

^[2] Vgl. URL: http://www.welt.de/wissenschaft/article829137/ [Stand: 26.03.2009].

^[3] Vgl. URL: http://ec.europa.eu/health/ph_information/documents/eb_64_de.pdf, S.26, [Stand: 26.03.2009].

^[4] Vgl. URL: http://www.clinchem.org/cgi/content/abstract/48/5/691 [Stand: 07.04.2009].

^[5] Vgl. Kachler, 2006, S. 668.

^[6] Vgl. Abbildung aus: Guder/Nolte, 2005, S. 1.

^[7] Vgl. URL: http://www.clinchem.org/cgi/reprint/43/8/1348, S.2, [Stand: 26.03.2009].

^[8] Vgl. Ernst, 2005, S. 62.

^[9] Vgl. URL: http://wwwnew.aekwien.at/media/eCard-HaeufigeFragen_aekvb.pdf [Stand: 08.04.2009].

^[10] Vgl. CLSI Committee Membership: H3-A6, Vol. 27, No. 26, S. 18f.

^[11] Vgl. URL: http://www.ncbi.nlm.nih.gov/pubmed/17076528 [Stand: 09.04.2009].

^[12] Vgl. Jehle, 2005, S. 83.

^[13] Vgl. URL: http://www.statistik.at/web_de/statistiken/gesundheit/gesundheitsausgaben/019701.html [Stand: 29.02.2009].

^[14] Vgl. URL: http://www.argomed.ch/webmaster/displayimage.asp?file=pictures%2F354%2F210569%2FArtikel_SAEZ_Nr._3_07.pdf [Stand: 30.03.2009].

^[15] Vgl. URL: http://www.karriere-medizin.com/index.php?id=1262 [Stand: 01.04.2009].

^[16] Vgl. URL: http://www.kvsh.de/db2b/upload/downloads/Argumentationspapier%20Honorarreform%2027.04.2009.pdf [Stand: 08.06.2009].

^[17] Vgl. URL: http://www.laborpraxis.vogel.de/index.cfm?pid=4706pk=172392print=trueprinttype=article [Stand: 01.04.2009].

^[18] Vgl. URL: http://www.tagesanzeiger.ch/meinungen/dossier/kolumnen--kommentare/Es-geht-nicht-um-Labortarife/story/15959234 [Stand: 03.04.2009].

^[19] Vgl. URL: http://www.ftd.de/unternehmen/gesundheitswirtschaft/:Gesundheitswirtschaft-Lockruf-der-Labormedizin/422934.html [Stand: 03.04.2009].

^[20] Vgl. URL: http://www.bmbf.de/pub/aktionsprogramm_informationsgesellschaft_2006.pdf [Stand: 03.04.2009].

^[21] Peters, 2007, S. 145.

^[22] Vgl. Abbildung aus: URL: http://www.im.iwi.unibe.ch/publikationen/pdfs/Interm_eHealth_Arb_Ber.pdf [Stand: 04.04.2009].

^[23] Vgl. URL: http://www.on-norm.at/publish/1171.html [Stand: 05.04.2009].

^[24] Vgl. URL: http://www.on-norm.at/publish/2080.html?L=0 [Stand: 05.04.2009].

^[25] Abbildung entnommen aus: URL: http://www.imi.uni-luebeck.de/~ingenerf/publications/Integrierte%20Versorgung%202004%20Ingenerf.pdf [Stand: 05.04.2009].

^[26] Vgl. URL: http://www.ftd.de/unternehmen/gesundheitswirtschaft/:Gesundheitswirtschaft-Lockruf-der-Labormedizin/422934.html [Stand: 09.04.2009].

^[27] Vgl. Guder / Nolte, 2005, S. 21.

^[28] Eigene Darstellung.

^[29] Eigene Darstellung.

^[30] Vgl. Abbildung aus: URL: http://www.gbo.com/documents/980103_HandlingRecommendations_051207_d.PDF [Stand: 13.04.2009].

^[31] Vgl. CLSI Committee Membership: AUTO7, Vol. 24, No. 20, S.5.

^[32] Eigene Darstellung.

^[33] Eigene Darstellung.

^[34] Vgl. ÖBV-MTA, 2003, S. 29.

^[35] Schätzung basiert auf eigener Erhebung

^[36] Vgl. Abbildung aus: URL: http://www.labor-limbach.de/fileadmin/user_upload/Dokumente/Anforderungsformulare/Anforderungsblatt1.pdf [Stand: 05.06.2009].

^[37] Vgl. Zapotoczky / Gampenrieder / Schöppl, 2002, S.102.

^[38] Vgl. URL: http://laboratorian.advanceweb.com/Editorial/Content/PrintFriendly.aspx?CC=123205 [Stand: 11.05.2009].

^[39] Vgl. URL: http://futurezone.orf.at/stories/1500609/ [Stand: 12.04.2009].

^[40] Vgl. URL: http://ris.bka.gv.at/Dokumente/BgblAuth/BGBLA_2008_II_451/BGBLA_2008_II_451.html [Stand: 13.04.2009].

^[41] Vgl. Weitzel / Harder / Buxmann, 2001, S. 6.

^[42] Vgl. URL: http://www.teialehrbuch.de/Kostenlose-Kurse/XML/7897-Von-EDI-nach-XML.html [Stand: 23.04.2009].

^[43] Abbildung übernommen aus: URL: http://www.edi.at/kapitel2.htm [Stand: 23.04.2009].

^[44] Vgl. Weitzel / Harder / Buxmann, 2001, S. 6.

^[45] Vgl. URL: http://www.edi.at/kapitel2.htm [Stand: 28.04.2009].

^[46] Vgl Weitzel / Harder /Buxmann, 2001, S. 7f.

^[47] Vgl. URL: http://www.teialehrbuch.de/Kostenlose-Kurse/XML/7897-Von-EDI-nach-XML.html [Stand: 28.04.2009].

^[48] Vgl. URL: http://www.ebz-beratungszentrum.de/organisation/themen/web-edi.html [Stand 28.04.2009].

^[49] Vgl. Weitzel / Harder /Buxmann, 2001, S. 8.

^[50] Vgl. URL: http://www.ebz-beratungszentrum.de/organisation/themen/web-edi.html [Stand: 04.05.2009].

^[51] Bitzer, 2003, S. 9.

^[52] Vgl. Bitzer, 2003, S. 9f.

^[53] Vgl. Meinel / Sack, 2003, S. 806.

^[54] Vgl. URL: http://www.come2xml.de/was_ist_sgml.html [Stand: 18.04.2009].

^[55] Vgl. URL: http://www.boku.ac.at/htmleinf/heinwas.html#sgml [Stand: 18.04.2009].

^[56] Vgl. Meinel / Sack, 2003, S. 806.

^[57] Vgl. Witzel / Harder / Buxmann, 2001, S. 19.

^[58] Vgl. Abbildung aus: Weitzel / Harder / Buxmann, 2001, S. 19.

^[59] Vgl. Witzel / Harder / Buxmann, 2001, S.19.

^[60] Vgl. URL: http://www.come2xml.de/about.html [Stand: 18.04.2009].

^[61] Vgl. Born, 2005, S. 47.

^[62] Abbildung übernommen aus: URL: http://homepages.fh-giessen.de/~hg11260/mat/xml-einf.pdf [Stand: 08.05.2009].

^[63] Vgl. URL: http://elib.at/www/wiki/index.php/XML [Stand 08.05.2009].

^[64] Abbildung übernommen aus: Bitzer, 2003, S. 56.

^[65] Vgl. Bitzer, 2003, S. 45.

^[66] Vgl. Bodendorf, 2006, S. 74.

^[67] Vgl. Bitzer, 2003, S. 55.

^[68] Vgl. URL: http://de.selfhtml.org/xml/intro.htm#validierung [Stand: 14.05.2009].

^[69] Vgl. Bitzer, 2003, S. 32.

^[70] Vgl. Skulschus / Wiederstein, 2008, S. 14.

^[71] Vgl. Werner / Schneider, 2007, S. 708.

^[72] Gläßer, 2003, S. 72.

^[73] Tidwell, 2002, S.1.

^[74] Vgl. Niedermeier, 2007, S.73.

^[75] Vgl. Abbildung aus: URL:www.xml-web.de/download/DIK2001_Knobloch.pdf[Stand: 17.05.2009].

^[76] Vgl. Weitzel / Harder / Buxmann, 2001, S. 40.

^[77] Vgl. Münz / Nefzger, 2005, S.66.

^[78] Vgl. URL: https://www.pcgo.de/praxis/cm/page/page.php?table=pgid=2104 [Stand: 16.05.2009].

^[79] Vgl. Lupik / Wiedemann / Schnell, 2006, S.8.

^[80] Vgl. Münz / Nefzger, 2005, S.29ff.

^[81] Hunt, 2003, S.11.

^[82] Vgl. Lupik / Wiedemann / Schnell, 2006, S.8.

^[83] Vgl. URL: http://www.elektronik-kompendium.de/sites/kom/0301201.htm [Stand: 18.05.2009].

^[84] Vgl. Koether, 2008, S. 219.

^[85] Vgl. Eckert, 2006, S. 77.

^[86] Vgl. Lupik / Wiedemann / Schnell, 2006, S. 14.

^[87] Vgl. URL: http://www.torsten-bauer.de/referate/isoosi/index.html [Stand: 19.05.2009].

^[88] Lupik / Wiedemann / Schnell, 2006, S. 10.

^[89] Vgl. Engelken / Wagner, 2008, S.276.

^[90] Vgl. URL: http://www.karakas-online.de/teia/XML/xml_1_1_2.htm [Stand: 17.05.2009].

^[91] Vgl. URL: http://www.a-s-hofem.de/nwchap11.htm [Stand: 20.05.2009].

^[92] Vgl. Eckert, 2006, S. 6.

^[93] Eigene Darstellung.

^[94] Vgl. Eckert, 2006, S. 6.

^[95] Vgl. Swoboda / Spitz / Pramateftakis, 2008, S. 15.

^[96] Vgl. URL: http://www.philipphauer.de/info/info/asymmetrische-verschluesselung/ [Stand: 24.05.2009].

^[97] Vgl. URL: http://www.rubin.ch/pgp/wasistpgp.html [Stand: 24.05.2009].

^[98] Vgl. Sollbach / Thome, 2008, S. 274.

^[99] Vgl. Eckert, 2006, S. 8.

^[100] Eckert, 2006, S. 8.

^[101] Vlg. Eckert, 2006, S. 7.

^[102] Vgl. Eckert, S. 11.

^[103] Vgl. URL: http://www.aerzteblatt.de/V4/archiv/artikel.asp?id=49873 [Stand: 17.05.2009].

^[104] Vgl. Wehrs, 2005, S. 36.

^[105] Vgl. URL: http://www.hl7.org/ [Stand: 24.05.2009].

^[106] Abbildung entnommen aus: Bärwolff / Victor / Hüsken, 2006, S. 52.

^[107] Vgl. Bärwolff / Victor / Hüsken, 2006, S. 56.

^[108] Vgl. URL: http://www.itwissen.info/definition/lexikon/health-level-seven-HL7.html [Stand: 24.05.2009].

^[109] Vgl. URL: http://www.hl7.ch/downloads/kurzeinfuehrung.pdf [Stand: 24.05.2009].

^[110] Vgl. Bärwolff / Victor / Hüsken, 2006, S. 54.

^[111] Vgl. URL: http://sciphox.hl7.de/atwork/cda/ZusammenfassungCDA.pdf [Stand: 26.05.2009].

^[112] URL: http://www.hl7.at/index.php?option=com_rd_glossaryItemid=8 [Stand: 26.05.2009].

^[113] Abbildung entnommen aus: Haas, 2006, S. 334.

^[114] Vgl. Bärwolff / Victor / Hüsken, 2006, S. 61.

^[115] Vgl. Haas, 2006, S. 341.

^[116] Vgl. Bärwolff / Victor / Hüsken, 2006, S. 146.

^[117] Vgl. Johner / Haas, 2009, S. 264.

^[118] Vgl. Bärwolff / Victor / Hüsken, 2006, S. 147.

^[119] Vgl. Schurr / Kunhardt / Dumont, 2008, S. 115.

^[120] Vgl. Bärwolff / Victor / Hüsken, 2006, S. 152f.

^[121] Vgl. URL: http://www.med-online.de/archiv/2003/01/med0301_13.pdf [Stand: 25.05.2009].

^[122] Vgl. Bärwolff / Victor / Hüsken, 2006, S. 153.

^[123] Vgl. URL: http://www.d2d.de/index.php?id=6 [Stand: 26.05.2009].

^[124] Vgl Wehrs, 2005, S. 42ff.

^[125] Eigene Darstellung.

^[126] Eigene Darstellung.

^[127] Abbildung entnommen aus: URL: http://www.vacuette.es/ [Stand: 27.05.2009].

^[128] Grafik entnommen aus: URL: www.vacuette.com [Stand: 27.05.2009].

^[129] Vgl. URL:http://www.fide-online.org/downloads/UIM_english_Dec_2002.pdf [Stand: 27.05.2009].

^[130] Eigene Darstellung.

^[131] Vgl. URL: http://www.chipkarte.at/portal/index.html?ctrl:cmd=renderctrl:window=ecardportal.channel_content.cmsWindowp_menuid=51921p_tabid=5p_pubid=65659 [Stand: 05.06.2009].

^[132] Eigene Darstellung.

^[133] Eigene Darstellung.

^[134] Vgl. Eckert, 2006, S. 736.

^[135] Schätzung basiert auf eigener Erhebung

^[136] Vgl. URL: http://futurezone.orf.at/stories/276191/ [Stand: 03.07.2009].

^[137] Wehrs, 2005, S. 44.