gms | German Medical Science

Einleitung: Für die elektronische Kommunikation zwischen Gesundheitsdienstleistern ist eine semantische und syntaktische Interoperabilität ein wesentlicher Bestandteil, da die IT-Systeme erst dadurch Daten korrekt empfangen und verarbeiten können. Bei dem Projekt Standard eCG kommen eStandards von Health Level 7 (HL7) und Global Standards One (GS1) zum Einsatz. Durch falsch verarbeitete Daten können Patienten gefährdet werden, da diese evtl. eine falsche Medikation erhalten oder eine falsche Diagnose erstellt wird. Im Projekt „Standards zur Unterstützung von eCommerce im Gesundheitswesen“, (Standard eCG), welches vom Bundesministerium für Wirtschaft und Energie gefördert wird, werden Beschaffungsprozesse analysiert und optimiert [1]. Ziel ist es, (semi-)automatisierte Beschaffungsvorgänge im Gesundheitswesen zu schaffen und zu erproben Dies ist allerdings nur mithilfe von eStandards möglich. IHE erstellte im Rahmen dieses Projekts einen Implementierungsleitfaden für eSupply welcher mittels einem definierten Use-Case im Democenter des Projektes simuliert wird.

Material und Methoden: Durch Interviews mit Fachexperten und Akteuren wurden relevante Transaktionsstandards identifiziert, die anhand der Kriterien gesetzliche Anforderungen, Verbreitungsgrad und Verfügbarkeit ausgewählt wurden. Die relevantesten sind HL7 Version 2 und GS1 eCom. Aus diesen Standards wurden anschließend Nachrichten, die den Beschaffungsprozess am besten abbilden, ausgewählt und optimiert. Beim GS1 Standard ist dies die Order Nachricht. Bei HL7 sind es die Nachrichten Pharmacy/treatment encoded order message, Stock requisition order message und Pharmacy/treatment order message. Es wurde ein Mapping zwischen der HL7 Nachricht Stock requisition order message und der Order Nachricht von der GS1 erstellt Durch das Mapping wird die Kommunikation zwischen der Industrie und den Krankenhäusern gewährleistest, da HL7 Nachrichten meist Krankenhaus intern und zur Kommunikation mit anderen Krankenhäusern eingesetzt werden, dagegen wird die GS1 Nachricht größtenteils zur Kommunikation von Lieferanten und Herstellern genutzt. Dieses wird im projekteigenen Integrating the Healthcare Enterprise (IHE) Implementierungsleitpfaden beschrieben. Es wurden Anwendungsfälle in Form von Use Cases spezifiziert, die einen Teil des Beschaffungswesens eines Krankenhauses abbilden. Im ersten Anwendungsfall wird das Krankheitsbild Einsetzen einer Hüfttotalendoprothese (Hüft-TEP) gewählt. Dieser Use Case wurde im Democenter des Standard eCG Projekts anhand der beschriebenen Schritte umgesetzt. Der Workflow beginnt bei der OP-Planung im Krankenhaus. Es werden alle OP relevanten Daten, wie beispielsweise das Datum, die Patientendaten, die Produktnamen und die Operations- und Prozedurenschlüssel (OPS), eingegeben. Die OPS Ziffer wird in diesem Fall zwingend benötigt, da sich durch diese Ziffer im späteren Verlauf Materialidentifikationsmerkmale, Produktidentifikationsmerkmale und Preise bestimmen lassen. Es wird eine proprietäre CSV Datei ohne Material- und Produktidentifikationsmerkmale und Preise, jedoch mit den Produktnamen, der Fall ID, der OPS und anderen Daten, erzeugt. Diese Datei von einem Kommunikationsserver eingelesen und danach von Diesem in eine HL7 V2 Nachricht Stock requisition order message konvertiert. Dabei wurden die Felder der KIS Bezeichnung, Materialnamen, Datum und OPS aus der CSV übernommen. Die KIS Bezeichnung wurde in das Feld Sending Application des Message Header (MSH) Segments, die Materianamen in mehrere OBR Segment in das jeweilige Relvant Clinical Infomation Feld eingetragen. Die OPS wurden ebenfalls in diese OBR Segmente in das Feld Placer Field 2 eingetragen. Diese befindet sich genauso wie bei den Materialnamen in mehreren OBR Segmenten. Anschließend prüft dieser, ob sich Identifikationsmerkmale für Produkte oder Materialien in der neu erstellten Nachricht befinden. Sofern dies nicht der Fall ist, wird mithilfe einer Representational State Transfer application programming interface (RESTful) Common Terminology Services 2 Schnittstelle ein Terminologieserver (TMS) angesprochen. RESTful ist ein Architekturstil, in dem beschrieben wird, wie eine Kommunikationsschnittstelle mithilfe von HTTP Request realisiert werden kann. CTS 2 beschreibt die Interaktionsmöglichkeiten und den syntaktischen und semantischen Aufbau von aus- und eingehenden Nachrichten [2]. Bei dieser Anfrage wird zu der definierten OPS ein passender eCl@ss Codes ermittelt. Produkte und Dienstleistungen werden durch den eCl@ss Standard beschrieben und spezifiziert [3]. Anschließend wird geprüft, ob die Produktnamen den Bezeichnern zugeordnet werden können. Durch die Zuordnung befinden sich im Folgenden Materialidentifikationsmerkmale in der neuen HL7 Nachricht. Da diese keine Produkte beschreiben, sind die Merkmale für diese Bestellung nicht ausreichend. Danach wird diese Nachricht an das Materialwirtschaftssystem weitergeleitet (MAWI). Nachdem einlesen der Nachricht prüft das System, ob sich Produktidentifikationsmerkmale in der Nachricht befinden. Da dies nicht der Fall ist, wird geprüft ob Materialidentifikationsmerkmale vorhanden sind. Da diese vorliegen, bestimmt die MAWI mithilfe einer Tabelle die dazugehörigen Produkte, Global Trade Item Numbers (GTINs) und Preise. Diese Daten werden in die vorhandene Nachricht integriert und anschließend an den Kommunikationsserver versendet und von diesem in eine Electronic Data Interchange for Administration, Commerce and Transport (EDIFACT) D96A Order Nachricht umgewandelt, da der Provider in diesem Fall kein anders Format akzeptiert. EDIFACT ist ein Transaktionsstandard der international dazu verwendet wird um kommerzielle Daten elektronisch auszutauschen [4]. Anschließend wird diese Nachricht auf den FTP Server vom Provider hochgeladen. Der Provider verarbeitet diese und erstellt abschließend eine neue Nachricht mit der Empfangsbestätigung.

