DSCSA and Serialization: Track-and-Trace, EPCIS, and Interoperability

The Drug Supply Chain Security Act (DSCSA) is the U.S. law that turned the prescription drug supply chain from a paper-and-trust system into a serialized, electronic, interoperable one. If you work in quality, supply chain, IT, or regulatory at a manufacturer, repackager, wholesale distributor, or dispenser, you will at some point own a piece of this: the serial numbers on the carton, the data exchanged with trading partners, the verification of a returned product, or the investigation when a number does not match. This article walks through the law, the data standards, the operating procedures, and the quality controls that help a DSCSA program stand up to inspection scrutiny.

The scope here is the United States. The European Falsified Medicines Directive (FMD) and other national serialization schemes share the same DNA (unique identifiers plus verification) but differ in architecture, so they are noted only where the contrast matters.

What DSCSA is and why it exists

DSCSA is Title II of the Drug Quality and Security Act (DQSA), signed into law in November 2013, codified primarily at section 582 of the Federal Food, Drug, and Cosmetic Act (21 U.S.C. 360eee-1). It replaced a patchwork of state pedigree laws (notably the older Florida and California pedigree requirements) with a single federal framework.

The stated goal: protect patients from counterfeit, stolen, contaminated, diverted, or otherwise harmful drugs by building an electronic, interoperable system to identify and trace certain prescription drugs as they move through the supply chain. The quality rationale is straightforward. A serialized, verifiable supply chain makes it far harder to insert a falsified product, far easier to scope a recall, and possible to detect diversion and theft before product reaches a patient.

The law set a phased, roughly ten-year build. Two anchor dates matter most:

• November 27, 2017 (manufacturers) and downstream dates through 2020: product identifier (serialization) requirements began.
• November 27, 2023: the statutory start of “enhanced drug distribution security,” the unit-level, fully electronic, interoperable tracing phase. FDA did not enforce on that date. It first granted a one-year stabilization period (announced August 2024) that moved effective enforcement to November 27, 2024, then issued staggered exemptions that pushed the real compliance clock out by trading-partner type. As verified against FDA’s current guidance, those exemption windows ran to May 27, 2025 for manufacturers and repackagers, August 27, 2025 for wholesale distributors, and November 27, 2025 for dispensers with 26 or more full-time employees. Small dispensers (a dispenser owned by a company with 25 or fewer full-time employees licensed as pharmacists or qualified as pharmacy technicians) and their eligible immediate trading partners were originally exempt from the enhanced requirements only through November 27, 2026. On August 6, 2026, FDA extended that exemption to November 27, 2027 while it completes a mandated assessment of whether small dispensers can feasibly adopt interoperable, package-level electronic tracing. Alongside the extension, FDA opened an assessment survey for small dispensers, due September 22, 2026 (a dispenser may designate someone else, including a consultant, to complete it), and once the assessment is final FDA has to publish it for public comment within 30 calendar days and hold a public meeting within 180 calendar days of that publication. As with the earlier exemptions, no notification to FDA is required to use the small-dispenser exemption; a qualifying dispenser and its trading partners simply document their own eligibility, and the extension is not a blanket waiver of every DSCSA obligation, only of the specified enhanced requirements. The practical reading as of August 2026: manufacturers, repackagers, wholesale distributors, and dispensers with 26 or more full-time employees are expected to be in full enhanced-phase exchange; small dispensers and their immediate trading partners get interim relief into late 2027, which means upstream partners still need a workflow for a downstream dispenser that is not yet fully interoperable at the package level. Confirm the live posture for your trading-partner type against the latest FDA guidance, because these dates have moved more than once.

Who is covered (and who is not)

DSCSA defines a small set of trading partners, and your obligations depend entirely on which one you are:

Products in scope are prescription drugs in finished dosage form for human use that are dispensed under a prescription. There is a defined list of exclusions in section 581/582, including blood and blood components for transfusion, radioactive drugs, imaging agents, certain intravenous and medical-gas products, compounded preparations, and others. Over-the-counter drugs are out of scope. When in doubt about a specific NDC, document the product-scope determination; “we assumed it was excluded” is the kind of gap an inspector tends to question.

The product identifier: what actually goes on the package

The serialized identity of a unit is the product identifier (PI). Under DSCSA it must appear on each package and homogeneous case in two forms: human-readable and a 2D data-carrier (in practice, a GS1 DataMatrix barcode). The PI is built from four data elements:

1. NDC (National Drug Code) of the product.
2. Serial number, a unique alphanumeric string for that individual package.
3. Lot number (batch).
4. Expiration date.

In GS1 terms, those map to Application Identifiers (AIs) inside the DataMatrix:

A representative encoded string (FNC1-delimited) looks like:

(01)00312345678906(21)A1B2C3D4E5(17)271130(10)LOT4521

