eZICS

Electronic Zambia Inventory Control System - Project Requirements Document

Description of User Cases / Systems Interface Issues / Device Menus / Process Flow Charts and Policy Issues

Introduction

This document attempts to illustrate from Medical Stores Ltd (MSL) perspective. The various uses of the proposed system, how eZICS will integrate to the current Ministry of Health (MoH) / MSL systems and procedures and further describes how MoH / MSL would wish to see the device menus structured and the work flow processes required both at the health care institution, the District Health Office (DHO) and centrally at MSL / MoH.

This document is not intended to be a system design but rather to illustrate to the systems designers the type of interactions we anticipate the system will need to perform given MSL understanding of the operational / procedural and legal requirements. This report has 5 sections.

1. Systems Interface / User cases

o Document draft prepared by J Gallien from the February meeting in Lusaka. This document describes the various user case interactions for the functions required to control the system.

2. Device Menus

o This document outlines the Menus as MSL perceives them at this time. These are clearly open to interpretation and amendment / improvement during the system design process. They have been prepared to allow MSL management team to visualise the process required and aid management in ensuring we keep things simple and cover all perceived eventualities. We would expect these to be developed and improved during the systems design process. However, we should always keep in mind that this system must be simple for the user. The device structures are shown at two levels: The health care stock holding facility and the controlling District / Central Ministry of Health (MoH) level.

3. Process flow charts

o The process flows have been developed by MSL to visualise the processes involved and to ensure that all required procedures as per Zambian / MoH processes and legal requirements are followed. This section has been designed to ensure that MSL internal procedures and controls will match the expected processes at rural level and District level within the health care system.

4. Systems issues to consider in relation to the Interfaces required between MACS and IBM

1 | P a g e

o This document prepared by MSL describes the various issues which interrelate between eZICS / MSL operating procedures and MACS (MSL Warehouse Management Software)

5. Policy Issues

o Summarises the key governmental policy issues that need to be taken into account on the system design.

Index Pages1. J Gallien report from Feb meeting Systems User Cases 3 15

2. Device Menus 17 24

3. Process flow Charts 25 37

4. Integration Issues with MSL / MoH procedures / MACS 38 47

5. Summary of Key Policy Issues 48

6. Volumetric calculations 49

2 | P a g e

Section 1

Zambia Inventory Control System

System Interface / Use Cases1

Definition of Terms

Product box Unit of Measure (UOM): smallest package size handled at MSL when picking items to complete a facility. Corresponds to an MSL product code (product type + package size). This is also the level at which Batch / Expiry data and barcode information is kept.

Shipment box: Cardboard box used to package for handling purposes different product boxes to be delivered to a specific facility on a given delivery route

Order: set of one or several shipment boxes constituting together a single shipment from MSL to a facility on a given truck delivery route, an order will further constitute the amalgamation of the Shipment Optimisation process and the Supplemental order. This order will be passed to MACS to allow the picking and packing of the shipment boxes.

Supplemental Order: Constitutes those items that a facility may order through the device, but will not flow the forecasting and optimisation suites. i.e. low volume or very sporadically ordered products. There will be a defined list of such products for the various levels of the health care structure.

Emergency Order: Emergency orders will cater for absolute exceptions for products that are neither normal shipment optimised order or supplemental orders. Emergency orders will not be processed via the eZICS system; they will be presented to MSL as per current procedure and will be processed manually.

Barcodes: Barcodes will be used whenever possible to capture product information at the various levels of transactions and also to capture the information attached to shipments. The barcode systems to use will be Code 39 for product barcodes and EAN128 for shipment labels, both of these protocols being industry standard for the pharmaceutical industry, although the system should be able to utilise other common barcode protocols.

1 Document draft prepared by Jrmie Gallien and edited by Ian Ryden and Dirk Van Wyk based on input from participants to the system design workshop organized in February 1-5 2011 in Lusaka.3 | P a g e

Forecast: The system generated forward looking view of demand, calculated per week with a future horizon of 18 months.

