Background

Laboratory services in Zimbabwe are offered at different levels ranging from bedside testing to sophisticated testing at reference laboratories. At these different levels, testing is done either using rapid diagnosis testing (RDT), point of care testing (POC) or conventional equipment is used. In any case, these tests are performed at the facility where the patient is attended to or the sample is referred to a higher level for testing.

At the end of a given period, any facility offering laboratory services is expected to report a number of parameters to the next or higher level. These parameters may include number of tests performed, number of results falling in a particular range, those tests which would have failed, number of reagents used and those in stock.

Some facilities which offer laboratory service have electronic systems and are able to pull data and report on the required parameters. On the other hand, there other facilities which run on paper based systems hence need to manually aggregate data at the end of a given period.

On receiving the data at a central point, the data is consolidated and presented in graphical format using tools such as spreadsheets or data analysis tools.

Zimbabwe laboratory network follows a tiered structure in which referral of services follows a bottom up approach.

The laboratories are broken into separate levels;

• Rural health centers – offers bedside testing and point of care
• Mission and Rural hospital laboratories -  offers bedside testing and point of care, and microscopy
• District hospital laboratories -  point of care, and microscopy
• Provincial hospital laboratories – all the above in addition to Conventional tests
• Central hospital laboratories – All the above, in addition to disease surveillance
• Reference laboratories  -- All the above

Purpose: The document is intended to document the requirements for a dashboard system for the Zimbabwe Ministry of Health and Child Care (MOHCC) from a users’ perspective. In order to do so, it will combine short overviews of the current system or operations as well as the intended vision.

There are two main groups of users who will use the system. The first group of users is the system administrator. The system administrators are concerned with data integrity and system stability. This group has the highest computer skill set and is capable of supporting the computer system, configure report templates etc. Their interaction with the system is limited to user account management, backing up, archiving data from the database and provides basic computer support to other users of the system.

The second group of users is laboratory and program professionals. They will be the main users of the system and their interest will be extracting data from the system and have it presented in tables and/or graphs. These users will fall into the following categories;

• District laboratory scientists
• District program managers
• Provincial laboratory scientists
• Provincial program managers
• National laboratory managers
• National program managers
• Implementation partners
• Service providers
• General public

Objectives

Under this consultancy contract, the engaged consultant will be expected to:

1. Prepare (in consultation with MOHCC) a detailed work plan with milestones to be achieved and expected outputs for the dashboard system.
2. Increase information visibility for decision making
3. Generation of Reports, both for external and internal use
4. Offer different views to data through slicing and dicing techniques

Duties and Responsibilities

Scope of Work

The scope will cover the development of a National Dashboard for laboratory tests done in Zimbabwe

Detailed Scope of Work

Device Management

The dashboard system should maintain information of individual devices that are used in diagnosis testing. The device management allows for all tests to be linked to a device over time. Users with authority may create, modify or delete devices.

1. The system maintains list of device profiles
2. The device profile consists of all or some of the following, but not limited to
3. A unique identifier  (System generated)
   1. Asset number (MOHCC generated)
   2. Serial number
   3. Device name
   4. Device model

Health Facility Profile Management

Health Facilities are either Laboratories, Hospitals or Health Centers that offer laboratory testing either using conventional machines or using point of care machines or bedside testing. The dashboard system keeps a record of all providers that have the ability to offer afore mentioned services.

1. The system maintains list of Health facility profiles
2. A health facility may be a clinic, a hospital, a health center or another laboratory, etc.
3. The provider profile consists of, but not limited to, the following
   1. A unique health facility identifier (Generated by MOHCC)
   2. Health facility name
   3. District
   4. Province
   5. Geo coordinates
   6. Physical address
   7. Telephone number
   8. Email address
   9. Contact person(s)

1. The system allows authorized users to manage health facility profiles.

Test Catalog Management

The dashboard system manages all the tests and procedures that are carried out by the health facility on a device by device basis. The LIS should allow for tests to be added, deleted or modified from the Test Catalog.

1. The system maintains one or more catalogs of all the offered testing services, i.e. tests.
2. Tests may be grouped in one or more categories and sub-categories in a catalog
3. A catalog test entry consists of, but not limited to, the following:
   1. A unique test identifier/code
   2. Test name
   3. Category name
   4. Subcategory name
4. The system allows authorized users to assign one or more test catalogs to health facility or device
5. The system allows authorized users to manage the test catalogs
6. The system allows authorized users to import the test catalogs.

Scheduling Management

The system should allow users to configure scheduled events which will run at set intervals or triggered by particular events.

The triggers may include, but are not limited to

1. Scheduled emailing of reports to set users
2. Email notification upon a particular event such as QC failure or equipment error threshold
3. Add request and sample received and accepted to specific test schedule
4. Non-reporting over a set period of time

Report Management

The dashboard system will generate reports in electronic format to authorized users. These reports will be stored or generated ad hoc and will allow the user to view tests done, tests ordered, Quality control, rejections, TAT, etc.

