Updates von mehreren Stunden Dauer, Probleme mit verlorenen Daten, Rechnungen von mehreren hundert Euro – der bundeseinheitliche Medikationsplan und die Änderung der Heilmittelverordnung haben viele Anwender so verärgert, dass verschiedene Berufsverbände nun von der KBV fordern, entsprechende Software selbst zu entwickeln. Und auch die KBV zeigt sich dieser Idee gegenüber aufgeschlossen, erfüllt sie doch einen langgehegten Wunsch, sich in diesem Feld zu betätigen. Für die Praxen klingt das verlockend – eine gut funktionierende und kostenlos von der KBV bereitgestellte Software, die per definitionem alle Anforderungen erfüllt. Zu schön, um wahr zu sein?

Im Rahmen einer Artikelserie beleuchtet "Der Allgemeinarzt" das Thema Praxis-EDV. Bisherige Themen waren unter anderem Softwarearchitektur, Netzanbindung, mobile Anwendungen, die Funktion von Servern, Telematik, Verschlüsselungstrojaner, die Besonderheiten des Software-Marktes und die Erfordernisse revisionssicherer Archivierung von Patientendaten.

Die KBV-Software müsste auf den Rechnern in den Praxen laufen und mit allen Betriebssystemen funktionieren, die derzeit in den Praxen im Einsatz sind. Da noch nicht alle Praxen ihre EDV mit dem Internet verbunden haben, würde eine Online-Lösung ausscheiden. Die KBV würde, wie auch jetzt schon bei den von ihr bereitgestellten Prüf- und Kryptomodulen, ihre Software daher wahrscheinlich in Java programmieren. Damit wäre es möglich, die gleiche Software sowohl auf Windows- als auch auf Apple-Rechnern einzusetzen. Nicht unterstützt würden damit die Betriebssysteme mobiler Geräte iOS und Android [1]; für die KV-Abrechnung nicht relevant, wünschenswert aber für Funktionen wie Heilmittel- oder Arzneimittelverordnung. Die Java-Laufzeitumgebung, die bei uns im Support ab und zu Probleme macht, wenn auf den Rechnern kein Java oder die falsche Version installiert ist, müsste auf allen Rechnern in der Praxis installiert und regelmäßig aktualisiert werden, und nicht nur wie jetzt auf den Rechnern, an denen die Abrechnung durchgeführt wird. Die KBV-Software müsste entweder von den Softwareherstellern zusammen mit deren Quartalsupdate oder separat von der KBV aktualisiert werden. In beiden Fällen würde der vielbeklagte langwierige und fehleranfällige Update-Prozess nicht vereinfacht, im letzten Fall durch eigene KBV-Updates sogar noch vervielfacht.

Das Schnittstellen-Problem

Die KBV-Software müsste über eine Schnittstelle an die vorhandene Praxis-Software angebunden werden, was erfahrungsgemäß sowohl die technische als auch organisatorische Komplexität erhöht. Schließlich hat man es in einer solchen Architektur nicht mit einem, sondern mit zwei getrennten Systemen zu tun, die beide funktionieren und miteinander kommunizieren müssen. Die Fehleranfälligkeit steigt an und das Ausfallrisiko des Gesamtsystems erhöht sich, da es nicht mehr korrekt arbeitet, wenn eines der Teilsysteme ausfällt. Die einfachste Lösung wäre die Nutzung der bereits vorhandenen Schnittstelle, mit der medizinische Geräte und Praxis-Software gekoppelt werden (GDT). Diese ermöglicht allerdings nur einen sehr begrenzten Datenaustausch und reagiert, da sie auf dem Austausch von Dateien basiert, langsam. Eine komfortable, schnelle Schnittstelle, die einen vollumfänglichen Datenaustausch ermöglichen würde und die mit allen am Markt vorhandenen Praxis-Softwaresystemen kommunizieren könnte, müsste vermutlich neu konzipiert werden.

