Unit-level GS1 DataMatrix serialization, permissioned-blockchain hash anchoring, and pharmacy scan-and-verify for DSCSA / EU FMD anti-counterfeit track-and-trace
Every regulatory serialization regime — DSCSA in the United States, the EU Falsified Medicines Directive — begins at the same physical event: printing a machine-readable code on each individual saleable unit that uniquely distinguishes it from every other pack of the same drug ever made. The GS1 2D DataMatrix symbol is the global standard container for this identity, packing four data elements into a grid the size of a fingernail, readable by any GS1-compliant scanner across the entire supply chain.
The GS1 DataMatrix on a pharmaceutical pack encodes four Application Identifiers (AIs) as a concatenated string:
AI (01) — GTIN (Global Trade Item Number): • 14-digit number identifying the specific product, strength, and pack configuration • Assigned by the manufacturer via GS1 company prefix + item reference + check digit • Equivalent in the US to NDC (National Drug Code, FDA-assigned, typically 10-11 digits: labeler-product-package) — GTIN is constructed to embed the NDC for US markets • Same GTIN across every unit of that exact SKU; does NOT vary by individual pack
AI (10) — Batch/Lot Number: • Alphanumeric, manufacturer-assigned, up to 20 characters • Links the pack to its manufacturing batch record, raw material lots, QC release data • Used for recalls: a contaminated batch can be traced to every dispensed unit
AI (17) — Expiration Date: • YYMMDD format per GS1 standard • Machine-verifiable at dispense to block expired stock from sale
AI (21) — Serial Number: • Unique to EACH individual pack — the critical anti-counterfeit element • DSCSA and FMD both require serials to be unpredictable/randomized (not incrementing 000001, 000002…) so a counterfeiter cannot guess valid unassigned serials • Typically 10-20 alphanumeric characters, cryptographically randomized at generation • Combined with GTIN, forms a globally unique pack identifier: no two packs anywhere share (GTIN, SN)
Physical encoding: • Printed via thermal transfer or laser marking directly on carton/label at packaging line • Grid typically 12x12 to 26x26 modules depending on data length • Reed-Solomon error correction (ECC200) allows ~30% of the symbol to be damaged/obscured and still decode correctly • 100% vision-inspected inline: every single pack's code is camera-verified against the intended data before the pack leaves the line — misprints are rejected automatically
Human-readable interpretation (HRI) text is printed alongside the barcode as a fallback for manual entry when scanning fails.
Printing a unique serial solves identification, not trust — a counterfeiter can print an equally convincing barcode. The blockchain layer solves the trust problem: it creates a tamper-evident, shared record of which serials are genuinely valid, who currently owns each one, and whether any given scan corresponds to a fact the network already agreed on. Rather than storing plaintext product data on-chain, the network stores cryptographic commitments — hashes — that let any participant verify authenticity without exposing competitively sensitive batch data to every other network member.
Cryptographic hashing of pack data:
• For each serialized pack, the manufacturer computes: H = SHA-256(GTIN || Lot || Expiry || SerialNumber || salt) • SHA-256 produces a fixed 256-bit (64 hex character) digest; changing a single character in the input completely changes the output (avalanche effect) • The hash is committed to the ledger — NOT the raw product data — preserving confidentiality between competing trading partners while still allowing any party to verify a given pack's hash matches what the manufacturer originally registered • A verifier who scans a physical pack recomputes the hash from the decoded barcode data and checks it against the ledger entry: match = authentic registration; mismatch or absence = suspect
Merkle tree batch aggregation: • Manufacturing batches can contain tens of thousands of units; committing one transaction per pack would overwhelm ledger throughput • Instead, pack hashes are arranged as leaves of a Merkle (hash) tree: pairs of leaf hashes are concatenated and re-hashed up the tree until a single Merkle root remains • Only the Merkle root (one 256-bit value) is written to the blockchain per batch, alongside batch metadata • Merkle proof: any individual pack's membership in the batch can be verified with only log2(N) sibling hashes, without revealing the other N-1 pack identities — efficient and privacy-preserving
Hyperledger Fabric architecture (permissioned ledger): • Membership Service Provider (MSP): issues cryptographic identities to manufacturers, distributors, pharmacies, and regulators — only known, vetted trading partners can write to the ledger • Channels: private sub-ledgers between subsets of participants (e.g., a manufacturer-distributor channel invisible to competitors) • Chaincode (smart contract): encodes the business logic — registering a serial, transferring custody, decommissioning at dispense — executed by endorsing peers • Endorsement policy: a transaction (e.g., "Pfizer registers batch X") must be endorsed by a defined set of peers (e.g., manufacturer + regulator node) before being ordered into a block • Ordering service: sequences endorsed transactions into blocks deterministically, replicated across all peers — this is what makes the log tamper-evident and append-only
MediLedger is a real-world production network built on this pattern, used by major US pharmaceutical manufacturers and distributors to meet DSCSA interoperability requirements without a single central database.
A serialized, hashed pack still needs a record of who legitimately possessed it at every step. DSCSA formalizes this as three linked data sets — Transaction Information, Transaction History, and Transaction Statement, collectively "T3" — that historically traveled as paper or PDF pedigrees and now propagate as ledger events, giving every downstream trading partner cryptographic assurance that the product passed only through authorized hands.
DSCSA (Drug Supply Chain Security Act, signed 2013):
• Phased 10-year implementation culminating in full, unit-level, interoperable electronic traceability enforced from November 27, 2023 • Every change of ownership requires the seller to provide the buyer with:
1. Transaction Information (TI): product identifier (GTIN/NDC), lot number, quantity, transaction date, and the names/addresses of the parties 2. Transaction History (TH): the complete chain of prior TI records back to the manufacturer — every hop the product took 3. Transaction Statement (TS): an attestation that the seller is authorized, received the product from an authorized entity, did not knowingly ship suspect/illegitimate product, and complied with verification requirements
• Post-2023: TI/TH/TS must be exchanged electronically, interoperably, at the individual package (serialized unit) level — not just lot level as in earlier phases • Trading partners must be able to respond to a verification request within 24 hours, confirming whether a specific serial number is valid • Suspect product: must be quarantined and investigated within 24 hours of identification; confirmed illegitimate product must be reported to FDA within 24 hours
EU Falsified Medicines Directive (2011/62/EU) and Delegated Regulation (EU) 2016/161:
• FMD introduced the legal framework in 2011; the Delegated Regulation specified the technical safety features, effective February 9, 2019 • Two mandatory safety features on nearly all prescription packs: a unique identifier (2D DataMatrix, analogous to GS1 serialization) and an anti-tampering device (ATD) on the outer packaging • European Medicines Verification System (EMVS): a hub-and-national-system architecture — manufacturers upload serials to a central European Hub, which routes to National Medicines Verification Systems (NMVS) in each member state • Pharmacies decommission (mark as "dispensed") the unique identifier in the national system at the point of supply to the patient — the pack cannot be validly re-dispensed afterward • Wholesalers must verify authenticity when handling product outside the normal chain (returns, non-regular suppliers) even though full unit-level verification at every wholesale step is not mandated as broadly as at dispense
Both regimes converge on the same principle: every legitimate custody transfer must be documentable and machine-verifiable, closing the paper-pedigree loopholes that historically let diverted or counterfeit product re-enter the legitimate supply chain.
Scanning every individual bottle every time a truck is loaded or unloaded would make serialization operationally impossible at real-world volumes. GS1 solves this with a nested aggregation hierarchy: items pack into cases, cases stack onto pallets, pallets consolidate into shipments — each level identified by a Serial Shipping Container Code (SSCC), with parent-child relationships recorded once so that scanning a single top-level code instantiates the entire manifest beneath it.
GS1 SSCC (Serial Shipping Container Code) structure:
• 18-digit code: extension digit + GS1 company prefix + serial reference + check digit • Assigned uniquely to every logistics unit above the item level: a case, a pallet, a shipping container • Printed as a GS1-128 linear barcode or encoded in an EPCIS aggregation event alongside the DataMatrix on individual units
Aggregation event recording (EPCIS — Electronic Product Code Information Services):
1. Item → Case: when N individual serialized units are packed into a case, an aggregation event links the case SSCC as parent and each unit's (GTIN, SN) as children. This event is written to the ledger once per case, not once per item.
2. Case → Pallet: multiple cases are stacked and shrink-wrapped onto a pallet; a new aggregation event links the pallet SSCC as parent of the constituent case SSCCs.
3. Pallet → Shipment: pallets loaded into a truck or container are linked under a shipment/Advance Ship Notice (ASN) reference, sometimes with its own top-level SSCC.
Operational effect:
• A distributor receiving a truckload scans the shipment or pallet-level SSCC once; the ledger returns the full nested manifest — every case, and every item serial within every case — without physically opening a box • Discrepancy detection: if the received item count doesn't match the aggregated manifest (a case is missing, or contains an unexpected serial), the receiving event flags a shortage or "unexpected inventory" exception automatically • Disaggregation: when a pharmacy breaks a case to dispense individual bottles, a disaggregation event decouples the item serials from the case parent, so each unit can subsequently move independently through its own T3 chain • This hierarchy is what makes DSCSA's package-level requirement operationally tractable at billions of units per year — verification queries traverse the aggregation tree instead of requiring a discrete scan of every unit at every single handoff
The final and highest-stakes checkpoint is the pharmacy counter, seconds before a patient receives their medication. A scan-and-verify query against the ledger answers three questions in real time: does this exact serial number exist as a genuine registration, is it still active (not already dispensed or decommissioned elsewhere), and is its appearance here consistent with the custody chain the ledger has recorded so far. Any "no" halts dispensing and quarantines the pack.
When a pharmacist scans a pack's DataMatrix before dispensing, the point-of-sale system issues a verification query to the ledger (directly or via a GS1/DSCSA-compliant verification router). Three classes of anomaly drive counterfeit and diversion detection:
1. Duplicate serial number scans: • The ledger tracks a status flag per (GTIN, SN): "active/in-supply-chain" vs. "decommissioned/dispensed" • If a serial already marked decommissioned is scanned again for dispensing, this indicates either a cloned barcode (counterfeiter copied a genuine serial onto fake product) or a process error (same pack scanned twice) • Response: immediate hard block on dispensing, automatic suspect-product investigation opened per DSCSA's 24-hour rule
2. Invalid / unknown serials: • If (GTIN, SN) has no matching registration hash anywhere on the ledger, the pack was never legitimately serialized by the claimed manufacturer • This is the classic signature of a wholly counterfeit product using a real GTIN with a fabricated serial number • Response: quarantine, do not dispense, report to manufacturer/regulator
3. Serials scanned out of expected supply-chain sequence: • The ledger holds the full custody path (T3 chain) for each serial: manufacturer → specific distributor → specific pharmacy • If a pack surfaces at a pharmacy with no recorded transfer to that pharmacy (or to any distributor supplying it), or if its last recorded location was in a different country/region entirely, this signals diversion (product illegitimately rerouted, e.g., stolen inventory or gray-market import) even when the serial itself is genuine • Statistical/temporal anomalies also matter: a serial "traveling" an implausible distance in an implausibly short time between scans is flagged for review
Aggregate network effect: • Because every trading partner queries the same permissioned ledger, a counterfeit or diverted pack that evades detection at one link is very likely caught at the next — the dispense-point scan is the last and most consequential checkpoint, closing the loop opened at manufacture • Regulatory reporting: confirmed counterfeit/illegitimate product detections feed back to FDA (DSCSA) or the National Medicines Verification System (EU FMD) within the mandated 24-hour window, enabling rapid recalls and law-enforcement referral
A 2023 industry pilot across the MediLedger Network demonstrated sub-second verification responses across multiple independent manufacturer and distributor nodes for DSCSA's November 2023 interoperability deadline, without any single party operating a central database of all serial numbers — proving that permissioned blockchain architecture can satisfy federal traceability law while preserving each trading partner's data confidentiality.