gms | German Medical Science

Das Gesundheitswesen steht vor der Herausforderung, die Qualität und Sicherheit der Patientenversorgung sowie die Effizienz der Versorgungsprozesse zu steigern. Dies geht einher mit einem Paradigmenwechsel hin zu zunehmend spezialisierten, arbeitsteiligen und dezentralisierten Systemen, also zu einer prozessgesteuerten und künftig sogar personenzentrierten Versorgung. Dieser Paradigmenwechsel kann insbesondere im Bereich der Notfallversorgung beobachtet werden, wo akut erkrankte oder verunfallte Personen schnell versorgt werden müssen. Innerhalb der Rettungskette ist die Übergabe vom Rettungsdienst in die Klinik eine kritische Schnittstelle.

Die in der Klinik bereits weit fortgeschrittene Digitalisierung der medizinischen Dokumentation beginnt aktuell auch im Rettungsdienst, in dem sogenannte Notfallmedizinische Informations-Systeme (NIS) eingeführt werden [1], [2]. Damit entsteht an der Schnittstelle zwischen Rettungsdienst und Klinik die Herausforderung einer semantischen interoperablen und prozessorientierten Kommunikation zwischen NIS und der Klinik-IT.

Da Einsatzmittel im Rettungsdienst überregional eingesetzt werden und Kliniken auch Patienten überregional aufnehmen, ist für eine erfolgreiche Marktdurchdringung die Einführung allgemeingültigen Industriestandards entsprechender Systeme erforderlich. Dies sollte möglichst frühzeitig und an bestehende Standards adaptiert erfolgen.

Das Ziel dieses Papiers ist die Analyse der grundlegenden Anforderungen zwischen NIS und KIS sowie ein Überblick über vorhandene Kommunikationsstandards und deren Eignung.

In der vorliegenden Arbeit wurde von einem Standardeinsatzszenario im Rettungsdienst ausgegangen: Ein akut erkrankter oder verunfallter Patient wird gemeinsam von einem Notarzteinsatzfahrzeug (NEF) und Rettungswagen (RTW) vor Ort versorgt. Die Dokumentation erfolgt zeitnah in einem NIS. Dabei ist eine automatische Datenübernahme vergleichbar zur Datenübernahme in der Anästhesie oder Intensivmedizin anzustreben [1], [3], [4].

Nach der Transportentscheidung sollen die Daten an die Zielklinik übertragen und dort für die Organisation der Notaufnahme verwendet werden. Nach Abschluss des Einsatzes wird das fertige Protokoll als abgeschlossen übertragen und als Befund in dem Krankenhausinformationssystem (KIS) eingestellt.

Weitere Szenarien sind zu berücksichtigen, wenn das NEF durch die RTW-Besatzung nachalarmiert wird oder von einem NEF mehrere Patienten in mehreren RTW zu versorgen sind, da in diesem Fall die Daten von mehreren Einsatzfahrzeugen zusammengeführt werden müssen.

Das Problem der Datenübermittlung kann vereinfachend in drei unabhängige Bereiche unterteilt werden:

• Sammlung,
• Transport und
• Darstellung

der Daten in einem bestimmten Format.

Die Inhalte der Datenerfassung sind durch den MInimalen NotarztDatensatz (MIND) in der jeweils gültigen Version von der Fachgesellschaft vorgegeben [5].

Der Prozess der Datensammlung kann – ungeachtet der Behandlung des Patienten – durch die Übernahme der Daten aus zur Behandlung des Patienten eingesetzten Geräten erfolgen.

