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

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

Pages

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

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.

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

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

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

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

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

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 Messages
8|Page

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

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 Frequency Facility /

/ Pull
Pharmacy
Store
Advice
Notice
/ Push Per
X
Forecast report
forecast
Forecast
Push Per
Authorisation
Forecast
Forecast
Variation Push Per
report (summary of
Forecast
changes made at DHO
level to forecast)
Order due to Facility Push Per Order
X
(post SO)
Orders shipped from Push Weekly
MSL not received at
Facility / District
Outstanding
Push Weekly
transfers / returns
report
Exception
reports Push Daily
detailing
large
discrepancies
/
omissions in data
collection
Stock
levels
by Push Push

Summary
Facility / Pull Monthly
country / province ,
district / facility with
drill down capability
with reference to
population / value etc
Stock
levels
by Push Push
category (HIV / RH / / Pull Monthly
Surgical
etc)
of
product by Country /
Province/ District /
Facility with drill
down to facility with
reference
to
population/ value etc
10 | P a g e

District / Province MoH

Large
Hospital

MSL

X
X

X
X

X
X

Item
transaction Pull
report
(Electronic
Stock card (Time
based)
Outstanding
stock Push
takes
Connectivity
issues Push
report Encompasses
no receipts / no
issues
/
no
connectivity.
Last
date connected
OOS reports (To be
defined) Facility
Level / district Level
OOS report Central
Level
Pipeline
analysis
report. MSL stock
cover future orders
due
Reports required to
satisfy M&E see
separate
M&E
document JG to
define
Consumption reports

comparative
reporting
by
province /district etc/
product category /
population / disease
pattern / Value
Stock
Count
/
Adjustment reporting
exception based
reports highlighting
large adjustments
Stock status report
Expired stock report
(BoS) etc
1.6

Monthly

Weekly

Push
/ Pull
Push

X
Monthly

Push
/ Pull

Push
/ Pull

Push

Pull

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.

2.4

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 leadtime 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 stockouts, 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.

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 healthcare 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 Report
Code
Desc
MSL001 Malaria
MSL001 Malaria
MSL001 Malaria
MSL001 Malaria
MSL001 Malaria
MSL001 Malaria
Appendix B

Sent from MSL

Received

10
10
10
10
10
10

10
10
10
7
10
10

Amend no to state actual qty

received

Stock Recount Process

Code
Desc

Qty Expected

Qty Counted

Diff

MSL001
MSL001
MSL001
MSL001
MSL001
MSL001

10
10
10
10
10
10

8
7
6
5
4
3

-2
-3
-4
-5
-6
-7

23 | P a g e

Malaria
Malaria
Malaria
Malaria
Malaria
Malaria

recount Qty

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

Device
DeviceSoftware
Software

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

Forecasting
Forecasting
Module
Module

Optimisation
Optimisation
Module
Module

Shipment Dates
for routes
maintained in
eZICS (Scenario
Manager)

Forecast run for

facilities in delivery
cycle (once weekly ?)
10 days before
shipment

eZics applies
certain rules
related to
availability of this
stock

Forecast Approved
submission from
District

Forecast diverted
for approval at
MSL if any line
amended by more
than 10%

Pipeline data with

expected arrival
(Orders due in)
and QC stock
Status 3)

Linked Items
(Pack Sizes )

Linked Items are

converted to single
units (ie tabs/ vials
etc)

Optimization
process (based on
available and
pipeline stock )

For linked items

eZics converts
back to MACS
SKU based on
FEFO

Stock reserved for

eZICS program
(defined calculation
in eZics.Scenario
manager)

3.1.2 Simple view of Approval / Authorisation points and procedures

28 | P a g e

MACS
MACS

Unallocated
Available stock in
MACS (Status 1)
by expire date

