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:

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.

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

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

Title	Document owner	Document status	Epic	Target release	Technical Lead
A. Plan Re-Supply Order	Vidya Sampath	DRAFT		3.3
B. Prepare Re-Supply Order for Delivery or Pick-Up	Vidya Sampath	DRAFT		3.3
C. Accept Re-Supply Order (Delivery only)	Vidya Sampath	DRAFT		3.3
D. Reject Re-Supply Order (Delivery only)	Vidya Sampath	DRAFT		3.3
E. KPIS, Reports, Notifications	Vidya Sampath	DRAFT		3.3
F. Campaign Workflow	Vidya Sampath	DRAFT		3.3
[DISC] Reporting Domain: Delivery/Re-Supply KPIs	Vidya Sampath	DRAFT	Reporting Domain	Vaccine Module	Technical Lead who reviews or supports document

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