Section II - Schedule of Requirements - TOR Strengthened LMIS PDF

You might also like

Download as pdf or txt
Download as pdf or txt
You are on page 1of 27

FUNCTIONAL USER AND SYSTEM

REQUIREMENTS

FOR THE STRENGTHENED LOGISTICS MANAGEMENT


INFORMATION SYSTEM (LMIS)
MINISTRY OF HEALTH
KINGDOM OF CAMBODIA

under the GFATM Health System Strengthening Grant

August 2017
 

Contents
List of Figures...................................................................................................................................................................... 2 
List of Tables ....................................................................................................................................................................... 2 
  Introduction ............................................................................................................................................................... 3 
  User/Functional Requirements .............................................................................................................................. 4 
2.1  Functionalities of the existing LMIS/DID (Legacy) ................................................................................... 4 
2.2  Proposed Enhancements to existing systems ........................................................................................... 6 
2.3  Product and facility data................................................................................................................................. 7 
2.3.1  Product data ................................................................................................................................................. 7 
2.3.2  Facility data ................................................................................................................................................... 7 
2.4  Enhanced User Requirements (EL) ............................................................................................................. 7 
2.4.1  Description of ADDTIONAL functionalities and enhancements ................................................... 7 
  Essential Logistics Data, Records and Reports.................................................................................................. 9 
3.1  Calculated Data Items .................................................................................................................................... 9 
3.2  Records ............................................................................................................................................................ 10 
3.3  Reports ............................................................................................................................................................ 10 
3.4  Graphs .............................................................................................................................................................. 12 
  System Requirements ............................................................................................................................................ 13 
4.1  General Requirements ................................................................................................................................. 13 
4.2  Technical Requirements............................................................................................................................... 14 
4.3  Security Requirements ................................................................................................................................. 15 
4.4  Operational and Maintenance Requirements ......................................................................................... 17 
4.5  Performance ................................................................................................................................................... 18 
4.6  Environments and Infrastructure ............................................................................................................... 19 
  Acronyms ................................................................................................................................................................. 21 
  Glossary .................................................................................................................................................................... 23 
  References ................................................................................................................................................................ 26 
  Annex ........................................................................................................................................................................ 26 
8.1  Annex 1 - Information of the Legacy LMIS ............................................................................................. 26 

1
List of Figures
Figure 1: Cambodia in-country supply chain information and product flow ....................................................... 3 
Figure 2: Logistic management and stakeholder mapping ........................................................................................ 4 

List of Tables
Table 1: Functionality of the Legacy LMIS (LL) ........................................................................................................... 5 
Table 2: Functional Requirements of the Strengthened LMIS ................................................................................. 9 
Table 3: Lists Basic Calculated Data Items ................................................................................................................ 10 
Table 4: Reports requirements .................................................................................................................................... 11 
Table 5: Basic Graphs ..................................................................................................................................................... 12 
Table 6: List of system general requirements ........................................................................................................... 13 
Table 7: List of technical requirements ...................................................................................................................... 14 
Table 8: List of security requirements ........................................................................................................................ 15 
Table 9: List of operational and maintenance requirements ................................................................................. 17 
Table 10: Performance requirements ......................................................................................................................... 18 
Table 11: Environments and Infrastructure requirements ..................................................................................... 19 
Table 12: Basic Hardware (Sever) Requirement ...................................................................................................... 19 

2
Introduction
An effective logistics management information system (LMIS) ensures an adequate quantity and quality of
vaccines, essential medicines and supplies are always available to meet patient demand. In order to do this,
the LMIS support:

1. Capturing accurate routine administration, dispensing and consumption data.


2. Real-time, end-to-end logistics data from point of origin to service delivery point
3. Demand forecasting, capacity building and modeling based on consumption1.

This document includes technical (software) specifications for the enhancement and migration of the DID
applications to an updated platform and the deployment of the new strengthened LMIS in five (5)
provinces, namely Phnom Penh (including Department of Drugs and Food and Central Medical Store),
Kampong Cham, Kampong Speu, Siem Reap and Battambang.

The strengthened LMIS (option 4)2 builds upon the existing structure and information of the current
Microsoft based Drug Information Database (DID) applications with an integrated system implemented
on a modern technology stack. The strengthened LMIS leverages new and enhanced networking
capabilities in Cambodia to provide an integrated platform for supporting LMIS, with anticipated longevity
through continued enhancements and improved functionality.

Current product and information flow is presented in Figure 1.

Figure 1: Cambodia in-country supply chain information and product flow

Medicines, drugs, supplies, commodities, goods, materials, products, and stock. These items flow through a logistics system. Users,
clients, patients, and customers. The people who receive or use supplies. The terms are used interchangeably throughout this
document.

1
PATH Common Requirements for Logistics Management Information Systems, Seattle: PATH; 2010
2
MOH LMIS Technical Working Group, 4th meeting minutes

3
Logistics management process and stakeholder mapping is shown in Figure 2.

Figure 2: Logistic management and stakeholder mapping

The strengthened LMIS will not include “selection” and “procurement” functionality as these processes
are carried out by a selection committee and independent procurement agencies. However, future
integrations and interoperability design factors should be taken into consideration during the development
of the new software.

User/Functional Requirements
2.1 Functionalities of the existing LMIS/DID (Legacy)
The existing DID applications include:

‐ National Drug Inventory Database, used at Central Medical Store to process orders from
operational districts, provincial hospitals, and national hospitals.
‐ Provincial Drug Inventory Database, designed to support provincial health departments to screen
and approve report and request forms from provincial hospitals and operational districts before
sending to Central Medical Store for order processing.
‐ Operational District Drug Inventory Database (ODDID), used at operational districts to process
report and requests forms from health centers and referral hospitals.
‐ Hospital Drug Inventory Database (HOSDID), used at referral hospitals, provincial hospitals and
national hospitals.

