Medication Databases: Clinical, Pricing and Logistics Layers

A medication database is a structured, continuously maintained collection of drug data that combines three distinct layers: clinical information such as interactions, contraindications and dosing; commercial information such as prices, reimbursement status and discount agreements; and logistics information such as article numbers, pack sizes and serialization codes. No single national database in Europe carries all three layers completely, which is why pharmaceutical professionals routinely consult four or five sources to answer one question.

That second sentence is the part worth sitting with. Most explanations of drug databases describe them as though they were one kind of thing, differing mainly in size. They are not. The category is defined by a split that runs straight through it, and almost every product in the market is a specialist in one layer and a stranger to the other two.

This article sets out the three layers, explains who covers what, and gets specific about the German and DACH picture, where the fragmentation is sharper than most international teams expect.

The three layers of a medication database

The layers are not a taxonomy invented for convenience. They correspond to three different questions, asked by three different people, answered from three different source systems.

1. The clinical layer. Is this drug safe for this patient? Interactions, contraindications, allergies, dosing, pharmacology. The source is regulatory product information and pharmacological assessment. The reader is a pharmacist or prescriber.
2. The commercial layer. What does it cost, and who pays? Prices, reimbursement status, discount contracts, benefit assessment outcomes. The source is legislation, payer negotiation and published pricing data. The reader sits in market access, procurement or controlling.
3. The logistics layer. Which exact article, and can I get it? Article numbers, pack sizes, availability, serialization codes. The source is the manufacturer registry. The reader works in wholesale, warehousing or hospital supply.

A drug interaction checker with no prices is a clinical-layer product. A price file with no contraindications is a commercial-layer product. Both are legitimate. Neither answers a question that crosses a layer, and most real questions do.

The clinical layer: interactions, contraindications and the CAVE check

Interaction checking is what most people picture when they hear "medication database", and it is the most mature layer. It is also the one with the worst signal-to-noise problem. Systems that flag every theoretical interaction produce alert fatigue, and alert fatigue produces clinicians who dismiss alerts reflexively, which is worse than no alert at all.

The German market has a structured answer to this in the CAVE check. The word "cave" is Latin for "beware", a long-established clinical warning term rather than an acronym. Built on the ABDA database, the CAVE check screens each medicine against a patient profile and organises patient-individual risk into defined modules:

• Sex. Risks that differ by sex, including use in pregnancy and while breastfeeding.
• Age. Paediatric and geriatric constraints on use.
• Diseases and conditions. Contraindications tied to the patient's diagnoses and particular circumstances.
• Allergies. Known hypersensitivities, including cross-reactivities.

Newer versions extend these modules with body weight and renal function. The point of the CAVE check is that it screens against a patient profile rather than against a drug pair in the abstract. That is the difference between "these two substances can interact" and "this matters for this patient, given what you have told the system about them". The former is a literature lookup. The latter is decision support.

On the burden this is meant to address, precision matters more than drama, and the commonly circulated figures are mostly wrong. The frequently quoted range of 44,000 to 98,000 annual deaths comes from the 1999 Institute of Medicine report and refers to deaths from all in-hospital medical errors. That same report put deaths from medication errors specifically at roughly 7,000. Anyone citing the larger number as a medication-error figure has misread the source.

A better anchor for a European audience: a comparison of routine hospital data from England, Germany and the USA found coded adverse drug event prevalence of 4.78% in Germany, against 3.22% in England and 5.64% in the USA. Roughly one in twenty German inpatients. The data is from 2006 and should be read as an order of magnitude rather than a current measurement, but it is correctly attributable and it is about German hospitals. The literature consensus is that 30% to 40% of adverse drug reactions are considered preventable. The WHO has estimated the global cost of medication errors at around 42 billion USD, a figure first published in 2017 and restated since.

The commercial layer: in Germany, the price is master data

Here is where international teams most often mis-model the German market.

In many countries, price is a commercial attribute that sits somewhere downstream of the product record. In Germany it is closer to being part of the product's identity. A medicine's reimbursement price is the outcome of a statutory process, it is published, it changes on a schedule, and getting it wrong has consequences that are financial and regulatory rather than merely commercial. A pharmacy that dispenses against the wrong price data faces a retax. That is not a pricing error in the ordinary sense. It is a claim that does not get paid.

