On a technical working group call recently an interesting reality of some current COVID vaccines surfaced relating to Product definitions and expiration dates.
We all have heard that the Pfizer and Moderna vaccine, so far, need to be stored in a freezer (or even a deep freeze for example -80C) and then may be stored in a more typical refrigerator (e.g 2-8C) for a few days (5 for Pfizer and 30 for Moderna) before being made ready for administration.
What this means is that like most medical products it’ll have an expiration date attached to it, that will likely be printed at the time it’s produced and labelled. This is also true for most of the vaccines we see, however for the newest mRNA vaccines a key difference is that their longer term storage isn’t in a 2-8C refrigerator, but rather a freezer, and when that vaccine is removed from the freezer a new clock starts counting down to a new expiration date, one that won’t be on the label as produced.
Expiration dates are important: both for traceability purposes along with the batch/lot # (i.e. where is everything and where has it been), as well as for operations to achieve processes such as First Expiry First Out and forecast how much will be needed in a re-supply by when. We’ve also seen this be used further, for example to re-balance locations inventory to reduce wastage across a network of locations.
Here’s a slide-deck from a high tech + high resource context using global standards with multiple labels, scanners (aka ADC), and presumably active internet connections to make the best of real-time look-ups.
Note how the different parts of the labels change and others stay the same starting on page 14 with the Manufacturers label:
- Manufacturer’s label has the expiration date while kept frozen.
- A logistics unit identifier (in GS1 known as an SSCC) is generated for new labels when removed from the freezer, and further in the break-pack label.
- The product identifier (GTIN), lot/batch, and serial number all persist from label to label, maintaining the authoritative information about what the product is, as well as traceability elements.
- The expiration date and the serial numbers are updated at specific steps. This adds new operational information (e.g. FEFO on the expiration date) as well as additional traceability aspects (note the serial number is preserved and extended).
To date OpenLMIS has focused on ensuring we have solid Product identification, as well as a concept of a variant of a Product that can form a Kit (IOW a Kit Product is still a Product). We have a lot of the expected traceability and operations elements: batch/lots, expiration dates. We even have placed design placeholders in for future capture of serial numbers (i.e. we know how we’ll capture it, but we don’t have the UX as the demand for barcode capture is still low in many of our implementations).
We have much of the fundamentals we’re seeing above, however we’re clearly lacking the workflows we see above, and in part that’s because we haven’t yet gotten to the logistics unit.
Logistic Unit (SSCC, ISO “License Plate”)
A logistic unit is a pretty familiar concept for many: it could be the pallet or shipping container that the product’s are loaded on/in. It can also be the box or tray that holds and likely is used to assist in transporting products. In GS1 this is known as the Serial Shipping Container Code (SSCC), and in ISO as the “license plate”, or ISO 15459-1.
The logistics unit differs from the product identifier in two important ways for our purposes: it identifies the something that’s aiding in transport or storage and handling (references the product identifier), and unlike a product identifier it’s more casually disposed of: you only need it for as long as the logistics unit is around, whereas the products it carries will have their same identifier for longer. As you can also see you can associate new meta-data to it: additional expiration dates, quantities or other relevant shipping information.
For the most part, the above use-case seems unlikely to be immediately useful in OpenLMIS: high cost for equipment (barcode readers, label printers, computers), inconsistent internet connectivity, and what looks like the likelihood that not many of the mRNA COVID vaccines will be available in LMIC contexts that we also are present in. Together this means that we likely don’t need to task engineering with this today (though I’d be glad to be wrong). However we should keep logistics units in mind for the future as the concept does unlock capabilities we can’t easily achieve today, a few of which I’ll highlight:
- Possibility that we’ll see a new trend in more new vaccines over the next 5-10 years.
- Tracking vaccines in passive cooling devices, or in general a higher level of shipment tracking.
- A number of locations are re-labeling products with their own labels + barcodes. We see this when the barcode is unreadable to the location, or even more often we see product identifiers changed to track from which donor a product came from. Relabeling actually is pretty common and it can result in huge challenges in forecasting, traceability, etc. If we had a logistics unit concept in OpenLMIS, there’d be one less reason for stakeholders to create new product identifiers, and instead create new logistic unit identifiers.
- For being more interoperable with other organizations that focus on moving products for us (e.g. 3PL), though we’d also want shipment identifiers.
- For these instances where someone says they want a Product Kit, but where their definition doesn’t match ours - i.e. their definition can’t fit that of a Product. This might be the first place this is useful to us as we’ve heard this from a few stakeholders over the years.
If anyone has anything else they’d like to share, or ask questions on, you are welcome to!