annex 1. technical requirements (based upon the initial ... · technologies. in addition, the vmis...

1

Annex 1. TECHNICAL REQUIREMENTS (Based upon the initial assessment)

2

CONTENTS

1. FUNCTIONAL REQUIREMENTS .....................................................................................................3

1.1. Conceptual Architecture .............................................................................................................. 3

1.2. Users/Actors ................................................................................................................................ 5

1.3. LIST OF REQUIREMENTS .............................................................................................................. 6

1.4. BUSINESS-PROCESSES ................................................................................................................ 29

2. SOFTWARE RELATED NON-FUNCTIONAL REQUIREMENTS .......................................................... 39

2.1. Requirements regarding system architecture ........................................................................... 39

2.2. Requirements regarding technology ......................................................................................... 42

2.3. Requirements regarding interoperability .................................................................................. 45

2.4. Requirements regarding informational security ....................................................................... 45

2.5. Performance requirements ....................................................................................................... 47

3. Centralized Databases .............................................................................................................. 48

4. Software Backup ...................................................................................................................... 49

5. Disaster Recovery and Business Continuity ................................................................................ 50

6. Software and User Documentation ........................................................................................... 51

7. Testing, Quality Assurance and UAT .......................................................................................... 52

8. Venue for Software Development/Customization ...................................................................... 55

9. License Agreement and Supply of Source Code .......................................................................... 56

10. Software Support ..................................................................................................................... 57

11. System Lifetime ........................................................................................................................ 58

12. Scale up for The Entire Country ................................................................................................. 59

13. Requirements for Hardware ...................................................................................................... 60

14. Server Room Requirements ...................................................................................................... 61

3

1. FUNCTIONAL REQUIREMENTS

1.1. Conceptual Architecture

Fig.1 Conceptual architecture of VMIS

The diagram showed in Fig. 1 represents the basic actors, which must be involved in the VMIS.

The most important are warehouses at central (republican), regional, district levels

The System will allow providing data on operations like receiving, transferring, write-off and

inventory:

- Through a graphical user interface – by entering needed data manually in a special electronic form. the system will perform some calculations automatically, based on entered data;

At the primary level, in policlinics and vaccination cabinets the responsible users will have the

possibility to provide all needed data on vaccine consumption such as: data on patient, vaccine, dose,

lot, series, etc. All consumption reporting may be done automatically by the System’s Analytic and

Reporting Module, as well as wastage calculations and other stock calculations, at any level.

4

Fig. 2 Conceptual decomposition of the System’s levels (including all three implementation

stages)

Taking into account the As-Is situation in the Uzbekistan’s centers for Sanitary-Epidemiological

Surveillance, it is recommended to implement the Vaccine Management Information System which

would include at least the following major features:

• Tracking of the procured quantities of vaccines;

• Batch & Expiry Management;

• Management of the contracts related to the supply of vaccines;

• Stock management of vaccines at central and regional, district and local levels (receiving,

transferring, write-off, inventory, consumption);

• Demand Forecasting and stock out (25% buffer) + alarm system close to stock out;

• Search and reporting features for ensuring real-time access to the verification of availability of

vaccines at any level;

• Data analytics, Reporting and Dashboards.

5

Fig. 3. Diagram of System components

1.2. Users/Actors Error! Reference source not found.Fig. 4 below is a high-level representation of the users/actors of

the VMIS. It depicts the external users, staff of the involved entities, support staff, and systems

involved in delivering the VMIS. The arrows (a generalization relationship) indicate organization

structure to a certain extent, but are meant to represent the inheritance of access rights. The users

6

presented will have their specific roles in the VMIS and each with its own functions and

responsibilities.

The external information systems, which will be used to exchange data with, are not shown in the

users/actors diagram. This is because the data exchange between the VMIS and the external sources

of information will be implemented through secured web-services.

Fig. 4 Involved Actors

1.3. LIST OF REQUIREMENTS The VMIS shall be implemented as a modular platform based on Service Oriented Architecture (SOA)

and that would allow the integration with other relevant ICT solutions in the health sector of

Uzbekistan.

VMIS as a modular platform must emphasize separating the functionality of the System into

independent, interchangeable modules, such that each contains everything necessary to execute

only one aspect of the needed functionality.

According to SOA principles, a service logically represents a business activity in real life with a

specified outcome. Thus, the System Architecture must allow exposing such services as VMIS must

allow in the future different user interfaces to work with the same data source.

Also, VMIS must provide rich web interface which has many of the characteristics of desktop, but

delivered through a standard web browser by using extensive use of JavaScript, HTML5 and similar

technologies. In addition, the VMIS solution must be based on Responsive Web Design (RWD)

approach, which allows web interfaces to render well on a variety of devices and windows or screen

sizes for mobile devices such as smartphones, tablets, etc.

Each functional requirement is labelled with FRQ prefix and could have the following marks:

− (M) = Mandatory = “The System must ...”;

− (HD) = Highly Desirable = “The System shall ...”; and

7

− (D) = Desirable = “The System may ...”;

, where:

− MUST – means that the requirement is defined is an absolute have requirement;

− MUST NOT – means that the numbered requirement is defined is an absolute prohibition.

SHOULD – means that there may exist valid reasons in particular circumstances to ignore a

particular item, but the full implications must be understood and carefully weighed before

choosing a different course.

Each functionality has the accompanying use-case diagram, which elaborates the requirement in a

more detail way and presents the business context in which the System functionality is used. The

detailed design that will be provided by the Contractor will have the detailed description of the

functionalities.

Functional Requirements for the Vaccine Supply Planning and Procurement Module

Identifier Name Type Description

FRQ001 Calendar of preventive vaccinations

M The VMIS must provide a dedicated user interface for registering the national Calendar of preventive vaccinations in Uzbekistan. Based on the aforementioned calendar, further, the calculation list of the needed vaccines is developed.

FRQ002 Data collection related to the vaccines demand

M The VMIS solution must provide a dedicated user interface that allows users at certain level/medical institution to specify the demand for vaccines.

FRQ003 Information on needed vaccines

M During the process of demand recording, the System will register all information on requested vaccine, quantity, stock on-hand, and other related information to vaccines.

Also the System will record the information related to the entity which requests the vaccines: ID and name of the institution, region, district, responsible person, etc.

FRQ004 Using official national list of vaccines in Uzbekistan

M The System must operate only with the vaccines that are officially registered in Uzbekistan.

FRQ005 Vaccine distribution lists M The VMIS solution will allow responsible users to create and save distribution lists of vaccines.

Republican level creates distribution lists for the regions.

8


Regional levels create distribution lists for district levels.

District level creates distribution lists for its subordinated medical institutions.

FRQ006 Data on budget for procurement of vaccines

M The proposed System must allow MoH users to store and manage information on approved budget for the procurement of vaccines.

FRQ007 Previous ToRs related to the procurement of vaccines

M The System must keep all previous ToRs related to the procurement of essential vaccines during the past periods.

FRQ008 Regulatory base related to the procurement process of vaccines in Uzbekistan

M The System must keep all needed regulatory documents related to the procurement process. The users must have the possibility to access the legal information regarding the procurement process of vaccines in Uzbekistan.

FRQ009 Management of ToRs M The System must provide functionalities for creation and storage of ToRs for the procurement of vaccines. During this process, users must have access to the following information managed by the System:

- Approved consolidated report on vaccines demand;

- Indicative prices; - Approved budget; - Required quantities.

FRQ010 Publish ToRs D Similar to the formation and approval of the nomenclature, the System must be integrated with an intranet that would allow publishing the ToRs as part of knowledge management and experience sharing between regions (internal process only_)

FRQ011 Approval of the ToRs D The relevant user from MoH must have the possibility to approve the ToRs.

FRQ012 Record procurement requests to international organizations

D The System must allow MoH users to document the requests for procurement to the international organizations. For this purpose, the System will record into the database all the data related to a request and will allow to upload and save all needed documents.

FRQ013 Management of estimates

M All estimates should be submitted through electronic document management workflows.

FRQ014 Contract management D The System will provide functionalities for management of contracts with Suppliers of vaccines. It will allow users to upload scanned copies of

9


contracts and filling all related metadata, as well as setting certain alert rules (e.g. alerts related to the scheduled deliveries of vaccines).

FRQ015 Tracking relations with suppliers

M The System will provide all necessary features and reports for tracking relations with the Suppliers.

Fig. 6 Use Case diagram related to the Procurement and Supply Manager’s main activities

10

Functional Requirements for the Module for Collecting Data on Needs for vaccines


FRQ016 Collecting data regarding the needs for vaccines in the medical institutions

M The System must provide a dedicated module and graphical user interface for the data collection process regarding the needs for vaccines in medical institutions.

FRQ017 Collecting data from regions/medical institutions

M The users from the regions/medical institutions must have the possibility provide information on the vaccines, required quantity and related planned indicators. The System will automatically calculate all the necessary amounts of vaccines.

FRQ018 Taking into account all relevant information

M The VMIS software solution must take into account the stock on-hand of vaccines and their shelf life, planned budget for procurement, planned supplies and other relevant parameters (to be established during the analysis and design phase).

FRQ019 Confirmation by using digital signature

M All provided data regarding the needs for vaccines in the medical institutions/regions will be confirmed by the user by applying the digital signature.

FRQ020 Data consolidation M The System will automatically consolidate all collected data from the regions.

Therefore VMIS will consolidate all saved requests of vaccines from all the regions and will apply all necessary calculation algorithms in order to create a consolidate list of vaccines needed to be procured.

FRQ021 Consolidated Report on vaccine demands

M All collected data regarding the needs for vaccines in the regions will be consolidated in a form of Report, which can be adjusted until it is digitally signed.

FRQ022 Approval by using digital signature

M The approval process will be carried out through the digital signatures of the responsible users.

In this regard, the VMIS will use the digital signature, which is issued by the Scientific Information Center of New Technologies of the State Tax Committee of the Republic of Uzbekistan and its regional offices.

FRQ023 Comparative analysis and other relevant analytics

M The System must provide reporting functionalities and Business Intelligence tools in order to be possible to make comparative analysis of the information regarding the needs for vaccines vs information of the past periods.

FRQ024 Additional or refined requests

M The system should provide the possibility to make an additional or refined request regarding the needs for

11


vaccines, depending on possible savings or deficits during the procurement process.

Fig. 7 Use case diagram related to the process of requesting vaccines

Functional Requirements for the Warehousing and Inventory Module

This Module represents in fact the stock management of vaccines and other vaccines, also known as inventory management, and involves all the policies, procedures, and techniques used to maintain the

12

optimum amount of each item in stock. It involves ordering, receiving, storing, issuing, and reordering items. Stock and inventory management are the core of the vaccines supply system.

Fig. 8 Use case diagram related to the Warehousing and Inventory Module


FRQ025 Real-time information M The module should reflect in real time the receipt of vaccines, real balances, and shipping requests.

FRQ026 Warehousing operations M The System must offer all necessary functionalities related to the stock management of vaccines: receiving, shipping, write-off and inventory operations. In other words, the proposed software solution must assure the management of stock transactions: entries into and exits from stock, transfers between warehouses, stock inventory and

uc Warehousing

System

Warehouse Operator

(from

Actors)

Athentication

Confirm receiv ing of

v accines

Write-Off operation

Shipping operation

Run Reports

Stock Inv entory

Warehouse Manager

User

(from

Actors)

Request User

Account

configuration

e.g. In cases when a new Warehouse Operator is

employed, the Warehouse Manager will make a

request to the System Administrator in order to

create a new User Account and to configure all

necessary access rights.

Also, in case an already registered Warehouse

Operator leaves, the Warehouse Manager must

notify the System Administrator in order to

deactivate the account.

Chat with other

users

Warehouse

Administrator

(from

Actors)

Set minimal and

maximal stock limit

per each medical

product

«include»

«include»

«include»

«include»

«include»

«include»

«include»

13


the possibility to automatically generate the necessary corrections by each stock item as a consequence of inventory differences.

FRQ027 Losses and adjustments operations

M Losses and adjustments operations is related to any issue out of the store for reasons other than consumption within the warehouse, e.g.:

- Changes in the stock due to removal of expired items, damaged items, theft, or adjustments to stock numbers during stock-taking;

- Redistribution to other warehouses/medical institutions are also recorded as a loss;

- Gains in stock quantities by means other than normal procurement channels;

FRQ028 Analytical information M In case of stock entries, the proposed VMIS software solution must allow the visualization of the agreement/contract based on which the vaccines were delivered. The system must allow the analysis of the agreement – what was contracted, how much was delivered and how much must be delivered at the level of each vaccine from the agreement, what payments must be performed (in advance, at the moment of service providing, final payment, etc). A Contractor can have several agreements, and each agreement can have several addenda.

FRQ029 justifying documents related to the transactions

M The System will automatically generate justifying documents for the managed transactions.

For each (transaction) movement of vaccines, the System must assure the automatic generation of accounting documents. .

FRQ030 Warehouses’ Management

M The System must allow the registering of unlimited number of warehouses.

The System must allow users to define the warehouses with which they currently work (e.g. central, regional or local level).

FRQ031 Configuration of warehouses’ locations

M The proposed VMIS software solution must allow users to define the locations in which they will store the items in the warehouse.

FRQ032 Shelf-life monitoring M The System must provide functionalities that would allow the Shelf-life monitoring and alerting.

FRQ033 Dashboard: Alerting and Reporting

M The System’s dashboard must highlight the percentage of vaccines that are in risk of expiry.

14


System’s Reports must alert the user that particular products will be available for at least 3 months based on Average Monthly Consumptions.

This must prompt the managers to seeking ways to transfer the product to/from another medical institution.

FRQ034 Minimum and Maximum stock levels

M The System must alert the user when stock reaches a minimum or maximum level and assist in developing the request to higher level for vaccines replenishment.

FRQ035 Interface for the Public Access

M The System must provide a dedicated interface for public access to the information about the availability of vaccines in certain warehouse.

FRQ036 Tracking. Traceability. M The System must provide functionalities that would allow tracking of vaccines according to various criteria such as Lot/Serial Number. Therefore, the System must ensure the traceability of the entire chain of vaccines.

FRQ037 Re-distribution operations of vaccines

M The System must allow re-distribution operations of the vaccines. (e.g. re-distribution of vaccines from one medical institution to another).

FRQ038 Confirmation of receiving vaccines in the warehouse

M The System will provide confirmation functionalities for the warehouses’ users which are receiving vaccines. Thus, the user will have to confirm in the System whether all the received quantities and quality of goods are according to the distribution document.

FRQ039 Unique nomenclature of vaccines

M The System must keep a unique official nomenclature of vaccines used in Uzbekistan.

FRQ040 Traceability Stock Cards M The System must provide functionalities for managing the so-called Stock Cards. Stock cards track the movement of vaccines in the warehouses and one card must be kept for each item in the warehouse.

Each time a transaction takes place, it must be available to be visualized on the stock card.

FRQ041 Stock Card Structure M The tentative description of the Stock Card is presented below and will be finally defined during the Analysis and Design Phase of the Project:

- Header information about the warehouse; - Item description;

15


- Pack size; - Code number; - Special storage conditions; - Unit of issue; - Average Monthly Consumption; - Minimum stock level; - Date; - Locations From/To; - Quantity in; - Quantity out; - Losses/adjustments; - Expiry date; - Batch or lot number; - Remarks;

FRQ042 Fast visualization of the stock item

M The proposed software solution must assure the fast visualization of basic information associated to an item (vaccine product).

FRQ043 Grouping of vaccines M The System must allow the classification of vaccines into groups of products and the definition of groups of products.

FRQ044 Standard Reports on stocks

M The System will include standard reports regarding stocks and/or movements of vaccines, allowing to specify the period of time.

FRQ045 Search feature M The proposed VMIS software solution must contain a multicriteria search engine and offer users the possibility of selection or editing of information by certain criteria.

FRQ046 Update information on stocks

M The System must provide a dedicated functionality for the medical institutions and warehouses that would allow users to update information on stock on-hand of vaccines and vaccines.

FRQ047 Submit requests for vaccines delivery

M The proposed software solution must provide functionalities for medical institutions to submit requests for vaccines delivery, including all related documents.

FRQ048 Single window for vaccines ordering

M The system should be user-oriented and serve as the single window for ordering vaccines. It should reflect the stock on-hand, ordered vaccines and estimated arrival time of the goods in the medical institution, as well as statistics on the average monthly consumption.

16


FRQ049 Integration with HMIS M The System must provide a dedicated API for electronic data exchange with HMIS.

FRQ050 Redistribution of vaccines M The system may propose how to redistribute vaccines, based on data regarding the needs for vaccines in other medical institutions, consumption and stock on-hand.

Functional Requirements for the Administration Module


FRQ051 Manage Document Management

M The administrator shall be able to define a new document template that is created or uploaded in the System using the administrative/management console of the System. The VMIS shall allow configuration of different data for different documents, such as field types, validation rules, ranges, possible values, instructions and error messages.

FRQ052 Manage alerts/internal notifications

M According to the internal processes, different users may need to be informed of various tasks awaiting their action in the System e.g. received vaccines in a warehouse that are awaiting confirmation from the side of Operator. For this purpose the System will allow the administrator to manage the configuration of alerts using the administrative/management console.

FRQ053 Manage organizations (entities) and units

M The System shall enable managing information about relevant organizations and organizational units. For instance, the relevant authorities shall have their own profiles that they use to log into the System and update only their own information (Email Contact, Telephone Contact, Website Contact, Physical Location, Organizational Units, Branches).

FRQ054 Content management M The System shall allow administrator to manage static content without having to change the software code.

FRQ055 Manage users and authorizations

M The management of user’s roles and permissions in terms of accessing the functionalities and data saved in the System – manage user rights through the roles/groups, will be available using the administrative/management console.

17


FRQ056 Logs Monitoring M The Administrator will be able to monitor all actions that occur in the System, including those with the most important events with the legal impact. For this purpose, the System will have its own logging mechanism.

Fig. 10. Use Case Diagram related to the Document management

18

Fig. 11. Use Case Diagram related to the Management of alerts

Referring to the above use case diagram (FigFig), IT administrator must have possibility to manage different types of alerts in the System. For example, the administrator shall be able to manage alerts that are related to the change of status of a document or the fact of receiving vaccines in the warehouse – an operation that is awaiting confirmation.

19

Fig. 12. Use Case Diagram “Manage Entities (Organizations)”

20

Fig. 13. Use Case Diagram “ Manage users and list of vaccines”

Users will be managed in a centralized manner. the VMIS solution must offer a possibility for managing user accounts, user roles (e.g. to create, update, change status and delete) and security policy, by means of defining the permissions for user roles and users to access the functionalities and data saved in the System. The users shall be able to authenticate through login and password.

21

Functional Requirements for the Reporting Module


FRQ057 Common report functionalities

M The System will allow defining parameters for generating reports, for instance supplies per vaccine type, time period, public authority, classifier, etc.

The VMIS will enable printing reports and exporting reports using HTML, Excel, Word, xml and pdf).

