Beim Betrieb medizinischer Einrichtungen fallen sehr viele unterschiedliche Daten an. Neben medizinischen Daten zählen dazu betriebswirtschaftlich relevante Informationen ebenso wie banale Termine und Adressdaten. Diese Vielfalt an Themen führt meist auch zu einer Vielfalt an eingesetzten Softwareprodukten. Softwareschnittstellen ermöglichen es diesen verschiedenen Programmen, miteinander auf festgelegte Weise Informationen auszutauschen. Bei Neuanschaffung und Erweiterung von Software ist das Vorhandensein und die Art von Schnittstellen zu anderen Programmen deshalb ein wichtiges Auswahlkriterium, um die Interoperabilität mit der bestehenden und auch der zukünftigen Softwarelandschaft zu gewährleisten.

Schnittstellenstandards wie FHIR (Fast Healthcare Interoperability Resources) und ISiK (Informationstechnische Systeme in Krankenhäusern) sind dabei ein unverzichtbarer Baustein auf dem Weg zu reibungslosem Datenaustausch im Gesundheitswesen. Im Zuge des Krankenhauszukunftsgesetzes (KHZG) und der Initiative ISiK setzt der Gesetzgeber nun vermehrt auf verpflichtende Schnittstellenstandards. Hierdurch wird die Interoperabilität verschiedener Softwareprodukte von der Kür zum harten Pflichtprogramm.

Softwareschnittstellen ermöglichen den Datenaustausch

Beim Thema Interoperabilität und Schnittstellen zwischen Softwareprodukten dürfte den Wenigsten der Mund wässrig werden. Tatsächlich handelt es sich bei Schnittstellen (oder Interfaces) aber um essenzielle Komponenten moderner Software, ohne die der Aufwand bei Erfassung, Pflege und Verarbeitung von Daten stark ansteigt und ein Gesamtüberblick über relevante Informationen nur schwer oder gar nicht möglich ist.

Schnittstellenstandards wie FHIR und ISiK sind ein unverzichtbarer Baustein auf dem Weg zu reibungslosem Datenaustausch im Gesundheitswesen.

Man kann sich Softwareschnittstellen als virtuelle Orte vorstellen, an denen bestimmte Informationen in einer ganz bestimmten, vorher festgelegten Form von einem zum anderen Programm übertragen werden. Dabei ist jeweils genau festgelegt, wie die jeweilige Abfrage von Daten und auch die jeweilige Antwort auszusehen hat. Der große Vorteil solcher definierten Softwareschnittstellen besteht darin, dass sie den Austausch von Informationen zwischen verschiedenen Programmen verschiedener Hersteller ermöglichen, sofern sie denn verwendet werden.

Ein Beispiel für Schnittstellenprobleme

Wenn nun ein Kalenderdatum mit Uhrzeit vom KIS in das Portal übertragen werden soll, könnte das Problem bestehen, dass von den unterschiedlichen Programmen intern unterschiedliche Darstellungen der Termine verwendet werden und ein Austausch über Termine somit nicht ohne Weiteres möglich ist. Eine theoretische Möglichkeit zur Behebung dieses Problems wäre, allen Herstellern dieselbe Art der Darstellung vorzuschreiben. Dies wäre aber ein sehr starrer und – bei der Zahl unterschiedlicher Hersteller – letztlich auch vermutlich undurchsetzbarer Weg. Durch die Verwendung von Schnittstellen müssen sich die verschiedenen Softwarehersteller nur an einem Punkt, nämlich eben an der Schnittstelle, auf eine Darstellung einigen.

Vom Patientenportal aus könnte dann eine Anfrage an das KIS kommen, welche Termine für eine bestimmte Untersuchung im Portal angeboten werden können. An der Schnittstelle zwischen den beiden Programmen werden nun in einem vorher festgelegten Schnittstellenformat die möglichen Zeitpunkte für die Untersuchung übergeben. Stimmt das vorgegebene Schnittstellenformat mit dem vom KIS intern verwendeten Format überein, so ist keine Zusatzarbeit nötig. Wird KIS-intern jedoch ein anderes Format verwendet, so müssen die Daten vom KIS vor der Bereitstellung an der Schnittstelle erst noch in das Schnittstellenformat umgewandelt werden.

Problemlos miteinander kommunizieren

Aus Sicht des Patientenportals ist so in jedem Fall klar, in welchem Format die Daten vom KIS bereitgestellt werden. Wird portalintern ein anderes Format verwendet, so müssen die Daten andersherum nach der Abholung an der Schnittstelle wieder in dieses gewünschte Format umgewandelt werden. Der Reiz an der Verwendung von solchen Schnittstellen ist, dass die verschiedenen Hersteller in ihren Programen nach wie vor tun können, was sie für richtig halten. Lediglich für die Schnittstellen muss ein gemeinsamer Standard festgelegt werden. Oft wissen die Hersteller nicht einmal, welches Format andere Hersteller intern verwenden. Dank der Schnittstelle ist aber trotzdem eine reibungslose Interoperabilität zwischen den verschiedenen Programmen möglich. Dieses Prinzip des Zugriffs nur per definierter Schnittstelle bei ansonsten von außen verborgenen internen Prozeduren eines Programms bezeichnet man als Datenkapselung oder Encapsulation.

In der ISiK Basis Stufe I geht es um den standardisierten Austausch von Patienteninformationen wie Name, Geburtsdatum, Versicherungsinformationen und Diagnosen.