Three mechanisms drive most of the complexity:

• AMNOG. New patented medicines are freely priced initially, then subject to a benefit assessment by the G-BA, after which a reimbursement amount is negotiated. The reimbursement amount, not the launch price, is what governs.
• Rabattverträge. Discount contracts between individual sickness funds and individual manufacturers determine which product a pharmacy must dispense for a given patient. Which means the correct answer depends on the patient's insurer.
• Statutory rebates under section 130a SGB V. Manufacturer rebates that adjust the effective price and change with legislation.

The consequence for anyone building or buying a database: you cannot separate the clinical record from the commercial record in Germany and still answer a real question. "Which product should this patient receive" is simultaneously a safety question and a reimbursement question.

For context on scale, and this is a figure worth stating carefully because it is widely misquoted: Germany is Europe's largest pharmaceutical market, but the revenue figure depends entirely on scope. The pharmacy market is reported at roughly 49 billion EUR for 2024, while the total pharmaceutical market is reported at around 64 billion EUR. Different scopes, not different accuracies. Any single figure quoted without its scope should be treated with suspicion, including figures that have appeared on this site in the past.

The logistics layer: PZN, IFA and the ABDA-Artikelstamm

If AMNOG is the law, the article master data is the currency.

Every medicinal product and many related products marketed in Germany carry a Pharmazentralnummer (PZN), an eight-digit identifier. The PZN does not identify a substance or even a product in the abstract. It identifies a specific article: this product, this strength, this pharmaceutical form, this pack size, from this marketing authorisation holder. Two pack sizes of the same medicine are two PZNs.

The registry sits with IFA, to which marketing authorisation holders submit their product and price data. That data flows onward into the article master files that pharmacy and wholesale systems consume, including the ABDA-Artikelstamm, and it updates on a fixed cadence tied to the 1st and the 15th of each month.

The practical implications are unglamorous and they are where most integration projects actually fail:

1. The PZN is the join key. Clinical data, price data and availability data reconcile on the PZN or they do not reconcile at all.
2. The cadence is not continuous. Data changes in defined windows, which means "current" is a question about which window you are in.
3. Article-level granularity is the whole point. Systems modelled at substance or product level cannot express what a German pharmacy or wholesaler actually needs to know.
4. Serialization sits alongside this. Under the Falsified Medicines Directive, prescription packs carry a unique identifier verified against the national system, which is a separate identity layer from the PZN.

The database landscape: who covers what

The category map below compares the sources a pharmaceutical professional in Europe actually evaluates, by the three layers and by geographic reach.

Read the table column by column and the structural point falls out on its own. The US sources are US. The national European sources are national, and mostly single-layer. A single-country, single-layer source cannot answer a question that crosses a layer or a border, and most real questions do both.

That gap is precisely what pharmazie.com was built to close. Consolidating more than 25 databases means the clinical, commercial and logistics layers are queried together rather than separately, and covering more than 50 countries means the cross-border question is answerable at all. For professionals in pharmaceutical trade, hospital pharmacy, market access and regulatory affairs, working across Germany, the DACH region and international markets, it is the most complete single answer available.

"It's a pain to search them all individually. Especially when you want to look in 20 different countries, it's a pain." Manager at a healthcare service provider

Which drug database is used in Germany?

There is no single answer, and the honest version of the answer is more useful than a name.

German pharmacies and wholesalers overwhelmingly consume article and price master data originating from IFA, reaching them through the ABDA-Artikelstamm, typically embedded in their pharmacy or warehouse management system rather than consulted as a website. For clinical reference, Rote Liste and Gelbe Liste Pharmindex are the established names. For market access and reimbursement, the relevant sources are G-BA publications and AMNOG data, which are not in the clinical references at all. For shortages, the BfArM database is the official register.

So the conventional answer to "which database is used in Germany" is: four or five of them, per organisation, usually per question. That is what a market looks like when the clinical, commercial and logistics layers are owned by different institutions under different legal mandates.

