Serialization across ANVISA, FDA and the EU: what actually differs

Serialization projects are usually scoped around the printer. A unique identifier goes on each saleable unit, a camera verifies it, the line runs. That part is well understood and, by now, largely commoditised.

The effort lands elsewhere: in what happens when a code is unreadable, in whether the pack hierarchy has to be maintained, and in the fact that the same physical product carries different obligations depending on which market it is destined for.

Aggregation is the dividing line

Marking individual units is one problem. Maintaining the parent-child relationship — which units are in which bundle, which bundles are on which pallet — is a different one, and it is where the operational cost concentrates.

Aggregation forces the packaging line to hold state. Every repack, every rejected carton, every partial case has to update a hierarchy that must remain accurate through the whole flow. A line that handles the happy path perfectly and loses its hierarchy on the first exception has not solved the problem; it has moved it to the warehouse.

Serialization is judged on the exception, not on the nominal run. Any system prints codes correctly when nothing goes wrong.

What differs by market

The obligations converge on a similar idea — a unique identifier that can be verified — but they diverge in ways that shape the system.

• Brazil (ANVISA) — the framework centres on a national traceability system with reporting of events by the actors in the chain. The practical consequence is that the plant must produce event records in the expected structure and on the expected schedule, which makes the reporting interface a first-class part of the project rather than an afterthought.
• United States (DSCSA) — built around transaction information passing between trading partners, moving toward interoperable, electronic, package-level tracing. The weight here falls on exchanging and retaining data with partners, and on being able to respond to verification requests.
• European Union (FMD) — a repository model with an anti-tampering device, where packs are uploaded to a hub and decommissioned at the point of dispense. The distinguishing operational demand is upload discipline: the pack must be in the system before it can be dispensed.

A plant that ships to more than one of these is not implementing three systems. It is implementing one serialization capability with per-market profiles — and the design question is whether those differences live in configuration or in code. Configuration ages far better, because regulations change on a schedule nobody controls.

The exceptions that decide the project

These are the cases that separate a line that runs from a line that stops:

1. A code prints badly and fails verification. The unit must be rejected and its identifier retired in a way that leaves an auditable trace — not silently reused.
2. A case is opened after aggregation. The hierarchy has to be updated rather than invalidated, or every downstream scan disagrees with the record.
3. A batch is partially reworked. Some identifiers survive, some do not, and the system needs to represent both without a manual spreadsheet reconciling them.
4. Connectivity to the external repository fails mid-run. Either the line stops, or it continues and queues — and that decision should be a deliberate, documented policy rather than an emergent behaviour.

Where it meets the batch record

Serialization answers where a unit went. It says little about how it was made. The two become genuinely useful when connected: an identifier that can be traced back to the batch, and from the batch to the process conditions under which it ran.

That link is what turns a recall from a market-wide action into a targeted one, and it depends on the electronic batch record holding execution data that is itself trustworthy — the same data integrity properties that apply to any regulated record apply to the serialization event log as well.

Scoping advice that saves rework

• Decide aggregation early. Retrofitting it onto a line designed only for unit marking is close to a rebuild.
• Treat per-market differences as configuration, and prove it by adding a second market before go-live rather than after.
• Specify exception handling in the URS with the same detail as the nominal flow, because that is what operations will live with.
• Keep the event log immutable and complete, including the rejected and retired identifiers. A gap in that log is a gap in the traceability claim.

The systems side of this sits in product traceability and NEO TRACK, within the broader manufacturing execution picture — and our note on what an EBR changes covers the execution record it should connect to.