The users will be able to define the types of reports they need following the WHEN, WHAT, WHERE approach. The approach allows the users to specify the data to show (WHAT), for which facility (WHERE) and for which period (WHEN). Examples of reports that the system should be able to produce are

1. Facility reporting summary Report

1. The report will show a list of devices with the following information
   1. Instrument name
   2. Instrument identifier (S/N, etc.)
   3. Last test date
2. The system should allow the user to filter the list by
   1. Facility
   2. District
   3. Province
   4. Device category
   5. Date filters such as reported in the last X days, performed tests in the last X days, not reported in the last X Days

1. The system should allow user to export the list to , but not limited, the following formats
   1. CSV
   2. XML
   3. PDF
   4. JSON

2. Facility list

1. The report should list all facilities in the system indicating
   1. Facility name, district, province
   2. Instrument available at the facility
   3. Date when each device last send data
   4. Date when device last performed a test
   5. Reports can be either displayed (viewed on a monitor) or printed
2. The system should allow the user to filter the list by
   1. District
   2. Province
   3. Instrument category
   4. Date filters such as reported in the last X days, performed tests in the last X days, not reported in the last X Days
3. The system should allow user to export the list to , but not limited, the following formats
   1. CSV
   2. XML
   3. PDF
   4. JSON

3. Suppression rate report

The aim of the report is to allow the user to evaluate a proportion of HIV positive patients achieving viral suppression. The system should therefore enable the following

1. Determine the viral suppression target
2. Specify age stratification categories
3. Specify gender stratification categories
4. Specify other stratifications (case information) e.g. pregnancy, breastfeeding, drug regimen
5. Specify location stratification categories
6. Categorize by submitting clinic

4. Rejection rate report

The aim of the report is to allow the user to evaluate the proportion of samples received that were rejected. The reports should

1. Show number of samples received during a specific period
2. Show number of samples rejected during a specific period
3. Percentage of samples rejected (a/b X 100%)
4. Categorize rejections by rejection reason
5. Categorize by facility, district or province

5. Invalid result rate report

The aim of the report is to allow the user to evaluate the proportion of samples tested and had invalid results. The reports should

1. Show number of samples received
2. Show number of samples tested
3. Show number of samples with invalid results
4. Percentage of samples with invalid results
5. Invalid results by device
6. Categorize by facility, district or province

6. Invalid result rate report

The aim of the report is to allow the user to evaluate the proportion of samples tested and those which failed. The reports should

1. Show number of samples tested
2. Show number of samples which failed
3. Percentage of failure
4. Failures by device
5. Failures by user

7. Current regimen report

The aim of the report is to allow the user to evaluate regimens being given to patients. The report should;

1. Indicate number of samples received
2. Number of samples tested by
3. Number of valid results
4. Number of patients achieving targets, e.g. positivity for Covid, VL suppression for HIV VL, TB resistance for TB, etc.
5. Categorize patients by different variable, e.g. regimen, reason for test, case information
6. Calculate suppression rate by regimen

8. Testing trends

The aim of the report is to give a view of the number of tests performed per given period. The reports should

1. Categorize tests by sample type
2. Categorize tests by facility level (rural health center, district etc.)
3. Categorize tests by submitting clinic

9. Testing reason report

Clinicians requests for tests due to various reasons. The report give an account of the various justification for viral load testing such as treatment failure, routine etc.

1. Categorize by reason for testing
2. Categorize by submitting clinic
3. Categorize by viral load result or result range or case

10. Turnaround time report

The aim of the report is to measure the amount of time between sample collection and results reporting. This will form basis for improving sample transportation, testing as well as results reporting.  The report should include

1. Number of samples by date collected, registered, received, tested, delivered results
2. Number of results report
3. Number of results reported within defined turnaround time
4. Percentage of results reported within defined turnaround time
5. Categorized by testing facility
6. Categorized by submitting  facility
7. Categorized by instrument

11. Health facility performance report

The aim of the report is to evaluate performance of different laboratories by;

1. Showing number of facilities serviced
2. Samples received
3. Repeat tests performed
4. QA test performed
5. Total tests performed

12. Visualization/GIS Reports

The consultant will be expected to develop visual maps, heat maps, charts, modern map technology

Communication with external systems

The dashboard system should have capability to communicate with other external systems by offering endpoints through Application Programming Interface (APIs).

User Account Management

User Access

1. The dashboard system provide online access to various laboratory personnel
2. Online access to the dashboard system is granted only through dedicated user accounts
3. The system maintains list of user accounts
4. A user account consists of the following components:

1. User Profile – contains user contact information
2. User Credentials – contains user authentication (identity confirmation) information
3. User Role – Defines user authorization and privileges

1. The system allows authorized users to manage user accounts.

User Profile

1. The user profile contain the following contact information
   1. Person full name including last (family), first (given) and middle names
   2. Gender
   3. Tile
   4. Department/organization
   5. The system allows authorized users to manage user profiles

User Credential

1. User credentials consist of the following information:
   1. A unique username and
   2. A unique password

