Accounts Receivable Excel 3D Pie Chart by grk13224

VIEWS: 400 PAGES: 88

More Info
									         Guidelines to Decisions on
        Computerised Drug Management
             Information Systems

               A practical manual

DRAFT                               04-12-10
                              Guidelines to Decisions on Computerised Drug Management Information Systems

                                    TABLE OF CONTENTS

CHAPTER 1 ........................................................................................................................................... 1

INTRODUCTION .................................................................................................................................. 1
   1.1   BACKGROUND TO MANUAL ....................................................................................................... 1
   1.2 AIM OF THE MANUAL .................................................................................................................... 1
   1.3   WHO CAN BENEFIT FROM THIS MANUAL .................................................................................... 2
CHAPTER 2 ........................................................................................................................................... 3

DRUG MANAGEMENT INFORMATION SYSTEMS (DMIS) ....................................................... 3
   2.1        DRUG MANAGEMENT CYCLE .................................................................................................... 3
   2.2        CORE PRINCIPLES OF DRUG MANAGEMENT INFORMATION SYSTEMS ....................................... 4
CHAPTER 3 ........................................................................................................................................... 5

PROCESS IN SELECTING A DMIS ................................................................................................... 5
   3.1    UNDERSTAND YOUR BUSINESS .................................................................................................. 5
   3.2    IDENTIFY YOUR REQUIREMENTS ................................................................................................ 6
   3.3    SCOPE OF PRODUCT ................................................................................................................... 8
   3.4    WEIGHT THE REQUIREMENTS AS A MODEL FOR EVALUATION .................................................... 9
   3.5    BUDGET LIMITATIONS ............................................................................................................. 10
   3.6    COST OF THE PACKAGE ........................................................................................................... 11
      3.61 Software .............................................................................................................................. 11
      3.62 Additional hardware and installations ............................................................................... 12
      3.63 Training .............................................................................................................................. 12
      3.64 Recurrent budget for maintenance, upgrades, technical support. ...................................... 13
      3.65 Project management consultancy ....................................................................................... 14
   3.7    HOW TO APPROACH THE SUPPLIER.......................................................................................... 15
CHAPTER 4 ......................................................................................................................................... 17

EVALUATION ..................................................................................................................................... 17
   4.1        DESK STUDY ........................................................................................................................... 17
   4.2        DIALOGUE WITH SUPPLIERS / NEGOTIATION ............................................................................ 18
   4.3        COST / BENEFIT/ IMPACT ANALYSIS ......................................................................................... 19
CHAPTER 5 ......................................................................................................................................... 20

IMPLEMENTATION .......................................................................................................................... 20
   5.1        DEFINE ORGANISATION OF IMPLEMENTATION ........................................................................ 20
   5.2        MONITORING AND EVALUATION .............................................................................................. 21
APPENDICES ...................................................................................................................................... 22
   APPENDIX 1 ......................................................................................................................................... 23
   FLOW DIAGRAM OF PROCESSES IN THE DRUG MANAGEMENT CYCLE.................................................... 23
   APPENDIX 2 ......................................................................................................................................... 25
   FEATURES AND FUNCTIONS OF AN IDEAL DMIS SYSTEM .................................................................... 25
   APPENDIX 3 ......................................................................................................................................... 27
   REQUIREMENTS FOR A DMIS .............................................................................................................. 27
   A) GENERAL FEATURES ....................................................................................................................... 27

 B) PHARMACEUTICAL FUNCTIONS ....................................................................................................... 29
 C) BUSINESS SYSTEM FUNCTIONS ....................................................................................................... 38
 D) INFORMATION TECHNOLOGY FUNCTIONS ...................................................................................... 43
 APPENDIX 4 ......................................................................................................................................... 48
 EXAMPLE OF A GENERIC QUESTIONNAIRE............................................................................................ 48
 APPENDIX 5 MODULES INCLUDED IN THE SELECTED SOFTWARE SYSTEMS ...................................... 57
 APPENDIX 6 ......................................................................................................................................... 58
 ADDRESSES AND FACT SHEET ON SELECTED SUPPLIERS....................................................................... 58
 APPENDIX 7 ......................................................................................................................................... 68
 GENERIC CHECKLIST FOR DMIS SYSTEMS (FROM QUESTIONNAIRE) .................................................... 68
 APPENDIX 8 ......................................................................................................................................... 70
 SAMPLE OF WEIGHTING REQUIREMENTS .............................................................................................. 70
 APPENDIX 9 ......................................................................................................................................... 71

DRAFT                                                                                                                                                 ii
                Guidelines to Decisions on Computerised Drug Management Information Systems


AMC            Average Monthly Consumption
AP             Accounts Payable
AR             Accounts Receivable
ASCII          American Standard Codes for Information Interchange
CIF            Cost, Insurance and Freight
DMIS           Drug Management Information System
EIS            Executive Information System
FAMS           Financial and Administrative Information System
FMIS           Financial Management Information System
FOB            Free on board
FSD            Fast moving, slow moving or “dead”
IT             Information Technology
LAN            Local Area Network
MIS            Management Information System
NGO            Non Governmental Organisation
ODBC           Open Data Base Connectivity
OS             Operating System
PG             Project Group
QA             Quality Assurance
SC             Steering Committee
UNICEF         United Nations Children‟s Fund
VAT            Value Added Tax
VEN-analysis   Vital, Essential and Non-essential categories
WAN            Wide Area Network
Y2K            Year 2000

DRAFT                                                                                    3
                                                                            Chapter 1: Introduction



1.1       Background to manual

WHO have been contacted on many occasions with the following question….. .``We
want to computerise our inventory and procurement systems, can you tell us how do
go about it. What sort of Drug Management Information System (DMIS) is required,
which particular system should be selected, where can it be obtained from and how
much will it cost ´´.

The response to this request is highly contextual, there is no one answer that would be
appropriate for all situations, but there is a more standard approach that can be used in
addressing these questions and that is the focus of this manual. This standard
approach can be used at all levels, at the district, regional or national level.

1.2       Aim of the manual

Managers are often faced with a need to improve organisational performance. The
demand for timely, accurate and appropriate information in order to take effective
decisions is crucial in improving efficiency. This may be through computerisation or
in setting up or improving manual systems. This publication assumes that basic
conditions that support computerisation are already being met in organisations
considering introducing a DMIS1, i.e. efficient existing manual systems, and essential
reqirements to support the use of computers in any organisation.

The aim of this manual is to provide management with some assistance in the decision
making processes towards the selection, evaluation and implementation of a
computerised DMIS. It will follow a logical step wise approach in addressing this
issue. A summary of each stage will be made together with recommendations, and
where appropriate, experiences from developing countries will be included. Many
countries have already gone through this process, some may be considering it and
others may want to improve what is in existence. It is useful to learn from their

In Chapter Two the concept of DMIS is further elaborated.

    Refer to Chapter 46 of the MSH/WHO manual on Managing Drug Supply (2 nd edition)

DRAFT                                                                                             1
                                                                   Chapter 1: Introduction

Chapter Three will allow managers to examine and describe what is required from a
DMIS. Having defined their needs, the issues of costs will be considered followed by
how to approach prospective suppliers of DMIS.

The process of evaluation will be discussed in Chapter Four describing how a number
of systems can be compared with the organisation‟s requirements through a scoring
and weighting system.

Fnally Chapter Five will draw attention to key issues which need to be taken up
during the implemention of any DMIS.

1.3     Who can benefit from this manual
The target audience for this manual are managers of drug supply and management
systems in the public, semi-public and private sectors of developing countries. They
may operate in institutions/organisations at different levels (national, central and
district) within a particular country.

The scope of manual is not to promote any particular system, i.e. it will not instruct
readers in any one particular software or make recommendations for the purchase of a
specific piece of hardware or software. Instead, the manual will highlight major
criteria that can be used in the process of selection, evaluation and implementation. It
will provide some information on some systems that are available, both commerically
and non-commercially. However, these are by no means the only systems available
and each country will need to carry out their own market research on available
systems. Also the criteria used for selection, evaluation and implementation are those
of the authors, those in the field may select different criteria to suit their own

The selected system will be based on the particular requirements, environment and
constraints that individual managers are confronted with in a particular

DRAFT                                                                                    2
                                           Chapter 2: Drug Management Information Systems



2.1     Drug Management Cycle
Any drug management cycle will include four basic functions: selection, procurement,
distribution and use of drugs (Figure 1).


                               Management support systems


                                       Storage &

Fig. 1 Drug Management Cycle

At the centre of the drug management cycle is a core of management support systems:
organisation, financing, information management and human resource management.
These management support systems hold the drug management cycle together. It is
improtant to note that there are linkages between the support systems and the drug
management cycle and that any weak link in any of these areas will ultimately affect
the availability, accessibility and affordability of drugs.

DRAFT                                                                                  3
                                          Chapter 2: Drug Management Information Systems

This manual will focus on DMIS systems required for organisations whose main
functions involve procurement, storage and distribution. However, although there is a
focus on the latter functions the same DMIS system can also support the other
functions of the drug management cycle, namely use and selection, e.g. with an ABC

Procurement involves the quantification of drug needs, selecting procurement
methods, establishing contract terms, and assuring drug quality and adherence to
contract terms. Storage involves functions such as inventory control and store
management whilst distribution involves clearing customs, collection of consignments
delivered by air/sea/road and delivery to drug depots and health facilities.

2.2     Core Principles          of    Drug     Management            Information

A Drug Management Information System (DMIS) is an organised system for
collecting, processing, reporting and using information in decision-making within the
context of drugs and medical supplies. Access to reliable information is one of the
most important management tools. The build-up of an effective DMIS is important in
the process of managing a drug distribution chain, to ensure that available and
affordable drugs are purchased and distributed in a timely and cost-effective way.

The focus of a DMIS is on the flow of goods from different locations. This means that
there is a focus on purchase/receipt, inventory control and on sale/distribution of
drugs. Supplier and customer databases are required to handle these transactions,
including the need to handle both the quantities of drugs being moved throughout the
system and the value of the drugs. Thus, financial control becomes important in
tracking drugs from the point of purchase, through storage to the point of sale.
Appendix 1 highlights some of the major steps in the process of drug procurement,
storage and distribution.

This report focuses on Drug Management Information Systems in the following areas:
procurement, storage (inventory control and store management) and distribution
including sales. This means that the system is an amalgamation of drug management,
inventory control, purchase and sales, and financial management information systems.
Additional supporting systems can include transport management (as a support to
sales) and human resource management (as a support to general organisational
management). An ideal DMIS system, a „benchmark‟ providing information on all
major business operations is described in Appendix 2.

DRAFT                                                                                 4
                             Appendix 3: A checklist of features and functions of an ‟ideal‟ DMIS



3.1     Understand your business

It is important to gain an intimate knowledge of the major operations of the
organisation, the processes and tasks that need to be performed to carry out the
business objectives of the organisation. This process will involve a thorough analysis
of what is currently in place, where there are problems or shortcomings, why they
exist and where improvements are required. It will also involve obtaining detailed
knowledge of how the organisation‟s DMIS is currently operating, if functioning well
or poorly, whether there are manual systems in place and whether these are
documented as standard operating procedures (SOP).

The next stage is to develop an Information Technology (IT) strategy. It will guide the
organisation in defining what kind IT infrastructure is required to be in place/replaced
to support the business in general terms. The DMIS system may handle inventory but
may require a supporting system, e.g. financial system to manage the accounts. Thus,
an IT strategy should link the different functions of the organisation, so that the
introduction of any computerised system into any business area is more uniform, and
therefore more easy to support.

The IT strategy will also consider three main points:
 distribution
 boundaries and
 levels of functionality

Some medical stores can comprise a head office and multiple warehouses based in
different regional areas. A decision will be required whether to have a centralised
system, where data are consolidated from the distributed offices, which would
require good communication links or whether to have autonomous regional offices,
each with its own complete system. Centralising or distributing systems has an
important impact on management organisation and structure and on the
implementation of any system

The introduction of any computerised system will have certain boundaries that will be
dependent on the options selected and also on the human-computer levels available.
The latter involves the skills and level of ability of staff within the organisation which
may create boundaries on the type of system selected.

DRAFT                                                                                          5
                             Appendix 3: A checklist of features and functions of an ‟ideal‟ DMIS

Finally, computer systems support the operations of the business, thus the level of
support that a new/revised system should provide should also be determined. This can
be defined in terms of functionality and the level of functionality required from any
system. This will be discussed further in Section 3.2.

At the end of this stage all the major business processes will have been analysed and
an IT strategy developed. At this stage it is important to make a decision whether to
look at all areas requiring improvement or to focus in on specific areas, i.e. to
computerise finance and accounts ahead of inventory control, procurement, human
resource management or transport.

Recommend: Look at all major processes in a holistic manner, but try to prioritise in
particular areas as it may not be realistic to computerise all areas at once.

The main focus in Zimbabwe, Government Medical Stores was to introduce a
computerised system for inventory control and procurement (INVEC-2) before a
computerised financial system. However, the emphasis in Tanzania’s Medical Stores
Department focused on a computerised financial system (Navision) ahead of a system
for inventory control and procurement. Both of these countries are now reviewing
their existing systems as neither system provides them with the full functionality that
they require.

3.2     Identify your requirements
After developing an IT strategy, and deciding to focus on a specific area, there is a
need to identify the requirements that a system should provide, i.e. the features or
facilities that are desired from any system. Requirements may be those that will
resolve or reduce the problems in an existing system, and those that are new
functional abilities which the current system cannot provide.

Requirements are divided here into four main areas of functionality and described
briefly in this section and in detail in Appendix 3:

   Pharmaceutical
   Business System
   IT Specific
   General

Under the pharmaceutical, business and IT specifications the terminology ‟essential‟
and ‟desirable‟ are introduced. Essential functions are those, which in the opinion of
the authors, are considered as the basic requirements for the organisation to carry out
its major busines processess in an optimal manner. The desirable features are those
which are not considered as essential, as the organisation can function without them,
however their inclusion would improve the overall efficiency of the organisation. The
classifications of essential and desirable are contextual and will differ according to the
size of the organisation, its environment and its functions. A checklist of features and
functions of an ideal DMIS are provided overleaf.

DRAFT                                                                                          6
                                        Appendix 3: A checklist of features and functions of an ‟ideal‟ DMIS

                                             What do you need?

A checklist of features and functions of the “ideal” DMIS

PHARMACEUTICAL CRITERIA                                    BUSINESS CRITERIA

Logistic forecasting                                       Finance module
                                                           23. Accounting dimensions
1.    Drug/budget needs forecasting
                                                           24. Audit trial
2.    ABC analysis
                                                           25. Budgets
                                                           26. VAT support
Distribution/dispensing drugs
                                                           27. Reports
3. Therapeutic category analysis
                                                           Accounts payable
Tender processing module                                   28. Supplier database
4.    Tender request report                                29. Integration
1.    Adjudication report                                  30. Reporting
2.    Supplier performance monitoring report
3.    Tender awards list                                   Accounts receivable
                                                           31. Customer database
Procurement management                                     32. Integration
7.  Purchase order generating                              33. Reporting
8.  Calculation of minimum stock                           34. VAT calculation
9.  Out of stock report
10. Currency conversion and adjustment for trade
                                                           35. Previewing reports
11. Order status report
                                                           36. Selection criteria
                                                           37. Sorting criteria
Inventory management
12.   Receiving report                                     IT CRITERIA
13.   Quality assurance record
14.   Product list with specifications
15.   Updating inventory databases                         Technical hardware information
                                                           38. Operation system
16.   Stock detail report
                                                           39. Data entry
17.   Inventory adjustment report
                                                           40. Printing facilities
18.   Expiry stock report
                                                           41. Network/Scalability
19.   Expiry date analysis or expiry risk report
20.   Stock control performance indicators
                                                           Technical system information
Sales and distribution module                              42. System base/Adaptability
21. Picking list - Functional list                         43. Compatibility and capacity
22. Return goods handling                                  44. Size of entries
23. Stock allocation by expiry date & batch traceability
                                                           System/ Data security
                                                           45. User ID and passwords
                                                           46. User access control
                                                           47. Year 2000 Compliance

DRAFT                                                                                                     7
                                                                       Chapter 4: Evaluation


Specific pharmaceutical functions are related to logistical forecasting, tender
management, purchase order, sales order, distribution and inventory modules are
described. Points of interest for the purpose of managing pharmaceuticals and medical
supplies are for example the capability of handling batch numbers, expiry dates, long
product names, traceability of products to suppliers and batch specific quality entry. It
is important to consider not only functions that are required at the current time but
also those that may be required in the future, with the development of the
organisation, e.g. bar coding, print bar code labels, internet electronic commerce, etc.

Business System

Business system functions include: finance, accounts management, the generation of
reports, human resource management and transport management. The requirements
for business functions in a DMIS system do not differ from requirements for business
modules in most other systems. As in other settings, the need for flexibility in report
generation output will be essential. Likewise the systems capabilities of providing
standard reports and options for outlining own reports.

IT Specific

IT specific characteristics are related to technical requirements, hardware, system
environment, disaster recovery, data security, integrity and compatibility with other
software in other local offices with which the system interfaces, data input and
transfer of existing data into a new system.


General requirements are related to issues such as the supplier, training and future
developments. Of particular interest to those in developing countries are those
suppliers with experience of their systems in these countries, the possibility of local
support and the type of layout and language on screens and reports.

3.3     Scope of product
Obtaining one system which could fulfill all the organisations‟s requirements would
be an ideal solution, but it may not always be possible, at least not to the level of
functionality that is desired. Here one may need to consider the advantages
/disadvantages of having:

   a single product which fullfills all requirements, to a lower level of functionality,
   separate products/modules for different requirements, e.g. for finance and
    inventory control,