The functionalities of the current DID applications (Legacy) are summarized pared in Table 1 below.

Health Centers have a paper-based inventory system as HCDID (Health Centre Drug Inventory Database)
is not deployed. HCDID requirements are listed in Enhancements (Section 2.2).

4
Table 1: Functionality of the Legacy LMIS (LL)

Functions/Processes NATDID PRODID ODDID HOSDID


Forecasting provide accurate √* The system √ The system allows √ The system √ The system
estimation of supplies for a specific forecasts the quantity of to estimate the forecasts the quantity forecasts the quantity
time period medicines and provincial needs of medicines and of medicines and
commodities needed commodities needed commodities needed
for the country. at the OD level at facility level

Requesting/Ordering: ensure - √ √ ability of OD users √


timely ordering of the medicines in the to produce
right quantity consumption reports
from health facilities

Receiving: receive verified quantity √ The system currently - √ √ ability to receive


and quality of goods into receives status updates and process electronic
store/pharmacy and determine need for from ODDID via USB invoices received from
remedial action when necessary and email. CMS/OD

Inventory control: monitor


stock levels and ensure good quality
products available

‐ Product classification √ by program (HIV, TB, √ by program (HIV, √ by program (HIV, √ by program (HIV,
Malaria) TB, Malaria) TB, Malaria) TB, Malaria)

‐ Stock records: basic information


for inventory management by √requests processing, √Stock √request processing √Receiving, stock on
recording all transactions for an report receiving balancing/stock on hands and transactions
item including receipts, issues, hand
order placed, order received and
stock losses)
√ ability to track
‐ Product flow tracking
√the system tracks all physical inventory at -
drug flow up to - OD and below and
stock transfers
between health
facilities

‐ Stock transfer - - √ ability to track -


physical inventory at
OD level and below
and stock transfers

Dispatch (distribution): √ tracks items shipped - - √ tracks items issued


identify and prepare accurate quantities from CMS to the hospital sub-
of items packed correctly from store pharmacy
needed for distribution/ transport for
lower level

Transport (distribution): - √ ability to track the - -


manage movement of supplies between quantity of
locations to ensure items are delivered commodities
in good condition and on time received by health
facilities from CMS

Visibility - √ ability to view the - -


stock status across
and within facilities in
their provinces

*Legend: “√”- function available; “-“ not applicable

5
2.2 Proposed Enhancements to existing systems
The Strengthened LMIS (option 4) includes the following functional and system improvements and
enhancements:

o central data repository and new method for data exchange


o electronic workflow based approach to approvals
o data visibility tools to view the repository (for authorized users),
o early warning system of impending expiry situations and impending stock outs
o introduction of PRODID and HCDID functionality
o changes to the parallel HIV LMIS
o additional functionality such as dispensing at the facility level

Data visibility shall follow the hierarchy of the Ministry of Health and reporting formats shall be designed
and fit to the need. The system should accommodate additional functions and enhancements needed in
the future such as integrations to the patient registration and health management information system. The
system shall not work and end up with only Microsoft Office 2016 but it should be able to upgrade as
technology evolves. The internet connections shall be used according to the availability and feasibility of
each location but allow maximum offline functioning as is feasible. The system shall be user friendly, simple
and flexible and not require staff with high capacity and skills in IT.

MOH Guiding Principles for the LMIS

‐ producing timely and accurate data for decision


making;
‐ simple and user-friendly;
‐ government ownership, leadership and sustained
management;
‐ single (integrated) tool for management of medicine
and other health products and the capability of easily
adding other medicines and health products; and
‐ interoperability with other health information
systems

6
2.3 Product and facility data
2.3.1 Product data
Legacy Enhancements:

International non- proprietary name Batch/lot number


(INN)
Commodity Code (CMS code) ATC code to be introduced in parallel with the
existing commodity code
Product Category (HIV/AID, TB,
Malaria etc) VEN assigns each medicine on the Essential
Dosage form (tab, cap etc.) Medicines List to one of the following categories: V:
Strength (milligrams, grams etc) vital medicines; E: essential medicines; N- non
Package unit essential medicines (see Section 2.4.1)
Expiry date
Manufacturer name (NATDID only)
Source

2.3.2 Facility data


Facility data should include:

Code Number - MOH Standard Code Number to be introduced (currently six digits code
number is given by CMS)
Facility Name
Facility type (CMS, PH, RH, OD, HC etc)
Contact person or Supervisor’s name (for administrative transaction)

2.4 Enhanced User Requirements (EL)


2.4.1 Description of ADDTIONAL functionalities and enhancements
a) In the Anatomical Therapeutic Chemical (ATC) classification system, the active substances are
divided into different groups according to the organ or system on which they act and their therapeutic,
pharmacological and chemical properties. Medicines are classified in groups at five different levels. It
is a powerful tool to analyze medicines utilization with the aim of improving medicines (antibiotics)
use. https://www.whocc.no/atc/structure_and_principles/. ATC code will be used in addition to the
existing CMS product code.
b) Electronic workflow based approach to approvals. The system should allow for approvals to
be conducted via electronic workflow. Examples of workflows include 1) approvals for requests from
hospitals to CMS 2) approvals for shipping of commodities; 3) approvals of transfers between facilities;
and 4) sign-off on leakages or losses of commodities. There is currently no requirement for electronic
signatures.
c) Early warning system of impending expiry situations and impending stock outs. The strengthened
LMIS should be able to transmit alerts and notifications for expiry threshold, stock outs, overstock
and understock and track batch/lot numbers. For example, warning to health facility provided at the