The GTIN (Global Trade Item Number) carries the NDC. A 10-digit NDC is embedded in a 14-digit GTIN with a leading indicator digit, a company prefix, item reference, and a check digit. Getting the NDC-to-GTIN mapping right is the single most common upstream data error, because the NDC can be expressed in several formats (for example 4-4-2, 5-3-2, 5-4-1) and the GTIN has to encode the correct one consistently across the master data, the printed barcode, and the EPCIS data.

The Standardized Numerical Identifier (SNI)

FDA’s older SNI guidance (the 2010 “Standards for Securing the Drug Supply Chain, Standardized Numerical Identifiers” document) defined the SNI as the NDC combined with a unique serial number. DSCSA’s PI is the operational successor. Practically, the SNI concept is what makes a unit globally unique: NDC plus serial.

Aggregation and the hierarchy

Real supply chains do not scan every carton at every step. Aggregation records the parent-child relationship between packaging levels: each unit (each) belongs to a case (or bundle), each case to a pallet. The pallet and case carry an SSCC (Serial Shipping Container Code, GS1 AI 00). Scan the SSCC on the pallet and the system can “inflate” to every serial inside without opening it. This is called inference: you infer the contents of a parent from the aggregation data rather than scanning each child.

Aggregation is not strictly mandated by the statute, but it is operationally essential for unit-level tracing and saleable-returns verification at scale, and trading-partner agreements almost always require it. Poor aggregation accuracy (a serial recorded in the wrong case) is one of the most damaging data-quality failures in the whole system, because it propagates silently until a verification fails downstream.

T3: transaction information, history, and statement

Before November 2023, DSCSA required three documents to travel with product at each change of ownership, collectively the T3:

• Transaction Information (TI): product name, strength and dosage form, NDC, container size, number of containers, lot number, transaction date, shipment date, and the names and addresses of the businesses from whom and to whom ownership is transferred.
• Transaction History (TH): a paper or electronic statement tracing the product back through each prior transaction to the manufacturer.
• Transaction Statement (TS): a written affirmation that the seller is authorized, received the product from an authorized partner, did not knowingly ship suspect or illegitimate product, had systems to comply, did not knowingly provide false TI, and did not knowingly alter the TH.

The enhanced (post-2023) phase changed the shape of this data significantly. Transaction History is eliminated in the enhanced model, because full traceability comes from the connected, package-level electronic data rather than a cumulative pedigree document. The Transaction Information must now be at the package level (include the product identifier, meaning serial numbers) and the entire exchange must be secure, electronic, and interoperable. The Transaction Statement persists. So the enhanced “T2” exchange is package-level TI plus TS, carried electronically.

A common interview trap: candidates say “DSCSA always required serial numbers in the TI.” It did not. The pre-2023 TI was lot-level. Package-level (serialized) TI is the defining change of the enhanced phase.

Sample Transaction Information (package level)

How those package identifiers actually move is the next topic: EPCIS.

EPCIS: the language of interoperable exchange

The industry chose GS1 EPCIS (Electronic Product Code Information Services) as the de facto standard for DSCSA data exchange. EPCIS is a GS1 standard for sharing supply-chain event data answering four questions about each event: What, When, Where, Why (the object/serials, the timestamp, the location, and the business context). The companion Core Business Vocabulary (CBV) standardizes the allowed values for the “Why” (business steps and dispositions) so that two trading partners interpret the same event the same way.

EPCIS 1.2 (XML) carried the early DSCSA implementations; EPCIS 2.0 added JSON and JSON-LD and is increasingly used. The GS1 US “Application Standard” for DSCSA constrains EPCIS so partners exchange data consistently. If you remember one thing: EPCIS is the message format, CBV is the controlled vocabulary, and the GS1 US guidance is the implementation profile.

The four core EPCIS event types

Each event carries key CBV fields:

• bizStep: the business step, for example commissioning, shipping, receiving, packing, unpacking, decommissioning.
• disposition: the state of the object, for example active, in_transit, in_progress, destroyed, returned, recalled.
• readPoint and bizLocation: where the event happened and where the objects now logically reside, expressed as GS1 GLNs (Global Location Numbers).

A worked EPCIS shipping event (simplified)

{
  "isA": "ObjectEvent",
  "eventTime": "2026-06-19T14:05:00-04:00",
  "eventTimeZoneOffset": "-04:00",
  "action": "OBSERVE",
  "bizStep": "urn:epcglobal:cbv:bizstep:shipping",
  "disposition": "urn:epcglobal:cbv:disp:in_transit",
  "readPoint": { "id": "urn:epc:id:sgln:0312345.00001.0" },
  "epcList": [
    { "epc": "urn:epc:id:sgtin:0312345.067890.A1B2C3D4E5" }
  ],
  "bizTransactionList": [
    { "type": "urn:epcglobal:cbv:btt:po", "bizTransaction": "urn:po:4500098765" }
  ],
  "sourceList": [
    { "type": "owning_party", "source": "urn:epc:id:sgln:0312345.00000.0" }
  ],
  "destinationList": [
    { "type": "owning_party", "destination": "urn:epc:id:sgln:0398765.00000.0" }
  ]
}

