Professional Documents
Culture Documents
Section II - Schedule of Requirements - TOR Strengthened LMIS PDF
Section II - Schedule of Requirements - TOR Strengthened LMIS PDF
Section II - Schedule of Requirements - TOR Strengthened LMIS PDF
REQUIREMENTS
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:
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.
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.
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)
‐ Product classification √ by program (HIV, TB, √ by program (HIV, √ by program (HIV, √ by program (HIV,
Malaria) TB, Malaria) TB, Malaria) TB, Malaria)
5
2.2 Proposed Enhancements to existing systems
The Strengthened LMIS (option 4) includes the following functional and system improvements and
enhancements:
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.
6
2.3 Product and facility data
2.3.1 Product data
Legacy Enhancements:
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)
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.
8
Table 2: Functional Requirements of the Strengthened LMIS
INV2 Requesting/Ordering LL LL LL LL LL
INV3 Receiving LL LL LL LL EL
‐ Product classification by LL LL LL LL EL
program
INV5 Dispatch LL EL EL - -
INV6 Transport EL LL EL EL -
INV7 Dispensing - - - EL EL
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.
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.
3.3 Reports
The LMIS should generate important reports listed in Table 4.
10
Table 4: Reports requirements
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.
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.
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.
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
NOTE: Software Vendor needs to propose the Server sizing (Server specification and quantity) for this
project on both Production environment and Disaster Recovery environment.
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.
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.
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.
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