7
75% depletion and warning to Province of Health Facility depletion at 90% and consideration of
max/min stock level.
d) Data visibility tools to view the repository (for authorized users). The system will provide a portal
(view) to view repository data to authorized users. For example, Provincial level users will be able to
view data from the database for their entire province and they will also able to view a specific OD in
their province.
e) Dispensing refers to the process of preparing and giving medicine to a named person on the basic
of a prescription. Dispensing module will be developed to track consumptions at the health facility. It
should include data on (a) patient who has received a treatment, (b) commodities which have been
dispensed to a patient and (c) prescriber who has prescribed the commodities. Future interoperability
with MOH Patient Management Registration System (PMRS) should be taken into account during the
development process.
f) Central data repository and new method for data exchange. The system will store data in
one central database (data repository), so there will be no need to send/transfer data via USB stick,
E-mail or via cloud solutions (e.g. Dropbox, Google drive).
g) Global Search. The system should allow for authorized users to search the database in accordance
with key fields and parameters. Search interface: Enable flexible search criteria for accessing
transactions by any data element including item number, requisition, supplier, date, location, status etc 
h) Notification alert of approval processes: When there is an approval request from Approver,
System should send alert to Approver via SMS / E-mail (priority) to ask for approval. In case of
approver is not available to access to system for period of time (e.g. go out to mission / abroad), then
approver can delegate authorize to another user within system (e.g. his/her assistant) to approve. 
i) Role Based Access Controls. Inventory and data visibility should be in accordance with user group
access controls. Authorizations must be configurable by a system administrator in accordance with
user groups and geographical designation (e.g. provincial manager in Phnom Pehn). The system will
then assign the capabilities, permissions, and views to an individual user in accordance with the
predesignated access controls for a given role in a given geographic location.
j) The enhanced system should be able to generate data quality monitoring reports (timeliness and
completeness) for data from each health facility. It should also include improved functionality for
capturing Emergency Orders. The system should use maintainable reference libraries for medicines,
commodities, and facilities and be flexible to allow for future upgrading to be interoperable with
other information system.
k) Paper-based health center inventory management exists. This inventory management system will be
computerized with functionalities listed as HCDID (NEW) including dispensing of commodities.
l) VEN system: A system of setting priorities for purchasing pharmaceuticals and keeping stocks in
which medicines are divided according to their health impact of individual medicines. VEN assigns each
medicine on the Essential Medicines List to one of the following categories: V: vital medicines are
potentially lifesaving, or are crucial to providing basic health services. E: essential medicines are
effective against less but nevertheless significant form of illness but are not absolutely vital to providing
basic health care, N- non essential medicines are used for minor or self-limited illnesses, or of
questionable efficacy, have a comparatively high cost for a marginal therapeutic advantage.

A summary of Strengthened LMIS user requirements is listed in Table 2.

8
Table 2: Functional Requirements of the Strengthened LMIS

ID Functions/Processes NATDI PRODID ODDID HOSDID HCDID


(see details in the Legacy) D (NEW)
INV1 Forecasting LL LL LL LL LL

INV2 Requesting/Ordering LL LL LL LL LL

INV3 Receiving LL LL LL LL EL

INV4 Inventory management

‐ Product classification by LL LL LL LL EL
program

‐ Stock records (additional info) EL EL EL EL EL


by authorized users

‐ Product flow tracking LL EL EL EL ‐

‐ Stock transfer monitoring EL EL EL - -

INV5 Dispatch LL EL EL - -

INV6 Transport EL LL EL EL -

INV7 Dispensing - - - EL EL

INV8 Visibility: ability to view the stock EL LL EL EL -


status across and within facilities

INV9 Stock Warning System: EL EL EL EL EL

INV10 Role Based Access EL EL EL EL EL


Controls

INV11 Electronic Approvals  EL EL EL EL EL

INV12 Global Search EL EL EL EL EL

INV13 Notification alert of EL EL EL EL EL


approval processes

* LL- Legacy LMIS functions; EL- Enhanced LMIS functions

Essential Logistics Data, Records and Reports


3.1 Calculated Data Items
A computerized LMIS contains data that describe the logistics system and data that track the movement
of products through that system.

9
The strengthened LMIS should be able to calculate basic data items such as Average monthly
consumption, Months of stock on hand, Quantities to resupply and Reporting Rates (Table 3).
Calculated data items appear on reports and graphs to facilitate decision making and are used as a means
of validating data entry.

Table 3: Lists Basic Calculated Data Items

ID Basic data items NATDID PRODID ODDID HOSDID HCDID

DAT1 Average monthly LL LL LL LL EL


consumption (AMC): For each
facility and product, calculate AMC on the
basis of the quantities dispensed to users in
several consumption reports over a period
of time. The number of reports to use in the
calculation is generally included as a system
parameter.

DAT2 Months of stock on hand: For LL LL LL LL EL


each facility and product, divide the
reported stock on hand at the end of
given period by the calculated average
monthly consumption.

DAT3 Quantities to resupply: For LL LL LL LL EL


each facility and product for a given
period, multiply the calculated AMC by
the maximum stock level and subtract
the reported stock on hand.

DAT4 Reporting rates: for each EL EL EL EL EL


reporting period, calculate the
percentage of active facilities that have
submitted reports.

3.2 Records
The LMIS should store the three types of records to provide accountability and traceability for the
product through the supply chain, from CMS to a health facility.

