epcis.cc

Manufacturer EPCIS 2.0 Resolver for DSCSA Phase 3 Unit-of-Use Verification

Tracing every dose from the manufacturing line to the patient's bedside

DSCSA Secures the Box. Who Secures the Dose?

The Drug Supply Chain Security Act (DSCSA) represents the most significant pharmaceutical traceability regulation in U.S. history. It requires serialization, electronic verification, and interoperable tracking of prescription drugs at every handoff in the supply chain. But its scope has a critical boundary: DSCSA tracks the unit of sale - the sealed box - not the individual dose inside it.

A box of 10 pre-filled syringes moves from manufacturer to distributor to pharmacy with a complete electronic pedigree. Every handoff is recorded, every serial number verified. But the moment a pharmacy technician opens that box and places 10 syringes on a shelf, the chain of custody ends. Each syringe becomes electronically anonymous.

1 in 10
Manually prepared IV medications involve errors (five-hospital observational study)
50%
Of U.S. hospitals lack IV Workflow Management Systems entirely
0
DSCSA data elements available at the point of care for unit-of-use items

Where DSCSA Stops

  • Serialization applies only to the sealed unit of sale - the box, case, or pallet
  • Individual syringes and vials carry no serialized identity under current DSCSA requirements
  • Once a box is opened, there is no electronic link between an individual item and its parent package
  • At the point of care, clinicians have no way to electronically verify that a specific syringe is authentic and belongs to the package it came from
  • The FDA's 2004 Drug Barcode Rule required only NDC data in barcodes - lot numbers and expiration dates were excluded because one-dimensional symbologies couldn't hold the data
  • Drug compounding errors that are not caught before a preparation leaves the pharmacy have a high likelihood of reaching the patient (ECRI, 2024 Top 10 Health Technology Hazards)

What RFID Unit-of-Use Tracking Adds

  • Every syringe and vial carries its own serialized RFID tag using GS1 TDS 2.3 SGTIN++ encoding
  • Each tag contains the product's GTIN, serial number, expiry date, lot number - and the manufacturer's resolver hostname
  • EPCIS 2.0 aggregation events link every unit of use to its parent unit of sale at the manufacturer
  • Any RFID reader, anywhere in the supply chain, can resolve an item back to the manufacturer in real time
  • At bedside, a clinician can confirm in one scan: this dose is authentic, unexpired, unrecalled, and traceable to its origin
  • Unlike barcodes, RFID reads don't require line of sight - an entire box of tagged items can be verified simultaneously without opening the package

The Human Cost of the Traceability Gap

The gap between unit-of-sale tracking and unit-of-use verification isn't theoretical. It has direct patient safety consequences that the healthcare industry is actively grappling with.

"Drug compounding errors that are not caught before a preparation leaves the pharmacy have a high likelihood of reaching the patient."
- ECRI, 2024 Top 10 Health Technology Hazards Report

The THRIV Coalition, a healthcare safety organization dedicated to eliminating IV preparation errors, has documented the scale of this problem. Their research highlights that nearly one out of ten manually prepared IV medications involve errors, most commonly wrong volumes and wrong ingredients - unintentional oversights by trained technicians working under time pressure.

THRIV advocates for five critical technologies in IV preparation: workflow management software, barcode scanning, volume verification, auto-labeling, and auto-documentation. These are essential safeguards. But they all operate within the pharmacy. None of them can answer the question that matters most at the patient's bedside: is this the right drug, from the right manufacturer, in the right package, and is it authentic?

A Scenario That Happens Every Day

A hospital pharmacy receives a shipment of injectable medication - 20 boxes, 10 syringes per box, 200 doses total. Under DSCSA, they verify the 20 box serial numbers against the advance ship notice. Verification passes. The boxes go to the shelf.

Over the next week, technicians open boxes as needed and place individual syringes in dispensing bins. By mid-week, the shelf has loose syringes from 12 different boxes. If one box was compromised during transit - tampered with, improperly stored, or contained a counterfeit product - those 10 compromised syringes are now mixed with 190 legitimate ones. There is no way to distinguish them.

With RFID unit-of-use tracking, every syringe carries its own SGTIN++ tag. When scanned, the tag resolves to this server and returns the complete aggregation record: which box it came from, when it was packed, and the full identity of every item in the original package. The compromised syringes are identified immediately.


Why RFID Succeeds Where Barcodes Cannot

The pharmaceutical industry has relied on barcodes for decades. GS1's Sunrise 2027 Initiative is focused on retail and grocery, moving from one-dimensional to two-dimensional barcodes at the point of sale. It does not address pharmaceutical packaging or unit-of-use drug tracking. For pharma, barcodes face fundamental limitations that RFID overcomes.

Capability 2D Barcode RFID (TDS 2.3)
Serialized identity per item No (possible with 2D barcodes, but rarely done on syringes or vials.) Yes
Lot number and expiry in tag No (possible with 2D barcodes, but rarely done on syringes or vials.) Yes
Read without line of sight No - must see the label Yes - reads through packaging
Bulk read (entire box at once) No - one at a time Yes - hundreds of items per second
Manufacturer resolver hostname in tag No - requires directory lookup Yes - SGTIN++ embeds the domain
Works on small-form items (syringe barrel) Difficult - label space required Yes - tag embeds in cap or barrel
Readable during sterile compounding Requires handling and orientation Yes - no contact, no orientation needed