DRAFT                                                                                     8
                                                                       Chapter 4: Evaluation

   two integrated systems, e.g. one for drug management /inventory control and a
    second for financial management.

With pharmaceuticals, some basic core functionality is required: stock management,
accounting, customer sales, procurement, management of tenders; and perhaps others,
human resource management, transport management, and so on. All this functionality
may not be found in one product, but the total solution could be obtained from
combining a number of different products together. Similarly, some components
within a product may be very good, whilst other components may be weak. It may be
possible to combine the strong components from different suppliers to make up the
whole system.

However, the disadvantage in combining components from different sources is the
greater risk for something to go wrong. If the system purchased is a single product,
then at least it is known that the components do function together. Pulling together the
best performing system from multiple products is always a balance between need and
risk. If a solution can be accepted from as few products as possible, this will reduce
the complexity of the final system.

In some cases there may be no choice other than to accept a combination of different
products as the solution. Therefore, issues of compatibility and performance must be
ensured between these products to a level that covers all the organisation‟s
eventualities. In any case, this option will require considerable and thorough
investigation and testing, such as investigations of other organisations carrying out
similar combinations, and whether vendors are prepared to offer guarantees that the
combined solution will perform to the organisations‟ expectations.

Finally the enviroment in which the organisation is operating is important as this will
decide what type of system and combinations of systems are required, single site /
single user, single site / mulitiple users, multiple sites / single user, multiple sites /
multiple users.

Recommend: Ensure participation in all stages, the more that staff are involved from
the very early stages in the decision making processes, the more empowered they will
be and the more sustainable the whole process will become.

User examples

3.4     Weight the requirements as a model for evaluation
From Section 3.2 a list of requirements will have been generated which should form
the basis of an ideal system. These requirements can be submitted to a range of
suppliers in a common manner and is discussed further in Section 3.8. However,
before this is carried out there is a need to look at the requirements and decide what
aspects are more important than others and then to weigh them in terms of
importance. It is important to carry out this step at this stage as it will form the basis
of the evaluation process, discussed further in Chapter 4.

DRAFT                                                                                     9
                                                                     Chapter 4: Evaluation

There are various methods for weighting preferences, one example is provided in
Appendices 8 and 9.

Note: Weighting future requirements may not be considered to be of high status at the
current time but should be included in the evaluation process to determine how the
various packages might meet these requirements in the future.


User examples


3.5     Budget limitations
Budget limitations will guide what options an orgnisation has in terms of procuring a
commerical or non-commercial system, develop an in-house system or abandoning
the project. The costs of the entire operation need to be considered here, not only that
of the software (see Section 3.6). It is important to have some idea of the funds
available and the prices of the systems, and other related costs, even at this early

All commnercial systems are built to satisfy as wide a range of customers as possible,
the more a system can be developed to meet everyone‟s needs the more that system
will cost.

Any financial gap between the needs of the organisations and resources to meet those
needs will need to be addressed, and options considered, i.e. look for other sponsors,
phase any implementation plan with for example inventory control aspects before
financial, downscale the whole programme, abandon.


User examples: Malawi, Mali, Rwanda, Nepal, West Africa – all developed their own
systems, Zimbabwe, Yemen, Cambodia Tanzania and Uganda all used commercial
packages. At various stages all used external expertise to either advise, develop,
install and/or implement their systems.

User examples: Cost of INVEC in Yemen and Zimbabwe.

Total implementation costs for INVEC-2 in Yemen, in 1996, was estimated as
approximately UD$ 20,000. This involved ? number of sites, number of users per site,
using inventory and procurement modiules.

In Zimbabwe, in 199?, for a more integrated system of INVEC-2 the total
implementation costs amounted to approximately UD$ 640,000. Procurement and

DRAFT                                                                                  10
                                                                     Chapter 4: Evaluation

inventory control modules were used. INVEC-2 was installed in 7 different locations
(1 headquarters with 25 users, 2 regional stores with 16 users each, 4 provincial
stores with 6 users each). The costs were only for the software and did not include:
the network, new servers, training, implementation and support.

Tanzania Medical Stores Department are currently (in 1999) investigating the cost of
a package that will provide them with ’all’ their needs, Business, Pharmaceutical,
Transport, and HRM and include costs for installation and training. Their annual
turnover is equivalent to USD          . Installations will be required in Dar the
headquarters and 8 Zonal stores in different locations around the country. Data will
be consolidated on a regular basis at Dar. The funds currently allocated to this
project are UDS 0.5 million. This does not include hardware.

3.6      Cost of the Package
When considering the entire costs of the package, all the following should be

   software,
   additional hardware and installations
   training
   recurrent budget for maintenance, upgrades, technical support
   management consultancy

At this stage it may also be useful to consider the costs of developing an in-house
system or procuring a commercial or non-commercial package, and the advantages
and disadvantges that both would confer.

3.61     Software

Pricing of software is extremely difficult, it is multifacted and the way in which
companies price their products varies enormously. The licence is normally based on
number of users, locations and modules

             Table: Licence details of selected software systems ERIK

System                Software              Licences based on       Modules
                                            concurrent users or
                                            named users
CLM Ver.2.06          Free
Concorde XAL          Prices available
Ver. 2.65
Gemedic Dos Ver       Free

DRAFT                                                                                  11
                                                                     Chapter 4: Evaluation

INVEC-2 Ver 1.5        Free
Navision Financial     Prices available
Ver 1.3                based on c-shells
                       per granule
SAP R/3 Ver 4.0A       Get prices
Sun Systems Ver        Get prices
Nepal system           Free
Lawson                 Prices available

Licences are often divided into two types, those which involve ‟concurent users‟ and
those which involve ‟named users‟. Concurrent users require less user licences, are
more flexible and ensure a high level of accountability, i.e. for the audit trail.

For named users, individual licences have to be purchased for each user. This can
result in users sharing passwords and is ulitmately less accountable.

Note with non-commercial systems where the software is free, what recall does an
organisation have if the supplier is not performing well? It is important that even with
‟free‟ software, a contract is drawn up with the supplier, covering all the issues of
contractual oblgations.

Include price comparison of the different suppliers by providing 2 scenarios of 2
different situations in orde to compare prices. ERIK to action. VR to circulate and
obtain feedback.

Recommend: Depending on the number of users in any location, it is probably better
to purchase licences for concurrent users rather than named users.

User example:

3.62    Additional hardware and installations

Apart from the hardware requirements, it could be expected that any DMIS used
would be carried out in a multi-user environment. This may be in the form of a WAN
or one or more LANs. Thus, there is a requirement that the DMIS is capable of
handling a network installation and large amounts of data, which are input from a
number of locations. Communication using the Internet or other data communication
would also be an advantage - both for data entry and extraction. This sets some
minimum requirements for hardware and response times, including an operating
system which can handle network installations

3.63    Training

Training can be split into three areas:

DRAFT                                                                                  12
                                                                      Chapter 4: Evaluation

    Training to use the new system
    Training to use peripheral applications (word-processing, spreadsheets, etc
    Technical training in supporting the new system and the network

Apart from the costs of training staff in the first two categories it is important to
consider the costs of training selected staff within the organisation, as technical staff
to provide front-line support. This will ensure that the organisation gradually becomes
more independent and only refers to the suppliers in difficult situations.

User example: Total implementation costs for INVEC-2 in Yemen, in 1996, was
estimated as approximately UD$ 20,000. This involved ? number of sites, number of
users per site, using inventory and procurement modiules.

In 1999, further training was required on the implementaiotn of INVEC-2 in
invoicing, the costs for 2 weeks of technical support from MSH Washington
amounted to USD ?

3.64    Recurrent budget for maintenance, upgrades, technical support.

    Maintenance

Maintenance plans will add to the overall and continous costs, but they are a matter of
negotiation and can make repairs and replacements cheaper in the long term.

Costs of hardware failure in terms of the cost of repair as well as the time and effort
involved and the overall cost to the business (loss of business) should be considered.

Some form of continued assistance may be required from the supplier, once a system
is installed, as the process of integration and change is likely to continue beyond the
terms of the intial contract to supply and install, these csts should also be considered.

Annual maintenance fee for the software licence-- erik

    Technical support

The issue of technical support, whether this is local, regional or international is
extremely important, as it is likely that there will be many reasons to contact the
supplier: business issues, implementation issues, technical queries, modifications,
unfrosen problems…..and so on. Although electronic communication channels are
improving, there is often a need to have local support close at hand. This means that
the choice of supplier is based on its ability to provide good local support. In order to
ensure that a supplier can deliver it is important to consider the following:

1.      The size and composition of the supplier
2.      Number of staff , number involved in product support, technical support,
        where these staff are based
3.      Qualifications of staff

DRAFT                                                                                   13
                                                                    Chapter 4: Evaluation

4.      Are they accreddited with any international organisations
5.      What kind of support do they offer.

    Future upgrades

Whether an in-house system is built or a commercial or non-commercial system is
procured, there will always be a question of future upgrades. Questions to consider
here are:

1.      Is the manufacturer of the system investing in new functionality?
2.      Will technical support be provided for a product that customers are no longer
3.      Transfer/convertsion of data from an existing system to an upgraded version
4.      Suppport and maintenance of upgrades. Note the more changes that are made
        to a standard package, i.e. customised to the need of the organisation, the
        increase in the costs in the long term of future upgrades. Everything depends
        on the quality of the original standard package.

Recommend: Upgrades are more probable where there is a high demand for a system,
which is supported by an organisation committed to maintaining state of the art
technology. The programming language of the system will offer some indication of the
organisations commitment, if it is an obscure language there is a high probability that
the manufacturer will not be able to maintain it.

User example: Uganda NMS and JMS have customided Navision DOS, a fianancial
system to their needs in order to handle pharmaceuticals. Navision Financials
Version 1.3 is an updated form of the programme in a Windows version, what do
Uganda do? Changing from their DOS version to Windows version may require more
funds, can their customised programme be replaced by the Windows version without
loss of their functionality?.

’Swedis’ was a DMIS system developed in Sweden and implemented in. Botswana.
Technical support for the system was only provided from Sweden. The developer of
the system, Pharmasoft are apparently no longer providing technical support, what
does this mean for Botswana?

INVEC-2 is currently DOS based, MSH are considering changing it to a Windows
version, what is the situation for the countries who have invested in the DOS
programme? What are the costs involved?

3.65    Project management consultancy

This question could be raised at the start of this manual but has been included in this
section as it has a cost implication. Selecting and evaluating computerised DMIS
involves considerable technical knowledge and expertise, if there is insufficient
capacity within organisation to undertake this process, a third party will need to be

DRAFT                                                                                 14
                                                                       Chapter 4: Evaluation

required. The costs of recruiting the third party who may be local, regional or
international, even if only to undertake certain aspects of this process, need to be
considered with the overall costs of computerisation.

User examples: Do it yourself or get external expertise.Examples of costs for external
assistance in selecting and evaluating software systems:

Tanzania MSD (Coopers and Lybrand)
Yemen (Cranfield)
Cambodia (MSH)
Malawi (expatriate working in medical stores).


3.7     How to Approach the Supplier
At this stage a small market research exercise is required to determine what systems
are available. Contact addresses are given for some systems described in this
publication (Appendix 6) but they are by no means the only suppliers and it is
advisable to look at what systems are available locally and internationally which
would meet the organisation‟s requirements.

Once requirements have been identified, the next step is to decide how to approach
the supplier. If it is by tender, will it be openly advertised or restricted to a selected
list of suppliers.

When evaluating different systems it is important to have a method by which all the
systems can be compared in a uniform manner. Having the findings in a common
format will make it easier to explain or promote the final decsion to senior
management or other project stakeholders. The responses from suppliers will never be
in the same format unless a common reply structure / format is selected. It is
important that the organisation take some time in preparing this presentation and the
detail of questions required to ensure a successful implementation so that suppliers are
clear on what they are expected to supply. The questionnaire in Appendix 4 may offer
some guidance together with the information in Appendix 3 on requirements and
supplier information.

Some further issues to consider in the tender document could include the following:

1.      Template for the proposal to obtain a uniform answer that will help in the
        evaluation process.
2.      System demonstration, using the organisations own test data so that staff can
        relate to the reports and screens. This may also indicate how easy it is to
        transfer data from any existing system to the new system.

DRAFT                                                                                    15
                                                                      Chapter 4: Evaluation

3.      Site visits (references of other users).
4.      Contract (wording) should stipulate what the client expects to be delivered,
        how and when, etc. This also applies to what is expected from the supplier in
        terms of their performance, i.e. what, when and how the supply is undertaken.
5.      Ask suppliers to present their software in written form or as a presentation. Let
        them come up with estimates.


User example: From zimbabwe - ERIK

DRAFT                                                                                   16
                                                                     Chapter 4: Evaluation



4.1     Desk Study
The evaluation process can take considerable time if carried out properly. It is
important that it is fair and transparent process.

From Section 3.2 requirements will have been identified for an ideal system. Each of
the responses needs to be evaluated and scored against the ideal system. Guidelines
should be provided on how to evaluate, what criteria are used and if any weighting of
responses is undertaken according to importance or bias (see Appendix 8). At this
stage the evaluation should only consist of a desk study, demonstrations and site visit
should only be undertaken after this stage is complete.

The evaluation process will include strengths and weakneses of each system and how
these interface with other systems and will also include an evaluation of the supplier.

One point of concern may be the issue of customisation. If one supplier states this is
possible and another claims that it is not possible, how is this evaluated?. ERIK


User example: Zimbabwe Medical Stores

In 1997 it was considered that INVEC-2 could not meet all the accounting
requirements of the Medical Store and a search was carried out for a system that
could provide both procurement / inventory control attributes as well as accounting
needs. Three systems were shortlisted, Navision Financials, SunSystems and MFG
Pro. A major reason for shortlisting these companies were the issue of local support
in Zimbabwe or the region and the fact that the systems were commercially
available.This latter point was considered important for two reasons. Firstly that a
sufficient pool of qualified personnel would be available to provide implementation
and technical support when required by the client. Secondly that upgrades were
more likely to be developed by commercial systems than non-commercial systems,
ensuring a future commitment in terms of software.

The staff in Zimbabwe looked at their requirements, weighted them and then
evaluated each of the systems against the weighted requirements. In their context
Navision Financials met most of their requirements (utilising a customised version
which was being developed in Uganda that would incorporate inventory and
procurement aspects).

DRAFT                                                                                    17
                                                                     Chapter 4: Evaluation

Next the functionality of the systems were compared against the prices of the systems,
a cost/benefit analysis. The range of the prices were from 7 –10 million Zimbabwe
dollars (1US$ = ? Zimbabwe $).

What was the result? That none of the systems were used due to financial problems.
Instead a short-term solution was required and a simple accounting package was
procured that could meet the basic accounting needs.

4.2     Dialogue with suppliers / negotiation
Once a shortlist has been developed from the previous section, demonstrations of
systems and field visits to reference sites can be undertaken.

It is unlikely that any single system can provide an organisations with all its
requirements within its resource envelope, for example, a particular system may cover
80% of the organisations requirements, what decision is taken about the remaining
20% that cannot be covered by the system. There is therefore a need to undertake a
dialogue / negotiation with the supplier. Does the organisation have the capacity to
handle these negotiatians? Discussions with suppliers will provide some information
on their potential to perform, but it is important to have staff involved who understand
the technical issues and can provide feedback to senior management.

Some of the questions that can be addressed to the suppliers could include the

   can the system be customised towards ones needs
   will the customisation affect future upgrades
   can the system interface with other standard packages, i.e. Excel, Access, etc.
   if system does not provide all the organisations requirements, can one forget about
    the 20% and use manual procedures
   will upgrades in the future cover the outstanding 20%

Various options will arise from the evaluation process, all these options will have cost
/benefit/impact implications. These are discussed further in the next section.

Recommend: A brief estimation

If package provides< 60% of needs, abandon and develop own system.
If package provides > 80% of needs, think about it but consider what to do about
remaining 20%.
It package provides between 60-80% of needs, consider customising the package or
developing own system.

User examples: Cost benefit analysis in Zimbabwe

DRAFT                                                                                  18
                                                                       Chapter 4: Evaluation

4.3     Cost / benefit/ impact analysis
A cost/benefit analysis seeks to measure the total costs of the new system against the
total expected benefits to be gained. In theory, it is a means of qualifying justification
for a new system. In practice, “total costs” can be difficult to measure as they include
tangible and intangible costs. Tangible costs are where a direct financial cost can be
attributed. It can be the purchase of an item or a service; the costs saved in displacing
staff either to perform other duties or being made redundant; or freeing up more time
to be able to perform a new business activity. Intangible costs are where no accurate
figures can be provided, for example improved customer perception of our
organisation‟s performance. Such costs can be difficult to quantify and be realistic.
There are many ways of performing a cost/benefit analysis, each as difficult to do
properly as the other, and each as much criticised as the other. However, the analysis
can provide an indicator of justification if we have the time and resources to carry it
out. Example purchase costs are hardware and software, upgrades, network
implementation, system implementation, user training. Example operating costs are
consumable items, and resources to operate and support the new system.

An impact analysis measures the effects the new system may have upon our user
environment. There may be required changes to the organisation‟s structure during the
conversion phase or afterwards, e.g. the warehouse layout may undergo physical
restructure, new departments created or removed. There may be changes to user
operating procedures, staff numbers, staff types, and perhaps changes to staff
contracts or grades. Depending on the size and complexity of the new system being
brought in, it is worth spending effort thinking about how our organisation may
change, and the issues, constraints, and advantages this may bring about.

The various options highlighted in the previous section will need to be costed. There
may be a need to divide the various activites and these can be highlighted when a plan
of implementation has been developed. Different items can be tendered for separately
with different cost estimates.

At the end of this process a choice will be made

Recommend: Must consider all the costs possible, not just those of the programme.
Also the software should be selected before the hardware.

User examples: In Zimbabwe the installation process in GMS included several local
companies: *(ERIK)
Compulink – cabling network
GMS/ Burco/ IDATA – training
IDATA – installation
MSH – programme

DRAFT                                                                                    19
                                                                  Chapter 5: Implementation



5.1     Define Organisation of Implementation
The implementation process will involve drawing up an implementation timetable and
deciding at what levels within the organisation decision making and implementation
actually take place. In this example, the following is suggested:

A Steering Committee, Project Group and specific Working Groups should be set up.
Membership of these various group, committees will be decided, including their
responsibilites, reporting structures, and how often they meet. They are described in
more detail below:

Steering Committee (SC)

The Head of the Steering Committee should be the client with representation from

1. They identify the Project Group to implement the operations.
2. Develop the strategy of implementation. Have to consider the following:
 one site /multiple sites
 one module on all sites at the same time or test it on one site then roll it out onto
 more than one module on one site or multiple sites, or test on one site then roll
 run 2 systems in parrlal, how to test double entries of old and new system, then
   compare results
 big bang, shut down old system and open with new system
3. Responsibilties include:
- monitor progress/performance of the project implementation
- handle requests for changes which often have a financial impact
- liaise with supplier as necessary

Project Group


Responsible for the overall plan of implementation. Take decisions on a day to day
basis on the running of the system.
Report to the Steering Committee.

DRAFT                                                                                     20
                                                                 Chapter 5: Implementation

Working Group


Assigned tasks which are responsible for, e.g. testing of system, supplier side systems
development, installation of cables, installation of hardware, etc.
Report to the Project Group.

Recommned: Include implementation, maintenance, routine operations. Plan
progressive implementation (one step at a time) and involve current and future users
in the design and implementation process. Develop an implementation plan.

User examples

5.2     Monitoring and evaluation
An introdcution of a computerised system is assumed to improve overall efficiency
and thus performance of the organisation. Therefore indicators should be developed
and measured before any installation as well as at regular intervals after the
installation to determine the impact of computerisation.

Computerised DMIS systems support the business processes by facilitating the more
routine aspects of the work, freeing staff to carry out more strategic orientated
activity. The results should be evaluated with management with the view to
improving other areas of the business process, in an iterative manner.

Recommend: Decide on some benchmarks before the implementation process starts,
test at regular intervals and make adjustments as necessary.

User examples

DRAFT                                                                                  21


DRAFT                22
                          Appendix 1: Flow Diagram of Processes in the Drug Management Cycle

Appendix 1

Flow diagram of processes in the drug management cycle

In this context the drug management information systems will be defined as all steps
included in the process of procurement and distribution. This can be depicted in a
flow diagram:

STEPS                                         METHODS

1. Estimating drugs/ medical supply needs     Quantification of drug requirements must
                                              be based on reliable estimates of actual
                                              need. The following methods can be
                                               consumption
                                               morbidity data
                                               estimated budget requirements
                                               adjusted consumption
                                               prioritisation based on
                                                  VEN/ABC/therapeutic category

2. Evaluating financial situation             Good, reliable financial management is
                                              essential and includes:
                                               preparation of long-range plans,
                                                  budgets, cash-flow and estimates of
                                                  resource needs
                                               control of the collection, safekeeping
                                                  and use of funds
                                               monitoring of proper accounting
                                                  system, setting of sales prices and
                                                  efficiency monitoring

3. Purchasing process                         Good Pharmaceutical Procurement
                                              Practices should be applied. In the
                                              procurement cycle the following must be
                                               procurement method
                                               contracts
                                               other sources for drugs (donations)
                                               comparative drug price date
                                               order status
                                               supplier performance

DRAFT                                                                                    23
                         Appendix 1: Flow Diagram of Processes in the Drug Management Cycle

4. Receive / Quality Control                 In the receive/Quality Control process
                                             the following measures must be taken:
                                              inspection of shipments
                                              laboratory testing
                                              expiry date analysis
                                              storage conditions
                                              lead-time analysis
                                              quarantine

5. Storage/ Inventory management             the following inventory information
                                             factors are essential to the order
                                             estimation/reorder system and
                                             appropriate storage of goods
                                              average monthly consumption
                                              supplier lead-time
                                              safety stock/ minimum & maximum
                                                 stock levels
                                              storage capacity and locations

6. Transport/delivery                        In the supply chain, transport
                                             management is important in ensuring
                                             drug availability to users. Here it is
                                             important to consider:
                                              transport alternatives
                                              planned delivery routes
                                              vehicle maintenance
                                              manpower planning

7. Distribution /Dispensing                  Information on rational drug use can be
                                             extracted from this level, such as:
                                              % of total drug expenditure
                                                 accounted for by
                                              % of total drug expenditure
                                                 accounted for by registered/essential

8. Human resource management                 Alongside this flow-chart will be the
                                             personnel management process, where
                                             information will be of major importance
                                             to managers in planning and organising
                                             the present workload and future tasks.
                                             In the human resource management
                                             process it will be important to know:
                                              job description
                                              personnel qualifications/training

DRAFT                                                                                   24
                                          Appendix 2: Features and Functions of an Ideal DMIS

Appendix 2

Features and functions of an ideal DMIS system

The Ideal Drug Management Information System, defined as a benchmark, will be
able to process operational information in all areas of drug supply chain for a
complete business environment, from the pharmaceutical functions to the more
general areas, such as finance, accounts and personnel information. Other enterprise
functions and more detailed pharmaceutical functions are mentioned but will not be
discussed further here.

   Logistical forecasting is an essential feature in a DMIS, since this very complex
    and time consuming process can be performed much quicker and produce much
    more accurate data at any given time compared to being done manually.

   A tender processing module should be given high priority as an essential
    function since it enables simplification of what is otherwise a complex process.
    The process is classified as essential, even if it can be done either manually or by
    use of other tools such as a spreadsheet. Integration of tenders into the overall
    management systems is regarded as so essential that other methods are hardly

   Procurement management is an essential function providing timely data without
    the delays inherent in producing data manually. Drug availability is of such
    importance that ensuring it in the best possible way is vital and for that reason the
    best tool for this process is an integrated procurement module - regarded as

   Inventory management will be essential for the purpose of providing timely
    information to both the procurement and sales department, even if stocktaking has
    to take place regularly to ensure the reliability of the data.

   A sales module can provide access to stock information quickly and update stock
    information immediately an order has been processed. In a decentralised drug
    distribution system, where financial responsibilities have been delegated to district
    level, it will be of major importance to provide accurate sales data to the district
    and a sales module will thus be essential.

   Financial and accounting management modules will streamline and speed up
    the data handling process, as well as improving the reliability of the data.

   Fixed assets are a desirable function, which will often be used together with a
    financial and accounting module.

   Transport management is a newly developed software functionality that has
    been of great value in various vaccine distribution programmes.

DRAFT                                                                                     25
                                          Appendix 2: Features and Functions of an Ideal DMIS

   Personnel management modules will be of importance in an environment where
    human resources contribute considerably to the total drug management cost.

Other enterprise functions:

For the overall management of a business enterprise in the drug distribution chain,
some of the following features can be useful, but will not be considered in detail:

   General-purpose software: word processing, spreadsheet, database
   Project management
   Communication: E-mail, Fax

Other related functions used in the pharmaceutical sector

Other software programs have been developed for the purpose of drug control, but
these will not be discussed in the context of software available to the drug distribution

   Drug registration
   Drug information
   Rational drug use
   Health statistics
   Data presentation

DRAFT                                                                                     26
                                                                 Appendix 3: Requirements for a DMIS

Appendix 3

Requirements for a DMIS

A) General features

                                 SUPPLIER INFORMATION
