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.
- The system maintains list of device profiles
- The device profile consists of all or some of the following, but not limited to
- A unique identifier (System generated)
- Asset number (MOHCC generated)
- Serial number
- Device name
- 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.
- The system maintains list of Health facility profiles
- A health facility may be a clinic, a hospital, a health center or another laboratory, etc.
- The provider profile consists of, but not limited to, the following
- A unique health facility identifier (Generated by MOHCC)
- Health facility name
- District
- Province
- Geo coordinates
- Physical address
- Telephone number
- Email address
- Contact person(s)
- 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.
- The system maintains one or more catalogs of all the offered testing services, i.e. tests.
- Tests may be grouped in one or more categories and sub-categories in a catalog
- A catalog test entry consists of, but not limited to, the following:
- A unique test identifier/code
- Test name
- Category name
- Subcategory name
- The system allows authorized users to assign one or more test catalogs to health facility or device
- The system allows authorized users to manage the test catalogs
- 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
- Scheduled emailing of reports to set users
- Email notification upon a particular event such as QC failure or equipment error threshold
- Add request and sample received and accepted to specific test schedule
- 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
- The report will show a list of devices with the following information
- Instrument name
- Instrument identifier (S/N, etc.)
- Last test date
- The system should allow the user to filter the list by
- Facility
- District
- Province
- Device category
- Date filters such as reported in the last X days, performed tests in the last X days, not reported in the last X Days
- The system should allow user to export the list to , but not limited, the following formats
- CSV
- XML
- JSON
2. Facility list
- The report should list all facilities in the system indicating
- Facility name, district, province
- Instrument available at the facility
- Date when each device last send data
- Date when device last performed a test
- Reports can be either displayed (viewed on a monitor) or printed
- The system should allow the user to filter the list by
- District
- Province
- Instrument category
- Date filters such as reported in the last X days, performed tests in the last X days, not reported in the last X Days
- The system should allow user to export the list to , but not limited, the following formats
- CSV
- XML
- 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
- Determine the viral suppression target
- Specify age stratification categories
- Specify gender stratification categories
- Specify other stratifications (case information) e.g. pregnancy, breastfeeding, drug regimen
- Specify location stratification categories
- 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
- Show number of samples received during a specific period
- Show number of samples rejected during a specific period
- Percentage of samples rejected (a/b X 100%)
- Categorize rejections by rejection reason
- 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
- Show number of samples received
- Show number of samples tested
- Show number of samples with invalid results
- Percentage of samples with invalid results
- Invalid results by device
- 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
- Show number of samples tested
- Show number of samples which failed
- Percentage of failure
- Failures by device
- 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;
- Indicate number of samples received
- Number of samples tested by
- Number of valid results
- Number of patients achieving targets, e.g. positivity for Covid, VL suppression for HIV VL, TB resistance for TB, etc.
- Categorize patients by different variable, e.g. regimen, reason for test, case information
- 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
- Categorize tests by sample type
- Categorize tests by facility level (rural health center, district etc.)
- 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.
- Categorize by reason for testing
- Categorize by submitting clinic
- 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
- Number of samples by date collected, registered, received, tested, delivered results
- Number of results report
- Number of results reported within defined turnaround time
- Percentage of results reported within defined turnaround time
- Categorized by testing facility
- Categorized by submitting facility
- Categorized by instrument
11. Health facility performance report
The aim of the report is to evaluate performance of different laboratories by;
- Showing number of facilities serviced
- Samples received
- Repeat tests performed
- QA test performed
- 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
- The dashboard system provide online access to various laboratory personnel
- Online access to the dashboard system is granted only through dedicated user accounts
- The system maintains list of user accounts
- A user account consists of the following components:
- User Profile – contains user contact information
- User Credentials – contains user authentication (identity confirmation) information
- User Role – Defines user authorization and privileges
- The system allows authorized users to manage user accounts.
User Profile
- The user profile contain the following contact information
- Person full name including last (family), first (given) and middle names
- Gender
- Tile
- Department/organization
- The system allows authorized users to manage user profiles
User Credential
- User credentials consist of the following information:
- A unique username and
- A unique password
- The system stores user credentials in encrypted format for security purposesUser Role
- A user role defines user authorization and should reflect the person’s title/job in the laboratory
- Example user roles are:
- System Administrator – A type of IT operations personnel that configures the system, schedules job runs and backs up the system data
- A user role represents a list of dashboard features to which the user has been granted access, i.e. privileges
- Every user account is assigned a user role
- The system allows authorized users to manage user roles
- The system allows authorized users to manage user role privileges
D. Expected Outputs and Deliverables
- Stable and working dashboard meeting the functional requirements outlined above
- Documentation – Technical and User manuals
- Activity reports and relevant annexes
ACTIVITIES |
DELIVERABLE |
DURATION |
WEIGHT % |
Meeting with key stakeholders |
Inception report |
1 day |
15% |
Development of a working dashboard meeting the functional requirements as outlined above |
Technical Report |
22 days |
40% |
Presentation of system to stakeholders |
Technical report |
3 days |
|
System reconfiguration |
Technical Report |
5 days |
15% |
Development of Technical and User Manuals |
User Manuals |
5 days |
|
The comprehensive dashboard/final report to be presented to MOHCC Top Management. |
Final draft evaluation report |
1 day |
15% |
Training of Users |
Training report |
3 days |
15% |
|
|
|
|
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
- 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
- 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
- Progress report will be presented at the end of each milestone. There is an option for presenting the report virtually depending on circumstances.
- 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
- The work will be performed over a period of 40 working days spread.
- MOHCC will is expected to review outputs, give comments, certify approval/acceptance of outputs, etc. with 2 weeks.
G. Duty Station
- Training will be conducted at a venue to be determined by MOHCC
Comments