Stock- keeping records hold information about products in storage. These include stock or bin cards
that contain information about a specific product and bath or lot number. Stock keeping records are
used to record stock balance, receipts, issues, and losses.

Transaction records: include requisition/request vouchers, issue vouchers, transfer vouchers, goods
received note, delivery notes, and packing lists.

Consumption records: include dispensing register and daily use logs.

3.3 Reports
The LMIS should generate important reports listed in Table 4.

10
Table 4: Reports requirements

ID Reports NATDID PRODID ODDID HOSDID HCDID

REP1 Quantity to supply or quantity LL LL LL LL EL


requested by facility: lists the
quantities to supply a singly facility for all the
products that the facility is authorized to
manage.

REP2 Stock status by distribution LL LL LL LL EL


level and by product: summarizes
the stock status for one or more selected
products at each distribution level in the
logistics system for a period of time.

REP3 Consumption average by LL LL LL LL EL


product: shows the AMC for one or
more products for a period of time
(monthly, quarterly etc).

REP4 Distribution discrepancies: EL EL EL - -


identifies potential errors in reporting
by facilities.

REP5 Expiry data: shows expiry data of LL LL LL LL EL


products by “fist expiry first out” principles

REP6 Emergency order: lists emergency LL LL LL - -


ordered times by a facility

REP7 Data entry errors: notes potential EL EL EL - -


data errors allowing operators to first
validate their data entry before contacting
the facility to resolve the error.

REP8 Non- reporting facilities: EL EL EL - -


identifies facilities that have not
submitted reports for a selected
reporting period.

REP9 Stock imbalances: indicates the EL EL EL - -


supply status at every facility in the
distribution system: overstock,
understock and stock out.

REP10 Adjustments summary: LL LL LL - -


summarizes adjustments by product and by
adjustment type for identifying any unusual
adjustments (loss, expiry) for a particular
product or by a particular facility.
REP11 ABC analysis report: based on EL - - - -
Pareto principle, analyzes annual medicine
consumption and cost determines which
items account for the greatest proportion
of the budget.

11
3.4 Graphs
The Strengthened LMIS should be able to product basic graphs with essential information on logistics
system performance in a quickly understood visual format. Table 5 lists Basic Graphs for the
strengthened LMIS.

Table 5: Basic Graphs

ID Graphs NATDID PRODID ODDID HOSDID HCDID

GRA1 Consumption data: displays EL EL EL EL EL


quantities of a selected product delivered
and dispensed to users over a selected
period time. This graph can be displayed as
either a line or bar graph showing
quantities dispensed over time.

GRA2 Stock status: for a selected product, EL - - - -


displays percentage of facilities that are
stocked according to plan over a selected
period of time. May also include percentage
of facilities stocked out or overstocked.

GRA3 Average stock levels: displays the EL EL EL EL EL


average stock level of a selected product
over a selected period of time.

12
System Requirements
4.1 General Requirements
Table 6: List of system general requirements

ID Requirement Description
GEN01 Languages - User Interface: The system should support the following languages, both
in terms of text and messages displayed to the user and the format of data (date and
number formats) and all associated documentation:
· English
· Khmer
GEN02 Extensibility: The system must be extensible to allow for integration with open source
reference libraries. The vendor will minimize hard coding any libraries so that the system
can integrate with other HIS systems at a later date once standards are developed. The
system will minimize proprietary dependencies. The system should be developed in a
modular (segmented) format so that changes to functionality can be made in future version
without having to rewrite the entire code base.
GEN03 Dates: Dates must be displayed in day month year format (DD/MMM/YYYY)
(01/Jan/2018)
GEN04 Usability - User Interface: Ease of use is a primary requirement for the user interface.
The user interface and user experience (UI/UX) should be similar in design to the current
UI/UX of the Drug Information Database applications to minimize user training and
confusion. Error messages should be informative and easy to understand and error
messages must be written to error logs to enable these issues to be properly audited and
investigated. The system should incorporate all usability heuristics to support ease of
navigation and general use of the system including data entry.
GEN05 MS Office Integration: The LMIS Should allow the import and export of CSV files (e.g.
excel) by authorized users.
GEN06 Audit Trails: System must be capable of providing audit trails that support legal and audit
requirements of the Government of Cambodia.
GEN07 Help facilities The system should provide on-line context sensitive help and user manual
help. These should be capable of being easily modified by system administrators. The
system help feature shall assist users in the recognition, diagnosis and recovery from
errors.
GEN08 Cambodia Localization: Confirm that the System will support the following in
respect of local settings:
a) The base currency of the system will be Cambodian Riel but the system will support
conversion from and to other currencies based on current exchange rates.
b) The System must handle the local calendar, including public holidays;
c) The System must be compliant with Cambodia's relevant regulations and legislation
d) The System must be able to process date-oriented functions with appropriate regard
to leap years, solar years, public holidays, local anniversaries and weekends.
GEN09 Support Requirements: The Software Implementation Partner (SIP) is requested to
support the application and provide support services direct to users of the application and
Cambodia's Ministry of Health's own Help Desk function. SIP must confirm help desk
support is available.
GEN10 Documentation: SIP will be asked to prepare and provide a User-Manual and Technical
Manual and training materials.

13
GEN11 Standard Reports: The system should use a dashboard and analytics reporting tool
capable of producing a set of standard operational and management reports, data and
graphs. These should be menu driven and be capable of complying with the Government
of Cambodia image and branding. Reports should be available in following languages:
· English
· Khmer
GEN12 Standards: Reference libraries must be able to change over time and comply with GS1
and WCO Data Model version 3 data models and standards
GEN13 Warranties and Licenses: The SIP must have back to back arrangements with any
subcontractors, OEMs, or software providers for all software and hardware components.
GEN14 Real time transactions: Provide real time response transactions submitted by
connected devices up to the configured national volume level.