Also, the System will provide support for subscribing to the reports, by means of receiving generated reports by email in regular intervals, prepared based on defined criteria in the subscription.

FRQ058 Analytical reports M The System must be capable of producing reports desegregated by type of source of supply. A report per each warehouse that groups the quantity of vaccines received from different sources (procured, transferred in from other facilities, received from the central warehouse, etc.) should be produced.

FRQ059 List reports M The VMIS will allow generating list reports (e.g. List of transactions, List of delivered vaccines, List of cancelled transactions, etc.). The Contractor will provide up to 10 reports to list information from the System.

FRQ060 Statistical reports M The Contractor will implement up to 15 different statistical reports (standard and advanced) that will be defined as part of the detailed design process.

FRQ061 Time series reports M The System will enable generating reports with time series of key performance indicators and graphic representations. The Contractor will develop up to 7 time-series reports.

FRQ062 Administrative reports M The System will enable generating administrative reports on completed workflow statuses by users, based on user activity, completed transactions by users and other standard administrative reports.

The use-case diagrams related to the reporting module that are included below provide some examples of the reports that are expected to be provided by the Contractor. The intention is that Contractor understands the complexity level to be able to estimate efforts for the requested number of reports. The final list and design of the reports will be determined during the detailed design of the System.

22

Fig. 12 Use Case Diagram related to the Common Reporting Functionalities