For pharmacy IV preparation - exactly the workflow THRIV focuses on - RFID is transformative. A technician pulling five syringes for a compounding order can have all five verified against the manufacturer's aggregation record before touching a single one. No scanning, no orienting labels, no one-at-a-time workflow. The reader confirms identity, authenticity, expiry, and lot number for every item simultaneously.


Why the Hostname in the Tag Changes Everything

In DSCSA Phase 2, every SGTIN-96 tag contains a GTIN and serial number, but no indication of where to verify the item. To look up aggregation data, you need a central directory or prior knowledge of the manufacturer's systems. This creates a bottleneck and a single point of failure.

GS1 TDS 2.3 SGTIN++ tags solve this by embedding the manufacturer's resolver hostname directly in the EPC memory. When a pharmacy scans a tagged syringe, the tag itself says "resolve me at epcis.cc." Another manufacturer's tag says "resolve me at dosetrace.org." No directory. No intermediary. The tag is the directory.

This mirrors how the internet itself works - decentralized, manufacturer-owned endpoints that any party can query directly. It is the architecture that makes multi-manufacturer, unit-of-use verification scalable.


How This Resolver Works

1
Scan: An RFID reader scans SGTIN++ tags on a unit of sale (e.g., a box of 10 syringes) or on individual units of use. The EPC in each tag contains the hostname epcis.cc, along with the GTIN, serial, expiry, and lot.
2
Resolve: The system constructs a GS1 Digital Link URL and queries this resolver using the GTIN and serial number extracted from the tag.
3
Verify: The resolver returns an EPCIS 2.0 JSON-LD AggregationEvent listing every child item packed into that unit of sale at the manufacturer - including each child's GTIN and serial number.
4
Validate: The receiving system compares the scanned tags against the manufacturer's record. Every item is confirmed: right product, right serial, right box, authentic tag. Any discrepancy is flagged immediately.

API Endpoint

GET /01/{GTIN}/21/{SERIAL}?linkType=gs1:epcis

Response: EPCIS 2.0 JSON-LD AggregationEvent
- Parent EPC, child EPCs, quantities, event time, biz step

Try It Live

Click the URL below to retrieve a real EPCIS aggregation for one of the demo boxes. The link is a working GS1 Digital Link - the same URL pattern that scanpads and RFID readers use against this resolver.

https://epcis.cc/01/30376045223300/21/17724760500010655?linkType=gs1:epcis
Domain GTIN (AI 01) Serial (AI 21) Link type

Part of a Distributed Verification Network

In a functioning DSCSA Phase 3 supply chain, no single entity controls all product data. Each manufacturer hosts their own EPCIS resolver. The SGTIN++ tag tells every reader in the supply chain exactly where to look.

This resolver serves products whose tags encode epcis.cc as their hostname. Other manufacturers' products resolve to their own domains - for example, dosetrace.org. A distributor or pharmacy receiving a mixed shipment from multiple manufacturers can verify every item seamlessly: each tag self-directs to the correct resolver. No central registry, no single point of failure, no dependency on a third-party data broker.

This is how pharmaceutical traceability should work: manufacturer-owned data, universally accessible, verified at every step from the production line to the patient's bedside.


One More Thing

Pair the Logical Serial With the Physical TID. Decommissioning Becomes Optional.

Every RFID chip carries two distinct identifiers. The EPC - the GTIN and serial number you've seen all over this page - is programmed into the tag at manufacturing. It's the logical identity, the part that DSCSA tracks. But the chip also carries a TID - a unique, factory-burned serial number written into the silicon during semiconductor fabrication. The TID is read-only. No field-programmable RFID writer can rewrite it. It is, in semiconductor terms, immutable.

This resolver's EPCIS aggregation records publish the TID alongside each child item:

{
  "eagile:epc": "https://id.gs1.org/01/00376045223033/21/84173524345281",
  "eagile:tid": "E28011C020000F7D42440317"  ← the chip's physical fingerprint
}

High-memory RFID chips will matter more and more as encoded data grows. SGTIN++ tags can already approach 256 bits once serial number and lot data are included, and chips like Impinj's M780 are well-suited for the kind of data the pharmaceutical space is going to need to carry on every tag.

When a scanpad, conveyor, or bedside reader sees a tag, it reads both. The reader then queries this resolver, gets back the manufacturer's record, and compares the TID. If the TIDs match, the item is mathematically proven to be the same physical chip that left the factory floor.

Why this matters: decommissioning becomes optional

Traditional supply chain "decommissioning" exists to stop counterfeiters from re-using valid serial numbers. The logic: if a real item with serial X has already been consumed, then a later scan claiming serial X must be a clone - but you only catch the clone by maintaining a centralized "decommissioned" list and checking it on every single scan. Every reader, every pharmacy, every distributor has to phone home.

TID pairing eliminates that requirement. A counterfeiter can clone the GTIN and serial onto a blank tag, but they cannot clone the TID. So when the manufacturer publishes the GTIN-serial-TID triple, every later scan can independently verify the chip without consulting anyone in real time.

In practice the pharmacy fetches the manufacturer's EPCIS record once - when the box arrives at the loading dock - and caches it locally. Every scan after that, including the bedside check, is a local TID comparison. No network round-trip, no waiting on someone else's API while the nurse holds a syringe.

The pharmacy never has to ask whether someone else has already consumed serial X. They look at the chip in their hand, look up the cached manufacturer record, compare TIDs, and they're done. Two-factor verification, fully decentralized. The supply chain stops needing a global "used items" registry, and the manufacturer's resolver stops being a write target - it's read-only and tamper-evident by design.