4.2 Technical Requirements


Table 7: List of technical requirements

ID  Requirement Description 
Database Schema: There should be a published database schema provided (e.g. a blueprint 
TEC001 
of how the database is constructed). 
System  Data:  All  system  data  must  be  contained  within  the  database  (i.e.  not  in 
TEC002 
documents) when synchronization occurs. 
Offline Capabilities: The system must support data entry and capture in offline mode (e.g. 
not write to the database but captured in the client side so that the user does not "lose" 
TEC003  data entered in offline mode). Basic functionality and tables will be available. The supplier 
should provide an offering that maximizes the user capabilities and general ease of use in 
offline mode while still maintaining a single database for the LMIS. 
Browser Based: The system should be browser based and compatible with IE version 11, 
TEC004 
Microsoft Edge, Chrome, Firefox, and Safari.  
Remote Maintenance Access: The system must be accessible remotely for maintenance, 
TEC005 
upgrades etc.  
Remote  Monitoring:  There  should  be  capabilities  for  remotely  monitoring  the 
TEC006 
performance and usage of the system. 
General Facilities: The system should have facility to see who is logged on at any one time 
TEC007 
and provide reports on System usage by User. 
External Interfaces: External interfaces to other systems should be XML/JSON based or be 
TEC008 
facilitated through data base integration using SQL. 
Sizing  Information:  The  SIP  must  be  able  to  provide  sizing  information  to  assist  with 
TEC009 
technical infrastructure requirements. 
Multiple  Environments:  The  system  is  likely  to  be  run  in  at  least  five  environments  i.e. 
TEC010  Development,  System  Test,  Acceptance  Test,  Production,  and  Backup  and  license 
implications of running the system in these environments must be clearly stated.  
TEC011  License Requirements: Any license restrictions on multi use must be clearly stated. 
Perpetual  License.  Any  license  requirements  must  provide  the  Cambodian  Ministry  of 
TEC012 
Health with rights to use/perpetual license. 

14
ID  Requirement Description 
Disaster  Recovery:  In  a  period  of  disaster  recovery,  the  Cambodian  Ministry  of  Health 
would  manage  and  co‐ordinate  the  implementation  of  the  failover,  but  the  supplier  is 
TEC013 
expected  to  design  the  architecture  and  deliver  the  backup  environment.  The 
supplier/vendor should provide evidence that it will be able to support this need. 
System Upgrades: In order to minimize costs and risks the system must be able to support 
TEC014  a seamless upgrade policy. There should be no requirement to reconfigure the package 
following an upgrade. 
Support  &  Maintenance:  The  SIP  must  be  prepared  to  support  the  application  for  a 
minimum of 12 months from the date of implementation. The actual annual support costs 
TEC015 
and  requirements  will  be  the  subject  of  annual  negotiations  between  the  Cambodian 
Ministry of Health and the successful bidder.  
Upgrades & Enhancements: Should the SIP use proprietary software, the SIP must explain 
TEC016  how  enhancements  or  upgrades  will  be  available  and  what  influence  the  Cambodian 
Ministry of Health will have in the development of these. 
Future App Development: MOH anticipates the development of an App in future releases 
of  the  product  for  simple  business  processes  at  lower  level  facilities  (e.g.  health  facility 
TEC017 
dispensing).  THE  SIP  should  develop  the  backend  of  the  new  LMIS  in  a  manner  that 
expedites App development and integration (e.g. Microservices and RestAPI).  
Centralized  Database:  The  system  must  maintain  all  data  in  a  centrally  located  ODBC 
compliant RDBMS (i.e. one that is in common usage in the IT industry). The SIP must specify 
TEC018 
with which DBMS(s) their solution will operate and state preferred options. The SIP must 
specify with which platform / OS their solution will operate and state preferred options. 
Future Analytics: The DBMS must support reporting tools that have capability to access, 
TEC019 
summarize, format, and graph all data.  

4.3 Security Requirements


Table 8: List of security requirements

ID  Requirement Description 
Security Policy: The new system must comply with Government of Cambodia’s Information 
SEC001 
Security Policy 
Authorization: The system must have an authorization mechanism that is primarily based 
SEC002  around the current NATDID, HOSDID, and ODDID system authorization functions. Account 
setup should be designed to mirror the existing account setup and authorization function. 
User Access Controls: System Administrators should be able to set up and manage user 
role based access controls (RBAC) in a configurable manner. This will provide the capability 
to mix and match access to inventories and workflows to form a series of “Roles”. Users 
SEC003  can then be allocated one or more “Roles” depending on their specific needs. In general, 
all  Role  Based  Access  Controls  (RBAC)  will  flow  down  ‐  NATDID/DFF  have  global  views, 
Provinces can view hospitals and health facilities, Hospitals can view health facilities, health 
facilities can only view their own inventories. 
User  Authorizations:  In  order  to  provide  transparency  and  integrity  the  system  should 
SEC004  ensure that data needing authorization cannot be authorized by the same user that has 
input it. 