Besides general information on the different software suppliers, such as company name, address and
contact information, some supplier related information is regarded as desirable and, indeed, essential to
establishing a reliable business relationship. Evaluation of information made available to the purchaser
will be essential in the process of selecting a computerised Drug Management Information System.

   Company reliability and sustainability

In the process of selecting a company, whatever the company‟s field of operations, essential
information must include "number of years company has been established", as this can indicate the
sustainability of the company. Additionally, company management capacity and customer satisfaction
is reflected in annual turnover and company size.

   Availability of local support

Availability of local support for maintenance of computers and programs is an essential requirement
that must be given high priority in the supplier evaluation process. Local support and the presence of
other users of this or similar software systems in the region/area are important, as this helps ensure a
high level of after-sales service from world-wide distributors. Information on countries in which the
company concerned is represented, the world-wide distribution of the system and guaranteed support
response time are regarded as essential criteria for evaluation.

   Company policies and strategies

Software companies have their own company policies and strategies. In the supplier evaluation process
it is important to ensure that no company policy or strategy is directed against the service level and
values preferred by the user. Questions concerning the company support policy, strategic alliances,
strategic direction of the company, maintenance policy and distributor selection strategy are all
questions essential to the evaluation process.

   References - appropriateness

Through familiarisation with references for the implementation of similar programs, either in part or in
whole, new customers will be able to judge for themselves the appropriateness of the software
application. The software supplier can also be asked to provide further information. Responses should
be used to determine the compatibility of the software with the intended program application.


   Training method

Training of staff is the key to maintaining good computer services in the daily operation of the
program, and at least two members of staff should be competent to operate each specific computer
program in the selected software system.
Different methods for implementation of initial and follow-up training exist. The initial training will
most often take place as on-site training and therefore training personnel must be suitably qualified.

DRAFT                                                                                                 27
                                                               Appendix 3: Requirements for a DMIS

   Training availability and materials

To ensure training accessibility, a certain number of training personnel must be available for on-site
training. Together with on-screen or manual-based training materials and self-tutorials available for
follow-up training after implementation, training availability must be ensured. Measures for training
personnel and ensuring materials availability are essential in the company selection process.

DRAFT                                                                                              28
                                                                  Appendix 3: Requirements for a DMIS

B) Pharmaceutical functions


   Drug/ budget needs forecasting – Consumption method                                     Essential

Of the various methods of drug needs quantification, the final choice of method will be based on the
type and reliability of data on drug usage, patient utilisation and morbidity patterns. The consumption-
based method is often the first choice, since it provides the most reliable data provided that inventory
records are available, reliable and updated. The consumption based quantification formula for
determining quantities to be ordered includes information on average monthly consumption, average
lead-time, time out of stock, procurement period and safety stock.

This function is essential in any automated procurement process, but also the possibility of making
manual adjustments to this formula must be considered essential, since components in the formula may
change over time, e.g. procurement period

Drug needs forecasting for budgetary purposes, e.g. for the coming year, based on previous
consumption and expected pack price will be an essential function. For this forecasting method, the
option of implementing adjustments to program expansions or strengthening in connection with disease
patterns (spread of HIV/AIDS) etc. must be available.

Drug needs forecasting using consumption-based methods to facilitate drug distribution at
district/community level is regarded as an essential feature. In a decentralised health system many
activities will be decentralised, including drug budget financial management. For that reason it is of
key importance that financial management and drug management at district level have the possibility to
plan and budget accordingly. A needs analysis in accordance with VEN classification is essential for
district/community level users with limited budgets, who will need to be able to estimate the cost of
purchasing things such as essential items.

ABC analysis                                                                                Essential

Due to restricted budgets for drug purchasing in many countries, prioritisation is usually necessary.
Various methods can be used for this purpose, e.g. VEN analysis, ABC analysis or therapeutic category

The VEN system is a system for setting priorities for the purchase and for keeping stock of drugs.
Drugs are categorised according to their health impact into vital, essential and nonessential categories,
and purchasing prioritisation is determined by this categorisation. This grouping is a specific
pharmaceutical method and is not used in more general computerised management information
systems, as opposed to ABC analyses, which are commonly used for priority setting. The VEN system
analysis is not regarded as essential, since it is a fairly simple function that presumably can be easily
included in any suitable system.

A therapeutic category analysis applies cost-effectiveness and cost-minimisation methods to help select
the best drugs for treating common diseases. This type of analysis will be essential/desirable in the
process of selecting drugs and preparing essential drug recommendations, but is not appropriate to the
drug management cycle under discussion here.

An ABC analysis is a method by which drugs are categorised according to their annual usage in terms
of unit cost time‟s annual consumption. Under this system, class A drugs are those which account for
75-80% of drug spending (due to high unit price and/or high consumption), class B drugs are those
with intermediate usage rates and class C drugs are those with low usage rates (accounting for 5-10%
of total drug expenditure).

This analysis is essential in a system that has to be capable of rationalising drug expenditure, since this
group of drugs accounts for the major part of drug expenditure – a key consideration at all levels. The

DRAFT                                                                                                   29
                                                                  Appendix 3: Requirements for a DMIS

ABC analysis will be important in the drug selection process, drug procurement, determining order
frequency, monitoring procurement priorities, and in inventory management for monitoring of shelf
life, planning of delivery schedules and decisions on the frequency of stocktaking.

The argument presented for systems application at national level also applies here. ABC analysis is
considered essential at the district/community level with its restricted budgets.

Estimating drug needs for multiple points sales                                             Desirable

Drug management information network systems set up nationally for different regions cover
distribution of similar drugs from several outlets. Where disease and drug use patterns differ from
region to region, it is important to oversee drug consumption in all regions, since central warehouse
distribution will reflect only the average consumption and not specific seasonal distribution by regions.
For example, an outbreak of communicable disease in one region and a corresponding increase in the
use of specific drugs can, given extensive knowledge of the country, be extremely useful in drug
forecasting for neighbouring regions, and at national level in forecasting the drug types and quantities
to be purchased.

In the case of a district where a number of health facilities purchase drugs from the same budget, a
features for drug needs estimates for multiple points sales will be desirable.


Functions will be regarded as desirable rather than essential.
There can be several reasons for investigating drug use and drug spending: e.g., to determine current
drug use patterns, correct specific drug use problems and/or monitor drug use over a period of time.

Expenditure on specific drug groups                                                         Desirable

System functionality to determine expenditure on specific drug groups can be desirable in the process
of identifying problems with regard to drug prescribing patterns for the purpose of correcting the
patterns so as to reduce expenditure on drugs at the national/regional level.

Therapeutic category analysis                                                               Desirable

Here the volume and value of various therapeutic categories of drugs are analysed. This analysis will
form the basis for decisions on drug selection and drug procurement. It can also be used to identify
problems in connection with irrational drug use, such as the percentage of total drug expenditure
accounted for by antibiotics or injections, or the use of certain drugs relative to disease patterns, which
could indicate misuse of drugs. Analyses of use/expenditure according to department, prescriber or
level of care would be essential.

WHO drug use indicators                                                                     NA

In 1993 WHO/DAP and INRUD published a manual on "How to Investigate Drug Use in Health
Facilities". This publication describes in detail 19 indicators for measuring drug use in health
facilities, e.g. % of drugs prescribed by generic name, % of patients treated without drugs. Some of
these indicators, desirable for health managers interested in drug dispensing analyses, can be calculated
using the computer based system – hence this function is considered desirable for DMIS implemented
at district/community level.

                                    TENDER PROCESSING

In most computerised systems for drug management at international and national level there is a need
and an obvious preference for purchasing acceptable quality drugs at the lowest possible price. Open
and restricted tenders, rather than competitive negotiation and direct procurement, are known to have

DRAFT                                                                                                   30
                                                                    Appendix 3: Requirements for a DMIS

the best effect on drug prices, and for this reason it can be argued that a tender module is highly
desirable under virtually any circumstances. A tender module will facilitate easy handling of the tender
evaluation, while module integrity with the rest of the system will increase accuracy in integrating
tender contract specifications into a procurement module.

The first step in the tender process will be to decide on the format of the tender (open or restricted),
which drug(s) should be requested in tender papers and in what quantities. These decisions could be
based on consumption patterns as described above.

The establishment of a tender request report is regarded as desirable but not essential, and the same
applies to the tender awards list and the possibility of generating contracts based on this list. The
essential elements of the tender module are:

Tender Request                                                                       Essential

Quantification of drug needs, as mentioned above, can be based on different methods and can be
carried out as a more or less centralised process. A decentralised quantification process can be
extremely time consuming and result in estimates being outdated by the time they are incorporated into
a final tender request. If reliable consumption data exist at regional/district level, it may be desirable to
utilise a tender request module at district level with the possibility of subsequent adjustment, to be
forwarded directly to the centralised procurement officer. Alternatively, the tender request report and
specified list of items required can be made at central level based on consumption/cost data and reorder
levels. Regardless of the level of use, the tender request report can save much time and effort while
supplying data with a much higher degree of accuracy, assuming reliability of data entry.

Adjudication report                                                                  Essential

To prepare an adjudication report, all information related to offers and suppliers must be entered. For
this purpose appropriate numbers and space for entry of evaluation criteria must be available.
Evaluation criteria can include product fulfilment of basic requirements concerning strength, unit size,
tablet coating etc., and supplier compliance with basic requirements such as delivery dates, previous
performance etc.

Assuming relevant information input, the software should be able to compile the adjudication report
and enable side-by-side comparison of offers.

In the event that the tender evaluation committee wishes to weight the evaluation criteria differently,
the software should allow for this. This function should be given high priority as a desirable function.

Supplier performance monitoring report                                                        Essential

To ensure the appropriate quality of drugs purchased, not only is careful supplier selection important
but also supplier performance monitoring, as this forms the basis for future purchase orders. From the
database it must be possible to prepare a supplier performance list, including for each supplier:
 Previous orders and deliveries
 Previous quality of products and packaging
 Previous adherence to delivery schedules, timeliness, supply in accordance with requirements and
    contract price versus invoiced price
 Level of service provided, e.g. suppliers return policy on expired drugs

