2D data matrices: practical uses
Since the DQSA passed back in 2013, data matrices have made their way onto practically all of the pharmaceutical packages on pharmacy shelves today. How can pharmacists use these innocuous barcodes?
These past two weeks, I have spent a fair amount of time pulling overstocked inventory and sending it for return to our wholesaler. My process for pulling returns at the moment is fairly inefficient: I walk through each shelf and look at the sticker from our wholesaler to see when the product was received, at what price, and then I look at the expiration date of the bottle and whether the seal is intact to see if it meets returnability criteria. My rule of thumb is if a bottle has been on my shelf for 2 months, it’s time to send it back.
As I’ve been walking the shelves, I’ve been musing about the 2D data matrices that are present on every bottle. For the uninitiated, this is what I’m talking about:
Note that I am NOT talking about a QR (quick response) code. QR codes look like this:
Many pharmacists refer to the data matrices on pharmaceuticals as QR codes, but they aren’t QR codes. GS1, the standards development organization responsible for the format of data matrices discusses the format here. They are matrices encoding specific data points about the bottle, in particular:
1) The Global Trade Item Number (GTIN): this is a longer version of the more familiar NDC or UPC number which specifies that the product in question is intended for sale in the United States. (prefix is 01)
2) The lot number (prefix is 10)
3) The expiration date (prefix is 17)
4) The bottle serial number: this is a unique number for each bottle of a given GTIN. (prefix is 21)
Since the enactment of the DSCSA as part of the DQSA (Drug Quality and Security Act), data matrices have been a required component of labeling. The FDA’s guidance for industry on the topic is here.
Many pieces of hardware and software that pharmacies use are able to interpret these data matrices, though many of them are incomplete in their interpretations. For example, my pharmacy software has the capacity to read the data matrix and extract the lot, expiration and GTIN to verify that the product used matches the product selected, provided that I have a 2D barcode scanner present at my workstation. It’s inconsistent though: in one area it can extract all three of those, and in another, it only extracts the lot and expiration, so I then have to scan the 1D UPC barcode to verify the product.
In addition, we have an EyeCon 9420 in our pharmacy. The EyeCon 9420 and 9430 are capable of reading the 2D data matrix and they record the NDC (contained in the GTIN), the lot, expiration and serial number into the transaction data (which gets printed onto an image that I can display in my software below the tray image of the tablets). I can see the transaction data in my pharmacy software, but only by pulling up that image. This makes patient level recalls more annoying than they should be (but more manageable that before we had the 9420). Ideally when I get a recall notice, I should be able to just search all of my dispensing records in my main pharmacy software and filter down in that database to see which prescription dispensations were fulfilled using the lot numbers in question. As it stands, I have to search for the NDC and then go pull an image for each of the transactions individually to see if that lot number was used. The Eyecon and my software have an API which transmits the NDC, the user, and other transactional data (I think mainly to allow my dispensing software to know which transaction to pull up from the Eyecon when I do an image request). With some modifications, this API could include the lot, expiration and serial and then that data could record to my dispensing database. Programmers and their time are a limited resource though, and the use case is pretty narrow.
Aside: I have to record lot and expiration when dispensing compounded products. I’d love to be able to print a (smaller) data matrix containing the internal compounded item number/formula ID, and the lot and expiration date as part of the batch stickers that we apply to our compound batches. I don’t have the technical chops to figure out how to do that. I have previously (manually - separate from the normal sticker) printed three separate 1D barcodes to apply to our batches (item, lot, expiry) which my software can parse if I scan them in the correct order.
So how does this relate to pulling products for return to my wholesaler?
Remember that my current process is based on pulling bottles off the shelf based on the sticker from the wholesaler and the expiration date. As I was doing this over and over, I thought to myself: what if we used those 2D matrices when receiving product at the pharmacy and when doing inventory counts and also recorded the lot/expiration/serial number used for every dispensing (through the use of the Eyecon)? What would be the implications of that?
A well designed inventory receiving system and process would allow a pharmacy to be precise about watching expiration dates of product and would allow the pharmacy to search for specific bottles that had been in stock for a certain time frame. What would this look like?
1) Supplier sends .810 invoice file containing the lot/exp/serial in a structured format.
2) Pharmacy receives shipment in a dedicated workflow in their software (perhaps with a peripheral input like an app) by pulling up an invoice to be received and then scanning the 2D data matrix for each bottle.
3) Pharmacy software associates the serial number, lot and expiration date for each bottle with the invoice.
4) On each dispensing, pharmacy scans the 2D data matrix (instead of the 1D barcode), which records the use of that specific bottle (or bottles in many cases).
5) When the pharmacy needs to identify items which will expire in the next month or two, they run a report from their software which lists all of the NDCs and serial numbers with an expiration date recorded as during the target date range. Depending on the pharmacy’s compliance to the prior steps, it could also be filtered to bottles/serial numbers still presumed to be in inventory.
6) Similarly when the pharmacy wants to pull inventory for returns or for transfer to other pharmacies, they can now search for bottles meeting search criteria (purchased from wholesaler X, purchased >2 months ago and <12 months ago, expiration >6 months in advance of expiration, bottle presumed sealed based on usage, cost of goods greater than a given threshold).
There would need to be a function to manually mark serial numbers en masse as previously used, as most pharmacies would not have perfect compliance to the necessary processes to capture all of the data elements needed.
The human element to make this work though is not dissimilar from the current processes in place at most pharmacies. The major change to pharmacy staff habits would be that 1D barcode scanning would need to be replaced by data matrix scanning. Otherwise, all of the rest of this is software coding.
There are some other barriers to this working as I envision it: primarily that the data matrices are not codified in the same manner across different manufacturers. My software for example CANNOT parse the matrices on ventolin HFA or Prasco brand albuterol inhalers, among others. I’m uncertain why this is but I suspect that the software is reading some element of the serial number or GTIN as the prefix identifiers for the lot or expiration date.
Anyhow, with appropriate software supports and a change to staff habits from using 1D barcodes to 2D data matrices when receiving and dispensing product, the time I spent pulling inventory for return could have been done much quicker, among other benefits. I’d love to hear other folks’ thoughts about this.