Stock allocation
(input from eZics
immediately allocate
stock in MACS Order
allocation level

Pick slip release

and normal MACS
processes

Shipment labels and

barcodes created at
point of dispatch

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

Facility user via
eZICS Mobile
Client

District user via

eZICS Client

eZICS Shipment
Optimistion
Module

MACS

Forecast Demand
Output (of items
flagged for SO
method)

Submit
demand
usage

Establish order

eZICS Demand
Forecast Module

Produce Forecast
Advice note to
facility user / Hosp
Store/ Health
Centre

Produce Demand
Driven Forecast
request based on
history etc

Final Decision for MOH

where this approval should
happen

Demand driven order

Approve Forecast
District/Hospital
Pharm in Charge

Nil response in 48 hrs

= deemed Forecast accepted
Yes

No
Reject or
amend ?

Amend

approval

reject

Submit
amendments

Amended
Forecast

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

Process amended
Forecast and
optimise shipment
schedule based
on live inventory
data

Live
inventory
data of
stock
available
to eZICS

Process order

Stock issue requrest

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

Allocate stock &

produce Order
and pick lists

Process complete.
Stock despatched from
MSL

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
Stock Receipt (Health Facility)
eZICS PDA SRF Version 1.0 5

Aug 2011

Identify Boxes that

Represents one Invoice/
shipment by sorting
boxes 1of x etc, from
the carton labels

Stock Arrives at
Health Facility

START

th

All Boxes
received for the
Shipment

Choose Receipts
on the PDA and
then select Full
Receipt

Yes

No

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

Open All boxes for

the shipment, unpack
stock and check
individual items

Find dispatch
Note/ MSL
Invoice

No

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
No
Choose Receipts on
the PDA menu and
select Individual Item
Receipt

Check items against

document and note
any discrepancies

Scan any carton label to

pick up the dispatch /
Invoice number, or enter
the number from the
documentation and enter

Yes

or select lookup and start

typing the product
description and select the
product & pack size

Check PDA
screen for correct
item and pack
size

Yes

No

Find correct item

code or barcode from
drop down list or
catalogue and scan
or enter code again

PDA received
receipt data

No
The Receipt detail
will automatically be
displayed on the
device (spreadsheet
format)

PDA received
receipt data

Enter Goods Received

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

The device will

return a message
that the receipt
data has not been
received

Stock received and packed on

shelve, Shipment status changed
to received at facility

Scan the Stock Item

label from the bin or
scan the product bar
code, or enter the
product code from the
Invoice and enter

Enter the Goods

Received Voucher
number and enter

Yes

Enter quantity
received and enter
(1)

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

Page 1

3.2.1.2 Stock received Not from MSL

30 | P a g e

Stock Receipt (Health Facility) Not received from MSL

eZICS PDA SRF Version 1.0 5

th

Aug 2011

Stock Arrives at
Health Facility

START

Record Invoice
number from Box
Label if available . List
Items and quantities
and file receipt list.

Find Invoice from

supplier
No

Yes

Choose Receipts on
the PDA menu and
select non MSL
receipts

Enter the invoice number

or internal reference and
the Supplier Name (open
text field) from the
documentation and enter

Check items against

document and note
any discrepancies

or select lookup and start

typing the product
description and select the
product & pack size

Scan the Stock Item

label from the bin or
scan the product bar
code

Check PDA
screen for correct
item and pack
size

Yes

Stock received and packed on

shelve, Shipment status changed
to received at facility

No

Find correct item

code or barcode from
drop down list or
catalogue and scan
or enter code again
(1)

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

Enter quantity
received and enter

Page 5

3.2.1.3 Stock received Transfers from Other Institutions

31 | P a g e

Receipt of Transfers
th

eZICS PDA TR Version 1.0 5 Aug 2011

Transferred Stock
Arrives at Health
Facility

START

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
Yes

Choose Receipts on
PDA, Show incoming
receipts and then
choose Outstanding
transfers.

No

List Items and

quantities and file
receipt list.

or

Check items against

document and note
any discrepancies

Choose Receipts on
the PDA menu and
select Individual Item
Receipt

Enter the transfer

number on the PDA and
enter(2)

Check PDA
screen for correct
item and pack
size

or select lookup and

start typing the product
description and select
the product & pack size

Scan the Stock Item

label from the bin or
scan the product bar
code, or enter the
product code from the
Invoice and enter
PDA received
receipt data

Yes

No

Yes

Enter quantity
received and enter
(1)

The device will

return a message
that the receipt
data has not been
received

The Receipt detail

will automatically be
displayed on the
device (spreadsheet
format)

No

Stock received and packed on shelve ,

Transfer Status Received at Facility

Find correct item

code or barcode from
catalogue and scan
or enter code again

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

3.2.1.5 Advanced view of stock to be received from MSL

32 | P a g e

Incoming Receipts
th

eZICS PDA IR Version 1.0 5

START

User wants to view

incoming stock

Information shown on
screen and printable if
devise is able to connect to
a printer.

Aug 2011

Select Receipts on
PDA and then
show incoming
Reciepts

Select : Product or
Shipment number
or shipment status

The system will return for product

selected : quantities in every status
and total
For shipment number all items, pack,
qty and status and for shipment
status: All items, pack and qty.

Page 4

33 | P a g e

3.2.2 Issuing Stock

Stock Issues (Health Facility)

eZICS PDA SI Version 1.0 5

START

Facility determines need to

replace a stock item in the
dispensary or ward
(Internal Requisition note
from Ward/ Dispensary)

th

Aug 2011

Select the Ward or

Destination and
enter requisition
number

On the PDA, select

Issues

No

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

Bin or Product
Barcode

Yes

Select Yes and Scan

Barcode and check
product description
and pack size on
screen

No

Correct
description and
pack

Yes

Enter quantity issued

and enter to confirm

Stock immediately
moved to Dispensary or
Ward dispatch

Page 1

34 | P a g e

3.2.3 Stock Management

3.2.3.1 Adjustments
Stock Management - Adjustments
th

eZICS PDA SMA Version 1.0 Aug 5

START

Facility determines
need to adjust stock
item due to for
example Damages,
Expired Stock etc

2011

On the PDA, select

Stock Management and
then select Adjustments

No

Select Lookup and start typing

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

Select the reason code

for the adjustment (1)

Bin or Product
Barcode

Yes

Scan Barcode and

check product
description and pack
size on screen

No

Correct
description and
pack
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

Yes
Enter quantity to be
adjusted with + or
for pos/neg
adjustment and enter
to confirm

Stock is adjusted by
system with the quantity
(subtracted or added with
the indicated quantity)

Page 1

35 | P a g e

3.2.3.2 Returns / Transfers

Stock Management Returns / Transfers

eZICS PDA SMRT Version 1.0 Aug 5

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

No

Select lookup and start typing

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

th

2011
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

Bin or Product
Barcode

Enter the Goods

Issued Voucher
number

Yes

Scan Barcode and

check product
description and pack
size on screen

No

Correct
description and
pack

Yes

Enter quantity to be
transferred or
returned and enter to
confirm

Report on open
transfer
transactions
needed (central
and district)

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

Page 1

3.2.3.3 Stock Write Offs (Board of Survey)

36 | P a g e

Stock Management Write Off

eZICS 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

A report can be printed

by the system at facility
or District level of items
written off per date/ date
range

On the PDA, select

Stock Management and
then select Stock Write
off

The system will

change the status
of the stock to
written off

The system provides a

screen with all stock
items, by description, pack
size and quantity on
expired and damaged
status at the facility

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

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?

Page 3

3.2.4 Stock count processes and procedures

37 | P a g e

3.2.4.1 Full Stock count process

Stock Count All Items (Health Facility)

eZICS PDA STF Version 1.0 110622

START

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

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)