Neben einfachen Daten wie Kalenderterminen, Adressen und Geburtstagen kommen im medizinischen Bereich auch deutlich komplexere Daten vor, wie Medikationspläne, Fieber- und Blutdruckkurven, Röntgen- und MRT-Bilder, Laborwerte, Diagnosen und viele weitere. Nun wäre es in der Praxis nicht durchführbar, dass sich immer je zwei Hersteller untereinander für einen bestimmten Datentyp auf eine bestimmte Schnittstelle einigen. Je mehr Hersteller die gleichen Schnittstellen in ihren Programmen verwenden, desto nützlicher ist die Schnittstelle. Eine zentrale Erstellung von Schnittstellen für die einzelnen Datentypen, die dann möglichst viele Hersteller verwenden können, ist daher sehr sinnvoll. Der Idealzustand sähe dann so aus, dass alle Programme von allen Herstellern den gleichen Satz Schnittstellen verwenden und jedes Programm somit mit jedem anderen problemlos kommunizieren könnte.

Nutzung etablierter Webtechnologien

Health Level 7 (HL7) ist eine internationale Organisation mit dem Ziel der Schaffung von Schnittstellenstandards für den Datenaustausch zwischen den Computersystemen verschiedener Organisationen im Gesundheitswesen. Mit dem HL7 Standard Version 2.x wurden einige Nachrichtentypen zum Austausch von häufig benötigten Datentypen im Gesundheitswesen eingeführt, wie zum Beispiel MDM zur Übermittlung medizinischer Dokumente, ORM zur Anforderung einer Untersuchung, ORU zur Befundübermittlung, ADT für Patientenstammdaten und noch viele weitere. Die nächste Version 3.x erweiterte die Version 2.x erheblich und nahm neben benötigten Nachrichtentypen auch die Abbildung bestimmter Prozesse in den Fokus.

Der Preis für diese Erweiterung war allerdings eine deutlich komplexere Implementierung des Standards im Vergleich zur Vorgängerversion. Die aktuelle Version heißt nicht 4.x sondern FHIR. In dieser Version liegt der Fokus einerseits auf einer einfachen Implementierung des Standards und andererseits auf der Nutzung von etablierten Webtechnologien. Letzteres soll unter anderem die Einbindung von Tablets und Smartphones in die Arbeitsabläufe erleichtern. Von HL7 kommen jedoch nur Vorschläge zu universellen Schnittstellen, welche in keiner Weise verpflichtend sind. HL7 hat schlicht nicht die Berechtigung, verpflichtende Vorgaben zu machen.

vegefox.com/stock.adobe.com

Verpflichtende Schnittstellenstandards

Mit dem KHZG machte aber der Bund einen Schritt in Richtung verpflichtende Schnittstellen. In der Förderrichtlinie hierzu heißt es, dass Vorhaben nur dann förderfähig sind, wenn dabei vorhandene technische, syntaktische und semantische Standards zur Interoperabilität digitaler Dienste verwendet werden. Allerdings gelten diese Vorgaben zum einen nur für Vorhaben im Rahmen des KHZG und somit längst nicht für alle medizinischen Softwareprodukte. Zum anderen müssen die besagten Standards nur „sofern verfügbar“ eingehalten werden. Für letzteres verweist die Förderrichtlinie auf das Interoperabilitäts-Verzeichnis „vesta“ der Gematik (heute abgelöst von dem Interoperabilitäts-Navigator INA).

Ein weiteres Gematik-Projekt macht mittlerweile deutlich weitreichendere Vorschriften zu Schnittstellen-Standards, die auch stetig weiter ausgebaut werden sollen. Diese Initiative ISiK baut auf den FHIR-Standards auf und definierte nun erstmals einige – ab August 2023 verpflichtende – Schnittstellenstandards für alle in Deutschland eingesetzten Krankenhausinformationssysteme. In dieser ersten Stufe, ISiK Basis Stufe I, geht es um den standardisierten Austausch von Patienteninformationen wie Name, Geburtsdatum, Versicherungsinformationen und Diagnosen. Diese Stufe I zu Basisinformationen wird mit der Basis Stufe 2 im Sommer 2024 und der Basis Stufe 3 2025 noch verpflichtend erweitert werden. Ebenfalls verpflichtend ab Sommer 2024 und 2025 sind dann auch weitere Schnittstellenmodule zum Austausch von Dokumenten, Medikationsinformationen, Vitalparametern, Körpermaßen, Terminplanungsinformationen sowie speziell pflegebezogenen Informationen (ISiP).

Standards ermöglichen Best of Breed-Ansatz

Diese verbindlichen Standards können in Zukunft noch erweitert werden und somit letztlich eine weitgehende Interoperabilität zwischen medizinischen Softwareprodukten erzwingen. Dies ist eine gute Nachricht für alle Hersteller von KIS-Subsystemen, die in Zukunft deutlich mehr Sicherheit zu der Frage haben werden, auf Basis welcher Schnittstellenstandards sie ihre Produkte entwickeln können. Für Krankenhausbetreiber bedeutet dies wiederum, dass es vermehrt möglich sein wird, auf den Best of Breed-Ansatz zu setzen, also jeweils das passendste Produkt auszusuchen und so die digitale Transformation aktiv steuern zu können.

Für Krankenhausbetreiber bedeutet dies wiederum, dass es vermehrt möglich sein wird, auf den Best of Breed-Ansatz zu setzen.

Vermutlich ist dieser Weg über gesetzlich vorgegebene Schnittstellen in dieser Form notwendig, denn trotz seit Jahrzehnten bestehenden Vorschlägen zu Standards von zum Beispiel HL7 wurden diese bisher von Herstellerseite eher zaghaft umgesetzt. Das liegt einerseits sicherlich an dem dadurch bei der Entwicklung entstehenden Mehraufwand. Andererseits bietet die Abwesenheit von Schnittstellen einem Hersteller zumindest theoretisch die Möglichkeit, Kunden dazu zu zwingen, in Form eines monolithischen Ansatzes bei den Produkten eines einzigen Herstellers zu bleiben.