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:

Storeroom Clerk / DIVO for Physical Inventory

  1. As a Stockroom Clerk I turn on my computer, open my web-browser, and go to OpenLMIS where I login using my account.

  2. When I’m ready to do a physical inventory, I go to the Physical Inventory screen in OpenLMIS on my computer under Stock Management.

  3. I click on Scan Barcode(s) button which brings up an empty table.

  4. 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.

  5. I put the vial back in place.

  6. I continue to take a vial, scan its barcode, and then return it to its place.

  7. 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.

  8. 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

The following journey works for an Immunization Nurse, however since OpenLMIS is not an EIR, patient data is not captured and warnings for dispensing expired stock are not given.

  1. As an Immunization Nurse I turn on my computer, open my web-browser, and go to OpenLMIS where I login using my account.

  2. When a new patient is ready to receive a vaccine dose, I go to the Adjustments screen in OpenLMIS on my computer under Stock Management.

  3. I click on Scan Barcode(s) button which brings up an empty table.

  4. I turn-on my barcode reader, take the vaccine vial I’m about to dispense from, and scan the barcode, which populates a row in the table on the computer screen.

  5. I administer the vaccine to the patient.

  6. I may continue to scan other vaccine vials for the same patient, as well as scan other vials for other patients throughout my day.

  7. When I’m ready, I return to my computer with OpenLMIS' Adjustment 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.

  8. When ready I click on the Confirm Scans button which takes all of my scan data and turns it into rows on the Adjustments screen, where I then fill in a Reason (such as dispensed) and a quantity (expected to be 1 if using sGTIN).

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)

Barcode Scan Modal

Physical Inventory

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:

Size

Epic

Small

https://openlmis.atlassian.net/browse/OLMIS-5642

https://openlmis.atlassian.net/browse/OLMIS-4895

Medium

https://openlmis.atlassian.net/browse/OLMIS-4842

https://openlmis.atlassian.net/browse/OLMIS-1094

Large

https://openlmis.atlassian.net/browse/OLMIS-3385

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 https://openlmis.atlassian.net/browse/OLMIS-1621 . 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 https://openlmis.atlassian.net/browse/OLMIS-1621 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