Stete Weiterentwicklung nötig - Integration heterogener IT-Systeme im Krankenhaus

Table of Contents

Zusammenfassung

Vor 20 Jahren wurden die ersten IT-Anwendungssysteme, in der Regel Patientenmanagementsysteme, Labor- und Radiologieinformationssysteme, aufwändig und teuer über proprietäre Schnittstellen miteinander gekoppelt. Der Einsatz von Kommunikationsservern und die Weiterentwicklung der Standards (z.B. HL7 und DICOM) ermöglichen inzwischen, den Aufwand für die Realisierung und Betreuung der Schnittstellen um 60-80 % zu reduzieren [10]. Dennoch müssen die Standardisierungsbemühungen fortgesetzt werden. Denn wenn die Kompatibilität und Interoperabilität von unabhängig entwickelten (autonomen) Teilsystemen erhöht werden soll, dann brauchen wir weit reichende Standards, welche die notwendigen Rahmenbedingungen festlegen, an denen sich die Hersteller orientieren müssen. Damit müssen sich nicht alle Hersteller auf ein gemeinsames „universelles” Datenbankschema festlegen, sie müssen sich jedoch zumindest bezüglich der Semantik gemeinsam genutzter Kontextdaten einigen. Zudem muss jedes Teilsystem in der Lage sein, sich in eine übergeordnete Systemarchitektur einzufügen und dabei teilweise die Kontrolle an zentrale Steuerungskomponenten abzugeben. Ein entscheidendes Kriterium für die Qualität einer Integrationslösung ist auch die Fähigkeit zur Weiterentwicklung: So müssen sich Krankenhausinformationssysteme ständig neuen Anforderungen anpassen (z.B. neue diagnostische und therapeutische Verfahren, organisatorische Veränderungen, Krankenhauszusammenschlüsse, veränderliche gesetzliche Rahmenbedingungen).

Summary

