.png)
ZusammenfassungEin E-Rezept-Backend braucht Arzneimitteldaten auf zwei Ebenen: den Verordnungskern zur eindeutigen Identifikation einer Packung, also PZN, Handelsname, Darreichungsform, Packungsgröße, Wirkstoff mit Stärke und Verschreibungsstatus, und die Wirtschaftlichkeitsebene aus Preisen, Festbeträgen, Rabattvertragskennzeichen und Substitutionsangaben. Die zweite Ebene ist kein Komfort, sondern Folge einer gesetzlichen Vorgabe: Nach § 73 Absatz 9 Sozialgesetzbuch V dürfen Vertragsärztinnen und Vertragsärzte nur Programme nutzen, die diese Inhalte führen und von der Kassenärztlichen Bundesvereinigung zugelassen sind. Die Zulassungspflicht trifft dabei die Verordnungssoftware, nicht die Datenquelle dahinter. Lizenziert wird üblicherweise je Praxis oder je lebenslanger Arztnummer. Dieser Artikel richtet sich an Anbieter von Praxisverwaltungs-, Verordnungs- und Telematikinfrastruktur-Software sowie an Middleware-Anbieter im E-Rezept-Umfeld.
Die Konstellation ist neu, aber sie wiederholt sich. Ein IT-Dienstleister baut kein vollständiges Praxisverwaltungssystem, sondern eine Middleware: ein Backend, das die Ausstellung elektronischer Verordnungen übernimmt, während das Frontend beim Praxissystem oder bei einem eigenen Produkt liegt. Der Dienstleister steht damit zwischen zwei Parteien und muss für beide liefern, ohne selbst die verordnende Stelle zu sein.
Genau daraus entsteht die Ausgangsfrage, die in solchen Gesprächen regelmäßig fällt und die fast immer als Vermutung formuliert wird: Es sei wohl gesetzlich vorgeschrieben, dass die Arzneimitteldaten aus einer lizenzierten Datenbank stammen müssen. Die Vermutung geht in die richtige Richtung, trifft aber den falschen Adressaten, und diese Ungenauigkeit ist teuer, weil sie die Verantwortlichkeiten falsch verteilt.
Richtig ist: Der Gesetzgeber schreibt nicht vor, von welchem Anbieter Sie Daten beziehen. Er schreibt vor, welche Inhalte die Software haben muss, die eine Ärztin oder ein Arzt zur Verordnung nutzt, und dass diese Software zugelassen sein muss. Für ein Backend heißt das: Sie sind nicht Adressat der Zulassungspflicht, aber Sie sind Zulieferer für deren Erfüllung. Ihr Feldsatz entscheidet, ob die Software, die auf Ihnen aufsetzt, die Anforderungen überhaupt erfüllen kann.
Es lohnt sich, diese Rollenverteilung einmal auszuschreiben, weil sie die Vertragsgespräche vereinfacht. Die verordnende Person trägt die Verantwortung für die Verordnung. Die Verordnungssoftware trägt die Zulassungspflicht. Das Backend trägt die Pflicht, die Inhalte vollständig, aktuell und aus einer lizenzierten Quelle bereitzustellen. Der Datenanbieter trägt die Lizenz an den Daten und deren Aktualisierung. Vier Rollen, vier Pflichten, keine davon ersetzt eine andere.
Der zweite wiederkehrende Punkt ist die Preisstruktur. Die Zielgruppe ist preissensibel, und das Lizenzmodell muss zur Abrechnungslogik des Backends passen, also je Praxis oder je Arztnummer, nicht als pauschale Unternehmenslizenz. Wer das erst nach der technischen Integration klärt, verhandelt zweimal.
Elf Felder sind je Packung Pflicht: PZN, Handelsname mit Zulassungsinhaber, Darreichungsform, Packungsgröße, Wirkstoff mit Stärke, Verschreibungsstatus, ATC-Code, Preise je Preisart mit Gültigkeitsdatum, Festbetrag und Festbetragsgruppe, Rabattvertragskennzeichen je Kostenträger, Aut-idem-Angaben und Vertriebsstatus. Medikationsplandaten kommen als eigener Lizenzumfang hinzu.
Der Feldsatz zerfällt sauber in zwei Blöcke. Der erste identifiziert die Packung, der zweite trägt die Wirtschaftlichkeitsprüfung. Ohne den zweiten Block kann die aufsetzende Verordnungssoftware ihre Pflichtinhalte nicht darstellen.
| Feld | Wofür das Backend es braucht | Pflicht oder optional |
|---|---|---|
| PZN | Eindeutiger Schlüssel der verordneten Packung, Verknüpfung zu allen weiteren Daten | Pflicht |
| Handelsname und Zulassungsinhaber | Darstellung im Verordnungsdialog, Unterscheidung gleicher Wirkstoffe | Pflicht |
| Darreichungsform und Packungsgröße | Auswahl der richtigen Packung, Grundlage für Reichweite und Dosierung | Pflicht |
| Wirkstoff und Stärke | Wirkstoffverordnung, Medikationsplan, Abgleich über Präparate hinweg | Pflicht |
| Verschreibungsstatus | Steuert, ob und in welcher Form verordnet werden darf | Pflicht |
| ATC-Code | Gruppierung, Vergleich und Auswertung über Handelsnamen hinweg | Pflicht |
| Preise je Preisart mit Gültigkeitsdatum | Vergleichende Preisinformation nach § 73 Absatz 8 Sozialgesetzbuch V | Pflicht |
| Festbetrag und Festbetragsgruppe | Erkennen von Mehrkosten für die versicherte Person | Pflicht |
| Rabattvertragskennzeichen je Kostenträger | Information nach § 130a und § 130e Sozialgesetzbuch V | Pflicht |
| Aut-idem- und Substitutionsangaben | Darstellung austauschbarer Präparate im Verordnungsdialog | Pflicht |
| Vertriebsstatus je PZN | Verhindert die Verordnung außer Vertrieb gesetzter Packungen | Pflicht |
| Medikationsplan-relevante Angaben | Befüllung des Medikationsplans nach § 31a Sozialgesetzbuch V | bedingt Pflicht |
Die letzte Zeile ist bewusst als bedingte Pflicht gekennzeichnet. Der Anspruch auf den Medikationsplan ergibt sich aus § 31a Sozialgesetzbuch V. Medikationsplandaten sind ein eigener Lizenzumfang mit eigenem Aktualisierungsrhythmus, nicht einfach eine Teilmenge des Artikelstamms. Wer den Medikationsplan erst später anbaut und die Lizenz dafür nicht von Anfang an mitverhandelt, verhandelt sie zum schlechteren Zeitpunkt nach.
Für ein E-Rezept-Backend gibt es drei Datenstufen, und nur die ersten beiden sind für den Betrieb zwingend. Die dritte entscheidet über die Qualität des Produkts, nicht über seine Zulässigkeit.
Stufe 1, der Verordnungskern. Identität der Packung: PZN, Handelsname, Darreichungsform, Packungsgröße, Wirkstoff mit Stärke, Verschreibungsstatus, Vertriebsstatus. Das ist die Mindestmenge, damit eine Verordnung überhaupt eindeutig ist.
Stufe 2, die Wirtschaftlichkeitsebene. Preise, Festbeträge, Rabattvertragskennzeichen und Substitutionsangaben. Diese Stufe ist der Grund, warum ein Artikelstamm allein nicht reicht. Nach § 73 Absatz 9 Sozialgesetzbuch V dürfen Vertragsärztinnen und Vertragsärzte nur elektronische Programme nutzen, die unter anderem die vergleichenden Informationen nach Absatz 8, Informationen zu Rabattverträgen nach § 130a und § 130e, Medikationsplanfunktionen nach § 31a und § 334 sowie Arzneimittelsicherheitsinformationen enthalten, und die von der Kassenärztlichen Bundesvereinigung für die vertragsärztliche Versorgung zugelassen sind. Absatz 8 verlangt dabei ausdrücklich Informationen, die Handelsbezeichnung, Indikationen und Preise so darstellen, dass sie unmittelbar einen Vergleich ermöglichen.
Stufe 3, die Recherchetiefe. Fachinformation, Interaktionen, Kontraindikationen, Wirkstoffdossiers, Verfügbarkeit und internationale Entsprechungen. Diese Stufe gehört nicht in jeden Verordnungsdialog, aber sie beantwortet die Rückfragen, die im Dialog entstehen. Der übliche Weg dafür ist kein zusätzlicher Datenimport, sondern ein Absprung in eine Rechercheoberfläche.
Was die Pflichtinhalte im Einzelnen umfasst, regelt nicht das Gesetz selbst, sondern der Anforderungskatalog für Verordnungssoftware und Arzneimitteldatenbanken, Anlage 23 zum Bundesmantelvertrag Ärzte. Die aktuelle Fassung ist Version 5.8, gültig ab dem 1. Oktober 2025. Wer ein Backend baut, sollte diesen Katalog kennen, bevor der Feldsatz festgelegt wird, nicht danach.
Der übliche Weg ist die regelmäßige Datenlieferung in das Backend, nicht die Einzelabfrage je Verordnung. Der Artikelstamm wird täglich aktualisiert, Preisupdates laufen im 14-tägigen Rhythmus, und der vereinbarte Rhythmus bestimmt zugleich die zulässige Vorhaltedauer im eigenen System. Lizenziert wird je Praxis oder je lebenslanger Arztnummer.
Der Grund für die Lieferung statt der Live-Abfrage ist die Antwortzeit: Ein Verordnungsdialog verträgt keine Netzwerklatenz gegenüber einem fremden System, die Daten liegen deshalb im Backend. Vier Punkte sind dabei zu klären.
Beim Lizenzmodell gibt es zwei gangbare Konstruktionen. Entweder Sie lizenzieren für alle Praxen eines angebundenen Praxisverwaltungssystems und melden die Zahl der Praxen oder Ärztinnen und Ärzte, oder jede Praxis entscheidet selbst und wird einzeln freigeschaltet. Beide Modelle funktionieren, sie unterscheiden sich in der Abrechnung, nicht in der Technik. Entscheidend ist, dass die Zähleinheit der Datenlizenz dieselbe ist wie die Zähleinheit Ihres eigenen Preismodells, also Praxis oder lebenslange Arztnummer. Sonst entsteht eine Marge, die mit der Nutzung in die falsche Richtung läuft.
pharmazie.com ist die konsolidierte Arzneimitteldatenplattform der DACON Datenbank Consulting GmbH, am Markt seit 1989. Sie vereint 25+ pharmazeutische Fachdatenbanken in einer einzigen Suche, der Eisbergsuche®. Zielgruppe sind ausschließlich Fachkreise im Gesundheitswesen. Der Fokus liegt auf DACH, die Arzneimitteldaten decken 50+ Länder ab. Die Daten werden täglich aktualisiert. Für ein E-Rezept-Backend sind vier Bestandteile einschlägig.
Arzneimitteldaten liefern die Produktebene, nicht die Zulassung der Software, nicht den Medikationsplan-Lizenzumfang und nicht die tatsächliche Verfügbarkeit einer Packung. Diese drei Punkte lassen sich nicht durch einen größeren Feldsatz lösen, sie gehören als eigene Arbeitspakete in die Projektplanung.
Die Zulassung erhält die Software, nicht die Datenquelle. Kein Datenanbieter kann Ihnen eine Zulassung nach § 73 Absatz 9 Sozialgesetzbuch V mitliefern. Der Datenbezug ist Voraussetzung dafür, dass die aufsetzende Verordnungssoftware die Pflichtinhalte darstellen kann, mehr nicht. Planen Sie das Zulassungsverfahren als eigenen Arbeitsstrang mit eigener Zeitschiene.
Medikationsplandaten sind ein eigener Umfang. Sie folgen einem eigenen Lizenz- und Aktualisierungsrahmen und sind nicht automatisch Bestandteil einer Artikelstammlizenz. Wer den Medikationsplan im Produktplan hat, verhandelt ihn mit.
Verfügbarkeit ist keine Eigenschaft des Artikelstamms. Ob eine Packung heute tatsächlich beschaffbar ist, steht dort nicht, und ein fehlender Lieferengpasseintrag ist kein Verfügbarkeitsnachweis. Warum das so ist und was stattdessen hilft, steht in unserem Beitrag zu Arzneimitteln, die ohne gemeldeten Lieferengpass nicht lieferbar sind.
Ein E-Rezept-Backend braucht den Verordnungskern und die Wirtschaftlichkeitsebene, also elf Pflichtfelder je Packung, plus Medikationsplandaten als eigenen Lizenzumfang, sobald der Medikationsplan dazukommt. Die gesetzliche Vorgabe adressiert die Verordnungssoftware und ihre Zulassung durch die Kassenärztliche Bundesvereinigung, nicht Ihre Datenquelle; Ihr Feldsatz entscheidet aber darüber, ob diese Zulassung erreichbar ist. Lizenzieren Sie in derselben Zähleinheit, in der Sie selbst abrechnen.
Weiterführend: wie sich eine PZN-Angabe aus einem Rezept gegen Referenzdaten prüfen lässt und wie eine Interaktionsprüfung per Schnittstelle eingebunden wird. Wenn Sie den Feldsatz gegen Ihre Spezifikation legen wollen, buchen Sie eine Demo.