Note the SGTIN (Serialized GTIN) in epcList: that is the serial number expressed as an EPC URI. The sourceList/destinationList carry the change-of-ownership “from/to,” which maps directly to the DSCSA TI buyer and seller. This is why people say EPCIS “carries” the T2: the regulatory data elements are present, just expressed in the GS1 vocabulary.

How partners actually connect

The data does not flow over one universal pipe. Connections are typically point-to-point integrations (often through commercial serialization or traceability platforms acting as a hub), AS2 or SFTP file drops, or API calls. A given manufacturer may exchange EPCIS with dozens of distributors through one or two solution providers. The interoperability obligation is about being able to connect and exchange in the standard format, not about a single government database. FDA explicitly did not build a centralized national track-and-trace repository; the system is distributed.

EPCIS 2.0 versus 1.2: the migration in practice

EPCIS 1.2 (ratified 2016) is what most DSCSA programs were built on: XML messages, moved mostly as file drops over AS2 or SFTP. EPCIS 2.0, ratified together with CBV 2.0 in June 2022, added JSON and JSON-LD as first-class formats alongside XML and leans toward REST-style API exchange rather than batch files. It also added a fifth event type, AssociationEvent, for recording a relationship between an object and an identifier (for example linking a reusable asset or a sensor to a shipment) and native support for sensor-element data, which matters more to cold-chain condition monitoring than to the core DSCSA data elements. The core four event types, bizSteps, and dispositions a DSCSA program actually uses carry forward largely unchanged.

The technical case for moving to 2.0 is straightforward: JSON and REST fit modern integration platforms better than XML file drops. The operational risk is what most migration write-ups underplay: interoperability is bilateral. One trading partner moving to EPCIS 2.0 does not, by itself, improve anything, and if the counterpart on the other end of that connection is still consuming EPCIS 1.2 XML, the exchange breaks rather than improves until both sides negotiate and test the version and transport for that specific connection. A platform-level upgrade is not the same thing as a partner-by-partner cutover.

One more thing worth naming: the technical target is not “EPCIS 2.0” as an abstraction, it is the specific GS1 US application standard release and PDG Interoperability Blueprint profile your trading partners and platform vendor have agreed to support. GS1 US publishes DSCSA-specific implementation guidance tied to a stated EPCIS and CBV version; confirm which version your trading-partner agreement references before building or changing an interface, because a partner “compliant with EPCIS” on paper and a partner compliant with the specific profile you built to are not always the same claim. See cloud SaaS validation for how to treat a hosted EPCIS or VRS platform’s version upgrades under change control.

Verification, VRS, and the GTIN-serial-lot-expiry lookup

DSCSA requires trading partners to be able to verify a product identifier, especially for suspect product and for saleable returns. The industry built the Verification Router Service (VRS) to do this at scale.

VRS answers a simple question: “I have this GTIN, serial, lot, and expiry. Is it a valid, manufacturer-issued identifier?” The requester sends those four data elements; the network routes the query (using a GS1 Lightweight Messaging Standard / PI lookup) to the responder operated by or for the product’s manufacturer; the response is a yes/no on the validity of that identifier. Crucially, VRS returns a verification result, not the full transaction history. It confirms the number is real; it does not by itself prove the unit is the genuine physical product.

The saleable returns verification requirement (effective for wholesale distributors November 27, 2019, but under FDA enforcement discretion that was extended twice, ultimately to November 27, 2023) is the highest-volume use of VRS. A distributor that receives returned, undamaged, in-date product cannot resell it unless it verifies the product identifier first. Given the volume of returns, manual verification is impractical, which is why VRS exists.

Verification roles and timing

• For a suspect product investigation, verification must happen promptly as part of determining whether the product is illegitimate (see below).
• For a saleable return, verification must occur before the product is put back into sellable inventory.
• A manufacturer that receives a verification request for a product identifier it issued must respond, generally within 24 hours for suspect-product verification requests.

Data exceptions versus suspect-product triggers: triage at scale

At real volume, most of what fires an alert in a DSCSA program is a data exception, not a product-integrity event. Treating every data exception as a suspect-product investigation buries the program in noise and trains staff to stop escalating; treating every data exception as harmless risks missing the one time it was not. The distinction is a triage step, and it deserves its own logic before a trigger ever reaches the suspect/illegitimate workflow below.