A high priority function, not only for the purpose of tendering but also for general procurement
activities, is considered desirable.

Tender awards list                                                                            Essential

A list of all tenders awarded, whilst a helpful tool for the procurement unit, is much more essential with
regard to maintaining transparency in the tender process. By issuing a tender awards list to all bidders
containing itemised supplier/price information, non-conformance to tender evaluation criteria can be
objected to. This process puts pressure on the tender evaluation committee to make their evaluation
criteria objective and to a certain extent enables fraudulent tender evaluation to be avoided.

DRAFT                                                                                                     31
                                                                  Appendix 3: Requirements for a DMIS

The tender awards list is essential, but the software system feature that enables such a listing is only
rated desirable, since an awards list can fairly easily be drawn up by hand.

Manage simultaneous tenders                                                                 Desirable

Depending on the selected procurement method and procurement frequencies, some national drug
distributors may wish to have a software system able to mange more than one tender at a time.

Tender contract-generating                                                                  Desirable

On the basis of the tender awards, contracts must be drawn up with suppliers in which every condition
of the contract is correctly formulated. Many contract terms are standard specifications, but some terms
will require additional input, requiring precise and accurate formulation of requirements and
specifications, e.g. those pertaining to quality standards, shelf life of products and packaging. A
software feature to assist in this process can be desirable but not essential.

                                 PROCUREMENT PROCESS

Purchase order-generating                                                                   Essential

A purchase order form or reorder report that is generated automatically when the reorder level is
reached is essential to avoid out of stock situations. Information requirements for establishing a
consumption-based reorder formula can include some or all of the following factors: average monthly
consumption (AMC), supplier lead time, safety stock, reorder level, stock position (on hand/on order),
maximum stock level and procurement period. This mathematical calculation model is much easier
handled by an automatic calculation from data already available in the database than if performed
manually - and also results in much more reliable results. The results thus generated are then entered on
a purchase order form together with the following information: product description, supplier
information (if any), on tender Yes/No, stock situation - on hand/on order, last purchase price, order
quantity recommended and order value.

Calculation of minimum stock                                                                Essential

The minimum stock level or reorder level will determine at what time a new order should be calculated
and placed. Calculation of minimum stock is, as can be seen, closely related to the purchase order
calculation and is equally essential to the purchasing process. It will be only natural to specify software
systems that are able to calculate minimum stock, average monthly consumption and reorder quantities.

Out of stock report                                                                         Essential

An out of stock report will be a listing of all items in the product range, which are out of stock on the
day of printing. Besides information on products and suppliers, this list should also contain information
about stock on order and delivery dates. This report is essential as a support function for the purchase
reorder generation feature, since in extreme situations it will show when a top-priority purchase is

Currency conversion and adjustment for trade terms                                          Essential

In dealing with international trade/tenders, quotations will be given in different currencies. To
eliminate a major cause of miscalculation, it is important that the computer can easily handle currency
conversion. The possibility of data entry of foreign currency and computer handling of conversion to a
common currency is regarded as essential.

Since international suppliers submit quotes using different trade terms (FOB, CIF, Flight), it is
important in the collating process to allow for these differences, as quoted prices will invariably
include major variants based on differing freight payments etc. This is why adjustment for different
trade terms is of importance in the procurement/ tender handling module.

DRAFT                                                                                                   32
                                                                  Appendix 3: Requirements for a DMIS

Order status report                                                                         Essential

An order status report, purchase order pending or overdue report lists all items, together with their
delivery status, where delivery has not taken place or where delivery dates have not been met. These
lists are of importance in drawing the attention of suppliers to outstanding matters and are also of
benefit in evaluating supplier performance. These reports should allow for searches to be performed
covering a given time period per item and/or per supplier.

This is an essential function at national level as drugs are usually ordered from many suppliers during
international competitive bidding at national level. This information is important in order to avoid
emergency procurement, as many suppliers do not stick to the delivery times.

Price comparison features                                                                   Desirable

Given the restricted financial resources, which are a feature of virtually all health programmes, the
costs of drug procurement are of extreme importance. But there are also other costs related to drug
procurement, e.g. loss of products due to poor packaging, replacement costs for drugs that expire in
stock, and the cost of suffering and diseases not treatable due to certain drugs being out of stock. A
decision on the method of procurement for each drug should take these considerations into account
By comparing procurement prices with prices from other systems, e.g. those of neighbouring countries,
or the prices listed in International Drug Price Indicator Guide, managers will obtain a picture of the
system‟s procurement efficiency, method of procurement and sources of supply.

A software feature that can go online to retrieve international drug prices and prepare purchase price
comparisons for current stock is a desirable function in a DMIS. But this process will not be regarded
as essential, since it can be performed manually and is an activity that does not have to be performed
many times a year, but could be done e.g. once a year.

Entering pharmaceutical supplies from donors                                                Desirable

In many developing countries drug donation will be an issue best handled at national level. Guidelines
for drug donation and methods of integrating drug donation into the regular drug supply system should
be decided nationally. In some software systems the procurement process is closely linked with
inventory management, making the entry of non-purchased drugs a problem. If drug donations are
entering the country on a regular basis it is important to ensure a feature that enables computer entries
of such drugs.

For systems applied to NGO supported units, where drug donation occurs, a feature for entering
pharmaceutical supplies from donors will be an essential function. This caused by the requirement from
many donors on accountability for donated drugs.

Port clearance report                                                                       Desirable

Port clearance procedures are often a time consuming process due to the inefficiency with which many
port facilities are run. This process can in many ways be costly in terms of man-hours, port storage
charges, tie-up of capital funds, damage to goods, insurance claims handling and delays to drug
supplies. A port clearance software feature able to keep track of goods, port clearance papers, port
clearance activities, reports of supplier inefficiency in shipment handling, damaged goods and
insurance claims, and able to monitor causes of delay, will be a desirable feature which can be a cost-
effective tool in dealing with such matters.


Receiving report.                                                                           Essential

Listing of orders received by item for a day, a specified period or by source. This list will show date of
receipt, total quantity, invoice price and any damage or loss. A receiving report is a valuable tool in the
receiving process, showing the basic information that must be entered to update the drug master file so
that it reflect physical stock changes. The data entered can also be used to check accuracy of invoice

DRAFT                                                                                                   33
                                                                    Appendix 3: Requirements for a DMIS

prices, supplier performance/monitoring of timely delivery, quality control data and as a record for
insurance claims.

Receiving reports will be essential for the smooth running of a receipt unit.

Quality assurance record                                                                       Essential

Physical inspections of all shipments and targeted quality control activities will be part of the overall
quality assurance (QA) policy implemented at national level in most countries. It is important to
maintain clear records of QA activities relating to goods received in stock. Therefore there should be
entry fields in the receipt report for QA findings. Depending on the results of quality assurance
activities, this entry will result in the product being either released for distribution or kept in quarantine
until a final decision on the product flow has been made.

This specific pharmaceutical related feature, although considered essential, is not included in many
DMIS. This is most probably due to the fact that many DMIS are general management information
systems that have been adapted to the pharmaceutical area. Often this problem is circumvented by
simply not entering goods with QA problems in the receipt record until a compensatory agreement is
reached e.g. with the supplier. This procedure can lead to important management information not being
entered into the system. Information is then only available upon request, which is not a satisfactory

Product list with specifications                                                               Essential

Computerised procurement and inventory management on a large scale needs to be handled by a
database program. The simplest report from a database will be a printout from the drug master file (the
product file in the database). For example, the drug master file can contain identification information
on the product (name, dosage form, strength, unit/package size), classification information
(ABC/VEN/pharmacology and storage); consumption related information (average monthly
consumption, safety stock level, minimum stock) supplier information (previous suppliers) and price
information (purchase and sales prices).

From this database information it will be possible to compile different reports containing specified
information. This will, for example, enable the management to produce an updated stock list with
product specifications and sales prices, for use as a product sales list.

Investing in a DMIS will result in this type of report making becoming an essential standard request.

Updating inventory databases                                                                   Essential

Some of the benefits of computerisation are to simplify and speed up complex tasks, increase data
integrity, and update and access information quickly, making information in the system accurate and

An essential requirement of the software program will be that the purchasing/tendering program can be
integrated with the inventory management system. The automatic updating of the inventory database
when procurement has been performed, supplies delivered, stock issued and sales completed, either
simultaneously or on a regularly daily basis, will be an essential function.

Stock detail report                                                                            Essential

There are numerous simple reports that can be retrieved from the basic database program, which will
prove useful tools in daily management. Most of them will be supplied as standard reports as a function
of the program, but simple preparation of non-standard reports based on information in the database
should also be enabled.

An inventory report on the stock balance of all items, with information specified in quantities by item/
batch and/or allocation. This will be a simple essential report compiled from information in the general

DRAFT                                                                                                      34
                                                                  Appendix 3: Requirements for a DMIS

Inventory adjustment report                                                                Essential

Either from stocktaking or due to waste of drugs, it can be necessary to make a database inventory
adjustment to reflect the physical stock. It will therefore be important to have a stock adjustment
function included in the system. An inventory adjustment made available after all stock adjustments
have been completed will be essential for the purpose of controlling stock adjustment and, for example,
to prevent unauthorised individuals from entering fraudulent changes to the stock balance. At the same
time, stock adjustment reports with information on the reason for the adjustment can be an essential
management tool for controlling losses and waste.

Expiry stock report                                                                        Essential

Another simple and essential database report is an expiry stock report, containing a list of stock items
which have expired or are due to expire in the coming months. It will be essential to monitor expiry
dates. Follow-up on this information will ensure removal of expired goods in stock, thus avoiding
distribution of expired drugs.

Expiry date analysis or expiry risk report                                                 Essential

A more advanced expiry report is the expiry data analysis or expiry risk report, which not only
retrieves basic information from the database but also performs simple calculations. An expiry risk
report will list all stock items at risk of expiry in stock, based on information on stocks, expiry dates,
previous consumption (AMC) and remaining shelf-life for products.

An expiry risk report can be extremely helpful in tackling the problem of expiry of drugs in stock, since
this report serves to notify managers of the current expiry risk and hence the steps they can take to
avoid or minimise projected losses.

Stock control performance indicators                                                       Essential

Several indicators can be mentioned as essential for stock movement information. For example, it will
be of extreme importance to know and have indicators for which drugs are fast moving, which are slow
moving, which are not moving (dead) - FSD classification - which are overstocked and which are at
risk of expiry. This information, combined with the ABC and VEN analyses, will provide the basis on
which to decide e.g. purchase frequency.

Lead time analysis                                                                         Desirable

A systematic analysis of the components affecting lead-time, i.e. the time that elapses from realising a
drug must be purchased until it is in stock. Lead-time will be influenced by factors such as reorder level
monitoring, method of purchase, supplier delivery times, port clearance, receiving procedures and any
quarantine period.

To perform a lead-time analysis, records should be kept for all milestone dates in the purchasing
process. This data is then used to perform automatic lead-time analyses, cross-comparisons of suppliers
and cross-purchase process analyses in order to identify the major factors affecting lead-time. This, in
turn, enables improvements to the purchasing process to be implemented.

Receipts report for specific periods                                                       Desirable

This function can make information available on which items are still physically in the receipt area and
to determine the receipt workload for specific periods. This function is considered desirable in the
context of overall storage management and personnel time management.

Stocktaking forms/physical stock inventory report                                          Desirable

Regular stocktaking is necessary, e.g. for the purpose of reordering and determining inventory value. If
this process is performed in the computerised system, it is recommendable to perform physical
stocktaking from time to time to ensure the accuracy of the data in the computerised system. A helpful
tool in the stocktaking process is the production of computerised stocktaking forms – a functional list

DRAFT                                                                                                  35
                                                                   Appendix 3: Requirements for a DMIS

that includes information on product, identification code, strength and unit size. The forms also serve
as an important stock classification tool, particularly with regard to product storage, racking and
shelving, thereby considerably easing the work of stock control, stocktaking and order selection. The
use of stock taking forms facilitates both the counting process and the inventory adjustment procedure.

Automatic expiry notification                                                                Desirable

Many software systems enable on-screen notification of activities that have been entered in a calendar.
This feature could be desirable for use in connection with drugs that have reached their expiry date but
which are still in stock. Such a notification could appear either when the expiry date has been reached
or when products within, say, three months of their expiry date are selected for issuing to
regional/district or community level health facilities.

Multiple warehouse implementation                                                            Desirable

A desirable feature for users at international/national level could be the possibility of setting the system
up in multiple warehouses and from central level being able to monitor drug levels and consumption in
each warehouse. This set-up could be desirable in a decentralised system in countries where central
level can support the overall organisation of drug distribution and allocation.

                                  SALES AND DISTRIBUTION

Picking lists - Functional list                                                              Essential

In all so-called drug distribution, "pull" systems or independent demand system orders of different
kinds will be entered in the drug distribution system one level above where the order is given. This is
often done by means of requisitions. When orders are entered into the computer system for invoicing, it
will be essential to the administration of drug distribution that picking lists be based on both order and
by physical location.

The possibility of designing a pick list that accords with stock placement ought to be considered an
essential feature.

Returned goods handling                                                                      Essential

Even in the best handled drug distribution system there will be situations where, for different reasons,
drugs will be returned from a lower to a higher level in the distribution chain. At national/district level
the system must be able to receive returned goods from a lower level and to handle goods to be
returned to suppliers.

The computerised drug management information systems must be able to keep records of these
returned goods handling procedures and claims, so as to reflect the size of the problem and the reasons
why problems are occurring. A returned goods report must describe the situation in relation to the
overall size of the problem, the amount of money involved and the reason for the return.

Stock allocation during order processing                                                     Essential

It is desirable to have a computerised DMIS that can allocate stock immediately orders are processed,
so as to ensure that stocks are actually available for distribution. Otherwise clients must be contacted
and the order adjusted (change of quantity or product specification).

Stock allocation by expiry date and batch traceability                                       Desirable

To reduce expiry costs, stock-handling procedures such as first-in/first-out or first-expiry/first-out have
been introduced. The programmed allocation of stock according to expiry date is considered a
desirable reminder for use of this handling method. However, as long as employees are responsible for
physically picking stocks from shelves, human error can never be entirely ruled out.

DRAFT                                                                                                    36
                                                                  Appendix 3: Requirements for a DMIS

Where products are withdrawn from the market, batch traceability is important. If products are
allocated to clients according to expiry date and using batch numbers, and assuming that users adhere
to system guidelines, it will be possible to trace batches to the receiver.

Client consumption analysis and budget                                                      Desirable

In sales and distribution, function records will be maintained in the computerised system to facilitate
financial administration, invoicing etc. Activities will not be limited solely to procurement
management and inventory management. Using the same database program for procurement, inventory
management and accounting is recommendable and desirable, since these activities are closely

Not only is it desirable to prepare financial overviews for each client for the purpose of controlling
drug expenditure, but also the preparation of an overview of client drug consumption would be an
important indicator of rational drug use.

Emergency orders                                                                            Desirable

A situation in which vital drugs are found to be out of stock at a lower level can result in the placing of
an emergency order. In this situation it is desirable that the software system is able to prioritise this
type of order. This can be done using a special emergency indicator for emergency orders being entered
into the DMIS. This indication should appear on the picking list, delivery note etc. It should be made
impossible for a delivery to a client to be processed without inclusion of any emergency orders placed
by the same client.

Stock reservation for sale                                                                  Desirable

Under certain circumstances at national/district level, it may be necessary to reserve stocks of some
drugs for specific clients and hence desirable to enter such reservations in the computerised system.

DRAFT                                                                                                   37
                                                                  Appendix 3: Requirements for a DMIS

C) Business System Functions


Accounting dimensions                                                                      Essential

It is assumed that all finance systems have at least one accounting dimension: a Chart of Accounts.
However, in larger installations this one accounting dimension is insufficient. Often, departmental
and/or profit centre accounting is required as well. The number of dimensions required can vary
greatly, but usually two or three are required as a minimum. This is important for control purposes. If
multiple dimensions are supported by the system, different levels of control can be assured - heads of
departments can track and monitor those expenses, which are directly attributable to them. It is also
important that these dimensions are supported throughout the system and in different modules, to
ensure that all transactions entered into any of the modules can be „tagged‟ with the correct dimensions.
Additional overview of the information retrieved is gained if the different dimensions support a
hierarchical structure - i.e. elements can be grouped and subgrouped.

Audit trail                                                                                Essential

An audit trail allows users and auditors to track financial transactions, which have been entered into a
system. This ensures e.g. that the list of transactions entered into a system is detailed enough to allow
for „backtracking‟ of financial entries. Based upon the audit trail, the chronological order and method
of entering financial transactions into the system should be able to be recreated. This allows e.g. for
errors to be tracked and corrected. In addition to keeping track of every transaction entered into the
system, there are a number of additional facilities, which may also assist the process. This includes
ensuring that only balanced transactions may be entered into a system and that, once entered,
transactions cannot be modified in any way. Also, checks for entering vouchers twice and allowing
templates to be entered may further reduce the risk of errors being entered into the system.

Budgets                                                                                    Essential

One of the main aims of utilising a computerised financial management system in an organisation is to
increase managerial information for better decision making. In this respect, financial budgeting and
control is an important issue. If a system is capable of handling budgets and budget comparisons, it
increases the system usability. Budgets can be made on several different levels - in particular with
relation to the accounting dimensions (e.g. departmental budgeting) - and over different time periods.
As a minimum, a budget system must allow budget figures to be entered for selected cost items (from
e.g. the Chart of Accounts) on a monthly basis. Variations on this can include departmental or project
budgets prepared on a weekly or quarterly basis. If different budgets can be handled simultaneously, it
is possible to make budget comparisons based upon e.g. different revised budgets.

