Das Technische Rahmenwerk IT-Infrastruktur der IHE-Initiative ein Werkzeug aus der Praxis für die Praxis

Transkript

1 Das Technische Rahmenwerk IT-Infrastruktur der IHE-Initiative ein Werkzeug aus der Praxis für die Praxis I Dr. Bernd Schütze HI Consulting, Düsseldorf Tel.: +49 (173) schuetze@ medizin-informatik.org ntegrating the Healthcare Enterprise (IHE) ist eine Initiative, die 1997 mit dem Ziel der Standardisierung und Harmonisierung der medizinischen Bild- und Datenverarbeitung von der nordamerikanischen Röntgengesellschaft (Radiological Society of North America, RSNA) und der»healthcare Information and Management Systems Society«(HIMSS, dem amerikanischen Pendant zum deutschen VHitG) gegründet wurde [1, 2, 3]. Insbesondere soll erreicht werden, dass Computersysteme unterschiedlicher Anbieter einen gemeinsamen Mindeststandard für die Zusammenarbeit zur Verfügung stellen. Bereits 1999/2000 begann auch eine Internationalisierung von IHE mit Etablierung von Gruppen auf nationaler und regionaler Ebene in Europa und Asien. Das Konzept von IHE Dr. Marco Eichelberg OFFIS e.v., Oldenburg Tel.: +49 (441) eichelberg@ offis.de Prof. Berthold Wein Praxisgemeinschaft im Kapuzinerkarree, Aachen Tel.: +49 (241) wein@ radiologie-aachen.de 116 Die IHE-Initiative entwickelt weder Standards noch ist IHE eine Zertifizierungsinstanz. Vielmehr beruht IHE auf der Zusammenarbeit von Anwendern und Herstellern: Anwender beschreiben, welche Informationen sie für ihre Arbeitsabläufe benötigen und welche Daten erfasst, verarbeitet und gespeichert werden müssen. Die Fachleute der an IHE beteiligten Hersteller definieren auf der Basis dieser Anforderungen Spezifikationen, die beschreiben, welche Standards zur Umsetzung der Anwender-Anforderungen in welcher Form eingesetzt werden [4, 5]. Sowohl die Anforderungen als auch die Spezifikationen und die einzusetzenden Standards sowie Anwendungsfälle werden in sogenannten»technical Frameworks«(dt. Technische Rahmenwerke) schriftlich festgehalten [3]. Diese Rahmenwerke werden in verschiedenen Arbeitsgruppen erstellt und dann zur öffentlichen Kommentierung und Diskussion ins Netz gestellt. Anschließend werden Beispielimplementierungen getestet (»Trial Implementation«). Die daraus gewonnenen Erfahrungen gehen wiederum ins Framework ein, bis dieses den Status»final«(endgültig) erhält. Ursprünglich aus der Radiologie stammend, wurde bald erkannt, dass der IHE-Ansatz auch für andere medizinische Fächer sowie fächerübergreifend für Anforderungen an die IT-Infrastruktur erfolgreich einsetzbar ist. Die Fachbereiche werden in der IHE-Terminologie als»domänen«bezeichnet. Stand 2007 arbeiten folgende Fachgebiete an der IHE-Initiative mit: Augenheilkunde IT-Infrastruktur Kardiologie Labor Pathologie Radiologie und Strahlentherapie Jede Domäne hat ihr eigenes Technical Framework, wobei ein Technical Framework mehrere sogenannte»integrationsprofile«beinhalten kann. Ein Integrationsprofil beschreibt einen Arbeitsablauf aus der realen Welt, z.b. die Aufnahme, Speicherung, Beurteilung und Verteilung einer Laboruntersuchung. Dabei werden die Kommunikationsabläufe sowohl innerhalb eines wie auch zwischen verschiedenen Informationssystemen definiert. Zu einem Integrationsprofil gehören bestimmte Rollen oder Funktionen der beteiligten IT-Systeme (Akteure). Ein IT-System kann dabei die Funktionen von einem oder mehreren Akteuren umfassen und natürlich auch Anwendungsfälle aus mehreren Integrationsprofilen unterstützen. So kann ein Informationssystem etwa gleichzeitig für die Patientenaufnahme und für die elektronische Auftragskommunikation zuständig sein. Zwischen den Akteuren werden sog. Transaktionen definiert. Eine Transaktion kann zum Beispiel die Anforderung bestimmter Daten oder die Bekanntgabe eines Status sein. Es wird genau beschrieben, aus welchen Schritten und über welche Schnittstellen die Information transportiert wird. Dieselbe Transaktion kann in verschiedenen Integrationsprofilen und Anwendungsdomänen genutzt werden. IHE ermuntert die Hersteller von medizinischen IT-Systemen, die in den Technical Frameworks beschriebenen Funktionen (Akteure) und Schnittstellen (Transaktionen) in ihren Produkten umzusetzen. Einmal im Jahr bietet IHE in den USA, in Europa und in Japan jeweils eine einwöchige Testveranstaltung namens»connectathon«(manchmal auch Connect-a-thon geschrieben) an, bei der Hersteller die Funktionsfähigkeit ihrer Schnittstellen und die Möglichkeiten zur herstellerübergreifenden Vernetzung und Integration ihrer Produkte unter neutraler Aufsicht von IHE umfassend prüfen (siehe Abbildung 1).