The System will support drill-down option in the report, from some general level to the detailed representation level. For example, to prepare a report on level of business activity group and see the number of transactions related to the delivery of vaccines in certain time period, and then to drill down over categories to the vaccines type.

The System will enable searching generated reports and will implement web-based reporting interface. The report templates will be managed by the administrator and the System must include a tool (web user interface) for designing reports.

The VMIS System will support normal or cross-tab reports. User must have possibility to reduce processing impact during core business hours by scheduling large reports to generate during off-peak hours.

23

Fig. 23. Use Case Diagram related to Analytical Reports

Fig. 346. Use Case Diagram related to List Reports

24

Fig. 1745. Use Case Diagram related to the Statistical Reports

Fig. 18.Use Case Diagram related to the Time Series Reports

25

Fig. 19. Use Case Diagram related to the Administrative Reports


FRQ063 Analytical support for decision-makers

M The proposed VMIS solution must make available to users capacities of managerial analysis supported by cubes of pre-processed data.

FRQ064 Cubes of specialized data by each area with the possibility of customization

M The proposed solution must contain cubes of specialized data by each area with the possibility of customization of views of analysis (table or graphic).

FRQ065 Filtering and sorting M The proposed solution must allow users to establish filtering and sorting criteria at the moment of running reports.

Also, the System must offer a reporting tool that will allow users do design customized reports and to save templates. Also there must be possible to generate ad-hoc reports.

FRQ066 Synthetic reports with aggregated data

