FMD for community pharmacies: the DataMatrix you already scan, and what it could be doing for your stock

the most expensive scan in your pharmacy does the least work

Every prescription pack that crosses your counter gets scanned. Has done since February 2019. The Falsified Medicines Directive made sure of it: the DataMatrix gets read, the serial number gets checked against the national repository, the pack gets decommissioned, the system says OK (or throws an alert, usually about an Italian parallel import), and the pack goes in the bag. Seven years of muscle memory. Tens of thousands of scans a year in even a modest community pharmacy.

Now consider what's inside each of those scans. The GS1 DataMatrix on an FMD pack carries four data elements: the product code (AI (01), the GTIN), a unique serial number (AI (21)), the batch number (AI (10)), and the expiry date (AI (17)). Your dispensing system reads all four — it has to, the verification request needs them. Then it uses the GTIN and serial for verification, marks the pack decommissioned, and throws the rest away. The batch number and the expiry date — the two fields that describe the actual physical stock sitting on your shelves — evaporate the moment the green tick appears.

This is worth sitting with for a second. Community pharmacies spend real labour every month on date-checking: walking the shelves, pulling packs, squinting at embossed expiry dates, maintaining a short-dated list on a clipboard or a spreadsheet. Meanwhile, the dispensing process itself reads the expiry date of every single pack, electronically, at the moment it leaves stock — and the PMR discards it. The pharmacy is paying twice for information it already captured once.

what FMD actually put on the pack

A quick grounding, because the directive gets talked about more than it gets read. Commission Delegated Regulation (EU) 2016/161 — the delegated act under the Falsified Medicines Directive — has applied since 9 February 2019. It requires prescription medicines (with the usual annexed exceptions) to carry two safety features: an anti-tamper device, and a unique identifier encoded in a 2D barcode, in practice a GS1 DataMatrix.

The unique identifier comprises the product code, serial number, batch number, and expiry date, with a national reimbursement number where the member state requires one. Manufacturers upload the serials to the European hub; the data flows to national medicines verification systems; and the pharmacy, as the end of the chain, verifies the pack's authenticity and decommissions the serial at the point of supply. The design goal was falsification — making it impossible to introduce a counterfeit pack with a duplicated or invented serial without the system noticing. At that job, the architecture is what it is and this post has no quarrel with it.

But notice what the regulation's authors had to do to make verification work: they forced batch and expiry into a machine-readable, globally standardised format on essentially every prescription pack in the EU. That second consequence — the one nobody designed for — is the one community pharmacies have left unused for seven years.

a note on the UK, because the picture is genuinely different there

This needs to be stated plainly, because out-of-date FMD content is everywhere and UK readers deserve the actual position as of mid-2026.

FMD safety features ceased to apply in Great Britain on 31 December 2020, at the end of the Brexit transition period. GB pharmacies stopped verifying and decommissioning at that point; there is no FMD obligation in England, Scotland, or Wales.

Northern Ireland kept FMD for a while longer, but no longer has it either. Under the Windsor Framework, FMD safety-feature requirements were disapplied in Northern Ireland from 1 January 2025. The UKNI verification system was shut down and its data deleted. UK-wide packs no longer carry the EU unique identifier requirements.

No replacement UK verification scheme is in operation as of mid-2026. A successor system has been discussed in the trade press for years; nothing is live. So if you practise in the UK: nobody is asking you to scan FMD codes today, and this post is not pretending otherwise.

What remains true everywhere — GB included — is the physical fact of the barcode. Manufacturers serialise for the EU market at scale, production lines aren't rebuilt per jurisdiction, and a large share of packs reaching UK shelves still carry a GS1 DataMatrix with batch and expiry encoded, regulation or no regulation. The verification obligation died; the data on the pack didn't. Everything below about receiving-side scanning applies wherever the code is physically present — which is most of the developed world's prescription packs, and under DSCSA, the US's parallel serialisation regime, every salable unit in America too.

the stock record you could be getting for free

Here is the operational argument, in one sentence: a pharmacy that scans the DataMatrix at goods-in and at dispense has, as a by-product, a live batch-and-expiry-accurate stock record — and almost no pharmacy does the first half.

Take the two ends separately.

At dispense (EU and Ireland). Your FMD scan already reads batch and expiry. If the PMR retained them instead of discarding them after verification, every dispensing event would decrement stock at the batch level. You'd know not just that you have twelve packs of a given product, but which batches they are and when each expires — updated continuously, by a workflow you already perform, at zero additional labour. The verification scan and the stock scan are the same scan. The only thing missing is software that treats the payload as inventory data rather than as a verification token to be used once and binned.