A data exception is a technical or data-quality failure in the electronic exchange itself: an EPCIS message that fails schema validation, a late or missing event, a GLN that does not resolve, an aggregation event referencing a serial not yet commissioned in your own system, a duplicate event, or a VRS request that times out because a responder is unavailable. A suspect-product trigger is physical or transactional evidence bearing on the legitimacy of the product: a VRS response that explicitly returns invalid (not a timeout), signs of tampering, a source that is not an authorized trading partner, or a transaction that does not reconcile with the physical count on hand.

The triage principle: a data exception becomes a suspect-product trigger only when the underlying cause cannot be explained and reproduced as an internal or trading-partner data or IT problem, or when it is joined by an independent physical or transactional red flag. Document the triage decision either way, because an inspector will ask why a given event was, or was not, escalated.

At high volume this triage needs to live in the exception-management tooling and a dedicated log, not in an ad hoc judgment call by whoever is on shift when the alert fires. A log that is separate from the suspect-product investigation record lets quality and trade compliance see the pattern of chronic partner-connectivity problems, which is a data-governance and change control issue, not something that belongs mixed into a patient-safety investigation log.

Suspect and illegitimate product: the investigation workflow

This is where the quality and regulatory disciplines intersect, and it is the part inspectors probe hardest because it is the patient-safety end of the law.

A suspect product is one for which there is reason to believe it is potentially counterfeit, diverted, stolen, intentionally adulterated, the subject of a fraudulent transaction, or unfit for distribution and a risk to patients. An illegitimate product is one for which credible evidence shows it is counterfeit, diverted, stolen, intentionally adulterated, the subject of a fraudulent transaction, or unfit and a risk.

The determination path

The two words that drive the clock are suspect and illegitimate. Suspect means “reason to believe” and opens an investigation; illegitimate means “credible evidence” and starts the 24-hour Form FDA 3911 clock. Walking the trigger through the path below keeps a team from either over-notifying (filing a 3911 on a product that was only suspect) or under-notifying (sitting on credible evidence).

Step-by-step

1. Detect / receive a trigger. A failed scan, a mismatched verification, a tip, a regulatory notice, physical signs of tampering, or a transaction that does not reconcile.
2. Quarantine. Physically segregate the product and stop further distribution. Document the quarantine.
3. Investigate to determine suspect status. Use verification (VRS), review the transaction data, inspect the physical product, and contact the upstream partner and/or manufacturer.
4. Verify the product identifier as part of the investigation, including a request to the manufacturer where relevant.
5. Conclude. If the investigation clears the product, document the rationale and release it. If credible evidence shows it is illegitimate, escalate.
6. Notify FDA and trading partners. For illegitimate product, notify FDA using Form FDA 3911 within 24 hours, and notify immediate trading partners you reasonably believe may have received it. Coordinate disposition (often destruction) with the manufacturer.
7. Terminate the notification when appropriate, again via Form FDA 3911, once FDA and partners agree the matter is resolved.

The 24-hour 3911 clock is one of several statutory notification clocks a quality and regulatory team has to track side by side; see regulatory reporting obligations and clocks for how it lines up against field-alert, biological product deviation, and other reporting timeframes so a single tracker, not memory, is what tells someone which clock is running.

Acceptance criteria for a defensible investigation

• Quarantine was immediate and recorded with date, time, and quantity.
• The product identifier was verified and the result captured.
• The decision (cleared vs illegitimate) is supported by documented evidence, not assertion.
• For illegitimate product, the 3911 notification timestamp shows it was filed within 24 hours of the determination.
• Trading-partner notifications are evidenced.
• Records are retained and retrievable for the required period (generally six years for transaction records under DSCSA).

Authorized trading partners and license verification

DSCSA limits trading to authorized trading partners. For manufacturers, repackagers, and wholesalers, “authorized” turns on FDA registration and state licensure; for dispensers, on a valid state license; for 3PLs, on the required licensure/reporting.

The National Association of Boards of Pharmacy maintains licensure resources, and FDA publishes the registration and 3PL/wholesaler reporting databases. Before you transact with a new partner, verify their authorization status and keep the evidence. As a matter of general guidance, transacting with an unauthorized partner is commonly treated as a compliance failure in its own right under the statute, independent of whether the product later turns out to be fine, so it is prudent to verify authorization regardless and to confirm how the requirement applies to your own situation.

A practical control: maintain an approved-trading-partner list inside your quality system, with the license/registration evidence attached and a periodic re-verification cadence (for example, at license-renewal dates). Tie new-customer and new-vendor onboarding to that check.

Trading-partner onboarding and the interoperability blueprint

Authorization (license and registration) answers the permission question: is this partner one you are allowed to trade with. It does not answer the separate question of whether your systems can actually exchange data with theirs. That second question is its own onboarding process, and it is where most first-shipment surprises come from.