M The proposed VMIS solution must allow the extraction of synthetic reports with aggregated data from various activities and modules.

26

FRQ067 Schemes of fast definition M The System must allow the use of schemes of fast definition of requirements of each specific data field (field covered by the system).

FRQ068 Extraction of reports in real time

M The System must allow the extraction of reports in real time by activities designed for the MoH management.

FRQ069 Adding new types of reports

M The proposed solution must assure the possibility of adding new types of reports in a simple and intuitive manner.

FRQ070 Customized reporting M The proposed solution must allow the extraction of any types of reports depending on requirements.

FRQ071 Exporting reports in other formats

M The reports must be exportable in PDF, MS Excel, and automated delivery mechanisms (e.g. e-mail).

FRQ072 Definition of templates M The solution must allow definition of templates containing, at least, a header and footer, where the emblem of the MoH of Uzbekistan and other general information, common for all reports, will be integrated.

FRQ073 Saving report settings M The solution shall allow creation, change or deleting of generated reports, also allowing: saving settings for further use.

FRQ074 Virtually unlimited number of reports

M The provided solution will have to support the development of a virtually unlimited number of reports. It shall allow delivery of reports addressing the scopes of processes within the MoH users.

FRQ075 Filter by fields M The reports shall be provided with filter by fields function (ex. Period, Organizational hierarchy, location).

FRQ076 Report settings M The solution shall allow creation, change or deleting of generated reports, also allowing: saving settings for further use.

FRQ077 Relational / multidimensional

M Groups in the report - based on a list of fields from the database (relational or multidimensional)

FRQ078 Report customization M Columns / information displayed - based on a list of fields from the database (relational or multidimensional), with the possibility to specify their type and size (especially for export). It shall also be possible to apply the list or the possible operators by selected fields.

- Totals / subtotals - based on a list of fields from the database (relational or multidimensional) and a list of possible functions or operators.

27

- Possible filters - based on a list of fields from the database (relational or multidimensional)

- Default filters/conditions - the field and the value to be specialized

- Ordering - based on a list of fields from the database (relational or multidimensional)

FRQ079 Reports design M The reports will have official header, emblem, signature, default texts

FRQ080 Different report types M Report Type: normal or cross-tab (where you can choose the fields to be grouped in rows or columns, and displayed information/values)

FRQ081 Name of the reports M The report will contain pre-defined name for export

FRQ082 Web visualization M The reporting will be conducted through a browser without having to install other software.

General Functional Requirements to the System


FRQ083 Custom oriented software solution

M All the modules must reflect the method of organization of the vaccines management chain in Uzbekistan (e.g. MoH, Regional Healthcare Departments, central/regional warehouses, medical institutions, etc).

FRQ084 Fully integrated modular solutions

M The proposed VMIS software solution must be fully integrated so that at the validation of a transaction the data is updated and validated in all related modules.

FRQ085 Upgradeability M The structure of the System’s components must be designed so that the legislative or organizational changes which may intervene afterwards can be operable with minimal efforts by the MoH;

FRQ086 Users definition M The System must contain a configuration feature which allows a shared access of users to the system resources, by definition of user roles at the level of module, function and operation.

FRQ087 delimitation of responsibilities of each User Role

M The proposed software solution must allow the delimitation of responsibilities of each user role up to level of function/operation (configuration of roles at level of menu, module, function, operation, action).

FRQ088 Simultaneous access of users

M The proposed System must assure simultaneous access of users to data.

28


FRQ089 Interconnected environment

M The System must offer the possibility that the applications can be exploited in distributed way in an interconnected environment to local network and at a distance (LAN and WAN);

FRQ090 Flexibility M The System must be flexible, using a wide range of parameters which are established depending on specific requirements;

FRQ091 Data validation from other external systems

M The new IT solution must check / validate the structure of data coming from the external systems with which it interfaces by files type text, buffer database, web services, depending on needs;

FRQ092 Protection against deliberate or accidental attempts of unauthorized access

M For the protection against deliberate or accidental attempts of unauthorized access to the data it stores, the proposed solution must assure:

• Security of data via system limitations of access based on rights and passwords, broken into several levels;

• For a user or group of users, the configuration of rights of access must be possible from the interface of the application;

The logging of daily operations individually for each user with right of access to the change of entries, with marking of the time when each operation was executed and the identity of the user who initiated it;

FRQ093 Security M The security shall be assured at level of module and operation in the module of definition of the rights and roles for users and groups of users;

FRQ094 M The proposed VMIS system shall assure the work capacity in an open structure, on several levels, using management systems of relational databases.

FRQ095 Processing transactions M In order to assure the coherent data, the proposed solution shall use the principle of processing transactions so that in case of an accidental breakdown of the system all the completed transactions shall be permanent and those uncompleted shall be cancelled;

FRQ096 Configuring organization chart of the involved entities in the Vaccine Cold Chain

M The proposed VMIS System must offer the possibility of creating the organization chart of the involved organizations such as MoH of Uzbekistan, involved warehouses, etc.

29


FRQ097 Integrity of data by checking the inconsistent data

M The proposed system must assure the integrity of data by checking the inconsistent data (checking and validation), missing data (validation) or deteriorated data (checking of inconsistency and validation of business rules functionally implemented in the system).

FRQ098 Logging of users transactions

M The proposed VMIS solution must allow the configuration of logging of transactions of users, at application level.

FRQ099 Validation of use of the data based on business rules

M The proposed solution must not allow erasing of data from the system if it is used in various transactions other than the current one, validation of use of this data based on business rules.

FRQ100 Unique database M The proposed solution must be able to work in client-server condition application, must be centralized, with unique database.

1.4. BUSINESS-PROCESSES 1.4.1.1. General Management of Vaccines Supply-Chain in Uzbekistan

Fig. 20 High-Level Management Cycle of Vaccines

The process of supply and distribution of vaccines in Uzbekistan is organized according to a

hierarchical approach. First of all it must be mentioned that the entire mechanism consists of two

30

types of vaccine supply: the one according to the plan on vaccinations and another according to the

epidemiological indicators.

Generally, the vaccine management process according to the vaccination plan takes place in a

centralized manner. The amount of vaccines required by the plan is purchased and stored centrally

at Republican Center for State Sanitary- Epidemiological Surveillance. Storage conditions such as

temperature and humidity are monitored in the central repository.

Further distribution of the necessary quantities of vaccines takes place hierarchically from the central

level to the regional warehouses (Regional Sanitary-Epidemiological State Centers). It is worth

mentioning that there are 15 regional centers of this type in Uzbekistan.

Subsequently, vaccines are transmitted every month to each district to the warehouses of the District

Sanitary-Epidemiological Surveillance Centers. The monthly reserve is chosen on the basis that it is

not always possible to insure the storage conditions at the level of districts for a longer period due

to unstable electricity supply. Otherwise, the transmission to the district level would take place every

three months. This would also ensures a 3-month reserve. However, it should be noted the fact that

Uzbekistan is now rebuilding cold chain for storing the vaccines, according to requirements and

standards in this area. Thus, for the future, a considerable improvement of the storage conditions is

foreseen.

The final element in the distribution chain is the vaccination point, such as the polyclinics or

vaccination cabinets - where the vaccine is administered to the end user or in other words consumed.

All of the above mentioned steps are accompanied by the documentary and record-keeping process

predominantly manually and in paper format, which is a considerable effort on the side of the