Mit der größte Kritikpunkt der Praxen an der derzeitigen Lösung sind die zusätzlichen Lizenzgebühren. Die Erwartung der Praxen an eine KBV-Software ist daher, dass sie kostenlos zur Verfügung gestellt würde. Die Anbindung der KBV-Software an die Praxis-Software über eine komfortable, schnelle Schnittstellenlösung würde jedoch für die Hersteller der Praxis-Software auch Anpassungsaufwand erzeugen. In der Praxis-Software müssten neue Funktionen geschaffen werden, um Daten an die Schnittstelle in dem von ihr verlangten Format zu übergeben und um Daten von der Schnittstelle entgegenzunehmen und in die eigenen Speicherstrukturen zu transformieren. Softwarehersteller, die in der Vergangenheit zusätzliche Gebühren für neue Software-Module mit den ihnen entstandenen Entwicklungsaufwendungen begründet haben, könnten dies somit auch weiterhin tun, denn Aufwände fallen ja auch an – nicht für die Programmierung neuer Funktionen, sondern für die Programmierung der zur Anbindung der Funktionen notwendigen Schnittstellen. Um zu verhindern, dass die Hersteller für die Schnittstellenanbindungen zu neuen KBV-Modulen Lizenzgebühren verlangen, müsste die KBV die Hersteller – notfalls per Gesetz – dazu verpflichten, die Schnittstellen zu den KBV-Modulen ohne weitere Zuzahlung im Rahmen der regulären Wartungs- und Pflegeverträge bereitzustellen [2]. Wenn dies aber im Rahmen ihrer Möglichkeiten läge, dann könnte die KBV auch heute schon einfach von den Herstellern verlangen, die in ihren Anforderungsdokumenten beschriebenen "gesetzlichen" Funktionalitäten ohne gesonderte Lizenzierung bereitzustellen.

Die Service-Frage

Die Funktionalität der KBV-Software wäre vermutlich deutlich umfangreicher als die der von ihr derzeit bereitgestellten Prüf- und Kryptomodule. Eine KBV-Software für Medikationsplan und Heilmittelverordnung würde beispielsweise eine Druckfunktion benötigen, um Medikationspläne und Verordnungsdokumente ausdrucken zu können. Da die KBV-Software nicht auf die Druckfunktionen der Praxis-Software zugreifen könnte, müsste sie eine eigene Druckerverwaltung beinhalten, die in der Lage wäre, alle "in der freien Wildbahn" anzutreffenden Drucker anzusteuern. Auch würde die KBV-Software eine eigene Datenbank benötigen, um eigene Daten wie etwa den Heilmittelkatalog oder Verordnungsdetails zu speichern – aufwendig in der Erstellung und Pflege, und eine weitere Quelle für Probleme mit Installation und Betrieb.

Und spätestens hier stellt sich die Frage, wer die KBV-Software eigentlich im laufenden Betrieb betreuen soll. Es würde ein Ansprechpartner bei Problemen benötigt, und auch jemand, der vor Ort in den Praxen bei der Einrichtung und bei Problemen hilft. Die Hersteller von Praxis-Software haben hier zwar ihre lokalen Servicestrukturen, diese würden aber sicherlich die Betreuung fremder Software nicht ohne eine entsprechende Vergütung übernehmen. Soll die Software für die Praxen aber tatsächlich kostenfrei sein, müsste die KBV wohl eigene bundesweite Betreuungsstrukturen für die über 120.000 laufenden Installationen aufbauen und diese aus eigenen Mitteln finanzieren.

Für gute Qualität sind Investitionen notwendig