A structured onboarding covers, before the first serialized commercial shipment moves:

1. Master data alignment. The GTIN-to-NDC mapping, GLNs for each ship-from and ship-to location, and expiry-date and lot-format conventions match on both sides.
2. Credentialing. Each party’s identity and system access are established the way the connection requires (certificate exchange, API credentials, or platform-specific onboarding).
3. EPCIS and CBV version and transport agreement. Both sides confirm which EPCIS and CBV version, and which transport (file-based or API), the connection will use, and put it in writing.
4. VRS responder registration. If you are a manufacturer or repackager, your responder is reachable and returns correct results for the GTINs in scope; if you are the requester, your platform can route to it.
5. Schema validation and round-trip test. Test messages validate against the agreed application standard, and a live round-trip test (send, receive, confirm ingestion) runs successfully with the partner’s actual receiving system, not just a generic validator.
6. Data-ownership and responsibility agreement. Who scans, who generates the EPCIS event, and who carries the T3/TS obligation are written into the contract or quality/technical agreement, not assumed (see the next section for why this matters most with 3PLs and repackagers).

An industry body, the Partnership for DSCSA Governance (PDG), exists specifically to keep individual companies from having to invent bilateral standards from scratch. PDG is a sector-neutral, nonprofit group of manufacturers, repackagers, distributors, dispensers, 3PLs, trade associations, and technology providers that publishes a shared Interoperability Blueprint describing how trading partners should structure transaction information and statement exchange, interoperable verification, interoperable tracing, and trading-partner credentialing and authentication. Reading the current PDG Blueprint and the GS1 US DSCSA implementation guideline before you design a new connection saves you from re-deriving conventions your future trading partners already expect.

3PL and repackager data ownership: who generates what

A company’s commercial label, whether contract manufacturer, third-party logistics provider, or contract packager, does not by itself determine its DSCSA data obligations. What matters is which activities it actually performs: does it take title to the product, does it physically change the package (repackage or relabel), and does it generate the shipping or receiving event. This is the single most common source of confusion in serialization programs that touch outsourced manufacturing or logistics, and it is worth a role-by-role breakdown.

The repackager row is worth sitting with, because it is where data ownership most often breaks silently. A repackager is not a pass-through: it re-serializes, becomes the originating party for a brand-new T3 on the repackaged units, and is expected to preserve traceability back to the manufacturer’s original lot and serials it consumed, so that a recall or an investigation can be traced through the repackaging step rather than stopping at it. When a repackager (or a contract packager acting in that capacity) serializes on your behalf, put the master-data ownership and the genealogy-preservation obligation explicitly in the quality and technical agreement and confirm it with a connectivity test before the first commercial batch; see CDMO oversight and quality agreements and conducting a supplier audit for how to build and verify that oversight.

Building and validating the serialization system (the quality view)

A serialization program is a GxP-adjacent IT and packaging system, and it is validated like one. Even though serialization data is not classic batch-record CGMP data, the printing and verification equipment on the line is part of the labeling control, and the data systems that generate and exchange serials should be managed under computerized-system controls. See computer software assurance fda and the gamp5 csv framework for the validation approach, and 21 cfr part 11 eu annex 11 for electronic-records expectations on the data side.

The system layers

Serial numbers are usually requested from an enterprise (L4) number generator, provisioned down to the line (L2), printed and vision-verified on each unit, aggregated, and the events sent back up to L4 for EPCIS exchange (L5).

What to validate and how to know it is right

• Serial number management. Numbers are unique, never reused, generated with adequate randomization where required, and reconciled (commissioned vs printed vs rejected vs shipped). Acceptance: a reconciliation report per batch with zero unexplained discrepancies and a controlled procedure for handling rejects (decommissioning) and re-prints.
• Print and verification. The DataMatrix is grade-acceptable (ISO/IEC 15415 print-quality grading is the usual reference, commonly a minimum grade such as C/1.5 by trading-partner agreement) and the human-readable matches the encoded data. Acceptance: documented grading and a vision system that rejects unreadable or mismatched units.
• Aggregation accuracy. Parent-child mapping is correct. Acceptance: aggregation challenge tests show 100 percent correct inflation; a sampling plan confirms no orphan or cross-mapped serials.
• EPCIS message integrity. Generated EPCIS validates against the GS1 US application standard schema and contains correct GLNs, bizSteps, dispositions, and source/destination. Acceptance: schema validation passes and a round-trip test with a trading partner (or test harness) confirms the partner can ingest it.
• Data integrity. Serial events are attributable, time-stamped, audit-trailed, and protected from alteration (ALCOA+ principles). See ALCOA+ in detail and audit trail design and review.

Roles and responsibilities

