.png)
SummaryMSV3 is Germany's standardised, internet-based ordering interface between pharmacies and pharmaceutical wholesalers, jointly maintained by three federal associations. It lets a pharmacy's merchandise management system query product availability by Pharmazentralnummer (PZN), place binding orders and retrieve order status in real time, replacing the older MSV2 batch protocol that ran over telephone lines at fixed deadlines. The name denotes a message standard rather than a product, and every large German wholesaler exposes an MSV3 endpoint.
For international teams evaluating the German market, MSV3 is easy to underestimate. It looks like plumbing. It is, but it is the plumbing through which the overwhelming majority of German pharmacy orders now flow, which makes it the difference between modelling German procurement as it works and modelling it as you assume it works.
This article sets out what the interface is, who governs it, how it replaced MSV2, the services it defines, how availability responses are classified, and how a connection is actually established. It closes with the honest limits, including where pharmazie.com uses MSV3 today and where it does not.
MSV3 is maintained jointly by three German federal associations: the DAV (Deutscher Apothekerverband) for pharmacies, PHAGRO for pharmaceutical wholesalers, and ADAS (Bundesverband Deutscher Apotheken-Softwarehäuser) for the pharmacy software vendors. No single vendor owns it, which is the point. It is an industry norm, not a proprietary protocol.
The specification lives in a requirements document, the Pflichtenheft, first published to professional circles on 20 June 2012, with the first reference implementation released alongside it. Pilot runs began in late 2012, and the interface rolled out across 2013 and 2014. It has since advanced through defined releases: version 1.0h is dated 13 May 2014, and the Release 2 requirements reached version 2.0i on 18 June 2018. Because the norm is versioned and public, wholesalers and software houses implement against the same document rather than against each other.
Adoption followed quickly. By 2016, according to PHAGRO, nearly two-thirds of German pharmacies had already moved to MSV3, and it has since become the de facto standard for pharmacy ordering in Germany. The ADAS project page documents the ongoing specification work.
MSV2 was a modem-based batch protocol: orders were collected and transmitted over a telephone or ISDN line at fixed ordering deadlines. MSV3 is an internet-based, real-time protocol: a request is answered in seconds, and orders can be placed flexibly within the pharmacy's delivery windows rather than against a clock.
The shift is not cosmetic. Batch ordering forced pharmacies to plan around the wholesaler's schedule and gave no immediate feedback on whether an item was in stock. Real-time querying inverts that: the pharmacy asks, the wholesaler answers within seconds, and the decision to order is made with the availability answer already in hand.
| Aspect | MSV2 | MSV3 |
|---|---|---|
| Transport | Telephone or ISDN modem line | Internet, web service over HTTPS |
| Timing | Batch, at fixed ordering deadlines | Real time, answered in seconds |
| Availability feedback | None before ordering | Live, per PZN, before ordering |
| Order timing | Scheduled batches | Flexible within delivery windows |
| Post-order data | Limited | Order status, delivery notes, returns |
MSV3 defines a small set of services that a pharmacy system calls against a wholesaler: an availability query, order transmission, order and delivery status, delivery notes, and returns. The first two are the core. The rest close the loop after an order is placed. Delivery notes and returns were added with Release 2 of the specification.
| Service | What it does | Binding |
|---|---|---|
| Availability query (Verfügbarkeitsanfrage) | Checks deliverability, quantity and price by PZN | No, reserves nothing |
| Order (Auftrag) | Places an order, reserves goods, triggers logistics | Yes |
| Order and delivery status | Retrieves confirmation, expected delivery, partial deliveries | Not applicable |
| Delivery note (Lieferschein) | Structured delivery documentation into the pharmacy system | Not applicable |
| Returns (Retoure) | Return processing back to the wholesaler | Not applicable |
The separation between the availability query and the order matters. An availability query is a lookup: it tells the pharmacy what it could get, at what price, without committing to anything. The order is the commitment. Keeping the two distinct is what allows a pharmacy to shop an item across several wholesalers before deciding where to place it.
An availability response is returned per PZN and carries a delivery-capability indicator, not a bare yes or no. That indicator is what turns MSV3 from a messaging format into something a system can act on automatically.
In practice the response distinguishes several states: fully deliverable in the requested quantity, partially deliverable (a quantity below what was asked for, sometimes with a promised remainder), not currently deliverable, and backordered or discontinued. Where a line cannot be served, the response carries a reason or defect indicator, so the ordering system can react without a human, for example by routing the shortfall to a second wholesaler. The exact code catalogue for these states is defined in the Pflichtenheft rather than left to each vendor, and that shared definition is precisely what makes automated multi-wholesaler routing possible. The specific numeric codes live in the specification document, not in vendor marketing.
Each wholesaler is a separate connection. The pharmacy stores an MSV3 configuration per wholesaler: an endpoint URL, a customer identifier (Kundenkennung) and a password issued by that wholesaler. There is no central hub that fans a single login out to every supplier.
A pharmacy dealing with three wholesalers therefore maintains three sets of credentials and three endpoints. Many wholesalers also impose rate limits or daily quotas on bulk availability queries, which a well-behaved integration has to respect. The upside of the per-wholesaler model is real: a pharmacy can compare live availability and price across suppliers and route each order line to the best source. The cost is that connecting, credential management and endpoint configuration are per-partner work, and every new supplier relationship is a new integration to maintain.
MSV3 is a norm, not a network. There is no central switchboard. A pharmacy connects to each wholesaler individually, with its own credentials and its own endpoint.
MSV3 is a technical norm, not a statutory one, but it operates inside the dispensing framework set by section 129 SGB V. The interface moves orders; the law decides which product a pharmacy may or must supply.
Section 129 SGB V governs how pharmacies dispense under statutory health insurance: the framework agreement (Rahmenvertrag) between pharmacies and the funds, substitution (aut idem), and discount contracts (Rabattverträge) under section 130a. Its provisions on non-availability, including the ability to dispense a therapeutically equivalent alternative when the contracted product cannot be supplied, describe exactly the moments where a live availability query earns its keep. The correct product to dispense depends on what is actually deliverable and reimbursable for that patient's insurer, and answering that with confidence means querying availability, price and reimbursement together rather than in sequence. For the broader shortage picture, see our guide to the German drug shortage database.
On pharmazie.com, MSV3 is available at two different maturity levels, and the difference is worth stating plainly rather than blurring.
On the buyer side, where a pharmacy or wholesaler issues the request, both the availability query and digital ordering are live and available as a standard add-on module. A customer can check deliverability and price across their configured wholesalers by PZN and place orders through the MSV3 client, alongside the platform's daily shortage data and the ABDA-Artikelstamm article and price master data. The seller side is still in a pilot phase: the server role in which a supplier receives incoming MSV3 orders is not yet generally available. Integration with ERP systems such as SAP is in evaluation. We describe the buyer-side ordering as the standard module it is, and are equally precise that the supplier-facing server side is not finished yet.
Two further limits deserve to be explicit. First, MSV3 is a German standard and it does not travel. It is not an interface to wholesalers in other countries and it carries no weight outside Germany. The platform's cross-border value, coverage across more than 50 countries, comes from its consolidated databases, useful when you need to source an equivalent product from abroad, not from MSV3. Second, on the German commercial layer, pharmazie.com carries the ABDA-Artikelstamm as its article and price master data. That is what feeds the availability and price view described in our guide to German wholesale drug prices. It is not a substitute for every commercial data feed a pharmacy might separately license, and we do not claim otherwise.
So what is the MSV3 interface? It is the versioned, industry-governed protocol through which a German pharmacy asks a wholesaler what is available and then orders it, in real time, one wholesaler connection at a time. It replaced a batch-and-modem world with a query-and-respond one, and in doing so it became the quiet backbone of German pharmacy procurement.
For anyone building against it, the practical lessons are consistent: treat availability and ordering as distinct operations, plan for per-wholesaler credentials and rate limits, honour the shared response codes so routing can be automated, and remember that the interface stops at the German border. For the surrounding data questions, our guides to the shortage database, wholesale prices and pharmaceutical import pick up where this one ends.
This content is intended for healthcare professionals and does not constitute medical advice. Last reviewed: July 2026.