2 Im Rahmen einer solchen Connectathon-Testwoche werden typischerweise mehrere tausend Tests zwischen Systemen von mehr als 70 Herstellern durchgeführt und von den Schiedsrichtern der IHE geprüft. Ziel der Testszenarien ist es, alltägliche Arbeitsabläufe bei der Patientenversorgung zu simulieren und alle daran beteiligten IT-Systeme wie etwa die Patientenaufnahme, das Stationssystem, bildgebende Systeme, Archiv und Befundungsarbeitsplätze der Fachabteilungen usw. zu integrieren. IHE veröffentlicht im Anschluss an jedes Connectathon, welcher Hersteller die Unterstützung welcher IHE-Integrationsprofile und Akteure nachgewiesen hat [6]. Tabelle1 zeigt beispielhaft die von einem Hersteller unterstützten Profile. Zusätzlich erfolgen auf verschiedenen Kongressen sogenannte Demonstrationen, bei denen Hersteller unter Beteiligung von Anwendern die erfolgreiche Umsetzung der IHE-Anforderungen in Form einer virtuellen Patientenbehandlung zeigen (siehe Abbildung 2). Enterprise User Authentication (EUA) Die Authentifizierung eines Benutzers ist ein notwendiger Prozess, bevor der Zugriff auf Anwendungen und die entsprechenden Daten ermöglicht werden kann. Im Integrationsprofil EUA wird beschrieben, wie ein Benutzer sich mit einer einzigen Zugangskennung an verschiedenen Informationssystemen anmelden kann (»Single-Sign-On«). Dies erlaubt eine zentrale Verwaltung der Benutzerdaten. EUA verwendet dazu das Kerberos-Verfahren (RFC 1510). Patient Identifier Cross-referencing (PI) Das Integrationsprofil PI zeigt auf, wie die Integration von IT-Systemen verschiedener Institutionen (z.b. verschiedene Krankenhäuser, Arztpraxen, Reha-Einrichtungen), die unterschiedliche Nummernkreise für die Identifikation des Patienten verwenden, mittels eines sogenannten»master «realisiert werden kann. PI beschreibt detailliert, wie Anwendungen per Das Technische Rahmenwerk HL7 Patienten-IDs aus anderen Nummernkreisen beim der Domäne IT-Infrastruktur MPI erfragen können. Ein solches System ist notwendig, Mit dem Rahmenwerk für die Domäne IT-Infrastruk- wenn Informationen aus verschiedenen Quellen zusamtur zeigt IHE Lösungen für Anforderungen auf, die über mengeführt werden sollen, um dem Arzt eine umfassenden Kontext einzelner Abteilungen und Funktionsbe- dere Sicht zu ermöglichen. reiche hinausgehen (daher der Begriff»Infrastruktur«). Die hier definierten Integrationsprofile verstehen sich Patient Synchronized Applications (PSA) als Bausteine, die je nach Anforderung einer konkreten Anwendung oder eines Hauses miteinander kombiniert PSA ermöglicht es, mehrere Anwendungen (etwa und zu diesem Zweck im Rahmen von Ausschreibungen RIS und PACS in der Radiologie) so zu synchronisieren, verwendet werden können. Das Technische Rahmen- dass die Auswahl eines Patienten in einem System vom werk IT-Infrastruktur steht im Internet zum freien Down- anderen System automatisch ebenfalls ausgeführt wird load zur Verfügung [7]. Gegenüber der ersten Fassung (man spricht hier von einem Kontextwechsel) wählt des Rahmenwerks, deren Integrationsprofile bereits in man im RIS einen Patienten aus, so zeigt die PACS[8] beschrieben wurden, hat sich das Rahmenwerk inzwi- Workstation automatisch die für diesen Patienten verschen erheblich weiterentwickelt. Im Folgenden soll daher fügbaren Studien an. Dieses Integrationsprofil basiert ein kurzer Überblick über die Inhalte der verschiedenen auf dem HL7-CCOW-Standard (»Clinical Context Object Workbench«). Integrationsprofile gegeben werden. Retrieve Information for Display (RID) Das RID-Profil ermöglicht einen einfachen, nur-lesenden Zugriff auf Patienteninformationen, die außerhalb der aktuellen Zugriffsmöglichkeit des Anwenders liegt (z.b. Zugriff auf Labordaten aus der Radiologie). Hierzu werden Formate wie HL7 CDA (Clinical Document Architecture, Level 1), PDF, JPEG usw. benutzt. RID setzt dabei auf»web-technik«(bei jedem Abruf aktuell generierte Webseiten mit Listen verfügbarer Dokumente, HTTP als Transportprotokoll) und kann relativ einfach in bestehende Anwendungen integriert werden. Consistent Time (CT) CT definiert Mechanismen zur Synchronisation der Systemuhr bei allen beteiligten IT-Systemen. Hierzu nutzt das IHE-Profil das Network Time Protocol (NTP), welches im RFC 1305 beschrieben wird. Eine Synchronisation der Systemzeit klingt nach einer Trivialität, ist aber ein wichtiger Baustein für andere Dienste, wie etwa die zentrale Benutzerauthentifizierung (EUA) oder den Aufbau eines»audit Trail«, in dem datenschutzrelevante Aktivitäten verschiedener Systeme im Netz protokolliert werden. Dr. Thomas Kauer Friedrich-AlexanderUniversität ErlangenNürnberg Lehrstuhl für Medizinische Informatik Tel.: +49 (9131) uk-erlangen.de Prof. Dr. med. Peter Mildenberger Klinikum der Johannes Gutenberg-Universität Mainz Klinik und Poliklinik für Radiologie Tel.: +49 (6131) radiologie.klinik. uni-mainz.de 117