Facility prepares for stock

take: Received items on
shelves, Issued items
removed from shelves,
stock on shelves what is
deemed to be in system

The user continues

counting all items in the
facility

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

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

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

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)

Starting at one end of

the facility the user
starts the count by
counting the item
physically

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

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

The system will only

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

1: The count is completed at this

stage by the system for matching
items
2: No items may be added as part
of the recount procedure
3: 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)

Once all items are

counted and flagged the
system will proceed on
the selection of Stock
Count Complete

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

?Stock counts and connectivity :

Will it be possible to do it offline ?
Yes in our opinion as latest stock
info should be on device

Page 1

3.2.4.1 Single Item Stock count process

38 | P a g e

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

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

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 user scan the

item or alpha search
and select the item on
screen.

The user enters the

quantity counted

The system displays the

item description and
pack size and status /es
and a field to enter the
count

The user enters

the final count in
the field provided

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

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

Page 2

3.2.5 Supplemental Order

39 | P a g e

Supplemental Orders
Facility user via
eZICS Mobile
Client

District user via

eZICS Client

User Select Order

Tab on Menu and
then select
Supplemental
Orders

eZICS Demand
Forecast Module

eZICS Shipment
Optimistion
Module

MACS

List of orders to be approved

to be visible at District .

Yes/
amended
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 Checked
against Forecast
or AMC

Order Checked
against stock
available

Pending more
than 14 days

No

If order not
approved within 2
weeks, it is
automatically
cancelled by the
system and a new
order will need to
be submitted

