gms | German Medical Science

Einleitung: Syntaktische und semantische Interoperabilität bilden die wesentliche Basis für die elektronische Kommunikation zwischen Gesundheitsdienstleistern. Ohne eine gemeinsame Sprache in Form von Terminologien, die gesundheitsrelevante Objekte, Prozesse und Ereignisse wie Krankheiten, Medizinprodukte, Arzneimittel usw. eindeutig benennen, kann keine semantische Interoperabilität hergestellt werden. Die syntaktische Interoperabilität stellt darüber hinaus die Fähigkeit dar, dass die verschiedenen IT-Systeme die Daten überhaupt erst empfangen können. Dazu dienen Transaktionsstandards, wie beispielsweise HL7. Im Rahmen des vom Bundesministerium für Wirtschaft (BMWi) geförderten Projektes „Standards zur Unterstützung von eCommerce im Gesundheitswesen“ (Standard eCG) an der Hochschule Niederrhein werden relevante Terminologien analysiert und aufeinander abgebildet [1]. Die Firma AVERBIS stellt als eCG-Projektpartner in diesem Zusammenhang eine modifizierte Version der Averbis Terminology Platform (ATP) zur Verfügung. Dieses Terminologiemanagementsystem (TMS) dient der inhaltlichen Erschließung und Bereitstellung von Terminologien und Begriffssystemen aus den Bereichen eHealth und eCommerce. Das TMS basiert dabei auf dem Common Terminology Services 2 (CTS 2) Standard. Dieser beschreibt die Interaktionsmöglichkeiten, den syntaktischen Aufbau und die Semantik der Serviceschnittstelle [2]. Ziel ist es, einen Beitrag zur Steigerung der semantischen Interoperabilität zu leisten und dadurch automatisierte, elektronische Beschaffungsvorgänge in Einrichtungen des Gesundheitswesens zu ermöglichen. Die Kommunikationsfähigkeit der unterschiedlichen IT-Systeme, die auch unterschiedliche Transaktionsstandards verwenden, wird mit Hilfe eines spezifischen Anwendungsfalls innerhalb des Projektes in einem Democenter erprobt.

Material und Methoden: Durch Interviews mit den beteiligten Akteuren und Experten werden die im Rahmen des Projektes relevanten Terminologien anhand von Verbreitungsgrad, gesetzlicher Anforderung und Verfügbarkeit identifiziert. Anschließend werden Mappings zwischen den Terminologien aus dem eHealth- und eCommercebereich erarbeitet indem über Gemeinsamkeiten Kreuzreferenzen hergestellt werden. In einem spezifischen Anwendungsfall wird die Implantation einer zementierten Totalendoprothese am Hüftgelenk beschrieben. Dazu wird ein Mapping zwischen den Operations- und Prozedurenschlüssel (OPS) Codes zur Hüfttotalendoprothese (Hüft-TEP) zu Codes des eCommerce Standards eCl@ss angefertigt. ECl@ss ist ein Standard, der Produkte und Dienstleistungen beschreibt und klassifiziert. Dieser Standard wird branchenübergreifend in der Industrie, im Handwerk, im Handel und im Gesundheitswesen angewendet [3]. Der OPS dient der Verschlüsslung von Operationen und Prozeduren im stationären und ambulanten Sektor [4]. Die Mappingergebnisse werden nach erfolgter Qualitätssicherung im TMS zur Verfügung gestellt.

Im Democenter der Hochschule Niederrhein werden die technische Umgebung eines Krankenhauses und ein Workflow zwischen einem Krankenhausinformationssystem (KIS) und einem Materialwirtschaftssystem (MaWi) unter Einbindung des TMS simuliert. Die technische Umsetzung erfolgt nach Vorgaben des von der Integrating the Healthcare Enterprise (IHE) für das Projekt erstellten Leitfadens. Für den Workflow ist das Abrufen der vorhandenen Mappings ausschlaggebend. Der Prozess beginnt im Krankenhaus bei der OP Planung der Hüftoperation. Dazu werden alle operationsrelevanten Daten des Patienten, das Datum, etc. und die OPS Ziffer sowie die benötigten Materialien des geplanten Eingriffs in das OP-Modul des KIS eingetragen. Als OPS-Ziffer des Use Cases wird für diesen Fall die

