Re-Supply

Introduction

This domain covers the workflow needs of individuals who are involved in routine vaccine stock resupply from one node to another (example, regional vaccine warehouse hub to district vaccine depot), covering the workflow of both those who act as suppliers of the vaccine product and those who are its receivers.The domain will cover both routine estimation methods (requisitions/pull and allocations/push) as well as workflow support depending on the type of vaccine stock transfer model used (pick-up/collections by receiver or delivery/distribution by supplier).

We looked at four types of supply chains:

  1. Pull/Requisition based that is pick-up transport model (Req. pick-up)
  2. Push/Allocation based that is pick-up transport model (Allocation pick-up)
  3. Pull/Requisition based that is delivery transport model (Req. delivery)
  4. Push/Allocation based that is delivery transport model (Allocation delivery) (Received 11 votes in support of this workflow at workshop in CPH

And the user needs for two different scenarios in the supply chain hierarchy:

(A) Sub-national level RIVO (Supplier) to District level DIVO (Receiver) – both ends have OpenLMIS

(B) District level DIVO (Supplier) to Health Facilities (Receiver) – only the district end has OpenLMIS, HF are paper-based

At present, the stories in this domain are still at a high-level. The domain will be discussed in further detail during the July 2017 regional workshop in Senegal. We hope to collect more detailed information on the critical elements and minimum requirements for supporting the workflow needs from in-country users.

Software development is being tracked in a combination of new epics below

Please be patient with us as we update the following information to reflect the split of work into multiple new pages.

 


Specific Re-Supply features planned for OpenLMIS version 3.3

This table shows the specific features and user stories slated for inclusion in the OpenLMIS version 3.3, which will include the MVP for managing vaccines. The top row indicates the key user activities within the domain, click on the header to navigate to page with details on the related user stories (vertical cells in the table). The user stories with green backgrounds are currently planned for the MVP for the development roadmap. The stories with yellow backgrounds are under discussion and may or may not be included in the MVP scope. The stories with white backgrounds will be considered up next if more funds become available or after the initial release.


Legend

  • Green is planned for MVP
  • Yellow is under discussion (adjustments to MVP scope made since the workshop)
  • White is up next
  • Headers = Key user activities
  • Cells = User stories

Two sets of users: Supplier (such as a RIVO who supplies to DIVO; or a DIVO who supplies to HFs) and Receivers (such as DIVO who receives from level above or HFs)

Submission of necessary data

(Receiver)

View critical data elements

(Supplier)

Set amounts to allocate or issue

(Supplier)

Prepare re-supply order

(Supplier)

Record delivery notes

(Supplier; delivery-based systems only)

Accept Re-Supply Order

(Receiver; delivery-based systems only)

Reject Re-Supply Order

(Receiver; delivery-based systems only)

Update Home Site Inventory

(Supplier and Receiver)

Update SoH of the receiver (if using OpenLMIS) AND Update SOH of the supplier)View forecasted needBatch view SoH

Generate electronic PoD

Record HF visit observations

Votes: +11

Confirm electronic PoDReject full order and provide reason per product line items (Full rejection of product)Receiver updates inventory after accepting products into CCE
Submit electronic requisition request (if using OpenLMIS)View receiver's SoHCapture SoH (if receiver does not have OpenLMIS)

Print PoD if no OpenLMIS at receiver

Record CCE status

Votes: +11


Confirm paper PoD (if receiver does not have OpenLMIS)Partial rejection (only few vials of a product, etc) and provides reasonEdge case: Supplier accepts back viable vials into original CCE and updates inventory data
Provide SoH information to supplier via other means so s/he can input into OpenLMIS (if receiver not using OpenLMIS)

View CCE Status

Votes: -1

Basic view of requisitions

Print electronic PoD

Votes: +10

Record programmatic data

Votes: +11





Provide paper-based requisition request to supplier via other means so s/he can input into OpenLMIS (if receiver not using OpenLMIS)

View total CCE capacity

Formerly MVP, moved out of scope

Capture requisitions (if receiver does not have OpenLMIS)