When a CMO or CPO serializes for you, the master data (GTIN, NDC, expiry format) and the EPCIS connection are the two things that break most often. Lock them down in the quality/technical agreement and run a connectivity test before the first commercial batch.

Saleable returns: the end-to-end procedure

Saleable returns are worth their own walkthrough because they generate the most transactions and the most findings.

1. Product is returned to a wholesale distributor, undamaged and in date.
2. The distributor scans the product identifier (GTIN, serial, lot, expiry) from the DataMatrix.
3. The distributor sends a verification request through VRS.
4. The manufacturer’s responder confirms the identifier is valid (or not).
5. If valid, the distributor may return the unit to sellable inventory and the associated transaction data is updated.
6. If invalid or no response, the unit is treated as suspect and enters the suspect-product workflow.

Acceptance criteria: every saleable return has a recorded verification result before re-shelving; no product is resold on a “no response” or a mismatch; turnaround on the verification meets the agreed service level; and the audit trail links the physical unit to the verification transaction.

Common failure: scanning the linear/legacy barcode instead of the 2D DataMatrix, so the serial is never captured and verification cannot run. Another: returns processed faster than the VRS can respond, so units get re-shelved on a pending result. Both are procedure-and-throughput problems, not technology problems.

Saleable returns at scale: the edge cases

The basic flow above covers the single-unit case. Volume returns processing runs into a handful of situations the simple flow does not answer on its own:

• Aggregated, case-level returns. A distributor receives an unopened, unbroken case carrying an SSCC rather than loose units. The DSCSA verification obligation is still per package, so the correct handling is to inflate the case against the aggregation data and verify at the unit level through inference, not to wave the case through because the outer packaging looks intact, a compromised or substituted unit inside a resealed case is exactly what unit-level verification exists to catch. Most VRS platforms support submitting the parent identifier and receiving per-unit results; confirm this with your responder and platform rather than assuming it.
• Cross-dock and hub consolidation. Some returns are consolidated at a 3PL or logistics hub before reaching the wholesale distributor that actually holds the verification obligation. The obligation stays with the trading partner that owns the product, not the party that physically handled it, so the contract with the 3PL needs to specify who captures the scan at the point of physical handling and who is accountable for acting on the verification result.
• Responder or network unavailability. Define “no response” operationally as a timeout after a stated number of seconds or retries, not an indefinite wait, and build the fallback quarantine path so that returns processing does not silently stall, or worse, get waved through under throughput pressure while the platform is down.
• Near-expiry product. A valid identifier on a unit close to expiry is verified the same way as any other unit. Whether a near-expiry unit is resalable is a separate business and quality decision layered on top of verification, not a substitute for it.
• Verification throughput. One-request-per-unit VRS calls become the bottleneck once return volume climbs. EPCIS 2.0’s REST orientation and newer VRS implementations increasingly support submitting a batch of identifiers in a single call; if your platform still only supports one at a time, that ceiling is exactly what forces the “re-shelve on pending” failure described above, and it is worth raising with your platform vendor before volume forces the issue.

Common mistakes and inspection-finding patterns

These are the recurring, generic patterns. None of them require naming a company to recognize.

• NDC-to-GTIN mismatch. The barcode encodes a GTIN that does not correctly map to the labeled NDC, or different formats appear in master data versus the printed code versus the EPCIS. Every downstream verification then fails.
• Human-readable does not match the encoded data. The eye-readable lot or expiry differs from what is in the DataMatrix. Classic labeling-control finding.
• Poor barcode print quality. DataMatrix grades below the agreed minimum, so partners cannot scan reliably.
• Aggregation errors. Serials assigned to the wrong case or pallet, producing failed receipts and unverifiable returns downstream.
• Incomplete or wrong EPCIS. Missing source/destination GLNs, wrong bizStep or disposition, schema validation failures, or events that do not reconcile (shipped count does not match commissioned count).
• T3 / TI gaps. Pre-enhanced records missing required fields; enhanced records that are still lot-level rather than package-level.
• Transacting with unauthorized partners or failing to keep license-verification evidence.
• Late or missing FDA 3911 notification for illegitimate product, or no documented suspect-product investigation procedure at all.
• Records not retained or not retrievable within the required period and timeframe when requested.
• No reconciliation of serial numbers (commissioned vs printed vs rejected vs shipped vs destroyed), so the program cannot prove every number is accounted for.
• Change control bypassed when master data (GTIN, expiry format) or EPCIS mapping is edited directly in production. This is both a CSV and a data-integrity finding.
• EPCIS version mismatch treated as a data problem instead of a connection problem. A partner upgrades to EPCIS 2.0 without confirming the counterpart can consume it, and events that used to pass start failing with no code change on the receiving side.
• 3PL or repackager responsibilities left ambiguous in the service agreement. No document states who captures the scan, who owns the resulting EPCIS event, and who carries the T3/TS obligation, so a data gap has no clear owner once it is found.
• Data exceptions triaged inconsistently. Either escalated to a suspect-product investigation by default, which trains staff to stop escalating anything, or waved through with no documented triage decision, which lets a chronic connectivity problem get quietly explained away every time without ever being fixed.
• A new trading partner connected without a documented onboarding and round-trip test. The first commercial shipment goes out before master data, GLNs, and EPCIS mapping were confirmed against the partner’s actual receiving system.