VAT support                                                                                Essential

In the purchase and sales of drugs, VAT calculation will become an issue in certain situations. The
finance module must ensure that VAT can be added and deducted at set rates in order to fulfil the
necessary reporting requirements. This should be integrated with any accounts receivable or payable

Reports                                                                                    Essential

In any financial system, there are a limited number of reports, which should be included in order to
view financial transactions, which have been entered into the system. These include a finance journal,
which lists all transactions entered chronologically, and a trial balance, which displays the balances for
all accounts in the Chart of Accounts. Additional reports include budget reports, which print budgets,
and also compare entered budgets with actual balances. Finally, most organisations produce Profit and
Loss Statements and Balance Sheets. There are a multitude of additional reports which may be

DRAFT                                                                                                  38
                                                                  Appendix 3: Requirements for a DMIS

produced from a finance system, including e.g. ledger cards displaying transactions entered for a
particular account, forecasting, cash flow analysis reports and other statistical reports.

                                     ACCOUNTS PAYABLE

Supplier database                                                                           Essential

The heart of any Accounts Payable system should be an extensive supplier database, which allows
storage of information pertaining to the suppliers. This becomes increasingly important with time as
historic data related to suppliers can form the basis for the decision making process related to purchase
of new items. This database may also simplify the printing of reports and preparing of mailing lists.

Integration                                                                                 Essential

An accounts payable system can add different degrees of functionality to a system. This can range from
having a supplier database to controlling the entire purchasing process, from receiving quotations to
receiving goods and issuing payments. The system may automatically generate entries in the General
Ledger (i.e. the relevant ledger entries are processed in the system when a payment is registered in the
Accounts Payable module). Alternatively, the system may allow users full control over the process.
The Accounts Payable module may also be integrated with other sub-systems, such as inventory
management or cash management.

The level of integration between an Accounts Payable Module and the remainder of the system is less
critical at district/community level than it is at national/international level, as the number of
transactions and number of suppliers are expected to be far greater at national/international level than at
district/community level.

Reporting                                                                                   Essential

There are a number of reports, which are required in any accounts payable system. A journal report
gives a record of all transactions related to suppliers. This serves as an audit trail for supplier
transactions. A list of suppliers can be used for a number of purposes, including mailing lists. An age
analysis report shows all outstanding payments, their value and when they fall due. These may be listed
by either due dates or by suppliers. Finally, purchase statistics (e.g. value or quantity of purchases) can
be helpful in determining repeat orders and negotiating supply contracts.

Generating payment schedules                                                                Desirable

Depending on the cash available, historic requirements, outstanding payments and payment terms and
conditions, payment schedules can be optimised. A MIS may provide some automation in relation to

                                  ACCOUNTS RECEIVABLE

The Accounts Receivable module shares most of the required features and functionality of the
Accounts Payable module, which is described above.

VAT calculation                                                                             Essential

In an accounts receivable system, which is integrated with an inventory module, automatic Value
Added Tax (VAT) calculation would be an essential part of the system as this eases the financial
control of the sales and distribution of inventory items.

DRAFT                                                                                                   39
                                                                  Appendix 3: Requirements for a DMIS

Interest calculation

When issuing invoices to customers, different terms of payment may be specified, e.g. cash on
delivery, 30 days credit. In addition to this, interest may be charged on overdue payments. If this
functionality is partly of fully automated in the system, control and interest calculation is simplified
and gives the system users a better overview and control of outstanding invoices. This is particularly
true in the case of larger outlets with a large number of customers.


In addition to the essential reports described above, there are some reports, which are unique in relation
to customers and are desirable in such a system. This includes the possibility of automatically
generating account statements, reminders to customers and printing of receipts.

Previewing reports                                                                         Essential

The industry standard for any application, which outputs information onto paper, is that the expected
result can be previewed on-screen before committing to paper. This is essential to save both time and

Selection criteria                                                                         Essential

At large installations, it is necessary that relevant information can be extracted from the DMIS when
needed. As the amount of information increases, the need to be able to specify and limit information
becomes important. If information cannot be limited in the form of e.g. an SQL SELECT statement, the
information desired and required could not be extracted from a database without producing a large
number of reports. In the daily use of a system, the need for information is dynamic and often specific.
By including a selection option combined with e.g. different grouping and sorting criteria, specific
information required as a basis for decision making can be extracted from the system. This may be
combined with e.g. a built-in report generator (see below).

Sorting criteria                                                                           Essential

Report generators                                                                          Desirable

When a system is installed at international or national level, it is expected that individual reporting
requirements be identified at some sites. If an application has a built-in report generator, localised
installations can produce their own reports when required. This minimises involvement from and
dependency upon both the supplier and the headquarters. Information in the DMIS can then be tailored
to suit precise needs for reports. This increases the quality and usability of a system. If a „Report
Wizard‟ or similar tool is available, new reports can be generated without specific computer
programming skills being required.

Graphical output                                                                           Desirable

Graphical output may be desirable not only at management level but also for public use, as charts and
graphs are better at conveying certain aspects of information in some cases. This can be important
when comparing information and conveying statistical data to non-technical persons. It is an added
advantage if a system can produce graphical output, but there are several graphic presentation tools
available on the market, which can be used independently of MIS.

DRAFT                                                                                                  40
                                                                  Appendix 3: Requirements for a DMIS

                                          FIXED ASSETS

Depreciation                                                                                Desirable

In larger organisations the number of fixed assets used (e.g. vehicles, houses and warehouses) may
make the automatic registration and depreciation of fixed assets in a MIS desirable. In addition to
registering information pertaining to fixed assets (e.g. description, purchase price, location) the main
functionality which can be gained from such a system is the automatic calculation of the depreciation
of fixed assets to ensure that the correct net book values are registered. There are a number of different
depreciation methods (e.g. straight line, percentage, fixed) and rates which can be employed. The
system should be able to handle all of these methods. In the case of sale, theft or disposal of assets, the
system should also be able to register the financial consequences.

Integration                                                                                 Desirable

A fixed assets module may be integrated at a number of different levels. This may be from keeping a
register of fixed assets to automatically registering purchases of fixed assets, calculating depreciation
rates and preparing the correct general ledger entries.

Maintenance and insurance                                                                   Desirable

Fixed assets are often of a nature, which requires maintenance and insurance cover during their use. A
system may include a facility to register this type of information and prepare forecasts of when service
or insurance is due again. The historical costs related to this may also be included.

Reporting                                                                                   Desirable

Fixed asset reports should include details regarding fixed assets, for e.g. control purposes. Book values
and depreciation to date should also be reported. Finally, if maintenance and insurance details can be
added to the system, reports should be available that list historical costs and details involved.

                               TRANSPORT MANAGEMENT

Route planning and costing                                                                  Desirable

A transport management system is chiefly used to assist in the efficient use of vehicles for
transportation of goods between different locations. This may be for the distribution of goods from one
main location to several locations or a combination of delivery and pickup. A transport management
system will assist in calculating the maximum usage possible based upon a number of factors,
including manpower availability, load possibilities, route distances and number of stops. Cost
calculations based on selected routes may also be automatically calculated by the system. In addition to
this, a route planning system may store information pertaining to vehicle use and maintenance if this is
not stored in e.g. a separate fixed assets module.

Integration                                                                                 Desirable

Transport Management can affect several areas of an application: transportation and movement of
inventory items, use of fixed assets, use of human resources, incurred running costs etc. Once again,
different levels and degrees of integration with the remainder of the system can range from storing data
pertaining to transport management to automatically generating entries related to the delivery and
location of goods, consumption of petrol and use of fixed assets and other resources. This will
ultimately lead to different levels of information being available within the system.

DRAFT                                                                                                   41
                                                                Appendix 3: Requirements for a DMIS

                         HUMAN RESOURCE MANAGEMENT

Personnel records                                                                         Desirable

The basis for any personnel management system is information pertaining to employees. This may
range from basic information such as name, address and employee ID to storing all information relating
to an employee‟s educational background, employment record, next of kin etc. The amount of
information required in a personnel management system will depend upon the organisation which is
using it. However, as organisations become larger, the amount of information, which can be stored
locally generally, becomes more important. The information store in such a database may be used when
e.g. handling promotion and career planning.

Resource planning                                                                         Desirable

In work areas where manpower or machine input is required, a resource-planning module may become
important. Employees are generally only available for a limited number of hours during a week and
allocating these limited resources efficiently can be aided by using a resource planning system. In this
system, the total availability of resources during a period is entered and these resources can then be
reserved for specific jobs. Machine or non-human resources may be handled similarly and in
conjunction with the manpower planning system, e.g. loading a vehicle requires not only manpower,
but also a loading bay and a forklift. Being able to view planned and actual usage gives management a
view not only of the efficiency of resource usage, but also areas or periods of time where additional
resources are required. This type of system becomes important when dealing with resource intensive


All organisations, which employ people, must prepare some form of pay slip when issuing salaries. The
complexity of these payslips will depend on the organisation concerned and the statutory reporting
requirements of the country in which the organisation is operating. In most cases there are a number of
earnings (e.g. gross pay, bonus, benefits) and deductions (e.g. tax, pension and/or union contribution)
which must be tracked and reported. Depending on the size of the organisation, a computerised system
may be financially beneficial to an organisation as it enables these earnings and deductions to be
automatically calculated. In addition to automatically preparing individual pay slips, total income tax
payable by the organisation can also be automatically calculated. In addition to this, a computerised
payroll system may also automatically generate the correct entries in the general ledger and/or

DRAFT                                                                                                 42
                                                                   Appendix 3: Requirements for a DMIS

D) Information Technology Functions


Operating system (OS) - Data input/output                                                    Essential

It is imperative that the system be able to run on a modern OS. At international level, the ability to run
on a choice of large-capacity operating systems such as Unix or its derivatives (e.g. IBM-AIX, HP-UX)
and Windows NT is essential.
The possibility of entering data into the system via devices such as laser/infrared light barcode readers
or magnetic strip sensory devices will allow for greater speed compared to standard keyboard

The system should be able to print to all kinds of printing devices: older types such as matrix printers
and more recent types such as inkjet printers and laser printers and plotters. This interfacing should be
possible using standard printer drivers for the system.

The ability to run under a modern OS must be considered as essential to all users. At the
district/community level the system should be able to run under a DOS or DOS/Windows 95 OS.

Network installation/scalability/ single user installation                                   Essential

The system must be available in a network version in order to cater for the needs of large international
customers. The network types should be modern, high capacity networks, able to support a large
amount of concurrent users. As the number of users rises, so do the requirements to the system,
network and hardware. Network installations will require larger investments in hardware and the focus
will have to be on optimising the size of the network to the configuration of the hardware. If the
hardware configuration is insufficient relative to the system requirements and number of users, access
time to the system will become too high. On the other hand, hardware capacity comes at a premium
and should not be over-dimensioned. It should be possible to expand a system in tandem with the
expansion of other activities. Such scalability could relate to different aspects regarding the use of the
system, such as:
 The basic functionality of the system: Is the system modular in its basic construction? Is it possible
     to start off with a limited functionality and later purchase additional modules when the need
 Increasing transaction volume: Are activities expanding in a way that lead to an additional
     transaction load? The system should be prepared to cater for this, e.g. by enlarging the underlying
 Increasing number of concurrent users: Should the need for additional concurrent users linked to
     the system occur, the system should be able to accept such an expansion. It is important to attempt
     to estimate such potential needs from the very start of the system assessment in order to ensure
     that the system in question not only complies with actual needs, but also will be able to handle
     possible additions within the scope of future expansion.
When used at smaller sites, it is imperative that the system is able to run as a single user installation on
a stand-alone desktop computer.

Data entry??

Printing Facilities??

DRAFT                                                                                                    43
                                                                  Appendix 3: Requirements for a DMIS

Internet ability                                                                           Desirable

Since retrieval and transfer of information via the Internet is becoming increasingly more widespread,
it would be a desirable option to have such Internet abilities in the system. The Internet may be used for
many other purposes than simple search and retrieval of generally available information. Some systems
will allow the user to access specific databases on other locations via the Internet, which could be of
great use to an international/national distributor.

                         TECHNICAL SYSTEM INFORMATION

System base and adaptability                                                               Essential

A software product can be developed in a multitude of programming environments. Different
programming languages, from different generations, with differing degrees of popularity. In general, it
will be an advantage if a known, modern programming language has been used in developing the
system. A well-known environment will minimise the cost of external consultancy, since the
availability of knowledgeable persons within this field will be greater than compared to an older, more
obscure language.

The system should allow for individual customisation of its functionality – preferably even the
development of entire “tailor-made” modules, in order to cater for specific needs. Such modules can
even be made by third parties, in cases where certain needs for some areas have been identified but
which are perhaps too specialised for the System Supplier itself to engage in the development of.

In many cases only some small degree of customisation will be necessary. For example, only minor
adjustments in the fields of a ledger card are required to make the day to day use of the system
considerably more flexible and thus inspire the end user to make full use of the system‟s advantages.

System compatibility and capacity                                                          Essential

A description of the system data compatibility, i.e. the ways in which the system can communicate with
other software systems, is relevant when assessing the system‟s potential to co-exist and exchange
information with other applications. If one wants to retrieve rough data in one system and e.g. present it
graphically via another software tool, the two systems will have to speak the same language, e.g. the
widespread ODBC (Open DataBase Connectivity) or ASCII (XX).

Many information systems have the ability to retrieve information from a variety of database formats.
The ability to support a well-known database other than the producer‟s own individually developed
database offers the same advantages in terms of the availability of skilled consultants/technicians as
described above.

Another dimension in the capacity of a system is the size and type of entries that are understandable to
the system. Basic limitations in the size of the recognisable input can strongly inhibit the system‟s
abilities to operate, e.g. in countries with high currency denominations.

It goes without saying that the system must comply with all „Year 2000‟ requirements. This means, that
the system must be able to handle all transactions perfectly, regardless of the current year or the year
being used in the transaction in question. Lack of a guarantee from the supplier that the system in
question is 100% year-2000 (often seen referred to as “Y2K”) compliant should automatically
disqualify any computer system, software or hardware!

If the system allows for connection to the user‟s intranet (internal electronic information network), the
system‟s handling of the protection of information on this intranet via use of a “firewall” should be

DRAFT                                                                                                  44
                                                                  Appendix 3: Requirements for a DMIS

System/Data security                                                                        Essential

Data security and integrity are fundamental issues to be addressed when dealing with system
assessment. Data security refers primarily to protection from unwanted viewing of and/or tampering
with data. Data integrity refers to protection from corruption of data, e.g. due to erroneous or invalid

Securing data from unauthorised viewing can be obtained by using strict login procedures
incorporating unique passwords. Each user will be assigned certain capabilities of viewing, modifying,
inserting and deleting data within the system, and the password will be the external key to the system.
The system should keep track of the user‟s activities, recording these in a user entry log.

In order to secure data from corruption, the system must have certain integrity functions, ensuring for
instance that the system accepts only valid input and is not left in an inconsistent state. Such a function
could be that the system always arranges its postings to the general ledger in a finance module as
completed postings, thus not allowing incomplete postings to be stored in the database. Should a power
failure occur on a platform not protected by an UPS (Uninterruptible Power Supply), the system must
be able to fully recover without damage to the database structure and subsequent loss of data.

User Ids and passwords                                                                      Essential

In any installation where data pertaining to an organisation or operation is stored, limiting access to
data is vital. This can be done at several levels - e.g. hardware (booting name and password), netware
(logon name and password) or application (application user name and password). In some cases, data
security requirements can be covered by other means (hardware or netware), but added security and
flexibility is achieved by the application also having an access control system. For example, this allows
users to gain access to a system from a number of different locations, which can be extremely
important in, say, a networking environment.

User access control                                                                         Essential

Although user IDs and passwords are essential for controlling access to a system, the amount of access
given to a user should also be controlled. For example, sales persons will rarely have the need to enter
details of supplies and suppliers into the system, although they will need to access stock levels and
customer details. This is essential when working with larger installations with a number of users - both
to ensure data consistency and integrity, and also to restrict access to specific information stored in the

User tracking log                                                                           Desirable

A user-tracking log allows a super user or system administrator to view the progress of users within a
system. This can be important when tracking errors made or attempts at accessing restricted areas. A
log can pinpoint which users were using a system at a particular time and (in cases where detailed logs
are concerned) can pinpoint which actions specific users (e.g. system areas accessed) carried out. This
type of information is desirable when maintaining a system and can provide information related to a
specific application which is not provided by e.g. network user tracking.

User specific menus                                                                         Desirable

It is essential that user access to the system is controlled and the addition of user specific menus is a
desirable addition to this. User specific menus simplify the user interface as only areas, which are
relevant to a user, are actually visible.

Data input validation                                                                       Desirable

Data input validation can be performed using a number of different methods. By using „look-up‟
functions for data entry where possible, the accuracy of data entry is increased. Input values may also
be suggested based on default system values. This can decrease repetitive data input and can also more
easily ensure data integrity. Large codes which may otherwise be difficult to remember (e.g. 12-digit

DRAFT                                                                                                   45
                                                                 Appendix 3: Requirements for a DMIS

item codes) can be searched for and verified at the time of data entry. For example, when entering an
order form for a large number of different items, it eases data entry if the user can search the database
from the order entry form for the required item codes. The correct items can be verified by looking at
e.g. product descriptions. Errors in data entry may be minimised using this type of facilities.

Power failure protection                                                                   Desirable

Power failures are part of the daily routine in a number of countries around the world. To ensure only a
minimal amount of data loss, there are a number of precautions, which can be taken, such as installing
uninterruptible power supplies for all workstations. However, additional safety in the form of data
recovery, backup systems and error correction can increase the sustainability of a system operating in
an unstable environment.

