.png)
ZusammenfassungRabattvertragsdaten aktuell zu halten heißt, den Vertragsstatus von hunderttausenden Pharmazentralnummern (PZN) gegen die Verträge von annähernd 100 gesetzlichen Krankenkassen abzugleichen, und das im Takt der laufenden Änderungen. Weil pro Kasse eigene Verträge nach § 130a Abs. 8 SGB V gelten, regional differenziert sind und sich alle 14 Tage verschieben können, ist eine einzelne, statische Liste als Datenbasis untauglich. Wer den Status zuverlässig abfragen will, braucht eine konsolidierte, historisierte und maschinell anbindbare Datenbasis, nicht die getrennten Nachschlage-Portale einzelner Kassen.
Grundlage jeder Arzneimitteldatenbank in Deutschland ist der ABDA-Artikelstamm, das offizielle Verzeichnis der verkehrsfähigen Arzneimittel und apothekenüblichen Waren. Er umfasst über 550.000 Artikel (PZN) und wird alle 14 Tage, jeweils zum 1. und zum 15. eines Monats, als Rohdatensatz bereitgestellt. Dieser Stamm liefert Identifikation, Preise (AVP, AEP, ApU), Festbeträge, Packungsgrößen sowie rechtliche Kennzeichen.
Die Rabattvertragsinformation selbst entsteht auf einer zweiten Ebene: Jede Krankenkasse schreibt ihre Verträge nach § 130a SGB V eigenständig aus und veröffentlicht die zugehörigen Vertragspartner. Diese kassenspezifischen Informationen müssen mit dem Artikelstamm verknüpft werden, damit aus einer nackten PZN die Aussage wird, ob und bei welcher Kasse ein Präparat gerade Vertragsartikel ist. Diese Veredelung, die Verknüpfung von Stammdaten und Vertragsstatus, ist der eigentliche Kern einer belastbaren Datenbasis.
Die Landschaft ist nicht statisch, sondern in ständiger Bewegung. Drei Faktoren treiben die Veralterung:
Aus diesen drei Faktoren folgt eine einfache Konsequenz: Die Qualität der Abfrage hängt vollständig davon ab, wie aktuell und wie vollständig die zugrunde liegende Datenbasis ist.
Für den professionellen Einsatz, ob im Backoffice einer handelnden Apotheke, in einem Rechenzentrum oder im Market-Access-Bereich, lassen sich die Anforderungen an die Datenbasis klar benennen.
| Anforderung | Warum sie entscheidend ist |
|---|---|
| Konsolidierung über alle Kassen | Der Vertragsstatus hängt von der abrechnenden Kasse ab. Eine kassenübergreifende Sicht über die IK-Nummer ersetzt das Nachschlagen in getrennten Kassenportalen. |
| Kurzer Aktualisierungstakt | Passt der Datentakt zum Vertragsrhythmus (14 Tage), sinkt das Risiko, dass ein gestern noch gültiger Status heute falsch abgebildet wird. |
| Historisierung | Maßgeblich ist der Status zum Abgabe- oder Bezugszeitpunkt, nicht der heutige. Ohne Zeitbezug ist ein späterer Nachweis unmöglich. |
| Abbildung der Vertragstypen | Mehrpartner- und Open-House-Modelle erfordern eine Oder-Logik, nicht die Anzeige eines einzelnen richtigen Präparats. |
| Maschinelle Anbindung | Große Mengen (Rezeptprüfung, Stammdatenpflege) lassen sich nur automatisiert verarbeiten, nicht per Einzelabfrage. |
Einzelne Krankenkassen stellen eigene Nachschlagewerke bereit, in denen sich der Vertragsstatus ihrer eigenen Präparate abfragen und teils als Liste exportieren lässt. Für die tägliche Praxis genügt das nicht: Wer Rezepte unterschiedlicher Kassen bearbeitet oder Stammdaten für ein ganzes Sortiment pflegt, müsste dann parallel in vielen getrennten Quellen suchen, jede mit eigenem Stand und eigenem Format.
Eine konsolidierte Datenbasis dreht das um: Die Abfrage erfolgt über PZN und IK-Nummer gegen einen einzigen, einheitlich gepflegten Bestand. Das ist die Voraussetzung dafür, dass sich der Status überhaupt zuverlässig, wiederholbar und automatisiert prüfen lässt, statt ihn manuell aus verstreuten Quellen zusammenzutragen.
Eine Datenbank, die nur den heutigen Stand kennt, löst nur die halbe Aufgabe. Beanstandungen und rückwirkende Prüfungen können Monate nach dem Vorgang erfolgen. Entscheidend ist dann die Frage: War dieses Präparat für diese Kasse an genau jenem Stichtag Vertragsartikel, und welcher Preis galt damals?
Eine reine Ist-Zustand-Sicht kann das nicht beantworten. Erst eine lückenlose Historie von Vertragsstatus, AVP und ApU macht den Stand vergangener Stichtage beweissicher rekonstruierbar. Diese Zeitachse ist der Unterschied zwischen einer bloßen Momentaufnahme und einer prüffähigen Datengrundlage.
Für die Anbindung an eigene Systeme gibt es im Wesentlichen zwei Wege, die sich in Aktualität und Integrationsaufwand unterscheiden.
Beim klassischen Weg werden die Datensätze im Aktualisierungstakt als Datei bezogen und in das eigene System eingespielt. Das gibt volle Kontrolle über die Verarbeitung, verlagert aber Aktualisierung und Pflege in die eigene IT. Für Akteure, die große Mengen automatisiert prüfen, etwa Abrechnungszentren, sind mengenbasierte Datenlizenzen der übliche Weg.
Über eine Programmierschnittstelle (API) wird die Datenbasis direkt abgefragt, ohne lokale Updates einspielen zu müssen. Gelten zu einem Stichtag neue Verträge, stehen sie unmittelbar bereit. Eine solche Schnittstelle lässt sich in unterschiedliche Systeme integrieren, von der Warenwirtschaft über ein ERP-System bis zu eigenen Anwendungen. In Verbindung mit einer Lieferbarkeitsabfrage über die MSV3-Client-Schnittstelle, die als Standard-Zusatzmodul live und produktiv verfügbar ist, lässt sich der Vertragsstatus im selben Prozess mit der tatsächlichen Beschaffbarkeit über den Großhandel abgleichen.
Der Bedarf an tagesaktuellen, kassenübergreifenden Vertragsdaten ist nicht auf eine Gruppe beschränkt.
Die Prüfung von Rabattverträgen ist immer nur so verlässlich wie die Daten dahinter. pharmazie.com bündelt den ABDA-Artikelstamm, eine Transparenzliste zum Vertragsstatus über mehr als 300.000 PZN und eine langjährige Preishistorie in einer Oberfläche und aktualisiert die Datenbasis im Zwei-Wochen-Takt. Über die API lässt sich diese Basis in eigene Systeme integrieren, über die MSV3-Client-Schnittstelle mit der Lieferbarkeit verknüpfen. Für handelnde Apotheken mit Großhandelserlaubnis, krankenhausversorgende Apotheken und Akteure mit hohem Prüfvolumen ist das eine belastbare Grundlage, um den Vertragsstatus aktuell zu halten, zu historisieren und automatisiert abzufragen.