employees of the sanitary-epidemiological surveillance centers. This fact involves also possible

human factor errors.

As a result of the distribution of vaccines to all levels, a reporting process is triggered from the local

level to the higher hierarchical level and then finally to the central level. The reporting process

consists of completing Form No. 6 “Report on Prophylactic immunizations” in paper format as well.

Each of the aforementioned processes related to the distribution of vaccines from one level to the

next will be described further in this document. Below is a schematic overview of the overall

distribution approach.

For general understanding of the burden of manually recordkeeping, please see the entire

Attachment 1. Samples of Existing Forms and Reports.

31

Fig. 21 Current conceptual approach

The distribution process according to the epidemiological indicators is realized in a decentralized

manner. Therefore, each of the State Sanitary-Epidemiological Surveillance Centers can purchase

certain vaccines depending on the seasonal or other factors, such as the epidemiological situation in

the region / district.

1.4.1.2. The process at the Regional Level

The distribution process to the regional level begins with the creation of the distribution lists central

level (Republican State Sanitary-Epidemiological Surveillance Center) for each region. Subsequently,

regional epidemiological surveillance centers are notified of the need to receive the needed

quantities of vaccines. At the same time, at the central (republican) level, the necessary bills to

accompany vaccines to the regions are prepared.

Empowered persons from Regional Centers for State Sanitary-Epidemiological Surveillance present

themselves with the power of attorney and receive the quantities of vaccines that are transported to

the regional warehouses.

Once the vaccines arrive in regional centers, the committee checks whether the type of vaccines and

the quantities received coincide with those declared in the documentation. The result of the

verification procedure is reflected in the "Report on Received Vaccines" (Отчет о прибытии

вакцин), which is confirmed by signature of the committee members. At the same time, after the

verification, the information about the received vaccines, amount, price, quantity, invoice is entered

in the Ledger.

It must be mentioned that the distribution of vaccines to the lower level is organized according to

the previously received demand from regional/district level. In this case, the regional level is

32

responsible for the preparation of the distribution lists for the district level - for the districts that are

part of the given region.

The sanitary-epidemiological surveillance centers at the district level are notified about the need to

receive the vaccines. When the vaccines are released, the necessary data are recorded in the "Ledger

of Vaccine and Sering Control". It is recorded manually the type of vaccine, lot, series, quantity, etc.

The necessary bills that need to accompany the vaccines sent to the lower level are also prepared.

34

Fig. 22. High-Level business-process diagram at the level of Regional Centers for Sanitary-

Epidemiological Surveillance

It is worth mentioning that once per month a report is sent to the Accounting department regarding

stock of vaccines: vaccine type, quantity, amount, etc.

1.4.1.3. The Process at the Level of District

The distribution process to the level of districts is somehow similar with the process at the level of

regional centers and begins with the creation of the distribution for each of the subordinated districts

of a certain region (Oblast). Subsequently, DCSSES are notified of the need to receive the needed

quantities of vaccines. At the same time, at the level of regional center, the necessary bills to

accompany vaccines to the regions are prepared.

Empowered persons from notified district enter for state sanitary-epidemiological surveillance

present themselves with the power of attorney and receive the vaccines that are further transported

to the warehouse.

Once the vaccines arrive in certain warehouse at the level of district, the committee checks whether

the type of vaccines and the quantities received coincide with those declared in the documentation.

The result of the verification procedure is reflected in the "Report on Received Vaccines" (Отчет о

прибытии вакцин), which is confirmed by signature of the committee members. At the same time,

after the verification, the information about the received vaccines, amount, price, quantity, invoice

is entered in the Ledger.

The district level is responsible for preparing the distribution lists for the subordinated medical

institutions. Once the distribution lists are prepared, the medical institutions are notified about the

need to receive the vaccines. When the vaccines are released, the necessary data are recorded in the

"Ledger of Vaccine and Sering Control". It is recorded manually the type of vaccine, lot, series,

quantity, etc. The necessary bills that need to accompany the vaccines sent to the lower level are

also prepared.

35

Fig. 23. High-Level business-process diagram at the level of District Centers for Sanitary-

Epidemiological Surveillance

36

1.4.1.4. The process at the Local Level

The process at the local level (medical institution / vaccination cabinet) begins with the receiving of

the vaccines by the Head of Nursing and recording this fact into the Ledger as in case of all other

superior levels.

As in the aforementioned cases, at the receiving the committee checks whether the received type of

vaccines and quantities are according to those declared in the documents. This fact is confirmed by

signature by all members of the committee in the same standard form on receiving vaccines. In case

there are some deviations, the higher level (district center for sanitary-epid. surveillance) is notified.

The received vaccines are stored and the doses are released at the moment when a patient is

accepted for vaccination. After the vaccination process the information about the patient, vaccine,

dose, lot, series, etc, is registered into the Ledger.

The System must take into account all this type of the data and provide a graphical user interface for

vaccination cabinets, so the responsible nurse may register this information.

37

Fig. 24. High-Level business-process diagram at primary level (policlinics, vaccination cabinets)

38

1.4.1.5. Other operations needed to be taken into account

Beyond the process of receiving and transmitting vaccines, at all levels, the VMIS must take into

account also the following operations:

- Transition of vaccines to another warehouse for a temporary storing due to some technical

issues (e.g. loss of electrical power);

- Write-off operation – this may occur due to some unpredictable conditions that may cause

damage to vaccines (e.g. accidents during transportation or emergency situations related to the

fridge). The write-off operation may be saved into the System, only by providing an argumentation

on each specific case;

- Re-distribution – this operation consists of transmitting vaccines from one warehouse/medical

institution to another in case of unforeseen situation like stock shortage in a certain medical

institution. This fact also must be documented into the Information System.

- Inventory – Usually in each warehouse which stores vaccines the inventory operation is carried

out once per month. The result of the inventory procedure must be also recorded into the system

and taken into account in the process of calculation of the real-time stock.

39

2. SOFTWARE RELATED NON-FUNCTIONAL

REQUIREMENTS

Each numbered requirement is labelled as NFFRQ and could have the following marks:

(M) = Mandatory = “The System must ...”

(HD) = Highly Desirable = “The System should ...”

(D) = Desirable = “The System may ...”

MUST – means that the numbered requirement as defined is an absolute requirement.

MUST NOT – means that the numbered requirement as defined is an absolute prohibition.

SHOULD – means that there may exist valid reasons in particular circumstances to ignore a particular

item, but the full implications must be understood and carefully weighed before choosing a different

course. An implementation which does not include such an item MUST be prepared to interoperate

with another implementation which does include the item, though perhaps with reduced

functionality. An implementation which does include a particular item MUST be prepared to

interoperate with another implementation which does not include the item (except of course for the

feature which the item provides).

2.1. Requirements regarding system architecture

Fig. 26. 3-Tier Architecture

40

Table 1.1 General requirements for the System Architecture

Identifier Type Description

NFRQ001 M The VMIS software solution architecture must be open, modular and based

on integrated components. These principles must be visible at all levels of the

architecture.

NFRQ002 M The proposed software solution must be web-based one and the involved

technologies must be widely used in the region.

NFRQ003 D Open-source solutions are also acceptable and in such cases, the supplier

must fully customize it according to the beneficiary’s needs.

NFRQ004 M The architecture of the VMIS software solution will be services-oriented

(SOA).

NFRQ005 M The VMIS software solution will be created based on a minimum 3-