15
Passwords: Access to the system will be restricted by e user and password. All passwords 
SEC005  must be hidden when being entered for verification. Passwords held on database tables 
must be encrypted. 
System Access: Access to the system will be restricted through password protection to all 
SEC006 
layers. 
Hard Coded Passwords:  No passwords should be hard coded and there will be a process 
SEC007 
in place to enable regular changing of passwords. 
System Time Out: The system should automatically time a user out of the system after a 
SEC008  specific period of time if no activity is detected. The period of time should be defined as a 
user parameter.  
Database Access: Under no circumstances should the system allow direct user access of 
SEC009  any  kind  to  the  database.    Such  access  shall  only  be  available  to  the  application  and 
database support teams. 
Attempted  Access:  The  system  must  record  any  attempted  access  to  system  by  an 
SEC010  unauthorized user (i.e. user name and password failures). This should be in the form of a 
daily report. 

SEC011  Audit Trail: The system should record and audit system changes made by a user. 

Roles:  The  system  will  provide  for  individual  system  functions  to  be  restricted  by  role. 
SEC012  Therefore functions of a sensitive nature which are accessible to some roles, will be denied 
under specified circumstances to other roles. 

Data Security: The system should also support the need to restrict user access to groups of 
data elements. Individual users need to be aligned with a specific hospital or provinces with 
SEC013 
users only having the ability to view or assess pharmaceutical inventories in their domain. 
Viewing inventory in other provinces, hospitals or health facilities will be prohibited.  

SEC014  Data Imports: Only designated authorized staff will have permissions to upload data. 

Application  Security:    If  external,  must  link  to  security  database  via  LDAP  or  Active 
SEC015 
Directory.  

SEC016  SQL Injection: The application should be able to reject SQL injection attacks.  

Hard Coded Backdoors: Must have no hard coded backdoors – No hard coded passwords 
SEC017 
that allow override of normal security. 

SEC018  Fixed Path names: The application should have no fixed path names. 

 
SEC019  DBA Access:  The application should have no requirement for DBA level access. 
 
Patch Management: The SIP must provide the Patch management strategy (e.g., Security 
SEC020 
fixes, patches, bugs, etc.) for the LMIS system. 

16
4.4 Operational and Maintenance Requirements
Table 9: List of operational and maintenance requirements