Remote access                                                                              Desirable

In some cases it is possible to gain access to a remote network via e.g. a dial-up connection or the
Internet. If a DMIS supports this function, data input and information retrieval can be made more
efficient in an international environment. This may be the case when there are a number of
workstations distributed over large distances or where access to up-to-date information from virtually
every location is a prerequisite.

Complete log                                                                               Desirable

The ability to retrieve a complete log of all transactions entered into the system within a given time
period would be a desirable feature for larger operations. When many users are operating the system,
such a log would facilitate the tracking of errors. When errors are tracked in this way, future mishaps
will be easier to avoid.

Integration of data

Integration and transfer of data between programs are essential since there is most often an overlap of
data used in the different programs. For that reason it is essential to ensure data integrity between the
different modules in the software system. If the software systems do not contain all modules used at the
enterprise, integrity with other, separate modules should be considered. A final decision on the range of
modules to be purchased will depend on the extent of data integrity required between different modules
and those already installed.

The import and export of data between various and similar standard packages can also be regarded as
an essential asset if computerised data already exist and there is a need to transfer old data to the new


The reason for computerisation will most often be to speed up complex tasks, increase accuracy in
spelling and calculation, automate repetitive tasks, streamline processes, and update and access
information, quickly providing managers with information for decision making. For most users the
language used on screen and in reports will be essential for the easy use of the program and for the
functionality of reports.

To be able to evaluate the language used on screen and in reports and to have the possibility of adding
specific languages are essential prerequisites for decisions on which software to purchase.

Documentation and help function

Properly documented software is essential in any operation. Although system users are expected to
undergo proper training, questions in connection with detailed system functionality arise regularly. On
a long-term basis, new users may also be introduced to systems through the use of proper

DRAFT                                                                                                  46
                                                                  Appendix 3: Requirements for a DMIS

documentation. System maintenance personnel may also require proper documentation as a basis for
their work. Proper documentation also increases user independence from suppliers. In these situations,
clarification is sought in either printed documentation or on-line help facilities, as opposed to
contacting the system suppliers. From a daily user‟s point of view, on-line help facilities ease system
use. The user does not need to leave the workstation to consult manuals. Context-sensitive on-line help
facilities ease searching for information, reducing time spent away from workstations even more.

Protection against entry of incomplete transactions

The quality of information extracted from computerised systems in the form of e.g. management
reports depends on the quality and completeness of data entered into the system. For example, if
expenditure budgets are prepared at departmental level, departmental expenditure can only be
compared to budget figures if they are „tagged‟ or identified as departmental expenditures. If a system
can ensure that transactions entered into it have identifying tags or codes attached to them, the
consistency of the data in the database can be maximised and hence the quality of information retrieval

On-line query

There are many situations where specific details are required „at a glance‟. This can be eased through
an on-line query facility, as this avoids the need for printing out reports in hard copy. In some cases,
having a „preview report‟ function can cover this, while in other cases accessing e.g. item details can be
done by viewing an item record in the database on screen.

Data import/export

Often, data stored in a particular database application must be used in conjunction with other data
analysis tools. The output of one system may serve as the input for a second system. Data migration
from one system to another is eased. For example, it is easier to keep one shared customer database
updated than three databases for use with three different systems. Integrated reporting tools may
require data from a number of different sources and applications. In these cases, data must be able to be
extracted in a usable format. This may be in the form of a comma delimited text file or through ODBC
(Open Database Connectivity - a standard for data interchange between different sources). When data
can be merged from different sources, the quality of information available to management increases. A
number of figures from, for example, different departments can be compared. For instance, information
related to geographical distribution of healthcare drawn from one system may be compared to
availability of funds from a different system. This becomes more important as the size and
diversification of an operation increase.


A charted accounting company or an operating systems supplier may certify a system. Such a
certification shows that the system has been tested and approved by the relevant company. This may
ease system compatibility issues involving different operating systems and statutory requirements.

DRAFT                                                                                                  47
                                             Appendix 4: Example of a generic questionnaire

Appendix 4

Example of a generic questionnaire
The following questionnaire was used to obtain information from software
companies/developers of computerised systems that could be used in a drug supply
business environment. It provides an example of the type of questions that could be
requested from suppliers, however it must be clear that when any such questions are
designed, the evaluation of the responses must also be considered together with the
capability of the organisation undertaking this process.

Section A -   Supplier Information

1. Your company name and address?
2. When and where was your company founded?
3. What was your annual turnover over the last three years?
4. Can you provide your annual accounts for the last three years?
5. How many employees do you have world-wide?
6. How many countries are you represented in?
7. In which countries are you represented?
8. How many installations do you have world-wide?
9. In how many countries is your system installed?
10. What local support is available?
11. What type of after sales support do you offer? Please describe your support
    policy, organisation and escalation procedures from your agent to your parent
12. What are your guaranteed support response times?
13. How many people are involved with Research and Development of your product?
14. Does your company have any strategic allies?
15. Do you have a declared strategic direction for your product for the future?
16. How are your agents or distributors selected?
17. What investment do you require from your agents or distributors in terms of
    training, organisation and equipment?
18. Could you give any reference installations related to Drug Management Systems?
19. Could you give any reference installations related to Drug Supply Systems?
20. Could you give any reference installations related to Inventory Management
21. Can you give any additional reference installations?
22. What is your maintenance policy and what are the costs involved (e.g. your
    upgrade release cycle and your maintenance fee)?
23. Please give your recommendation on staffing and their qualifications of a support
    organisation for the system?
24. On which level(s) would you recommend your system being utilised;
    International, Regional, and/or Community

Section B -   Technical Hardware Information

1. What type of operating system(s) does your system support?

DRAFT                                                                                   48
                                              Appendix 4: Example of a generic questionnaire

2. What type of data input devices does your system support?
3. What type of printers does your system support?
4. Is your system available in a single user installation?
5. What are the minimum hardware requirements for this type of installation?
6. What are the recommended hardware requirements for this type of installation?
7. Is your system available in a network version?
8. What type of network does your software support?
9. What is the maximum number of users possible?
10. What are the minimum hardware requirements for this type of installation?
11. What are the recommended hardware requirements for this type of installation?

Section C -    Technical System Information

1.  In what development environment was your system developed?
2.  Which Programming language was used?
3.  Can your system be customised for different types of installations?
4.  Does you system allow for third party add-on products?
5.  Who is qualified to carry out system customisation?
6.  In case of individual customisation, how do you ensure compatibility with future
7. Is the system source code available for viewing and how is it updated?
8. How easily can fields be added to the system?
9. What data compatibility does your system offer? (i.e. ODBC, ASCII files)
10. What database formats does your system support?
11. Is your system Year 2000 compatible?
12. How large are your unique identifier fields?
13. Are they alphanumeric?
14. What size are your strings?
15. What is the largest decimal number, which your system can calculate with?
16. What is the largest number of digits, which your system can display on screen?
17. How many different versions are available?
18. How many different versions are released each year, on average?
19. What versions are you currently supporting?
20. What is the name and latest version number of your software system?
21. Quality control. Which procedures do you follow before a new version is
22. How do you ensure version compatibility?
23. What additional functionality have you planned for future versions?
24. What are the possibilities for upgrading in the future and how future-proof is the
25. What connectivity to the Internet/e-mail services does the software support?
26. Does your system offer Intranet connectivity and if so, how is the firewall
    controlled within the system?
27. Does your system comply with ISO or OSF standards?
28. Do you have a demonstration version available free of charge?

Section D -    Training

1. Do you conduct your own training?

DRAFT                                                                                    49
                                                Appendix 4: Example of a generic questionnaire

2.   What qualifications do your training personnel hold?
3.   How many training personnel do you have world-wide?
4.   How are your training programmes carried out?
5.   What type of training material is available for your system?
6.   Are self -paced tutorials available?
7.   Please describe a recommended training plan for the system users and

Section E -      General

1. How are the different system components linked?
2. Does your system support multiple currencies?
3. In how many different languages are the system available?
4. Can these languages be used concurrently?
5. Can additional languages be added to e.g. reports?
6. What type of help facility is available within the system?
7. Is there an on-line help facility?
8. What type of user documentation is available?
9. What type of system documentation is available for the system?
10. What facilities are available to protect against entry of incomplete transactions?
11. Does the system suggest inputs where possible?
12. Does the system allow for on-line inquiry without having to print a report display?
13. Does the system support data import/export facilities? If yes, do these facilities
    apply to the entire database?

Section F -      Reporting

1.   Does your system have a built in report generator?
2.   Are there any supporting features built into this? (e.g. Report Wizard)
3.   Can you preview reports before printing?
4.   Does your system provide graphical output? Please specify (e.g. graph, chart, pie,
5.   What types of selection criteria are available when extracting data from your
     system? (e.g. SQL statements)
6.   Can you specify sorting criteria?
7.   Can you specify grouping criteria?
8.   Can you specify calculation criteria?
9.   Can you specify which fields to print?

Section G -      System/Data Security

1. Does your system allow for user IDs and passwords?
2. Does your system allow for a user-tracking log?
3. Can the system produce a complete log of all transactions and modifications done
   in e.g. one day?
4. Does your system provide user-specific menus?
5. Is it possible to restrict user‟s access to data entry and/or data retrieval?

DRAFT                                                                                      50
                                                 Appendix 4: Example of a generic questionnaire

6. What additional data security features does your software offer?
7. Is there data input validation available where possible?
8. How is data validated?
9. How does the system ensure data integrity?
10. How does your system react to power failure?
11. What type of error correction is supported by your system?
12. Does your system have a native data/software backup system?
13. Does the system allow for remote access by customers? If yes, how are they
    restricted to view and modify their own data only?

Section H -    Estimating drugs needs - Logistical forecasting

If the answer is no to the first question, go on to next section.

1. Does your system have a calculation model for estimation of drug needs? And is it
   able to forecast needs in e.g. one months time or for the coming year?
2. On which parameters is this formula based? What information is used to generate
   order quantities?
3. How will adjustments to this formula be activated?
4. Could estimation of needs be adjusted and prioritisation made, based on e.g. ABC
   analysis or change of service levels?
5. Does your system allow for drug need estimation and forecasting for multiple
   point sales; consolidated and individually?

Section I -    Distribution / Dispensing and rational use of drug

4. Does your system provide possibilities for generating reports on drug costs spent
   on specific drug groups?
5. Can the system perform calculation of WHO drug use indicators?

Section J -    Tender Processing

If the answer is no to the first question, go on to next section.

1. Does the system include a tender processing module?
2. How many evaluation criteria can be entered?
3. How can criteria be weighted?
4. Can the module generate a tender request report?
5. Can the system monitor outstanding quantities by item for the order as well as for
   the complete tender awards?
6. Can tender quotations be entered and an adjudication report be made?
7. Can a tender award list be prepared?
8. Can a tender contract be generated based on the awards?

DRAFT                                                                                       51
                                                 Appendix 4: Example of a generic questionnaire

Section K -    Procurement process

If the answer is no to the first question, go on to next section.

1. Does the software include a procurement module?
2. Can the system automatically create purchase orders based on previously
   calculated needs and forecasts?
3. Is it possible to enter supplies, which have not been purchased, such as donations?
4. Does the software have automatic calculation of minimum stock?
5. Can the module generate the following reports:
    Port clearance report
    Order status report
    Out of stock items
    Price comparison with on-line imported international prices
    Supplier performance based on previous quality control entry?

Section L -    Inventory management/ Receipt / Quality Control

If the answer is no to the first question, go on to next section.

1.  Does your system have an inventory management module?
2.  How is this module integrated with the remainder of the system?
3.  Does this module automatically generate entries in the General Ledger?
4.  What kinds of inventory classifications are available?
5.  Does the system allow for monitoring of stock levels and consumption for
    multiple branches?
6. Can you transfer stock items between different warehouses or locations?
7. Does the system allow for receipt of items into stock without immediate costing?
8. What kind of stock control performance indicators does the system support?
9. Are minimum order levels suggested?
10. Can the module perform a lead-time analysis report?
11. Can stock be reserved for sale?
12. Does the module give space for a quality control entry per received unit?
13. Is there a lock to ensure that quarantined products are not processed or where
    quality control results have not been entered?
14. Does the system include an automatic expiry notification/not to be issued
15. Can the module reproduce a receipt report?
16. How does the system handle returned goods?
17. Can your system monitor claims related to e.g. damaged/expired goods?
18. How are claims processed in your system?
19. Can the software monitor expiry dates and generate
     Expiry stock reports?
     Expiry date analysis?
     Expiry risk report? (Stock items at risk of expiring in stock)
20. Can the module generate:
     Journal?
     List of Items?
     Turnover?

DRAFT                                                                                       52
                                                 Appendix 4: Example of a generic questionnaire

       Picking Lists?
       Stock Lists?
       Physical stock status report?
       Stock detail report?
       Stock taking forms?
       Inventory variation report after inventory adjustment?
       Invoicing?
       Stock Ledgers?
       ABC analysis?
       Stock level projection by branch and consolidated?

Section M -    Financial Module

If the answer is no to the first question, go on to next section.

1. Does your system have a finance module for entering cash and financial
2. How many accounting dimensions does the module support?
3. Do these dimensions support individual hierarchies?
4. Are all dimensions supported throughout the system?
5. What identifying fields can you enter for each transaction?
6. Can you prevent direct entries into the General Ledger?
7. Can unbalanced debit/credit transactions be entered into the system?
8. Does the system allow posting to multiple accounts to be done in one transaction?
9. Can input journals be set up for recurrent transactions?
10. Does your module have an audit trail?
11. Can you book the same voucher twice?
12. Can you modify entries once they have been booked in the system?
13. Has your system been certified or approved by any operating system manufacturer
    or charted accounting company? Please give details.
14. Does you module allow for the entry of Financial budgets?
15. On what time frame are these budgets entered? (E.g. daily, monthly, quarterly)
16. Can you have more than one active budget at any one time?
17. Can the Finance module support VAT?
18. Can you post entries in previous accounting periods?
19. Which of the following reports are present in your module:
     Journal or Cash/Bank Book
     Accounting Codes (e.g. Chart of Accounts, Accounting Dimensions)
     Trial Balance
     Profit and Loss Accounts
     Budget Reports
     Balance/Budget Reports
     Ledger Cards
     Cash Forecasting
     Liquidity Reports

DRAFT                                                                                       53
                                                 Appendix 4: Example of a generic questionnaire

Section N -    Accounts Payable

If the answer is no to the first question, go on to next section.

1. Does your system have an accounts payable module?
2. Does your module have a supplier database?
3. Can the system suggest supplier payment conditions based upon cash available
   and supplier payment terms?
4. How is this module integrated with the remainder of the system?
5. Does this module automatically generate entries in the General Ledger?
6. What functionality does this module add to the system?
7. Which of the following reports are present in your module:
    Journal
    List of Suppliers
    Age Analysis
    Purchase Statistics

Section O -    Accounts Receivable

If the answer is no to the first question, go on to next section.

1.   Does your system have an accounts receivable module?
2.   Does your system have a list of customer details?
3.   Does the system calculate interest rates on overdue payments?
4.   How is this module integrated with the remainder of the system?
5.   Does this module automatically generate entries in the General Ledger?
6.   What functionality does this module add to the system?
7.   Can the system calculate Value Added Tax (VAT) automatically?
8.   Which of the following reports are present in your module:
      Journal
      List of Customers
      Age Analysis
      Sales Statistics
      Reminders
      Statement of Accounts
      Receipt of Payments Vouchers

Section P -    Fixed Assets

If the answer is no to the first question, go on to next section.

1.   Is there a fixed assets module in your system?
2.   Does it handle automatic depreciation?
3.   What types of depreciation methods are supported?
4.   Can you enter your own depreciation calculation method?
5.   Can your module handle sales and theft of Fixed Assets?
6.   How is this module integrated with the remainder of the system?
7.   Does this module automatically generate entries in the General Ledger?

DRAFT                                                                                       54
                                                 Appendix 4: Example of a generic questionnaire

8. Does the module support maintenance history?
9. Does the module handle insurance details?
10. Which of the following reports are available in your module:
     List of Assets‟ Details
     Depreciation to Date
     Cost of Maintenance to Date
     Insurance

Section Q -    Transport Management

If the answer is no to the first question, go on to next section.

1. Does your system have a transport management module?
2. Does the module assist with route planning in relation to local conditions/
   accessibility to certain roads etc.?
3. Possibility of cost comparison of different transport methods?
4. Record keeping for vehicle use and maintenance?
5. Possibility of manpower planning?
6. Can the system handle load management?
7. How is this module integrated with the remainder of the system?
8. Does this module automatically generate entries in the General Ledger?

Section R -    Personnel Management

If the answer is no to the first question, go on to next section.

1. Does your system include a personnel management module?
2. Does the module include detailed personnel records?
3. Can the system handle formal education and training information?
4. Does the system handle notes on personnel career ambitions?
5. Does your module handle resource management?
6. Can it suggest hourly allocation?
7. Can your module prepare payroll calculations?
8. Can your module prepare pay slips?
9. How is this module integrated with the remainder of the system?
10. Does this module automatically generate entries in the General Ledger?

Section S – Sales and distribution

1.   Can the system allocate stock when processing orders?
2.   Can stock automatically be allocated by expiry date?
3.   Is it possible to override automatic allocations?
4.   Can pick list be made based on both order and by location?
5.   Does the system allow issuing of non-cost items?
6.   Does a sales order processing performance monitoring system exist?
7.   Does the module facilitate the trace of specific batches?

DRAFT                                                                                       55
                                               Appendix 4: Example of a generic questionnaire

Section T – Pricing

1. What is the price of your system?
2. If it is of a modular composition, could you specify your pricing structure with a
   few examples?
3. What is the price of your after sales support?
4. What is the price of you training programmes?
5. How do you price on-call support?
6. What is the pricing structure of system customisation?

DRAFT                                                                                     56
                                                                                 Appendix 5: Modules inlcuded in the selected software systems

Appendix 5               Modules included in the selected software systems

FEATURES                        CLM    Concorde   Gemedic   Invec-2   Navision    SAP          Sun          Lawson         Nepal


Logistical forecasting          YES      YES       YES       YES        NO        YES           NO

Tender processing module        NO       NO         NO       YES        NO        YES           NO

Procurement management          YES      YES       YES       YES        NO        YES           YES

Inventory management            YES      YES       YES       YES       YES        YES           YES

Financial management            NO       YES        NO      MIN.       YES        YES           YES

Accounts Payable                NO       YES       MIN.     MIN.       YES        YES           YES

Accounts Receivable             NO       YES       MIN.     MIN.       YES        YES           YES

Sales and Distribution          YES      YES       YES       YES       YES        YES           YES


                                NO       YES        NO       NO        YES        YES           YES
Fixed Assets
                                YES      NO         NO       NO         NO        NO            NO
Transport management
                                NO       YES        NO       NO        YES        YES           NO
Personnel management

DRAFT                                                                                                                                      57
                                         Appendix 6: Addresses and fact sheets on selected suppliers

Appendix 6
Addresses and fact sheet                             AEDES                  GEMEDIC DOS ver. 2.2
on selected suppliers                                Agence Européenne pour le Développement et la
                                                     34 Rue Joseph II
1)                                                   B-1000 Brussels, Belgium
Lawson Software             Lawson Insight           Att.: Daniel Vanderbergh
                                                     Phone           32 2219 0306