Ein weiteres Ärgernis, das eine von der KBV bereitgestellte Software beseitigen soll, ist die bemängelte Qualität der von einigen Software-Herstellern ausgelieferten neuen Programmteile. Mangelnde Softwarequalität wird dann ausgeliefert, wenn man bei der Programmierung und beim Test an Ressourcen spart. Unzureichende Ressourcen sind zum einen eine Folge der ambitionierten Gewinnziele einiger Softwarehersteller [3], zum anderen eine Folge der Marktstrukturen, die es insbesondere kleineren Herstellern, die seit Jahren mit sinkenden Installationszahlen zu kämpfen haben [4], erschweren, bei stagnierenden Erträgen und unter Preisdruck zusätzliche Ressourcen für die Entwicklung neuer Module bereitzustellen. Für die Entwicklung einer KBV-eigenen Software bedeutet dies, dass deren Qualität letztlich ebenfalls von der Ausstattung ihres Entwicklungsteams abhängen und damit letztlich wieder eine Frage der Budgetausstattung sein wird.

Was also müsste die KBV tun, um es besser zu machen als jetzt die Hersteller der Praxis-Software? Sie müsste nicht unerhebliche Mittel für die Entwicklung und den Test qualitativ hochwertiger Software bereitstellen. Diese müssten entweder aus den Mitgliedsbeiträgen stammen, oder doch über entsprechende Lizenzgebühren gegenfinanziert werden [5]. Sie müsste zudem die Hersteller von Praxis-Software dazu motivieren, passende Schnittstellen zur Verfügung zu stellen, und eine bundesweite Betreuung ihrer Software organisieren. Machbar ist das schon, allerdings nur unter hohem personellen und finanziellen Einsatz, mit entsprechendem zeitlichen Vorlauf und allen Risiken von IT-Projekten vergleichbarer Größenordnung. Um die aktuellen Probleme schnell zu lösen, ist die eigene Softwareentwicklung durch die KBV daher sicherlich kein probates Mittel. Die Frage ist, ob die KBV mit ihren Gestaltungsmöglichkeiten hier nicht andere, regulatorische Lösungen finden kann. Und, ob eine Praxis wirklich keine andere Alternative hat, als ihr ungebührlich erscheinende Forderungen ihres Softwareherstellers zu akzeptieren – zum Glück gibt es derzeit ja noch die Auswahl unter einer ganzen Reihe von Anbietern.


Literatur:
1) https://www.java.com/de/download/faq/java_mobile.xml
2) http://news.doccheck.com/de/161807/wer-jetzt-mit-dem-medikationsplan-geld-macht/
3) http://www.apotheke-adhoc.de/nachrichten/politik/nachricht-detail-politik/medikationsplan-aerzte-softwarehaeuser-zocken-uns-ab/
4) http://www.kbv.de/html/6989.php
5) http://www.aerztezeitung.de/praxis_wirtschaft/e-health/article/927304/medikationsplan-software-gebuehren-zankapfel.html

Ergänzende Literatur:
http://www.bvdd.de/de/news/top-news/kbv-ruegt-praxissoftwarehersteller.html
http://www.kbv.de/html/1150_26518.php
https://www.aerzteblatt.de/nachrichten/46621/KBV-will-kuenftig-Praxissoftware-selbst-entwickeln
http://www.biermann-medizin.de/fachbereiche/urologie/kliniken-praxen/kbv-verliert-geduld-herstellern

Bisher in dieser Serie erschienene Beiträge finden Sie hier.



Autor:

Alexander Wilms

Alexander Wilms betreut seit über 15 Jahren die allgemeinärztliche Praxis seiner Frau in IT-Fragen und war maßgeblich an der Entwicklung von RED Medical, der ersten webbasierten Arztsoftware, beteiligt. Die Server stehen in einem deutschen Hochsicherheits-Rechenzentrum. Die Patientendaten werden ausschließlich verschlüsselt gespeichert. Die Software hat alle maßgeblichen Zertifizierungen der KBV und das Datenschutzgütesiegel des Unabhängigen Landesdatenschutzzentrums (ULD) und des TÜV Saarland.

Erschienen in: Der Allgemeinarzt, 2017; 39 (5) Seite 70-72