Tracing Every Dose - Manufacturer EPCIS Resolver for DSCSA Phase 3 Unit-of-Use Verification
Give the dose an identity at the manufacturer. Then give it a parent worth checking against.
The shorthand version of this problem - "individual doses are not serialized" - is close enough to true that it gets repeated, and imprecise enough that a pharmacy director will push back on it. So here it is properly.
The first gap is identity. The overwhelming majority of vials, syringes, and ampoules leave the manufacturer with no serialized RFID identity of any kind. DSCSA does not require one, and nothing in the supply chain supplies one. The dose a nurse draws from is, electronically, an anonymous object.
The second gap is whose identity it is. A small fraction of unit-of-use items do carry a tag, applied downstream by the hospital. Kit and tray management has done this well for years, and those systems do build an aggregation: the technician reads the unit of sale, tags the items coming out of it, and the software associates them. Credit where it is due - that is a real parent-child record and it does real work. But it is assembled locally, after the box is open, from an identity the pharmacy assigned, against a parent the pharmacy cannot independently verify. It documents what this pharmacy put together. It cannot document what the manufacturer packed.
And there is nothing upstream to check it against, because the sealed unit of sale arrives with a printed 2D barcode and no RFID tag. Outside this demonstration, no site anywhere is performing RFID scanning of a unit of sale that contains RFID-tagged units of use. The parent half of the relationship has no installed base whatsoever.
It is both halves, and they are not symmetric.
Most doses carry no serialized identity at all. The few that do were tagged downstream and aggregated to a parent the pharmacy assembled rather than one the manufacturer published. And there is no manufacturer-side RFID parent for anything to point at yet.
A downstream tag answers "what is on my shelf." A manufacturer aggregation answers "what did the manufacturer put in the box." Only the second is provenance, and provenance is what the point of care has never had.
The dose, and it is not a close call. Not because the parent record is optional - it is what turns an identity into a provenance - but because the parent side has no installed base to build on, while a manufacturer-applied serial on the vial pays for itself before any parent exists. It removes the downstream tagging labor outright, and it replaces an identity the pharmacy invented with one that still means something after the item leaves the building.
Once the doses carry manufacturer identity, tagging the parent and publishing the aggregation is a change at the packaging line, not a change to a single clinical workflow. That sequence is why this resolver exists: the endpoint has to be demonstrably real before anyone tags a parent to point at it.
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: original disclosure, June 30, 2026
These fix the prior-art date. They carry the original, uncorrected text.
Independent date verification: version 2 erratum, July 27, 2026
These fix the date of the correction, not the date of the disclosure.