5-820.01 verwendet. Im KIS selber sind keine weiteren Identifikationsmerkmale oder Preise des einzusetzenden Materials hinterlegt. Bei Fertigstellung der Planung wird vom KIS eine Textnachricht in Form einer CSV Datei generiert. Diese Nachricht enthält fallspezifische Informationen wie Patienten ID, Fall ID, OPS Ziffer und die Angaben zum Material. Diese Datei wird von einem Kommunikationsserver abgerufen und verarbeitet. In erster Instanz prüft der Kommunikationsserver, ob sich Identifikationsmerkmale des Materials in der CSV Datei befinden. Wenn dies nicht zutrifft, wird geprüft, ob eine OPS Ziffer im Dokument enthalten ist. Durch Detektion der OPS wird eine automatische Anfrage an das TMS mit Hilfe einer CTS Representational State Transfer application programming interface (RESTful API) erstellt. RESTful ist ein Schema, in dem beschrieben wird wie eine Kommunikationsschnittstelle eines Services erstellt wird. Dieses Schema wird meist bei Webservices angewandt. Hierbei wird abgefragt, ob es zu der OPS passende eCl@ss Codes gibt und ob die Bezeichnungen teilweise mit den Materialnamen übereinstimmen. Diese Codes werden dann mitsamt ihren Bezeichnern in eine vom Kommunikationsserver neu erstellten HL7 Nachricht eingetragen und an das MaWi versendet. Die Änderung des Formats dient der syntaktischen Interoperabilität. In der MaWi werden anschließend durch hinterlegte Katalogdaten des Lieferanten den eCl@ss Codes, die Global Trade Item Numbers (GTINs) der Produkte und die zugehörigen Preise zugeordnet. Anschließend wird eine Bestellnachricht in Form einer HL7 Nachricht generiert. In dieser Nachricht sind alle notwendigen Daten vorhanden, die für die Materialbestellung notwendig sind. Abschließend wird über den Kommunikationsserver die Bestellung in das EDIFACT Format umgewandelt und an den Lieferanten versandt. Der Anwendungsfall wird durch den Erhalt einer Empfangsbestätigung abgeschlossen.

Ergebnisse: Das Mapping zwischen den siebzehn OPS Codes im Bereich der Hüfttotalendoprothese zu eCl@ss lieferte jeweils mindestens eine Übereinstimmung. In diesem Zusammenhang wird von einem n:m Mapping gesprochen. Im Rahmen des Democenters konnte mit Hilfe des IHE Implementierungsleitfadens gezeigt werden, dass das Mapping der beiden semantischen Standards und die Umwandlung der notwendigen syntaktischen Standards einen automatischen Workflow ermöglicht, obwohl die verschiedenen Softwaresysteme keine einheitlichen Schnittstellen besitzen. Somit kann mit Hilfe der CTS2 Spezifikation in diesem Zusammenhang ein großer Nutzenvorteil erzielt werden.

Diskussion: Gespräche mit Experten und Anwendern beweisen eine hohe Nachfrage nach zuverlässigen Mappings zwischen medizinischen Terminologien und Standards aus dem Beschaffungswesen. Jedoch werden die verfügbaren Mappingergebnisse auf Basis der unterschiedlichen Terminologien in der Regel nicht frei zugänglich zur Verfügung gestellt. Ein spezifisches Problem besteht in der Zuordnung von eCl@ss Codes zu produktspezifischen Codes, wie bspw. der GTIN. Für eine solche Zuordnung ist es notwendig weitere Mappings zu den konkret im jeweiligen Krankenhaus genutzten Produkten durchzuführen. Dies wird allerdings mit einem entsprechenden Arbeitsaufwand und der Notwendigkeit einer stetigen Kontrolle und Aktualisierung bei Produktänderungen verbunden sein. Des Weiteren ist die grundsätzliche Möglichkeit zu prüfen, ob produktbezogene Identifikationsmerkmale direkt im OP-Modul eines KIS hinterlegt werden können. In Folge einer solchen Integration wäre der zusätzliche Einsatz eines TMS zumindest in diesem Kontext vermeidbar.

Dennoch kann eine konsequente Nutzung eines TMS auch weitere Nutzenpotentiale, beispielsweise zur einfachen Abfrage semantischer Inhalte oder auch zur Erlössicherung in Form einer umgekehrten Abfrage vom eingesetzten Produkt zur richtigen OPS-Ziffer, hervorbringen.