levels/layers architecture (Presentation Layer, Business-logic layer, Data

layer), in a way that higher layer interacts only with preceding lower layer

(Fig. 26)

NFRQ006 M The VMIS software solution will optimize processing of queries (i.e. caching

of queries).

NFRQ007 M The VMIS software solution uptime shall be at least 99.9%, with 8 hours RTO

and zero data loss RPO.

The Presentation Layer enables user interaction with the business functions of the System. The requirements for the presentation layer are shown in the following table.

Table 1.2 Requirements for the Presentation Layer


NFRQ008 M The user will use web browser to access all the functionalities and data in the VMIS

software solution for which he/she is authorized. The System will be compatible

with at least 2 most recent versions of the following Web browsers: Microsoft

Internet Explorer, Microsoft Edge, Mozilla Firefox, Google Chrome and Safari.

NFRQ009 M The System will implement HTML 5 web interface and should use only web browser.

In case of certain specific functionality (e.g. document scanning) the VMIS software

41


solution may use certain minimum supplementary installations (e.g. web browser

add-ons) if needed.

NFRQ010 M The presentation layer won’t implement any business rules, except of the validation

of data entries.

The Business Logic Layer implements the functionalities of the System. This layer is responsible for

accessing, processing and transformation of data, manages the business rules and assures the data

consistency and accuracy. The business logic layer is accessed from the presentation layer to make the

functionalities available to the users and it can also offer the functionalities to external information

systems through the data exchange interfaces.

The requirements for the business logic layer are defined in the following table.

Table 1.3 Requirements for the Business Logic Layer


NFRQ011 M The Business Logic Layer must be completely independent from the Presentation

Layer and from external applications that use the data exchange interfaces.

NFRQ012 M The Business Logic Layer must have a completely modular architecture based on

reusable components and abstract interfaces. There must be no identical functions

made by different components (e.g. data access).

NFRQ013 M The Business Logic Layer must contain and delimit the “business workflow” and

“business entity” components.

NFRQ014 M Access to business entity components will be done through business workflow

components.

NFRQ015 M The business entities must be clearly defined at the Business Logic Layer.

NFRQ016 M Business entity components must contain all data and business logic related to the

business entity, for undertaking the business operations, implementation of

relevant business rules and for the maintenance of the integrity and accuracy of

contained data.

NFRQ017 M The components related to Business Logic Layer must communicate through

dedicated interfaces/ internal functions (tight coupling).

NFRQ018 M The components of the Business Logic Layer must be accessible for external

applications only through the data exchange interfaces.

42


NFRQ019 M The architecture of the Business Logic Layer will allow simultaneous access to the

functionalities of the System.

The database and data will be implemented using the relational database management system (DBMS).

The requirements for the Data Layer are defined in the following table.

Table 1.4 Requirements for the Data Layer


NFRQ020 M The data model implemented at the Data Layer of the System must follow at

least the third-normal form for the database design, to reduce the duplication

of data and ensure referential integrity.

NFRQ021 M The VMIS software solution data model must follow the Common Data

Modeling with a generic Data Model which consists of generic types of entity

like class, relationships, and others.

NFRQ022 M The data at the Data Layer must be accessed only through the Business Logic

Layer and independent from the Business Logic Layer.

NFRQ023 M The data model implemented at Data layer must be properly documented. The

documentation must contain both the technical description of the data (e.g.

entity-relationship diagrams, structures of databases, objects in databases,

etc.), and the semantic description (association of data structures with business

entities and their properties). The semantic description has to be available for

users, where applicable (e.g. customization of reports).

NFRQ024 M The Data Layer must assure the integrity and accuracy of data (transaction

integrity).

2.2. Requirements regarding technology At this level there are the software and hardware components needed for the running of the System (Presentation Layer, Business Logic Layer, Data Layer). The Contractor is responsible to include in its offer all needed software at this level for functioning of the offered solution for the VMIS solution and to define the deployment model of the System on Beneficiary’s infrastructure.

43

The requirements regarding architecture for the technological level are presented in the following table.

Table 1.5 Requirements for the technology architecture


NFRQ025 M The technology architecture must have a high level of resistance to failure and

must not contain single points of failure (SPOF).

NFRQ026 M The technology architecture must assure rational and balanced use of processing

resources.

The technological platform shall be made up of the totality of software and hardware components needed to assure the operating environment for the System. Regarding hardware, the Contractor must provide the requirements for Servers, Storages, virtual machines and other related hardware. The technological platform for software includes: software development platforms, database management system, operating systems, and any other software including third-party software needed for the System to operate. The Contractor must provide all software for the offered solution for the VMIS to operate. Also, the Contractor is responsible for implementation and configuration of the software to the designed hosting environment.

The requirements for the technological platform are shown in the following table.

Table 1.6 General requirements for the technological platform


NFRQ027 M The technological platform for software must be widely used in several countries,

and must be locally supported in Uzbekistan by partner who is authorized by the

manufacturer.

NFRQ028 M The technological platform for software must be independent from the hardware

technological platform (i.e. shall run on at least two types of processors from

different manufacturers).

NFRQ029 M The technological platform for software must be homogeneous (i.e. must consists

of minimal number of different technologies, e.g. same operating systems for

middleware and database).

NFRQ030 M The technological platform for software must support the creation, modification,

processing, storage and accessing of textual data in Unicode format.

NFRQ031 M All components of the System (e.g. middleware, databases) shall run on platform

with operating systems from the Windows Server, UNIX or Linux. The supported

44


versions of the operating systems must be maintained by producers and shall

belong to the latest 2 major versions.

NFRQ032 M For running of the VMIS software solution at the Beneficiary side, the Contractor

shall specify equipment which can be purchased from the local market in

Uzbekistan.

The requirements for the technologies for the Presentation Layer are shown in the following table.

Table 1.7 Requirements for the technology platform for the Presentation Layer


NFRQ033 M The VMIS solution should provide a user-friendly interface that is intuitive and accessible to all types of users of the information system and accessed via a web browser. Also, VMIS should provide an intuitive graphical design and user-friendly interface that is balanced and distinctively optimized for a minimum resolution of 1360x468. At the same time, the user interface should be responsive on multiple devices/screens and optimized for mobile devices, such as tablets, smartphones and touch screens.

NFRQ034 M The System shall support cross-browser compatibility, by means that users shall

be able to access the System using standard web browsers, such as Internet

Explorer, Mozilla Firefox, Google Chrome, and Safari, using either desktop or

mobile devices.

The requirements for the technologies for the Business Logic Layer are shown in the following table.

Table 1.8 Requirements for the technology platform for the Business Logic Layer


NFRQ035 M The components which form the Business Logic Level must be developed in