Goods in Transit Notification

Votes: +5

HF Open/Closed Status





View pipeline

Votes: +6

Supplier sets amounts to allocate/issue

Generate a basic pick list (to gather stock for delivery) that shows

  • antigen
  • amt available
  • Batch/Lot
  • Expiry

Votes: +5






View net CCE capacity

Votes: +3

Group requisitions

Votes: +5

Advanced pick list that includes items in basic list above + location of antigen in cold room/CCE

Votes: 2






View Session Plans

Votes: +4

System recommends amounts (based on FEFO and amount available)

Votes: 13

Confirm shipment via SMS




View utilization (vaccines administered)

Votes: +5

Auto top-up to max. as per country policy

Votes: 6







View consumption (doses out of CCE)

Bundling

Votes: 4








Manage exceptions

Votes: 2








Prioritize Requisitions






Reject approved requisitions




Open Questions

There are two outstanding parts within the re-supply domain that still need significant country users perspective for how to support the two:

  • Needs for modifications of the current "Report and Requisition" workflow within OpenLMIS
  • Re-Supply of Vaccine Stock for Campaigns, including immunization weeks, outreach, emergency responses, and mobile brigade sessions
QuestionStatusOutcome
Are the 'view critical elements' (like estimated needs) the same for requisitions to allocations?OpenYes, SOH and CCE status are common across both approaches

What amount of modifications are needed to the current requisition service to support vaccines?

  • At least a new column with reorder amounts using min and ISAs
Open
  • How should OpenLMIS allow users to update current SOH? 
    • Cannot require a PI because they may only want to update SOH for one product (PI is a workflow for all products).
    • Need to understand what usability would work best in this scenario.
Open

Configuration: Need to determine how OpenLMIS knows which facility is fulfilling for which facility. Does it matter? How do we want to manage this?

Open

How do we support min stock for the re-supply 

Open

How do we handle campaigns in the MVP

  • Re-Supply of Vaccine Stock for Campaigns, including immunization weeks, outreach, emergency responses, and mobile brigade sessions
Open
How important is the 'verification of SOH at a receiving facility' to the resupply process? This brings in quite a lot of complexity and issues when the SOH is submitted within OpenLMIS.  However, if input by the user we would assume it is already verified/validated according to the SOP.Open

Detailed Scope

Select the following wiki pages for detailed information on the user stories within each key activity.

Background

Definitions, so we are all on the same page:

  • Pull SC aka Requisitions SC = lower level sends requisitions orders to upper level and that's the foundation on what the amount of stock to give that level is built on. Req. Orders can be multiple time periods depending on local practice (biweekly, monthly, quarterly, as needed, emergency, etc).
  • Push SC aka Allocations SC = upper level determines how much stock to give to lower level based on factors such as pre-determined needs estimation, a review of stock usage and historic supply data from the lower levels. Again, they might do this over multiple time periods depending on local practice.
  • Pick-up based transport model aka Collections based transport model: lower level picks-up the stock from upper level
  • Delivery-based transport model: upper levels delivers the stock to the lower level; when upper level decides to also take allocation decisions while at the actual delivery site, it is called informed push and is based on vendor managed inventory principles commonly seen in pvt sector. Two examples of this approach is DLS (Mozambique) and Benin. 
  • Copenhagen Small Group Discussions included Kaleb Brownlow, Amy Roberts, Fesha Getahun, Justin Lorenzon, Mary Jo Kochendorfer, and Vidya Sampath were the participants discussing this domain. 

  • You can have 5 types of supply chains as a result in a country and amongst countries:
    1. Pull/Requisition based that is pick-up transport model (Req. pick-up)
    2. Pull/Requisition based that is delivery transport model (Req. delivery)
    3. Push/Allocation based that is pick-up transport model (Allocation pick-up)
    4. Push/Allocation based that is delivery transport model (Allocation delivery) (Received 11 votes in support of this workflow at workshop in CPH)
    5. Ad-hoc, in that what's done on the ground is opposite of what country or region or district says it does on paper/in theory

Save