A useful internal check: pick one shipped batch and trace a single serial end-to-end (commission to ship to receive to EPCIS to, if applicable, a return). If you cannot follow that one number cleanly through every system, neither can an inspector, and that is where the questions start. See supply chain data integrity and data integrity foundations for the broader discipline.

DSCSA and international serialization regimes compared

Both DSCSA and the EU FMD require a unique identifier and verification, but the architecture differs. The EU Falsified Medicines Directive (Directive 2011/62/EU) and its Delegated Regulation (EU) 2016/161 use a centralized hub-and-repository model: manufacturers upload unique serial numbers to the European Medicines Verification System, and pharmacies decommission each pack at dispense by checking it against the national repository, plus a tamper-evident anti-tampering device on the pack. DSCSA, by contrast, is distributed: no central repository, traceability achieved through interoperable EPCIS exchange between partners, and verification routed through VRS. EU = verify-at-dispense against a central database plus tamper evidence. U.S. = serialized data exchanged partner-to-partner with point-of-need verification. Do not conflate the two in an interview; it signals you have only worked one region.

Unit-level serialization with a 2D data carrier is now close to universal across major pharmaceutical markets; what varies is where verification happens, whether a central government database exists, and whether reporting is risk-triggered or continuous. Russia’s national track-and-trace system, Chestny ZNAK, illustrates a third model beyond DSCSA and FMD: it requires manufacturers and importers to report serialized movements to a state-operated system at each supply-chain step, with a cryptographic security element embedded in the 2D code alongside the GTIN, serial, batch, and expiry, so the obligation is continuous state reporting rather than DSCSA’s point-of-need verification or FMD’s point-of-dispense decommissioning.

The practical read for a manufacturer selling into more than one of these markets: serialization is not a single global capability built once and reused everywhere. Each regime differs on where verification happens, whether a central government database exists, and what physical anti-tamper features are mandated. A product identifier scheme built to satisfy DSCSA does not automatically satisfy the EU FMD or Russia’s Chestny ZNAK, and vice versa, even though all of them sit on the same underlying GS1 numbering and 2D data-carrier technology. Treat each market as its own regulatory determination, not a variant of the one you already know.

Interview-ready questions and strong answers

Q: Walk me through the four data elements of a DSCSA product identifier. NDC, serial number, lot number, expiration date. They appear human-readable and in a 2D DataMatrix, mapped to GS1 AIs: 01 (GTIN, which encodes the NDC), 21 (serial), 10 (lot), 17 (expiry). The NDC-plus-serial combination is what makes each unit globally unique.

Q: What changed at the November 27, 2023 enhanced phase? Exchange went package-level (serialized TI), fully electronic, and interoperable. Transaction History was eliminated; Transaction Information now carries product identifiers; the Transaction Statement remains. FDA applied staggered enforcement discretion after that date, so confirm the current posture for the specific trading-partner type rather than assuming hard enforcement on day one.

Q: What is EPCIS and how does CBV relate to it? EPCIS is the GS1 standard message format for sharing supply-chain event data: what, when, where, why. CBV is the controlled vocabulary that standardizes the “why” (bizSteps and dispositions) so two partners read an event the same way. The GS1 US application standard is the DSCSA-specific profile. Event types are Object, Aggregation, Transaction, and Transformation.

Q: What is the VRS for, and what does it actually return? The Verification Router Service routes a product-identifier query (GTIN, serial, lot, expiry) to the manufacturer’s responder and returns whether that identifier is valid. Its highest-volume use is saleable-returns verification. It confirms the number is genuine; it does not return full transaction history and does not by itself prove the physical unit is authentic.

Q: You receive a saleable return. Walk me through it. Scan the 2D code to capture GTIN, serial, lot, expiry; send a VRS verification request; only re-shelve if the manufacturer’s responder confirms validity; if invalid or no response, treat it as suspect and quarantine. Record the verification result against the physical unit before it re-enters sellable inventory.

Q: You find a product you believe is illegitimate. What do you do, and on what clock? Quarantine immediately, investigate (verify the identifier, review transaction data, inspect the product, contact upstream/manufacturer), and if credible evidence confirms it is illegitimate, notify FDA via Form FDA 3911 within 24 hours and notify immediate trading partners. Coordinate disposition, then terminate the notification via 3911 when resolved.