At goods-in (everywhere the code exists). This is the bigger prize and the more universally applicable one. When the wholesaler tote arrives, the packs in it carry DataMatrix codes whether you're in Cork, Lyon, or Carlisle. Scanning each pack — or each outer, where the aggregation exists — at receiving captures the batch and expiry of stock at the moment it enters the pharmacy. No reading embossed dates off crimped foil. No typing 06/2027 into a field, or more honestly, no skipping the field because the queue is building. We've written about why removing expiry-date typing changes the quality of the whole record: a date captured by scan is right every time; a date captured by keyboard is right most of the time, and "most of the time" compounds into a stock file you can't trust.

The standard objection is workload: "we barely get the tote unpacked as it is — now you want every pack scanned?" Fair, but run the arithmetic honestly. A goods-in scan is about a second per pack, and the receiving scan replaces work rather than adding to it — the alternative isn't zero effort, it's the date-checking labour deferred to the end of the month, performed under worse conditions, against stock that has since been shuffled, split, and partially dispensed. Capturing expiry once at the door, when the pack is in your hand anyway, is the cheapest moment that information will ever be available. Every later moment costs more and yields a worse record.

Put the two together and the monthly date-check changes character. Instead of a wall-to-wall physical search for short-dated stock, the system produces the list — these products, these batches, expiring in the next 90 days, currently in stock — and the physical work reduces to pulling and verifying the named packs. The clipboard process exists because the stock record can't be trusted on expiry; make the record trustworthy and the process shrinks to a fraction of itself. The same record turns batch recalls from a shelf-crawl into a query, and gives the figure that most pharmacies genuinely do not know — what expiry is costing them — an actual evidence base, because write-offs become attributable to specific batches received on specific dates from specific suppliers.

It also sharpens supplier conversations. When goods-in scanning timestamps the expiry of everything received, "this wholesaler keeps sending short-dated stock" stops being an impression and becomes a report. Residual-shelf-life expectations are negotiable when you have the receiving data; they're a grumble when you don't.

why PMRs throw the data away

Not malice — history. FMD compliance arrived in 2019 as a deadline, and PMR vendors implemented it as what it legally was: a verification step. The integration brief was "send the unique identifier to the national system, display the response, decommission." Batch and expiry travelled through the code path because the verification message needs them, and were never wired into the stock module, because the stock module predates the whole affair and was built around pack counts, not batch identities.

So the typical community pharmacy in 2026 runs two parallel systems that don't speak: a verification pipeline that reads batch and expiry thousands of times a month and retains nothing, and a stock record that desperately needs batch and expiry and gets them rarely, manually, or not at all. The DataMatrix sits in the middle, fully capable of feeding both.

The fix is not standards work — GS1 did that decades ago; the AIs are stable, documented, and identical on every pack. The fix is software that parses the full payload and files it where it belongs: a receiving workflow that scans packs into batch-level stock, and a stock record that the dispensing scan decrements. Pharmacies shouldn't have to build this; they should ask for it, and decline systems that can't do it. The test is simple and worth running in any demo: scan one pack from your own shelf and ask to see where the batch and expiry went. If the answer is "into the verification log," you've learned what you needed to.

where ShelfLifePro fits

This receiving-side gap is precisely what ShelfLifePro's GS1 2D barcode scanning addresses. Scan the DataMatrix on any pack — with a handheld scanner or a phone camera — and ShelfLifePro parses the GS1 AIs: (01) product, (10) batch, (17) expiry, (21) serial. At goods-in, that means each pack enters stock with its batch and expiry attached, captured in the second the scanner beeps. No typing, no foil-squinting, no "we'll catch it at the date check."

From there the system does what a batch-aware record should: expiry reports ordered by urgency, short-dated alerts before the stock is unsellable rather than after, recall lookups by batch in seconds, and a stock file that matches the shelves closely enough to act on. For deliveries where scanning every pack is impractical, supplier-file receiving takes the wholesaler's despatch file directly — batch and expiry columns in, batch-level stock out.

None of this asks you to change what FMD already trained you to do. The packs are serialised, the codes are standard, and your team already knows how to scan. The only change is refusing to let the most data-rich object in your pharmacy — that small square of dots you've been scanning since 2019 — keep doing only a quarter of its job.

ShelfLifePro captures batch and expiry from the GS1 DataMatrix you already scan — at goods-in and beyond — and turns it into a live, expiry-accurate stock record. The date check becomes a report, not a ritual.