MoH Approved Forecast: This is the Forecast as amended by duly authorised MoH staff at District / Hospital. Such staff will amend the forecast for a future horizon of 1 month from the next shipment date. In determining why the forecast should be amended such staff will be assessing the quality of the constituent parts of the forecast (Issues / Receipts / Adj etc and will make necessary amendments to correct any data errors. They will further be assessing if the future month poses any significant challenges that could not be foreseen in the forecast. Such events may include Disease outbreak, Immunisation programme, etc.

Shipment optimised products- Any product that will be controlled within the optimisation programme, all such products will be managed by the various devices controlling eZICS. Switch???? To transfer from one pot to the other

Shipments A shipment will become the amalgamated orders once the shipment optimised products and the supplemental orders are completed. In other words the two types of orders will be merged to produce one input to MACS.

Outline

This document describes the various use cases for the inventory control system envisioned. It covers in turn the interface between the different types of users and the envisioned system, as follows: 1. Health Centre Staff; 2. District Staff; 3. MSL Staff; 4. MSL Management; 5. Ministry of Health.

1. Health Centre Staff

1.1 Hardware

Mobile device with relatively large screen, keyboard, cellular communication capabilities, standard format memory card slot, IR or Bluetooth device-to-device communication capabilities and integrated or separate laser bar code scanner.

1.2 Inventory Transactions Recording

The mobile hardware and its client software application will support the recording and transmission by cellular network of all relevant local stock-related transactions. Before listing these transactions (e.g., receipt, issue, stock count, etc.) individually, we define the key common interface component used to specify which exact product type the stock transaction relates to.

Product Type Input:

Case 1: In the few cases where the product box contains a manufacturer-issued bar code, the employee can scan directly this bar code with the device from the product box;

Case 2: If Case 1 does not apply, the employee can identify the product type on a local printed catalogue (or poster) of products containing the product description, the MSL code and a printed bar code for all/most frequent products, and scan the bar code associated with that product type from the catalogue.

4 | P a g e

Case 3: If neither Case 1 nor Case 2 applies, the employee can also manually enter the product code provided by either the existing MSL catalogue or the bar-code catalogue mentioned in Case 2, using an ergonomically designed drop-down menu/scrolling interface.

All input cases above are followed by a confirmation step involving a visible screen message showing the full description in words of the product type just entered, the pack size / dosage information and quantity of goods involved (i.e. information stored at product box level) and a confirmation or cancellation button-based input required from the employee to verify that the entry just submitted corresponds indeed to the product for which the employee intends to record a stock transaction.

We now list the individual stock transactions types required.

Receipt: specification that a certain quantity of a specific product is being received by the facilitys inventory manager at a given time and should be added to the existing stock on record. There are two cases.

Case 1 - Full order receipt. As responsibility/ownership of the inventory is being transferred, the facility employee uses the device to read the bar code appearing on the printed label attached to the dispatch note or packing label on any one of the shipment boxes from the order (or manually enters the alphanumerical reference code printed on the same label if a functioning bar code scanner is not available). Upon a confirmation from the application that the full order receipt process is available for this order (see below), the health centre worker enters the number of boxes from the order that are being received. If the number of entered boxes matches that recorded in the system at MSL for that order, the transaction is complete. Note: it is important for the system/application to ensure that the number of order boxes entered at MSL is known to the local device before authorizing this full order receipt process, otherwise inventory tracking integrity could be lost (i.e., if the system could mislead the user to believe for some time that this full order receipt method was successful/appropriate when in fact it is not, during that time the user could physically move the products from the shipment boxes to the pharmacys storage shelves, making it more difficult to properly record this receipt with the alternative inventory receipt methods described next)

Case 2 Line by line order receipt confirmation. This second order receipt method is more labour-intensive than the previous one, but offers more control and still leverages the order data information in order to save time. It involves the initial input of an MSL order number or barcode, then the input of specific quantities of each product type being received through an interface displaying at the same time all the product types and recorded shipment quantities present in the database for that order.

Case 3 - Individual item receipt. This third inventory receipt method, most flexible but also most labour-intensive, may be used in the following circumstances: (i) the order receipt method described in Case 1 cannot be used because the number of shipment boxes for that order recorded at MSL is not known locally (e.g., connectivity problems), or does not match the number being received; (ii) some shipment boxes in the order have already been opened/damaged; (iii) there is insufficient transportation or storage capacity for the facility to

5 | P a g e

receive all the shipment boxes of an order at the same time; (iv) inventory not associated with an MSL order is being received, such as transfers from other facilities or bulk inventory from the district; (v) inventory from sources other than MSL (e.g. donations from other partners, local purchase from the private sector) is being received. In those cases, the HC worker proceeds to a drug-by-drug receipt process relying for each drug on the product type input process described above (see product type input), followed by a specification of how many new product boxes for this product are being received

Partial Receipts On occasions it is possible that MSL vehicles cannot carry the full dispatched qty. In these instances the shipment note states 6 carton to follow (for example), the system will need to be capable of allow secondary shipments against partial receipts for the same shipment no. Possibly, by using user case 2 or 3 above.

For all receipt type transactions it will be necessary for audit purposes to enter a goods receipt note no. Such no. will correspond to the manual reports that are required by Govt Audit and Legal authorities at all levels of health care facilities

See Appendix 1

Care Provider/Patient Issues: specification that a certain quantity of a specific product is being issued to a care provider in the dispensary (Stock room) or to a patient (in the case of local pharmacies interacting directly with patients) at a given time, and should be subtracted from the existing available stock. After specifying the transaction type, the user specifies the product being issued using the product type input process described above (see product type input), then the quantity expressed as a multiple of the unit of measure associated with the Product box defined at the beginning of this document. In order to avoid any confusion and overlap with the patient-level system known as smartcare, please note that the system described in the present document will not allow issues of drugs at the tablet level. Note: it would be useful for the client application to require a confirmation of the issue quantity submitted after it is first entered, at least when that quantity exceeds some threshold set up to identify potentially abnormal issue patterns (e.g. more than one product box at a time, several boxes in the same day), in which case a specific alert message could be displayed to prompt the confirmation. Within the constraint that issues for this system may only be recorded as a multiple of the basic unit of measure for the product type considered (typically a box), it is more generally desirable for all patient/care provider issues out of the pharmacy to be performed as continuously (i.e. small frequent quantities rather than infrequent large quantities) as possible, for the following reasons: (i) local inventory outside of the pharmacy is less likely to be stored according to proper temperature, humidity and security conditions; (ii) local inventory outside of the pharmacy is not visible to the system and must be estimated with some error when computing replenishment quantities and patient drug availability performance (this estimation error may increase with the amount of inventory outside of the pharmacy); and (iii) large quantities of the same drug issued at a single time may bias the estimation of demand seasonality performed for forecasting purposes,

For all issue type transactions it will be necessary for audit purposes to enter a goods Issued voucher no. Such no. will correspond to the manual reports that are required by Govt Audit and Legal authorities at all levels of health care facilities

6 | P a g e

See Appendix 2

Transfers/Issues to Other Facilities: transaction identical to the previous one, except that (i) the products being moved out of the local pharmacy are not meant for patients in the catchment area of the facility and (ii) a systematic quantity confirmation input should be used. Note: this transaction decreases the available stock recorded for that facility, just like the previous one (Care Provider/Patient Issues) does. The critical difference (and requirement to distinguish them) however is that transfers/issues to other facilities do not affect the local demand calculation performed by the forecasting system, but care provider/patient issues do. For this reason, the case of an issue to a community worker using the drugs to provide care to patients in the catchment area of the health centre/clinic should be recorded as a care provider/patient issue and not a transfer/issue to other facilities, because otherwise the system will ignore the needs of the local patients being served by this community worker when computing replenishment quantities. At the same time, it is desirable that such issues to community workers be performed as continuously as possible, i.e., frequent issues of small quantities as frequently as possible instead of large infrequent quantities, for the reasons discussed in the note on the previous transaction Care Provider/Patient Issue-

Physical Stock Count: Specification that a given total quantity of a specific product type is currently available for distribution at the pharmacy. The client application could be leveraged to issue stock count reminders/status notification in order to promote adherence to specified stock auditing process guidelines. Note: the discrepancy between the quantities entered as part of a physical stock count transaction and the system stock on record immediately before that point can form the basis of a performance metric quantifying inventory records accuracy in a facility of district.

Adjustment: Specification that a given quantity of a specific product is no longer available for distribution to patients of the facility because of one of the following reasons (which must also be specified through an ergonomic interface): Expired; Damaged; Returned to District / MSL. Note: this transaction can form the basis of performance metrics quantifying the amount of drug expiry and waste relative to total stock or demand at the facility or district level. It is envisaged that such adjustments will be made against a pre agreed list of adjustment codes.

i. Adjustment reasons codes will be maintained centrally and the system will need to allow for modification and or creation of new codes.

Expired stocks - When stocks expire current procedures require that the facility retains such stocks physically until such time as the local audit authority (Board of Survey) reviews the stocks and agrees to there disposal. Therefore allowance will need to be made to allow facilities to make stock adjustments for Expired stocks / Damaged Stocks, such stock will then remain on site and visible in the system but

7 | P a g e

will not form part of the current stocks available for Forecasting or Shipment Optimisation. Consideration is required as to how to handle this, possibly as a different stock type.

For all process on the hand held device it is assumed that all long-running processes will be executed to completion without interruption to invoke other functions on the tracking application. Where there may be a requirement for larger facilities for perform more that one procedure at the same time (say: stock take and issues). Such a facility will be allocated 2 or more devices.

1.3 Emergency / Ad-hoc and Supplemental Replenishment Requests

Specification of an emergency or supplemental replenishment request for a given quantity of a specific drug, along with the required input of a written text message explaining why this request should be considered. For certain drugs which will not be distributed with the new shipment optimisation method, an additional order communication feature separately identified as Supplemental Order will be available this potential input is effectively identical otherwise to the emergency replenishment request feature available for all drugs. The interface for this feature should rely on the product type input process described above as well as a confirmation step before final submission. The submission of this request can be performed at any time by the facility. Note: it would be particularly useful for the application to display the current stock quantity on record for the facility as well as any incoming pipeline quantity on its way to the facility as part of the replenishment request submission process.

All Supplemental orders will be submitted to the DHO for approval before being sent to the eZICS system. No product that is controlled by shipment optimisation shall be allowed to be placed on a supplemental order. The correct process dealing with such products will be to amend the forecast to reflect higher than expected demand as discussed below. Whilst those items that are not subject to optimisation will simply pass through the optimisation suite, subject to the normal validation methodologies. Visibility of all supplemental orders will be required on the device, before and after amendment by the district.

1.4 Stock Take Process

Stock count process. The system will need to control adequate stock take processes to facilitate monthly (TBC via policy decision) stock count at each facility. All stock counts will need to be able to reported and monitored at both District and Central level.

1.5 Forecast approval process

During the forecasting stage of eZICS, eZICS will prepare a forecast for the defined forecast period, by week (currently envisaged to be 18 months) for each facility in the programme, This forecast will then be presented back to the facility / DHO for approval. It is envisaged that to ensure the forecast is simply and easily understood at these levels that the forecast presented will be defined as follows:

o The forecast will show the volume of goods that are expected to be demanded for each product for the forthcoming calendar month / 4 weeks (to be defined). The facility will then have the ability to amend the data to suit any local variations or adjustments. For the four weeks following the next shipment date.

1.6 Messages8 | P a g e

The eZICS system will allow multiple communication channels between the health care facilities, District level and Central level, such reports will include but not be limited to the following examples. Copies of all messages will be available centrally.

Produce Advice note to facilities of replenishment based upon demand. This is your suggested forecast based upon your demand / usage

Forecast approval to District / hospital.

o Message: A Forecast approval has been sent for facility XXX , please review and advise within 48 hours

An order for facility XXX has been dispatched from MSL, see your receipts menu / incoming receipts for details

o Destination: To facility

Shipments received at DHO

o Dear Facility, your order no XXX for this months has been received at DHO, please arrange for delivery.

Stock count process

o You do not appear to have performed a stock take for over 45 days, please do so.

You have any issues data for more than 15 days; please call MSL / DHO to discuss.

The following orders was received at DHO more than 15 days ago and does appear to have receipted at the facility. Please discuss with the DHO / MSL

You have outstanding transfers from another facility, please review and advise

1.7 Report Consultation

Visualization of the history of submitted inventory transactions related to a specific drug over a specified timeline (electronic stock control card consultation).

Visualization of the contents of an order on its way to the facility as well as its status (dispatched at MSL, in transit between MSL and district, received at district. This order contents and status information should be pushed to the local client application and trigger two visible notifications/alerts: (i) when an order for a facility has been dispatched by MSL (i.e. when the tentative order contents is generated); and (ii) when the order has been received at the district, to inform facility staff that it is now ready to be collected if desired/necessary.

All reports should be viewable on any device and printable where the capability exists

9 | P a g e

Ad hoc reporting will need to able to be performed by adequately trained MSL staff using the recognised IBM report writing tool.

The following reports are envisaged to support the different levels of the health sector, all of which will be available on a push / pull basis and via WEB access and will be automatically published when appropriate.

All reports will have drill down capability where necessary.

MSL / IBM will be the author of all reports. It will not be necessary for distributed report writing.

Report Type Push / Pull

Frequency Facility / Pharmacy Store

District / Large Hospital

Province MoH MSL

Advice Notice / Forecast report

Push Per forecast

X

Forecast Authorisation

Push Per Forecast

X

Forecast Variation report (summary of changes made at DHO level to forecast)

Push Per Forecast

X

Order due to Facility (post SO)

Push Per Order X X

Orders shipped from MSL not received at Facility / District

Push Weekly X X

Outstanding transfers / returns report

Push Weekly X X

Exception reports detailing large discrepancies / omissions in data collection

Push Daily X

Stock levels by Summary Facility country / province , district / facility with drill down capability with reference to population / value etc

Push / Pull

Push Monthly

X X X X

Stock levels by category (HIV / RH / Surgical etc) of product by Country / Province/ District / Facility with drill down to facility with reference to population/ value etc

Push / Pull

Push - Monthly

X X X

10 | P a g e

Item transaction report (Electronic Stock card (Time based)

Pull X X X X X

Outstanding stock takes

Push Monthly X X X

Connectivity issues report Encompasses no receipts / no issues / no connectivity. Last date connected

Push Weekly X X

OOS reports (To be defined) Facility Level / district Level

Push / Pull

X X X

OOS report Central Level

Push Monthly X X X

Pipeline analysis report. MSL stock cover future orders due

Push / Pull

X X

Reports required to satisfy M&E see separate M&E document JG to defineConsumption reports comparative reporting by province /district etc/ product category / population / disease pattern / Value

Push / Pull

X X X X X X

Stock Count / Adjustment reporting exception based reports highlighting large adjustments

Push X x

Stock status report Expired stock report (BoS) etc

Pull X X X X

1.6 Information Transmission

This set of interface features relates to the transmission of information from the local device to the central system.

A first component is a visible status display feature informing the facility user of the existence of some transactions that have been entered on the device but have not been transmitted to the rest of the system

11 | P a g e

yet because of cellular network access issues. This information is important because it signals to the user that some specific actions (see below) may be required for that information to be transmitted (and the central system to determine proper forecast / replenishment quantities).

In the event that a device cannot connect to the cellular network, the member of staff responsible for the device will seek to move the device to an area where connectivity exists and process the outstanding information on a timely basis.

In the event that the above action is not possible, it is envisaged that when the local district health management team visit, they will remove the device to an area that will allow transmission and replace the device with an alternative device registered to that facility.

The final component addresses the process to be followed at the facility when the local hardware device is broken / unusable. In those cases the standard stock control cards should be used in order to record key inventory transactions on paper until the repair or replacement of the hardware, at which point the transactions recorded on paper should be entered on the device or more likely a notebook computer managed by the District Support function. Note: the specification of a date different than the current one may be required for those transactions entered a posteriori, contrary to all the other inventory transaction recording cases mentioned so far for which the current device system clock can be used as a transaction time stamp.

Permanently Disconnected sites

In the event that a facility is permanently disconnected with a low chance of the device finding connectivity within one month one of two scenarios will follow.

The facility manager should attempt to relocate the device to an area with connectivity to allow the data to be downloaded.

In the event that this is not possible, the District will be responsible for collecting the device and downloading the data at DHO level.

To cater for areas where connectivity is intermittent, poor, or non-existent, there will be a physical business process whereby all facilities must ensure their devices are connected and synched with the central server at least once per month, ideally in the days preceding the next due Shipment Optimisation run, to ensure Optimisation has the latest current stock levels. However the system must be designed to cater for occasions whereby a facility has failed to make connectivity in the weeks preceding the Optimisation run. Therefore, in the event that a facility has failed to make connectivity between its device and the central server during the preceding weeks (suggested as any time > 1 week) when Shipment Optimisation is run, Shipment Optimisation should estimate current stock at that facility by taking the last known stock level at that facility (which is whenever the device last connected and synched) and depleting it by the forecast demand usage over that same period using the last known forecast run at the time of the last connection. This estimated current stock level will then be used by Shipment Optimisation for calculating the stock replenishment for that run.12 | P a g e

Example: Facility X last connected its device on 1 Aug, and the current stock level of drug Y was 100. The demand forecast for drug Y at facility X based on the demand forecast run at the date closest to 1 Aug showed a weekly demand forecast of 15,15,20,20 for consecutive weeks from 1 Aug. If shipment optimisation is run on 28 Aug and there has been no further device connectivity, it will take the last known stock (i.e. 100 @ 1st Aug) and estimate the current stock level on 28 Aug based on the demand forecast over the period to the current date i.e. 100 15 15 20 20 = 30. It will then run shipment optimisation based on this figure and the latest demand forecast run going forward. Nb. This simple example is based on clean dates/full weeks for ease of illustration, but in practical terms it should be able to calculate based on any dates, part weeks, etc.

2. District Staff

2.1 Hardware

The hardware at the district should include the mobile device defined under 1.1 and used to record all inventory transactions at the district level. In addition, a laptop or desktop computer with internet access could be useful for some features requiring better visualization capabilities (see description of reporting features in 2.3 below).

2.2 Inventory Transactions Recording and Emergency Replenishment Requests

The client interface used at the district level should support the submission of all the inventory transactions and emergency/ad-hoc replenishment requests already described in 1.2 and 1.3, with the following additions/modifications:

When the number of received boxes matches that entered at MSL, the full MSL order receipt transaction can be used (see Case 1 - Full order receipt attempt under Receipt transaction in 1.2). When the number of boxes do not match or the order seems otherwise compromised (e.g. open or damaged shipment box), the line by line order receipt confirmation method can be used (see 1.2)

The interface for the transaction Transfers/Issues to Other Facilities should include the possibility of issuing an entire order based on the order number or bar code, using an entry process similar to that described under Case 1 or Case 2 of the Receipt transaction in 1.2 (but with language obviously adapted to the case of an issue as opposed to a receipt).

The same transaction Transfers/Issues to Other Facilities should also include the possibility of specifying when appropriate that some inventory being transferred out is taken from an MSL order received at the district that couldnt be transferred out in a single time or whose integrity was otherwise compromised. It should also provide the possibility of issuing everything remaining in an order (as opposed to a drug-by-drug specification of what that is), which the system can track because of the modification just discussed.

13 | P a g e

2.3 Report Consultation

The district users and provincial supervisors should be able to view on screen, print, download as a file (.CSV and PDF) the following information.

Electronic stock control card: History of submitted inventory transactions related to a specific drug over a specified timeline, for any specified facility in the district (including the district pharmacy itself).

District stock status: Table showing for any specific product and for every facility in the district (rows) the following information (columns): (i) pipeline inventory quantities (at MSL or between MSL and the district, at the district, from the district and the facility); (ii) on-hand inventory at the facility; and (iii) demand forecasts for the next four months. Useful related options would be to alternatively show all the inventory quantities in this table expressed as days of cover (using the demand forecast for the next month as the basis for computation) and monetary value (using the price or cost for that product).

Facility reporting status: Table showing, for every facility in the district, the number of days since the last inventory transaction at that facility was transmitted to the system, either for a specified product or for all the products.

Logistic performance report: Table showing, for every facility in the district (rows) and for a specified historical timeline, the following information (columns): (i) the average, minimum and maximum lead-time in days between the receipt of an MSL order at the district and the receipt of the same order at the facility; (ii) the average number of physical stock count transactions per product and per month over the period (iii) the average absolute value of discrepancies between system stock and physical stock identified upon physical stock count transactions, expressed as a percentage of demand over the period (see transaction Physical Stock Count in 1.2); (iv) the percentage of drug expiry/waste relative to demand over the period; and (v) the percentage of demand that could not be satisfied because of stock-outs, relative to total demand over the period. Note that the district user should ideally be able to display information (ii)-(v) either for all the products or for a specific one.

Ad hoc reports as may be required.

2.4 System/User Administration

The district users should have the ability to create, delete or modify the accounts of users at all the facilities in their district, so they can manage the facility set-up, phone replacement and other similar resource and user management-related processes at the district level. MSL management will have the ability to view the user resource information thus managed by the districts (see 4.2).

2.5 Information Transmission

14 | P a g e

The interface feature related to information transmission are identical to those described in 1.5 because of better network coverage the district users are of course expected to primarily help other facilities transmit their information by inserting their memory cards (and establishing phone-to-phone connections), as opposed to being helped with that task themselves. District users should manage the flow of memory cards, for example by using a one-for-one replacement policy consisting of attaching a memory card to a box being shipped to that facility in order to replace any cards previously sent by that facility to the district.

3. MSL Staff

The only system interaction discussed for the MSL staff is the printing, taping and scanning of bar code labels on every shipment box included in an order, triggering the creation of that order in the system and its association with the inventory contents listed in the invoice.

4. MSL Management

4.1 Hardware

High-performance laptop or desktop computer with a large monitor and a good internet connection. Note: while this document focuses on interface as opposed to infrastructure issues, it should be noted that the need and potential gaps associated with appropriate internet connectivity for MSL, the districts and the hospitals, cell phone network connectivity for districts and facility and appropriate hardware should not be underestimated.

4.2 Resource Management

The task of creating, editing and deleting all resources and related information (i.e., facilities, products including cost/price and barcodes, districts, schedule of primary district delivery routes) will be performed with MACS, except for the administration of users and devices associated with the new system. An important component of the resource information management by MSL is the specification of the set of products available to be managed through this system for each facility (e.g. Level 4 facilities may have access to a different set of products than level 3 facilities and hospitals, etc.). In other words, this feature provides MSL the ability to control/manage which subset of the product catalogue each facility can be stocked from. Also, MSL will have the ability to access and review the information related to users and devices created by the districts (see 2.4) as part of an interface specific to the new system.

4.3 Amendment of delivery / supply/ forecast / issues data

The system will need to allow MSL staff to amend all data related to the delivery / forecasting / SO cycle. For example should a vehicle be stolen, incorrect issues data supplied by facilities a device is destroyed and data lost. , etc.

4.4 Demand and Lead-Time Forecasting

Visualization of historical weekly demand for each product at each facility and historical order delivery lead-times between the districts and the facilities.

15 | P a g e

Visualization and modification of demand forecasts for each product at each facility and forecast of delivery lead-time to each facility (see also Forecast report in 4.6). The time horizon for demand forecasting should be 18 months, in order to enable procurement planning.

Ability to create a demand forecast a new product and/or a new facility based on historical demand information for similar products and/or appropriate existing facilities (because of geographic proximity or other similar features).

Ability to end a forecast for a discontinued product.

Ability to create a lead-time forecast for a new facility based on historical lead-time information for similar facilities (because of geographic proximity or other similar features).

4.5 Shipment Optimization

Visualization and modification of shipment optimization input data for every product Note: this partly overlaps with the visualization and modification of demand and lead-time forecasts described in 4.3 above, but also includes warehouse, facility and pipeline stock.

Management of shipment optimization parameters (e.g. termination criterion, holding cost parameter, lead-time parameter, demand variability parameter, execution schedule / script).

Visualization and manual modification of shipment optimisation output (shipment decision variables) for every product.

4.6 Report Consultation

The reporting format requirements for MSL Management include all the ones already specified for the districts in 2.3, except that their geographic scope should be extended to all the districts and facilities instead of being restricted to the facilities in a given district.

The only additional reporting requirement is associated with the visualization of detailed demand forecasts for a specific product in every facility, along with some aggregation at the district and national level. The horizon for demand forecasting should be 18 months, in order to enable procurement planning at central level. Note: this feature partly overlaps with 4.3, but it could be good to separate because that report would also be useful to Ministry of Health users (see 5), who probably should not get the ability to modify demand forecasts at the product and facility level as is described in 4.3.16 | P a g e

In terms of output format for the information contained in the reports discussed above, we discussed the high potential benefits associated with representing some of that information using graphs and maps, if possible. The use of graphs in particular is highly desirable.

5. Ministry of Health

Appropriate hardware would be a personal computer (laptop or desktop) with an internet connection.

The key system interaction for Ministry of Health users is to allow access to reporting features. The specific reports envisioned would be the same as defined for MSL Management in 4.6, except that Ministry of Health users at the provincial level would only access the information associated with the districts from their own province.

Appendix 1:

Goods receipt Note used by Facilities

17 | P a g e

Appendix 2: Issues Report used by facilities

18 | P a g e

Section 2: Device Menus Facility Level and District / Central

This section covers the device structures envisaged by the MSL. The reason these were developed was to assist in clarity of the processes and procedures involved.

The key issue that arises on the structure of the device menus is that simplicity and clarity and the key requirements.

Section 2.1 deals with the devices used at the health-care delivery point. Which may be a pharmacy at larger institution, or a simple store cupboard at the lower levels of the health service, Rural Health Centres and Rural Health Posts? It is preferable that one menu system can be developed to fit all levels of the care structure.

Section 2.2 deals with the types of transactions anticipated at the District Health Office (DHO) level. At this level, management control, audit issues and the transfer of stock (cross docking is dealt with). As discussed in the user case section. The DHO will not take direct responsibility for the item by item levels of stock. They will take responsibility for the cartons they temporarily store whilst awaiting onward shipment to the actual health-care delivery point.

2.1 Facility Level

Device Menus at Health Care Facility

2.1.1 Main Menu

19 | P a g e

2.1.2 Receipts Menu

2.1.3 Issues Menu

20 | P a g e

2.1.4 Stock Management

2.1.5 Stock Count Menu

21 | P a g e

2.1.6 Messages Menu

2.1.7 Reports Menu

22 | P a g e

2.1.8 Supplemental Orders Menu

Emergency orders will not be dealt within eZICS. Such orders will be dealt with manually and the order placed will be entered into MACS and the subsequent issue will be captured by eZICS.

Appendix A

Shortage ReportCode Desc Sent from MSL Received

MSL001 Malaria 10 10Amend no to state actual qty received

MSL001 Malaria 10 10MSL001 Malaria 10 10MSL001 Malaria 10 7MSL001 Malaria 10 10MSL001 Malaria 10 10

Appendix B

Stock Recount ProcessCode Desc Qty Expected Qty Counted Diff recount Qty

MSL001 Malaria 10 8 -2 MSL001 Malaria 10 7 -3 MSL001 Malaria 10 6 -4 MSL001 Malaria 10 5 -5 MSL001 Malaria 10 4 -6 MSL001 Malaria 10 3 -7

23 | P a g e

2.2 District Menus / MoH

Districts are required to perform a number of roles in ensuring that all orders are accurately submitted with the appropriate authorisations. The further manage the delivery of stocks between District Health Offices (DHO) and the service delivery point. We further anticipate that they will rake a key role in auditing the accuracy of the data submitted and managing the stock count process required to validate the data. Finally, they will be required to perform some device / user management functions. The following device menus describe these roles.

2.2.1 Main Menu

2.2.2 Forecast / Order Review and Approvals

24 | P a g e

2.2.3 Shipment receipts at district

2.2.4 Stock Count Management

2.2.5 Messages

25 | P a g e

2.2.6 Reports Menu

2.2.7 User Device Management

26 | P a g e

Section 3 Operation flow Charts of procedures

3.1 Demand / Order Process / Approval and Interface Issues

The following flow charts describe the overall process from a central (MSL) system and process perspective. 3.1.2 demonstrates the various authorisation / approval process required

3.1.1 This flow chart describes the overall process from a central (MSL) system and process perspective.

27 | P a g e

Demand/Order Interface

MACSMACSOptimisation ModuleOptimisation

ModuleForecasting

ModuleForecasting

ModuleDevice SoftwareDevice Software

Shipment Dates for routes

maintained in eZICS (Scenario

Manager)

Forecast Advice Note for facility and demand driven order produced 10 working days

before shipment date

Stock allocation (input from eZics

immediately allocate stock in MACS Order

allocation level

Stock reserved for eZICS program

(defined calculation in eZics.Scenario

manager)

Forecast run for facilities in delivery

cycle (once weekly ?)10 days before

shipment

Optimization process (based on

available and pipeline stock)

Pipeline data with expected arrival (Orders due in) and QC stock

Status 3)

Forecast Approved submission from

District

Forecast diverted for approval at MSL if any line

amended by more than 10%

Linked Items (Pack Sizes)

Unallocated Available stock in MACS (Status 1)

by expire date

eZics applies certain rules

related to availability of this

stock

Linked Items are converted to single units (ie tabs/ vials

etc)

For linked items eZics converts back to MACS SKU based on

FEFOPick slip release

and normal MACS processes

Shipment labels and barcodes created at

point of dispatch

3.1.2 Simple view of Approval / Authorisation points and procedures

28 | P a g e

Simple/High level overview of approval process of Demand Forecast driven ordersE

stab

lish

orde

rap

prov

alP

roce

ss o

rder

MACSeZICS Shipment

Optimistion Module

District user via eZICS Client

eZICS Demand Forecast Module

Facility user via eZICS Mobile

Client

Submit demand usage

Forecast DemandOutput (of items flagged for SO

method)

Produce Demand Driven Forecast

request based on history etc

Approve Forecast District/Hospital Pharm in Charge

Demand driven order

Process amended Forecast and

optimise shipment schedule based on live inventory

data

Nil response in 48 hrs= deemed Forecast accepted

Stock issue requrest

Allocate stock & produce Order and pick lists

Process complete. Stock despatched from

MSL

Yes

Live inventory data of stock

available to eZICS

No

Reject or amend ?

Submit amendments

Amend

AmendedForecast

Forecast terminated. Process complete (non operational/ closed in rainy

season)

reject

Produce Forecast Advice note to

facility user / Hosp Store/ Health

CentreFinal Decision for MOH

where this approval should happen

The eZICS MACS integration to be described in more

detail on a separate diagram, please refer to same here

3.2 Processes required at Health Care Delivery point

29 | P a g e

The following flowcharts describe the processes and procedures required at the health care delivery point for each of the functional requirements.

3.2.1 Stock Receipts

3.2.1.1 Standard Stock Receipt from MSL

Page 1

Stock Receipt (Health Facility)eZICS PDA SRF Version 1.0 5th Aug 2011

START Stock Arrives at Health Facility

Identify Boxes that Represents one Invoice/

shipment by sorting boxes 1of x etc, from

the carton labels

All Boxes received for the

Shipment

Choose Receipts on the PDA and then select Full

Receipt

Enter Goods Received Voucher Number and enter, All Stock has been received . Pack stock away on shelves

Yes

No

Open All boxes for the shipment, unpack

stock and check individual items

Scan any box label or the shipment number

barcode on the invoice, (if the scanner not

working, enter number on device) Check

number on screen and enter

Yes

Find dispatch Note/ MSL

Invoice

Check items against document and note any discrepancies

Record Shipment or Invoice number from Box Label. List Items and quantities and

file receipt list .

No

Yes

Choose Receipts on the PDA menu and

select Individual Item Receipt

Find correct item code or barcode from

drop down list or catalogue and scan or enter code again

Scan any carton label to pick up the dispatch /

Invoice number, or enter the number from the

documentation and enter

Scan the Stock Item label from the bin or scan the product bar

code, or enter the product code from the

Invoice and enter

Check PDA screen for correct

item and pack size

No

Enter quantity received and enter

(1)

Yes

Stock received and packed on shelve, Shipment status changed

to received at facility

1: System to warn user if item has already been

received in full or in excess for

shipment number combination or if

item not on shipment

2: Discrepancy reporting.? MSL

or select lookup and start typing the product

description and select the product & pack size

PDA received receipt data

No

PDA received receipt data

No

The Receipt detail will automatically be

displayed on the device (spreadsheet

format)

YesThe device will

return a message that the receipt

data has not been received

Enter the Goods Received Voucher number and enter

3.2.1.2 Stock received Not from MSL

30 | P a g e

Page 5

Stock Receipt (Health Facility) Not received from MSLeZICS PDA SRF Version 1.0 5th Aug 2011

START Stock Arrives at Health Facility

Find Invoice from supplier

Check items against document and note any discrepancies

Record Invoice number from Box

Label if available . List Items and quantities and file receipt list.

No

Yes

Choose Receipts on the PDA menu and

select non MSL receipts

Find correct item code or barcode from

drop down list or catalogue and scan or enter code again

(1)

Enter the invoice number or internal reference and the Supplier Name (open

text field) from the documentation and enter

Scan the Stock Item label from the bin or scan the product bar

code

Check PDA screen for correct

item and pack size

No

Enter quantity received and enter

Yes

Stock received and packed on shelve, Shipment status changed

to received at facility

1: If item not on database confirm

with MSL or district if this item needs

to be added/ controlled. Open a stock card in any case and continue

using the item pending a descision

or select lookup and start typing the product

description and select the product & pack size

3.2.1.3 Stock received Transfers from Other Institutions

31 | P a g e

STARTTransferred Stock Arrives at Health

Facility

The transferring facility needs to complete a

transfer note with transfer number and

number of boxes

Open All boxes for the shipment, unpack

stock and check individual items

Find Transfer Note Number

Check items against document and note any discrepancies

Choose Receipts on PDA, Show incoming

receipts and then choose Outstanding

transfers.

No

Yes

Choose Receipts on the PDA menu and

select Individual Item Receipt

Find correct item code or barcode from catalogue and scan or enter code again Enter the transfer

number on the PDA and enter(2)

Scan the Stock Item label from the bin or scan the product bar

code, or enter the product code from the

Invoice and enter

or

Check PDA screen for correct

item and pack size

No

Enter quantity received and enter

(1)

Yes

Stock received and packed on shelve , Transfer Status Received at Facility

1: System to warn user if item has already been

received in full or in excess for

shipment number combination or if

item not on shipment

2: If the system didnt generate a Transfer number, the stock will be

received via stock adjustment (When all facilities are not yet on this system )

Page 2

Receipt of TransferseZICS PDA TR Version 1.0 5th Aug 2011

List Items and quantities and file

receipt list.

or select lookup and start typing the product description and select

the product & pack size

PDA received receipt data

The Receipt detail will automatically be

displayed on the device (spreadsheet

format)

The device will return a message that the receipt

data has not been received

No

Yes

3.2.1.5 Advanced view of stock to be received from MSL

32 | P a g e

Page 4

Incoming ReceiptseZICS PDA IR Version 1.0 5th Aug 2011

START User wants to view incoming stock

Select: Product or Shipment number or shipment status

Select Receipts on PDA and then show incoming

Reciepts

The system will return for product selected: quantities in every status

and totalFor shipment number all items, pack,

qty and status and for shipment status: All items, pack and qty.

Information shown on screen and printable if

devise is able to connect to a printer.

33 | P a g e

3.2.2 Issuing Stock

Page 1

Stock Issues (Health Facility)eZICS PDA SI Version 1.0 5th Aug 2011

START

Facility determines need to replace a stock item in the

dispensary or ward(Internal Requisition note from Ward/ Dispensary)

On the PDA, select Issues

Bin or Product Barcode

Select Yes and Scan Barcode and check product description and pack size on

screen

Stock immediately moved to Dispensary or

Ward dispatch

YesNo

Select No or lookup and start typing the product description and select the product & pack

size or scroll down the full list to select the item

Enter quantity issued and enter to confirm

Correct description and

pack

Yes

No

Select the Ward or Destination and enter requisition

number

34 | P a g e

3.2.3 Stock Management

3.2.3.1 Adjustments

Page 1

Stock Management - AdjustmentseZICS PDA SMA Version 1.0 Aug 5th 2011

START

Facility determines need to adjust stock

item due to for example Damages, Expired Stock etc

On the PDA, select Stock Management and then select Adjustments

Bin or Product Barcode

Scan Barcode and check product

description and pack size on screen

Stock is adjusted by system with the quantity

(subtracted or added with the indicated quantity)

YesNo

Select Lookup and start typing the product description and

select the product & pack size or scroll down the full list to

select the item

Enter quantity to be adjusted with + or

for pos/neg adjustment and enter

to confirm

1: Adjustment Codes (table to be maintained at

Central DB)- Damaged-Expired

-Receipt Error-Issue Error

-Procured own funds-Donation

2: Damage and Expired stock status needs to

reflect as such but needs to be listed for inspection by Board of Survey. See

Write-Off

Correct description and

pack

Yes

No

Select the reason code for the adjustment (1)

35 | P a g e

3.2.3.2 Returns / Transfers

Page 1

Stock Management Returns / TransferseZICS PDA SMRT Version 1.0 Aug 5th 2011

START

Facility determines need to return stock item to MSL or to Transfer the item to another facility. (Note approval needed by MSL for returns and District for Transfers)

On the PDA, select Stock Management and

then select Returns/ Transfers

Bin or Product Barcode

Scan Barcode and check product

description and pack size on screen

Stock is adjusted by system for this facility with the quantity (subtracted)

and a transfer transaction with unique number (receipt) is created for the

receiving facility

YesNo

Select lookup and start typing the product description and

select the product & pack size or scroll down the full list to

select the item

Enter quantity to be transferred or

returned and enter to confirm

Report on open transfer

transactions needed (central

and district)

Correct description and

pack

Yes

No

Select the District name in which the facility resides . Then select the name of

the facility for the Transfer and enter. (Drop down

Boxes) If MSL is selected it represents a return

Enter the Goods Issued Voucher

number

3.2.3.3 Stock Write Offs (Board of Survey)36 | P a g e

Page 3

Stock Management Write OffeZICS PDA SMWO Version 1.0 110620

START

Facility need to write off stock items that is physically still at the facility (quarantined) but unusable once approval has been obtained by Board of

Survey / District for example Damages, Expired Stock

On the PDA, select Stock Management and then select Stock Write

off

The user will enter quantities on the screen against the items that

were physically inspected and approved for write off by the BOS

Signed BOS document to be filed for record

The system will change the status

of the stock to written off

A report can be printed by the system at facility or District level of items written off per date/ date

range

How do we manage old Damage/ Exp stock

statuses for which stock cannot be found. (We could still write them off,

but there will be no certificates.do we need

to indicate that on the system?

The system provides a screen with all stock

items, by description, pack size and quantity on

expired and damaged status at the facility

3.2.4 Stock count processes and procedures

37 | P a g e

3.2.4.1 Full Stock count process

Page 1

Stock Count All Items (Health Facility)eZICS PDA STF Version 1.0 110622

START

Facility prepares for stock take: Received items on shelves, Issued items removed from shelves,

stock on shelves what is deemed to be in system

On the PDA, select Stock Count and then Full Count (By default the system will not allow any transactions

until the stock take has been completed)

The system will only proceed if all items

listed are flagged and will return a message for the user to finalise the unflagged items

The system will rewrite the stock on hand and record the discrepancy transactions on the

electronic stock card as Stock Count Discrepancy +/-.

Other transactions may continue after this step

Once all items have been counted the user will

select First Count Complete on the PDA

Once all items are counted and flagged the system will proceed on

the selection of First Count Complete

1: The count is completed at this stage by the system for matching

items2: No items may be added as part

of the recount procedure3: Stock take to be conducted

monthly. Last stock take date to be visible to districts , MSL, MOH.

4: Reporting should include matched items (listing no/0

discrepancies- Audit reporting/ stock take or date period)

?Stock counts and connectivity : Will it be possible to do it offline ? Yes in our opinion as latest stock

info should be on device

The system lists all items with pack size and status (ie Expired/Damaged already

adjusted) on screen for which any stock exists but returns a

0 value (blind count)

Starting at one end of the facility the user starts the count by counting the item

physically

The user can either scan the item and enter the quantity in which case the

displayed list is updated with the count quantity for the item and a

count flag is shown against the item OR

The user seek by scrolling or typing the item name alph to locate it on the list and then enter the count quantity in which case a flag is returned next

to the item

The user continues counting all items in the

facility

Once the user is satisfied that all items have been counted physically the

screen can be checked for all unflagged items to

determine if they may be missed in the count. Any

missed items can be checked and counted.

If the user finds no stock for an un-flagged item, a zero is entered

and the item will be flagged

If the user attempts to count / scan the same item twice on the PDA, the PDA will display a warning. This mechanism may warn the user that the stock may have been counted already or it is situated in more than one area. Once investigated the user will only enter the correct total

quantity for the item counted

If an item that is not found on the list have been counted it

can be added by selecting add item on the PDA and scanning the barcode or alpha searching

the item and pack size and entering the counted quantity

The system will now compare the physical count against the system information and will

return a list on screen similar to the first count list with additional

columns showing the system quantity, count and discrepancy and a column for the recount (1)

The user will now locate the items on the list in the store room and recount them by

entering the recount and final figure to be accepted. Once again the tag mechanism is

employed. (2)

Once all items are counted and flagged the system will proceed on the selection of Stock

Count Complete

3.2.4.1 Single Item Stock count process

38 | P a g e

Page 2

Stock Count Single Item (Health Facility)eZICS PDA STSI Version 1.0 110622

START

Facility prepares for stock take: Receipts of item on shelve, Issues of the item

removed from shelve, stock on shelve what is deemed

to be in system

On the PDA, select Stock Count and then Single Item

Count (By default the system will not allow any transactions on the item until the stock take has

been completed)

The system will rewrite the stock on hand and record the discrepancy transaction on the

electronic stock card as Stock Count Discrepancy +/-.

Transactions may continue after this step

The count is now complete

The user scan the item or alpha search

and select the item on screen.

The system displays the item description and

pack size and status/es and a field to enter the

count

The user enters the quantity counted

The system compares the count and returns the system

quantity only if there is a discrepancy. If the system and physical count is the

same the system will display a message that the count was

successfully completed

The system returns the system count, physical count and discrepancy on screen and a field to

enter the recount

The user enters the final count in the field provided

1: No items may be added as part of this count procedure

2: Reporting should include matched items (listing no/0

discrepancies- Audit reporting/ stock take or date period)

?Stock counts and connectivity : Will it be possible to do it offline ? Yes in our opinion as latest stock

info should be on device

3.2.5 Supplemental Order

39 | P a g e

Supplemental Orders

MACSeZICS Shipment

Optimistion Module

eZICS Demand Forecast Module

District user via eZICS Client

Facility user via eZICS Mobile

Client

User Select Order Tab on Menu and

then select Supplemental

Orders

User Scan item/s Bar code or select item from dropdown list

(only items allowed for the facility level may

be selected) and enter requested quantity/s

and reasons

District notified electronically

and approve or amend order

Order/affected lines Cancelled

No

Order Checked against Forecast

or AMC

Yes/amended

List of orders to be approved to be visible at District .

Order Checked against stock

available

Order listed and displayed to MSL

user for amendment/ final approval (listing , Forecast/AMC,

MSL stock position, stock on the way to facility

Process order request for SO

lines and optimise shipment schedule

based on live inventory data

Allocate stock & produce pick lists

with one order number

Live inventory data of stock

available to eZICS

Process complete. Stock despatched from

MSL

Stock issue Request

MSL approve, reject or amend

order

Not ApprovedApproved/amended

Is Item part of SO

Yes

No

Consolidate SO and non SO lines of order in eZics

If order not approved within 2

weeks, it is automatically

cancelled by the system and a new order will need to

be submitted

Pending more than 14 days

Section 4 MSL / MACS issues40 | P a g e

eZICS- Systems issues to consider in relation to the Interfaces required between MACS and IBM

Overview

Consideration needs to be given to the level of interfaces required between the two systems, the relationship between Shipment Optimisation and both MACS and MSL standard procedures and the timeframe of frequency of interaction between the systems This paper sets out to establish these requirements.

Which System controls the core operational Data

As the majority of the key data will be held and maintained in MACS it is considered desirable, where possible, to maintain all the main data in MACS. This data can be summarised as:

Product Data

o Pack size relationships

Location Data

o Routing Data

Disease / Population Data

o Population by District

o Incidence of Malaria / HIV / RH etc per 1000 population by district

Proportion of products available for the eZICS programme

Product Data and Location information will be held and maintained in MACS and interfaced where necessary to IBM.

Population / disease data will be controlled in eZICS. Likewise, as the data required to determine the proportion of products reserved will reside in eZICS it is preferable for the reservation of stock process to also be determined in eZICS.

Not only will we need to address the interfaces themselves. This programme will require a thorough review of all current processes at MSL including order processing, allocation of stock to orders, dispatch and delivery procedures. As this programme will be running in 3 districts of 73 initially, we will further need to determine a method of effectively allocating stocks between those facilities in the programme and those that will operate normal procedures. Such methodology will need to reflect an escalation of the programme over time. This paper also addresses these issues.

Barcodes

We have determined that the best barcode systems to use will be Code 39 for product barcodes and EAN128 for shipment labels, both of these protocols are industry standard for the pharmaceutical industry.

41 | P a g e

Simon P upon review of the products at MSL I see little Code 39 barcodes. What would be your view to establishing EAN 128 as the standard for both products and labels?

Overall Data considerations

In considering what data to transfer between the systems; we should always over spec rather than the reverse. The reason for this is that it is envisaged that the IBM solution will become more than a shipment optimisation programme. It should over time become the country wide forecast and quantification data warehouse as well. Secondly, it is envisaged that most management information / reporting on issues such as Demand, Consumption, Stock levels through the supply chain and Forecasting will be performed in the IBM solution and will be visible to the potential 2,500 users.

As such, where a choice is too made about the level of detail to interface, we should consider the future implications of these issues to ensure that the IBM solution has sufficient information to produce meaningful reports.

Overall process and procedural considerations

MACS is a real time warehouse management system. As such, stocks are being received, moved, allocated and issued on a minute by minute basis during each working day. This poses a number of challenges to MSL current working procedures and the details of systems interfaces. Clearly, the shipment optimisation procedures will need to run at a moment in time when nothing else is occurring in MACS, otherwise the stocks will not reconcile.

This basically leaves us with two options.

We freeze work in MACS whilst the stocks are sent from MACS to IBM, the calculations are performed and the resulting rationing of stock are returned to MACS and allocated, or,

We run nightly processes during out of hours periods to control the process.

Batch and Expiry Date considerations

The ops research currently does not support Batch, Valuation or Expiry date consideration. The rationale for this is that the lower level health facilities in Zambia currently do not manage their stock rotation in this manner. However, as the IBM data warehouse will probably become the lead Management Information / reporting centre for all levels of the health service, it is probably relevant to transfer details of all essential management information to IBM. Such information may not be required by the shipment optimisation programme; however we should transfer essential management information such as Batch, Expiry date and value (ZMK) information for all Issues to facilities. This would allow visibility of such information to all levels of the health supply chain.

Further if eZICS is to calculate how much stock is reserved for the programme (As it will hold the variable data in the scenario manager database, this makes sense), eZICS will be required to output order from eZICS based upon the oldest expiry date for linked items.

42 | P a g e

1. Interfaces required from MACS to IBM

1.1. Basic product Information

1.1.1. To optimise or not?

Whilst the number of products that are included in the shipment optimisation programme itself is perceived to be rather small (possibly 40 60 items at the lowest level of the health service), there will be a further subset of products that such facilities will be allowed to order and are stocked on a consistent basis in their stock rooms (Slow moving or non essential products). It is important that ALL products in such a location are treated in the same manner when it comes to the normal stock control processes: receipts, issues, adjustments and stock take on the hand held device / computer at the location. As such, it is envisaged that ALL products MSL carries will be required to be managed by the IBM solution. This leads to two key issues.

The number of products being managed by the stock control programme may be as high as 800 1000 at a hospital level.

We will need to separate these items into two types on the system, those that are SOd, and those that are not.

o There will be different subsets of products for different facilities.

As such a flag will be required in MACS related to facility level that will describe if a product is to be optimised or not.

1.1.2. Basic product data

MACS holds and controls multiple levels of data for each product that MSL stocks. It is envisaged that the following product based data will be interfaced to IBM

Fields to Interface

Product Code, Desc, Pack size, Product status, product type (Tablet etc), product grouping (Malaria), pack / units relationship (dosage), Barcode, Avg Price, Linking codes for substitute pack size items.

Frequency of Interface

Real time

43 | P a g e

1.2. Basic Facility information

An interface will be required to transfer current relevant facility information, for all facilities / project facilities. Further a flag will need to be maintained in MACS to allow visibility if which facilities are in the Ops research programme

Definition of fields required to be transferred

Facility name (MACS), HMIS code (MOH code), Name, Address line 1 6?? Postcode? facility type (level), District, province, Route, Contact?, Status (opened / closed), OPS Research Flag (New).

Frequency of Interface

Real time

1.3. Outstanding Purchase Orders

It is envisaged that MSL will take greater ownership of the pipeline data (outstanding purchase orders due into MSL). In order to achieve this MSL management has agreed to enhance the Goods In function to control this issue. The Goods In manager will from the commencement of this programme hold monthly meetings with key stake holders to ensure all their outstanding Purchase Orders are held accurately in the PO system in MACS and that the qtys of stock and estimated delivery dates are maintained accurately.

MSL will be required to improve its pipeline / outstanding PO data validity.

Fields to be interfaced.

Product Code, Due Date, Qty on order, programme (are they available for free distribution) Order no?

Frequency of interface

Real time?

1.4. Stock figures available for rationing via the shipment optimisation routines:

1.4.1. Stock Status of goods available for the shipment optimisation programme.

MACS holds a number of different stock statuses (6 in total) including good stock, Stock held in QC, rejected stocks and expired stocks.

After consultation with Jeremie Gallien we have established that the stock statuses to be used in the optimisation process as Good Stock and QC stocks. The QC stocks will be used as part of assessment of future demand (i.e. there is an expectation that they will be released in good stock at some stage).

44 | P a g e

This is quite some assumption as much of MSLs QC stocks are long term QC rejections that are awaiting authority to move to expired or rejected stocks. MSL will need to review this issue and advise accordingly. However, it may be necessary to create a new stock status Long term QC to cover such an eventuality.

In conclusion the stock types that will be considered for interface to shipment optimisation are:

Good Stock

QC Stocks (Short term, if a change is made)

For each type of stock the following data will be interfaced.

Product Code, Expiry date, Batch No, Qty (Unallocated)

1.4.2. Stock Allocation considerations

MACS has some complex routines that allocate stock to orders. At any point in time a proportion of MSLs stocks will be allocated to orders. When this allocation is made MACS considers both the expiry date in allocating stocks and its location in the warehouse (Pick Faces first). Therefore, when the real time stock position is transferred to IBM for consideration in optimising deliveries, we need to ensure that only un-allocated stocks are transferred.

Conclusion

Only transfer unallocated stocks

1.4.3. Rationing of MSLs stocks to the programme

The Ops research for shipment optimisation will initially be trialled in 3 districts. However, the intention is to rollout the programme aggressive once a successful trial has been confirmed.

As such, we need to determine what % of MSLs overall stocks are available to the shipment optimisation programme. This functionality does not exist at present.

The calculation for how to reserve stocks will be held in the Scenario manager database by reference to the following data.

The population of the districts as a % of total country population.

The incidence of known diseases (HIV and Malaria) for the districts as a incidence per 1,000

Such data will then be converted into an overall % per type of product which will need to be transferred to MACS to reserve such qtys of stocks.

This calculation will be finally determined by the outcome of the discussion in the M&E document,

45 | P a g e

1.5. Consumption Data (Issues)

We will need to transfer to the IBM the actual issues performed by MSL for all location, both Ops research locations and other facilities. i.e. confirmed PODs

Definition of files required

Order no / Invoice no / dispatch note no?, facility / location code, Product code, Order qty, dispatched qty, date, shipment dispatch no (Barcode), Due date???, no of Cartons issued - (Not currently supported?), Batch no and Expiry date information

Frequency

Nightly?

1.6. Shipment Calendar

The current MSL shipment calendar is a non rules driven series of dates per route (circa 35 routes which contain circa 120 delivery locations), per month. The dates vary by month. In order to understand the shipment date this calendar will be required to be managed and maintained, this will be controlled in eZICS. MACS will still control the relationship between facility and route as this is required to determine pick slip release etc.

This module will be managed eZICS scenario manager to create relationships between, facilities and routes and the forecast commencement date of each route and the route duration (1 6 days)

Definition of fields required to be interfaced

Facility Code, Route no, delivery date, duration of trip.

2. Interfaces required between IBM to MACS

Once the above data has been transferred to IBM and the shipment optimisation routines have been completed. IBM will need to populate MACS with the required data to all the orders and subsequent picks to be created. The following interfaces are required from IBM to MACS

2.1. The Order details

Once the shipment optimisation has been completed the key output from IBM will be the order to be imported to MACS, these orders will need to be prefixed with an SO indicator to clearly identify all SO orders in MACS. The following fields will be required.

Definition of fields to be transferred

IBM ref no; facility code, product no, qty required. Order date, delivery date required (see shipment calendar), Order status.

46 | P a g e

Frequency

Immediately after the shipment optimisation routines are completed.

Comment for MACS: We will need to create the allocations in MACS at the same time to avoid the stock being stolen by other facilities.

2.2. POD confirmation / shortage reporting

The system as it is currently envisaged will require the receiving facility to confirm delivery on the device and report shortages. As such, we require such details to be interfaced to MACS to enable an automated POD (proof of delivery) process in MACS.

Definition of fields to be transferred

MACS Dispatch note no, product code, received qty, shortage qty.

It may be better to only report variances??

Consideration is required from a procedural point of view here. At present Proof of Delivery is the signed dispatch note returned from the Facility. Are we comfortable to interface this possibly as we will never receive the signed dispatch note as it is signed for at DHO level?

DVW / IR to consider further

2.3. Returns

Subject to how returns are dealt with at the facility end of the programme, we may require the ability to interface such returns to MACS.

A procedure will be required in eZICS to allow amendment / completion of outstanding returns. Separate procedure will be required at MSL to monitor eZICS returns against actual returns. At present we consider this to be a disconnected procedure that will not be reconciled or interfaced.

2.4. eZICS Scenario Database

It is envisaged that eZICS will maintain the entire key scenario data required to enable the calculations. These are seen as follows:

Population and demographic information by District

Incidence of Malaria / HIV etc by district and head of population

The shipment dates to all facilities and the lead times that arise (Journey times)

47 | P a g e

However some of this information may be required in MACS to determine the overall levels of stock to be reserved for the programme. eZICS will perform this calculation and provide the reservation qtys to MACS.

Action: Decision required on where the stock reservation calculations are calculated

Definition of fields that will be required

Morbidity data held by regime (product group)

To be agreed with MOH but currently envisaged that this will include

HIV, Malaria, TB, Reproductive Health (Incidence per 1,000 population

Population held by District

Shipment lead times / closure during rainy season etc.

Such data will be maintained and controlled in Scenario Manager in eZICS. There is no requirement to hold such data in MACS if the stock reservation process occurs in eZICS.

3. Other Considerations MACS / IBM

3.1. Pack size substitution considerations

The majority of MSLs major products have a number of pack sizes (1,000 tablets, 500 tablets, 100, 25 etc). Each of which have expiry date considerations. MACS cater for these well, in that if an order comes in for 1,000 but MSL is out of stock it will automatically convert this order to another pack size and deal with first expiry at the same time). However, When Shipment Optimisation occurs the procedure for substitution requires clarification.

The proposed procedure for dealing with this is as follows:

The forecast / Issues and receipts data for each facility will be converted into the lowest possible unit of measure (Tablets, Vials etc).

o The linking of SKUs is controlled in MACS

The stock figures available for the programme (supplied by MACS) will be converted to the lowest possible unit of measure

The SO process in eZICS will optimise and forecast based upon this lowest Unit of Measure.

The order created in eZICS and sent back to MACS will then be converted back to an SKU based upon the oldest expiry date first.

o Consideration needs to be given as to where this occurs (eZICS)

48 | P a g e

o The precise maths behind this need to be agreed but it is assumed it will follow the process below.

eZICS will convert the no of tablets required into a rounded no of pills that will match the pack sizes available in MACS.

eZICS will the pick any pack sizes smaller than this qty based upon the FEFO rules.

Where no stocks exist in smaller qtys than those required by eZICS, eZICS will round up the requirement as per SO to the next lowest available no of units and request a pick for the SKU.

3.2. Rounding up when eZICS requires less than the minimum pack size available.

eZICS will be required to round up to the lowest possible pack size available above the qty forecast.

3.3. Frequency of Interfaces

The frequency of the interfaces defined above has not been determined at this stage.

3.4. Barcodes on Dispatch notes

The barcode on the dispatch note, invoice and shipment label to be the same.

Q: Should we consider putting individual barcodes on the dispatch note. This may solve the problem of when the comms are not working and the receiving facility has no idea what it is expecting?

3.5. MSL / SOPs

Re write MSL / SOPs to reflect key changes required in particular on Pipeline data (maintenance of Purchase Orders) order processing / stock allocation and shipment labels / complete orders only distributed.

3.6. MACS support in Zambia

It is envisaged that MACs will be required to provide 2 visits to Zambia during the programme.

To set up preliminary requirements in MACS

Barcodes

Shipment Labels

Support visit during implementation to ensure smooth interface operations and verify data accuracy of transferred data

49 | P a g e

4. Further Issues that require consideration in the IBM Shipment Optimisation module

4.1. Ensure that key policy issues are incorporated into the design document, these are:

District Sign-off is required by MoH.

Manual stock cards will need to be maintained as present.

Historical data is required for 5 yrs.

Determine the list of stocks to be optimized and the extended list of supplemental drugs that facilities may order by facility type.

Will provincial staff be named by people / function (Role)?

Are Provinces / Districts allowed to view each others data?

Are monthly stock takes a requirement of the MoH?

4.2. Overall view of the products to be included for shipment optimisation

Whilst the number of products that are included in the shipment optimisation programme itself is perceived to be rather small (possibly 40 60 items at the lowest level) there will be a further subset of products that such facilities will be allowed to order and are stocked on a consistent basis in their stock rooms (Slow moving or non essential products). It is important that ALL products in such a location are treated in the same manner when it comes to the normal stock control processes: receipts, issues, adjustments and stock take. As such, it is envisaged that ALL products MSL carries will be available to the highest level of the health service (Hospitals) and will be required to be managed via the IBM solution, whether this is on a remote device at the lower levels of the health service, or a Computer on the hospital. This leads to two key issues.

The number of products being managed by the stock control programme may be as high as 800 1000 at a hospital level.

We will need to separate these items into two types on the system, those that are optimised, and those that are not.

The IBM solution will be required to manage the basic stock managemen