.png)
ZusammenfassungEine Arzneimitteldaten-API ist eine programmierbare Schnittstelle, über die ein Zielsystem einzelne Arzneimittelinformationen zur Laufzeit abruft, statt einen kompletten Datenbestand periodisch als Datei zu importieren. Sie liefert artikelgenaue Stamm-, Preis-, Verfügbarkeits- und Fachinformationsdaten auf Anfrage, üblicherweise adressiert über die Pharmazentralnummer als Schlüssel.
Für IT-Verantwortliche in Softwarehäusern, Großhandlungen, Kliniken und pharmazeutischen Unternehmen ist die Entscheidung zwischen API und Dateilieferung keine reine Geschmacksfrage. Sie bestimmt, wie aktuell Ihre Daten im Betrieb tatsächlich sind, wie hoch Ihr Pflegeaufwand ausfällt und ob Ihr Lizenzmodell mit der Zahl Ihrer Endkunden skaliert oder Sie ausbremst. Dieser Beitrag beschreibt, was eine Arzneimitteldaten-Schnittstelle leistet, woran Sie Anbieter belastbar messen und an welcher Stelle Integrationen in der Praxis am häufigsten scheitern.
Die Abkürzung API bezeichnet im pharmazeutischen Umfeld zwei völlig verschiedene Dinge, und ein erheblicher Teil der Suchanfragen zu „API Pharma“ meint nicht die Software.
| Begriff | Bedeutung | Kontext |
|---|---|---|
| API (Application Programming Interface) | Programmierschnittstelle für den maschinellen Datenaustausch zwischen Systemen | IT, Systemintegration, Softwareentwicklung |
| API (Active Pharmaceutical Ingredient) | Arzneilich wirksamer Bestandteil, im Deutschen der Wirkstoff | Herstellung, Qualitätssicherung, Regulatory Affairs, Einkauf |
Wenn in einem Lastenheft „API-Sourcing“ steht, geht es fast immer um Wirkstoffbeschaffung. Wenn im selben Haus die IT von „API-Anbindung“ spricht, geht es um Webservices. Beide Bedeutungen sind fachlich korrekt und beide sind in derselben Organisation im Umlauf. Klären Sie diese Mehrdeutigkeit früh in Projektgesprächen, denn sie erzeugt regelmäßig Missverständnisse zwischen Fachbereich und IT. Dieser Beitrag behandelt ausschließlich die Programmierschnittstelle. Für die Wirkstoffebene ist der relevante Datenpunkt nicht die Schnittstelle, sondern die Wirkstoffbezeichnung samt ATC-Code und Wirkstärke.
Der zentrale Unterschied ist nicht das Datenformat, sondern der Zeitpunkt der Wahrheit. Ein Flatfile oder ein Datenbank-Dump bildet den Stand zum Zeitpunkt der Erzeugung ab. Zwischen zwei Lieferungen arbeitet Ihr System mit Daten, deren Alter Sie kennen, aber nicht beeinflussen können. Eine API beantwortet die Frage zum Zeitpunkt der Anfrage.
Dem stehen echte Nachteile gegenüber, die Sie ehrlich bewerten sollten. Eine API bindet Ihre Verfügbarkeit an die des Anbieters. Sie erzeugt Latenz an Stellen, an denen ein lokaler Index in Mikrosekunden antwortet. Und sie ist ungeeignet für Massenauswertungen: Wer monatlich den Gesamtmarkt analysiert, ist mit einer Rohdatenlizenz besser bedient als mit 50.000 Einzelabrufen. Die belastbare Architektur ist deshalb in vielen Fällen hybrid, mit lokal gehaltenem Stammdatenkern und per API abgerufenen volatilen Schichten wie Preis, Verfügbarkeit und Lieferengpassstatus.
„Wir wollen keine großen Datenmengen im Portal, sondern über eine API auf einen Service zugreifen, der aktuell ist.“ Geschäftsführer, IT-Dienstleister
Arzneimitteldaten-APIs gewinnen an Bedeutung, weil die Prozesse im Gesundheitswesen zunehmend digital und ereignisgesteuert ablaufen. E-Rezept, elektronische Patientenakte und tägliche Lieferengpassmeldungen verlangen den Datenstand zum Zeitpunkt der Abgabe, nicht zum Zeitpunkt der letzten Dateilieferung. Je kürzer die geforderte Reaktionszeit, desto klarer der Vorteil des Abrufs zur Laufzeit.
Drei Treiber wirken zusammen. Erstens die Digitalisierung der Versorgungsstrecke: Mit dem E-Rezept und der elektronischen Patientenakte (ePA) entstehen Prozesse, die eine verordnete PZN zur Laufzeit auflösen, auf Abgabefähigkeit prüfen und dokumentieren müssen. Zweitens die Volatilität der Daten selbst: Rabattvertragslagen, Festbeträge und Engpassmeldungen ändern sich in Takten, die ein manueller Importlauf nicht mehr einholt. Drittens der Kostendruck auf die IT: Wer den Bestand nicht mehr lokal vorhalten und synchronisieren muss, senkt Betriebsaufwand und Lizenzrisiko zugleich.
Arzneimitteldaten werden selten um ihrer selbst willen abgerufen. Sie sind Zulieferung für einen Prozess in einem führenden System. Die häufigsten Ziele:
Diese Ziele unterscheiden sich in einem entscheidenden Punkt: Manche brauchen wenige Felder zu vielen Artikeln, andere viele Felder zu wenigen Artikeln. Klären Sie das vor der Anbieterauswahl, denn es entscheidet darüber, ob Ratengrenzen oder Feldtiefe Ihr limitierender Faktor wird.
Eine Arzneimitteldaten-API ist in der Regel ein REST-Webservice: Das Zielsystem stellt eine HTTP-Anfrage an einen Endpunkt, adressiert einen Datensatz über die PZN und erhält die Antwort strukturiert als JSON. Der Zugriff ist authentifiziert, üblicherweise über einen Zugangs-Token oder Schlüssel je anfragendem System. Die zurückgelieferten Felder folgen einem dokumentierten Schema.
Praktisch heißt das: Ein Abruf richtet sich an einen Endpunkt je Datenart, etwa Stammdaten, Preis oder Verfügbarkeit, und liefert genau die Felder dieser Schicht zurück. Die Antwort im JSON-Format ist maschinenlesbar und lässt sich ohne Umweg über einen Datei-Parser direkt weiterverarbeiten. Neben JSON sind XML und für Massenabzüge dateibasierte Formate wie CSV verbreitet. Die Authentifizierung je System erlaubt es zugleich, Abrufmengen und Berechtigungen pro Anbindung zu steuern.
Eine Sonderrolle spielt die Verfügbarkeitsabfrage gegenüber Großhandlungen: Sie folgt in Deutschland dem MSV3-Protokoll. Die reine Abfrage der Lieferfähigkeit ist etabliert. Die Bestellauslösung über diesen Weg ist auf pharmazie.com auf der Einkäuferseite live und als Standard-Zusatzmodul verfügbar, bleibt aber DE-spezifisch und ist kein länderübergreifendes Merkmal der Schnittstelle, nur die Anbieter- oder Serverseite befindet sich noch in der Pilotphase.
Der Zugriff über eine Schnittstelle ist dabei nur der eine Bezugsweg. Der andere ist der klassische Datenexport, bei dem der Bestand als Datei geliefert und lokal gehalten wird. Beide unterscheiden sich systematisch:
| Eigenschaft | REST-API (Abruf zur Laufzeit) | Datenexport / Rohdatenlizenz |
|---|---|---|
| Aktualität | Stand zum Abrufzeitpunkt | Stand zum Lieferzeitpunkt |
| Datenhaltung | Keine lokale Kopie nötig | Vollständige Kopie im eigenen System |
| Beste Eignung | Artikelgenaue Einzelabfragen, volatile Schichten | Massenauswertung, Offline-Verarbeitung |
| Pflegeaufwand | Liegt beim Anbieter | Eigene Ladestrecke, Delta, Historisierung |
| Latenz und Verfügbarkeit | Hängt an der Anbieterverfügbarkeit | Lokal, unabhängig vom Anbieter |
| Lizenzrecht | Recht zum Abruf | Recht zur Haltung und Weiterverarbeitung |
Wann die Mengen- oder Auswertungslogik für eine eigene Datenhaltung spricht, ist im Detail unter Rohdatenlizenz für Arzneimitteldaten beschrieben.
Prüfen Sie eine Arzneimitteldaten-API entlang von sieben Dimensionen. Die ersten beiden werden fast immer geprüft, die übrigen fünf entscheiden in der Praxis über Erfolg oder Scheitern des Projekts.
| Kriterium | Konkrete Prüffrage |
|---|---|
| Abdeckung | Welche Märkte, welche Artikeltypen, welche Datenarten? Sind Rx und OTC enthalten, auch Klinikpackungen und außer Vertrieb gegangene Artikel? |
| Aktualisierungsrhythmus je Datenart | Nicht „wie oft aktualisieren Sie“, sondern pro Schicht getrennt. Preise, Verfügbarkeit, Fachinformation und Engpassmeldungen haben systematisch verschiedene Takte. |
| Identifikatoren | Über welche Schlüssel ist ein Datensatz adressierbar? PZN, ATC, GTIN, Zulassungsnummer, nationale Codes anderer Märkte? Reverse-Lookup möglich? |
| Raten- und Exportgrenzen | Wie viele Artikel pro Abruf, wie viele Abrufe pro Zeiteinheit? Was passiert beim Überschreiten: Drosselung oder Fehler? |
| Lizenzform | Schnittstellenzugang oder Rohdatenlizenz? Abrechnung pro Call, pro Endkunde oder pauschal? |
| Verfügbarkeit | Zugesagte Verfügbarkeit, Wartungsfenster, Verhalten bei Nichterreichbarkeit. Gibt es einen Fallback? |
| Versionierung | Wie werden Feldänderungen angekündigt? Laufen alte Versionen parallel weiter und wie lange? |
Der am häufigsten unterschätzte Punkt ist die Aktualisierungsfrage je Datenart. Eine pauschale Antwort wie „täglich“ ist wertlos, weil sie die volatilste Schicht mit der stabilsten in einen Topf wirft. Zur Einordnung die Kadenzen, mit denen die Datenschichten auf pharmazie.com geführt werden:
| Datenart | Takt | Bemerkung |
|---|---|---|
| Preise Deutschland | Zweimal monatlich | Mit Historie zurück bis zur Markteinführung |
| Lieferengpassmeldungen BfArM | Täglich | Volatilste Schicht, hier ist ein Dateiimport strukturell im Nachteil |
| Österreich und Schweiz | Monatlich | Nationale Preis- und Stammdaten |
| Übrige EU-Märkte | Wöchentlich | Grundlage für die Suche nach Alternativen jenseits des Inlandsmarkts |
Die Preishistorie ist dabei kein Nebenprodukt. Wer eine Erstattung nachvollziehen, eine Rückstellung bilden oder eine Preisentwicklung belegen muss, braucht den Stand zu einem vergangenen Stichtag, nicht den heutigen. Fragen Sie deshalb explizit, ob eine API nur den aktuellen Wert oder auch den Wert zu einem Datum liefert.
In deutschen Systemen ist die von der IFA GmbH vergebene Pharmazentralnummer der praktische Verbindungsschlüssel zwischen Ihrem Bestand und einer externen Arzneimitteldatenquelle. Sie ist eineindeutig, achtstellig, prüfziffernsicher und in nahezu jedem relevanten Zielsystem bereits vorhanden. Als Join-Key ist sie damit ausgezeichnet geeignet.
Das eigentliche Problem liegt eine Ebene darunter, und es ist die mit Abstand häufigste Ursache dafür, dass eine technisch fehlerfreie Anbindung fachlich falsche Ergebnisse liefert: Die PZN ist artikelgenau, viele Zielsysteme sind aber auf Produktebene modelliert.
Eine PZN identifiziert genau eine Handelsform eines bestimmten Anbieters. Zwei Packungsgrößen desselben Präparats sind zwei PZN. Derselbe Wirkstoff von zwei Herstellern sind mindestens zwei PZN. Wenn Ihr Zielsystem dagegen ein Feld „Medikament“ führt, unter dem fachlich mehrere Handelsformen zusammenfallen, entsteht eine Abbildung von vielen auf eines. Die typischen Folgefehler:
Die Konsequenz für die Architektur: Entscheiden Sie bewusst, auf welcher Ebene Ihr System die Wahrheit hält. Wenn Sie auf Produktebene modellieren müssen, brauchen Sie eine Aggregationsregel, die fachlich begründet und dokumentiert ist, sowie einen Weg, von der aggregierten Sicht wieder auf die einzelne PZN zu kommen. Prüfen Sie deshalb bei jeder API, ob sie neben dem PZN-Lookup auch einen Reverse-Lookup und eine Auflösung über den Wirkstoff anbietet.
Der ABDA-Artikelstamm ist der zentrale wirtschaftlich-rechtliche Stammdatensatz für in Deutschland verkehrsfähige Arzneimittel und apothekenübliche Produkte. Über eine API binden Sie ihn an, indem Sie je PZN gezielt die benötigten Felder abrufen, statt den kompletten Bestand zu importieren. Grundlage bleibt derselbe Datensatz, der Bezugsweg ist der Abruf zur Laufzeit.
Der Datensatz enthält Basisinformationen wie PZN, Artikelbezeichnung und Packungsgröße, rechtliche Einstufungen wie Verschreibungs- und Apothekenpflicht sowie Preis- und Erstattungsangaben (zur Herleitung siehe Arzneimittelpreise berechnen). Herausgeber ist der ABDATA Pharma-Daten-Service, der den Stamm als Rohdaten im 14-tägigen Takt zum 1. und 15. eines Monats aktualisiert. Auf pharmazie.com ist der ABDA-Artikelstamm einer der konsolidierten Datenbestände und über dieselbe Schnittstelle adressierbar wie die übrigen Schichten. Welche Datenbanken darüber hinaus zusammengeführt sind, beschreibt der Beitrag zur Arzneimitteldatenbank.
Ja. Neben Stamm- und Preisdaten lassen sich beschreibende Texte wie Fach- und Gebrauchsinformationen strukturiert je PZN abrufen und in Shop- und Content-Systeme einspielen. Für E-Commerce ist das der Unterschied zwischen einer Produktseite mit vollständigen Pflichtangaben und einer bloßen Artikelnummer. Der Abruf erfolgt feldweise, sodass nur die tatsächlich benötigten Textbausteine übertragen werden.
Zwei Punkte sind dabei zu beachten. Erstens der Adressat: Fach- und Gebrauchsinformation unterscheiden sich in Detailgrad und Zielgruppe, was ein Shop sauber getrennt führen muss. Zweitens die Aktualität: Diese Texte ändern sich mit jeder Änderung der Zulassung, weshalb der Abruf zur Laufzeit gegenüber einem einmaligen Import im Vorteil ist.
Diese Frage wird häufig zu spät gestellt und kippt dann ganze Projekte. Ein Schnittstellenzugang berechtigt zum Abruf einzelner Datensätze zur Laufzeit. Eine Rohdatenlizenz berechtigt zur Haltung und Weiterverarbeitung des Bestands im eigenen System. Beides sind unterschiedliche Rechte mit unterschiedlicher Preislogik.
Auf pharmazie.com ist die Grenze bewusst als Mengengrenze gezogen: Exporte sind bis 5.000 PZN pro Abruf möglich, darüber hinausgehende Nutzung setzt eine Rohdatenlizenz voraus. Das ist eine klare Linie und beantwortet die Frage, die in Ausschreibungen fast immer offen bleibt, nämlich ab wann aus Nutzung eine Datenhaltung wird.
Prüfen Sie bei der Preislogik besonders zwei Modelle kritisch. Eine Abrechnung pro API-Call macht Ihre Kosten von Ihrem Nutzerverhalten abhängig und damit vorab nicht kalkulierbar. Eine Abrechnung pro angebundenem Endkunden trifft Softwarehäuser hart, weil sie den Datenbestand einmal brauchen, aber vielfach zahlen. Beide Modelle sind verbreitet, beide sind für bestimmte Konstellationen sinnvoll, und beide sollten Sie gegen Ihr eigenes Wachstumsszenario durchrechnen, bevor Sie unterschreiben.
Eine Integration wird nicht am Tag der Inbetriebnahme bewertet, sondern im dritten Betriebsjahr. Vier Punkte entscheiden darüber, ob sie dann noch trägt.
Verhalten bei Nichterreichbarkeit. Klären Sie vorab, was Ihr System tut, wenn die Schnittstelle nicht antwortet. Ein Abbruch mit Fehlermeldung ist bei einer Preisauskunft vertretbar, in einer Verordnungsstrecke dagegen nicht. Verbreitet und sinnvoll ist ein gestufter Rückfall: zuerst ein lokaler Zwischenspeicher mit ausgewiesenem Alter, dann eine explizite Kennzeichnung im Interface, dass der angezeigte Wert nicht taggenau ist. Was Sie vermeiden sollten, ist ein stiller Rückfall auf alte Daten ohne Hinweis, denn genau daraus entstehen Fehler, die niemand bemerkt.
Umgang mit unbekannten Schlüsseln. Eine PZN, die keine Treffer liefert, ist selten ein Tippfehler. Meist handelt es sich um einen gelöschten Artikel, der im eigenen Bestand weitergeführt wird. Behandeln Sie diesen Fall deshalb nicht als technischen Fehler, sondern als fachliches Signal und protokollieren Sie ihn auswertbar. Eine steigende Zahl unbekannter Schlüssel ist der zuverlässigste Frühindikator dafür, dass Ihr Stammdatenbestand veraltet.
Feldänderungen. Datenmodelle ändern sich, weil sich Regulatorik ändert. Klären Sie, ob neue Felder additiv eingeführt werden, ob es einen Ankündigungszeitraum gibt und wie lange eine abgelöste Version parallel erreichbar bleibt. Ein Anbieter ohne verbindliche Aussage dazu verlagert ein Planungsrisiko vollständig zu Ihnen.
Protokollierung. Halten Sie fest, welche Anfrage wann welche Antwort erhalten hat. Das ist nicht nur Betriebsdiagnostik. In Prozessen, in denen ein Beschaffungs- oder Prüfversuch nachweisbar sein muss, ist das Abfrageprotokoll der Nachweis. Wer es erst nachrüstet, wenn es gebraucht wird, hat es für den relevanten Zeitraum nicht.
Mittelfristig verschiebt sich die Datengrundlage von national vergebenen Nummern hin zu standardisierten, strukturierten Produktinformationen. Die maßgebliche Entwicklung ist die Umsetzung der ISO-IDMP-Standards durch die Europäische Arzneimittel-Agentur, deren Datenmodelle auf FHIR-Ressourcen abgebildet werden. Die EMA dokumentiert Umfang und Zeitplan in ihrer Übersicht zu den ISO-IDMP-Standards.
Praktisch bedeutet das: Informationen, die heute als Freitext in der Fachinformation stehen, werden zunehmend als adressierbare Felder verfügbar. Für Integrationen ist das ein Gewinn, weil sich damit Fragen maschinell beantworten lassen, die heute gelesen werden müssen. Es bedeutet aber nicht, dass die PZN verschwindet. Sie bleibt der Schlüssel für alles, was mit Bestellung, Abgabe und Abrechnung in Deutschland zu tun hat. Realistisch ist eine Koexistenz: national vergebene Handelsformkennungen für den operativen Prozess, IDMP-Kennungen für die regulatorische und wissenschaftliche Ebene. Eine API, die beide Welten adressierbar macht und aufeinander abbildet, wird deshalb an Wert gewinnen.
Für rein deutsche Stammdatenfragen gibt es mehrere tragfähige Wege, und die Entscheidung fällt meist über Preis und vorhandene Integrationen. Der Unterschied wird dort deutlich, wo eine Frage mehrere Datenschichten oder mehrere Länder gleichzeitig berührt: wenn ein Artikel im Inland nicht lieferbar ist und Sie wissen müssen, ob es in einem anderen Markt eine wirkstoffidentische Alternative gibt, und zugleich, was sie kostet und ob sie beschaffbar ist. Genau für diese schichten- und länderübergreifenden Fragen über den DACH-Raum und 50+ Länder hinweg ist eine konsolidierte Quelle die vollständigste Antwort, weil die Alternative darin besteht, drei bis fünf Einzelquellen selbst zu verbinden und dauerhaft synchron zu halten.
Fordern Sie vor jeder Entscheidung einen Testzugang an und prüfen Sie ihn mit Ihren eigenen PZN, nicht mit den Beispieldaten des Anbieters. Nehmen Sie bewusst schwierige Fälle: einen außer Vertrieb gegangenen Artikel, eine Klinikpackung, einen Artikel mit aktueller Engpassmeldung und einen mit führender Null. Diese vier Fälle zeigen in kurzer Zeit, ob eine Schnittstelle für Ihren Anwendungsfall trägt.
Dieser Inhalt richtet sich an Fachkreise und stellt keine medizinische Beratung dar. Zuletzt geprüft: Juli 2026.