Order listed and

displayed to MSL
user for
amendment/ final
approval (listing ,
Forecast/AMC,
MSL stock
position, stock on
the way to facility

MSL approve,
reject or amend
order

Order/affected
lines Cancelled

Not Approved
Approved/amended

Is Item part of
SO

Yes

No

Process order
request for SO
lines and optimise
shipment schedule
based on live
inventory data

Consolidate SO
and non SO lines
of order in eZics

Live
inventory
data of
stock
available
to eZICS

Stock issue Request

Allocate stock &

produce pick lists
with one order
number
Process complete.
Stock despatched from
MSL

Section 4 MSL / MACS issues

40 | 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 unallocated 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 management procedures for ALL products
but only optimise deliveries for those that are defined as shipment optimised
4.3. Historical Data
We will need to pre load historical data for all facilities from MACS to allow before and after comparisons in
the same database.
Data to be held:
50 | P a g e

 All Issues
All Orders
All data entered on the R&R forms by month, including stock levels by product by facility by month
from supply chain manager
Two years data required

4.4. Management Reporting / Data warehousing

It is envisaged that the IBM solution will be visible to all levels of the health chain from the Minister of Health
to the smallest facility (2,500 users in total). As such, we need to ensure that all relevant data held in MACS is
transferred to IBM to enhance the visibility of stocks in the supply chain. For example:

Although Batch Nos, Values and Expiry dates are not being managed at facility level. Visibility of what
Batch Nos and Expiry dates were sent where would be extremely useful to the MoH.

We should hold sufficient information in IBM to allow good report writing capabilities. For example.
o We should hold not just facility codes but the addresses and contact details
o On product data we should hold any relevant information not necessarily used for stock control
by the facilities. i.e. Stock by supplier / Donor (MSL Level), Expiry Date.
o Values of Stock in ZMK
o A detailed list of the likely Management reports is defined in the User Cases document

4.5. Forecast Horizon

The minimum requirements for Shipment Optimisation (In terms of creating orders is 6/7 months. However, it
is envisaged that this solution when implemented nationwide will become the core system for forecasting
national quantification. As such, the requirement for the forecast horizon is a minimum of 18 months?
5. Process Issues at MSL
MSL will be required to amend its Standard Operating Procedures to accommodate the routines involved in
freezing the stock records in MACS and transferring the data to IBM to allow optimisation.
The key issue arises around the pipeline data, Order receipt / allocation of stocks to orders and creation of
Barcodes and Shipment labels.

51 | P a g e

Section 5: Policy Issues that impact on eZICS

The Following Key Policy Issues arise in considering the eZICS.
Historical Data

The legal requirement for historical data is 5 years.

Product selection of optimized products

52 | P a g e

At present, there is no agreed list of essential drugs in Zambia (i.e. the items that will be
optimised). This will be developed over the course of the implementation and further developed
during the research year. As such eZICS will need to be flexible to accept changes to the list of
optimized products during the course of the research. Secondly, there will be two levels of drugs
that will be controlled in eZICS: Those items that facilities may order that will require
optimization and a second set of stocks that will be controlled within the system but will not be

optimized. For the second category of stock, eZICS will be operating as an order transmission
and authorization device and a stock control system.
Authorisation and Control

MoH policy in Zambia is that all orders must be approved by the District Health Office,
secondly, the manual stock cards will need to be maintained at facilities until such time that the
MoH, Auditor General is satisfied that the system is functioning satisfactorily. There are
currently policy changes on electronic data records and transmission going through parliament;
however the final outcome for these issues is not yet known. As such, the system will need to
cater for current practices.

Stock count procedures

We require further clarification from MoH as to the set procedure and timeliness of carrying out
stock take procedures at facility levels. This may have an impact on our ability to satisfactorily
perform the necessary audit and stock take functions.

Visibility of Data

Further clarification of whom is able to see which sets of data is required. For example, can each
province review other provinces performance? The system may need to cater for different access
rights to the various levels of data.

Proof of Delivery Signatures

Volumetrics

53 | P a g e

Currently POD is signed at District level not Facility level, a policy change may be required (as
is probably sensible) to request the Districts to forward the dispatch notes to the facilities
receiving the goods and obtain a second signature / authorisation process that the goods have
been received. This will allow full auditability between the system and the paper work and would
allow easy understanding of any differences that may arise.