.png)
ZusammenfassungEine Software, die aus einem Medikationsplan die Bedarfsmenge für drei oder sechs Monate und die dazu passende Packungsgröße berechnet, braucht vier Feldgruppen je Pharmazentralnummer (PZN): die Menge je Packung mit ihrer Einheit, Wirkstoff und Stärke je Anwendungseinheit, die Preisangaben zum Stichtag und den Vertriebs- sowie Verfügbarkeitsstatus. Das Packungsgrößenkennzeichen N1, N2 oder N3 genügt dafür nicht, weil es eine erstattungsrechtliche Einordnung nach angenommener Behandlungsdauer ist und keine Stückzahl. Diese Felder liegen im Artikelstamm und werden über einen lokalen Datenbestand plus einen Einsprung in die Oberfläche bereitgestellt. Dieser Artikel richtet sich an Software- und Plattformanbieter, die ein Medikationsplan- oder Bedarfsplanungsmodul bauen, und an deren Produkt- und Entwicklungsteams.
Das Vorhaben lautet immer gleich: Eine Anwendung übernimmt einen Medikationsplan, also eine Liste von PZN mit der jeweiligen Einnahmehäufigkeit, und beantwortet daraus eine kaufmännische Frage. Welche Packungen und wie viele davon decken einen Zeitraum von drei oder sechs Monaten ab, und welche Packungsgröße ist dabei je Anwendungseinheit die günstigste?
Der Medikationsplan ist dafür ein belastbarer Ausgangspunkt, weil er ein geregeltes Artefakt ist. Nach § 31a Absatz 1 Sozialgesetzbuch V haben Versicherte, die gleichzeitig mindestens drei verordnete Arzneimittel anwenden, Anspruch auf Erstellung und Aushändigung eines Medikationsplans. Nach § 31a Absatz 2 dokumentiert er alle verordneten Arzneimittel, die ohne Verschreibung angewendeten Arzneimittel und Hinweise auf Medizinprodukte, soweit sie für die Medikation relevant sind.
Genau hier entsteht die Lücke. Der Plan sagt, was angewendet wird und in welchem Rhythmus. Er sagt nicht, wie viele Packungen welcher Größe das über einen Quartalszeitraum ergibt. Diese Rechnung ist keine medizinische, sondern eine Stammdatenrechnung, und sie scheitert regelmäßig an derselben Stelle: Die Felder, die sie braucht, stehen nicht im Plan, sondern im Artikelstamm. In Discovery-Gesprächen mit Software- und Plattformanbietern ist das eine der am häufigsten unterschätzten Abhängigkeiten eines solchen Moduls. Das Modul wird als Rechenlogik geplant und ist in Wahrheit zuerst ein Datenbeschaffungsprojekt.
Die Rechnung braucht zwölf Felder je PZN, von denen acht Pflicht sind. Der Kern ist unspektakulär und wird gerade deshalb oft übersehen: Ohne die Menge je Packung und ihre Einheit ist keine Bedarfsmenge bestimmbar, und ohne Wirkstoff und Stärke je Anwendungseinheit ist keine Dosierungsangabe in Stückzahlen übersetzbar.
| Feld | Wofür es in der Berechnung gebraucht wird | Status |
|---|---|---|
| PZN | Eindeutiger Schlüssel, an dem Medikationsplan und Artikelstamm zusammenkommen | Pflicht |
| Menge je Packung | Divisor der Bedarfsrechnung: Bedarf geteilt durch Packungsinhalt ergibt die Packungszahl | Pflicht |
| Einheit der Menge (Stück, Milliliter, Gramm) | Macht die Zahl rechenbar und verhindert, dass Stückzahlen und Volumina vermischt werden | Pflicht |
| Darreichungsform | Entscheidet, ob eine Anwendungseinheit eine Tablette, ein Hub oder ein Volumen ist | Pflicht |
| Wirkstoff und Stärke je Anwendungseinheit | Übersetzt eine Dosierungsangabe in Anwendungseinheiten je Tag | Pflicht |
| Apothekenverkaufspreis zum Stichtag | Grundlage des Preisvergleichs je Anwendungseinheit zwischen den Packungsgrößen | Pflicht |
| Verschreibungspflicht | Steuert, ob die vorgeschlagene Menge überhaupt ohne Verordnung beschaffbar ist | Pflicht |
| Vertriebsstatus und Kennzeichnung „außer Vertrieb" | Verhindert Vorschläge auf Packungen, die nicht mehr handelbar sind | Pflicht |
| Packungsgrößenkennzeichen N1, N2, N3 | Erstattungsrechtliche Einordnung und Filter, ausdrücklich keine Rechengröße | optional |
| Lieferengpassstatus | Zeigt, ob ein größerer Vorrat zum Planungszeitpunkt realistisch beschaffbar ist | optional |
| Festbetrag und Zuzahlungskennzeichen | Nur im Kontext der gesetzlichen Krankenversicherung relevant | optional |
| Packungsbeilage (PIL) | Anzeige für den Nutzer, nicht Teil der Rechnung | optional |
Der Unterschied zwischen Pflicht und optional ist hier kein Komfortmerkmal. Fehlt ein Pflichtfeld, liefert die Rechnung nicht ein schlechteres, sondern ein falsches Ergebnis: Eine Bedarfsmenge, die auf einer nicht mehr vertriebenen Packung beruht, ist nicht bestellbar.
Für die Bedarfs- und Packungswahl brauchen Sie zwei Datenstufen. Die wirtschaftlich-rechtliche Stufe liefert Menge, Preis, Vertriebsstatus und Erstattungsgrößen. Die qualitative Stufe liefert Wirkstoff, Stärke, Darreichungsform und die Produktinformationen. Sobald eine Dosierungsangabe in Anwendungseinheiten umgerechnet wird, brauchen Sie beide.
Die häufigste Fehlannahme in diesem Use-Case betrifft das Packungsgrößenkennzeichen. Es wirkt wie eine Mengenangabe, ist aber keine. Nach § 1 Absatz 1 der Packungsgrößenverordnung erhalten Fertigarzneimittel ein Packungsgrößenkennzeichen „entsprechend der Dauer der Therapie, für die sie bestimmt sind", bestimmt nach der Anzahl der einzelnen Anwendungseinheiten in der Packung:
Entscheidend ist der nächste Schritt. Nach § 5 der Packungsgrößenverordnung regelt das Bundesinstitut für Arzneimittel und Medizinprodukte (BfArM) das Nähere zur Ermittlung der Packungsgrößen mit Zustimmung des Bundesministeriums für Gesundheit und kann dabei „für Arzneimittel eine Behandlungsdauer zugrunde legen, die von § 1 Absatz 1 Satz 2 Nummer 1 oder Nummer 2 abweicht", sofern das auf Grundlage der Fachinformation medizinisch notwendig ist. Die so ermittelten Messzahlen werden im Bundesanzeiger bekannt gemacht.
Praktisch heißt das: Zwei Packungen verschiedener Wirkstoffe, die beide als N2 gekennzeichnet sind, können völlig unterschiedliche Stückzahlen enthalten, weil die zugrunde liegende Messzahl je Wirkstoff festgelegt wird. Wer aus dem N-Kennzeichen auf eine Menge schließt, rechnet systematisch falsch. Das Kennzeichen ist ein Filter und eine erstattungsrechtliche Größe, die Rechengröße ist die tatsächliche Menge je Packung. Die Einordnung der drei Kennzeichen erklärt das Glossar zu den Normgrößen N1, N2 und N3.
Ein zweiter Fallstrick sind Kombinationspackungen. Nach § 1 Absatz 2 der Packungsgrößenverordnung wird das Kennzeichen zunächst für jedes enthaltene Arzneimittel gesondert ermittelt; maßgeblich für die Kombinationspackung ist dann das Kennzeichen des Einzelarzneimittels mit der größten ermittelten Packungsgröße. Ein Modul, das Kombinationspackungen wie Einzelpackungen behandelt, erzeugt hier stille Fehler.
Auf der Erstattungsseite ist die Packungsgröße dagegen sehr wohl eine Kostengröße, nur anders als erwartet. Die Zuzahlung nach § 61 Satz 1 Sozialgesetzbuch V beträgt 10 vom Hundert des Abgabepreises, mindestens jedoch 5 Euro und höchstens 10 Euro, jeweils nicht mehr als die Kosten des Mittels. Weil sie je Packung anfällt, verändert die Wahl der Packungsgröße die Belastung der Versicherten unmittelbar. Das ist eine Größe der gesetzlichen Krankenversicherung und gilt nicht pauschal für andere Kostenträger.
Der tragfähige Weg ist zweiteilig: ein lokaler Datenbestand für alles, was gerechnet wird, und ein Einsprung in die Oberfläche für alles, was nur angezeigt wird. Diese Trennung entscheidet über Antwortzeiten, Datenvolumen und Lizenzumfang.
Teil eins, der lokale Bestand. Die rechenrelevanten Felder werden als Datenlieferung bereitgestellt, üblicherweise als Komplettaustausch im JSON-Format, und decken die PZN ab, die in einem Medikationsplan vorkommen können. Rechnen Sie damit lokal. Eine Bedarfsplanung über zwölf Positionen und sechs Monate löst sonst Dutzende Einzelabfragen aus, und zwar genau in dem Moment, in dem ein Nutzer auf eine Antwort wartet. Beim Komplettaustausch liegt die Versionsverwaltung bei Ihnen: Sie entscheiden, wann ein Stand aktiv wird, und müssen den alten Stand sauber ablösen.
Teil zwei, der Einsprung. Langinhalte wie Packungsbeilage, Produktabbildung und ausführliche Wirkstoffinformationen gehören nicht in den lokalen Bestand, weil sie ihn unverhältnismäßig aufblähen. Der Weg dafür ist ein Deep Link je PZN in die Oberfläche, bei dem die PZN übergeben und die Zielansicht direkt aufgerufen wird. Für den Nutzer entsteht ein Sprung, keine zweite Recherche. Den Vergleich der Integrationsmuster vertieft der Beitrag zur Einbindung einer Arzneimittelrecherche in Fachsoftware.
Die Kopplung, die am häufigsten fehlt. Die Haltedauer des lokalen Bestands muss an den Aktualisierungsrhythmus der Lizenz gekoppelt sein, nicht an die eigene Release-Planung. Ein Bestand, der auf einen zweiwöchentlichen Preisstand ausgelegt ist, darf nicht ein halbes Jahr unverändert in einer App liegen, wenn daraus Preis- und Statusaussagen abgeleitet werden. Welche Haltedauer und welcher Umfang zulässig sind, regelt die Datenlizenz; die Grundlagen dazu stehen im Beitrag zur Rohdatenlizenz für Arzneimitteldaten.
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 dieses Vorhaben sind vier Bestandteile einschlägig:
Eine PZN-bezogene Abfrage über diesen Bestand ist damit kein Zusammensuchen aus drei Quellen, sondern ein Zugriff. Genau das ist der Punkt der Konsolidierung: Menge, Preis, Status und pharmazeutischer Inhalt kommen aus demselben Stand, nicht aus drei Ständen mit drei Aktualisierungsterminen.
Vier Dinge deckt dieser Weg nicht ab, und sie gehören vor den Entwicklungsstart auf den Tisch.
Keine Therapiebeurteilung. Die Daten liefern Stärke, Menge und Darreichungsform. Sie beurteilen nicht, ob ein Dosierungsschema fachlich richtig ist, ob eine Dauertherapie fortgesetzt werden soll oder ob zwei Positionen eines Plans zusammen passen. Für die Interaktionsprüfung ist ein eigener Rückgabefeldsatz nötig, siehe Interaktionsprüfung bei Polymedikation einbinden.
Keine Aussage über den Bestand vor Ort. Der Artikelstamm sagt, dass eine Packung existiert und handelbar ist. Er sagt nicht, ob sie in einer bestimmten Apotheke heute vorrätig ist. Lieferbarkeitsabfragen laufen über die MSV3-Client-Schnittstelle, die auf der Einkäuferseite live und produktiv ist, aber ein Werkzeug des Einkaufs bleibt und kein Endnutzerweg.
Keine Packungsbeilage im lokalen Bestand. Diese Inhalte sind über den Einsprung oder über ChatPIL® zugänglich, nicht als Teil der Datenlieferung. Eine Offline-Funktion, die Packungsbeilagen anzeigen soll, lässt sich auf diesem Weg nicht bauen.
Keine Erstattungsentscheidung. Festbetrag und Zuzahlung sind abbildbar, die Entscheidung über eine Kostenübernahme ist es nicht. Und eine Grenze, die dieser Use-Case besonders berührt: Die Plattform und ihre Daten richten sich ausschließlich an Fachkreise im Gesundheitswesen. pharmazie.com richtet sich nicht an Endverbraucher und ersetzt keine medizinische oder pharmazeutische Beratung. Welche Inhalte eine endnutzerseitige Oberfläche zeigen darf, ist Gegenstand der Lizenzvereinbarung und vor dem Launch zu klären, nicht danach.
Die Berechnung von Bedarfsmenge und Packungsgröße aus einem Medikationsplan steht auf acht Pflichtfeldern je PZN, und das Packungsgrößenkennzeichen ist keines davon: N1, N2 und N3 sind erstattungsrechtliche Einordnungen nach einer je Wirkstoff festgelegten Messzahl, nicht Stückzahlen. Rechnen Sie mit der tatsächlichen Menge je Packung und ihrer Einheit, halten Sie die rechenrelevanten Felder lokal und holen Sie die Langinhalte über einen Einsprung je PZN.
Weiterführend: der Leitfaden zu PZN-Stammdaten und Preisen per API und JSON, der Feldbedarf beim Ausstellen einer Verordnung in Arzneimitteldaten für ein E-Rezept-Backend und die Frage, wann zwei PZN austauschbar sind, wenn eine geplante Packung ausfällt. Die Pflichtangaben einer Packungsbeilage regelt § 11 des Arzneimittelgesetzes.
Wenn Sie prüfen möchten, welche dieser Felder Ihr Modul tatsächlich braucht und in welchem Format sie geliefert werden: Vereinbaren Sie eine Demo und bringen Sie zehn bis zwanzig PZN aus Ihrem Anwendungsfall mit. An echten Nummern ist in zwanzig Minuten geklärt, was in einer Spezifikation drei Wochen offen bleibt.