3 Cross-Enterprise Document Sharing (DS) Abb. 1: Überprüfung der unterstützten Mammography Image Scheduled Workflow Patient Information Reconciliation Consistent Presentation of Images Access to Radiology Information Key Image Note Evidence Documents Reporting Workflow Consistent Time Cardiac Catheterization Workflow Retrieve ECG for Display Echocardiography Workflow NM Image Portable Data for Imaging Patient Demographics Query Image Manager Image Display Display Time Client Importer Patient Demographics Consumer Portable Media Creator Portable Media Importer Import Reconciliation Workflow Result Matrix For Company:»Fa. YZ GmbH«Audit Trail and Node Authentification (ATNA) Das DS-Integrationsprofil ermöglicht einen sicheren, institutsübergreifenden Austausch von klinischen Dokumenten wie Bildern und Befunden. DS definiert dabei die Metadaten, mit denen Dokumente indexiert und gesucht werden können, sowie die Transaktionen für das Einstellen, Suchen und Abrufen von Dokumenten. Die konkreten Dokumententypen, Kategorien usw. müssen dabei zwischen den kooperierenden Institutionen vorab vereinbart werden DS bietet hier viel Flexibilität, wobei IHE durchaus Vorschläge für geeignete Dokumentenformate etwa für Befundberichte, strukturierte Arztbriefe, Bilder oder auch gescannte Papierdokumente macht. Diese werden in anderen, domänenspezifischen Integrationsprofilen veröffentlicht, die mit DS kombiniert werden können. DS ermöglicht sowohl den Aufbau zentraler Dokumentenarchive als auch eine verteilte Struktur, bei der die Dokumente beim jeweiligen Urheber verbleiben und nur ein zentrales Dokumentenverzeichnis existiert. DS ist die technische Basis für mehrere nationale Projekte zum Aufbau einer elektronischen Gesundheitsakte, darunter Health Infoway in Kanada und das ELGA-Projekt in Österreich. Technisch basiert DS auf dem ebml-standard (»Electronic Business ML«) und Webservices. Personnel White Pages (PWP) Das PWP-Profil realisiert ein»elektronisches Telefonbuch«, mit dem sich Daten zu Mitarbeitern innerhalb einer oder mehrerer verbundener Organisationen auffinden lassen. Damit lässt sich einerseits der klinische Arbeitsablauf optimieren (Suche nach Kontaktinformationen wie Name, Anschrift, Telefonnummer, -Adresse), andererseits können Anwendungen auf das Verzeichnis zugreifen, um etwa den Namen und Titel des Anwenders (und nicht nur das»login«) korrekt darzustellen. ATNA definiert grundlegende Dienste für Datenschutz und Datensicherheit: die zuverlässige Authentifizierung der IT-Systeme Tabelle 1: in einem Netzwerk mit kryptographischen Mitteln Patient Administration Connectathon(.509-Zertifikaten und Schlüsselpaaren), Management (PAM) Ergebnismatrix für eine verschlüsselte Kommunikation wo notwendig einen Hersteller sowie Die Pflege der Stammdaten eines Patienten sowie die ein Protokoll zur Führung eines zentralen»logbuchs«verwaltung von Informationen über die Aufnahme, Ver(Audit Trails), in dem alle sicherheits- und daten- legung und Entlassung eines Patienten (ADT»Admisschutzrelevanten Aktivitäten vermerkt werden. sion, Discharge, Transfer«) sind zentrale Bausteine in allen»workflow«-integrationsprofilen, die IHE in verschiedenen Technisch setzt ATNA auf dem TLS-Protokoll (RFC 2246), Domänen wie Radiologie, Kardiologie, Labormedizin usw. dem»reliable Syslog«(RFC 3195) und den von IHE maß- entwickelt und über viele Jahre erprobt und verfeinert hat. geblich entwickelten»security Audit and Access Accoun- Die Erfassung dieser Daten erfolgt typischerweise im KIS, tability Message ML Data Definitions for Healthcare und alle nachgelagerten Abteilungssysteme werden per Applications«(RFC 3881) auf. HL7 auf dem aktuellen Stand gehalten. IHE-Profile auf einem Connectathon 118