1300 Godward St                                      Fax             32 2219 0938
Minneapolis MN                                       E-mail
Attn: John Townsend
Phone         1 800 477 13
                                                     Systems Union Group Ltd.            SunSystems
Fax           1 612 379 7141
                                                                                         Ver. 4.2
                                                     No 1 Hammersmith broadway
                                                     London W6 9DL
2)                                                   England
Navision Financial          Navision                 Att.: Niell Young
                            Ver. 3.56a               Phone         44 1252 378837
Frydenlunds Allé 6                                   Fax           44 1252 371559
DK 2950 Vedbæk                                       E-mail
Att.: Jens Lykkegaard
Phone           45 45 65 50 00
                                                     Columbus IT Partners           Concorde XAL
Fax             45 45 65 50 01
                                                     Krudtlobsvej 1
                                                     1403 Copenhagen K
3)                                                   DK – Denmark
SAP AG                      SAP R/3                  Att.: Martin Garbrecht
                            Ver. 4.0A                Phone          45 70 25 07 00
Neurottstrasse 16                                    Fax            45 70 25 07 01
D-69190 Walldorf                                     E-mail
Att.: Renate Giese/ Leo Schneider
Phone           49 62 27 340
                                                     CLM                    CLM Ver 2.06
Fax             49 6227 34 1282
                                                     Management Sciences for health
                                                     165 Allandale Road
                                                     Boston, MA 1973
4)                                                   Att.: Anne C Williams
MSH                  INVEC-2                         Phone
                     Ver.1.5                         Fax
Management Sciences for Health                       E-mail
1515 Wilson Boulevard, Suite 710
Arlington, VA 22209, USA
Att.: Julie McFadyen                                 9)
Phone           1 703 524 7893                       Nepal                     Own system
Fax             1 703 524 7898                       Medical Stores

DRAFT                                                                                            58
                                    Appendix 6: Addresses and fact sheets on selected suppliers

CLM Version 2.06
Supplier Information

The system was developed by Management Sciences for Health, Boston,
Massachusetts, USA. The system is currently installed at 7 locations in 7 countries
(e.g. Peru, Nicaragua, Nepal, Kenya, Madagascar), used by e.g. National
Immunisation Programmes and Family Planning NGOs and available in three
different languages English, French and Spanish. Allies include the Pan American
Health Organisation. The software is available as a non-commercial system, with a
possible strategy for an upgrade to a Windows platform.

Pharmaceutical Features

CLM software was developed for the purpose of medical supply handling, and has no
installation related to drug management or drug supply. In this relation the system has
the weakness of no tender module, no space for quality control entry per received unit
and no standard ABC analysis or inventory variation report after inventory
adjustment is available in the system. Without accounts receivable module the system
is weak in a sales function e.g. without the possibility of making clients consumption
analysis and budget. The systems strong asset is the transport management module,
making it attractive for vaccines handling.

Business Application Features

This system does not support the entry of financial transactions and has no Finance,
Accounts Receivable or Accounts Payable modules. However, there are Equipment
and Transport Management modules in the system. The system does not have a
Personnel or Fixed Assets system. The reporting system includes a report generator,
supports user selection and allows new reports to be added to the system. The system
does not support graphical output.

IT Specific Features

CLM offers excellent possibilities for use of user ID‟s and passwords, but no features
for restricting users access to data entry and/or data retrieval. The system addresses
small installations and doesn‟t support large, high-capacity Operating Systems. There
are no network-capabilities.

The system is developed in an older generation environment, and doesn‟t allow for
any customisation or add-on products. Only the supplier is allowed to make changes
to the program. The CLM system only offers limited system compatibility.
CLM states that its date fields allow for 4 digit years.


Cost involved in implementing this system is based upon paying for consultant time
used in installation and training.

They plan to have a free demonstration version available within the next six months.

DRAFT                                                                                       59
                                   Appendix 6: Addresses and fact sheets on selected suppliers

Concorde XAL Version 2.65
Supplier Information

Damgaard International, Birkerød, Denmark developed the system. The system is
installed at over 1000 locations in 17 countries and available in the following
languages at present: English, Danish, German, Norwegian, Swedish, Dutch, Russian,
Polish, Czech, Lettish, Latvian, Lithuanian, Hungarian and Chinese. They have
alliances with Microsoft, Oracle and IBM.

Pharmaceutical Features

The system was developed as a financial, inventory system applied to customers with
similar distribution and logistics processing as in the drug management and drug
supply-handling sector, but with no medico companies on their reference list.
Concorde system does not include specific tender features, and does not include
standard field for quality control entry, making supplier performance reports weak
only based on delivery adherence.
Procurement management, Inventory management and Sales modules include almost
all the essential and desirable features in an eligible DMIS system.

Business Application Features

The system has an integrated Financial system including General Ledger, Budgeting,
Accounts Receivable, Accounts Payable and Fixed Assets. The system also has a
Payroll module. The system does not have any Transport Management module.

The system has an integrated and flexible report generator, which allows for the
addition of any number of user-defined reports. It includes support for graphical
output on the screen only.

IT Specific Features

Concorde has excellent features for system/data security. The system supports a wide
variety of operating systems, offering a very good scalability and network capacity.

The system offers a very good data compatibility, and allows for extensive
modifications and add-on solutions. The customer can perform some modifications
after buying a separate tool – more elaborate customisation is performed by the

Concorde XAL is Year 2000 compliant.


The price of the system depends on the number of modules used, operating system
used and number of concurrent users – in addition to consultancy involved related to
installation and training.
They have a demonstration version available for USD 100 (to cover media costs).

DRAFT                                                                                      60
                                    Appendix 6: Addresses and fact sheets on selected suppliers

GEMEDIC Version 2.2
Supplier Information

The system was developed by AEDES (Agence Européenne pour le Développement
et la Santé) scrl, Brussels, Belgium as a non-commercial software. The system is
installed in 7 countries both at national and regional level (Chad, Central Africa,
Liberia, Cameroon, Guinea, Cambodia and Democratic republic of Congo) and
available in a French and English version.
The companies‟ strategic direction is no further development of GEMEDIC DOS
version, but with extension of the existing commercial system will there be placed
emphasise on an accounting management centred system.

Pharmaceutical Features

This system has as most of the others no tender processing module, together with the
lack of financial and accounting management it makes a software package with lack
of many essential features.
The inventory management module is presenting the most appropriate features in the
system even without the quality assurance record, while the logistical forecasting and
procurement management lack important functionalities.

Business Application Features

The system does not have a Finance module, but has some support for following up
on Accounts Payable and Accounts Receivable, including printing a number of
related reports. The system does not have any Fixed Assets, Transport Management
or Personnel Management modules.

The system has a report generator, which allows the user to select from a finite
number of combinations. The system does not support graphical output.

IT Specific Features

Gemedic has no facilities for user ID‟s and passwords, nor any possibility of
controlling access to the system. The system only supports the most basic operating
systems, and has no network capabilities.

Gemedic has possibilities for addition of functionality, requiring specially educated
staff or consultancy assistance. The system offers fair data compatibility, but only
supports one type of database.

Gemedic is Year 2000 compliant.


System software available free of charge. Cost involved in implementing this system
is based upon paying for consultant time used in installation and training.
They have a demonstration version available free of charge.

DRAFT                                                                                       61
                                    Appendix 6: Addresses and fact sheets on selected suppliers

INVEC-2 Version 1.5
Supplier Information

MSH Drug Management Program, Arlington, Virginia, and USA developed the
system on a non-commercial basis. The system is currently installed at 17 locations in
11 countries (e.g. Cambodia, Grenada, Commonwealth of Dominica, St Lucia, St
Vincent, Haiti, Zimbabwe, Zambia, Eritrea and Yemen) with the latest version only
available in English.
The Company‟s strategic direction is for the time being taken up to revision.

Pharmaceutical Features

The software system were developed for the purpose of drug management at national
level and have many specific pharmaceutical functionalities inclusive a tender
module. Weakness in the system is its lack of standard entrance field for quality
control activities and consequently poor supplier performance report possibilities.

The system is by the supplier recommended for use both at national and
district/community level, but has a higher score on essential features for users at
national level than for a lower level user group.

Business Application Features

The system has limited support for entering financial transactions and allows for the
entry of yearly budgets, but cannot produce financial reports. Both Customer and
Supplier databases exist. The system does not have any Fixed Assets, Transport
Management or Personnel Management modules.
The system has a report generator, which allows user queries to take place. The
system does not support graphical output.

IT Specific Features

Invec-2 possesses excellent features for system/data security. The system mainly
addresses smaller to medium installations and doesn‟t support large, high-capacity
Operating Systems.

Invec-2 is developed in an older generation environment, and only features limited
system adaptability and compatibility. All modifications have to be made by the
manufacturers own staff, and the system has a very limited choice of databases. The
system only allows for limited addition of extra functionality, to be developed by

The system only offers limited system compatibility. Invec-2 is Year 2000 compliant.


Cost involved in implementing this system is based upon paying for consultant time
used in installation and training.
They have a demonstration version available free of charge.

DRAFT                                                                                       62
                                     Appendix 6: Addresses and fact sheets on selected suppliers

Navision Financials Version 1.3
Supplier Information

The system was developed by Navision Software a/s, Vedbæk, Denmark. They are
represented in 27 countries and are installed at ca. 30,000 locations in over 75
countries. Their reference list related to Drug management include Pharmacia Upjohn
and related to Drug supply systems - Medical Store in Tanzania. They have alliances
with Microsoft, Citrix, TimeLine, Siemens-Nixdorf and IBM, and the software are
available in 18 different languages.

Pharmaceutical Features

The system is developed as a financial management system only slightly modified to
a drug management information software.
The system has a fair amount of inventory management features, but lacks some
essential specific pharmaceutical characteristics e.g. tender handling, logistical
forecasting and procurement module are all missing.
Among the inventory management features in their standard software there is no
space for a quality control entry or supplier performance monitoring report.

Business Application Features

The system has an integrated Financial system including General Ledger, Budgeting,
Accounts Receivable, Accounts Payable and Fixed Assets. The system also has a
Personnel Management module. The system does not have any Transport
Management module.
The system has an integrated and flexible report generator which allows for the
addition of any number of user-defined reports. It does not include direct support for
graphical output.

IT Specific Features

Navision Financials (NF) is a modern financial management information system,
based on previous experience from earlier systems.
NF is based on technology with excellent features pertaining to system/data security
and choice of operating system. NF‟s scalability and network capacity is quite good,
since the system is suitable for different sizes of operations, ranging from single user
stand alone installations to large network installations of approximately 250 users.
The system has a high degree of system compatibility, due to its utilisation of market
standards for data transfer, however only two specific types of databases are
supported by the system (ver. 2.0). The possibilities for individual customisation is
very good, even though major modifications require specially trained staff or
consultancy assistance. NF is certified Year 2000 compliant.

The price of the system depends on the number of modules used, operating system
used and number of concurrent users – in addition to consultancy involved related to
installation and training.
They have a demonstration version available free of charge.

DRAFT                                                                                        63
                                    Appendix 6: Addresses and fact sheets on selected suppliers

SAP System R/3 Version 4.0A
Supplier Information

SAP AG, Walldorf, Germany, developed the system. They are represented in ca. 90
countries, the system are available in approx. 30 different languages and have some
600 installations in 8 countries related to Healthcare Institutions. Among their
references can be found several hospital-pharmacies in Germany.

Pharmaceutical Features

Among the specific pharmaceutical criteria almost all-essential features can be found
in the SAP R/3 system – Materials Management module. A missing feature that can
be mentioned is no tender award list can be made. Unfortunately some questions were
unanswered by the company, and for that reason a complete picture of the software
system can not be made.

Business Application Features

The system has an integrated Financial system including General Ledger, Budgeting,
Accounts Receivable, Accounts Payable and Fixed Assets. The system also has a
Personnel Management module. The system does not have any Transport
Management module.

The system has an integrated and flexible report generator, which allows for the
addition of any number of user-defined reports. It also includes support for graphical

IT Specific Features

SAP is a highly developed management information system, which features excellent
system/data security on all levels.

Due to the fact that SAP mainly cater for large and even very large installations,
SAP‟s choice of Operating Systems isn‟t very well suited for small installations. The
network scalability is quite good, when larger installations are in focus.

SAP supports a wide variety of large standard databases, and features the possibility
of a high degree of customisation to suit each customer. This customisation has to
take place in SAP‟s own programming environment, and is typically carried out by
consultants or specially trained staff. The system handles almost any size of entries.

SAP is certified Year 2000 compliant.


The price of the system depends on the number of modules used, operating system
used and number of concurrent users – in addition to consultancy involved related to
installation and training.
They do not have a demonstration version available free of charge.

DRAFT                                                                                       64
                                    Appendix 6: Addresses and fact sheets on selected suppliers

SunSystems Version 4.2
Supplier Information

Systems Union Limited, London, UK, developed the system. There are over 15,500
installations in 172 countries, and the company is represented in 65 countries. They
have alliances with Microsoft, IBM, Sybase, Oracle, HP and Digital and 24 languages
are currently available.

Pharmaceutical Features

In the SunSystem no tender module is provided and no function for estimating drug
needs. Else almost all other essential pharmaceutical specific features can be found in
the software system and the inventory management system is in particular strong.

Business Application Features

The system has an integrated Financial system including General Ledger, Budgeting,
Accounts Receivable, Accounts Payable and Fixed Assets. The system does not have
any Transport Management or Personnel Management modules.

The system has an integrated and flexible report generator, which allows for the
addition of any number of user-defined reports. It also includes support for graphical

IT Specific Features

SunSystems has excellent features for system/data security. The system supports a
wide variety of operating systems, offering a good scalability and network capacity.

SunSystems is a packaged product and customisation of the core product is not
permitted. The system does allow for third party add-ons. There is a high degree of
data compatibility, and the system supports several of different databases.

SunSystems is Year 2000 compliant.


The price of the system depends on the number of modules used, operating system
used and number of concurrent users – in addition to consultancy involved related to
installation and training.

Information regarding a demonstration version is available on request.

DRAFT                                                                                       65
                                Appendix 6: Addresses and fact sheets on selected suppliers

Lawsons JYTTE
Supplier Information

Pharmaceutical Features

Business Application Features

IT Specific Features


DRAFT                                                                                   66
                                Appendix 6: Addresses and fact sheets on selected suppliers

Nepal Medical Stores Jytte
Supplier Information

Pharmaceutical Features

Business Application Features

IT Specific Features


DRAFT                                                                                   67
                                                              Appendix 7: Generic checklist for DMIS

Appendix 7

Generic checklist for DMIS systems (from questionnaire)
1)       General classification characteristics

     Training methods/ availability                               D – 1-4
     Training material                                            D – 5-6
     Multiple languages                                           E - 3-5
     Documentation/ On-line help                                  E – 6-9

2)       Specific pharmaceutical characteristics (Essential functions and features)

     Drug/ budget needs forecasting – Consumption method          H-1, H-2, H-3
     ABC analysis                                                 L-20, H-4
     Tender request report                                        J-4
     Adjudication report                                          J-2, J-3, J-6
     Supplier performance monitoring report                       K-5
     Tender awards list                                           J-7
     Purchase order generating                                    K-2
     Calculation of minimum stock                                 K-4
     Out of stock report                                          K-5
     Currency conversion and adjustment for trade terms           E-2
     Receiving report.                                            L-15
     Quality assurance record                                     L-12, L-13
     Product list with specifications                             L-20
     Updating inventory databases                                 L-1, L-2, L-3
     Stock detail report                                          L-20
     Inventory adjustment report                                  L-20
     Expiry stock report                                          L-19
     Expiry date analysis or expiry risk report                   L-19
     Stock control performance indicators                         L-8
     Picking lists - Functional list                              L-20
     Returned goods handling                                      L-16, L-17, L-18
     Stock allocation by expiry date and batch traceability       S-2, S-7
     Therapeutic category analysis                                Not in questionnaire

