Vial-to-child Barcode Scanning LOE Narrative
Background
In support of traceability efforts and to pilot a new application identifier available which is able to encode the VVM status of a vaccine vial into certain types of barcodes, this document will provide a rough first exploration of the level of effort that would be required to capture and use this data in OpenLMIS.
User Journey
User Persona: Storeroom Clerk
Tools needed:
A PC with always-on internet connectivity (note: supporting occasionally connected internet is under development separately - https://openlmis.atlassian.net/browse/OLMIS-1621, more on this is in the Total Cost of Ownership section)
A web-browser running OpenLMIS, and an OpenLMIS account.
A barcode reader that can read a 2D barcode (GS1 DataMatrix - ECC 200).
WiFi or Bluetooth to support the communication between barcode reader and computer, depending on requirements of barcode reader
Storeroom Clerk / DIVO for Physical Inventory
As a Stockroom Clerk I turn on my computer, open my web-browser, and go to OpenLMIS where I login using my account.
When I’m ready to do a physical inventory, I go to the Physical Inventory screen in OpenLMIS on my computer under Stock Management.
I click on Scan Barcode(s) button which brings up an empty table.
I turn-on my barcode reader, take the vaccine vial I’m about to count, and scan the barcode, which populates a row in the table on the computer screen.
I put the vial back in place.
I continue to take a vial, scan its barcode, and then return it to its place.
When I’m ready, I return to my computer with OpenLMIS' Physical Inventory screen, and I can now review all of the scans I have made with my reader. Each scan has produced a row in my table, where each row is: product name, lot/batch number, expiration date, VVM status, and serial number. I’m given the option to remove any row (adding a row is done by doing an additional scan), canceling all scans, or confirming my scans. If I choose to cancel my scans a confirmation box will display making sure I want to discard all my scans.
When ready I confirm my scans which populates the Current Stock, VVM Status and Reasons columns using every sGTIN scan as a +1 for Current Stock, and the maximum VVM status scanned. If a Product or lot is encountered not already on the physical inventory screen, it is added to the table (same as the Add Product button).
Additional Journeys
In an receive workflow
In an issue workflow
As part of a Proof of Delivery (variation on Receive)
Work
The following focuses on the Physical Inventory journey, however it’s constructed in a way for planned re-usability and extension in additional journeys (e.g. Issue, Receive, etc), as well as expanding the manual workflow if we choose to back-away from the design presumptions of having serialized GTINs (sGTIN) and VVM statuses in the primary packaging barcode. In the latter case, if the barcode didn’t have an sGTIN nor a VVM status, we expect there to be more manual counting and entering of quantities after a barcode is scanned on the computer screens (or adopting a mobile device where quantities can be entered on the spot), as without an sGTIN on the primary package the user can’t rely on single-scans alone to arrive at a total quantity easily.
To this end the work envisions two re-usable components: a Barcode Parsing component which can parse Application Identifiers (AI) found in raw-data from barcode readers reading GS1 Datamatrix in the browser, and a Barcode Scan Modal which is meant to direct user input from a scanner to the parser, which can be included in one of the user-journey’s stock management workflows (e.g. Physical Inventory).
Barcode Parsing (aka Application Identifier parsing)
As a Stockroom Clerk I want scans from my barcode scanner to parse GTIN-14 (AI 01) from the barcode so that I know which product I’m scanning.
As a Stockroom Clerk I want scans from my barcode scanner to parse Batch/Lot number (AI 10) from the barcode so that I know which batch or lot I’m scanning.
As a Stockroom Clerk I want scans from my barcode scanner to parse Expiration Date (AI 17) from the barcode so that I know when the product I’ve scanned expires.
As a Stockroom Clerk I want scans from my barcode scanner to parse Serial Number (AI 21) from the barcode so that I know the serial number of the product I’ve just scanned.
As a Stockroom Clerk I want scans from my barcode scanner to parse VVM (AI 8009) from the barcode so that I know at which VVM stage the vial I’ve just scanned is at.
Barcode Scan Modal
As a Stockroom Clerk I want scans from my barcode reader to populate a table in my Barcode Scans Modal, where each scan produces a new row in my modal with the AI that my scan has parsed so that I can see that my barcode reader is scanning into my application.
As a Stockroom Clerk I want any duplicated scans of the same product+serial number to be automatically collapsed to one scan so that I don’t miscount.
As a Stockroom Clerk I want to be able to remove any scanned row from my Barcode Scans so that I can remove an inadvertent scan.
As a Stockroom Clerk I want a button that says “Cancel” on Barcode Scans so that I can discard all scans I’ve made easily.
As a Stockroom Clerk I want a confirmation dialog to display if I click Cancel on the Barcode Scans modal that asks me to confirm my cancel in case I inadvertently clicked cancel and I do not want to erase all of my scans.
As a Stockroom Clerk I want a button that says “Add N Scanned Items to Physical Inventory” that will confirm all my scans so that I may add my scanned items to my in-progress physical inventory.
As a Stockroom Clerk I want Lots not currently listed in OpenLMIS to be automatically added to OpenLMIS so that I don’t need to manage lots, it does it for me.
As a Stockroom Clerk I want scans of GTIN + Serial number to be remembered between invocations of the Barcode Scan modal of any unique Stock Management transaction (Physical Inventory, Adjustment, Issue, Receive, etc) so that if I bring up the modal more than once, and scan the same item again, it knows that it’s seen this same scanned item before recently and I don’t miscount.
Physical Inventory
As an Stockroom Clerk I want a button to exist on the Physical Inventory screen that says “Scan Barcodes” that when clicked brings up my Barcode Scans Modal so that I can indicate that I can capture input from a barcode scanner.
As a Stockroom Clerk I want Products & Lots not currently listed in my Physical Inventory to be automatically added to my inventory so that I don’t need to separately add them through Add Product.
As a Stockroom Clerk I want the count of unique product + serial number scans to count toward my Current Stock of that Product+Lot’s quantity so that I accurately use my scans to count toward my on-hand inventory.
As a Stockroom Clerk I want the maximum VVM Status (meaning Stage N > Stage N-1) scanned to update my VVM Status column so that my VVM status column always contains the maximum VVM status that I have entered into my physical inventory.
As a Stockroom Clerk I want any scans which are troublesome to present a warning to the user so that Products not in OpenLMIS, expiration dates which have passed, or VVM statuses beyond keeping are flagged to remind me that I encountered such products.
As an Administrator I want to associate the semantics of discarding an item due to expiration date passing to a single Stock Reason.
As an Administrator I want to associate the semantics of discarding an item do to passed VVM status to a single Stock Reason.
As a Stockroom Clerk I want any expired scans to add to the quantity of Reasons of that Product so that I don’t have to manually add that reason.
As a Stockroom Clerk I want any VVM Status scans greater than 2 to add to the quantity of Reasons of that Product so that I don’t have to manually add that reason.
Work Sizing
The relative work sizing at this stage is prepared by the project’s architect using relative t-shirt sizing referencing completed epics.
Reference Epics:
Estimate
Size
Item | T-shirt size |
|---|---|
Barcode Parsing | Small |
Barcode Scan Modal | Small-Medium |
Physical Inventory | Medium |
An initial estimate for the work referenced above is combined that of 1 x Small, 1 Small-Medium, and 1 x Medium. It’s expected that to add additional Stock Management journeys, we can expect their sizing to be similar to that of Physical Inventory.
Velocity
With the current core team funding level we are able to complete 1-2 small epics and 1 medium or well-defined large epic per release cycle. While we could add additional staff to help us move a little faster on this, the dependency on the two Barcode-related epics means that adding more people will not help to accelerate the delivery of the Physical Inventory updates. However, if there are other Stock Management journeys that we want to consider, additional staff would allow us to work on those journeys concurrently.
Sprints
Item | Size | Estimated Sprints to Completion |
|---|---|---|
Barcode Parsing | Small | 3-4 Sprints |
Barcode Scan Modal | Small-Medium | 4-5 Sprints |
Physical Inventory | Medium | 6-8 Sprints |
Total |
| 13-17 Sprints |
If we were trying to fit this into our traditional quarterly release schedule, I would schedule the two small epics for one release cycle (to be worked on concurrently) and then start on the Physical Inventory epic once those smaller epics are completed, with the expectation that it would be completed the next release cycle.
Total Cost of Ownership
The above journey makes a number of design choices that effect the Total Cost of Ownership (TCO), generally balancing hardware pricing against software development cost.
A barcode reader vs a camera
A barcode reader is assumed to be used as currently OpenLMIS doesn’t work on a mobile device, and physically bringing the computer and the product in close enough proximity for a computer’s camera to read the barcode is likely not viable for an end-user in our expected work environments.
Additionally there is some practical guidance that barcode readers work better than cameras in low-light environments (@Wesley Brown or @Brian Taliesin do you have a handy link for this?) which are typical for many of our work environments.
The cost of a barcode reader is approximately $100 USD per location.
Using OpenLMIS on a PC vs a mobile device
OpenLMIS today works on a PC, generally because workflows today are paper-oriented, and therefore the forms are wide mandating large screen relestate. Moving away from paper to direct to digital data-entry, of which barcodes are a part, is an argument for moving OpenLMIS to smaller screen workflows, including mobile devices. At this point however the effort to undertake that software development cost is kept separate as there are many workflow changes in moving to mobile devices.
The cost of a PC with internet is approximately $1000 USD + a recurring monthly charge of $20 USD for data based on the local MNO rates.
Always-on Internet
Currently OpenLMIS Stock Management requires always-on internet. There is work currently scheduled to enhance Stock Management to work in occasionally connected environments in . While this work is scheduled, it isn’t trivial to add to OpenLMIS in terms of work, and the current user journey is a challenge for locations where internet bandwidth is narrow in the following way: there are many products that could be scanned, and scanning only returns a numeric product identifier (GTIN). Converting this numeric identifier to a human-readable product name is done with the least bandwidth when done on-demand. Locations with challenged internet connections will always face the same trade-off within OpenLMIS: on-demand interactions will take less bandwidth, however they’ll need to be connected all the time to work, whereas refreshing shared data dictionaries, such as a full list of Product Identifier to Product Name mappings, will require more overall bandwidth and therefore a longer lead time to getting a useful reference data-set on their local device. As the data-set grows larger, such as adding new products into the supply chain, so does the problem faced by locations trying to preload all of this data, some of which they may never actually need or use.
Currently is estimated as an Extra Large, meaning that the work is significantly more than a Large. This currently has no sizing reference to give us an accurate estimate for sprints needed for completion. While this work is scheduled, it’s recommended that this pilot focus on always-on internet locations before tackling internet-challenged locations.
Relevant Links
Gap Feature Groupings as Sizing Reference
Stock Management Barcodes epic design
OpenLMIS: the global initiative for powerful LMIS software