Kurzer Rückblick: Was war die Rolle der AOK PLUS im ARMIN-Projekt?
Der Gesetzgeber hatte mit dem § 64a SGB V damals einen Paragrafen zum Thema Modellprojekte für Medikationsmanagement eingeführt, das lief damals unter dem Arbeitstitel ABDA-KBV-Modell. Es fand sich aber kein Bundesland, das ein entsprechendes Modellprojekt initiiert hätte. Da ist die AOK PLUS dann in die Bresche gesprungen. Da die Krankenkasse in Sachsen und Thüringen einen hohen Anteil der GKV-Versicherten abdeckt und es dort eine gute Zusammenarbeit mit KVen und Apothekerverbänden gibt, wurde entschieden, ein Modellprojekt zu starten. Das war dann allerdings kein Modellprojekt nach § 64a, sondern ein freiwilliges GKV-Modellprojekt nach § 63 SGB V.
ARMIN war medizinisch ein Erfolg. Warum wurde trotzdem entschieden, es nicht fortzuführen?
Wir hatten von Anfang an das Ziel, ein elektronisches Medikationsmanagement aufzubauen, mit einer Single-Source-of-Trust, also einem gemeinsam von Arztpraxen und Apotheken gepflegten Medikationsplan, der auch versorgungsrelevante Fachfunktionalitäten anbietet. Wir glauben, dass das jetzt im Rahmen der Telematikinfrastruktur breit aufgesetzt werden sollte und dass es nicht zielführend ist, aus ARMIN einen IV-Vertrag zu machen.
Während der Projektphase von ARMIN wurde 2016 der Bundeseinheitliche Medikationsplan (BMP) mit der Medikationsliste als Barcode eingeführt, 2019 dann der eMP, letztlich ein BMP auf der eGK. Wie unterschied sich das, was Sie bei ARMIN gemacht haben, von diesen Initiativen?
Wir haben einen serverbasierten Medikationsplan aufgebaut, zunächst im damaligen „Sicheren Netz der Kassenärztlichen Vereinigungen“, später im Rahmen der Telematikinfrastruktur. Das erlaubte es unter anderem, den Kreis der Zugriffsberechtigten so weit zu fassen, wie nötig. Bei uns konnte zum Beispiel eine Nachtschwester im Pflegeheim zugreifen, was mit der eGK bis heute nicht gehen würde. Der zweite Unterschied bestand darin, dass wir von vornherein sehr viel Wert auf User Interface und User Experience gelegt haben. Die Implementierung in den Praxis- und Apotheken-IT-Systemen war integraler Bestandteil von ARMIN. Wir haben außerdem von Anfang an ein flexibles und modernes Standarddatenformat genutzt, damals XML, heute wäre das FHIR. Wir haben eine Governance implementiert, die Anwender:innen und auch die PVS-Hersteller eingebunden hat, und wir haben Fachfunktionen vorgegeben, die den Versorgungsprozess abbildeten. BMP und eMP sind dagegen bis heute nur technische Formulare, die nicht regeln, wer was wann einträgt, und bei denen es auch keinerlei verbindliche Anforderungen dahingehend gibt, wie die Primärsysteme das umzusetzen haben.
Trotzdem: Hätte man nicht besser zusammenarbeiten sollen?
Wir haben schon versucht, diese Entwicklungen zusammenzuführen. Das ist uns nicht gelungen. Uns war immer klar, dass die Anforderungen, die wir an unser Medikationsmanagement gestellt haben, mit dem BMP/eMP nicht umsetzbar gewesen wären. Der BMP war rechtlich aufgehängt im § 31a SGB V, mit sehr vielen beteiligten
Institutionen. Letztlich hat man als kleinsten gemeinsamen Nenner einen analogen Medikationsplan geschaffen, ergänzt um einen Barcode. Die AOK PLUS hat immer gesagt, dass sie den Ausdruck unterstützt, dass es aber keinen Grund gibt, sich bei der digitalen Version so stark zu beschränken, wie es mit dem Barcode dann getan wurde. Das galt insbesondere für den eMP. Der war von vornherein zum Scheitern verurteilt, schon wegen der fehlenden Verbreitung von PINs für die eGK. Das war jedem klar.
Stichwort Fachfunktionen: Was waren das für Funktionen, die ARMIN zu einem Erfolg machten?
Wenn Sie sich heute ansehen, wie der BMP genutzt wird, dann hat der Patient drei BMPs von drei Ärzt:innen mit jeweils zwei Medikamenten. Er nimmt sich dann eine Schere und Tesafilm und baut sich seinen BMP für die Kühlschranktür zusammen. Bei uns gab es eine fachliche Anforderung an das Primärsystem, die besagte: Wenn die Karte gesteckt wird, wird im Hintergrund die Verordnungsdatenhistorie der letzten drei Monate für diesen Patienten bei der Krankenkasse heruntergeladen und dann verglichen mit dem, was auf dem aktuellen ARMIN-Medikationsplan steht. Stimmt das nicht überein, ist systemseitig ein Deltaabgleich zu unterstützen, bei dem die Unterschiede visualisiert werden, damit der Arzt oder Ärztin den Plan aktualisieren können. Außerdem hatten wir diverse UI/UX-Vorgaben, etwa dass Zeilen mit einem Mausklick übernommen werden können. Diese Art von Fachfunktionen haben wir spezifiziert, und das war am Ende ein 90-seitiger Katalog, den wir den PVS-Herstellern in die Hand gedrückt haben.
Wie haben Sie die Governance für diese Arbeiten im Projektrahmen konkret organisiert? Mit welchen Leuten haben Sie an diesen 90 Seiten gearbeitet?
Die grundsätzlichen fachlichen Anforderungen haben wir im Kreis der Vertragspartner besprochen, also KVen und Apothekerverbände. Interessant wird es eine Ebene tiefer, wo es darum geht, was die Systeme im Hintergrund machen und was der Praxis bzw. Apotheke wann an Informationen angeboten werden sollen. Das wurde mit Ärzt:innen und Apotheker:innen besprochen. Da gab es Anforderungs-Workshops, heutzutage nennt man das Requirement Engineering. Außerdem waren, ganz wichtig, die Produktmanager jener PVS-Hersteller an Bord, die mit uns zusammenarbeiten wollten. Die konnten sagen, was schon geht und was noch nicht geht, und vor allem: Was geht schnell? Und was ist viel Aufwand? Das Ergebnis war ein iterativer Prozess, bei dem gut umsetzbare Funktionen priorisiert wurden. Nur der Vollständigkeit halber: Viel unterstützt hat uns auch die gevko, eine AOK-Tochterfirma. Die sind sehr erfahren mit Anforderungskatalogen für Praxis-IT-Hersteller. Nach der Verschriftlichung gab es die Version 1.0 des Anforderungskatalogs. Dieses Dokument hat auch während der Programmierungsphase noch gelebt, und am Ende sind wir aus der Entwicklung mit einer Version 2.0 rausgegangen. Das hat dazu geführt, dass die Ärzt:innen und Apotheker:innen gesagt haben: „Das macht Spaß, das Tool kann das, was ich mir vorgestellt habe, und jetzt verwende ich das auch, es fühlt sich nicht mehr an wie eine Doppeldokumentation.“ Ich glaube da müssen wir auch auf Bundesebene hinkommen.
Auf Bundesebene stehen wir mit der elektronischen Medikation im Kontext der Opt-out-ePA vor dem nächsten Versuch, endlich eine funktionierende digitale Medikation im deutschen Gesundheitswesen zu etablieren. Wie lässt sich das, was bei Ihnen im Projekt funktioniert hat, darauf anwenden?
Wir brauchen auf Bundesebene eine andere Governance. Stand heute haben wir unverbindliche Implementierungsleitfäden für Schnittstellen. Das ganze Thema fachliche Anforderungskataloge ist völlig vernachlässigt, das müsste erst mal aufgebaut werden. Und dann müsste man sich noch die Frage stellen, wer ist legitimiert, so einen fachlichen Anforderungskatalog rauszugeben, und zwar so, dass ein Dialog und Veränderungen möglich bleiben. Erfolg haben wir nur, wenn die Anwender:innen das, was wir entwickeln, am Schluss auch benutzen wollen. Dafür braucht die PVS-Industrie Unterstützung, und nicht nur Druck. Ein gutes Beispiel aus einem anderen Kontext ist die ATC-DDD-Festlegung des BfArM für Arzneimittel. Da gibt es auch immer mal Differenzen zwischen pharmazeutischer Industrie, WIdO und BfArM. Die Stakeholder, die am Ende mit der Festlegung leben müssen, erarbeiten diese Festlegung gemeinsam in einer Arbeitsgruppe mit klarer Geschäftsordnung, und das BfArM setzt das Ergebnis einmal im Jahr amtlich in Kraft. So etwas könnten wir auch auf die gematik übertragen: Die gematik wäre als neue Digitalagentur der offizielle Herausgeber eines solchen Anforderungskatalogs. Erstellt wird der aber in entsprechenden Gremien. Die müssen nach klaren Regeln tagen, damit das weniger konfrontativ wird als in der Vergangenheit. Denn das haben wir auch gelernt: In den ersten ARMIN-Jahren haben wir es mit Stärke und Druck versucht, das hat nicht funktioniert. Der kooperative Ansatz war besser.
Konkreter: Wer sollte in so einem Board auf Bundesebene sitzen?
Wir können das auf Bundesebene zum Beispiel über die Spitzenverbände organisieren. Die Anwenderseite muss von KBV/ mio42 bzw. ABDA besetzt werden, und die sollten ihr Personal natürlich weise auswählen. Das dürfen keine Funktionäre sein. Zusätzlich brauchen wir zwingend die Produktmanager der PVS-Hersteller. Die werden bislang gern vergessen, sie sind aber sehr nah dran an den Anwendern, näher als eine KBV oder eine ABDA. Ebenso wie interessierte Krankenkassen, die die Tools ja dann auch in die Versicherten-Frontends bringen müssen. Natürlich werden diese Arbeitsgruppen zu einzelnen Funktionen sagen, hier sei keine Einigung möglich. An dieser Stelle muss es jemanden geben, der die abschließende Entscheidung treffen kann, damit sich solche Prozesse nicht endlos in die Länge ziehen. Um das „Anordnen“ kommen wir nicht völlig herum, aber es ist dann eine Anordnung auf Basis eines transparenten Arbeitsprozesses.
Nun haben Sie bei ARMIN aber nicht nur positive Erfahrungen mit den PVS-Herstellern gemacht. Manchen war das schlicht zu viel Aufwand. Wie lässt sich diese Blockadehaltung lösen?
Die politischen Anforderungen an die PVS-Hersteller sind enorm. Das war auch einer der Gründe, warum wir Mitte 2022 gesagt haben, wir lassen ARMIN auslaufen. Wir stehen jetzt nur noch einige wenige Jahre vor einem dann hoffentlich serverbasierten Medikationsplan auf Bundesebene. Den müssen wir jetzt zu einem Erfolg machen, und zwar gemeinsam. Um Ihre Frage zu beantworten: Ich glaube, wenn wir von den Einzelprojekten wegkommen zugunsten eines einheitlichen, bundesweiten Vorgehens, dann wird es auch leichter, die PVS-Hersteller von attraktiven Integrationen in ihre Systeme zu überzeugen.
Es wird aber auch auf Bundesebene nicht automatisch funktionieren. Die Medizinischen Informationsobjekte (MIO) sind als TI-einheitliche Module gedacht, trotzdem setzt bisher kein einziger PVS-Hersteller zum Beispiel das seit anderthalb Jahren existierende Impf-MIO um, aus guten Gründen. Wenn jetzt mit dem Gedanken gespielt wird, die digitale Medikation in der ePA als MIO zu bauen – ist das vor dem Hintergrund der bisherigen Erfahrungen mit MIOs nicht etwas gewagt?
Wir dürfen die Fehler der Vergangenheit nicht wiederholen, das gilt auch für die MIOs. Es braucht eine Governance für eine verbindliche Implementierung von Fachfunktionen. Das ist der erste Schritt, und die gibt es bei den MIOs bisher nicht. Wenn wir diese Governance haben, dann entstehen Anforderungskataloge mit höherer Akzeptanz. Und dann ist es am Ende auch sekundär, ob eine digitale Medikation als MIO umgesetzt wird oder ob sie über einen eigenen Fachdienst umgesetzt wird.
Was wäre Ihre Präferenz?
Es gibt für beide Ansätze Argumente. Für die Umsetzung als reines ePA-MIO spricht, dass wir noch viele andere MIOs haben, die Medikationsdaten benötigen und die dann unkompliziert aufeinander aufbauen können. Dagegen spricht, dass Menschen, die vom Opt-out-Recht bei der ePA Gebrauch machen, dann auch keine digitale Medikation haben, während eine eigene Fachdienst-Lösung den Opt-out unabhängig von der ePA ermöglichen würde. Man könnte auch eine Hybrid-Lösung wählen, bei der man einen Fachdienst an die ePA anhängt. Aber noch mal: Das sind letztlich nachgelagerte, technische Fragen. Entscheidend ist die Governance-Struktur, und die braucht es für ein Medikations-MIO genauso wie für einen Fachdienst.
Wer ist am Zug, um so ein neues Governance-Modell aufzusetzen? Das Ministerium? Die gematik?
Das ist aus meiner Sicht eine Aufgabe des Ministeriums. Natürlich könnte die gematik intern ihr Requirement Engineering verbessern, das bliebe aber unverbindlich, solange es nicht im Gesetz verortet ist. Es wird auch eine Zertifizierung für so etwas geben müssen. Stand heute darf das nur die KBV für das Arzneimittelverordnungsmodul. Aber bei den Diskussionen, die es in den letzten Jahren gegeben hat, wäre es glaube ich nicht zielführend, die Zertifizierung dort anzusetzen. BfArM wäre eine Option. Die gematik in ihrer neuen Struktur als Bundesoberbehörde wäre auch denkbar. Aber das darf sich dann für die Hersteller nicht anfühlen wie die bisherige gematik. Die gematik darf dann nur der formelle Herausgeber eines vorher möglichst konsensuell erarbeiteten Dokuments sein. Wichtig ist vor allem, dass es damit jetzt auch zügig losgeht. Eine digitale Medikation ist viel, viel komplexer als ein Impfpass. Bei so einem aufwendigeren Anforderungskatalog an PVS-Hersteller ist schnell mal ein Jahr an Entwicklungszeit weg, um Fachfunktionen zu programmieren, die am Ende das komplette PVS betreffen. Da müssen wir jetzt mit anfangen und nicht erst zwei Jahre lang über Backends und richtige Zuordnungen streiten. Sonst haben wir in vier Jahren immer noch keine digitale Medikation.
Wo sehen Sie die Rolle der Krankenkassen?
Die Krankenkassen wollen da mitreden. Sie sind die, die an allen Multimedikationsprojekten, die es in den letzten Jahren gab, maßgeblich beteiligt waren. Sie haben Expertise in diesem Bereich, und sie können natürlich gewisse Daten zur Verfügung stellen, die hilfreich sind. Unabhängig davon sind die Krankenkassen in intensivem Dialog mit der gematik, was die ePA angeht. Und natürlich haben die Krankenkassen ein starkes Interesse daran, dass die Anwendungen schnell zu den Versicherten kommen und da Nutzen stiften – gerade jetzt, wo wir seit ARMIN wissen, dass wir durch eine gut umgesetzte, digitale Medikation sogar die Mortalität senken können.
Dr. Julia Lämmel MBA
ist Bereichsleiterin Arznei-, Heil- / Hilfsmittel bei der AOK PLUS. Sie studierte Pharmazie an der Universität Leipzig und promovierte in Gesundheitsökonomie an der Universität Bayreuth. Bevor sie 2022 zur AOK PLUS kam, war sie lange als Krankenhausapothekerin in Großbritannien und am Uniklinikum Dresden tätig. Sie ist verantwortlich für die Verträge mit den relevanten Verbänden des abgedeckten Leistungsspektrums und der pharmazeutischen Industrie für rund 3,5 Millionen Versicherte. Ein weiterer Fokus ist die Entwicklung der digitalen Landschaft im deutschen Gesundheitswesen.
Das Interview führte Philipp Grätzel von Grätz, Chefredakteur E-HEALTH-COM.