modern and widely used programming language (e.g. C#, Java).

NFRQ036 M The technology at this layer must allow seamless integration of the functional

modules of the System.

The requirements for the technologies for the Data Layer are shown in the following table.

Table 1.9 Requirements for the technology platform for the Data Layer

45


NFRQ037 M The System shall support relational database management systems that have the following modern capabilities:

- effective utilization of RAN and SIMD instructions - Columnar format for tables (including compressions) - Partitioning - Virtualization, Cloud deployment

The System should be able to use these opportunities.

NFRQ038 M The System will be implemented using a single database management platform

implemented in high-availability (e.g. failover cluster, mirroring).

2.3. Requirements regarding interoperability Table 1.10 Non-functional requirements for the interoperability


NFRQ039 M The electronic data exchange between the System and external information

resources will be performed through secured web services.

NFRQ040 M The proposed System must be integrated with the following IT

resources/systems:

- The official database of vaccines in Uzbekistan

NFRQ041 M Application interfaces must be based on open standards (REST HTML, SOAP).

NFRQ042 M Application interfaces shall allow data exchange with external information

systems in online and offline mode.

NFRQ043 M Application interfaces will allow weak coupling with external information

systems (e.g. communication based on messages).

NFRQ044 M All implemented application interfaces in the System must be properly

documented (e.g. using Web Services Description Language – WSDL).

NFRQ045 M The System shall support the internal notifications and alerts by sending email

messages using predefined templates to the indicated recipients.

2.4. Requirements regarding informational security Table 1.11 Requirements for the information security

46


NFRQ046 M The System has to support the following informational security requirements according to the Information Security Standard:

− Information integrity – maintaining and assuring the accuracy and completeness of data over its entire life-cycle;

− Confidentiality – protection from unauthorized access to data; and

− Availability – to ensure the availability of the information when needed.

NFRQ047 M The System has to support the following main mechanisms for ensuring the informational security:

− authentication and authorization;

− managing access to information;

− recording actions of users in the System and transactional logs;

− encryption of information;

− IT audit; and

− business continuity and disaster recovery.

A very important aspect is the mechanism for controlling user actions in the System – to detect at an early stage attempts to access confidential data or to make intentional or accidental injury to the information integrity.

Table 1.12 Requirements regarding the Authentication into the System:


NFRQ048 M VMIS will allow registering users and information about their profiles (e.g. UserID, password, first name, last name, e-mail address, etc.).

NFRQ049 M The VMIS solution will ensure user authentication by at least user ID and password.

NFRQ050 M User passwords must be protected in the VMIS. The applied password protection method must ensure that passwords will not be intercepted, decrypted or restored.

NFRQ051 M The VMIS will allow blocking, disabling or suspending user accounts at the application level.

NFRQ052 M Users can access the VMIS only after they have been authenticated.

NFRQ053 M The VMIS will allow setting limits on idle time before user’s session expires due to inactivity.

NFRQ054 M VMIS will support required mechanisms to implement unified authentication (e.g. Kerberos).

Table 1.13 Requirements regarding the Authorization into the System:

47


NFRQ055 M VMIS will allow a detailed access control of all system objects and possible

operations (e.g. entities, properties of entities, forms, menus, repositories,

read / update / delete operations).

NFRQ056 M VMIS will allow setting up user groups and roles, as well as combining users

into groups and roles.

NFRQ057 M VMIS will allow granting access rights at user level, user group and role

levels. A group can contain several subgroups / roles. A user can be

associated with one or more groups and roles, thus his/her access rights are

defined cumulatively.

NFRQ058 M VMIS will allow granting access rights according to established rules (e.g.

document change is possible only if the author or operation is performed

within a certain period of time).

NFRQ059 M VMIS will allow temporary delegation of access rights of one user to

another. Delegation can be performed by preserving or suspending

permissions of the delegate.

2.5. Performance requirements Table 1.14 Performance requirements


NFRQ060 M The average server reply time shall not exceed 5 seconds at nominal system load. This is not applicable for reports generation.

NFRQ061 M The System must be capable to allow activity of min. 700 users and max. 1,000 users, with estimated 500 concurrent connected users, in the First Phase (central, regional and districts levels) of the Project.

NFRQ062 M Performance testing will include minimum two components: system Load Testing and system Stress Testing.

48

3. Centralized Databases All VMIS’ data shall be stored centrally in one database located within Uzbekistan (this is a mandatory

requirement). Hosting of the VMIS (testing and production environments) shall be also within

Uzbekistan.

All the system users shall access/ modify/ delete the data through appropriate modules based on the

access rights. These central data shall be utilized for various reports and for analysis purposed for

decision support.

It is important to be noted that all data generated by the VMIS is owned by Government of

Uzbekistan. The Contractor cannot use these data for any purpose during or beyond the contract

period.

The Tenderer is required to explicitly specify which database (e.g. Microsoft SQL Server, Oracle,

PostgreSQL, etc.) will be used by the VMIS solution. In case the license is needed the Tenderer shall

include its cost in his financial proposal.

49

4. Software Backup The successful Tenderer shall ensure database backup with a latency of maximum 1 day. This means

that at any point of time maximum data loss would be of the last 1 day data.

To avoid performance degradation of the system such backup should be scheduled out of working

hours daily. Incremental backups should be taken.

Apart from backing up data at the server room, backups should be taken on external media as per

the following schedule.

No. Backup type Frequency Storage period No of backup

tapes

1 Incremental Daily 1 week 2+1

2 Incremental Weekly 1 month 2+1

3 Full backup Monthly 1 year 2+1

4 Full backup Yearly Permanent 2+1

50

5. Disaster Recovery and Business Continuity The successful Tenderer has to ensure business continuity at the time when disaster occurs. There

should be a disaster recovery plan, which is tested and well documented and easily understood which

will help recovery as quickly and effectively as possible from an unforeseen disaster or emergency

which might interrupt information systems and business operations. The DR plan should have the

following:

• All staff fully understand their duties in implementing such a plan

• Operational policies that are adhered to within all planned activities

• Proposed contingency arrangements are cost‐effective

• Implications on other sites (e.g., in case there is some interruption in UP, the same

may/may-not interrupt operations in Uzbekistan).

51

6. Software and User Documentation


DOC001 M VMIS must have a printed instruction booklet and a user manual

explaining how to use the system.

The user manual will be distributed electronically as a PDF document. It

should be written at a level of an average user with poor computer skills.

DOC002 M The User Manual must be written in Uzbek and Russian languages.

DOC003 M The User Manual must have a dual purpose: serving both as a desktop or

reference resource, as well as a training tool for any training activity.

In case of a training activity, the user manual can be printed out and

distributed amount all training participants.

DOC004 M In addition, the Contractor shall provide a Manual for System

Administrators of the VMIS written in Uzbek and Russian languages.

52

7. Testing, Quality Assurance and UAT The Tenderer shall prepare and submit in his proposal methodology and procedures specifying details

how he intends to design and develop the VMIS.

Methodology shall include details about goods, materials needed for information technologies

(hardware, System software, COTS software, custom software, etc.) and testing activities. The

methodology shall be updated after signing of the Contract Agreement and adapted according to the

Project Plan after the acceptance of the Project manager.

Special attention shall be drawn by the Contractor during the Methodology preparation and during

implementation to Beneficiary’s requirements related to the integration of the already developed

procedures and processes to the new System and uninterruptable operation of the current System

until Commissioning is completed by the Contractor.

The Tenderer shall demonstrate that the proposed methodology and procedures they will use fully

cover the topic of the project so that it is possible to test all the functionalities identified and agreed

with the Beneficiary in the Auditing, System analyses and design phase.

INSPECTIONS

o Inspections at VMIS development stage

• Contractor shall keep a System development version in the Development Environment.

• At least 70% of the developed specific VMIS components shall be subjected to unit testing. This is will not be applicable in case of using COTS products.

• Contractor shall regularly update the components of the development environment and support the regular reports with VMIS demos.

• Contractor shall document and address the Beneficiary requests that will be classified into defects and modification requests if appropriate.

• Inspections at System delivery stage

• To perform the delivery Contractor shall install the System components on an integrated environment (according to the configuration requested by the Beneficiary).

• Contractor shall install the System components according to the installation guidelines.

• Contractor shall install the System components together with the MoH’s System administrator.

• Contractor shall modify the configuration parameters according to the installation guidelines.

• Contractor shall modify the configuration parameters together with the System administrator.

• Contractor shall demonstrate the functionality of all the System components.

53

PRE-COMMISSIONING TESTS

• In addition to the Contractor’s standard check-out and set-up tests, the Contractor (with the assistance of the Beneficiary) shall perform the tests on the System before installation will be deemed to have occurred and the beneficiary will issue the Installation Certificate(s);

• The Beneficiary will check if all the automatic mechanisms of integration with other computer subsystems meet the requirements.

• The Contractor will perform the accessibility testing according to the Web Content Accessibility Guidelines (WCAG) 2.0. The Contractor shall provide details about the testing method and the achieved results.

• The Contractor shall perform the security testing at least according to OWASP Top 10 vulnerabilities. The Contractor shall provide details about the testing method and the achieved results. Contractor will conduct the performance testing at least for two components

A. Load testing; B. Stress testing.

• The Beneficiary may request an expertise of the testing results from third parties.

• The acceptance criteria for pre-acceptance testing are:

A. 100% of the nonconformities detected at delivery were addressed; B. 80% of the accessibility tests for A level are successful; C. 100% of the security tests are successful; D. performance is better than required; E. no critical nonconformities and less than 2 major nonconformities and 30

average and minor nonconformities were detected.

• The acceptance date will be the point when all the nonconformities detected when

the VMIS is put into production have been addressed.

OPERATIONAL ACCEPTANCE TESTS

• The Contractor shall prepare and submit all needed documentation for tests and

Operational Acceptance Tests procedures performance in advance.

• The Beneficiary (assisted by the Contractor) will perform the following tests on the

System and its Subsystems following installation to determine whether the System

and the Subsystems meet all the requirements mandated for Operational

Acceptance.

• The Beneficiary will check the entire business cycle and the related technical

performance through operational tests.

• The operational acceptance criteria’s when the Beneficiary will consider accepting

the System are as follows:

o all the positive scenarios have been successfully performed and operation;

54

o at least 80% of the negative scenarios must be successfully handled; o there are no high or critical severity bugs; o no testing scenario will corrupt the data integrity.

The System shall be deemed as accepted when it will operate according to the normal

parameters and no major operation deficiencies are operation and detected at least

during three months.

Major deficiencies shall be considered the errors that cause obstruction of VMIS

functionalities that prevents avoiding or overcoming a situation that requires the

involvement of the System Administrator or even System developers.

55

8. Venue for Software Development/Customization The software development/customization activities will be carried out at the premises of the selected

Proposer. However, the testing will have to be carried out at Beneficiary (or place designated by

UNICEF) in the presence of users and subject matter experts nominated for the activity. The selected

Proposer will have to conform to the timings and working days of UNICEF during the testing.

56

9. License Agreement and Supply of Source Code The proposed VMIS solution and any software must be covered on open source solutions, which will

be granted to the owner of the System.

The Contractor must deliver a fully functional “turnkey” solution, including project management,

preparation and coordination of the proposed appliance architecture and software installation,

acceptance tests and professional assistance during the production startup. The offer must include

detailed description of the proposed services.

The Contractor must obtain all necessary copyright and other Intellectual Property Right permissions

before making any Third Party Material available as Auxiliary Material for the purpose of the

implementation of the System.

All Intellectual Property Rights in the Contract Material vests in the Beneficiary. The Contractor

retains all Intellectual Property Rights in: (i) any COTS Software and derivatives thereof and (ii) any

other of Contractor’s Pre-existing Intellectual Property, which Contractor may furnish during the

course of the System implementation through a License.

If the Beneficiary needs to use any of the Auxiliary Material owned by the Contractor or any other of

Contractor’s Pre-existing Intellectual Property to receive the full benefit of the Services, the

Contractor shall grant a license to the Beneficiary. The Contractor shall provide perpetual and

unlimited user licenses to the Beneficiary.

If the Contractor needs to use any Material owned by the Beneficiary or any Contract Material as

defined for the purpose of performing its obligations to implement the System, the Beneficiary will

grant to the Contractor, royalty-free, non-exclusive, non-transferable license to use, reproduce,

adapt, modify and communicate such Material solely for the purpose of providing the Services and

Deliverables.

The source code for the VMIS should be provided with proper documentation explaining the

functions of each module/routine. The final version of the complete source code will have to be

compiled in front of UNICEF IT Expert and submitted along with all the necessary documentation.

Necessary instructions for incorporating any modification changes in the software and its compilation

into an executable/installable product should be explained clearly. All source codes will become

proprietary item of the UNICEF, which will subsequently transfer it to the Beneficiary. It must be

understood that the software will be developed for the Ministry of Health of the Republic of

Uzbekistan, which represents the Beneficiary.

Ministry of Health of the Republic of Uzbekistan envisions using the software application procured in

all the regions and districts in Uzbekistan. The Beneficiary will have all the rights to install/deploy/use

this application for Routine Immunization purposes in any region, district or locality in Uzbekistan.

57

10. Software Support There should be explicit tracking of bugs and change requests and the designated people should get

access to monitor the performance and issue resolution.

58

11. System Lifetime The selected software from this RFP shall have a lifetime of at least ten years. The selected Tenderer

(the Contractor/Supplier) should demonstrate its commitment to ensure that its VMIS solution will

have this lifetime. Depending on the options selected and authorized by UNICEF or Ministry of Health

of the Republic of Uzbekistan, additional deliverables will be required. The selected Tenderer is

encouraged to identify additional project deliverables, as applicable, beyond the minimum set

specified in this document.

The selected Tenderer is advised that the aforementioned project deliverables are not related to

payment points.

59

12. Scale up for The Entire Country The VMIS solution will be piloted in one region (Oblast) of Uzbekistan initially and based upon the

success of the project the same will be used in all the districts and other localities in Uzbekistan. The

software procured through this RfP is for Ministry of Health of the Republic of Uzbekistan who will

have all the rights to install/deploy/use this software for routine immunization purposes in any

region/district of Uzbekistan without any additional payment to the selected Tenderer.

60

13. Requirements for Hardware

This RfP does not foresee procurement of any hardware. However, the Tenderer has to specify in his

technical proposal all details of the needed hardware for the development/customization, testing,

functioning and using of the proposed VMIS solution.

All needed hardware for VMIS is subject to a separate procurement procedure.

It is expected the selected tenderer will maintain three environments:

- Development environment;

- Testing environment;

- Production environment.

At the beginning of the project, it is expected that the development environment will be prepared at

the premises of the Contractor, while all needed hardware infrastructure will be procured and

installed in the server room within Uzbekistan. After all hardware is delivered and installed, the

Contractor will migrate the development environment to the data center in Uzbekistan and will

prepare as well the testing and production environment.

61

14. Server Room Requirements

Server room requirements need to be described by the Tenderer based on proposed technical

solution.

Mandatory requirement foresees that hosting and data for the present RfP shall be located in a data-

center in Uzbekistan. All services related to the delivery and installation of the server-room

infrastructure are subject to another procurement procedure.

annex 1. technical requirements (based upon the initial ... · technologies. in addition, the vmis...

Documents