Imagine if the DMV didn’t maintain a database of drivers and their driving history. Instead, they just printed all the important information on your driver’s license — such as your name, date of birth, and preferences for organ donation — and relied on each driver to carry their license at all times.
Now, imagine if someone got pulled over for speeding three times last year. The first time might be a pretty normal traffic stop. During the second and third stops, though, the officer would probably want to know that this driver has a history such behavior. But remember, in our fictional scenario here, there is no DMV database in which the officer can lookup your license and driving record; instead, she would need to rely on what’s printed on your license.
I don’t need to describe this fictional scene too much further, do I? It’s pretty obvious that this is a nonsensical system, prone to incomplete, outdated information and fraud.
The DMV figured this out decades ago. Why can’t we make similar advancements in the management, serialization, and tracking of drugs too? Well, that’s exactly what UnitVisID can help with.
By Copy, By Reference
In most computer programming languages, when you want to use a particular piece of information in multiple places, there are two ways to do something.
- By Copy — The first approach is to keep copying the data to each place you might need it.
- By Reference — The second approach is to only have one copy of the information (a “single source of truth”). Any time your code needs to read or update this, rather than telling it the information directly, you give it an address or pointer (the “reference”) so it knows where to look for the source of truth.
The first approach — by copy — might seem easier at first glance. After all, you always have the data at hand and never need to look anything up. But imagine if that data changes over time. You will inevitably find yourself in a situation where you’ve got multiple copies of the data that get outdated or out of sync.
The second approach — by reference — might be slightly more complicated, but can make the difference between correct, complete, and current data vs. not.
How does this relate to drug labels?
A drug label is kind of like a driver’s license which (theoretically) can contain all the information about a driver and her driving history. The pharmaceutical manufacturer knows some of the information about a particular drug when they print and apply the label to a vial or syringe; for example, they know the NDC, drug name, concentration, lot number, and expiration date. So, they print it.
Good start! But what if that drug is a refrigerated drug like rocuronium or succinylcholine?
Refrigerated drugs will eventually have a “beyond use date” (BUD) calculated when they leave cold storage. The BUD is typically determined by calculating some number of days (maybe 30 or 60 days) after the drug is removed from refrigeration. But the manufacturer doesn’t know this information when they’re printing and applying the drug’s label. And so, our system of relying on that copy of data — the copy that’s printed on that vial’s label — starts to break down.
But, if we track all the attributes and events for this unique, serialized vial in a database — just like the driver information and driving history in the DMV database — we can now have access to a rich dataset about the vial in question, including information created downstream from the manufacturer, such as beyond use dates.
Benefits of Unit Dose Serialization, Coupled with the Registry
Unique and Addressable — By having a serial number on each unit dose, we can treat each vial and syringe as a unique and addressable object, not just one of many anonymous doppelgängers from within a production batch. This allows you to handle use cases like:
- beyond use dating
- recall management
- tracking items through various inventory management systems and workflows
- associating items with events such as patient administration
- looking up individual items to research or manage with exceptions (i.e. finding a vial of fentanyl on the bathroom floor)
Additional Information — By storing the item’s attributes and event history in the Registry, instead of printing it on the label or encoding it into a barcode, you can store an unlimited number of attributes and events. You’re not limited to the physical space on a label or within a barcode.
Evolving Over Time — You can add to each item’s set of attributes and events as that item works its way through the supply chain to the patient. The beyond use date, described above, is a great example of this. You’re not limited to that which you know at the time of manufacturing and label printing.
These benefits are not found in most of today’s drugs and static labels, but with UnitVisID medications, these benefits are always included. When your systems make use of this information, it leads to increased safety, efficiency, and visibility.
In Part 2
In part two of this series, we’ll talk about the barcode’s role and explore the impact it has on system interoperability at the hospital. Read part 2: The Evolution of Drug Tracking: from Barcodes to The Registry