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:
- Pull/Requisition based that is pick-up transport model (Req. pick-up)
- Push/Allocation based that is pick-up transport model (Allocation pick-up)
- Pull/Requisition based that is delivery transport model (Req. delivery)
- 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.
| Note |
|---|
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. |
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) | (Supplier) | Set amounts to allocate or issue (Supplier) | (Supplier) | (Supplier; delivery-based systems only) | (Receiver; delivery-based systems only) | (Receiver; delivery-based systems only) | (Supplier and Receiver) |
|---|---|---|---|---|---|---|---|
| Update SoH of the receiver (if using OpenLMIS) AND Update SOH of the supplier) | View forecasted need | Batch view SoH | Generate electronic PoD | Record HF visit observations Votes: +11 | Confirm electronic PoD | Reject 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 SoH | Capture 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 reason | Edge 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
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
| Question | Status | Outcome |
|---|---|---|
| Are the 'view critical elements' (like estimated needs) the same for requisitions to allocations? | Open | Yes, SOH and CCE status are common across both approaches |
What amount of modifications are needed to the current requisition service to support vaccines?
| Open | |
| 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
| 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.
| Page Properties Report | ||
|---|---|---|
|
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:
- Pull/Requisition based that is pick-up transport model (Req. pick-up)
- Pull/Requisition based that is delivery transport model (Req. delivery)
- Push/Allocation based that is pick-up transport model (Allocation pick-up)
- Push/Allocation based that is delivery transport model (Allocation delivery) (Received 11 votes in support of this workflow at workshop in CPH)
- 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
| Gliffy | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|