Was sind typische Szenarien, in denen im klinischen Alltag Interoperabilität zwischen medizintechnischen Geräten untereinander beziehungsweise zwischen Medizintechnik und klinischen IT-Systemen wünschenswert oder erforderlich ist?
Sylvia Thun: In Berlin versuchen wir zum Beispiel derzeit, Geräte der Intensivmedizin in unser Patientendatenmanagementsystem (PDMS) zu integrieren. Das ist in einigen Bereichen schier unmöglich, weil insbesondere die Anbieter kleinerer, spezialisierter Systeme nicht die Standards bieten, die wir brauchen, um die Geräte anzubinden. Die Gerätehersteller haben zumindest teilweise Lösungen, die die Daten zugänglich machen. Aber das heißt nicht, dass wir sie auch unkompliziert ins PDMS oder auch ins Klinikinformationssystem (KIS) bekommen. Das ist schon sehr mühsam.
Sven Zenker: Prinzipiell sehe ich drei Hauptszenarien. Wenn wir medizintechnische Geräte als Datenquelle für medizinische Dokumentationszwecke betrachten, dann gibt es technische Integrationsanforderungen in Richtung IT. Das zweite Szenario ist das Alarmmanagement, inklusive auch komplexerer Entscheidungsunterstützungsszenarien („Clinical Decision Support“), die sowohl auf der Input- als auch auf der Output-Seite, d. h. bezüglich Datenquellen und bezüglich der Endstrecke der Alarme, medizintechnische und informationstechnische Systeme involvieren können. Dabei geht es nicht nur um Dokumentation, sondern die Daten müssen „actionable“ sein. Das erste Szenario ist lösbar mit herstellerspezifischen Integrationsschichten, die in Beschaffung und Betrieb sehr aufwendig sein können. Das zweite Szenario ist ambitionierter, es erfordert Stand heute hausspezifisches Risikomanagement, Latenzgarantien und Garantien der Übertragungssicherheit, die mit heute verfügbaren Technologien und Produkten, gerade in Systemlandschaften mit Komponenten von unterschiedlichen Herstellern, oft kaum realisierbar sind. Das dritte Thema schließlich, das wir bisher lediglich konzeptionell, aber noch nicht im Doing angehen konnten, sind Fernsteuerungsszenarien. Dafür tragen die regulatorische Umgebung und auch die tatsächlich am Markt umgesetzten Interoperabilitätsstandards und zugehörigen Spezifikationen meiner Auffassung nach noch nicht weit genug. Es gibt hier aber eindeutig einen klinischen Bedarf. Das gilt auch für die Alarm-Weiterleitung, wo wir in Bonn schon wichtige Use Cases hatten, die wir nicht bauen konnten.
Was bedeutet die suboptimale Interoperabilität für die klinisch tätigen Berufe?
Sven Zenker: Es gibt da teils absurde Szenarien. Wir haben zum Beispiel eine reine IT-zu-IT-Schnittstelle im Kontext präoperativer Evaluation, wo patientensicherheitskritische Befunde und Handlungsempfehlungen der Anästhesist:innen vom PDMS beziwhungsweise Anästhesie-Informations-Management-System (AIMS), einem Klasse-IIa-Medizinprodukt, ins übergeordnete KIS transferiert werden müssen. Das geht technisch über eine übliche Kombination aus HL7v2 und einer herstellerspezifischen XML-Schnittstelle. Aber wir haben keine Signalwegsüberwachung, keine Vollständigkeitsgarantien, keine Latenzgarantien, nichts. Deswegen sitzen da die Anästhesist:innen mit zwei Bildschirmen und bestätigen aktiv im KIS, dass das, was dort angekommen ist, das ist, was gemeint war. Ein anderes Beispiel ist die Point-of-Care-Analytik. Die ist unmittelbar „actionable“, denken Sie an die Einstellung eines Beatmungsgeräts oder die Dosisänderungen bei einem Kalium- oder Insulinperfusor. Weil die Informationen aus dem Analysegerät über mehrere IT-Schnittstellen in das Zielsystem gelangen, das für ärztliche Entscheidungen genutzt wird, und weil es keine Garantien für Vollständigkeit, Richtigkeit und korrekte Zuordnung zu Patient:innen gibt, sehen wir uns aus Gründen des Risikomanagements gezwungen, die Pflegekraft, die das Blut gewonnen und die Analytik durchgeführt hat, zu bitten, im Zielsystem die Werte noch einmal zu kontrollieren und einen Haken zu setzen. Nur dann übernimmt ein Mensch die Verantwortung für die Richtigkeit, und es können kritische klinische Entscheidungen auf Grundlage der überprüften Daten im Zielsystem getroffen werden. In praxi haben sicherlich nicht alle Krankenhäuser diese Risikomanagement-Themen in gleicher Weise bereits in ihre Prozess- und Technologielandschaft integriert.
Björn Andersen: Und das sind jetzt schon vergleichsweise technische Lösungen. Es gibt auch noch reihenweise Einrichtungen, in denen in der Regel Pflegekräfte die Daten händisch von einem IT-System ins andere übertragen. Es geht also durchaus noch schlimmer.
Ist das vor allem ein Problem der großen Häuser und Unikliniken?
Martin Kasparick: Diese Fragen werden grundsätzlich gestellt, da unterscheidet sich das Uniklinikum kaum vom kleineren Klinikum. Allenfalls denken die Unikliniken dann noch weiter, zum Beispiel Richtung Datennutzung für Forschungszwecke. Ein Klassiker ist bei den Patientendaten das Gewicht: An verschiedensten Medizintechnikgeräten muss das Gewicht immer wieder neu eingegeben werden. Wenn sich da einer vertippt, kann das zu Fehldosierungen führen. Wir reden also wirklich von risikobehafteten Konstellationen – die eigentlich sehr einfach auflösbar sein sollten.
Sven Zenker: Gewicht ist ja gerade in der Pädiatrie und Neonatologie ein kritisches Thema. Dort gibt es erste – allerdings noch nicht vollständig standardbasierte und interoperable – Lösungen von unterschiedlichen Herstellern, insbesondere Pumpenherstellern. Eine solche haben wir am UKB in unseren IT-Systemen integriert und flächendeckend im akutmedizinisch-pädiatrischen Bereich, inklusive Kinderanästhesie, ausgerollt. Die übergreifende Patientenidentifikation und Übertragung der patientenspezifischen Informationen zwischen IT-System und Pumpe – insbesondere des Körpergewichts, sodass Dosislaufraten am Gerät angezeigt werden können, was eine wichtige Voraussetzung für die Standardisierung der Zubereitung parenteraler Medikamente insbesondere in der Neonatologie ist – geschieht dort über einen QR-Code. Etablierung und Wartung erfordern Stand heute erhebliche betreiberseitige Spezialkompetenz und entsprechenden Ressourceneinsatz, aber es ist ein gutes Beispiel für eine (leider nicht standardbasierte) Interoperabilitätslösung, die unmittelbar helfen kann. Es braucht nicht immer die ambitionierte, netzwerkbasierte Schnittstelle; Barcode-basierte Lösungen haben in bestimmten, praxisrelevanten Szenarien sogar deutliche Vorteile. Es wäre natürlich toll, wenn so etwas auch vollständig interoperabel ginge.
Björn Andersen: Die Beispiele von Sven Zenker zeigen, dass wir bei Interoperabilität nicht nur über technische Schnittstellen, sondern auch über die Übernahme von Verantwortung reden. Wenn vernetzte Lösungen proprietär sind, dann sind sie oft gemeinsam als Gesamtsystem zugelassen. Aber genau davon wollen wir wegkommen, denn das schränkt die Krankenhäuser in der Auswahl ihrer Geräte stark ein. Man wählt dann nicht mehr das Gerät, das am besten zum Anwendungsfall passt, sondern das, das am besten zu den Bestandssystemen passt, Stichwort Vendor-Lock-in. Das ist genau einer der Punkte, an denen wir mit dem nichtproprietären Übertragungsstandard SDC ansetzen.
Sylvia Thun: Ich kann das nur unterstreichen: Das ist nicht nur ein Thema mit Altgeräten, sondern beschäftigt uns auch bei den Neuanschaffungen. Wir schaffen es bisher noch nicht, dass die Hersteller das liefern, was wir in in den Anforderungskatalogen an Schnittstellen fordern. Wir wissen, wo die Reise hingeht, Stichworte SDC, FHIR. Aber es ist immer noch schwierig mit den meisten Herstellern, das sehen wir in unserer Testumgebung, die wir hier an der Charité aufgebaut haben. Es reicht auch nicht aus, wenn es der Medizingerätehersteller kann. Die IT-Systeme haben teilweise gar keine Datenfelder für die Daten, die von den Geräten kommen. Meiner Meinung nach brauchen wir irgendeine Art von Qualitätssiegel, das Kompatibilität mit internationalen Standards zertifiziert und validiert – nicht nur Kompatibilität mit proprietären deutschen Vorgaben.
Die Stichworte SDC und FHIR sind gefallen. Rekapitulieren wir vielleicht an dieser Stelle noch einmal kurz die letzten Jahre. SDC ist aus dem deutschen Förderprojekt OR.NET heraus entstanden. Wie kam das, und was genau ist dieses SDC eigentlich?
Martin Kasparick: Der Fokus im OR.NET-Projekt (2012 bis 2016; die Redaktion) war es, Geräte im OP-Saal zu vernetzen – was sich eins zu eins in Richtung Geräte auf Intensivstationen ausweiten lässt. Das OR.NET-Projekt wollte die Geräte-zu-Geräte-Kommunikation erstmals über Herstellergrenzen hinweg ermöglichen. Das war damals Neuland. Die Familie der ISO/IEEE-11073-Standards gab es zwar schon, aber die hatte den Fokus auf Personal Health Devices gelegt. Für komplexe Medizingeräte wie Beatmungsgeräte, Infusionspumpen etc. gab es keine herstellerübergreifenden Standards. Aus diesem großen Projekt mit rund fünfzig geförderten und rund vierzig weiteren, assoziierten Partnern entstand die Initialzündung für die Normenfamilie IEEE 11073 SDC. Die Kernnormen wurden 2018 von der IEEE und inzwischen auch von der ISO verabschiedet. Dadurch, dass es so ein großes Konsortium war, konnten wir die gesamte Anforderungsbreite, die an eine solche Normenfamilie zu stellen ist, abbilden.
Björn Andersen: Durch die zahlreichen Partner wurde es natürlich auch sehr mühsam und komplex. Aber es war ein Erfolg, die ersten drei auch als Kernnormen von SDC bezeichneten Standards, die sich mit Übertragungstechnologie, Informations- und Service-Modell sowie Architektur- und Protokollstandards beschäftigen, reflektieren das. Unser Ziel bleibt es aber, einen Standard zu entwickeln, der nicht nur technische Interoperabilität gewährleistet, sondern der vor allem klar die Verantwortlichkeiten der einzelnen an der jeweiligen Systemfunktion beteiligten Geräte definiert. Die Frage, die uns seit OR.NET sehr stark beschäftigt hat, ist die von Verantwortung und Vertrauen: Wie schaffen wir es, dass ein Netzwerkgerät einem anderen, unbekannten Teilnehmer ausreichend vertraut, um mit ihm zusammen eine klinische Funktion auszuführen? Das Zweite, woran wir innerhalb des aus dem Förderprojekt hervorgegangenen OR.NET e. V. intensiv gearbeitet haben, sind partikuläre Interoperabilitätsstandards. Wir glauben, dass neben Standards für die Herstellung des Vertrauens noch weitere Standards auf Geräteebene nötig sind, wenn wir erreichen wollen, dass Geräte irgendwann wirklich austauschbar sind.
Martin Kasparick: Von der Geräte-zu-Geräte-Kommunikation abzugrenzen ist die Kommunikation von Geräten zu IT-Systemen und von IT-Systemen untereinander. Die ist explizit nicht Teil von SDC. Das Schöne war, dass relativ parallel zu SDC der FHIR-Standard entwickelt wurde, der in der Denke dem, was für die Geräte-zu-Geräte-Kommunikation entwickelt wurde, ähnelt. Diese beiden Standards konkurrieren nicht miteinander, sondern sie ergänzen sich sehr gut. Neben technischen Gründen mag dies auch daran liegen, dass es eine recht hohe personelle Überdeckung zwischen den jeweiligen Expert:innen gab und gibt.
Sven Zenker: Was ich beim Thema SDC als Dammbruch wahrgenommen habe, ist, dass hier erstmalig ein herstellerübergreifender, interoperabler Standard so aufgestellt wurde, dass er belastbare Kommunikation mit Garantien für die Signalübertragung ermöglicht, wie wir sie innerhalb der proprietären Herstellerwelt, zum Beispiel beim Aufbau von Monitoringanlagen in der Intensivmedizin, schon immer hatten. Das ging vorher über Herstellergrenzen hinweg nur in sehr eingeschränkten Szenarien. Das sollte jetzt natürlich auch dann zur Verfügung stehen, wenn wir über die IT-Schnittstellen reden. Mein Rat an die Medizintechnik-Welt wäre, nicht zu tief in die strukturierte Repräsentation medizinischer Sachverhalte einzusteigen. Denn das wird in der FHIR-Community ja intensiv bearbeitet. Wenn ich mir etwas wünschen dürfte, dann wäre das ein Standard, der eine Verknüpfung der medizinischen, in FHIR repräsentierten Daten mit den Signalwegsgarantien der SDC-Welt ermöglicht. Das würde sehr viele sehr reale Probleme lösen.
Braucht es denn wirklich beides, SDC und FHIR?
Sylvia Thun: Wir haben an der Charité einen Kooperationsvertrag mit dem Unternehmen Dräger hinsichtlich der Entwicklung der FHIR-Schnittstelle und des Mappings von SDC auf FHIR. Grundsätzlich lässt sich sehr viel sowohl in FHIR als auch in SDC ausdrücken. Eine Option ist, quasi hinten raus, im Datenintegrationszentrum, auf FHIR zu mappen, die andere , bessere Option ist ein Mapping direkt vorne am Geräteausgang. Wünschen würde ich mir, dass auch die Alarme mit übertragen werden. Das sollte meines Erachtens in FHIR abbildbar sein, aber das scheint nicht so einfach zu sein. Wir haben uns die FHIR-Ressourcen der Gerätehersteller angeschaut, die sind stabil und gut. Vieles ist aber noch nicht normativ. FHIR Release 5 steht vor der Tür, da müssen die Hersteller dranbleiben und dürfen sich nicht ausruhen. Grundsätzlich gibt es bei HL7 eine ganze Gruppe von Medical-Device-Experten, die seit Jahren Standards aus der IEEE- 11073-Familie in FHIR überführen. Das geht, und so sehe ich das Prozedere auch bei SDC. Wenn was fehlt, sollte man es dann allerdings primär in FHIR nachziehen. Hier muss die deutsche Industrie mitarbeiten.
Björn Andersen: Wir versuchen letztlich immer, einen sinnvollen Trade-off zu finden: Wie viel lohnt es sich, Richtung FHIR weiterzuleiten, für wie viel interessieren sich die IT-Systeme? Bei den Alarmen wird das funktionieren, entsprechende FHIR-Ressourcen gibt es im Entwurfsstadium. Aber die Mechanismen drum herum, das sichere Zustellen an den entsprechenden Kommunikator, der dann den Menschen alarmiert, das ist in FHIR sehr viel schwieriger zu lösen. Auch deswegen brauchen wir sowohl FHIR als auch SDC. Der Fokus von FHIR liegt eher auf der Übermittlung in IT-Systeme und nicht so sehr auf die Interaktion für gemeinsame klinische Funktionalitäten, die eine hohe Synchronität erfordern. SDC hat dagegen nicht den Anspruch, alles so aufzubereiten, dass ein IT-System damit optimal umgehen kann.
Martin Kasparick: Die Standards, die für die IT-zu-IT-Kommunikation genutzt werden, haben die von Herrn Zenker angesprochenen Bestätigungen und Latenzversprechen nicht an Bord. SDC ist genau dafür entwickelt worden. Deswegen brauchen wir dieses Nebeneinander: Das am Point-of-Care befindliche Alarmverteilungssystem nutzt SDC, die saubere Dokumentation und die Weiternutzung dieser Information in IT-Systemen geht dann über FHIR. Das passt wunderbar zusammen, auch wenn die beiden Standards auf semantischer Ebene erst mal sehr überschneidend wirken.
Vielleicht noch mal ganz konkret: Inwieweit machen es solche Standards jetzt einfacher, das Problem der regulatorischen Anforderungen in Multi-Vendor-Umgebungen zu erfüllen? Wie kommen wir von den Standards zu einem rechtssicheren System?
Martin Kasparick: Stand heute werden zwei Geräte, die etwas gemeinsam tun sollen, als Verbund in Verkehr gebracht und gemeinsam risikobewertet. Wenn ein Krankenhaus zwei Geräte zusammenbringen will, die nicht zusammen zugelassen sind, oder sie um eigene Funktionen ergänzt, wird es rechtlich gesehen zu einem Hersteller. Wir sind angetreten, genau das zu ändern. Innerhalb von SDC gibt es dafür die sogenannten Participant Key Purpose Standards, die ganz klar festlegen, welche Verantwortung zum Beispiel ein alarmerzeugendes Gerät hat, das an einem Alarmverteilungssystem teilnehmen möchte. Genauso wird klar definiert, was die Anforderungen an Geräte sind, die Alarme konsumieren. Die Verantwortung des Krankenhauses besteht nur noch darin, ein geeignetes Kommunikationssystem zur Verfügung zu stellen. Und damit das Krankenhaus das kann, gibt es wiederum als Teil der Standards sogenannte Documentation Requirements. Auf deren Basis definieren die Hersteller für ihre unterschiedlichen Geräte die Anforderungen an das Netzwerk und an die Prozesse im Krankenhaus. Einfach gesagt: Die Risiken, die vorher zusammen als System abgedeckt wurden, werden jetzt einzeln abgedeckt. Damit das funktioniert, müssen die Hersteller Tests in geeigneten Referenzumgebungen durchführen. Das ist die neue Welt, in der Medizingeräte sich treffen und sicher miteinander kommunizieren.
Björn Andersen: Klar ist, dass es natürlich erst einmal ein gewisser Aufwand ist, entsprechende Produkte zu entwickeln. Warum lohnt es sich trotzdem? Weil damit Dinge möglich werden, die bisher nicht gingen. Weil Aufwände an anderer Stelle vereinfacht werden. Weil niemand mehr mit neuen Gerätekombinationen zur Zulassungsbehörde laufen muss. Das Zusammenarbeiten mit unbekannten Geräten in klar festgelegten Szenarien und Rollen wird Teil der Zweckbestimmung des Geräts.
Sven Zenker: Aus meiner Sicht ist das ein Schritt in die richtige Richtung. Die Notwendigkeit ist klar. Aber jetzt wird man in partnerschaftlicher Zusammenarbeit zwischen Anbietern diese Dinge erst einmal realisieren müssen. Es ist ja längst nicht so, dass sich jeder Hersteller schon zu offenen Standards verpflichtet hätte – jenseits von HL7v2 und einem Lippenbekenntnis zu FHIR. Solange das nicht passiert, können wir auch nichts pilotieren, und erst beim Pilotieren werden wir herausfinden, was es real bedeutet, solche komplexen Systemlandschaften aufzubauen und zu betreiben. Ich denke, es sollten sich alle darüber im Klaren sein, dass noch eine steile gemeinsame Lernkurve zu bewältigen ist.
Sylvia Thun: Mal ganz ehrlich, Hosen runter: Gibt es schon irgendeinen Hersteller, der das wirklich annimmt, insbesondere auch in den USA? Ist schon irgendwas implementiert, außerhalb der Charité?
Björn Andersen: Anwenderseitig und seitens der regulatorischen Behörden sind die USA ausgesprochen interessiert. Bei den Anbietern ist das Interesse noch zurückhaltender, aber es gibt da Bewegung. Der Fokus liegt derzeit auf dem europäischen Kontinent, da aber auch wirklich über Grenzen hinweg. Neben Dräger sind weitere europäische Hersteller gerade sehr aktiv und bringen viele Verbesserungen ein. Auch der OR.NET e.V. wird internationaler. Ja, die Sache kam aus dem deutschen Bereich, und viel Arbeit wird aus Deutschland heraus geleistet. Aber das Thema hat ganz klar einen internationalen Drive.
Martin Kasparick: Durch die Normierungsarbeiten und vor allem die Teilnahme an den sogenannten Plug-a-thon Veranstaltungen, bei denen die Interoperabilität verschiedener Implementierungen von SDC gegeneinander getestet werden, ist bekannt, dass diverse Hersteller sehr intensiv an Produkten mit einer SDC-Vernetzung arbeiten. Ich denke, dass ich nicht zu viel verspreche, wenn ich sage, dass Betreiber, Anwender und Patienten sehr gespannt darauf sein dürfen, was in diesem Jahr auf einigen Messen gezeigt werden wird. Am Markt verfügbare Produkte werden entsprechend folgen. Dräger hat es auch bereits gezeigt, mit in den Verkehr gebrachten Produkten, die auf dem SDC-Standard basieren.
Welche Möglichkeiten gäbe es, diesen herstellerseitigen Akzeptanzprozess noch etwas zu beschleunigen?
Sven Zenker: Da kommt natürlich den Kunden eine wichtige Rolle zu. Legitime kommerzielle Interessen sind nicht notwendigerweise deckungsgleich mit den Interessen der Kundenseite, und damit eben auch der Solidargemeinschaft im Gesundheitssystem. Mit der Schaffung von Interoperabilität bei proprietären Lösungen verdienen einige Hersteller gutes Geld. Ich denke, es wird sich nur dann etwas bewegen, wenn von Nachfrageseite immer wieder sehr explizit gefordert wird, solche einen Vendor-Lock-in zumindest einhegende, offene Standards zu unterstützen. Ein einfacher Weg im öffentlichen Sektor ist Ausgestaltung von Ausschreibungen. Damit lassen sich Entwicklungspipelines der Hersteller und Priorisierungen schon beeinflussen. Zumindest in der Universitätsmedizin arbeiten wir daran, bei den Ausschreibungen ein bezüglich dieser Themen etwas stärker abgestimmtes Vorgehen hinzubekommen, sodass im gemeinsamen Interesse bestimmte Mindeststandards gefordert werden. Dass es auch regulatorisch gewisse Hebel gibt, zeigt in einem anderen Bereich der branchenspezifische KRITIS- Sicherheitsstandard.
Sylvia Thun: Ich denke auch, dass es regulatorische Hebel gibt. Am Ende hat das, was wir hier diskutieren, mit Patientensicherheit und Patientenschutz zu tun. Von daher kann der Gesetzgeber eingreifen. Indirekt zielt unsere Arbeit im Interop Council ja genau in diese Richtung: Wir empfehlen Standards, diese Empfehlungen gehen ans Bundesministerium für Gesundheit (BMG). Das BMG gibt das dann zu einem Zeitpunkt X regulatorisch vor, und dann wird darauf im SGB V verwiesen. Bei den Krankenhaus-IT-Standards ISiK ist das so ähnlich passiert, da läuft im Sommer 2024 die Übergangsphase für die Basisstufe ab und die Krankenhäuser müssen das ab dann umsetzen. Bei ISiK steht nun explizit FHIR fest, was hervorragend ist. In Gesetzen sollten zuständige Organisationen benannt werden, die sich um interoperable Standards kümmern müssen, und keine Technologien. Die können sich mit den Jahren weiterentwickeln.
Hat denn das Interop Council die Medizintechnik und deren Standards schon auf dem Schirm?
Sylvia Thun: Das Thema Medizintechnik ist prinzipiell auf der Roadmap, allerdings bisher nur punktuell. Im nächsten Jahr beispielsweise die GDT-Schnittstelle, die in FHIR abgebildet werden könnte. Die ist unter anderem für Blutzuckergeräte wichtig, die Daten in elektronische Patientenakten transferieren sollen. Das könnte zum Beispiel ein FHIR-basierter ISO/IEEE-11073-Standard werden, aber ich will nicht vorgreifen. In der DiGA-Verordnung taucht ISO/IEEE 11073 übrigens auch noch bei den digitalen Gesundheitsanwendungen (DiGA) auf, die darüber mit Medizingeräten kommunizieren sollen. Das ist nur rudimentär implementiert worden.
Björn Andersen: Man sollte dazu vielleicht noch ergänzen, dass es nicht ganz einfach ist, einen Standard wie SDC regulatorisch zu fordern. Auf IT-Schnittstellen, die unterschiedliche Akteure des Gesundheitswesens verbinden und die vielleicht sogar noch erlösrelevant sind, hat der Gesetzgeber unmittelbaren Zugriff. Das ist bei Gerätestandards etwas schwieriger. Die Betreiber dazu zu bewegen, entsprechende Forderungen zu stellen bzw. Ausschreibungen entsprechend zu gestalten, halte ich für wichtiger.
Martin Kasparick: Eine Frage in Richtung Sven Zenker und Sylvia Thun. Würde es den Betreibern, also den Krankenhäusern, helfen, wenn es Fördermittel gäbe, die Pilotimplementierungen finanzieren? Oder wäre das zu viel bürokratischer Aufwand?
Sven Zenker: Ich sehe durchaus noch einige Herausforderungen auf dem Weg zu einer funktionierenden, interoperablen Welt. Ein wichtiger Weg, die Lösung solcher Herausforderungen gemeinsam voranzubringen, sind funktionierende Pilotprojekte, die einen gewissen Leuchtturmcharakter haben. Letztlich müssen wir prüfen, ob der Mehraufwand, den die Umsetzung offener Standards bedeutet, durch das, was wir erreichen, rechtfertigbar ist. Das geht nur empirisch, und natürlich hilft es in solchen Vorhaben, wenn die Aufwände gegenfinanziert sind. Auch Universitätsklinika haben nicht beliebig viele freie Ressourcen, um solche Innovationen voranzutreiben. Wer für eine mögliche Finanzierung einstehen könnte, vermag ich nicht einzuschätzen, ich würde es aber als hilfreich ansehen.
Sylvia Thun: Eine andere Option wäre, mit Incentives zu arbeiten. Allerdings haben wir beim Krankenhauszukunftsgesetz (KHZG) gesehen, dass das fürchterlich kompliziert sein kann. Über die KHZG-Förderung sollten ja theoretisch auch die FHIR-Standards quasi ins System kommen, das tun sie aber nur selten, da KIS-Hersteller noch kein FHIR liefern. Es bräuchte zusätzlich eine Art validierende Instanz, die wir bei der gematik einrichten könnten, um zu überprüfen, ob die Standards auch richtig genutzt werden.
Brauchen wir noch Modellprojekte bei SDC, oder brauchen wir keine mehr?
Sylvia Thun: Wir sind da auf der Kante. Eigentlich könnten wir schon implementieren, aber es macht natürlich trotzdem Sinn, vorher noch mal alles auszutesten, bevor es in den Alltagsbetrieb geht. Entscheidend ist: Wir müssen da weiterkommen. Ich kriege immer wieder fürchterliche Angst, wenn ich mir vorstelle, welche Daten in welcher Qualität versendet und dann für medizinische Entscheidungen herangezogen werden. Standards verbessern die Patientensicherheit, sie retten Leben. Das gilt für IT-Standards, und es gilt für Standards auf der Geräteebene.
Die Gesprächsrunde moderierte Philipp Grätzel von Grätz, Chefredakteur E-HEALTH-COM.
Zu den Gesprächsteilnehmer:innen
Prof. Dr. med. Sylvia Thun, Direktorin Core Facility Digitale Medizin und Interoperabilität am Berlin Institute of Health (BIH) der Charité Universitätsmedizin Berlin; Leiterin Interop Council der gematik; Stellvertretende Vorsitzende HL7 Deutschland
PD Dr. med. Sven Zenker, Ärztlicher Leiter Stabsstelle Medizinisch-Wissenschaftliche Technologieentwicklung und -koordination (MWTek) am Universitätsklinikum Bonn
M.Sc. Björn Andersen, Systemarchitekt Dräger, Vorstandsmitglied e.V.
Dr.-Ing. Martin Kasparick, Systemarchitekt Interoperabilität B. Braun Gruppe; Vorsitzender Subarbeitsgruppe SDC der Point of Care Device Working Group bei der IEEE