„Integrating the Healthcare Enterprise“ (IHE, http://www.ihe-d.de/) ist eine Initiative, die als Zusammenschluss von Anwendern (Ärzten) und Herstellern sog. Integrationsprofile erarbeitet hat, die konkrete Problemfälle im Bereich des interoperablen Datenaustausches und die dazugehörigen Lösungen auf Basis von Standards insbesondere „Health Level 7“ (HL7, http://www.hl7.de/ / http://www.hl7.org/) beschreiben.

Für die Datenübernahme aus Geräten wurde bei IHE in der Domäne „Patient Care Devices“ (PCD) das sogenannte „Device Enterprise Communication (DEC)“ Integrationsprofil erarbeitet, in dem das Gerät in der Rolle des „Device Observation Reporters (DOR)“ die Informationen an einen „Device Observation Consumer (DOC)“ übermittelt. Hierbei werden die Daten auf Basis von ISO/IEEEE 11073 „Health Informatics – Point-of-care medical device communication“ kodiert und syntaktisch als HL7 v2.6 ORU-Nachricht (Befund) übermittelt.

Alternativ zur Datenübernahme aus Geräten fertigt der Notarzt ein Behandlungs-protokoll an. Hierbei können die von den Geräten übernommenen Daten ggf. direkt eingebunden werden.

Zur Übermittlung der Daten verweist das DEC-Profil auf MLLP – dies ist eine adressierte Socket-Kommunikation auf Basis von TCP/IP – sowie WS-* (Webservices). Letzteres lässt sich auch im NEF oder RTW einsetzen. Die Schwierigkeit ist, dass eine Empfangsstelle existieren und bekannt sein muss.

Alternativ dazu gibt es neben D2D, der „Doctor to Doctor“ Kommunikation der KBV (http://www.kbv.de/, http://www.d2d.de/) als dateibasierte, adressierte und gesicherte Übertragungsvariante, noch das von IHE ITI („IT Infrastructure“) beschriebene Integrationsprofil XDM: „Cross-Enterprise Document Media Interchange“. Hierbei werden Standardmedien wie bspw. CDs oder USB-Sticks zum Datenaustausch eingesetzt. Wenn bei letzterem von den Vorteilen vorab übermittelter Daten abgesehen wird, kann relativ einfach im RTW ein USB-Stick beschrieben werden, der alle Daten als Dokumentsammlung enthält und direkt im Krankenhaus in das empfangende Informationssystem eingelesen wird. Damit wären alle relevanten, während der Notarztbehandlung angefallenen Daten sofort in der Notfallambulanz verfügbar.

Bleibt die Fragestellung der Übernahme der Daten in ein KIS: Vom Ablauf her besteht entweder die Möglichkeit einer Standardaufnahme in das KIS unter Nutzung vorhandener Identifikationsmöglichkeiten, sofern der Patient ansprechbar oder sonst wie identifizierbar ist. Anderenfalls ist eine Notaufnahme mit Übernahme der Daten durchzuführen und im Nachgang das IHE Integrationsprofil „Patient Information Reconciliation“ (PIR) zu benutzen, um die Daten mit einem evtl. bereits angelegten Patientendatensatz zu konsolidieren.

Die nun noch zu diskutierende Datendarstellung kann im ersten Schritt – abgesehen von der Datenübernahme aus Geräten – auf eine reine Dokumentendarstellung reduziert werden, weil eine Behandlungsdokumentation im Vordergrund steht. Die Deutsche Interdisziplinäre Vereinigung für Intensiv- und Notfallmedizin e.V. (DIVI, http://www.divi-org.de/) hat begonnen, die Dokumentation in der Notaufnahme auf Basis des DIVI-Notaufnahmeprotokolls in Deutschland zu vereinheitlichen.

Formulare sind ein bestimmter Typ von Dokumenten, für die HL7 im Jahre 2005 die sogenannte Clinical Document Architecture (CDA) spezifiziert hat. Dies ist eine umfassende und relativ generische Vorgabe, um beliebige klinische Dokumente unter Nutzung der XML-Technologie (eXtensible Markup Language, http://www.w3.org/) abbilden zu können. CDA unterstützt dabei zum einen den Anwender, in dem in den Dokumenten direkt lesbare Texte enthalten sind. Darüber hinaus werden aber auch die Informationssysteme unterstützt, indem sog. Markups in die Dokumente eingebaut werden, um kodierte Informationen zu übertragen. Auf diese Weise entstehen Dokumente, die über sog. XML-Stylesheets zur Anzeige gebracht und auch ausgedruckt werden können, die aber ebenfalls zur unmittelbaren Datenübergabe zwischen zwei Informationssystemen genutzt werden können. Wichtig ist hierbei zu vermerken, dass diese Dokumente sowohl von den Anwendungen ohne Benutzerinteraktion automatisiert erstellt werden als auch digitale Signaturen zur Authentifizierung des Inhaltes enthalten können.

Der bvitg (Verband der Hersteller von IT im Gesundheitswesen, www.bvitg.de, vormals VHitG) hat 2006 CDA als Grundlage benutzt, um eine deutsche Fassung davon zu veröffentlichen, die unter dem Namen VHitG Arztbrief [6] bekannt geworden ist.

IHE hat in der Domäne "Patient Care Coordination" (PCC) weitere sog. Content Profiles erstellt, die dedizierte Vorgaben für Dokumenteninhalte darstellen. Hier wäre insbesondere das Profil "Emergency Department Encounter Summary" (EDES) zu erwähnen, das Vorgaben für "Triage Notes" (TN), "Nursing Notes" (NN) und "Emergency Department Physician Notes" (EDES-EDPN) enthält.

Für eine Reihe der zu lösenden Fragen lassen sich direkt Realisierungsmöglichkeiten aufzeigen, die einsetzbar sind. Für andere wiederum – wie bspw. das Notarztprotokoll – gibt es Grundlagen (CDA), die weiter spezifiziert und offiziell (über das Interoperabilitätsforum, www.interoperabilitaetsforum.de) abgestimmt werden müssen, um als Standard deklariert werden zu können. Die noch ausstehende Abbildung des MIND-Datensatzes des DIVI-Protokolls auf CDA lässt abgesehen von der Versionierung (MIND2/3) verschiedene Möglichkeiten zu. Die dazugehörigen Vor- und Nachteile sind zu diskutieren und festzuschreiben.

Wie dargestellt wurde, sind genügend profilierbare Kommunikationsstandards zur Lösung der anstehenden Probleme verfügbar, so dass von proprietären Lösungen Abstand genommen werden kann. Die Standardisierungsorganisation HL7 und auch IHE sind Lokalisationen oder besser noch erweiternden Change Proposals nicht abgeneigt.

An dieser Stelle sei den vielen Freiwilligen gedankt, die sich aktiv in den Standardisierungsorganisationen wie IHE und HL7 engagieren.

Die Autoren erklären, dass sie keinen Interessenkonflikt haben.