Digitale Vernetzung klinischer Systeme und elektronische Patientenakten sind wahrlich keine neuen Themen. Die Corona-Pandemie hat unserem Gesundheitssystem jedoch den Spiegel vorgehalten und gezeigt, welchen bescheidenen Stand Deutschland auf diesem Feld bislang erreicht hat. Es gibt nicht wenige Leuchtturmprojekte, jedoch in der Fläche ist die Digitalisierung noch längst nicht angekommen.
Das vor Kurzem auf den Weg gebrachte Krankenhauszukunftsgesetz (KHZG) soll nun Anreize für alle bieten, den Aufbruch zu wagen und die notwendigen Investitionen anzupacken. Auf vielen Ebenen lassen sich in den kommenden Jahren Vorhaben durch eine gewaltige finanzielle Förderung von insgesamt 4,3 Mrd. Euro realisieren. Im Fokus stehen dabei elf förderfähige Bereiche, für die Anträge gestellt werden können.
Interoperabilität: Das müssen Geräte und Systeme leisten
Ein Schwerpunkt der Förderung ist die Interoperabilität von medizinischen Geräten und Systemen. Dies umfasst die hausinternen Prozesse im Krankenhaus wie auch die Kommunikation mit anderen Einrichtungen und zentralen elektronischen Patientenakten, wie sie jetzt von den Krankenkassen angeboten werden.
Die Förderung, die über das KHZG ermöglicht wird, ist allerdings an die folgenden Bedingungen geknüpft (KHZG, §19 II):
- [dass] international anerkannte technische, syntaktische und semantische Standards zur Herstellung einer durchgehenden einrichtungsinternen und einrichtungsexternen Interoperabilität digitaler Dienste verwendet werden
- [dass] generierte, für Patientinnen und Patienten relevante Dokumente und Daten in die elektronische Patientenakte übertragbar sind
Letztendlich ergibt sich aus diesen beiden Punkten dieselbe Konsequenz: Wenn ein Krankenhausbetreiber oder eine Klinik die Investitionen in medizinisches Equipment gemäß KHZG staatlich subventionieren lassen möchte, sind auf einmal Standardschnittstellen zum Datenaustausch ein zwingendes Beschaffungskriterium. Und damit wirkt sich das KHZG auf die Hersteller aus: die Marktchancen von Insellösungen sinken ab sofort drastisch.
Die bisherige Zurückhaltung der Medizingerätehersteller, sich der Schnittstellenthemen intensiver anzunehmen, kommt jedoch nicht von ungefähr. Wenn es um Software für Medizingeräte geht, liegt das Hauptaugenmerk bislang eher auf Themen wie Sensorik, User Experience und Sicherheit. Und wer sich mit dem Schnittstellenthema befasst, stößt als erstes auf die Frage, mit welchem der sehr verschiedenen heute verfügbaren Kommunikationsstandards man sich im Falle des eigenen Gerätes am besten auseinandersetzen sollte.
In der Tat gibt es in vielen Fällen keine klare Grenze zwischen „richtig“ und „falsch“. Die Konformität des eigenen Geräts zu einem bestimmten Standard führt aber nur dann zur gewünschten Interoperabilität der Geräte beim Anwender, wenn sich hinreichend viele andere Hersteller für denselben Standard entscheiden – denn der Anwender will ja einen Datenaustausch mit anderen Systemen erreichen. Maßgeblich sind hier die führenden Lösungen, zum Beispiel das Krankenhausinformationssystem KIS, das Picture Archiving and Communication System, kurz Pacs, und künftig eben auch die elektronische Patientenakte, ePA.
Für einen Hersteller von Medizingeräten, die Bild- oder Videodaten und gegebenenfalls daraus abgeleitete Analysedaten erzeugen, ist die Wahl noch relativ einfach. Bei Systemen in der Radiologie, Endoskopen oder auch für Kameras in der Dermatologie, die innerhalb einer medizinischen Einrichtung betrieben werden, führt an Digital Imaging and Communication in Medicine, kurz Dicom, kein Weg vorbei.
Dicom ist für Bilder und Video Pflicht – aber er kann mehr
Für Bild- und Videodaten ist der Dicom-Standard das Maß aller Dinge. Er ist recht komplex und erfordert eine steile Lernkurve. In der Praxis allerdings ermöglichen Dicom-Schnittstellen dem Anwender, nach dem Motto Plug&Play zu arbeiten. Und Dank der Abwärtskompatibilität zu Vorversionen ist eine Investition in eine Dicom-Schnittstelle für lange Zeit gesichert.
Der Einsatz von Dicom ist aber nicht auf den Austausch von Bilddaten beschränkt. Beispielsweise lassen sich Schnittstellen für EKG-Messgeräte, Messwerte in der Augenheilkunde und strukturierte Befunde aller Art damit lösen. In solchen Grenzbereichen ist es aber wichtig, rechtzeitig auszuloten, welchen Standard der Anwender im Krankenhaus erwartet.
Etwas unübersichtlicher wird es bei Geräten, die im Krankenhaus betrieben werden, aber vor allem Messwerte, Kurven oder andere Analysedaten erzeugen. Beispiele hierfür sind Laborsysteme, Infusionspumpen oder Geräte, die auf der Intensivstation und im OP kritische Körperfunktionen überwachen. Solche Systeme werden bisher am häufigsten
per Health Level 7 (HL7) eingebunden. Auch der im Projekt OR.Net entwickelte herstellerübergreifende Standard „Service-Oriented Device Connectivity“ (SDC) aus der IEEE 11073-Familie beschreibt den bidirektionalen Datentransfer zwischen einer Vielzahl von Medizingeräten. IEEE 11073-SDC spielt in der Praxis eine Rolle, allerdings nicht für die Dokumentation. Hierfür ist eine Abbildung der Daten auf HL7 definiert.
Anders als Dicom ist HL7 ein sehr flexibler Standard. Er bietet viele Freiheitsgrade, Optionen und Konfigurationsmöglichkeiten, und es gibt ihn in unterschiedlichen Versionen – die untereinander nicht kompatibel sind. HL7 ist zwar in der Software einfach zu handhaben, erfordert aber einen höheren Aufwand bei der Inbetriebnahme als zum Beispiel Dicom. Für eine HL7-Geräteschnittstelle bedeutet das: Der Entwickler muss von Anfang an denkbare Konfigurationsmöglichkeiten vorsehen, damit nicht jedes Anbindungsprojekt eine Softwareänderung erfordert.
Die Standards Dicom und HL7 sind darüber hinaus beide in den 1970iger und -80iger-Jahren definiert worden und damit zu einer Zeit, in der die heutigen Entwicklungen im Bereich mobiler Gesundheitsanwendungen längst nicht abzusehen waren. Daher haben sie eine Gemeinsamkeit: Sie gehen davon aus, dass der Datenaustausch stets zwischen zwei vorab bekannten Partnern erfolgt, also „peer to peer“. Aus heutiger Sicht ist es aber ziemlich unrealistisch, dass ein Krankenhaus mit zahlreichen mobilen Blutzuckermessgeräten hunderte von HL7-Schnittstellen einrichtet, um die Geräte darüber zu erreichen. Das wäre nicht zuletzt aufgrund von Cybersecurity-Aspekten ein Unding. Für solche Fälle wiederum wurde vor wenigen Jahren der Fast-Healthcare-Integration-Resources-Standard, kurz FHIR (gesprochen wiedas englische Wort „fire“) entwickelt. Eine erste Version wurde 2018 freigegeben.
Um FHIR ist schon vor der ersten Freigabe ein regelrechter Hype entstanden. Das lässt sich unter anderem darauf zurückführen, dass
- dem Standard eine moderne Technologie zugrunde liegt (Representational State Transfer, abgekürzt Rest – darin sind bestimmte Vorgaben für die Softwarearchitektur von verteilten Systemen zusammengefasst, insbesondere für Webservices),
- er über ein Datenmodell aus einem Guss verfügt sowie
- über eine hervorragende Dokumentation.
FHIR wird sicherlich in den kommenden Jahren an Bedeutung gewinnen, ist aber – anders als Dicom und HL7 – noch längst nicht flächendeckend und mit allen Ausprägungen verfügbar. Derzeit wird FHIR vor allem dort eingesetzt, wo Aufgaben mit Dicom und HL7 praktisch unlösbar sind: wenn es um mobile Anwendungen und Datenaustausch mit Systemen außerhalb des Hauses geht.
FHIR – der Standard für den Corona-Impfnachweis
Ein gutes Beispiel für einen Fall, in dem es ohne FHIR nicht ging, ist der europäische Corona-Impfnachweis. Dafür ist die Kommunikation zwischen Krankenhaus, zentralem europäischem Register und einer App beim Patienten erforderlich. Bei der Entwicklung eines solchen Medizingerätes, das Daten am Patienten außerhalb des Krankenhauses erhebt, ist FHIR der beste Weg. Und so ist damit zu rechnen, dass Häuser, die solche Geräte einsetzen möchten, entsprechende Schnittstellen entweder haben oder demnächst schaffen werden – jetzt auch KHZG-gefördert.
Für die Medizinproduktehersteller ergibt sich aus diesen Überlegungen, dass bei der Entwicklung ihrer Geräte zwischen Konformität und Interoperabilität unterschieden werden muss und Konformität zu Schnittstellen allein nicht hilft. In allen hier erwähnten Standards gibt es zwar ein Mindestmaß an Informationen, das über eine konforme Schnittstelle kommuniziert werden muss. Das allein reicht in der Praxis aber häufig nicht aus, um den vom Anwender erwarteten Workflow zu implementieren – also Interoperabilität zu erreichen.
Wer mit diesem Zusammenspiel schon Erfahrungen gesammelt hat, ist für künftige Projekte im Vorteil. Wenn diese Erfahrungen noch fehlen, hilft die Arbeit der Initiative IHE: Sie hat im Integrating-the-Healthcare-Enterprise-Standard IHE die grundlegenden Überlegungen zu definierten klinischen Abläufen, den beteiligten Systemen und Kommunikationsstandards sowie den entsprechenden Nachrichten, die ausgetauscht werden müssen, zusammengefasst. Der Standard kann für kommende Projekte genutzt werden.
Wie überall in der Medizintechnik, müssen aber auch regulatorische Anforderungen beachtet werden. Schon die präzise Definition der Anforderungen an Schnittstelle und gewählten Standard sind eine gewisse Herausforderung. Die gewählte und entworfene Lösung zu testen, ist dann eine weitere Hürde, die oft erst recht spät im Entwicklungsprozess erkannt wird. Insbesondere dann, wenn man prüfen muss, wie sich das System bei Fehlermeldungen und Timeouts des Kommunikationspartners verhält, stößt man beim Testen gegen andere Medizinprodukte sehr schnell an Grenzen. Der Aufbau einer hierfür geeigneten Testumgebung kann Kosten in derselben Größenordnung verursachen wie die Implementierung selbst.
Prüfen, was Toolkits bieten und wieviel man selbst wissen muss
Wer für die Implementierung am Markt erhältliche Toolkits einsetzen will, sollte nicht nur deren Funktionsumfang evaluieren. Weitere maßgebliche Punkte sind:
- Wie viel Kompetenz zum Kommunikationsstandard muss aufgebaut werden, um das Toolkit zu verwenden?
- Wie präzise ist die Behandlung von Fehlern?
- Gehört eine QM-Dokumentation zum Toolkit?
- Gibt es Mechanismen, die den Anwender zwingen, „es richtig zu machen“? Oder ist das Toolkit nur auf das Schreiben, Versenden, Empfangen und Lesen von Nachrichten ausgerichtet?
- Welche Unterstützung bietet das Toolkit bei kritischen Fehlern im Feld?
Kostenlose Open Source Toolkits sind verfügbar und meist von guter bis sehr guter Qualität. Wenn der Anwender aber viel Expertise aufbauen muss, um sie nutzen zu können, muss dieser Aufwand bei der Auswahl des Kits berücksichtigt werden. Zertifizierte Toolkits senken zudem den Aufwand beim Erstellen der QM-Dokumentation.
Insgesamt erscheint die Welt der Kommunikationsstandards zuweilen abschreckend – aber man kommt nicht mehr darum herum. Das KHZG verstärkt einen Trend, der sich seit langem abzeichnet: Relevante Informationen sollen überall verfügbar sein, wo sie gebraucht werden. Verfechter von Insellösungen sollten nicht hoffen, dass sich dieser Trend umkehren wird, wenn die bereitgestellte Fördersumme ausgegeben ist. Das Thema wird Gerätehersteller und die Medizinbranche mit steigender Intensität begleiten.
Dass das KHZG praktisch zeitgleich mit dem Geltungsbeginn der europäischen Medical Device Regulation, der MDR, gekommen ist, stellt die Hersteller vor große Herausforderungen. Doch kann es gelingen, auf diesem neuen, digitalen Feld einen Wettbewerbsvorteil zu erlangen, wenn man sich der Situation stellt. Dienstleister und Zulieferer können solche Vorhaben unterstützen.
Sind Systeme erst flächendeckend vernetzt, wird „Informationstiefe“ vermutlich der nächste Treiber sein. Sowohl die Mechanismen in den Standards als auch die Algorithmen in der KI warten nur darauf, mit Daten von Patienten gefüttert zu werden. In der Radiologie, die der Vorreiter im klinischen Datenaustausch ist, entsteht diese neue Realität schon heute.
Weitere Informationen
Die Softgate GmbH aus Erlangen ist ein Dienstleister für die Softwareentwicklung. Der Fokus liegt auf den Branchen Medizintechnik, produzierende Industrie und Informationsmanagement.
Die Standards im Überblick
Bei der Vernetzung von Medizingeräten stehen vor allem folgende Standards zur Verfügung:
- HL7 (www.hlz.org)
Health Level 7 könnte man als Allroundtalent für den Datenaustausch im Gesundheitswesen bezeichnen. Da er so flexibel ist und in verschiedenen Versionen existiert, bedeutet eine Entscheidung für eine HL7-Schnittstelle aber nicht, dass diese zu allen Anforderungen passt. Es kommt sehr auf die Definition der Schnittstelle und die Anforderungen des Gegenübers an. Der vor einigen Jahrzehnten definierte Standard wurde für eine peer-to-peer-Kommunikation ausgelegt. Der heute geforderten Anbindung zahlreicher mobiler Geräte wird das nicht gerecht. - Dicom (www.dicomstandard.org)
Bildgebende Systeme zum Beispiel in der Radiologie, Endoskope oder auch Kameras in der Dermatologie übertragen Daten über den Standard Digital Imaging and Communication in Medicine, kurz Dicom. Auch Messdaten lassen sich übertragen. Ob das sinnvoll ist, muss im Einzelfall entschieden werden. Wie HL7 ist Dicom für peer-to-peer-Kommunikation ausgelegt.
dicomstandard.org - IEEE 11073-SDC (ornet.org)
Der herstellerübergreifende Standard „Service-Oriented Device Connectivity“ (SDC) beschreibt den bidirektionalen Datentransfer zwischen einer Vielzahl von Medizingeräten. Die Dokumentation ist über HL7 vorgesehen. - FHIR (hl7.org/fhir/)
Der Fast-Healthcare-Integration-Resources-Standard, kurz FHIR, setzt auf eine moderne Technologie (Rest), ein Datenmodell aus einem Guss und eine hervorragende Dokumentation. Noch ist er die Ausnahme und schließt Lücken bei mobilen Anwendungen, die mit HL7 und Dicom nicht abgedeckt werden können.
Über die Kommunikationsstandards hinaus ist eine Grundlage geschaffen worden, um das Zusammenspiel der Geräte und Systeme im Krankenhaus zu beschreiben:
- IHE (www.ihe.net)
Der von der Initiative Integrating the Healthcare Enterprise (IHE) definierte Standard fasst die grundlegenden Überlegungen zu festgelegten klinischen Abläufen, den beteiligten Systemen und Kommunikationsstandards sowie den entsprechenden Nachrichten, die ausgetauscht werden müssen, zusammen. Er soll dazu dienen, Standards wie HL7 oder Dicom so zu nutzen, dass Krankenhäuser daraus den größtmöglichen Nutzen ziehen.
Kontakt zum Softwarehersteller:
Softgate Gmbh
Allee am Röthelheimpark 43
91052 Erlangen
Tel.: +49-(0)9131-812700
E-Mail: contact@soft-gate.de
Mehr zum Thema Digitalisierung in der Medizin
Big Data für die Medizin: Nicht China als Vorbild, sondern Dänemark
