Pharmaceutical track and trace connects a pack’s identity with the records used to verify and follow it through supply. For a packaging-line project, define the destination market and product scope, the identifier to apply, the verification and reject process, and the data exchanged with the site system.
The US DSCSA and EU Falsified Medicines Directive framework use different supply-chain models. This guide compares their effect on packaging specifications, including the distinction between serialization and aggregation. Motionwell designs the printing, reading, handling and control stations that connect the physical pack with those records.
For covered products, DSCSA combines package identification with electronic, interoperable transaction information and verification duties. EU safety features combine a unique identifier and anti-tampering device, with repository-based verification and decommissioning. Translate the applicable requirements into code content, artwork, line checks and reporting responsibilities; specify case or pallet aggregation separately where the operating or customer requirement calls for it.
The physical layer, meaning the station that prints, the station that reads, the reject that follows a failed read and the controller that keeps the record accurate, is the part we design, and that is the part this article is written from. How that station is laid out on the conveyor and what happens to a pack that fails are on our pharmaceutical serialization page and our code reading and traceability page.
What Is Pharmaceutical Track and Trace Regulating: the Pack, the Data or the Line?
The requirements connect physical packaging with supply-chain records. Identifiers must reach the correct packs, EU safety features include protection against tampering, and the responsible organisations must maintain and exchange the required data. Separate these layers in the equipment scope so artwork, inspection and reporting have named owners.
| Layer | What DSCSA fixes | What EU 2016/161 fixes | Who owns it after go-live |
|---|---|---|---|
| The pack | Product identifiers for covered packages and homogeneous cases | A unique identifier and anti-tampering device on products within the safety-feature scope | The responsible product and packaging organisation |
| The data | Electronic, interoperable exchange of transaction data between trading partners as product moves | Repository upload and the applicable verification and decommissioning duties | The legally responsible participants, supported by their serialization software |
| The line | What has to be printed, read back and recorded per saleable unit and per case | The code content and the print-and-verify requirement | The plant, through the machine and its handover pack |
Use the responsibility column to assign artwork, serial-number management, line verification and reporting. At the line, reconcile issued identities with accepted, rejected, sampled and unused outcomes so the site system receives an accountable result.
Serialization assigns unit identities. Traceability links those identities with events, and track and trace includes the exchange and verification of that information through supply. The packaging line originates pack-level events and communicates with the site serialization system; the project scope defines that interface separately from the wider supply-chain software.
What Does the US DSCSA Actually Require, and From Whom?
The DSCSA is Title II of the Drug Quality and Security Act, enacted in 2013, and the FDA’s DSCSA page is the primary source for its current state. Stripped to what a packaging engineer needs, it asks for two things.
Package identification. Manufacturers and repackagers have product-identifier duties for covered packages and homogeneous cases. Define the responsible participant and packaging operation in the project scope, then specify how the identifier is printed, checked and bound to the physical pack. The station-level design is on our pharmaceutical serialization page.
Electronic, interoperable exchange of transaction data. This obligation falls on the trading partners, not on the pack. At each change of hands, from manufacturer to wholesaler to dispenser, the handoff is recorded and passed on in a form the next party’s system can read. That chain is built at every handoff, never checked once at the end, and it is what the word “trace” refers to.
For a Singapore export project, identify the covered product, trading-partner roles and transactions. The FDA’s current exemptions page sets out the small-dispenser exemption through 27 November 2027, with its 27 November 2026 qualification date and applicable trading-partner provisions. Map that scope to the customer’s actual supply chain and record the required line functions in the URS.
Include the applicable package and homogeneous-case identifiers in the print specification. Keep that requirement distinct from aggregation: a case identity and a record of its child units are different data objects. Define both where the customer’s packing and transaction workflow needs them.
What Does EU FMD and Delegated Regulation 2016/161 Require?
The Falsified Medicines Directive 2011/62/EU set the policy, and Commission Delegated Regulation (EU) 2016/161 set the detail. It has been in application since 9 February 2019, so for a line being specified now it is settled law and not an approaching deadline.
For medicinal products within the applicable safety-feature scope, it requires two packaging features.
The unique identifier. Apply the safety features to the medicinal products within the legislation’s scope, including the relevant prescription status, listed exceptions and national extensions. The European Commission safety-features Q&A, section 1.3 explains that coverage. For each included product, define the identifier and artwork before selecting the print station.
The anti-tampering device. A physical feature that shows whether the pack has been opened. The regulation does not say what form it takes, and on a folding carton it is usually a seal or a label across the opening. For the line it is one more application step, and one with a rule attached: it must never cover the code, because a code under a seal cannot be verified. The interaction between closures and code position is discussed on our capping and sealing systems page.
Repository verification and decommissioning. The system supports checking the identifier against the repository and changing its status at the required supply or handling event. Those supply-chain checks complement the manufacturer’s line checks for a correctly printed and readable identifier.
Define the line’s code-content and print-quality checks together with the repository interface. Under Article 33 of Regulation 2016/161, the marketing authorisation holder or relevant parallel trader ensures the specified information is uploaded. Assign the operational upload route and acknowledgements with that responsible party. Aggregation remains a separate logistics and system-design choice.
What Goes Into the Unique Identifier, and What Does That Decide on the Line?
Both systems use product identity, serial number, batch or lot, and expiry information. Specify the applicable machine-readable carrier, product-code format and human-readable content for each packaging level and market; a homogeneous case can have a different carrier requirement from an individual package.
| Data element | EU 2016/161 | US DSCSA | Where the value comes from on the line |
|---|---|---|---|
| Product code | Product code, plus a national reimbursement number where required | National Drug Code | The product master, selected by recipe |
| Serial number | Unique per covered pack | Unique per covered package | Controlled serial-number allocation, with duplicate prevention |
| Batch or lot | Required | Required | The batch record for the run in progress |
| Expiry | Required | Required | Approved batch data, with controlled entry or transfer and verification |
| Human-readable text | Applicable Article 7 human-readable elements | Applicable product-identifier text | Generated from controlled data and checked against the machine-readable content |
| Physical feature | Anti-tampering device | None required by the identifier rule | A seal or label arrangement that preserves identifier readability |
Two design consequences follow from the table, and both are decided before any hardware is ordered.
The first is data control. Product codes come from approved master data, batch and expiry values from the released batch information, and serials from controlled allocation. Automate these transfers where practical. Any manual entry needs defined permissions, verification and a record of the change.
The second is that the field list sets the print field, and once a second market adds a reimbursement number the panel the artwork leaves free gets tighter. How the print field then constrains the code and the reader is engineered on the labelling and coding systems page; the point here is that the chain starts from the regulation’s field list, so that list has to be confirmed per destination before the artwork is signed off.
How Do DSCSA and EU FMD Differ on Verification?
They answer the same question, is this pack genuine, by two different mechanisms, and the difference changes what leaves the line, though not what happens on it.
DSCSA combines transaction-information exchange with product-identifier verification and processes for suspect or illegitimate product. A complete transaction record supports tracing, but it does not by itself establish that a physical pack is genuine. The packaging line contributes controlled identifiers and pack outcomes to the responsible trading partner’s systems.
EU FMD uses a repositories system. The marketing authorisation holder or relevant parallel trader arranges the Article 33 upload. Supply-chain participants verify and decommission identifiers at the steps required for their activity, including supply to the public. Identifier status and authenticity checks work alongside verification of the anti-tampering device.
| Question | DSCSA | EU 2016/161 |
|---|---|---|
| Where is the pack checked | Transaction-data exchange and the applicable verification steps | Verification and decommissioning steps for the participant’s activity, including supply to the public |
| What the packaging operation contributes | Identifier data and pack outcomes for the responsible trading partner | Identifier data and pack outcomes for the responsible upload organisation |
| What the record has to contain | Required package identity and transaction information | Required unique-identifier data for products within scope |
| What a missing record means | A break in the chain at whichever handoff it is missing from | A pack that fails verification when dispensed |
| What the line has to have produced | Verified identifiers and outcomes for covered packages and homogeneous cases in the agreed packaging scope | Verified identifiers and outcomes for packs within the safety-feature scope |
The last row is the one that matters to a packaging engineer, and it reads almost the same in both columns. Whichever model the destination market uses, the line has to have printed a code whose content matches what the manufacturer will report, read that code back to prove it is there, and reported the outcome for every serial number it was given. The difference between the two regimes lives in the serialization software and in the manufacturer’s reporting. The message set between line and site system carries the outcome upward, and that handshake is described in full on the serialization page.
Is Aggregation Required, or Is It a Manufacturer’s Choice?
Serialization and aggregation are two different records. The first says what each unit is; the second says where it is. The unit, case and pallet chain, and how it is built out of reads, is on our code reading and traceability page. The question for a specification is narrower: does either regulation oblige you to build the second record, or is somebody else asking for it?
EU 2016/161 recital 20 allows scanning an aggregated code to support verification of multiple identifiers. The DSCSA statutory framework also permits aggregation among the methods used to manage and exchange package-level information. Treat the selected parent-child model as an explicit system requirement, with its operational purpose, data format and acceptance tests.
So for a specification, aggregation is being done for one of three reasons, and each reason changes where it gets built.
| Reason for aggregating | Who is asking | What it changes in the line scope |
|---|---|---|
| The selected data-exchange workflow uses aggregation | The supply-chain system design | Define case identity, child-unit records and the evidence needed for the chosen exchange method |
| A trading partner or the customer’s corporate standard requires it | The contract | The record format and the reporting interface are specified by the customer and tested at acceptance |
| The warehouse wants one scan per pallet at receipt | Operations | The case packer is designed so the record is a by-product of the packing sequence |
Plan how the system knows which identified units entered each parent container. It may reuse validated upstream reads and tracking or capture identities at the packing station. Include rejects, samples, rework and case reopening in the transaction design. A retrofit review should establish which existing identity records can be trusted and where additional reads or tracking are needed.
What Do These Rules Turn Into at the Coder, the Reader and the Record?
Map the applicable requirements to line functions and acceptance evidence. The following table covers the main printing and verification operations; data exchange, reconciliation and failure handling complete the physical-line interface.
| Requirement in the text | Station that answers it | Evidence the line has to produce |
|---|---|---|
| Code content fixed: product code, serial, batch, expiry | A coder fed from the recipe, the batch record and a serial pool | The string sent to the coder, logged against the serial number, per unit |
| Code content and print quality verified | Read-back and the specified print-quality verification method | Decoded content compared with intended data, with quality evidence recorded according to the approved test method |
| Anti-tampering device present and the code still readable | Seal or label application and verification arranged for the pack layout | Presence and position checked, including readability after any operation that could obscure or damage the code |
Three points of practice sit behind that table and are worth stating plainly.
Bind each event to the correct identity. Record decoded data, comparison and inspection results, and the final pack disposition with a stable serial or tracking key. Whether the record is assembled in the controller or site software, validate event ordering, durable transfer, duplicate handling and recovery after communication loss.
Print and verification are separate functions. They may use integrated equipment or separate stations. Validate that the read checks the actual mark, compares it with the intended content and assigns the result to the correct pack. Where stations are separated, tracking must preserve that identity through the transfer and reject decision.
The acceptance test includes normal production and failure handling. Challenge the station with bad codes, a duplicate serial, a blocked reject, loss of the site-system connection and a restart with packs on the conveyor. Check containment, recovery and complete serial reconciliation against the approved protocol. The witness roles and evidence belong in the factory acceptance test checklist. For stations added to an existing line, the handling interfaces are covered in our packaging line integration guide.
When Does 21 CFR Part 11 Apply to the Track and Trace Record?
Part 11 addresses electronic records and electronic signatures within its scope. Use the current eCFR text to identify which required records or submissions the system handles electronically, then define access, audit trail, retention and signature functions with the quality team. The applicability follows the record and its use, not the PLC or software brand.
List the serialization records that support the manufacturer’s regulated activities, their owners and their retention requirements with the quality team. Use that assessment to define the equipment’s electronic-record functions and validation scope. The design review should cover:
- Define named users, roles and command authority in the system that manages access, including any controller or operator-interface functions that need them.
- Changes to the recipe, the serial pool and the reject rules are recorded with who, when and the previous value.
- The line clock is synchronised with the site system, because a record stamped by a controller and a report stamped by a server have to agree about the order of events.
- The record is retained for the period the manufacturer’s procedures require, in a form that can be read without the machine that made it.
Those four items are far easier to design in than to add to a running line, and they are the same four whether the driver is DSCSA, 2016/161 or the customer’s corporate standard. The equipment view of Part 11 is on our electronic batch records page, and the questions a plant asks about it are answered in our 21 CFR Part 11 guide. Where the recipe and the user accounts live, on the panel or in the plant’s supervisory system, changes what has to be validated and where, and that division is discussed in our SCADA vs HMI guide.
What Does One Line Shipping to Both Markets Have to Handle?
A line built in Singapore for both markets needs approved layouts, data formats and pack features for each destination. Recipes can select the configuration; print-field size, reader capability and tamper-evident handling must also accommodate the physical differences.
| Item | US batch | EU batch | How the line handles the difference |
|---|---|---|---|
| Product code | National Drug Code | Product code, with a reimbursement number where required | Recipe selects the code and its format |
| Human-readable text | Applicable product-identifier text | Applicable Article 7 elements | Recipe selects the approved print layout |
| Physical feature | None required by the identifier rule | Anti-tampering device | Seal or label station enabled or disabled by recipe, with change parts where the seal format differs |
| Reader recipe | Matches the US layout | Matches the EU layout | Reader recipe bound to the same recipe as the coder, so the two cannot be selected separately |
| Upward report | Pack outcomes and identifiers supporting the trading partner’s transaction workflow | Pack outcomes and identifiers supporting repository upload | The line exchanges the agreed data with the selected serialization system; supply-chain reports are tested at that interface |
The rule that makes this workable is that the artwork, the code content, the reader recipe, the reject rules and the physical feature are one recipe, selected together. A changeover between markets is then a recipe selection plus whatever change parts the tamper-evident seal needs, and the batch record states which market’s rule the run was made under. Where the changeover between formats is a productivity problem in its own right, the ways of shortening it are in our guide to reducing changeover time.
For a dual-market line, map each test to the functions and recipes it covers. Common reject or reconciliation functions can share evidence where the configuration and risk assessment support that reuse; market-specific content, artwork and interface behaviour need their own checks. Include a readable code with the wrong market data in the challenge set.
Which Inputs Complete the Packaging-Line Specification?
Build a product-and-market matrix with the customer’s regulatory and packaging teams. Link each required identifier, safety feature and transaction record to the station or software function that supplies it.
Record five inputs in the specification because they determine the station list and acceptance criteria.
- The destination markets and the current text for each. The field list, the human-readable requirement and the physical feature follow from this, and a market added after artwork approval reopens the print field.
- The customer’s corporate standard. It can go beyond what either regulation asks, and it commonly names the grade the code must reach and the conditions it is measured under. How a grade is stated and why the conditions matter is on the code reading page.
- Who owns the serial pool and who reports. Usually the manufacturer and its serialization software vendor, and the line’s interface to them has to be agreed before either side writes code.
- Whether aggregation is in scope, and why. The three reasons in the table above lead to three different designs, and a case packer built without it is expensive to change.
- Which failure cases the acceptance test demonstrates, and who signs each. Bad codes, duplicates, a blocked reject, a lost link and a restart with packs on the line. A protocol without those is a demonstration of the printer, not of the requirement.
The wider production context for a serialised packaging line, from filling through to palletizing, is on our pharmaceutical and packaging automation page.
Where Does the Data Requirement Land on the Line?
A pharmaceutical track and trace specification should connect each applicable market requirement to a pack operation and a data record. Define identifier content, verification, reject handling, serial reconciliation and the reporting owner. Add aggregation where the chosen supply-chain workflow needs it, then test the physical line and software interface together on normal and fault cases.