Ergebnisse: Die Simulation hat bewiesen, dass es möglich ist, den Beschaffungsprozess im Gesundheitswesen durch mehrere interoperable Standards zu optimieren und automatisieren.

Desweitern entstanden zwei Mappings, das eine zwischen einer proprietären CSV Datei und einer im Projekt definierten HL7 Nachricht und das andere zwischen der vorher erwähnten HL7 Nachricht zu einer EDIFACT Nachricht.

Diskussion: Problematisch ist die Erzeugung einer proprietären CSV Datei durch das KIS. So muss bei alternativen Krankenhausinformationssystemen die Zuordnung neu durchgeführt werden. Eine Alternative stellt hier eine HL7 Nachricht dar, da diese bei allen KIS, die diese Schnittstelle unterstützten, eingesetzt werden kann. Dieser Anwendungsfall ist in einer nächsten Simulation geplant.

Ein weiteres Problem ist die Ermittlung der Material-ID, weil die dazu verwendeten Produktnamen aller Voraussicht nach nicht mit den eCl@ss Bezeichnern übereinstimmen. Eine bessere Lösung stellt das Senden von Katalogdaten durch die MAWI an das KIS dar.

Darüber hinaus erweist sich die manuelle Zuordnung der GTINs zu den eCl@ss Codes als problematisch. Bei Änderungen des Produktes oder des Lieferanten erfordert dies ein erneutes Mapping.