1. The system stores user credentials in encrypted format for security purposesUser Role
2. A user role defines user authorization and should reflect the person’s title/job in the laboratory
3. Example user roles are:
   1. System Administrator – A type of IT operations personnel that configures the system, schedules job runs and backs up the system data
4. A user role represents a list of dashboard features to which the user has been granted access, i.e. privileges
5. Every user account is assigned a user role
6. The system allows authorized users to manage user roles
7. The system allows authorized users to manage user role privileges   

D.           Expected Outputs and Deliverables

1. Stable and working dashboard meeting the functional requirements outlined above
2. Documentation – Technical and User manuals
3. Activity reports and relevant annexes

Documentation

Documentation will include sufficient and detailed documentation for a general laboratory user as well as necessary details for the specialty laboratories as appropriate. The specific documentation guides shall be provided to cover the needs of the following users.

Installation and Administration

The installation guide shall be detailed enough to provide system’s administrators with all of the information necessary to install and bring the application live in a production environment. The documentation shall list all utilities and tools necessary for the proper administration of the system. These tools shall cover management and administration of the system database, the user interface, and any auxiliary programs integrated into the delivered system.

User Guide

Laboratory User documentation shall be sufficient and detailed enough to allow different levels of lab users to perform their functions without having to rely overly much on external support.

System Operator Documentation

This portion of the document is intended for those people who are running the system. It shall include direction for operating the various hardware components, operating the software and, recognizing and correcting problems.

This consists of, but not limited to, the following

1. Software and system operating direction

Hardware operating direction

Timelines for the deliverables/outputs

The work will be performed over a period of 90 working days spread over 3-4 months

E.      Institutional Arrangement

1. The IT LIMS Coordinator will review output and confirm acceptance, directly supervise the Contractor, to whom the consultant will be directly responsible, reporting to, seeking approval/acceptance of output
2. Progress report will be presented at the end of each milestone. There is an option for presenting the report virtually depending on circumstances.
3. The contractor is expected to liaise/interact/collaborate with IT LIMS Team through the IT Coordinator during performance of the work for technical guidance

F.      Duration of the Work

1. The work will be performed over a period of 40 working days spread.
2. MOHCC will is expected to review outputs, give comments, certify approval/acceptance of outputs, etc. with 2 weeks. 

G.     Duty Station

1. Training will be conducted at a venue to be determined by MOHCC

Competencies

Professionalism:

Demonstrates professional competence and mastery of subject matter;

Good research, analytical and problem-solving skills;

Conscientious and efficient in meeting commitments, observing deadlines and achieving results.

Communication:

Excellent and effective written and oral skills; ability to persuade people with varying points of view and to present information in a concise and accurate manner, ability to clearly communicate links between the organizations.

Planning and Organizing:

Proven ability to plan, coordinate and monitor own work and that of others;

Ability to work under pressure and uses time efficiently;

Identifies priority activities and assignments, adjust priorities as required.

Teamwork:

Works collaboratively with colleagues to achieve organizational goals;

Solicits input by valuing ideas and expertise of others and is willing to learn from others

LANGUAGE:

• Fluent in English

1. Scope of Price Proposal and Schedule of Payments

1. Lump Sum Amount is the preferred approach. 
2. The Lump Sum Amount must be “all-inclusive”.
3. Clearly state that the contract price is fixed regardless of changes in the cost components.

J.      Recommended Presentation of Offer

For purposes of generating Offers whose contents are uniformly presented and to facilitate their comparative analysis, it is best to recommend the preferred contents and presentation of the Offer to be submitted, as well as the format/sequencing of their presentation.  The following documents may be requested:

1. Duly accomplished Letter of Confirmation of Interest and Availability using the template provided by UNDP;
2. Personal CV or P11, indicating all past experience from similar projects, as well as the contact details (email and telephone number) of the Candidate and at least three (3) professional references;
3. Brief description of why the individual considers him/herself as the most suitable for the assignment, and a methodology, if applicable, on how they will approach and complete the assignment. A methodology is recommended for intellectual services, but may be omitted for support services [Note: this is optional for support services];  
4. Financial Proposal that indicates the all-inclusive fixed total contract price, supported by a breakdown of costs, as per template provided.  If an Offeror is employed by an organization/company/institution, and he/she expects his/her employer to charge a management fee in the process of releasing him/her to UNDP under Reimbursable Loan Agreement (RLA), the Offeror must indicate at this point, and ensure that all such costs are duly incorporated in the financial proposal submitted to UNDP. 

K.     Criteria for Selection of the Best Offer

Required Skills and Experience

The individuals desirous of quoting for the work should make an expression of interest by submitting the required documents and information listed below

1. The relevant individual should have a degree in Computer Science, Information Systems or any related field
2. Proven Knowledge and the use of the following tools is a must: Database versioning, java, jasper reports, angular JS
3. Knowledge of health information systems is an added advantage
4. At least 6 years working experience
5. Proven experience in developing working system (provide references)
6. The individual selected should be a local