AIS-Integration: ein weites Feld
Die Ärzte in den KVen nutzen laut KBV-Statistik noch immer 145 Arztinformationssysteme (AIS). Die Veränderungsraten sind gering. Die Zahl der Installationen des Marktführers CompuGroup (10 Einzelsysteme) ist zwischen Q3 & Q4/2020 um 300 zurückgegangen; der Markt-Zweite medatixx (5 Systeme) verzeichnete ein Minus von 48 Installationen – 0,86 bzw. 0,25%. Derweil legen ein paar kleinere Anbieter zu. Die Top-4 außerhalb der Psychotherapie – T2med, tomedo, Medical Office und SMARTY – konnten 272 Installationen hinzugewinnen. Das ist stattlich, kündigt aber keine radikalen Veränderungen an: Bei 77 der 145 Systeme hat sich die Zahl der Nutzer um höchstens 1 verändert. Es bleibt dabei: Ein AIS zu wechseln, ist mit großen Schmerzen für die Praxis verbunden. Eine Integration durch Marktkonsolidierung werden wir wohl nicht mehr erleben.
Das sind vordergründig schlechte Nachrichten für Anwendungen, die eine Integration benötigen. Zumindest dann, wenn man Maximalforderungen im Sinn hat. Die elektronische Patientenakte ist ein gutes (?!) Beispiel: Hier wird die Integration so gelebt, dass sämtliche AIS-Anbieter für jede einzelne Funktion – Notfalldatensatz, Medikationsplan, Arztbrief, Impfpass etc. – einen sicheren Export in die ePA des Patienten implementieren müssen, inklusive Frontend für die Suche, die Anzeige und die Administration. Das heißt zum Beispiel: Die Funktion „Medikationsplan in ePA exportieren“ wird in Deutschland 145-mal implementiert! Mit offensichtlichen Konsequenzen auf die Kosten dieser Systeme und auf die Innovationskraft der Systemhersteller. Denn statt sich eigene kreative Gedanken über neue Funktionen und einfachere Bedienung machen zu können, sind die Hersteller allein durch dieses ‚Integrationsvorhaben‘ auf Jahre hinaus blockiert.
Dabei ginge es auch anders: An vielen Stellen wäre Integration möglich, wenn die Hersteller einen Teil der in ihren Systemen gespeicherten Daten in einem einfachen Standard-Textformat (csv, XML, JSON) regelmäßig exportieren würden. Einen Teil etwa, den die Ärzte selbst bestimmen können, oder der sich aus gesetzlichen Pflicht- und ärztlichen Kür-Anteilen zusammensetzen könnte. Dann hätten Drittsystemanbieter die Chance, über alle Praxen hinweg originelle Integrationslösungen zu entwickeln, ohne dass die AIS-Hersteller dafür benötigt würden. Für diese Hersteller wäre das nicht einmal eine Einschränkung, denn sie könnten sich an dieser Entwicklung natürlich beteiligen, müssten es aber nicht. An einer solchen Lösung attraktiv ist natürlich, dass die Daten der Patientendokumentation für einen Austausch zur Verfügung stünden. Heute ist es so, dass die Daten in Systemen ‚gefangen‘ sind, die den AIS-Herstellern gehören. Damit sind ein Zugriff und eine Weiterverarbeitung in der Regel nur mit deren Zustimmung möglich.
Das Fallbeispiel TumorScout, initiiert von Dr. Felix Cornelius, entwickelt mit Ärzt:innen, illustriert eine Integrationslösung, die sich dieser Idee bedient.
TumorScout
Wer in Deutschland Krebspatienten behandelt, ist zur Meldung an das jeweilige Landeskrebsregister verpflichtet. Ein umgangssprachliches Beispiel für eine solche ärztliche Pflichtmeldung:
Ich [ärztliche Daten] habe am 23.10.2021 bei Patient X [alle Stamm- und Versicherungsdaten] eine Therapie mit dem Wirkstoff Leuprorelin begonnen, um die Erkrankung C61 zu behandeln, die am 16.01.2018 diagnostiziert wurde. Die Therapie hat eine palliative Intention und keinen Bezug zu einer operativen Therapie.“
Alle fett gedruckten Teile sind Pflicht, wenn der Beginn einer Arzneimitteltherapie gemeldet werden muss. Man darf auch noch mehr angeben, aber Wirkstoff, zugeordnete Diagnose usw. sind notwendig, um die Meldevergütung von 5 Euro zu erhalten und – in den Worten einer dem Autor bekannten Führungskraft eines deutschen Krebsregisters – keine Ordnungswidrigkeit zu begehen.
Fast alle der genannten Daten liegen in den AIS-Datenbanken bereits vor. Im Beispiel gilt das nahezu sicher für alle Angaben außer den zwei letztgenannten (palliativ bzw. ohne Bezug). Denkbar ist, dass die Datumsangaben aus dem AIS nicht ganz genau sind. Dort steht bspw. das Datum der AM-Verordnung, aber nicht der Tag der ersten Gabe/Einnahme. Sinnvoll ist also eine Kombination: Nutzung der AIS-Daten, so weit wie möglich, und darauf aufbauende Zusatzinformationen, so weit nötig.
Die Struktur, in der die Originaldaten im AIS gespeichert sind, ist individuell. Ebenso sind die Regeln der 15 deutschen Krebsregister individuell und weichen zum Teil stark voneinander ab. Wenn jeder AIS-Hersteller die Regeln jedes AIS lernen müsste, wären das 145*15= 2.175 Lern- und Entwicklungsschritte. …für ein paar Tausend onkologisch tätige Ärzte. Allein diese Betrachtung zeigt, dass eine eigene Entwicklung sinnvoll ist, die die Anforderungen jedes Krebsregisters verstehen und die Export-Formate aller AIS interpretieren kann, und die sich auf die Nische des Krebsregisterprozesses spezialisiert – zur Erleichterung und Beschleunigung dieser Aufgabe für die Ärzte.
TumorScout verfolgt diesen Weg, auch wenn dieser noch steinig ist, weil es einen solchen einfachen Export bislang nur bei wenigen der 145 Anbieter gibt. Die Integration der AIS funktioniert so: Wer TumorScout nutzt, wählt sich online in das System ein (Software as a Service) und lädt dann eine einfach strukturierte und sicher verschlüsselte Textdatei hoch, in der alle Angaben aus dem eigenen AIS stehen, die für eine Krebsregistermeldung bedeutend sein könnte. Zunächst sind das alle Stammdaten, Diagnosen, Arzneimittel, Arztbesuche, Laborwerte und Abrechnungsziffern – für alle Krebspatienten.* Sobald diese Informationen bei TumorScout liegen, kann das System die Praxis bei der Erstellung der richtigen Meldedokumente unterstützen. So können Datumsangaben einfach korrigiert, Aussagen bspw. zur Intention einer Therapie hinzugefügt und vollständige Meldungen durch Angabe weniger Mindestangaben erzeugt werden.
Damit das funktioniert, muss auf Seiten der AIS-Hersteller lediglich eine täglich wiederholte Datenbankabfrage implementiert werden, um die oben mit einem Stern markierten Angaben zu extrahieren. In welchem Format dieser Export erfolgt, ist unbedeutend, denn es ist für die tumorscout und jeden anderen Entwickler vergleichbarer Integrationslösungen nicht schwierig, die Formate zu verstehen und die Inhalte strukturiert zu importieren. Umgekehrt ist es ebenso: Für die AIS-Hersteller wäre es einfach, einen solchen Export zu implementieren. Eine Person mit Kenntnis über die Datenbankstruktur des AIS benötigt dafür nicht mehr als 2-3 Tage.
TumorScout unterstützt alle Anbieter, die solche Exporte bereitstellen.
Was ist mit dem Import?
Der gewählten Darstellung könnte man beim Beispiel eGK entgegenhalten, dass die AIS-Hersteller nicht nur verpflichtet werden müssen, die eigenen Daten zu exportieren, sondern auch die sonstigen Daten zu importieren und anzuzeigen. Dem ist entgegenzuhalten: (1) Die Nutzung der eGK ist sowohl für Ärzte als auch für Patienten freiwillig. Ein Arzt, der sich aktiv für die Nutzung der eGK entscheidet, wird auch kein Problem haben, ein separates Drittsystem zu nutzen – vor allem, wenn es von einem Anbieter entwickelt wurde, der sich auf genau diese Funktionalität spezialisiert hat und womöglich eine schönere, einfachere, praktischere Lösung implementiert hat. (2) Jeder AIS-Hersteller hätte natürlich das Recht, einen solchen Import zu implementieren. Die Ergebnisse dürften weit besser sein, als wenn sie dazu verpflichtet werden. Mit TumorScout ist das im Übrigen ähnlich: Es handelt sich um ein separates System, das im Browser läuft. Es gibt auch integrierte Lösungen, bspw. im AIS Quincy. Dem Autor sind Ärzte bekannt, die Quincy nutzen und die dort vorhandene Lösung vorziehen, und es gibt Ärzte, die lieber TumorScout verwenden – als eigenes System neben ihrem AIS.
Weitere Potentiale
Das oben erwähnte Beispiel der eGK liefert viele Anwendungsbeispiele, die sich in vergleichbarer Weise umsetzen ließen. In ihrer Version 3.0 sollen zum Beispiel auch Laborwerte in die ePA übertragen werden. Warum erst dann – frühestens Anfang 2023? Was ist daran so kompliziert? Die naheliegende Vermutung: Das ist nicht kompliziert, aber die AIS-Hersteller haben vorher keine Zeit. Sie entwickeln das nicht, weil sie sich vom Wettbewerb absetzen können, sondern weil sie von Politik und KBV dazu verpflichtet werden.
Würden die Laborwerte aller Patienten in einem einfach strukturierten Textdokument auf einem Rechner in der Praxis abgelegt, könnten Drittanbieter über alle AIS hinweg Lösungen zum Management von Laborwerten entwickeln. Das wäre auch deshalb eine gute Idee, weil Laborwerte untereinander oft nur bedingt vergleichbar sind. Der PSA-Wert ist bspw. häufig an das Gerät und die gewählte Labordiagnostik gebunden, weshalb in der Bezeichnung des Laborwerts neben dem Kürzel PSA häufig auch noch ein Hinweis auf den Hersteller des Geräts zu finden ist. Auch Einheiten unterscheiden sich teilweise. Ein Hersteller, der sich auf die Integration von Laborwerten spezialisieren würde, könnte Einheitswerte schaffen und Umrechnungstabellen führen. Ein einzelner AIS-Hersteller wird das in der Regel weder wollen noch können, denn das erfordert eine sehr spezielle Kenntnis, die außerhalb des Kerngeschäfts der Hersteller ist.
So, wie die Integration bislang von Seiten der Gematik und des BMG verstanden wird, bleiben derartige Potenziale ungenutzt – sowohl inhaltliche, gestalterische, als auch ökonomische, wettbewerbliche, innovationsförderliche Potenziale! Das Beispiel TumorScout zeigt im Einzelfall, dass es auch anders geht.
Zur Magazin-Übersicht