Im Folgenden werden nun die Ergebnisse der vorhergehenden Kapitel unter Hinzunahme einer weiteren Komponente - den Potentialen von EDI - kombiniert: Es wird beschrieben, in welchen Bereichen und unter welchen Umständen der elektronische Datenaustausch eingesetzt werden kann. Die damit verbundenen Nutzeffekte und der Beitrag der Standards zur Ausschöpfung dieser Potentiale werden aufgezeigt.
Zuerst werden im nachfolgenden Unterkapitel grundlegende Überlegungen zu den Schnittstellen beim elektronischen Datenaustausch gemacht. Die entsprechende Problematik tritt typischerweise bei den vielfältigen Systemen der Krankenhäuser auf, weshalb sich die Ausführungen in diesem Abschnitt auf die Spitäler konzentrieren. Beim Vergleich zwischen Möglichkeiten und Potentialen werden neben den Krankenhaus-internen Beziehungen auch externe Beziehungen des Krankenhauses und den anderen Institutionen des Gesundheitswesens untersucht.
"The principal function of a hospital information system is not computation but communication" ([Blei92]). Eine zentrale Bedeutung eines Krankenhaus-Informationssystems kommt dem Erfassen, Speichern und Zusammenstellen (neu anordnen) von Daten zu, um diese anschliessend anzuzeigen oder auszudrucken. Durch die heterogene Umgebung im Krankenhaus, hervorgerufen durch die unterschiedlichen Aufgaben der einzelnen Abteilungen, sind oft verschiedene EDV-Systeme im Einsatz. Um dem hohen Kommunikationsbedarf gerecht zu werden, müssen zwischen diesen Systemen Brücken geschlagen werden.
Für ein Verständnis des elektronischen Datenaustauschs, dem Einsatz von Standards und den daraus resultierenden Potentialen müssen grundlegende Überlegungen zu den Schnittstellen gemacht werden.
Unter "integriert" wird verstanden, dass einzelne Teile zu einem Ganzen zusammengeführt werden. In diesem Sinne kann ein System mit inneren Schnittstellen zwischen seinen Subsystemen als "integriert" bezeichnet werden. Ein solches System ist aber von einem System abzugrenzen, welches in sich selbst keine Subsysteme und somit keine Schnittstellen hat. Letzteres wird hier als "vollständig integriert" oder "integriert im engeren Sinne" verstanden.
Bei einem integrierten System im engeren Sinne benutzen also alle Beteiligten die gleiche Datenbank. Die Daten werden nicht redundant gehalten, und Modifikationen sind sofort "wirksam" und für alle sofort sichtbar. Jeder arbeitet immer mit den aktuellen Daten ([Bei92]). In einem solchen Umfeld müssen keine Daten ausgetauscht werden, und EDI sowie die damit verbundenen Standards werden nicht gebraucht. Der Aufwand für den elektronischen Datenaustausch entfällt (oder präziser gesprochen, der Arbeitsaufwand verschiebt sich auf eine andere Ebene, die Datenbank oder den Hersteller). Hauptvorteil dieses Systems ist die zusätzliche Funktionalität: Durch den Wegfall von Barrieren (EDI), können die Daten problemlos für verschiedene Zwecke verwendet werden, unabhängig von der ursprünglichen Absicht, in der sie eingegeben wurden.
Für ein Krankenhaus bedeutet dies, dass ein einziges EDV-System gekauft wird. Hard- und Software sind aufeinander abgestimmt und kommen (wahrscheinlich) vom gleichen Anbieter.
Ein vollständig integriertes System stellt sicherlich den Idealfall dar. Leider gibt es aber eine Reihe von Gründen und Problemen, wieso ein solches System nicht bzw. nur begrenzt eingesetzt werden kann:
Ein anderer Extremfall ist ein Szenario, bei dem verschiedene EDV-Systeme existieren, diese aber nicht miteinander kommunizieren. Die Folgen können sein, dass die Systeme über einen "zu kleinen" Teil des relevanten Umweltausschnitts informieren und eine ganzheitliche Sicht nicht ermöglicht wird oder nur durch zusätzlichen Aufwand erreicht werden kann.
Ein solch ungünstiges Szenario gilt es in jedem Fall zu vermeiden. Wenn keine Schnittstellen vorhanden sind, können die Daten nicht elektronisch ausgetauscht und direkt weiterverarbeitet werden. Medienbrüche und erhebliche Kosten entstehen, und Potentiale werden nicht ausgeschöpft.
Dies gilt für den Datenaustausch zwischen Unternehmungen allgemein (denn EDI zielt genau auf diesen Bereich ab), es gilt aber auch für das Gesundheitswesen und insbesondere für den Datenaustausch innerhalb der Krankenhäuser, wo ja - wie oben beschrieben - die Kommunikation ein extrem wichtiger Faktor ist.
(Das Kapitel 4.3, "Vergleich von Potentialen und Möglichkeiten", nennt explizit die Potentiale des elektronischen Datenaustauschs im Gesundheitswesen.)
Ein erster Schritt in Richtung "ganzheitliche Sicht" kann gemacht werden, wenn den Benutzern der Zugriff auf die benötigten Systeme ermöglicht wird. In diesem Fall sind zwar zusammengehörende Daten in verschiedenen Datenbanken aufbewahrt und somit getrennt, aber sie können vom Anwender einzeln eingesehen und modifiziert werden. Der Benutzer kann sich durch Recherchen in den verschiedenen Systemen einen Überblick verschaffen. Die Daten können jedoch nicht von den EDV-Systemen übergreifend verwendet und kombiniert werden.
Meistens verfügt ein EDV-System nicht über alle relevanten Daten, und der Benutzer benötigt zusätzliche und aktuelle Informationen. Wenn die entsprechenden Daten in einem anderen System bereits elektronisch vorhanden sind, ergeben sich durch den elektronischen Austausch dieser Daten eine Reihe von Vorteilen (vgl. folgende Kapitel). Eine Kommunikation und somit eine Integration im weiteren Sinne zwischen den Systemen ist erstrebenswert. Dabei werden die Daten aus der Datenbank des einen Systems selektiert und über Schnittstellen in das andere System transferiert. Dort werden sie in der Regel in die Datenbank integriert (oder in Ausnahmefällen auf dem Ausgabemedium angezeigt).
Um die Verbindung und die Kommunikation zu ermöglichen, sind neben einer physischen Verbindung (Koaxial, Glasfaser,..) zwischen den beteiligten Parteien eine Fülle von Normen und Regeln notwendig. Bei der Wahl des Datenaustauschformats sind grundsätzlich die folgenden zwei Möglichkeiten denkbar:
Meistens wird bei der Benutzung eines Standards nur ein Bruchteil der zur Verfügung stehenden Möglichkeiten verwendet. Wenn die Bedürfnisse der Anwender sich ändern, stellt der Standard durch das breite Angebot oft die gewünschten Nachrichtentypen und Komponenten bereits zur Verfügung. Zudem beruhen die Standards häufig auf einer soliden Basis und können vom Standardisierungsgremium oder durch den Benutzer ausgebaut werden.
Flexibilität innerhalb des Standards selbst wie auch bezüglich Integration (neuer) Systeme sind somit die Hauptvorteile. Als Folge dieser Flexibilität können weitere Vorteile resultieren wie beispielsweise das Ermöglichen einer Zusammenarbeit mit Partnern oder allgemein die Akzeptanz bei anderen Marktteilnehmern.
Zudem muss der Standard nicht selbst entwickelt werden und kann übernommen werden. Die Wahrscheinlichkeit, dass sich beim Standard grundlegende Fehler eingeschlichen haben, ist dadurch relativ klein, und fremdes Know-how ist in den Standard eingeflossen.
An Grenzen stösst man bei dieser Alternative, wenn ein Standard für das gewünschte Einsatzgebiet nicht existiert oder er die Bedürfnisse des Anwenders nicht zu befriedigen vermag. Ein weiteres Problem kann der enorme Aufwand infolge eines umfangreichen und flexiblen Standards sein, so dass vor allem für kleinere Institutionen der Nutzen zu gering und ein Einsatz somit fraglich ist.
Bei den "verbreiteten" Standards können zwei Typen unterschieden werden: Standards, welche durch Normierungsgremien (eher theoretisch) erarbeitet wurden, und "De-facto Standards", welche aufgrund einer grossen Benutzerzahl eine bedeutende Stellung eingenommen haben. Ein "De-facto Standard" kann beispielsweise auch ein Datenaustauschformat eines bedeutenden Softwareherstellers sein.
Wird in vielen Krankenhäusern die gleiche Soft- und Hardware verwendet (wenige Anbieter, welche sich auf diesen Bereich spezialisiert haben), so wird dadurch der elektronische Datenaustausch erleichtert. Um eine Integration im weiteren (als auch im engeren) Sinne zu vereinfachen, könnten innerhalb eines Krankenhauses Soft- und Hardware möglichst vom gleichen Hersteller benutzt werden. Fraglich ist hierbei allerdings, ob sich ein entsprechender Anbieter mit einem derart umfassenden Angebot finden lässt. Noch besser ist es, wenn die in den Krankenhäusern eingesetzte Software wichtige Standards wie beispielsweise HL7 und DICOM unterstützt.
In den Krankenhäusern sind die einzelnen EDV-Systeme typischerweise historisch gewachsen, und es werden je nach Abteilung unterschiedliche Systeme verwendet. Die Daten werden von den betreffenden Systemen in getrennten Datenbanken verwaltet. Um Insellösungen zu vermeiden, wurden und werden die entsprechenden Daten elektronisch über die Schnittstellen ausgetauscht. Dass Insellösungen - vor allem in einem Krankenhaus, wo die Kommunikation ein wichtiger Faktor ist - den ungünstigsten Fall darstellen, bleibt unbestritten. Welche Vor- und Nachteile ergeben sich aber bei einem integrierten System im weiteren Sinne gegenüber einem vollständig integrierten System? Sollen die Systeme und deren Schnittstellen, welche heute in den Krankenhäusern vorhanden sind, durch ein einziges System ersetzt werden?
Die Vorteile eines "vollständig integrierten Systems" sind im betreffenden Kapitel bereits erwähnt worden. Im Vergleich dazu muss bei Systemen mit Schnittstellen folgendes beachtet werden (vgl. [Blei92]):
Bei einem vollständig integrierten System entfällt dieser Aufwand für den Anwender und wird vom Hersteller übernommen.
Wenn mehrere EDV-Systeme im Einsatz sind, welche untereinander Daten austauschen sollen, stellt sich die Frage, wie die Verbindungen und Schnittstellen zwischen den Systemen angeordnet werden sollen:
Der Datenaustausch zwischen Systemen verschiedener Institutionen des Gesundheitswesens kann beispielsweise über ein Clearing Center realisiert werden. Die verschiedenen Möglichkeiten und ihre Vor- und Nachteile haben allgemeingültigen Charakter und sind nicht nur für das Gesundheitswesen gültig. Deshalb wird an dieser Stelle nicht darauf eingegangen. (Einige Überlegungen zu diesem Thema lassen sich aber trotzdem im folgenden Abschnitt wiederfinden.)
Für die Gestaltung der Verbindungen und Schnittstellen innerhalb eines Krankenhauses sind ebenfalls verschiedene Varianten denkbar. Mögliche Architekturen werden im Folgenden kurz beschrieben (vgl. Kantonsspital Schaffhausen):
Hervorgerufen durch die heterogene Zusammensetzung eines Krankenhauses sind oft verschiedene EDV-Systeme vorhanden, welche miteinander kommunizieren sollten. Eine triviale Lösung, um diese Forderung zu erfüllen, stellt die Punkt-zu-Punkt Verbindung dar; es wird untersucht, welche Systeme miteinander Daten austauschen müssen, und verbindet sie direkt.
Diese Variante mag zwar in einer Ausgangslage mit Insellösungen flexibel und als schnell zu realisieren erscheinen, bei steigender Anzahl Kommunikationsbeziehungen stösst man bei dieser Lösung jedoch schnell an Grenzen:
Bei der Einbindung neuer Systeme müssen zu allen Kommunikationspartnern Verbindungen und Schnittstellen bereitgestellt werden. Speziell im Krankenhaus muss zu einigen Systemen praktisch immer eine Verbindung erstellt werden (Buchhaltung, Patientenadministration).
Die Anzahl zu wartender Schnittstellen und Verbindungen steigt bei Hinzunahme weiterer Systeme überproportional.
Eine Alternative stellt die (zentrale) Daten-Drehscheibe dar, wie sie beispielsweise im Kantonsspital Schaffhausen geplant ist. Hier fliessen sämtliche auszutauschende Daten über ein zentrales System. Im Prinzip entspricht diese Idee genau derjenigen eines Clearing-Centers, wie es bei EDI häufig eingesetzt wird. Lediglich die Grössenordnung ist eine andere, weil sich die Daten-Drehscheibe auf das Krankenhaus beschränkt.
Jedes System wird mit der Drehscheibe verbunden, und pro System ist nur eine einzige Schnittstelle zu implementieren und zu warten. Systeme können auf diese Art und Weise - vor allem bei vielen Kommunikationspartnern - flexibel eingebunden und entfernt werden. Eine enge Beziehung aufgrund des grossen Datenverkehrs wird sich zwischen der Drehscheibe und den Systemen "Buchhaltung" bzw. "Patientenadministration" ergeben; ein reibungsloser Datenaustausch zwischen diesen Systemen muss gewährleistet sein.
Weiter ist bei einer solchen Lösung zu beachten (vgl. [Schm92], "Clearing Center"):
Neben den beiden genannten Möglichkeiten sind selbstverständlich auch Mischformen möglich; das heisst, es werden grundsätzlich alle Daten über ein einziges System ausgetauscht, aber in Ausnahmefällen oder bei einer sukzessiven Umstellung von einer Variante zur anderen sind die involvierten Parteien direkt verbunden.
Die Situation wird sich nie vermeiden lassen, in der ein System über Daten verfügt, welche in der Datenbank eines anderen Systems benötigt werden. In einem solchen Fall müssen die Daten über Schnittstellen ausgetauscht werden. Mit dem elektronischen Datenaustausch ist eine Reihe von Potentialen verbunden. Diese Potentiale sind sowohl bei der Verwendung eines verbreiteten Datenaustauschformats als auch bei individuellen Formaten vorhanden, aber für die Realisierung und den tatsächlichen Nutzen spielen Standards eine zentrale Rolle.
Wenn nun untersucht wird, in welchen Bereichen des Gesundheitswesens die Daten elektronisch ausgetauscht werden können, müssen zuerst die vorhandenen Datenbanken ermittelt werden.
Bei den Beziehungen zwischen den Institutionen ist das Ganze relativ einfach: Typischerweise besitzt jede Institution ihr eigenes System und ihre eigenen Datenbanken, so dass die Möglichkeiten für den Einsatz des elektronischen Datenaustauschs leicht erkennbar sind.
Im Krankenhaus kann das Einsatzgebiet von EDI nur sehr viel schwieriger und differenzierter bestimmt werden, denn die vorhandenen Datenbanken können je nach Spital unterschiedlich angeordnet sein; im Extremfall wird für das Krankenhaus eine einzige Datenbank verwendet, so dass sich der elektronische Datenaustausch innerhalb des Spitals erübrigt.
Die Unterscheidung zwischen "vollständig integrierten Systemen" und "Systemen mit Schnittstellen" wurde in Anlehnung an [Blei92] gemacht und anschliessend aufgrund der Interviews in den Krankenhäusern detaillierter unterschieden. Vor- und Nachteile einer Daten-Drehscheibe und einer dezentralen Lösung sind [Schm92] und [Emme93] entnommen.