Q: What is aggregation and why does it matter? It is the recorded parent-child relationship between packaging levels (each to case to pallet), with cases and pallets carrying SSCCs. It lets you infer the contents of a sealed parent from data rather than scanning every child, which is essential for unit-level tracing and high-volume returns. Aggregation errors are among the most damaging data-quality failures because they propagate silently.

Q: How is a serialization system validated, and what data-integrity controls apply? Treat it as a computerized system under a risk-based CSV/CSA approach: validate serial-number management and reconciliation, print and vision verification, aggregation accuracy, and EPCIS message integrity, with change control over master data and EPCIS mapping. Apply ALCOA+ to serial events: attributable, time-stamped, audit-trailed, and protected from unauthorized change.

Q: How does DSCSA differ from EU FMD? DSCSA is a distributed, partner-to-partner EPCIS model with VRS verification and no central database. FMD is a centralized repository model where packs are decommissioned at dispense against a national system, plus a physical tamper-evident device. Same goal, different architecture.

Q: What changed with the small-dispenser DSCSA exemption in 2026? FDA extended the exemption for small dispensers (a dispenser owned by a company with 25 or fewer full-time pharmacists or pharmacy technicians) from November 27, 2026 to November 27, 2027, announced August 6, 2026, while it runs a mandated feasibility assessment, including a survey due September 22, 2026. Manufacturers, repackagers, wholesale distributors, and larger dispensers are not affected; their enhanced-phase clocks already ran out in 2025.

Q: Should every VRS timeout open a suspect-product investigation? No, not automatically. A timeout or system-unavailability response is usually a data exception: log it, retry, escalate to IT or the trading partner, and track the pattern. It becomes a suspect-product trigger when the cause cannot be explained as an internal or partner data problem, or when an independent physical or transactional red flag is present alongside it. Treating every technical exception as a suspect-product event buries real signals in noise; treating every one as harmless risks missing a real one.

Q: Does a 3PL generate Transaction Information? No. A 3PL stores and ships product on behalf of a trading partner but does not take title to it, so it has no DSCSA change-of-ownership transaction of its own and does not generate T3. It may capture or relay EPCIS scan events under its service agreement, but the T3/TS obligation and the associated liability sit with the trading partner that owns the product. A repackager is different: it does take title, re-serializes, and becomes the originating party for a new T3 on the repackaged units, while still needing to preserve the genealogy back to the manufacturer’s original lot.

Q: What is the practical risk in an EPCIS 1.2 to 2.0 migration? Interoperability is bilateral. If one trading partner moves to EPCIS 2.0’s JSON/REST pattern while its counterpart is still consuming EPCIS 1.2 XML files, the exchange breaks rather than improves unless both sides negotiate and test the version and transport for that specific connection. The safe pattern is parallel support: keep 1.2 live while building 2.0, round-trip test each partner individually, and cut over partner by partner rather than all at once.

Practical tips

• Nail the master data first. GTIN, NDC format, and expiry-date format errors break everything downstream, so freeze them under change control and reconcile across master data, printed code, and EPCIS.
• Run a connectivity / round-trip test with each new trading partner before the first commercial shipment. EPCIS that validates against the schema can still fail in a partner’s system because of GLN or vocabulary mismatches.
• Keep a serial reconciliation report per batch (commissioned, printed, rejected/decommissioned, shipped). It is the cleanest evidence that you control your numbers, and it is the first thing a thorough auditor asks for.
• Treat saleable-returns throughput as a capacity problem, not just a compliance one. If VRS response time cannot keep up with returns volume, you will get pressure to re-shelve on pending results; build the procedure to forbid that.
• Maintain an approved-trading-partner register inside the quality system with license/registration evidence and a re-verification cadence tied to renewal dates.
• Write the suspect/illegitimate product SOP so the 24-hour 3911 clock and the quarantine step are unambiguous, and rehearse it; the first time you run it should not be during a real event. See how to write an sop.
• Retain DSCSA transaction records and serialization data for the required retention period (generally six years for transaction records) in a retrievable form, and confirm you can produce them on the timeframe FDA specifies.
• Specify the EPCIS and CBV version and transport per trading-partner connection in the technical or quality agreement, not just “EPCIS-compliant.” A partner running 2.0 and one running 1.2 can each believe they comply and still be unable to exchange data with each other.
• Put the 3PL and repackager data-ownership question in writing before the first shipment: who scans, who owns the resulting event, who carries the T3 obligation. Silence on this is where returns processing and recall tracing stall later.

Related articles

• good distribution practice cold chain
• supply chain data integrity
• cold chain shipping qualification
• recall management field actions
• product complaint handling
• gamp5 csv framework
• computer software assurance fda
• data integrity foundations
• cdmo oversight quality agreements
• conducting a supplier audit
• regulatory reporting obligations and clocks