E-Rezept - Warum so kompliziert?

Nur ein Teil vom Ganzen

Die Einführung des E-Rezepts ist ein riesiges Projekt und dennoch nur ein Teil der Bemühungen um die Digitaliserung im Gesundheitswesen, die unter dem Titel E-Health zu finden ist:

Herzstück des digitalen Gesundheitswesens in Deutschland ist die Telematikinfrastruktur (TI). Sie ist die Datenautobahn, die alle Beteiligten im Gesundheitswesen auf einem sehr hohen Sicherheitsniveau miteinander vernetzt.
Quelle: www.kbv.de/html/e-health.php

Den Zugang vermittelt für Arztpraxen und Apotheken der sogenannte Konnektor, ein spezieller Router, der es u.a. ermöglicht, die notwendige Sicherheit zu gewährleisten und den Datenverkehr zu verschlüsseln.
(Vgl. Wikipedia: Konnektor_(Informationstechnik)

Um als Entwickler im E-Health-Bereich tätig werden zu können, kommt man nicht umhin, sich mit dieser Telematikinfrastruktur zu beschäftigen.

Ich habe vor drei Jahren damit begonnen, mich für eine Apotheke mit eigenem, älteren AVS (Apothekenverwaltungssystem) zunächst mit dem Konnektor und anschließend mit dem E-Rezept zu befassen. Selbst für jemanden, der schon seit 2008 für Apotheken programmiert, ist das keine kleine Aufgabe.

Inzwischen ist das Projekt soweit fortgeschritten, dass die Apotheke E-Rezepte einlösen und über das Apothekenrechenzentrum abrechnen kann. Fertig ist es aber nicht - und wird es wohl auch nie sein, denn die Möglichkeiten der elektronischen Verordnung werden ständig weiter ausgebaut - und leider auch umgebaut. Sollte das E-Rezept später auch noch in eine europäische Lösung integriert werden, wie es bereits angedacht ist, wird es wieder neue Anforderungen geben.

Sand im Getriebe

Im Lauf des Jahrs 2024 werden vermutlich auch Privatversicherte in größerem Umfang E-Rezepte nutzen können. Es soll das E-Rezept für Hilfs- und Betäubungsmitteln erweitert werden, die zur Zeit nur auf dem Papierrezept verschrieben werden dürfen. Jede Ausbaustufe ist aufwändig und die Bereitschaft, sich freiwillig mit den Neuerungen auseinanderzusetzen, ist nicht bei allen Beteiligten vorhanden.

Die war auch bei der Einführung des E-Rezepts selbst nicht vorhanden. Der damalige Gesundheitsminister Jens Spahn wollte deshalb gern nachhelfen und das E-Rezept ab 2022 verpflichtend machen.
(Vgl. DAZ.online - Spahn will die E-Rezept-Pflicht ab 2022 )

Der neue Gesundheitsminister Karl Lauterbach hat - zum Glück - die Stimmen derer erhört, die vor diesem übereilten Schritt gewarnt hatten. Dabei ist Karl Lauterbach gewiss kein Bremser, wenn es um Digitalisierung im Gesundheitswesen geht.
(Vgl. dazu DAZ.online: Lauterbach: „Durchbruch für die Digitalisierung" )

Auch wenn man mal die fehlende Schulung der Beteiligten in den Arztpraxen und Apotheken außer acht lässt, die immer wieder kritisiert wurde, war das E-Rezept auch in der technischen Entwicklung längst noch nicht so ausgereift, dass man es ohne größere Probleme an den Start hätte bringen können. Viel zu wenig echte Rezepte waren bis dahin ausgestellt, eingelöst und abgerechnet worden.

An allen Ecken und Enden wurde noch entwickelt und getestet. Das von der Gematik bereitgestellte Testsystem Titus machte auf mich einen recht unfertigen Eindruck. Auch jetzt wird noch ständig daran entwickelt, was zu Unterbrechungen durch neue Releases führen kann. Auch Störungen sind nich selten.

Ansonsten macht die Gematik, die ja für die Entwicklung des E-Rezepts verantwortlich ist, aktuell einen guten Job. Besonders die wöchentlichen E-Rezept-Sprechstunden für Entwickler und andere Beteiligte sind hilfreich und zeugen von großem Engagement. Auch die Kooperation zwischen den Teilnehmenden wird gut koordiniert.
Infos zur E-Rezept-Sprechstunde der gematik

Darüber hinaus gibt es ein Hilfeforum und viele Publikationen wie Spezifikationen und Implementierungsleitfäden oder schlicht auch ganz allgemeine Einführungen für die breite Bevölkerung.

Ist jetzt das E-Rezept endlich weit genug, dass man im Alltag genauso gut damit klar kommen kann wie etwa mit dem Online-Banking? Besonders die Ärzte bezweifeln das. Sie profitieren auch am wenigsten vom E-Rezept, wie man überall nachlesen kann. Die bisherige Papierpraxis ist eingespielt und für die Ärzte einfach. Ein Mehrwert wird nur von wenigen gesehen.
(Vgl. dazu PZ: Bei den Ärzten überwiegt die Skepsis )

Derzeit sei das E-Rezept aus Sicht der Fachärzteschaft noch nicht praxistauglich. Für die Praxen bedeute die Nutzung des E-Rezepts einen deutlich erhöhten Zeitaufwand und die Bindung von Kapazitäten von Praxispersonal, die dringend für die eigentliche Versorgung benötigt würden. Zum einen dauere die Erstellung des E-Rezepts selbst noch viel zu lange, zum anderen sei der Erklärungsbedarf immens hoch.
Quelle PZ: Bei den Ärzten überwiegt die Skepsis (S. 2)

Ob das so sein muss, ist umstritten. Oft liegt es an einem unzweckmäßigen Workflow, wenn die Erstellung des E-Rezepts zu lange dauert. Ein Flaschenhals ist die Signierung des E-Rezepts, wenn nicht die Möglichkeit der Komfortsignatur genutzt wird. Dann kann es sogar vorkommen, dass das E-Rezpt noch nicht fertig signiert ist, wenn der Patient schon mit in der Apotheke steht. Weder für die das Apothekenpersonal noch für die Patienten war anfangs klar, warum die Rezepte nicht abrufbar waren. Diese verließen dann häufig wütend die Apotheke und gingen in die nächste. Inzwischen war das Rezept fertig signiert und einlösbar, und die erste Apotheke hatte den Imageschaden.

Große Probleme treten dann auf, wenn eine Apotheke Probleme mit dem Konnektor oder allgemein mit der TI bekommt und der Support aufgrund von Überlastung erst mit Verzögerung reagieren kann. Eine Apotheke, die keine Rezepte einlösen kann, muss die Patienten weiterschicken, was zu erheblichen Verlusten führen kann. (Vgl. dazu apotheke adhoc: E-Rezept-Ausfall: Apotheke im Stich gelassen )

Und natürlich der Datenschutz

Die Größe des Projekts und das Zusammen- und Gegeneinanderwirken der verschiedenen Akteure sind Gründe dafür, warum das E-Rezept so kompliziert ist.

Natürlich spielt auch der Datenschutz zu Recht eine große Rolle und bewirkte, dass das E-Rezept eine Weile aus den Augen der Öffentlichkeit verschwand. Der vorgesehene Einlöseweg über die Gesundheitskarte war als nicht datenschutzkonform angesehen worden.
(Vgl. heise online: E-Rezept mit Gesundheitskarte: Datenschützer erteilen spezifiziertem Weg Absage )

Technisch gesehen wird das E-Rezept dadurch kompliziert, dass es sicher sein muss. Es muss mit sicheren Verschlüsselungs- und Übertragungstechniken arbeiten, um nicht angreifbar zu sein. Das System muss hochverfügbar sein, damit das Gesundheitssystem nicht zum Erliegen kommt.

Kompliziert sind aber auch die Datenstrukturen, die für die Kommunikation zwischen der Artpraxis zum E-Rezept-Fachdienst und von dort zur Apotheke verwendet werden. Hier stelle ich mir oft die Frage, ob die wirklich so kompliziert sein müssen. Doch dazu später mehr.

E-Rezept und Gesundheitskarte

Damit auch diejenigen folgen können, die sich noch nicht mit dem E-Rezept beschäftigt haben, betrachten wir kurz das E-Rezept im praktischen Leben:

Der Arzt hat Frau Mustermann zwei Medikamente verschrieben und das E-Rezept elektronisch signiert. In der Apotheke gibt sie Ihre Gesundheitskarte ab oder steckt sie in ein Terminal, um die Medikamente zu bekommen. - Wie funktioniert das?

Anders als oft vermutet (und häufig auch falsch publiziert), befinden sich die Rezepte nicht auf der Karte selbst. Es sind dort überhaupt keine Informationen zum E-Rezept gespeichert. Über die Gesundheitskarte legitimiert sich die Apotheke lediglich beim E-Rezept-Fachdienst durch Übermittlung eines aktuellen digitalen Prüfnachweises, der per VSDM über den Konnektor abgerufen wird, und bekommt dadurch eine Liste mit Daten, die wiederum das Abholen der einzelnen Rezepte ermöglicht.
VSDM heißt Versichertendaten-Management. Dieser Dienst kann übe eine sogenannte SOAP-Schnittstelle des Konnektors genutzt werden.

Der Abruf der eigentlichen E-Rezept-Daten erfolgt über eine oder mehrere URLs, die eine Task-ID und einen Accesscode als Parameter enthalten. Dabei hat jede Verordnung eine eigene URL. Im Beispiel von Frau Mustermann bekommt die Apotheke also zwei URLs, über die die Rezepte geladen werden können.

Im Moment wird in der Arztpraxis häufig ein Blatt ausgedruckt, das das E-Rezept repräsentiert und Barcodes für die jeweiligen Verordnungen (max. 3) enthält. Dieses ausgedruckte Blatt ist selbst kein E-Rezept, was auch häufig missverstanden wird. Es enthält aber ein bis drei URLs, mit denen das oder die E-Rezepte eingelöst werden können. Von daher sollte man auch auf dieses Blatt gut aufpassen so wie vorher auf das rosa Rezept.

Wichtig ist zu wissen, dass ein E-Rezept selbst immer nur eine Verordnung enthält. Es können zwar mehrere Packungen desselben Medikaments - z.B. 3 mal PZN12345678 - aber nicht mehrere verschiedene verordnet werden. (In Österreich ist das anders. Da können bis zu zehn Medikamente in einem E-Rezept verordnet werden, das dann aber auch nur bei einer einzigen Apotheke eingelöst werden kann.)

Die URL für den Abruf des E-Rezepts ist nicht einfach frei über das Internet zu erreichen. Auch hier führt der Weg über den Konnektor, der die Verbindung absichert.

Was ist mit der E-Rezept-App?

Ein weiterer Weg, ein E-Rezept einzulösen, wird über die Gematik-App ermöglicht. Mit dieser App kann der Patient seine E-Rezepte verwalten. Den Zugang zur TI (Telematikinfrastruktur) erfolgt mit Hilfe der Gesundheitskarte und dem integrierten Chip, der über ein modernes Handy ausgelesen werden kann. Zusätzlich braucht man zur Nutzung der Karte noch eine PIN, die von den Krankenkassen meist nur auf Antrag mitgeteilt wird. Dieser Einlöseweg für Rezepte ist relativ kompliziert und wird daher zur Zeit auch noch wenig genutzt.

Beim Rezept für Privatversicherte wird die App vermutlich eine größere Rolle spielen, weil es hier keine Gesundheitskarte sondern andere Authentifizierungsverfahren gibt. Ich vermute, dass sich beim Thema App noch einiges bewegen wird.

Interessant ist die App, weil Patienten direkt Kontakt mit ihrer Apotheke aufnehmen können, die Verfügbarkeit des Medikaments anfragen und ihr Rezept dann der Apotheke direkt zuweisen können. Es ist dann nur ein Weg zur Apotheke nötig. Wenn die Apotheke das Medikament per Botendienst liefert, kann man ganz zuhause bleiben. Außerdem können die Benutzer mit der App auch ihre E-Rezepte anzeigen lassen und sogar selbst löschen, wenn Sie diese nicht mehr einlösen möchten.

Die Kommunikation zwischen App und Apotheke ist wieder ein eigenes Thema. Natürlich gibt es auch dafür Protokolle und Spezifikationen. Ich beschränke mich aber in diesem Beitrag überwiegend auf die Erstellung und das Einlösen des E-Rezepts und die Schwierigkeiten, die es dabei zu überwinden gilt. Und selbst dieses Thema kann hier nicht ausgeschöpft werden, sondern es muss immer wieder auch auf andere Quellen verwiesen werden.

Kann das E-Rezept nicht mehrfach eingelöst werden?

Beim Abruf des E-Rezepts durch die Apotheke ändert sich der Status auf "in-progress" und ist damit umgehend gesperrt. Auch der (fast) gleichzeitige Abruf von zwei Stellen wäre nicht möglich. Hier kann nur eine Apotheke den "Zuschlag" bekommen. Allerdings ist es ein normaler Vorgang, dass die Apotheke, die häufig erst nach dem Abruf des Rezepts sehen kann, was es enthält, das Rezept zurückgibt oder zurückgeben muss. Gründe können sein: Das Medikament ist nicht verfügbar und der Patient will es in einer anderen Apotheke probieren, oder es ist älter als 28 Tage und wird dann von der Krankenkasse nicht mehr erstattet.

Auch ein Löschen des Rezepts ist möglich, wenn sich z.B. herausstellt, dass der Arzt etwas Falsches verschrieben hat und der Fehler in der Apotheke auffällt. Ein Löschen in der Apotheke sollte natürlich nur in Absprache mit dem Arzt oder Patienten erfolgen. Auch der Arzt kann das Rezept löschen, solange es noch nicht von der Apotheke abgerufen wurde. Das könnte notwendig sein, wenn er kurze Zeit nach Erstellen der Verordnung einen Fehler bemerkt.

Eine einfache Rückgabe des Rezepts gibt das Rezept wieder frei und versetzt es in den Status, den es vor dem Abruf hatte. Der Patient kann dann z.B. in eine andere Apotheke gehen und da sein Glück versuchen. Oder er kommt nach einer halben Stunde wieder und lässt das Rezept erneut abrufen, weil er sich entschlossen hat, doch die lange Lieferzeit zu akzeptieren.

Die Stationen des E-Rezepts

Bevor wir einen Blick auf die Datenstruktur des E-Rezepts werfen, wollen wir kurz seinen Transportweg betrachten und beschränken uns auf den Idealfall, dass alles glatt durchläuft:

1. Das E-Rezept wird in der Arztpraxis mit Hilfe des PVS (Praxisverwaltungssystem) erstellt und auf den zentralen E-Rezeptserver geladen.
2. Die Apotheke lädt mit Hilfe einer URL das E-Rezept vom E-Rezept-Server und sperrt es damit gleichzeitig gegen weitere Zugriffe.
3. Die Apotheke lädt eine Bestätigung auf den E-Rezeptserver, dass Sie das Medikament (oder ein Austauschmedikament) abgeben hat und erhält eine elektronische Quittung in Form einer Datenstruktur. Damit ist das E-Rezept auf dem E-Rezeptserver abgeschlossen.
4. Die Apotheke erstellt einen Abrechnungsdatensatz und schickt diesen zusammen mit der Quittung und dem Verordnungsdatensatz an das Apothekenrechenzentrum (ARZ), mit dem es einen Vertrag hat.
5. Das ARZ prüft die Daten und schickt die Abrechnung in einer anderen Datenstruktur an die zuständige Kasse.

Der Datenverkehr unter der Lupe

Man muss unterscheiden zwischen den Protokollen, die sich auf den Versand des E-Rezepts sowie der angesprochenen Datensätze für den Quittungsabruf und die Abrechnung beziehen sowie den Protokollen, die den eigentlichen Inhalt beschreiben.

Die Gematik hat das alles sehr schön dokumentiert, über folgende Seite findet man den Einstieg, um sich dann immer tiefer vorarbeiten zu können:

E-Rezept API-Dokumentation

Auf dieser Seite findet man die Links zu den untergeordneten Beschreibungen. Wenn man sich für die Verarbeitung des E-Rezepts in der Apotheke interessiert, kann man das hier nachlesen:

E-Rezept API-Dokumentation für Apotheker

Dem Entwickler reichen diese Dokumentationen nicht aus. Es gibt auch noch einen Implementierungsleitfaden für das E-Rezept und viele Spezifikationen, die bis ins kleinste Detail gehen. (Siehe Linkliste)

Ein Blick ins Innere des E-Rezepts

Um Daten im deutschen Gesundheitswesen strukturieren zu können, hat man sich für den FHIR-Standard entschieden. Wir werden uns das am Beispiel des E-Rezepts noch genauer ansehen.

Die Kassenärztliche Bundesvereinigung (KBV) erklärt FHIR folgendermaßen:

FHIR® wurde im Jahr 2014 ins Leben gerufen und ist der neueste Standard zum Datenaustausch zwischen unterschiedlichen Softwaresystemen im Gesundheitswesen. Im Gegensatz zu anderen Standards steht nicht ein bestimmtes Dokument im Vordergrund, sondern dessen Inhalte. Diese werden in FHIR® als Ressourcen bezeichnet und enthalten nur kleinere Informationsmengen.
Quelle KBV: Erklärung FHIR

Anders als dieses Zitat vermuten lässt, ist FHIR keine komplette Neuentwicklung sondern basiert auf einem Standard mit den Namen HL7:

The Fast Healthcare Interoperability Resources (FHIR) specification combines the best features of HL7’s versions two and three and CDA. The difference? FHIR leverages the latest web standards and applies a tight focus on implementability.
Quelle: History of FHIR: How the Data Exchange Standard Began

Bei Wikipedia erfährt man, dass HL7 1987 in den USA gegründet wurde, "um eine Industrienorm (englisch: Standard) für klinische Informationssysteme zu verfassen". Weiter heißt es dort:

HL7 verbundene Organisationen, sogenannte Affiliates, existieren inzwischen in über 30 Ländern. Die erste Partnergesellschaft wurde bereits 1993 in Deutschland gegründet. Auch in den USA ist HL7 lediglich eine von vielen akkreditierten Gruppen, die Industriestandards im Gesundheitswesen bearbeiten.
Quelle: Wikipedia - HL7

FHIR - Viel Bürokratie, wenig Feuer

FHIR wird ausgesprochen, wie das englische fire. Ob FHIR aber wirklich die Entwicklung des E-Rezept-Projekts beschleunigt, möchte ich zumindest zur Diskussion stellen.

Eine auf FHIR basierende XML-Struktur nutzt Basis-Profile und sogenannte Extensions. Ein typisches E-Rezept kann man sich z.B. hier ansehen:
E-Rezept-Beispiel

Eine tabellarische Darstellung der Struktur sieht so aus:
Tabellarische E-Rezept-Struktur

Die PZN eines Festpreismedikaments, eine der wichtigsten Informationen im E-Rezept, findet man z.B. auf folgendem Pfad,

Bundle.entry[2].resource[0].code[0].coding[0].code[0] -> 08585997

Berücksichtigen sollte man beim Auslesen der Daten mit xpath auch den jeweiligen Identifyer:

Bundle.entry[2].resource[0].code[0].coding[0].system[0] -> http://fhir.de/CodeSystem/ifa/pzn

Reduzieren wir einmal die Fundstelle für die PZN auf folgende Struktur im XML-String:

<code>
    <coding>
        <system value="http://fhir.de/CodeSystem/ifa/pzn" />
        <code value="08585997" />
    </coding>
    <text value="Prospan&#174; Hustensaft 100ml N1" />
</code>

Die eigentlichen Daten stecken generell nicht in den Elementen sondern in Attributen mit dem Namen "value". Das ist nicht das, wozu in Lehrwerken geraten wird:
XML Elements vs. Attributes

Lesbarer wäre diese Variante gewesen:

<code>
    <code system="http://fhir.de/CodeSystem/ifa/pzn">08585997</code>
    <text>Prospan&#174; Hustensaft 100ml N1</text>
</code>

Die Erklärung für die Nutzung von value-Attributen ist die Erweiterbarkeit durch Extensions. Mehr dazu in diesem Artikel:

Attributes Versus Elements in FHIR XML

Dieser generelle Erweiterbarkeitswunsch hat seine Berechtigung. Die Idee dahinter ist wohl, dass man die Strukturen einfach ausbauen kann, und der bisherige Code zum Auslesen der Daten funktioniert weiter.

Für die Arbeit mit medizinischen Daten ist diese Annahme gefährlich, weil ja gerade wichtige Informationen in den Erweiterungen stecken könnten. Die Erweiterung hat ja schließlich ihren Grund.

Wenn das Apothekensystem die neuen Daten nicht berücksichtigt, kann das natürlich dann zu Problemen führen, wenn die medizinische Versorgung des Patienten oder gesetzliche Bestimmungen betroffen sind. Bei jeder Änderung des Profils, das mindestens einmal im Jahr zu erwarten ist, kommt Arbeit auf die Hersteller der Systeme zu, die mit den FHIR-Strukturen zu tun haben.

Aus diesem Grund halte ich die FHIR-Strukturen, in deren Verästelungen und Verzweigungen wichtige Daten verborgen sind, nicht für geeignet, die Entwicklung des E-Rezept-Projekts zu beschleunigen. Hier hätten klare und übersichtliche Datenstrukturen den Entwicklern viel Arbeit abgenommen.

Die FHIR-Strukturen bieten zu viele Möglichkeiten, alles Erdenkliche an Informationen und Sicherungsmechanismen in das E-Rezept zu integrieren. Die Gefahr ist, dass man am Ende den Wald vor Bäumen nicht mehr sieht.

Wie man die PZN eines verordneten Medikaments ausliest, kann man einem offiziellen XSLT-Stylesheet entnehmen

<xsl:template match="fhir:entry/fhir:resource/fhir:Medication">
        <xsl:choose>
            <xsl:when test="fhir:code/fhir:coding/fhir:system[@value='http://fhir.de/CodeSystem/ifa/pzn']">
            [...]
<text>(PZN: </text>
<xsl:value-of select="fhir:code/fhir:coding/fhir:code/@value"/>

Man muss dazu sagen, dass das Stylesheet dazu da ist, die Daten der XML-Struktur als HTML-Repräsentation in Form des gewohnten Papierrezepts darzustellen. Doch auch für die bloße Extraktion der gewünschten Daten muss man ähnlich kompliziert vorgehen.

Die Komplexität entsteht dadurch, dass unterschiedliche Organisation für bestimmte Datenelemente zuständig sind.

Begibt man sich auf die Suche nach der sogenannten kanonischen URL, die die PZN eindeutig bezeichnen soll, stößt man auf diese Seite:
Package de.basisprofil.r4 1.5.0-alpha2 Pzn
Hier erfährt man, dass die PZN selbst gar nicht an dieser Stelle definiert ist sondern die ganze Struktur nur ein "PZN Platzhalter-CodeSystem" ist.

Bei der PZN versagen die über FHIR-Profile aufstellbaren Regeln. Die Gültigkeit einer PZN damit zu überprüfen wäre nicht praktikabel. Wenn man wissen will, ob sie definiert ist, muss man im ABDA-Artikelstamm nachsehen, der zweimal im Monat aktualisiert wird.

Neben der PZN, die hier beispielhaft untersucht wurde, gibt es natürlich weitere wichtige Daten, wie die Anzahl der Packungen, die Dosierung, die Arztnummer, Versichertuen-ID und -Status u.v.m. Auch diese Informationen müssen mit Hilfe des korrekten Pfads ausgelesen werden.

Mein persönlicher Eindruck ist der, dass man sich mit den FHIR-Strukturen im E-Rezept ziemlich verzettelt hat. Der Wartungs-, Abstimmungs- und vor allem auch der Einarbeitungsaufwand muss gewaltig sein.

Die Validierung der FHIR-Strukturen ist ein Thema für sich. Eine Zeitlang gab es sogar Diskussionen darüber, ob der FHIR-Validator der Gematik oder der ABDA das letzte Wort über die Gültigkeit von E-Rezepten oder Abrechnungsdaten haben sollte. Zum Glück gibt es jetzt einen allgemein akzeptierten Referenz-Validator .

Noch kein durchschlagender Gewinn für die Datensicherheit

Bei all dem Aufwand bei der Zubereitung des Datensalats drückt sich der E-Rezept-Fachdienst davor, simple Überprüfungen im E-Rezept direkt vorzunehmen und offenkundig ungültige Rezepte gar nicht erst zuzulassen.

Wenn der Arzt eine ungültige Pharmazentralnummer (PZN) angibt, kann diese dennoch ins E-Rezept und in die Apotheke gelangen, sofern das PVS (Praxisverwaltungssystem) das nicht abfängt. In der Apotheke fällt der Fehler dann normalerweise auf und das Rezpept muss mühsam in Rücksprache mit dem Arzt geändert werden.

Problematisch sind vor allem Freitextrezepte, wie sie gern von Zahnärzten verwendet werden, wenn sie keinen Artikelstamm in ihrem System haben. Eine automatische Verarbeitung des Freitextrezepts ist kaum möglich, besonders wenn damit Rezepturen verordnet werden. Fehler und Unstimmigkeiten sind an der Tagesordnung, wenn das Freitextrezept zum Einsatz kommt.

Welche Verbesserungen sind denkbar?

Ich mache mir keine Illusionen, dass ein System, in das viel Zeit, Geld und Arbeitszeit gesteckt wurde, im großen Stil wieder geändert wird. Jede Änderung wäre mit viel Aufwand verbunden. Programmcode muss umgeschrieben und getestet werden.

Für realistischer halte ich gezielte Strukturverbesserungen oder auch die Einführung von parallel nutzbaren Alternativen, die man freiwillig nutzen kann.

Zum Nutzen der Apothekensysteme stelle ich mir vor, dass die relevanten Rezeptdaten zentral auf dem Gematikserver in eine einfache Struktur gebracht werden. Diese könnten dann zusätzlich beim Download übertragen werden, und das Apothekensystem müsste sich mit den komplexen FHIR-Strukturen nicht mehr befassen. Das AVS reicht das eigentliche Rezept einfach wie bisher an das Rechenzentrum weiter, muss aber den Inhalt selbst nicht auseinander pflücken.

Auch die Erstellung der Abrechnungsdaten könnte m.E. gut auf FHIR-Strukturen verzichten. Hilfreich wären einfache und langlebige Datenstrukturen. Das wäre meines Erachtens ein guter Beitrag zur Verbesserung des E-Rezepts.

Ausblick auf das Jahr 2024

Andere Länder, wie Österreich, haben gezeigt, dass das E-Rezept funktionieren kann. Nur hat man dort einiges anders gemacht, und die Gesundheitssysteme kleinerer Länder sind nicht unbedingt mit dem deutschen vergleichbar.

Die ersten Wochen im Jahr 2024 werden zeigen, ob das E-Rezept und die dafür geschaffene Infrastruktur stabil genug sind, um den erhofften Nutzen entfalten zu können, oder ob die Probleme so groß werden, dass man wieder auf das rosa Rezept zurückschalten muss. Die erste Woche im neuen Jahr ist aber recht gut angelaufen.

Über Rückmeldungen und Verbesserungsforschläge zu diesem Artikel freue ich mich. Bitte verwenden Sie dafür mein Kontaktformular auf p-bieling.de .