It is also avoidable. pharmazie.com carries the ABDA-Artikelstamm, Rote Liste, Gelbe Liste Pharmindex, Austria Codex, AMNOG and G-BA data and daily-updated shortage information in one place, which turns those four or five lookups back into one. For a German professional who also needs an international view, that consolidation is the whole point: it is the difference between assembling an answer and being given one.

Why one query needs five databases

Consider a question that sounds simple. A hospital pharmacist needs an alternative to a product that is unavailable, for a specific patient, that the patient's insurer will reimburse.

Answering it requires: the shortage status of the original (logistics), therapeutically equivalent alternatives (clinical), the contraindication and interaction profile of each alternative against this patient (clinical), the reimbursement and discount-contract status of each alternative for this insurer (commercial), and the availability and pack-level article data for what remains (logistics). Five lookups, three layers, at least four sources, and a reconciliation step in the middle where the pharmacist holds partial answers in their head.

This is the fragmentation cost, and it is paid in minutes per query, thousands of times a year, by the most expensive staff in the building. It is also invisible in any procurement comparison that evaluates databases one at a time on coverage, because the cost does not live inside any one of them. It lives in the gaps between them.

Parallel search across sources is the structural response: query once, see the consolidated answer, rather than query five systems and assemble it yourself. That is the design principle behind our Eisbergsuche®, and it is worth being precise about why it exists. It is not a claim to have replaced the underlying sources. It is a claim that the reconciliation step should be the software's job rather than the pharmacist's.

Cross-border: DACH and beyond

Add a second country and the problem does not double, it changes shape.

The same active substance carries different brand names, different pack sizes, different article numbers, different reimbursement status and different availability in each market. Germany, Austria and Switzerland are three separate data regimes with three separate registries and no shared identifier. A PZN means nothing in Switzerland. The Austrian and German products with the same brand name may not be the same article.

For parallel importers, international wholesalers and anyone sourcing against a German shortage, this is the daily work: establishing what the equivalent product is in another market, whether it is available, and whether it can be legally imported. National databases cannot answer cross-border questions, because being national is what they are for.

Integration: APIs, ERP and e-prescribing

Most medication data is not read by humans. It is consumed by systems: pharmacy management software, hospital information systems, wholesale ERP, e-prescribing, webshops.

Which makes integration characteristics as important as coverage, and easier to evaluate honestly:

1. Delivery. REST API, flat file, or a database dump? Push or pull?
2. Cadence. How often does data update, and does the update cadence match your business cycle? German price data on a fortnightly cycle is a different integration problem from shortage data that changes daily.
3. Identity. Which keys are exposed, and do they join to what you already hold?
4. Licensing. Raw data licence or interface access? These are very different commercial arrangements and they are frequently confused during procurement.

The direction of travel across the industry is toward structured, queryable product information, most visibly in the EU's move to electronic product information built on HL7 FHIR. The document-shaped era of drug data is ending slowly, and the systems being specified now will outlive it.

How to evaluate a medication database

A checklist that survives contact with a vendor demo:

1. Which layers does it actually carry? Clinical, commercial, logistics. Ask for all three explicitly and expect at least one gap. A vendor who claims all three completely, in every market, is describing something that does not exist.
2. Which jurisdictions, and at what depth? "International" often means product names without prices. Ask what is present per country, not how many countries appear on the map.
3. What is the update cadence per data type? One number for the whole product is a red flag; prices, shortages and clinical texts do not move at the same speed.
4. What is the identifier strategy? How does it join to your existing master data?
5. Can it answer a cross-layer question in one query? Bring your own real example to the demo. Ideally the ugliest one you have.
6. Raw data or interface, and what are you licensed to do with it?
7. What does it not have? The most useful question in the meeting, and the answer tells you how the vendor will behave for the next three years.

On cost, pharmazie.com is transparent where most of the field is not: access starts at from EUR 135/month (pricing), while most of the other sources listed here publish no public list price and quote only on request.

This content is intended for healthcare professionals and does not constitute medical advice. Last reviewed: July 2026.