4 Das PAM-Integrationsprofil stellt eine komplette Neufassung dieser Funktionen dar, die gegenüber den ADT-Funktionen in den derzeitigen IHE-Workflow-Profilen einen erheblich erweiterten Funktionsumfang bietet und mittelfristig in diese integriert werden soll. PAM unterstützt dabei sowohl ein zentrales wie auch ein dezentrales Patientenaufnahmemanagement. Technisch wird damit der»generationswechsel«von HL zu HL7 2.5 vollzogen. Der praktische Nutzen von IHE IHE-Integrationsprofile erleichtern die Ausschreibung von neuen IT-Systemen ungemein [9], da typische Anforderungen aus Anwendersicht bereits definiert und mit detaillierten technischen Implementierungsanforderungen unterfüttert sind, z.b.: Korrektur von Patientenstammdaten in einem Informationssystem mit automatischem Abgleich in den verbundenen Informationssystemen oder Gleichartige Bilddarstellung bei verschiedenen Befundungsarbeitsplätzen und selbst zwischen Monitor und Hardcopy. IHE unterstützt somit das medizinische Personal bei der Definition seiner Anforderungen. Je nach Anforderung kann in den Ausschreibungen auf die Unterstützung bestimmter Akteure aus den einzelnen IHE-Integrationsprofilen verwiesen und somit sichergestellt werden, dass die Informationssysteme die notwendige Funktionalität und die zur Integration benötigten Schnittstellen gewährleisten. Dadurch wird natürlich auch die EDV-Abteilung bei der Ausschreibung entlastet. Ein Beispiel soll dies verdeutlichen: Ein Krankenhaus möchte sich im Rahmen der integrierten Versorgung mit einer radiologischen Arztpraxis, welche auch die radiologische Betreuung des Krankenhauses übernimmt, einer Reha-Klinik, mit welcher die klinikeigene Orthopädie Patienten gemeinsam behandelt, sowie einer ophthalmologischen Arztpraxis, welche auch die augenärztliche Betreuung im Krankenhaus durchführt, vernetzen. Dabei speichern die Augenärzte ihre Behandlungsdaten in ihrem Praxisverwaltungssystem (PVS), die radiologische Praxis die bei ihnen anfallenden Daten im radiologischen Informationssystem (RIS) bzw. die Bilddaten im Bildarchiv (PACS), die Reha-Klinik in ihrem Klinik-Informationssystem zur Rehabilitation und das Krankenhaus in ihrem Klinik-Informationssystem (KIS). Dazu sollen die für die Patientenbehandlung relevanten Bild- und Befunddaten aller verbundenen Partner sicher ausgetauscht werden. Eine Einverständniserklärung des Patienten wird eingeholt, bevor Dokumente für den Austausch freigegeben werden. Aus Datenschutzgründen möchte man jedoch keine zentrale Datenbank mit allen Daten aufbauen, und aus Kostengründen möchte man die Daten auch nicht redundant mehrfach (d.h. in jedem Haus) speichern. Das IHE-DS-Integrationsprofil bietet in der Kombination mit den Integrationsprofilen PI und DS-I (DS for Imaging, eine Erweiterung von DS speziell für den medizinischen Bilddatenaustausch) eine Lösung für dieses Problem (siehe Abbildung 3): Die Bildarchive (PACS) werden so nachgerüstet, dass sie IHE-Schnittstellen für den regionalen Bilddatenaustausch erhalten. Die Bildarchive können nun Bilddaten für den Datenaustausch bereitstellen, die Bilder bleiben aber vor Ort. Diese Funktionalität wird durch folgende IHE-Akteure (Angaben zu Abb. 2: Demonstration der IHE-Ergebnisse auf einem Kongress Abb. 3: Einsatz von DS zur Synchronisation der Patienten-IDs verschiedener Informationssysteme 119

5 Der sichere (verschlüsselte) Austausch der Daten wird von IHE DS grundsätzlich gewährleistet, ebenso ist gewährleistet, dass nur speziell dafür freigegebene IT-Systeme Zugang zum gemeinsamen Netzwerk bekommen. Basierend auf den Connectathon-Ergebnissen können geeignete Hersteller bei einer Ausschreibung gezielt angeschrieben werden. Im Kaufvertrag mit dem Hersteller können dann entsprechende Forderungen vertraglich bindend und ggf. sogar mit Vertragsstrafen für Nichterfüllung versehen festgehalten werden. Fazit Abb. 4: Weltweite Verbreitung von IHE 120 Integrationsprofilen in Klammern) gewährleistet: Imaging Document Source/Document Repository (DS-I) PI Consumer (PI) für den Zugriff auf den Master Die Befunddaten sollen in einer elektronischen Patientenakte verbleiben, die vom KIS angeboten wird. Die KIS-Systeme werden daher ebenfalls so nachgerüstet, dass sie Befunde für den Datenaustausch bereitstellen können. Dies entspricht folgenden IHE-Akteuren und Integrationsprofilen: Document Source/Document Repository (DS) PI Consumer (PI) für den Zugriff auf den Master Als»Zentralsysteme«, die alle Häuser gemeinsam nutzen, werden ein Dokumentenverzeichnisdienst und ein Master eingerichtet. Diese führen eine Liste aller derzeit für den Austausch freigegebenen Dokumente und Bilder und sorgen für den Abgleich der Patientenkennziffern. Damit realisieren die Zentralsysteme folgende IHE-Akteure und Integrationsprofile: Document Registry (DS) als zentrales Dokumentenverzeichnis PI Server (PI) als Schnittstelle des Master Schließlich werden in jedem Haus einige Arbeitsplätze mit der Fähigkeit nachgerüstet, Bilder und Befunde im Dokumentenverzeichnis zu suchen und direkt aus dem digitalen Archiv des zugehörigen Krankenhauses anzufordern. Diese Funktionalität wird durch folgende IHE-Akteure und Integrationsprofile gewährleistet: Document Consumer (DS) für den Zugriff auf Dokumente Imaging Document Consumer (DS-I) für den Zugriff auf radiologische Bilder PI Consumer (PI) für den Zugriff auf den Master IHE ist das Ergebnis einer erfolgreichen Zusammenarbeit von Anwendern und Herstellern. Die Anwender (in der Regel ärztliches Personal) definieren die Anforderungen, d.h. die Funktionen, die sie sich von der IT in ihrer täglichen Arbeit erhoffen. Die Hersteller kümmern sich um die technische Umsetzung dieser Anforderungen. Aus dieser Zusammenarbeit entstehen die zu einer Domäne gehörenden Integrationsprofile. Jedes dieser Profile beschreibt medizinische und auch verwaltungstechnische Arbeitsabläufe (Anwendungsfälle), die daraus resultierenden Anforderungen für die IT-Systemintegration sowie eine umsetzbare Lösung für die gestellten Anforderungen auf der Basis von Standards. Das Profil beschreibt Funktionen (Akteure) und Schnittstellen (Transaktionen) der an einem Arbeitsablauf beteiligten IT-Systeme. Auf den jährlichen Connectathons wird geprüft, ob die Systeme der Hersteller die gestellten Anforderungen tatsächlich erfüllen. Die Ergebnisse dieser Integrationstests sind im Internet öffentlich verfügbar. Integrationsprofile erleichtern die Anschaffung neuer Informationssysteme deutlich. Zum einen wird eine Vielzahl von Anwendungsfällen bereitgestellt, die den Arbeitsablauf im Gesundheitswesen widerspiegeln, so dass auf diese in einer Ausschreibung verwiesen werden kann. Zum anderen können die Anforderungen an Informationssystemen in Ausschreibungen kurz und prägnant formuliert werden, z.b.: gefordert wird für das zu beschaffende System die Unterstützung des Integrationsprofils»Scheduled Workflow«(Radiologie) mit dem Akteur»Image Display«sowie die Unterstützung des Integrationsprofils»Enterprise User Authentication«(IT-Infrastruktur) mit dem Akteur»Client Authentication Agent«. Hinter dieser knappen Formulierung steht ein präzise definierter Satz an Funktionen und Schnittstellen, die auf herstellerunabhängigen Standards basieren und in einem Konsensusprozess erarbeitet wurden. Anwender haben dadurch einerseits mehr Planungs- und Zukunftssicherheit, andererseits ist es sehr wahrscheinlich, dass es auch Produkte

