.png)
SummaryThe ABDA database (ABDA-Datenbank) is the reference drug knowledge base for the German pharmaceutical market, produced by ABDATA Pharma-Daten-Service, a division of Avoxa, which is a subsidiary of ABDA, the federal union of German pharmacists' associations. It supplies the pharmaceutical, clinical and legal content that sits behind German pharmacy software, hospital information systems and physician practice systems: product information, interactions, patient-individual risk checks, substance data and active ingredient dossiers, for German and international medicinal products.
Two things are commonly confused, and getting them straight is the whole point of this article. The ABDA database is the clinical and reference layer. The ABDA-Artikelstamm is the commercial article master file that carries prices, dispensing status and reimbursement flags. They come from the same producer, they are licensed separately, and they answer different questions. This article covers the first one.
The producer is ABDATA Pharma-Daten-Service. ABDATA is not an independent company: it is a business division of Avoxa, Mediengruppe Deutscher Apotheker GmbH, based in Eschborn. Avoxa was formed in 2016 out of several pharmacist-owned media and service companies, and it also publishes the Pharmazeutische Zeitung and runs the expopharm trade fair.
Avoxa in turn is a subsidiary of ABDA, Bundesvereinigung Deutscher Apothekerverbände, the federal umbrella organisation of German pharmacists. That ownership chain explains the character of the data. The ABDA database is not a commercial data product built by an outside vendor and sold into pharmacy: it is editorial content produced inside the profession's own structures, with pharmacists on staff writing and maintaining it.
The practical consequence for anyone licensing the data is that the ABDA database is an editorially curated knowledge base, not a raw regulatory feed. Its content is assessed, harmonised and classified by ABDATA's editorial teams before it reaches a customer system. That is its main value and also the reason it cannot be reconstructed from public sources.
Most confusion in the English-speaking market comes from treating "the ABDA data" as one thing. In practice ABDATA maintains two clearly separated product families.
| Dimension | ABDA database (ABDADatenbank²) | ABDA-Artikelstamm |
|---|---|---|
| Nature of the content | Pharmaceutical, clinical and therapeutic knowledge | Commercial and legal article facts |
| Typical question it answers | Is this combination safe for this patient? | What does this pack cost and may it be dispensed? |
| Granularity | Product, substance and active ingredient level | Article level, one record per PZN |
| Primary consumers | Medication safety checks, clinical decision support | Point of sale, ERP, wholesale, billing |
| Update rhythm | Continuous editorial maintenance | Twice monthly, on the 1st and the 15th |
| Data origin | Regulatory texts, literature, authority communications | Supplier reports via IFA, plus statutory pricing rules |
If your project is about pricing, logistics, ordering or reimbursement, you need the article master file. If it is about therapy, safety or substance-level questions, you need the database. Many real systems need both, which is precisely why the boundary is worth understanding before a licensing conversation.
ABDATA structures its flagship product, ABDADatenbank², as a set of modules that can be licensed in combination. The modular design exists because a hospital pharmacy, a physician practice system and a manufacturer's regulatory team need overlapping but not identical subsets.
| Module | What it covers |
|---|---|
| Fertigarzneimittelmodul (finished medicinal products) | Core product information: composition, dosage form, strength, indications, application |
| AMTS module (medication safety) | Interactions and patient-individual risk assessment, the checks pharmacy software surfaces as CAVE warnings |
| Plus X module | Product images, tablet divisibility, and linked regulatory documents such as SmPCs and Rote-Hand-Briefe (Dear Healthcare Professional letters) |
| Pharmazeutische Stoffliste (pharmaceutical substance list) | Properties of medically and pharmaceutically relevant substances, including excipients |
| Wirkstoffdossiers (active ingredient dossiers) | Clinical and pharmaceutical monographs at active ingredient rather than product level |
Two further elements are worth naming because they shape what the data can be used for.
A CAVE check is a patient-individual risk check that tests a proposed medication against attributes of the specific patient rather than only against other drugs. The term comes from the Latin imperative "beware", and in German pharmacy software it is the standard label for this class of warning.
An interaction check asks whether drug A conflicts with drug B. A CAVE check asks a broader set of questions:
These checks depend on structured, coded data. A free text warning inside an SmPC PDF cannot be evaluated by software. The reason the AMTS module exists is that someone has to convert regulatory prose into machine-comparable attributes, and that conversion is editorial work performed once centrally rather than repeatedly in every pharmacy.
"We would have the option of pulling product information from several different data sources, but then we would still have to process it ourselves." Project manager at a pharmaceutical service provider (translated from German)
The user base is wider than the pharmacy counter that most descriptions stop at.
| User group | Primary use |
|---|---|
| Community pharmacies | Dispensing checks, counselling, substitution decisions |
| Hospital pharmacies | Ward supply, medication review, unit dose and compounding support |
| Physician practice and hospital information systems | Prescribing decision support at the point of prescription |
| Pharmaceutical manufacturers | Competitive and portfolio analysis, regulatory and market monitoring |
| Wholesalers and pharmaceutical traders | Product identification, substitution logic, cross-border sourcing |
| Statutory health insurers and consultancies | Reimbursement analysis, therapy area assessment |
| Software vendors | Embedding the data as the knowledge layer inside their own application |
Note the pattern: most end users never see ABDATA as a brand. They see their pharmacy management system, their hospital information system or their practice software. The data is licensed by the software vendor and rendered inside that vendor's interface, which is why so many German healthcare professionals use ABDA data daily without naming it.
ABDATA licenses its data to organisations, not to individual professionals, and the licence is scoped by module, by user group and by intended use. There are two broad delivery models.
Licence terms, module combinations and pricing are agreed individually with ABDATA and are not published. Anyone planning a budget should treat licence cost, integration effort and the ongoing cost of the update process as three separate line items, because the second and third routinely exceed expectations in raw data projects.
The clinical layer and the commercial layer meet at the PZN, the Pharmazentralnummer, the eight-digit German product identifier assigned by IFA GmbH. The PZN is defined as the uniform national identifier under section 131 SGB V, and it is the join key that lets a system move between the two worlds.
The flow runs in one direction. A supplier reports an article to IFA and receives a PZN. That article record, with its commercial and legal attributes, flows into the ABDA-Artikelstamm on the twice-monthly cycle. ABDATA then enriches and links the pharmaceutical content in the ABDA database against the same identifiers. A pharmacy system scanning a pack therefore resolves one PZN into both a price and a safety profile.
This is why the two products are complementary rather than alternative. A price without a safety check is a transaction with no clinical control. A safety check without a price and a dispensing status cannot complete a dispensing act.
The ABDA database is authoritative for the German market and strong on German-language clinical content. Three limits show up repeatedly in practice.
This is the gap pharmazie.com was built for. Where each of the other sources covers only one slice, pharmazie.com bundles all three data layers, clinical (C.A.V.E. and the ABDA interaction check), commercial (prices, AMNOG, rebate contracts) and logistic (PZN, supply shortages with EU alternatives), plus international product data across DACH and 50+ countries, in a single platform: more than 25 databases, 50,000+ German products and 120,000+ international products behind one parallel search. For cross-layer and cross-border questions, that consolidated view is the most complete single answer available, and it is accessible through a web interface and a REST API rather than requiring a raw data pipeline. DACON Datenbank Consulting GmbH has been building pharmaceutical data infrastructure since 1989.
Access to pharmazie.com starts from EUR 135/month (see pricing), a rare point of transparency in this market, since most of the other data providers publish no public list price and quote enterprise licences only on request.
Three assumptions come up repeatedly in international projects, and all three are wrong.
A fourth point is worth stating plainly for anyone comparing sources internationally. The ABDA database is not equivalent to a public reference such as DrugBank or RxNorm. Those are open scientific and terminology resources. The ABDA database is a licensed, editorially maintained knowledge base built to drive regulated dispensing decisions in one national market, which is a different product with a different obligation attached to it.
Work backwards from the question your organisation has to answer.
This content is intended for healthcare professionals and does not constitute medical advice. Last reviewed: July 2026.