3)       Desirable specific pharmaceutical functions and features as addition to the ideal system

     Drug need estimation for multiple point sales               H-5
     Drug cost spending on specific drug groups                  I-1
     Manage simultaneous tenders                                 Not in questionnaire
     Tender contract generation                                  J-8
     Order status report                                         K-5
     Price comparison features                                   K-5
     Entering donated pharmaceutical/ supply                     K-3
     Port clearance report                                       K-5, L-17, L-18
     Lead-time analysis                                          L-10
     Receipts report for specific periods                        L-15
     Stock taking forms / physical stock inventory report        L-20
     Automatic expiry notification                               L-14
     Multiple warehouse implementation                           L-5, L-6
     Stock allocation during order processing                    S-1
     Clients' consumption analysis and budget                    O-8
     Emergency orders                                            Not in questionnaire
DRAFT                                                                                            68
            Appendix 7: Application of weighting system in evaluation of selected software systems

  Stock reservation for sale                                 L-11
  WHO drug use indicators                                    I-2

DRAFT                                                                                          69
                                                Appendix 8: Sample of weighted requirements

Appendix 8

Sample of weighting requirements
In analysing the essential business, IT specific and general areas of various systems a
number of functions can be highlighted in each, e.g. accounting dimensions, audit
trail, budgeting, VAT support and reports in the Finance module. Each function can
be evaluated in relation to each of the systems and given a score from 0 to 5
depending upon its existence and its properties.

Based upon these marks, each area could score a maximum number of points in each
system, e.g. 25 points for the „Finance‟ module, 20 points for the „Accounts
Receivable‟ module and 20 points for „Technical Hardware Information‟. However,
the points available do not reflect the relative importance of each functional area. For
example, the functionality of the Finance module may be deemed more important
than the Accounts Receivable module; therefore a weighting system is required.

In this example 200 points in total were allocated to the evaluation of the systems, i.e.
an ideal system would score 200 points. A greater focus has been placed on the
Pharmaceutical criteria which have been allocated half of these points (100 points),
with the Business System and IT Specific criteria allocated 45 points each and the
General criteria allocated 10 points.

The weights allocated to each overall area are further sub-divided into each of the
essential functions within these areas; i.e. the Finance module is given 20 points, and
the Accounts Payable and Accounts Receivable modules 5 points each. Once again,
these points indicate the maximum attainable.

After this was completed, the actual scores given for each feature were converted into
a weighted value. For example, the area „Technical System Information‟ was
evaluated based upon three criteria of 5 points each, giving a total maximum score of
15. The weighted value of this are was 10. Thus, the weighted value was attained
using the following formula:


                   where:    W is the Weighted value,
                             A is the Actual score attained,
                             M is the Maximum possible score and
                             V is the maximum weighted Value possible.

As an example, a system may score 12 points on Technical System Information from
a maximum of 15 points during evaluation. As this overall area is weighted at 10, the
value must adjusted to fit into the range from 0-10. The score of 12 will thus be
adjusted using the above formula: 12 / 15 * 10, which is equal to 8 out of a possible

DRAFT                                                                                   70
            Appendix 9: Application of weighting system in evaluation of selected software systems

Appendix 9
Application of weighting system in evaluation of selected
software systems

The evaluation of the selected Drug Management Information Systems is based
purely on the information provided from the software suppliers from the questionnaire
shown in Annex , and following additional information requested from the suppliers
involved. No demonstration of any of the systems has been undertaken in this
evaluation, therefore the figures should be viewed with some caution as actual
application and use of the systems has not been evaluated.

SOFTWARE                                        SUPPLIER
CLM Ver. 2.06                                   Management Sciences for Health, USA
Concorde XAL V. 2.65                            Columbus IT Partners, Denmark
Gemedic Dos Ver.2.2                             Agence    Européenne        pour   le
                                                Developpement et la Santé, Belgium
Invec-2 Ver. 1.5                                Management Sciences for Health, USA
Navision Ver. 3.56a                             Navision Financial, Denmark
SAP R/3 Ver. 4.0A                               SAP AG, Germany
Sun Systems Ver. 4.2                            Systems Union Group Ltd., UK
                                                Nepal Medical Stores

The intent of this evaluation is to compare the functionality of several different
storage- and information-systems, in order to establish their suitability as a Drug
Management Information System, and assess their individual performance with a
strong pharmaceutical bias.

Evaluation sheets on the selected evaluation criteria are to be found in Annex ? and
the weighted results can be found below in Table 5.

DRAFT                                                                                          71
                                                                        Appendix 9: Application of weighting system in evaluation of selected software systems

 Table 5: Application of weighted system in evaluation of selected software

Essential Functions                Weight   CLM     Concorde   Gemedic        Invec-2       Navision        SAP           Sun         Lawson         Nepal
Specific pharmaceutical Criteria
Logistical forecasting               15     10.5      13.5        7.5            15            7.5          13.5           4.5
Tender module                        20      0         3           0             15             0            15             0
Procurement management               15      9         15         3.8           11.3           3.8           15           13.5
Inventory management                 50      39       46.4       38.2           40.9          43.6          45.5          45.5

Pharmaceutical Total                100     58.5      77.9       49.5           82.2          54.9           89           63.5

Business System Criteria
Finance Module                       20      0        18.4         0             5.6          18.4          19.2          18.4
Accounts Payable                     5       0         4.7        3.3             4            5             5             4.7
Accounts Receivable                  5       0         4.8        2.5            3.3           5             5             4.8
Reporting                            15      15        15          9             15            15            15            15
Total                                45      15       42.8       14.8           27.9          43.4          44.2          42.8

IT Specific Criteria
Technical Hardware Information       10       5        8.5         5             6.5           9.5            8            6.5
Technical System Information         10       4         8         6.7             6            8.7           8.7           7.3
Year 2000 Compliance                 10       8        10         10             10            10            10            10
System/Data Security                 15      7.5       15          0             15            15            15            15
Total                                45     24.5      41.5       21.7           37.5          43.2          41.7          38.8

Training                             5       1.5       3         1.5              2            3.5           4.5            3
Miscellaneous                        5        3       4.5         2               2            4.5           4.5           4.5
Total                                10      4.5      7.5        3.5              4             8             9            7.5

Other Criteria Total                100      44       91.8       40             69.4          94.6          94.9          89.2

Overall value                       200     102.5    169.7      89.5           151.6         149.5         183.9         152.7

 DRAFT                                                                                 72
To all: should we put in these individual evaluations?

Evaluation sheets on the selected evaluation criteria

The first sheets included shows the actual scores obtained by each of the systems for the overall
essential and desirable features for specific Pharmaceutical criteria, the Business System, IT Specific
and General criteria which were measured. The final sheet shows the weighted values obtained for the
essential features.

As the same Business System, IT Specific and General criteria are generally deemed essential for both
International/National and District/Community level, no distinction is made between the two user
levels. While some specific pharmaceutical criteria will distinguish between the two different user
levels, and the evaluation results will be separated for users at International/National level and for users
on District/Community level.
                         Feature                            CLM   Concorde Gemedic   Invec-2   Navision   SAP     Sun     Lawson   Nepal
Essential Features                                                                                              Systems
Specific pharmaceutical characteristics

Logistical forecasting
H - 1-3                  Drug/budget needs forecasting       5       4        5        5          0        4       0
L-20, H-4                ABC analysis                        2       5        0        5          5        5       3

Tender module
J-4                      Tender request report               0       0        0        5          0        5       0
J-4                      Adjudication report                 0       0        0        5          0        5       0
K-5                      Supplier performance monitoring     0       3        0        0          0        5       ?
J-7                      Tender awards list                  0       0        0        5          0        0       0

Procurement management
K-2                    Purchase order generating             2       5        5        0          0        5       5
K-4                    Calculation of minimum stock          5       5        0        5          0        5       5
K-5                    Out of stock report                   5       5        0        5          0        5       3
E-2                    Currency conversion                   0       5        0        5          5        5       5

Inventory management
L-15                     Receiving report                    5       5        5        5          5        ?       5
L-12-13                  Quality assurance record            0       3        0        1          0        5       5
L-20                     Product list                        5       5        5        5          5        5       5
L-1-3                    Updating inventory databases        3       5        3        3          5        5       5
L-20                     Stock detail report                 5       5        5        5          5        5       5
L-20                     Inventory adjustment report         4       5        5        5          5        5       ?
L-19                     Expiry stock report                 5       5        5        5          5        5       5
L-19                     Expiry data analysis/risk report    5       5        5        5          5        5       5
L-8                      Stock control performance ind.      3       3        1        2          4        5       5
L-20                     Picking list                        5       5        5        5          5        5       5
L-16-18                  Returned goods handling             3       5        3        4          4        5       5
Essential Features         Feature                 CLM   Concorde Gemedic   Invec-2   Navision   SAP     Sun   Lawsons Nepal
Business System Criteria

Finance Module
M-2-4                      Accounting Dimensions    0       5        0        1          3        5      5
M - 5-7,10-12              Audit Trail              0       5        0        3          5        5      5
M - 14-16                  Budgeting                0       3        0        3          5        4      4
M – 17                     VAT Support              0       5        0        0          5        5      5
M – 19                     Reports                  0       5        0        0          5        5      4

Accounts Payable
N–2                        Supplier Database        0       5        5        5          5        5      5
N - 4-5                    Integration              0       5        2        5          5        5      5
N–7                        Reporting                0       4        3        2          5        5      4

Accounts Receivable
O–2                        Customer Database        0       5        5        5          5        5      5
O - 4-5                    Integration              0       5        2        5          5        5      5
O–8                        Reporting                0       4        3        3          5        5      4
O–7                        VAT Calculation          0       5        0        0          5        5      5

K-5                        Order status report      5       5        0        5          0        5      5
F–3                        Previewing Reports       5       5        5        5          5        5      5
F–5                        Selection Criteria       5       5        3        5          5        5      5
F - 6-9                    Sorting Criteria         5       5        1        5          5        5      5
Essential Features               Feature                         CLM   Concorde Gemedic   Invec-2   Navision   SAP     Sun     Lawson   Nepal
IT Specific Criteria

Technical Hardware Information
B-1                              Operating Systems                3       5        2        3          5        4       5
B-2                              Data Entry                       2       4        2        2          5        4       2
B–3                              Printing Facilities              3       4        4        4          5        4       3
B – 4-11                         Network/Scalability              2       4        2        4          4        4       3

Technical System Information
C – 1-8                          System Base/Adaptability         2       4        3        2          4        4       3
C – 9-10                         System Compatibility/Capacity    2       4        3        3          4        4       4
C – 12-16                        Size of Entries                  2       4        4        4          5        5       4

Year 2000 Compliance
C – 11                           Year 2000 Compliance             4       5        5        5          5        5       5

System/Data Security
G–1                              User IDs and Passwords           5       5        0        5          5        5       5
G-5                              User Access Control              0       5        0        5          5        5       5

Essential Features               Feature                         CLM   Concorde Gemedic   Invec-2   Navision   SAP     Sun

D - 1-4                          Training Methods/Availability    1       3        1        2          4        4       3
D - 5-6                          Training Material                2       3        2        2          3        5       3

E - 3-5                          Multiple Languages               2       4        3        1          4        4       4
E - 6-9   Documentation/On-Line Help   4   5   1   3   5   5   5
Desirable Features Feature                                    CLM Concorde Gemedic Invec-2 Navision SAP SunSystems
International and national user level
Specific pharmaceutical characteristics
Estimating drugs needs
H-5                      Drugs estimate multiple point            0        3       0      3       0    3             0

Distribution/ dispensing drugs
I-1                        Spendings on specific drugs            4        4       5      4       0    4             0

Tender processing
J-8                       Tender contract generating              0        0       0      0       0    5             0

Procurement process
K-5                       Price comparison features               0        4       0      0       0    0
K-3                       Entering donated drugs                  5        5       5      5       0    5             5
K-5, L-17-18              Port clearance report                   0        5       0      0       0    5             3

Inventory management
L-10                      Lead-time analysis                      3        4       0      5       5    5             2
L-15                      Receiving report specific periods       5        5       5      5       5    ?             5
L-20                      Stock taking forms/inventory rep.       5        5       0      5       5    5             3
L-14                      Automatic expiry notification           0        0       5      5       0    5             1
L-5-6                     Multiple warehouse implement.           3        5       0      3       5    5             5

Sales and distribution
S-1                       Stock allocation during process.        5        5       5      5       5    5             5
S-2, S-7                  Batch traceability                      5        4       0      5       0    5             5
O-8                       Clients' consumption                    0        5       5      0       5    5             3
L-11                      Stock reservation for sale              5        5       5      5       5    5             5
Desirable Features Feature                                   CLM Concorde Gemedic Invec-2 Navision SAP SunSystems
District and community level users
Specific pharmaceutical characteristics
Logistical forecasting
H-5                      Drugs estimate multiple point           0        3       0      3       0    3             0

Procurement process
K-5                      Order status report                     5        5       0      5       0    5             5
K-3                      Entering donated drugs                  5        5       5      5       0    5             5

Inventory management
L-20                     Stock taking forms/inventory rep.       5        5       0      5       5    5             3
L-14                     Automatic expiry notification           0        0       5      5       0    5             1

Sales and distribution
S-1                      Stock allocation during process.        5        5       5      5       5    5             5
S-2, S-7                 Batch traceability                      5        4       0      5       0    5             5
O-8                      Clients' consumption                    0        5       5      0       5    5             3
I-2                      WHO drug use indicators                 0        0       0      0       0    0             0
Desirable Features         Feature                        CLM Concorde Gemedic Invec-2 Navision SAP SunSystems
Business System Criteria
Accounts Payable
N-3                        Generating Payment Schedules       0        3       0      0       5    0             3

Accounts Receivable
O-3                        Interest Calculation               0        3       0      0       4    5             3

Fixed Assets
P - 2-5                    Depreciation                       0        3       0      0       5    5             3
P - 6-7                    Integration                        0        5       0      0       5    5             5
P - 8-9                    Maintenance and Insurance          0        5       0      0       5    4             2
P - 10                     Reporting                          0        5       0      0       5    5             3

Transport Management
Q - 2-6                    Route Planning and Costing         2        0       0      0       0    0             0
Q - 7-8                    Integration                        3        0       0      0       0    0             0

Personnel Management
R - 2-4                    Personnel Records                  0        5       0      0       5    5             0
R - 5-6                    Resource Planning                  0        5       0      0       5    4             0
R - 7-8                    Payslips                           0        5       0      0       5    5             0

F - 1-2                    Report Generators                  3        5       3      4       5    5             5
F-4                        Graphical Output                   0        2       0      0       0    5             5

Desirable Features         Feature                        CLM Concorde Gemedic Invec-2 Navision SAP SunSystems
IT Specific Criteria
System/Data Security
G - 2-3                    User Tracking Log                  3        5       0      5       5    0             5
G-4                        Use Specific Menus                 0        5       0      0       5    5             5
G - 7-8                    Data Input Validation              5        5       5      5       5    4             5
G - 10   Power Failure Protection   0   4   1   1   5   4   3
G - 13   Remote Access              0   5   0   0   5   5   5
                                                                  Appendix 9: Requirements for a DMIS

             To all : Do the current sections need to be expanded with this

             Connectivity with Other Systems
Either the system should link directly with another computer system, internal or external to our
organisation, or there should be the facility to export the data into another system. Equally, we may
need to import data into the new system from an external source.

For example: we have built up a number of useful data manipulation programs to aid management
reporting; we are required to export data to an external organisation for audit purposes; at times we
may be required to bulk load the system with new data.

             Report Generation
Most systems should come with some means of generating reports, and in fact should hold a standard
library of reports, e.g. ABC analysis type reports. However, the ease, flexibility, and power of reporting
may vary quite considerably from one system to another. We may also need to perform quite complex
ad hoc queries. Should we decide to choose a system with relatively poor reporting capabilities, there
may be third party reporting tools that can be purchased to extend reporting ability. Again, we should
ensure compatibility between the two.

             Conversion of Legacy Data
Current and archived data are still important information for us: current data to close off end of year
processing and archived data for management reports and trends analysis and for statutory reasons. We
should ensure the data tables of the new system will be able to store our required information, and we
need to investigate who will be able to perform the conversion: either ourselves, the supplier, or
someone else.

The security of the new system should reflect, or improve on, our current business model of which user
has what type of authority and responsibility, and to what level. If we have or intend to have a sizeable
number of users, we should consider how user friendly is the system in maintaining user security. For
example, a system may specify security only at the individual user level, or it can specify security at a
group or multi-group level. If we had to change access rights for every member of a group, the former
would require changes to each individual; the latter just to the group(s).

             Disaster Recovery
Disaster recovery encompasses:
 the ability to retrieve data that is as up to date as possible in the event of data loss
 The ability to continue with business processing in the event of primary system failure.

The first is to do with ensuring we have some means of backing up our critical data on a regular basis,
being able to store these backups in a safe place (we may wish to store a copy in a separate location
from our office for additional security), and being able to restore this data and recover from the original
problem with the minimum of delay.

The second is dependant on how crucial is our requirement to have a computer system running all the
time, i.e. can we make do with a manual system during the period of system failure and catch up later,
or must we have a duplicate running system that is immediately activated as the primary one fails. The
latter example would entail the parallel running of a secondary server system and the complexity of
maintaining two concurrent data sets. An expensive option, which I don‟t think, many of us will
require, though we should consider how the business would respond during periods of computer
                                                               Appendix 9: Requirements for a DMIS

We may specify hardware requirements if we need to abide by policies or statutory requirements, or if
there were any specific hardware requirements we need. If we have insufficient skills within our
organisation to make any judgements on this issue we can refer suppliers‟ recommendations to known
third parties. The later section, Technical Options, provides further details on this.

To top