6 mit dem gewünschten Funktionsumfang gibt und dieser nicht im Rahmen einer aufwendigen und teuren Individualentwicklung realisiert werden muss. Ein wichtiger Baustein sind hier die sogenannten»ihe Integration Statements«, in denen Hersteller dokumentieren, welche IHE-konformen Funktionen und Schnittstellen (Integrationsprofile/Akteure) ihre Produkte bieten. Die von IHE veröffentlichten Informationen über die Connect athon-ergebnisse ermöglichen es darüber hinaus, nachzuprüfen, ob der Hersteller im Rahmen einer (vielleicht sogar regelmäßigen) Connectathon-Teilnahme die gewünschten Integrationsprofile und Akteure erprobt hat, was ein guter Hinweis darauf ist, dass der Hersteller das Thema der herstellerübergreifenden IT-Integration wirklich ernst nimmt. Hierbei kann man sich auf die Ergebnisse der Connectathons zwar nur bedingt verlassen, da die Hersteller hier oft auch Prototypen testen. D.h., die Ergebnisse müssen nicht unbedingt auch für das Produkt gelten, welches gerade auf dem Markt angeboten wird. Andererseits wird natürlich der erfolgreichen Umsetzung eines IHE-Profils in einem Prototypen recht schnell die Umsetzung in das marktreife Produkt folgen, so dass bei einer Kaufentscheidung die erfolgreiche Teilnahme an einem IHE-Connectathon eine bedeutsame Information ist. Mit IHE ist auch eine spätere Erweiterung der IT-Infrastruktur relativ einfach handhabbar. Da bekannt ist, welche IHE-Profile von der vorhandenen IT-Infrastruktur unterstützt werden, kann bei der Anschaffung ergänzender Informationssystem-Technologie auf die zu unterstützenden Profile hingewiesen werden und die neuen Systeme passen abgestimmt in die vorhandene IT-Infrastruktur ein. Denn die Integration von IHE-konformen IT-Komponenten ist letztlich sowohl für den Anwender als auch für den Hersteller selbst weniger zeit- und kostenintensiv als die Integration von nicht erprobten Komponenten. IHE-Deutschland Obwohl die Initiative aus Amerika stammt, ist IHE international weit verbreitet. So gibt es nationale IHEInitiativen in Australien, China, Dänemark, Frankreich, Großbritannien, Niederlande, Israel, Japan, Italien, Korea, Norwegen, Spanien, Taiwan und natürlich in Deutschland (siehe Abbildung 4). In Deutschland wird IHE durch den Verein»IHE Deutschland e.v.«vertreten. Jede natürliche und juristische Person kann Mitglied werden. IHE Deutschland kümmert sich darum, dass nationale Besonderheiten bei dem Integrationsprozess nach dem IHE-Modell von Anfang an berücksichtigt werden. Dies betrifft z.b. die Organisation von Arbeitsabläufen sowie Organisationsstrukturen des nationalen Gesundheitssystems. Bedingt durch die Struktur von IHE hat IHE Deutschland zwei Vorsitzende, von denen einer die Anwender (User-Cochair) und einer die Hersteller (Vendor-Cochair) repräsentiert. Für die einzelnen Domänen gibt es bei IHE Deutschland als Ansprechpartner sogenannte Caretaker (»Kümmerer«). Den für die jeweilige Domäne (Augenheilkunde, Kardiologie, Labormedizin, Pathologie, Radiologie) zuständigen Ansprechpartner sowie die IHE-Vorsitzenden erreicht man über das IHE-Sekretariat, welches natürlich auch den ersten Ansprechpartner zu allen Anfragen bzgl. IHE darstellt. Die Kontaktadresse lautet: IHE Deutschland e. V. c/o ZVEI FV Elektromedizinische Technik Lyoner Str Frankfurt am Main Tel.: 069/ /-207 Fax: 069/ info@ihe-d.org n IHE ist natürlich auch im Internet vertreten: IHE Deutschland: IHE Europa: IHE International: Literatur [1] Mildenberger P, Wein B, Bursig HP, Eichelberg M. (2005) Aktuelle Entwicklungen von DICOM und IHE. Radiologe. 45(8): [2] Wein BB. (2003) IHE (Integrating the Healthcare Enterprise): Ein [6] IHE (2007) Connectathon Results Browsing. [Online, zitiert ]; Verfügbar unter [7] IHE Technical Frameworks IT Infrastructure Technical Framework neuer Ansatz zur Verbesserung der digitalen Kommunikation im (2007) V Vol. 1 (ITI TF-1): Integration Profiles. [Online, zitiert Gesundheitswesen. Rofo. 175(2): ]; Verfügbar unter [3] Channin DS. (2001) Integrating the Healthcare Enterprise: A Primer Part 2. Seven Brides for Seven Brothers: The IHE Integration Profiles. IHE_ITI_TF_4_0_Vol1_FT_2007_08_22.pdf [8] Kauer Th, Mildenberger P. (2005) Integration von IT-Systemen im Rahmen der Initiative Integrationg the Healthcare Enterprise (IHE). mdi. RadioGraphics. 21: [4] Henderson M, Behlen FM, Parisot C, Siegel EL, Channin DS. (2001) Integrating the Healthcare Enterprise: A Primer Part 4. The Role of Existing Standards in IHE. RadioGraphics. 21: [5] Mildenberger P, Kauer Th. (2005) Integrating the Healthcare 7(3): [9] Channin DS, Parisot C, Wanchoo V, Leontiev A, Siegel EL. (2001) Integrating the Healthcare Enterprise: A Primer Part 3. What Does IHE Do for ME? RadioGraphics. 21: Enterprise (IHE) Eine internationale Initiative zur Interoperabilität im Gesundheitswesen. mdi. 7(2):