Tracing Every Dose - Manufacturer EPCIS Resolver for DSCSA Phase 3 Unit-of-Use Verification
The vial on the shelf has an identity. It does not have a provenance.
It is tempting to open with "individual doses are not serialized." That is not true, and a pharmacy director will tell you so in about four seconds. Hospital pharmacies have been applying RFID tags to individual vials and syringes for more than a decade. Kit and tray management does it as a matter of routine: a technician tags an item on the way into inventory, and the shelf becomes machine-readable. Several vendors do this well.
Here is what that tag cannot tell you. It cannot tell you which sealed box the vial came out of, because the identity on it was assigned by the hospital, after the box was already open. There is no aggregation record linking the two. And there is no aggregation record because the sealed box - the unit of sale, the object DSCSA actually serializes - shows up carrying a printed 2D barcode and, in nearly every case, no RFID tag at all.
The gap is not that unit-of-use is unserialized. It is that unit-of-use is unaggregated.
And it is unaggregated for a specific, fixable reason: the unit of sale carries no RFID parent. No parent tag at the manufacturer means no manufacturer-published parent-child record, which means nothing about the manufacturer's packing event survives the box being opened.
A downstream tag answers "what is on my shelf." A manufacturer aggregation answers "what did the manufacturer put in the box." Only the second one is provenance, and provenance is the thing the point of care has never had.
The patient safety argument for unit-of-use traceability is real. It is also routinely oversold, and overselling it is how you lose a clinical audience. So here it is scoped honestly.
The figure usually cited next to that quote - roughly one in ten manually prepared IV medications involving an error - comes from a five-hospital observational study of 1,679 doses published by Flynn, Pearson, and Barker in 1997. The citation is correct. Three things have to be said alongside it:
So the claim this site makes is deliberately narrow. Unit-of-use RFID addresses the wrong-item-selected subset, not the wrong-volume-drawn majority. Inside that subset it does something nothing else does: it verifies identity in bulk, without contact, without orientation, without line of sight, and against the manufacturer's own record rather than a label printed downstream.
ECRI recommends gravimetric verification. We agree. Gravimetrics and manufacturer-anchored identity verification are complementary controls covering different halves of the same failure surface, and anyone presenting either as a replacement for the other is selling something.
Wrong ingredient substitution. THRIV has documented a case where an order for a low-risk sedative was filled with a paralytic agent, a potentially fatal substitution. An IV workflow management system catches that class of error during compounding, and should. But if the source vial itself was mislabeled or substituted before it reached the pharmacy, no compounding workflow detects it, because every downstream check confirms the label that is already wrong. Verification against the manufacturer's aggregation record - linking that specific vial to the box it was packed in at the plant - is the only check upstream of the mistake.
Dosing errors. In another documented case, a pediatric patient received ten times the ordered dose of sodium chloride and died. That is a volume error, and volume verification is what addresses it. Serialized unit-of-use tracking does not, and we will not claim otherwise. What it adds is a separate, prior assurance: that the container being drawn from is the product and concentration the system believes it is, traceable to a manufacturer's production record rather than to a printed label.
The pharmaceutical industry has a long history with barcodes. The first medication was scanned at the point of care in a hospital in 2000, at the Colmery-O'Neil VA Medical Center in Topeka, Kansas. The FDA enacted the Drug Barcode Rule in 2004. Today, barcode scanning is a cornerstone of medication safety, and over 10 billion barcodes are scanned daily worldwide.
But barcodes have inherent limitations that make them insufficient for unit-of-use verification at the point of care, particularly for injectable medications:
| Capability | 2D Barcode | RFID (TDS 2.3) |
|---|---|---|
| Serialized identity per item | Possible, but seldom done on syringes or vials | Yes |
| Lot number and expiry encoded | Possible, but seldom done on syringes or vials | Yes |
| Read without line of sight | No - requires visual access to label | Yes - reads through packaging and gloves |
| Simultaneous bulk verification | No - one item at a time | Yes - hundreds of items per second |
| Manufacturer resolver in the carrier | No - requires an external directory | Yes - SGTIN++ embeds the hostname |
| Readable on small-form items | Difficult - requires printable label area | Yes - tag embedded in cap, plunger, or barrel |
| Works during sterile compounding | Requires handling and orientation | Yes - contactless, orientation-independent |
For the IV preparation workflows THRIV focuses on, this matters operationally. A technician pulling five vials for a compounding order can have all five checked against the manufacturer's aggregation records - identity, lot, expiry, expected chip - before touching any of them. No scanning, no label orientation, no one-at-a-time handling, no break in the sterile field.
GS1's Sunrise 2027 Initiative is focused on retail and grocery, moving from 1D to 2D barcodes at the checkout counter. It does not cover pharmaceutical packaging. Even if 2D barcodes were adopted for pharma, they still could not deliver line-of-sight-free reading, bulk verification, or an embedded resolver hostname. For unit-of-use items like pre-filled syringes, small vials, and single-dose ampoules, the physical constraints of label area and the operational constraints of one-at-a-time scanning make barcodes impractical as the primary verification mechanism at the point of care.
RFID and barcodes are complementary. Barcodes serve the broader supply chain. RFID serves the last mile, from the pharmacy shelf to the patient.
The key capability in GS1 TDS 2.3 is the SGTIN++ encoding. Unlike earlier tag formats that store only a product identifier and serial number, SGTIN++ includes the manufacturer's resolver hostname directly in the RFID tag's EPC memory.
Any reader, at any point in the supply chain, can determine where to verify an item simply by reading the tag. No lookup table, no central directory, no prior relationship with the manufacturer. The tag says: "I am GTIN 30376045223300, serial 17724760500010655, and my manufacturer's record lives at dosetrace.org."
This is what makes distributed pharmaceutical verification work at scale. Different manufacturers operate different resolvers, and the supply chain does not have to know the topology in advance, because every tag is self-describing.
It also introduces a problem worth naming out loud. If the tag says where to verify it, the tag nominates its own auditor. An adversary controlling both the tag contents and a web host can encode a hostname they operate, publish any record they like there, and a conforming reader will report a clean verification. That has an answer, and it is set out under trust anchoring further down this page.
The registry key is gs1:epcisRepository, per the GS1 Web Vocabulary. Earlier revisions of this page and of the accompanying disclosure used gs1:epcis, which is not a conformant link type. This resolver accepts the request regardless of the value supplied.
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://dosetrace.org/01/30376045223300/21/17724760500010655?linkType=gs1:epcisRepositoryIn a real DSCSA Phase 3 supply chain, no single entity owns all the data. Each manufacturer is responsible for their own products and their own verification infrastructure. The SGTIN++ tag makes that practical by carrying the resolver hostname in every tag.
This resolver - dosetrace.org - serves products whose tags identify it as the authoritative source. Other manufacturers' products resolve to their own domains, such as epcis.cc. A pharmacy receiving a mixed shipment from multiple manufacturers verifies every item seamlessly: each tag self-directs to the correct resolver. No centralized registry, no data broker, no single point of failure.
This reflects a principle DSCSA itself was built on: each trading partner is responsible for their own data. SGTIN++ extends that principle down to the tag. The manufacturer's resolver is the source of truth, and the tag carries the address.
A manufacturer fills and tags 24 vials, packs them into a box, tags the box, and records the aggregation event on their EPCIS resolver. The box ships to a distributor, then to a hospital pharmacy. At every step, the box-level serial is verified under DSCSA - and now the box-level tag can be read in bulk rather than presented to a scanner one face at a time.
At the pharmacy, the box is opened. A technician scans the shelf with an RFID reader. All 24 vials are read simultaneously. Each one is checked against the manufacturer's aggregation record for that box. All 24 match. The items are cleared for dispensing, and the link between vial and parent survives the box being discarded.
Three days later, a nurse pulls one vial for a patient and scans it at bedside. The system confirms: this is vial 17 from box 4082, packed at the manufacturer on March 3, expiry December 2027, lot A240301. That is a unit-of-use item carrying a manufacturer-established provenance to the point of administration.
Every RFID chip carries two distinct identifiers. The EPC - the GTIN and serial number you have seen all over this page - is programmed into the tag. It is the logical identity, the part DSCSA tracks. The chip also carries a TID, a per-chip serial number written into the silicon during semiconductor fabrication. On the production-grade parts a supply chain actually buys, the TID is locked at the factory and an ordinary field programmer cannot rewrite it.
This resolver's EPCIS aggregation records publish the TID alongside each child item:
When a scanpad, conveyor, or bedside reader sees a tag, it reads both values, looks up the manufacturer's record, and compares the TID.
Comparing a value read off a tag against a value fetched from a server is a plaintext equality check. Nothing in the exchange is secret and nothing is challenged, so the check cannot distinguish the chip that legitimately holds the value from any device willing to report the same string. It is not authentication, and this page does not claim it is.
Real cryptographic tag authentication exists and looks different. ISO/IEC 29167 defines air-interface security services for RFID. EPC Gen2v2 defines the Authenticate and Challenge commands. Products like NXP UCODE DNA implement challenge-response against a key that never leaves the chip and never crosses the air. That proves possession of a secret. A TID comparison proves that something in front of the antenna is willing to repeat a number the manufacturer published on the public internet.
Gen2 parts advertising a writable TID bank are also offered for sale by specialty vendors in single quantities with a matching writer, at roughly ten dollars, in at least one case marketed explicitly for anti-counterfeiting bypass analysis. We cite those as vendor listings, not as something we have tested ourselves. The logical point above does not depend on them: an emulator that simply reports the expected TID was always sufficient.
Because the attack stops amortizing, and attacks that do not amortize do not pay.
Supply chain "decommissioning" exists to stop counterfeiters from reusing valid serial numbers. The logic: if a real item with serial X has already been consumed, 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 scan. Every reader, every pharmacy, every distributor phones home.
Publishing TIDs alongside EPCs changes what that registry has to be for. The volume attack it was built to stop - one stolen serial, reproduced ten thousand times - now fails on the first read without consulting anyone, because the counterfeiter cannot produce ten thousand correct TIDs. What is left for the registry is the targeted case, and a central registry was never a good answer to that one either.
In practice the pharmacy fetches the manufacturer's EPCIS record once, when the box arrives at the dock, and caches it. Every scan after that, including the bedside check, is a local comparison. No network round trip, no waiting on someone else's API while a nurse holds a syringe. That property comes from manufacturer-published aggregation and a resolver the tag can name, not from anything about the TID, and it holds regardless of how the TID discussion above resolves.
The weakness named earlier is the sharper one: the tag nominates its own auditor. An adversary who controls the tag contents and a web host skips the TID question entirely. Three measures answer it, and any serious deployment needs at least one:
.well-known endpoint and trusted because it was found there proves only that the host agrees with itself.The signature establishes who wrote the record. The directory establishes who was entitled to write it. Together they are what turns this resolver pattern from a convenience into a control.
The combination described above - RFID TID pairing, an EPCIS 2.0 aggregation extension that publishes TIDs alongside child EPCs, GS1 Digital Link resolution via manufacturer-encoded hostnames on SGTIN++ and SSCC++ tags, local caching at the receiving party, and point-of-administration verification - was published as a defensive technical disclosure on June 30, 2026.
A version 2 erratum was published on July 27, 2026. It withdraws the original document's claim that a counterfeiter "cannot produce a tag with an arbitrary TID," restates TID pairing as the economics control described above, adds the self-nominated-resolver problem and its trust-anchoring answers, and corrects the GS1 link type. No disclosed method was withdrawn or narrowed; the prior-art dedication stands as published on June 30, 2026. The original version remains archived at the anchors below.
The full disclosure, including the erratum, is available at:
The methods, systems, and combinations described in the disclosure are dedicated to the public technical record. Any party in the pharmaceutical supply chain, or any other supply chain where item-level verification matters, is free to implement, deploy, and use the described techniques without seeking permission or paying a license fee. The disclosure exists specifically to prevent any party from obtaining patent rights that would block industry adoption of the pattern this resolver helps demonstrate.
Independent date verification