20 years ago, the first IT systems - as a rule patient management systems, laboratory and radiology information systems - were linked together via proprietary interfaces, which was both complicated and expensive. In the meantime, the use of communication servers and the further development of standards (e.g. HL7 and DICOM) have made it possible to reduce by 60-80 % the effort needed to realize and maintain the interfaces. Nevertheless, standardization efforts need to be continued, since, if compatibility and interoperability of independently developed (autonomous) subsystems are to be improved, we need comprehensive standards that establish the necessary basic conditions to which manufacturers must orientate themselves. While this does not mean that all manufacturers must favour a common „universal” database schema, they must agree at least on the semantics of commonly employed context data. Furthermore, every subsystem must be integratable in a higher-level system architecture and, in part, relinquish control to central control components. A major criterion for the quality of an integration solution is the ability to support further development: thus, a hospital information system must constantly adapt to new demands (e.g. new diagnostic and therapeutic methods, organisational changes, hospital mergers, changes in basic legal requirements.

Key Words

IT-Systems - hospital information system - patient management systems - laboratory information systems - standardization - database - integration

Die Infrastruktur der Informationstechnologie (IT) der meisten Krankenhäuser ist heute durch eine limitierte Zahl gekoppelter, heterogener Systeme (etwa drei bis zehn, in Ausnahmefällen aber bis zu 30) gekennzeichnet. Diese und autarke Systeme, die physische Werkzeugebene (z.B. Server, Speicher, PCs, Netz, Organisationsmittel) sowie die in ihrer informationsverarbeitenden Rolle beteiligten menschlichen Handlungsträger bilden den rechnerunterstützten Teil eines Krankenhausinformationssystems (KIS) [19].

Traditionelle Kernsysteme eines Krankenhausinformationssystems sind das Patientendatenmanagement zur Verwaltung von Aufnahmen, Entlassungen und Verlegungen sowie kaufmännische Systeme für Finanzbuchhaltung, Materialwirtschaft und Controlling. In der Regel übernimmt das Patientendatenmanagement auch die wichtige zentrale Aufgabe der Vergabe von Patienten- und Fallidentifikationen. Diese Funktion ist sehr wichtig, um die verschiedenen Informationen aus den verschiedenen Anwendungssystemen und medizinischen Geräten zusammenführen zu können.

Weit verbreitet und fest etabliert sind auch Abteilungssysteme wie das Laborinformationssystem (LIS) und das Radiologieinformationssystem (RIS). Darüber hinaus dringt die Informationstechnologie inzwischen weit in klinische Bereiche vor: So unterstützen diese Systeme zusammen mit so genannten klinischen Arbeitsplatzsystemen (KAS) die Auftrags- und Befundkommunikation für Stationen und Ambulanzen. Immer häufiger sind auch bild- und signalgebende Modalitäten (z.B. Magnetresonanztomografie, Computertomografie, Ultraschall, Herzkatheter) in die rechnerunterstützte klinische Informationsverarbeitung eingebunden.

In diesem Zusammenhang werden bereits häufig PAC-Systeme („picture archiving and communication systems” = PACS) eingesetzt. Diese übernehmen Bilder von den bildgebenden Geräten (Bildakquisition), sodass die Befundung der Bilder und Bildsequenzen (Bilddiagnostik) und die Bilddemonstration für andere Abteilungen (Bildkonferenzen) durchgeführt, die Bilder zusammen mit den radiologischen Befunden archiviert und später bei Bedarf bereitgestellt werden können. Das System kann aber auch die Bildkommunikation innerhalb eines Krankenhauses und mit externen Institutionen unterstützen. Wichtig ist, dass Bild und Befund bei der Bilddemonstration und -kommunikation als eine Einheit betrachtet werden.

In der klinischen Informationsverarbeitung nimmt die Bedeutung der elektronischen Patientenakte [6] [7] [14] [16] ständig zu. In dieser werden die medizinischen Informationen einer Person in genau einer Institution auf digitalen Datenträgern gespeichert. Dazu gehören unter anderem Textdokumente, Bilder, Signale oder Filme zur Dokumentation der Anamnese sowie diagnostischer, therapeutischer, pflegerischer und administrativer Maßnahmen. Die Dokumente der elektronischen Patientenakten können in verschiedenen Anwendungssystemen aufbewahrt, zwischen Systemen ausgetauscht, aber auch an ein zentrales digitales Patientenarchiv übergeben werden.

Ein solches Archiv ist jedoch nicht nur ein Aufbewahrungsort von elektronischen Patientenakten, es muss auch eine ordnungsgemäße, revisionssichere und rechtlich anerkannte elektronische Aufbewahrung der Daten über einen Zeitraum von 30 Jahren und mehr sicherstellen. Mit der Novellierung des Signaturgesetzes und den Anpassungen im privaten und öffentlichen Recht ist seit dem Jahr 2002 ein Lösungsansatz für die rechtliche Anerkennung der elektronischen Langzeitarchivierung gegeben. Der §126a des Bürgerlichen Gesetzbuches definiert elektronische Dokumente, die mit einer qualifizierten elektronischen Signatur nach dem Signaturgesetz versehen sind, als elektronische Form. Für diese gilt nach §192a Zivilprozessordnung der Anschein der Echtheit.

Ansätze zum Aufbau elektronischer Patientenakten sind:

• die zeitnahe digitale Erfassung standardisierter, strukturierter Daten am Ort der Entstehung und ihre direkte Ablage in einer elektronischen Patientenakte

• die zeitnahe digitale Erstellung von freitextlichen Dokumenten und ihre direkte Ablage in einer elektronischen Patientenakte

• die automatische Übernahme von Dokumenten aus daten- und dokumentenerzeugenden Anwendungssystemen und ihre Ablage in einer elektronischen Patientenakte

• die automatische Übernahme von digital erstellten Objekten aus bild- und signalgebenden Verfahren möglichst nach ihrer Entstehung und inhaltlichen Freigabe und ihre Ablage in einer elektronischen Patientenakte

• das Scannen und Indexieren von Papier- und Bildakten und Ablage in einer elektronischen Patientenakte

• Kombinationen der oben aufgeführten Ansätze.

Grundsatz eines digitalen Archivkonzeptes sollte es sein, dass alle Dokumente und ihre beschreibenden Daten möglichst digital erzeugt und übernommen werden. Manuell gescannt und indexiert werden sollte nur dann, wenn keine digitalen Quellen existieren. Dies bedeutet auch, dass der Ausbau der rechnerunterstützten klinischen Dokumentation vorrangig zu realisieren ist. Gegenwärtig findet man in den deutschen Krankenhäusern in der Regel Papier- und Bildakten sowie zusätzlich partielle elektronische Patientenarchive vor.

Grundsätzlich existieren zwei verschiedene Architekturansätze bei den elektronischen Archivsystemen für Patientenakten:

• autarke Dokumentenmanagement- und Archivierungssysteme

• digitale Archive, deren Objektverwaltung in rechnerunterstützte Anwendungssysteme wie klinische Arbeitsplatzsysteme integriert ist.

Bei den in Anwendungssystemen integrierten digitalen Archiven werden aus der Oberfläche des Anwendungssystems bestimmte Dokumente, Bilder, Signale oder Filme ausgewählt, aus dem digitalen Archiv geholt und mithilfe eines Viewers dargestellt. Praktische Erfahrungen am Universitätsklinikum Heidelberg haben gezeigt, dass bei autarken Lösungen für eine zufrieden stellende Datenkonsistenz ein hoher Aufwand erbracht werden muss. Sie haben jedoch den Vorteil, dass sie unabhängig von der Gesamtlösung lauffähig sind.

Die Entwicklungen von elektronischen Dokumentenmanagement- und Archivsystemen für Patientenakten (DMAS) und PAC-Systemen haben bereits vor etwa 30 Jahren unabhängig voneinander begonnen. Nur wenige Produkte sind in den letzten Jahren als integrierte Lösungen mit gemeinsamer Datenbank, Funktionalität und Oberfläche entwickelt worden. Neben der integrierten Lösung kann eine Kopplung von DMAS und PACS über Schnittstellen oder durch das Betrachten der Bilder über einen Web-Browser erfolgen. Im letzten Fall sind Verweise auf die Bilder in der zentralen Patientendatenbank hinterlegt.

Datenintegration

Das Kernproblem bei der Datenintegration besteht in der semantischen Heterogenität der zu integrierenden Teilsysteme, die auf die Entwurfsautonomie verschiedener Hersteller zurückzuführen ist [13]: Da gemeinsame konzeptionelle Grundlagen fehlen, sind die unterschiedlichen Systeme oft nur schwer miteinander in Einklang zu bringen oder gar nicht kompatibel. Um diese semantische Heterogenität zu reduzieren, hat sich im Krankenhausumfeld vor allem der nachrichtenbasierte Standard HL7 etabliert [10].

„Health Level 7” basiert auf einem umfassenden Katalog von nachrichtenauslösenden Ereignissen, so genannten „Events”, und den zugehörigen Nachrichtenformaten. Im Zuge der Standardisierung dieser Nachrichten wird vor allem die Semantik der auszutauschenden Daten festgelegt. Die Codierungsregeln sind verantwortlich für den syntaktischen Aufbau einer Nachricht, spielen aber letztlich eine untergeordnete Rolle.

HL7 ist kein „Plug-and-Play”-Standard: Kaum ein Hersteller hat den kompletten Standard implementiert, üblicherweise bieten sie nur häufig vorkommende Events und Nachrichtentypen an. Eine Anwendungsintegration auf dieser Basis erfordert auch immer die Definition einer Integrationsstrategie. Der Standard erlaubt jedoch eine gewisse Bandbreite, indem beispielsweise benutzerdefinierte Felder und Segmente und unterschiedliche Propagierungsstrategien möglich sind (z.B. Pull-Strategie: Anforderung relevanter Daten bei Bedarf; Push-Strategie: sofortiges Senden an alle potenziellen Interessenten - mit datenschutzrechtlichen Konsequenzen).

Neben der semantischen Heterogenität spielt bei der Datenintegration auch die Synchronisation redundanter Datenbestände in autonomen Teilsystemen eine wesentliche Rolle: Daten die mehrfach in verschiedenen Systemen gehalten werden, müssen auf den gleichen Änderungsstand gebracht werden. Würden die Datenobjekte synchron aktualisiert, müssten alle Replikate gemeinsam aktualisiert werden, sodass nie ein Replikat veraltet. Eine HL7-basierte Integration beruht jedoch typischerweise auf einem asynchronen Nachrichtenaustausch. Ein Datenobjekt wird demnach nur in einem Teilsystem geändert, erst dann wird die Änderungsnachricht an die Replikate weitergeleitet. Ist ein System nicht erreichbar, kann es vorkommen, dass es die Nachricht nicht oder erst verspätet erhält.

Die Mindestanforderung, dass keine Änderungen an redundanten Daten verloren gehen („Konvergenz”), kann aber hergestellt werden. Dazu müssen zusätzliche Maßnahmen gewährleisten, dass ein Datenobjekt immer nur in einem System geändert werden kann. Es muss also ein „führendes System” bestimmt sein. Eine geeignete Komponentenaufteilung, bei der die Datenredundanz und die Notwendigkeit zur Synchronisation minimiert wird, macht es möglich, auf das Risiko der Dateninkonsistenz Einfluss zu nehmen. Die Gewährleistung der Datenkonsistenz spielt dementsprechend bei der strategischen Planung der Gesamtarchitektur eine wichtige Rolle.

Funktionale Integration

Redundanzen entstehen nicht zuletzt aufgrund einer mangelnden funktionalen Integration der verschiedenen Teilsysteme. Typischerweise gibt es in autonom entwickelten Systemen eine Reihe redundant implementierter Querschnittsfunktionen (z.B. Autorisierung, Patientenidentifikation). Neben solchen elementaren Funktionen kommen aber auch komplette Anwendungsverfahren (z.B. Patientenaufnahme) mehrfach vor. Hier bedarf es einer funktionalen Abstimmung der verschiedenen Komponenten im Rahmen einer umfassenden Systemarchitektur.

Diese sollte einerseits die Anwendungsanforderungen abdecken (z.B. reguläre Patientenaufnahme durch Verwaltungspersonal, Kurzaufnahme außerhalb der normalen Dienststunden direkt in den Fachabteilungen, ambulante Aufnahme dezentral in den Polikliniken, Notaufnahme mit eingeschränkten Möglichkeiten zur Patientendatenaufnahme und -identifikation) und andererseits gleichzeitig den Anforderungen zur Erhaltung der Datenkonsistenz Rechnung tragen (insbesondere Vermeidung von Mehrfachaufnahmen und falscher Zuordnungen). Im Falle einer funktionalen Überlappung heterogener Systeme sind zentrale Komponenten zur Erhaltung der Datenkonsistenz unerlässlich: So ist die Funktion des zentralen „Master Patient Index” erforderlich, um eine systemweit eindeutige Patientenidentifikation zu gewährleisten.

Präsentationsintegration

Zur Präsentationsintegration gehört, dass der klinische Benutzer den Eindruck erhält, mit einer einzigen Anwendung zu arbeiten, auch wenn er tatsächlich mit vielen verschiedenen Applikationen interagiert. Dazu zählt das „single sign on” sowie ein Kontextmanagement, das Kontextwechsel in verschiedenen, gleichzeitig aktiven Anwendungen synchronisiert. CCOW („clinical context object working group”) bezeichnet einen aufkommenden Standard, der für die Kontextsynchronisation einschließlich „single sign on” für heterogene Applikationen sorgen soll. „Single sign on” bedeutet dabei, dass sich ein Benutzer nur noch einmal anmelden muss, auch wenn er verschiedene Komponenten verwendet.

Ein derartiger Standard muss naturgemäß Annahmen über die Rolle zentraler Systemkomponenten machen (zentraler Kontextmanager) und damit Rahmenbedingungen für eine CCOW-konforme Systemarchitektur abstecken. CCOW-konforme Applikationen müssen in der Lage sein, in eine solche Architektur eingebettet zu werden und damit einen Teil der eigenen Autonomie aufzugeben. Die meisten der heute erhältlichen autonomen Anwendungssysteme weisen noch keine entsprechende Kompatibilität auf. Sie sind daher mit entsprechendem Aufwand nachträglich an eine vorgegebene Architektur anzupassen.

Ablaufintegration

Die Ablaufintegration betrifft die Koordinierung des Informationsflusses zwischen verschiedenen Anwendungssystemen gemäß der Anforderungen, die aus den zu unterstützenden Behandlungs- bzw. Geschäftsprozessen resultieren. Eine Trennung von Ablaufspezifikation und Anwendung ist wünschenswert, um die Flexibilität und Anpassbarkeit zu erhöhen [4]. So sind beispielsweise die bei der Arztbrieferstellung zu durchlaufenden Stationen nicht immer gleich. Je nachdem, ob der Arztbrief direkt am Bildschirm erstellt, auf Band bzw. digital diktiert oder per Spracherkennung generiert wird, ändert sich der Ablauf.

Nur sehr rudimentär wird heute die Ablaufintegration - im Sinne einer flexiblen Steuerungsmöglichkeit für Geschäftsprozesse - in heterogen verteilten Umgebungen mit autonomen Abteilungssystemen unterstützt. Die Forderung nach einer Trennung von Ablauf- und Anwendungslogik lässt sich kaum realisieren: Denn die abteilungsinterne Ablauflogik ist meist im Abteilungssystem fest codiert, die abteilungsübergreifende Ablauflogik dagegen setzt zunächst einmal die Datenintegration voraus. Immer häufiger wird eine Workflow-Technologie eingesetzt, derzeit bleibt diese jedoch noch vorwiegend auf den Einsatz im Rahmen homogener integrierter Systeme beschränkt [9].

Für den Informationsfluss von und zu Modalitäten hat sich vor allem DICOM („digital imaging and communication in medicine”) als Standard für medizinische Bilddaten und zugehörige Kontextdaten etabliert [2]. Neben dem Informationsmodell, das den DICOM-Kontextdaten zugrunde liegt, werden im Rahmen des Standards auch Kommunikationsdienste spezifiziert. Dazu zählt die Übermittlung von Arbeitslisten an Modalitäten („DICOM Worklist Management”), sodass die zur Bildindizierung erforderlichen Kontextdaten nicht an der Modalität redundant eingegeben werden müssen.

Auch DICOM ist kein Plug-and-Play-Standard, weil es - genau wie HL7 - die funktionale Überlappung der zu integrierenden Teilsysteme nicht vermeidet und nicht regelt, welche Funktionalität von welchem System wahrzunehmen ist. Die Initiative „Integrating the Healthcare Enterprise” (IHE) versucht, auf der Basis von HL7 und DICOM die Integration verschiedener KIS-Komponenten zu verbessern [18]. Dabei werden vor allem Integrationsprofile und die daran beteiligten Akteure definiert. Die Spezifikation von Akteuren (Rollen) im Zusammenhang mit Integrationsprofilen legt genau fest, welche IHE-Transaktionen wann aufgerufen werden müssen. Eine Integration auf der Basis von IHE erfordert dann die Aufteilung der erforderlichen Akteure auf die realen Systeme.

Werkzeuge

Um die nachrichtenbasierte Integration auf der Basis von HL7 zu unterstützen, wird üblicherweise ein Kommunikationsserver eingesetzt: eine spezialisierte MOM („message oriented middleware”), die in erster Linie dazu dient, das Management der schnittstellenbasierten Systeme zu erleichtern. Dazu gehören

• Verwaltung und Kontrolle der Kommunikationsteilnehmer

• Einrichtung und Test von Nachrichtenverbindungen („routing”)

• Konvertierung von Nachrichten zur Angleichung verschiedenartiger Schnittstellen

• Überwachung der Kommunikation („Monitoring”).

Grafische Benutzerschnittstellen erleichtern die dazu erforderlichen Spezifikationen. Gemäß dieser nimmt der Kommunikationsserver zur Laufzeit Nachrichten entgegen, die Nachrichten werden identifiziert, die Empfänger (gegebenenfalls auch mehrere) bestimmt, und für jeden Empfänger wird die Nachricht in ein geeignetes Zielformat überführt sowie zur Abholung bereitgestellt. Um eine Entkopplung von Sender und Empfänger zu ermöglichen, werden Nachrichten vom Kommunikationsserver kurzzeitig (teilweise mehrere Tage) zwischengespeichert. So kann der Empfänger eine Nachricht auch verspätet beim Kommunikationsserver abholen, wenn er zum Zeitpunkt des Sendens gerade nicht erreichbar war. Im Idealfall kann der Kommunikationsserver dazu beitragen, die Anzahl der erforderlichen Schnittstellen zu reduzieren, da jedes Teilsystem im Prinzip nur noch mit dem Kommunikationsserver und nicht mehr direkt mit allen potenziellen Kommunikationspartnern interagieren muss [Abb. 1].

[Abbildung 2] zeigt ein Beispiel für die Nutzung eines Kommunikationsservers zur Rückübermittlung von Labordaten aus einem autonomen Laborinformationssystem mit mehreren Mandanten (Transfusionsmedizin und Zentrallabor) in ein zentrales Krankenhausinformationssystem.

Eine weitere spezialisierte Form einer MOM sind so genannte PACS-Broker, welche zur DICOM-konformen Koordinierung des Informationsflusses eingesetzt werden. Der PACS-Broker nimmt dabei Kontextdaten aus KIS und RIS entgegen (z.B. Patientenidentifikation, Untersuchungsnummer, Untersuchungsgerät), generiert eine so genannte „DICOM Worklist”, die an die Modalität übergeben wird, und liefert die zurückkommenden Bilddaten zusammen mit den Kontextdaten an ein DICOM-PACS.

Zur Bildverteilung werden häufig Web-Server eingesetzt, die eine rasche Etablierung eines ortsunabhängigen Datenzugriffs in einem Intranet ermöglichen. Repositories (physisch zentral oder virtuell) dienen dazu, in heterogenen Umgebungen die Funktion des Master Patient Index, eines Befund-Containers oder eines Terminologie-Servers wahrzunehmen.

Architekturkonzepte

Die in der Praxis etablierten Standards HL7 und DICOM orientieren sich an einer „Bottom-up”-Integrationsstrategie. Daneben existiert jedoch eine Reihe weiterer Standardisierungsbestrebungen, die im Sinne einer Rahmenarchitektur für Informationssysteme im Gesundheitswesen eher eine „Top-Down”-Vorgehensweise propagieren, um so der semantischen Heterogenität und der funktionalen Überlappung entgegenzuwirken. Beispiele sind HISA („healthcare information systems architecture”) und die darauf aufbauenden bzw. nachfolgenden Standards [8]. Diese versuchen, auf einem vordefinierten zentralen Datenbankschema allgemeine krankenhausspezifische Dienste zu spezifizieren.

Die Idee, die funktionale Überlappung durch standardisierte Dienste zu reduzieren, liegt auch der CORBAmed-Initiative der OMG („object management group”) zugrunde (z.B. „patient identification service”, „lexical query service”) [11]. Bislang konnten diese Ansätze in der Praxis die Produktkompatibilität noch nicht verbessern. Vereinzelt werden die definierten Konzepte aber bereits genutzt, um daran die Spezifikation einer Komponentenarchitektur für ein verteiltes Krankenhausinformationssystem zu orientieren [5].

Evolutionsstrategien

Vor dem Hintergrund der beschriebenen Standards und Werkzeuge und unter Berücksichtigung der am Markt verfügbaren Produkte ist für jedes Krankenhaus eine Unternehmensarchitektur zu definieren und in diesem Zusammenhang auch ein Konzept zur Weiterentwicklung des Systems (Systemevolution) zu erstellen. Die grobe Strategie wird üblicherweise in einem Datenverarbeitungs-Rahmenkonzept festgeschrieben.

Aus technischer Sicht soll im Zuge einer Evolutionsstrategie eine Gesamtarchitektur definiert werden. Diese legt einerseits eine Infrastruktur fest, die eine flexible technische und funktionale Weiterentwicklung ermöglicht, und unterstützt andererseits eine prozessorientierte Integration in das Gesamtsystem. Im Prinzip kann man zwei grobe Richtungen unterscheiden: „Best-of-Breed”(BoB)- [3] [5] und holistische Ansätze [12]. Letztere basieren üblicherweise auf dem Konzept eines einzigen Herstellers („enterprise resource planning” (ERP)-Suite). Sie werden durch die integrierte Datenhaltung (meist eine zentrale und hoch komplexe Datenbank), die dadurch mögliche Reduktion der Datenredundanz und die Möglichkeit des direkten Datenzugriffs aus verschiedenen Anwendungsverfahren motiviert. BoB-Ansätze sind dagegen vorwiegend durch die Schwächen der schwerfälligen ERP-Produkte motiviert:

• Keine ERP-Suite bietet für alle Anwendungsverfahren ein integriertes Anwendungsmodul, das die jeweils beste Lösung für diesen Anwendungsbereich ist.

• Die Einführung von ERP-Systemen ist häufig mit einer so genannten „Big-Bang”-Umstellung und gleichzeitigen umfangreichen organisatorischen Änderungen verbunden, die im Zuge der Anpassung an die der Software zugrunde liegenden Annahmen bezüglich der Geschäftsprozesse notwendig werden. Dies ist mit einem hohen Projektrisiko verbunden, was in der Vergangenheit nicht selten zu Projektfehlschlägen geführt hat [1] [15].

• Die Weiterentwicklung des Systems hängt in hohem Maße von einem Hersteller ab, was eine bedarfsorientierte Systemevolution im konkreten Unternehmen erschwert. Änderungen und Anpassungen an der Software sind häufig mit großem Aufwand und langen Entwickungszyklen verbunden.

• Die Bindung an einen einzigen Hersteller ist mit einem erhöhten Risiko verknüpft, weil man sich auch von der wirtschaftlichen Entwicklung und langfristigen Existenz dieses Unternehmens abhängig macht [3].

Der BoB-Ansatz versucht, das Risiko zu streuen und die Flexibilität zu erhöhen. Hier werden - nach Bedarf - Anwendungskomponenten von verschiedenen Herstellern über Schnittstellen in eine Gesamtarchitektur integriert. Unzureichende Integration und mangelnde Kompatibilität dieser heterogenen Komponenten sind ein bedeutender Risikofaktor für Projektfehlschläge [1] [15]. Die für ERP-Systeme genannten Nachteile gelten darüber hinaus zumindest teilweise auch für einzelne BoB-Komponenten, da diese für sich genommen auch nur beschränkte Möglichkeiten zur bedarfsorientierten Prozessanpassung bieten. Zusätzlich wird die komponentenübergreifende Prozessanpassung durch den hohen Integrationsaufwand begrenzt.

Unabhängig vom verwendeten Integrationswerkzeug erfordert die semantische Abstimmung heterogener Systeme einen hohen manuellen Aufwand und ein tiefes Verständnis für die Datensemantik in allen zu integrierenden Systemen. Die Erstellung und Wartung von Schnittstellen ist dementsprechend (auch bei Verwendung von HL7 und DICOM) mit einem erheblichen Personalaufwand verbunden.

Das „Intermountain Health Care” - eine Krankenhauskette um Salt Lake City (22 Häuser mit 2500 Betten sowie mit 100000 stationären Patienten und drei Millionen ambulanten Behandlungen im Jahr) - beschäftigt 19 Mitarbeiter ausschließlich für die Wartung von 31 verschiedenen Schnittstellentypen [3]. Am Universitätsklinikum in Marburg (1200 Betten, 45000 stationäre Patienten und 250000 ambulante Behandlungen pro Jahr) wird dagegen ein homogener Ansatz praktiziert. Dort ist derzeit eine halbe Stelle für die Wartung von zwei bis fünf Schnittstellen vorgesehen. Dieser Ansatz soll die mangelnde Flexibilität herkömmlicher ERP-Lösungen durch den Einsatz eines integrierten Generator-Werkzeugs ausgleichen [12].

Ausblick

Aufgrund der Initiativen des Bundesministeriums für Gesundheit und Soziale Sicherung (BMGS) und weiterer Institutionen (z.B. Aktionsforum Telematik im Gesundheitswesen (ATG), Industrieverbände) zur Gesundheitskarte und -akte sind in den nächsten Jahren vermehrte Aktivitäten bei der Vernetzung von medizinischen Versorgungsregionen zu erwarten [17]. Die bisherigen umfangreichen Anforderungen der Integration nehmen bei einer Einführung von Gesundheitskarten und -akten nochmals zu. Es gilt beispielsweise, Komponenten von Krankenhausinformationssystemen, Arztpraxis- und Apothekensystemen über öffentliche Netze miteinander zu verbinden.

Für die Kommunikation von Arztpraxen untereinander sowie zwischen Arztpraxen, Laboratorien, Krankenkassen, Kassenärztlichen Vereinigungen und Krankenhäusern gibt es in Deutschland heute die Familie der xDT-Kommunikationsstandards (ADT = Abrechnungsdatenträger, BDT = Behandlungsdatenträger, GDT = Gerätedatenträger, LDT = Labordatenträger). Initiativen wie die VCS (VDAP Communication Standard des Verbandes Deutscher Arztpraxis-Softwarehersteller e.V.) oder die D2D (Doctor-To-Doctor, Kassenärztliche Vereinigung Nordrhein) haben erste Schnittstellenlösungen geschaffen, die einer Weiterentwicklung bedürfen. Ein weiterer wichtiger Ansatz, Informationen sowohl hochstrukturiert als auch dokumentenorientiert aufzubereiten, ist die so genannte „Clinical Document Architecture” (CDA) im Rahmen der Entwicklung der HL7 Version 3.

Abb. 1

Abb. 2

Literatur

• 1 Al-Mashari M, Zairi M. BPR implementation process: an analysis of key success and failure factors.  Business Process Management Journal. 1999;  5 87-112
• 2 Bidgood WD, Horii SC, Prior FW, Van Syckle DE. Understanding and using DICOM, the data interchange standard for biomedical imaging.  Journal of the American Medical Informatics Association. 1997;  4 199-212
• 3 Clayton PD, Narus SP, Huff SM. et al. . Building a comprehensive clinical information system from components. The approach at Intermountain Health Care.  Methods Inf Med. 2003;  42 1-7
• 4 Dadam P, Reichert M, Kuhn K. Clinical workflows - the killer application for process-oriented information systems?.  Proc 4th Int Conf on Business Informations Systems. 2000; 
• 5 Degoulet P, Marin L, Lavril M. et al. . The HEGP component-based clinical information system.  Int J Med Inf. 2003;  69 115-126
• 6 Detmer D, Steen EB. Countdown to 2001: The computer-based patient record after the institute of medicine report.  Yearbook of medical Informatics. 1995;  55-60
• 7 Dick RS, Steen EB. The computer-based patient record: an essential technology for health care (2nd ed) Washington DC.  National Academy Press. 1997; 
• 8 Ferrara FM. The CEN healthcare information systems architecture standard and the DHE middleware. A practical support to the integration and evolution of healthcare systems.  Int J Med Inf. 1998;  48 173-182
• 9 Haux R, Seggewies C, Baldauf-Sobez W. et al. . Soarian - workflow management applied for health care.  Methods Inf Med. 2003;  42 25-36
• 10 Heitmann KU, Blobel B, Dudeck J. HL7 - Kommunikationsstandard in der Medizin.  Köln: Verlag Alexander Mönch. 1999; 
• 11 Jagannathan V, Wreder K, Glicksman B, al Safadi Y. Objects in healthcare-focus on standards.  ACM Standards View. 1998;  22-26
• 12 Kuhn KA, Lenz R, Elstner T. et al. . Experiences with a generator tool for building clinical application modules.  Methods Inf Med. 2000;  42 37-44
• 13 Lenz R, Kuhn KA. Intranet meets hospital information systems: the solution to the integration problem?.  Methods Inf Med. 2001;  40 99-105
• 14 Prokosch HU. KAS, KIS, EKA, EPA, EGA, E-Health: Ein Plädoyer gegen die babylonische Begriffsverwirrung in der Medizinischen Informatik.  Informatik, Biometrie und Epidemiologie in Medizin und Biologie. 2001;  371-382
• 15 Sauer C. Deciding the future for IS failures: not the choice you might think.  In: Curie W, Galliers R (eds). Rethinking management information systems.  Oxford: Oxford University Press. 1999;  279-309
• 16 Schmücker P, Ohr C, Beß A. et al. . Die elektronische Patientenakte - Ziele, Strukturen, Präsentation und Integration.  Informatik, Biometrie und Epidemiologie in Medizin und Biologie. 1998;  221-241
• 17 Warda F, Noelle G. Telemedizin und eHealth in Deutschland: Materialien und Empfehlungen für eine nationale Telematikplattform.  Köln: Deutsches Institut für medizinische Dokumentation und Information. 2002; 
• 18 Wein BB. IHE (Integrating the Healthcare Enterprise): a new approach for the improvement of digital communication in healthcare.  Rofo Fortschr Geb Rontgenstr Neuen Bildgeb Verfahr. 2003;  183-186
• 19 Winter A, Ammenwerth E, Brigl B, Haux R. Krankenhausinformationssysteme.  In: Lehmann TM, Meyer zu Bexten E (eds).  Handbuch der Medizinischen Informatik. Stuttgart: Schattauer. 2002;  473-525

Anschrift für die Verfasser