ID  Requirement Description 
SLA  Compliance:  The  SIP  shall  ensure  compliance  to  uptime  and  performance 
requirements of the LMIS solution as indicated in the performance requirements 
OM001 
(Table X) and any changes to the software shall be planned accordingly by the LIP 
for ensuring the SLA requirements. 
Application Software Maintenance: The SIP shall address all the errors/bugs in the 
OM002  LMIS  solution  (vis‐à‐vis  the  approved  test  plan)  at  no  additional  cost  during  the 
operations and maintenance period.  
Problem Identification and Resolution: The SIP shall resolve all identified issues and 
OM003  known  problems  with  the  application  during  the  operations  and  maintenance 
period (e.g. system malfunctions, performance problems and data corruption etc.) 
Maintain Configuration Information: The SIP shall use an established Git repository 
OM004  and  configuration  and  release  tool  to  ensure  the  code  is  auditable,  and  version 
control and configuration information is maintained. 
Maintain System Documentation: The SIP will maintain and update 
documentation of the software system to ensure that: 
a. Source code for the customizations is documented 
b. Business (Functional) specifications are documented 
c. Application documentation is updated to reflect on‐going maintenance and 
OM005 
enhancements including BRS and SRS, in accordance with the defined standards 
d. User manuals & training manuals are updated to reflect on‐going 
changes/enhancements 
e. Standard practices are adopted and followed in respect of version control and 
management. 
System Monitoring: The SIP will ensure overall monitoring and management of the 
LMIS system deployed in the data center and DR site, which includes administration 
OM006  of  infrastructure  (web/application  servers,  database  servers  etc,  and  all  other 
services  ancillary  to  these  facilities  to  ensure  performance  and  availability 
requirements of the project. 
Service  Desk:  The  SIP  will  implement  a  one  year  service  desk  ‐  online  and  call 
OM007  support ‐ for advanced users to provide issue resolution support for addressing the 
issues reported by the users of the LMIS system (advanced and end users). 
System Performance, Uptime, and Security Monitoring: The SIP will provide 24x7 
OM008  monitoring  &  management  of  availability,  performance,  and  security  of  the 
infrastructure and assets of the LMIS system. 
Data  Redundancy:  The  SIP  will  ensure  that  daily  back‐up  copies  of  the  data  are 
OM009 
created and maintained safely. 
Data  Migration:  Data  for  the  existing  legacy  systems  in  the  pilot  sites  will  be 
OM010 
migrated to the new system. 
Storage and Backup: The SIP shall provide the IT Infrastructure required for storage 
OM011  and  data  backup  requirements  at  the  DC  and  DR  sites  to  include  the  necessary 
licenses, tools, software, and hardware. 

17
ID  Requirement Description 
Hosting Environment: The primary data center will be at the central medical store. 
The disaster recovery site (DR) will be located at the Department of Drugs and Food 
(DDF). Development and Testing environments can be located at the vendor site 
OM012 
but  will  be  transferred  to  the  CMS  prior  to  pilot  completion.  Any  external 
environments  to  include  cloud  service  providers  must  meet  security  and  data 
protection and privacy standards. 
Capacity Planning: The SIP must plan for capacity issues and demonstrate that the 
OM013 
environments and infrastructure are sufficient for the pilot needs of the MOH. 
Disaster Recovery: The SIP must plan for failover and continuity of operations in the 
event of a significant fail event. The system must ensure data integrity in the event 
OM014 
of  a  hardware  or  software  failure.  The  system  must  allow  for  recovery  of 
transactions in progress after a hardware or software failure. 
Data Conversion: The SIP must be able to work in parallel with other legacy systems 
OM015 
to manually move data from one system to another as required. 
Data Integration: The LMIS must be able to integrate patient registration data after 
the pilot is complete. The LMIS will authenticate a patient and integrate with the 
OM016 
"to‐be"  Health  Information  System  to  transfer  patient  macro  reference  data 
(address, birthdate, health facility etc.). 

4.5 Performance
Table 10: Performance requirements

ID  Requirement Description 
PER001  Peak Loads: The LMIS must be able to manage peak loads for critical periods 

PER002  Operating Hours: The LMIS must be available for Business Operation 5 days 
a week, 10 hours a day (7am‐5pm) 

PER003  Maintenance: LMIS maintenance and upgrades must be performed during 
out of business hours and not during critical times (e.g. quarterly and annual 
reporting periods). Maintenance strategy and approach is required from the 
SIP. 

PER004  Scalability: The LMIS must be able to increase or decrease infrastructure 
capacity based on demand 
PER005  Data Management: The SIP must provide the data management and 
storage approach of the proposed LMIS. 
PER006  Uptime: The system will have a monitored uptime of 99.9% 

PER007  Usage: The system must be able to scale up to a minimum of 200 
concurrent users with access over the Internet for the LMIS pilot phase with 
the ability to scale to 1000 concurrent users when fully deployed across the 
country. This support should occur with no less than 2 second degradation 
when fully loaded with concurrent users. 

18
4.6 Environments and Infrastructure
Table 11: Environments and Infrastructure requirements

ID  Environment  Location Pre‐Pilot  Location Post‐Pilot 


Production 
EI001 
Environment  Central Medical Store (CMS)  Central Medical Store (CMS) 
Development 
EI002 
Environment  Vendor or Cloud  Central Medical Store (CMS) 
EI003  Test Environment  Vendor or Cloud Central Medical Store (CMS)
Disaster Recovery  Department of Drugs and  Department of Drugs and Food 
EI004 
Environment  Food (DDF)  (DDF) 

NOTE: Software Vendor needs to propose the Server sizing (Server specification and quantity) for this
project on both Production environment and Disaster Recovery environment.

Table 12: Basic Hardware (Sever) Requirement

Item #  Item  Description  Quantity  Vendor 


1  Servers ‐ Hosting  Computer Servers ( Please  TBD by Software  SOFTWARE
LMIS  provide server pricing for future  vendor 
customized solution ) 
      Specific Server capcity: Need to       
provided by Software vendor to 
relevant to LMIS system within 
their proposal 
      Documentation:        
Complete User's Manual in English 
      Warranties:        
Minimum 3 Year  warranty on 
parts and services in Cambodia 
Indicate the Agency in Cambodia 
where the warranty can be 
claimed 
      Licenses: The Licences must be       
installed into the computer upon 
delivery 
Any license restrictions on multi 
use (personal, transferrable to 
other Ministries) must be clearly 
stated. 
      MS Office Integration: The system       
should meet or surpass minimum 
hardware specifications identified 
by Microsoft for hosting MS Office 
2016 Professional. 

19
      Electrical Outlet and Volts: All       
hardware must support 230 Volts 
and electrical outlets type C 
      Cambodian Legislation: The       
procurement of all items must 
comply with Cambodian legislation 
and laws. 
2  UPS ‐ for Server  Need to have 24 hours UPS supply  TBD by Software  SOFTWARE
‐ Customize solution  vendor 
      Specific requriement of USP for       
servers need address in Software 
vendor proposal 
      Documentation:        
Complete User's Manual in English 
      Warranties:        
Minimum 3 Year  warranty on 
parts and services in Cambodia 
Indicate the Agency in Cambodia 
where the warranty can be 
claimed 
      Electrical Outlet and Volts: All       
hardware must support 230 Volts 
and electrical outlets type C 
      Cambodian Legislation: The       
procurement of all items must 
comply with Cambodian legislation 
and laws. 

20
Acronyms
AMC Average Monthly Consumption
BRS Business Requirements Specifications
CENAT National Centre for Tuberculosis and Leprosy Control
CNM National Centre for Parasitology, Entomology and Malaria Control
CMS Central Medical Store
CSV Comma Separated Values (e.g. Excel)
DBA Database Administrator
DC Disaster Center
DDF Department of Drug And Food
DID Drug Information Database
DMU Data Management Unit (at NCHADS) and name of HIV Database at ART Sites
DID Drug Information Database
DR Disaster Recovery
GS1 Global Standard 1
HC Health Center
HCDID Health Center Drug Inventory Database
HOSDID Hospital Drug Inventory Database
HP Health Post
LDAP Lightweight Directory Active Protocol
LMIS Logistics Management Information System
LMIS-TWG Logistics Management Information System – Technical Working Group
MOH Ministry of Health
MOS Months of Stock
NATDID National Drug Inventory Database
NCHADS National Centre for HIV/AIDS, Dermatology and STD Control
NH National Hospital
NP National Program
OD Operational District
ODBC Open Database Connectivity
ODDID Operational District Drug Inventory Database
OEM Original Equipment Manufacturer
OS Operating System
PHD Provincial Health Department
PMRS Patient Management Registration System
PRODID Provincial Drug Inventory Database

21
PSM Procurement and Supply Chain Management
RDBMS Relational Database Management System
SDLC Systems Development Life Cycle
SDP Service Delivery Point
SLA Service Level Agreement
SIP Software Implementation Partner
SQL Structured Query Language
SRS System Requirements Specifications
UI/UX User Interface/User Experience
UNOPS United Nations Office for Project Services
USAID United States Agency for International Development
VB Visual Basic
WCO World Customs Organization
WHO World Health Organization
WMS Warehouse Management System

22
Glossary

ABC Analysis: ABC classification of medicines is based on Pareto principle. According to this, often
70-80% of the budget is spent on 10-20% of the medicines. ABC classification of annual medicine
consumption and cost determines which items account for the greatest proportion of the budget.

Batch: The quantity of a pharmaceutical produced in one production run.

Adjustments. Changes recorded when quantities of a product are issued to or received from other
facilities at the same level of the pipeline. Also, sometimes used to explain administrative corrections—
e.g., a physical stock count that is different from quantity listed on stock-keeping records.

Consumption: The rate at which items are issued to clients or patients. This is also called demand
(which is, in strict terms, the rate of requests or orders). Consumption is usually measured in terms of
units consumed within a specific period.

Consumption records. Records kept on products consumed. See also daily activity register.

Daily activity register. Record that gives the quantity of each product dispensed to a user by user
name or user number and by date. Used only at service delivery points, such as clinics, hospitals, or
community-based distributors. See also consumption records.

Dispensed-to-user data. Information on the quantity of products actually given to customers.


Sometimes referred to simply as dispensed or consumption data.

Emergency order point. The level of stock that triggers an emergency order, regardless of the timing
within the review period. It is always lower than the minimum stock level.

Essential data items. These include stock on hand, stock on order, consumption, and losses and
adjustments.

Expiry date: The date appearing on a product and established by the manufacturer beyond which the
manufacturer will not guarantee the potency, purity, uniformity, or bioavailability of the product.

Forecasting. Management function that estimates the quantities of products a program will dispense to
users for a specific period of time in the future.

Inventory: The sum of all items held in stock

Issue voucher. Transaction record that lists the items and quantities of products issued to a service
delivery point.

Lead time. The time between when new stock is ordered and when it is received and available for use.
Lead time varies depending on the system; speed of deliveries; availability and reliability of transport;
and, sometimes, weather.

23
LDAP (Lightweight Directory Access Protocol) is a software protocol for enabling anyone to
locate organizations, individuals, and other resources such as files and devices in a network, whether on
the public Internet or on a corporate intranet.

Losses. The quantity of stock removed from the pipeline for any reason other than consumption by
clients (e.g., losses, expiration, and damage). See also shrinkage.

Maximum stock level/maximum quantity. The level of stock above which inventory levels should
not rise under normal conditions.

Minimum stock level/minimum quantity. The level of stock at which actions to replenish
inventory should occur under normal circumstances.

Physical inventory. The process of counting by hand the total number of units of each commodity in a
store or health facility at any given time.

Pull system. Refers to a drug distribution system in which the personnel who receive supplies at each
peripheral facility determine the drug quantities to be requisitioned from higher levels.

Push system. Refers to a drug distribution system in which the personnel who issue the supplies at the
procurement unit or warehouse determine what drug quantities are to be issued to lower levels.

Rate of consumption. The average quantity of stock dispensed to users during a particular time
period.

Requirements. The specific things the information system must do to make the process efficient and
achieve its purpose.

Requisition. Transaction record used in a pull distribution system that lists the items and quantities
requested by a facility.

Safety stock: The buffer or minimum stock that is kept on hand to protect against stock-outs. If there
is no safety stock, stock-outs will occur when deliveries are delayed or when there is an unexpected
increase in demand. In theory, the safety stock is separate from the working stock, but in practice there
is no separation of the two, and safety stock sometimes must be issued

Shelf life. The length of time a product may be stored without affecting its usability, safety, purity, or
potency.

SQL injection: is a kind of hacking system method which allow hacker to log-in OR access into system
without knowing the username and password.

Stock card. A generic name for either an inventory control card or a bin card.

Stock on hand. The quantity of usable stock in inventory at a particular point in time. (Items that are
unusable are not considered part of stock on hand. They are considered losses to the system.)

24
Stock-keeping records. Records kept on products in storage. Also see transaction records and
consumption records.

Stores ledger. A stock-keeping record that keeps information about all lots of a product. Often
referred to as a Stock Ledger.

Systems Development Life Cycle (SDLC). A conceptual model that describes the stages involved
in an information system or software development project, from an initial feasibility study through
maintenance and close-out.

Transaction records. Records kept on products being moved from one facility to another. Also see
stock-keeping records and consumption records.

Universal Product Code (UPC). A generic term that refers to the GTIN-12, Coupon-12, RCN-12,
or VMN-12 encoded in a UPC-A or UPC-E barcode symbol.

VEN system: A system of setting priorities for purchasing pharmaceuticals and keeping stocks in which
medicines are divided according to their health impact into vital, essential, and nonessential categories.

25
References
- PATH Common Requirements for Logistics Management Information Systems, Seattle: PATH;
2010
- MOH LMIS Technical Working Group, 4th meeting minutes
- The supply Chain Manager’s Handbook: A Practical Guide the Management of Health
Commodities, JSI, 2017
- Guidelines for Implementing Computerized Logistics Management Information Systems (LMIS)
Second Edition, USAID1DELIVER
- Managing Access to Medicines and Health Technologies, Managements Sciences for Health
- Building Blocks for Logistics System Design for HIV tests and ARV drugs, Inventory Control
Systems, Logistics Management Information System, and Storage and Distribution,
USAID1DELIVER
- Cambodia Logistics Management Information System, Feasibility Study on Options to Strengthen
Cambodia’s Health Products LMIS, 2016, USAID, PERFAR and WHO

Annex
8.1 Annex 1 ‐ Information of the Legacy LMIS
Annex 1 – Information of the Legacy LMIS is about what is the architectures of current system (Legacy
LMIS) look like. For more details, please see the annex 1 file.

26

You might also like