Consultancy: Developing an Electronic Case Management System for the Ministry of Labour of Kenya

Request for proposals (individual consultant)

Background and Objective

The ILO is implementing the USDOL funded development cooperation project, All Hands in Kenya: Advancing Labour Standards through Cooperative Action. The project aims to strengthen labour inspection to promote compliance with labour law, international labour standards and acceptable conditions of work. To support this objective, the Labour Department and the Occupational Safety and Health Department within the Ministry of Labour (MoL) of Kenya will be equipped with an online Electronic Case Management System (ECMS) to manage labour inspection actions.

The Project recently completed the process of mapping the procedural workflows, drawing a static wireframe, and developing the Software Requirement Specifications (SRS) for the proposed system. These documents form the foundation of the ECMS and should be studied and referenced in the preparation of a response to this request for proposals.

Scope of Work

System requirements

1.Technical requirements

Interface language

The web application/user interface labels will be in English.

Concurrent users

The application should be designed to handle 200 concurrent planned system users (400 total) in 52 county offices throughout Kenya and 1000 concurrent public users.

Web based

The proposed ECMS must be a web-based application. The application should be accessible from a standard personal computer (PC), tablet, and/or cell phone device depending on the type of user and functions being used. The user interface should be homogenous on each platform (web and mobile). The application should be designed to work with a range of browsers (e.g. Chrome, Firefox, Safari) and operating systems (e.g. Windows, Mac, Linux) to ensure maximum accessibility.

User Interface (UI), User Experience (UX)

The user interface appearance and behavior should be coherent and compatible with W3C accessibility guidelines. The ECMS application will be built with the user experience in mind, with ease of use, low learning curve and sufficient performance as core principles. The application should be able to facilitate efficient navigation and minimize the time required to complete tasks.

The application should provide online help and context-sensitive online help facilities, with meaningful error messages that users can appropriately act upon. The user interface should follow a single or a limited number of user interface rules, consistently with the operating system environment in which the ECMS operates. The application should also provide easy-to-use and intuitive end user and administrator functions, as assessed by a panel of typical users. Furthermore, the user interface should be compatible with specialist software used by users with disabilities and provide the ability for users to move, resize and modify display windows, select sound and volume of audio alerts, and save modifications in a user profile. The application should offer persistent, user-definable defaults for data entry where desirable.

Single Sign On

The application should work with a “Single Sign On” approach. This means that a user needs to login only once to navigate through the entire ECMS application to access the functionality associated with their user profile. Depending upon the user rights and access control, functional modules are displayed and specific data at the appropriate administrative level is provided. To ensure security, the system must have a session timeout set with auto logout after a fixed time, whereby the user will have to login again.

Reporting and Analytics

The ECMS should provide built-in reporting and analytics capabilities that allow users to generate ad-hoc reports and analyze data. The system should support a variety of data visualization tools and should be able to export data in various formats, including PDF, Excel, and CSV.

Document Management

The ECMS must have document management capabilities that can capture and declare electronic records, including those from existing electronic documents or newly created ones. It should be able to acquire metadata directly from the record-generating application and allow additional metadata completion by the user. The system must also manage electronic documents within the same file plan and access control mechanisms as electronic records. Additionally, it should allow editing of electronic documents that have not been declared as records, while preventing editing of those that have been declared as records. The ECMS should manage versions of electronic documents as separate entities while maintaining the link between them. It should interface with related packages such as image processing and scanning systems and workflow systems while retaining control of existing electronic records.

Cloud environment during the duration of the service contract

The service provider will provide the cloud environment from application development until the end of the maintenance period. At handover, the cloud environment will be migrated to the cloud or physical server to be determined.

Cloud environment/data hosting post the service contract

Data hosting will be provided on the premises using the Government Common Core Network (GCCN). This is to be determined and may differ per office.

Hardware, operating systems, and network environments

The hardware environment should support both client-server platforms and workstation environments. The operating system environment should be compatible with the ECMS, such as Microsoft Server 2019 or Unix versions like Ubuntu Server. The user interface industry standards should be supported, including Microsoft Windows and X-Windows. The ECMS should also have an intranet browser interface using HTML5 standards.

Supporting Software

A database management system license and implementation are necessary for integration with the ECMS, including the SQL language version. The ECMS should be able to interface with various user applications like word processors, spreadsheets, e-mail systems, and other applications for the capture of electronic records. The system should also produce various output formats for individual or bulk exports, including PRO-required formats for permanent preservation and electronic publishing formats such as CSV, PDF, HTML 5.0, and XML. Search and retrieval and information exchange standards, including Z39.50, should be supported by the ECMS. TWAIN and/or Isis scanner interfaces and Group IV facsimile compression should also be integrated into the system. The ECMS should support the TIFF v6 image format, and if the system allows for color images, JPEG, PNG, GIF, or other user-selectable formats should also be supported.

Scalability and Performance

The ECMS should be designed to handle the current workload and should be scalable to accommodate future growth. The system should have sufficient processing power, storage, and network bandwidth to provide fast response times and minimize downtime. Estimated system data requirements are as follows:

Year One:

Installation, System Data and User Data: 2 TB

Year Three:

Total system Data and User Data: 3 TB

Year Five:

Total system Data and User Data: 6 TB

Departments should consider the extent to which the ECMS provides short response times (in line with user expectations), and is capable of serving the range of sizes of user population for which it is intended, including:

• Adequate response times for commonly performed functions under standard conditions, including 75% of the total1000 anticipated user population logged on and active, 100% of the anticipated total volume of documents managed by the system, and consistent performance over at least ten transaction attempts.
• Simple searches should be performed within 3 seconds and complex searches within 10 seconds.
• The first page of a record accessed within the previous three months should be retrieved and displayed within 4 seconds, while the first page of a record not accessed within the previous three months should be retrieved and displayed within 20 seconds.
• A single implementation of the system should have an electronic record store of at least 17 Terabytes or and serve at least 200 users simultaneously.
• The system implementation should be expandable in a controlled manner, up to at least 800 users, while providing effective continuity of service.
• The system should support the above without imposing undue systems/account management overheads and without any features that would preclude use in small or large organizations, with equally variable numbers of differently-sized organizational units.

Maintenance

The ECMS system should allow for organizational changes, support user movement, re-configure system parameters, provide backup and recovery facilities, monitor storage space, and ensure ongoing development and support.

• It should allow for bulk changes to record organization, folder structure, and indexing information, while ensuring metadata and audit trail data are accurately handled. This allows for organizational changes such as dividing an organizational unit into two, combining two units into one, moving/re-naming an organizational unit, or dividing a whole organization into multiple units. The system should also support the fluid movement of users between organizational units, individually or in bulk.
• It should allow for retrieval, display, and re-configuration of system parameters and implementation choices, such as indexing elements, user roles, and functions.
• It should provide backup facilities and rebuild capabilities using backup and audit trails.
• It should also offer recovery and rollback facilities in case of system failure or update errors, with notification to administrators of the results.
• It should monitor available storage space and alert administrators when necessary.
• Ongoing development and support are crucial to ensure the system can be upgraded to keep up with changes in systems and application software.

Integration with Other Systems

The ECMS should be designed to integrate seamlessly with other existing systems, such as document management systems, accounting systems, etc.If the new or modified system needs to communicate with another government site or an external organization (like a payment carrier), certain specifications for the interface need to be written. These specifications depend on whether the interface is sending data from the new system to the other site/organization or receiving data from them. If the interface is sending data, the specifications should be detailed enough for the other organization to develop the necessary file processing. If the interface is receiving data, the specifications should provide sufficient information for the other organization to effectively use the interface file in their application. The interface specifications should include the following:

• An overview of the data required for each specified file, including a description of the data.
• The frequency of data submission (e.g., monthly, annually), the effective dates of the submissions, and the due dates (e.g., 5th working day of the month).
• A record layout for each transmitted file.
• A list of data elements, including the format for each data element.
• Physical file characteristics, such as the data set name, record length, and record format.

Alternatively, if the files are transferred via FTP (File Transfer Protocol), the specifications should include:

• The file name to be transmitted.
• The target system for the FTP transmission.

Additionally, the specifications should outline the procedure for notifying the receiving site when the file has been submitted. It’s important to note that at this stage of the development process, any general issues regarding the interface should have already been resolved.

Regulatory compliance

The ECMS should be designed to comply with all relevant regulatory requirements, such as data protection laws, privacy laws, and institution-specific regulations. The system should have built-in controls and features that help users comply with these regulations.

2. Security requirements

Access Control and Domain Rights

The ECMS should establish access controls including controls to identify, authenticate and permit access only to authorized individuals and controls to prevent users from providing information to unauthorized individuals who may seek to obtain this information by fraudulent means. Access control protocols for users will be based on the following functions:

• ECMS shall require a login and password designed to meet minimum security requirements (e.g. X number of letters, numbers, etc.) to access a web-based case management system algorithm.
• A two-factor authentication – this is where a system may, for example, require users to provide a verification code or answer a security question, along with their username and password to log in.
• In addition, the software shall include Single Sign On (SSO) capability – this is an authentication process that allows organizations to manage login credentials for multiple applications in a singular location using an Identity Provider (IDP).
• The ECMS must support control of access to electronic records and electronic folders.
• The ECMS must support a minimum protective marking scheme, which allocates security categories to records, folders and users as a means of controlling access; and should support a more extensive protective marking scheme.
• The ECMS must support control of access to electronic records and electronic folders by business or organisational grouping, lists of named users, or individual owner.
• The ECMS must support the allocation of users to one or more user roles, which determine allowable user access to system functions and facilities available in the ECMS.

Encryption

The ECMS should provide encryption of electronic information, including while it is in transit or in storage on networks or systems to which unauthorized individuals may have access. The ECMS must be able to retain the information that an electronic signature has been verified as authentic, as a metadata element bound to the electronic record with which the signature is associated.

• The ECMS must be able to retain and preserve as metadata, details about the process of verification for a digital signature, including the Certification Authority with which the signature has been validated and any checks made against a certification revocation list or similar status verification agency.
• Where an electronic record has been sent or received in encrypted form by a software application which interfaces with the ECMS, the ECMS must be capable of restricting access to that record to users listed as holding the relevant decryption key, in addition to any other access control marking allocated to that record.
• Where an electronic record has been transmitted in encrypted form by a software application which interfaces with the ECMS, the ECMS must be able to keep as metadata with that record the fact of encrypted transmission, the type of algorithm, and the level of encryption used.

Network Security

System should use SSL encryption based on https protocol. Public-key encryption methods are used as part of SSL encryption and are expected to be part of the ECMS.

Intrusion Detection Systems, Backup and Continuity Plans

Monitoring systems and procedures should be suggested by the service provider to detect actual and attempted attacks on or intrusions into ECMS. Measures should be in place to protect against destruction, loss, or damage of beneficiary information due to potential environmental hazards, such as fire and water damage or technological failure. The system should have built in data archiving facility to perform automatic data backup provision and archive all historical data based on the scheduled time/date.

Data Protection and Privacy

International best practices to maintain the data protection and privacy in the ECMS is strongly proposed. Specific reference is made to Kenya data protection guidelines where applicable. Any sensitive issues or concerns should be raised as soon as they are identified.

Audit Trail

The system must maintain a record of all activities and changes to management information. This will include trail of all actions executed, which identifies the user and associated details, the data being changed, and the time of the action.The audit trail must be retrievable and exportable in various formats, including PDF, Excel, and CSV.

3. Other requirements

Data Migration

Data migration from existing legacy Microsoft Excel or Access will only be facilitated by the service provider if provided in a uniform and homogenized manner. Errors in data migration due to unclean or non-uniform data is not the responsibility of the service provider.

Cloud computing services

The service provider will provide cloud computing services throughout the duration of the contract, including during the warranty period. Upon completion of the warranty period, cloud computing services or physical servers to ensure functionality of the system, will be the responsibility of the Ministry of Labour.

ECMS Modules

The ECMS should include the following modules as detailed in the workflow, wireframe, and SRS. These modules should be interconnected and integrated with each other to support implementation as proposed in the SRS.

There are three groups of modules. The Common Modules are accessible by both the Labour and OSH Department. The Labour Department Modules are only accessible by the Labour Department. The OSH Department Modules are only accessible by the OSH Department.

1.Common Modules (accessible from the Labour and OSH Department)

Complaints Module

Receive and review labour law and OSH related complaints. A complainant can lodge a complaint with the labour/OSH inspector by filling in the form. The system should create an entry on the Complaint Register with a reference number, generate a PDF document of the form, and notify the complainant. The system should allow for automated or manual allocation of the complaint to an officer. The officer determines the complaint’s validity and whether to link it to the inspection process or end the process. The system flags various actions as per timelines laid out and changes the complaint’s colour to indicate the stages of the process.

OSH Recording Module (accidents, diseases, dangerous occurrences)

Receive and review reports of accidents, illnesses, and diseases from workers and employers, and analyse statistics for public policy making. The module should make available the DOSH 1 form sections Part 1 to the public to enable them to make accident notifications, Part 2 to doctors to enable them to make doctor’s reports, and all sections to only inspectors to enable them to make investigation reports. The system should create an entry on the Complaint Register with a reference number, generate a PDF document of the form, and notify the complainant. The system should allow for uploading of evidence and reports by all parties, including the public, doctors, and inspectors, and should present an option for inspectors to take a subsequent inspection action. All complaints should be entered into a register with each complaint being tracked as per agreed timelines. Additionally, on completion of investigation and when a claim is found, the system shall present form DOSH for filling the claim details. During the filling of the claim form, the system shall automatically calculate the total claim as per the agreed parameters.

Reporting/Notifications Module

This module should be able to capture various types of reports such as death, dismissal, redundancies, strikes/lockouts, and distress calls. For death reports, the system should capture the cause and location of death and trigger an inspection by OSH or Labour for benefits. For dismissal reports, employers should upload evidence of the dismissal process and indicate the amount of wages due. For redundancy reports, employers should fill a notice one month prior, indicate the criteria and provide details on numbers, gender, occupation, sector, and region county. For strikes/lockouts reports, employers/employees should indicate the sector, notice period, region, and reasons. Finally, for distress calls, the system should capture details such as name, ID/passport number, employer/employment agency details, and the nature of distress and report to NEA or Labour Attaché.

Inspection Assignment Module

The Inspection Assignment Module should have the capability to assign inspection actions to inspectors, which may include statutory visits based on inspections, complaints or accident reports from Module 1 and 2, and other relevant criteria. It should be able to enable automated assignment based on agreed parameters, such as unit/speciality (OSH or labour law), workload, geography, or other criteria. This feature can save time and ensure that the most appropriate inspector is assigned to the task. Moreover, the module should allow managers to manually assign, cancel or pause inspection actions as needed, providing them with greater control over the inspection process.

Customizable Digital Inspection Checklist Module

The Customizable Digital Inspection Checklist Module should be designed to enhance the inspection process by allowing inspectors to view and check off topics in real time using a cell phone or tablet. The module must be easily customizable with an administrator login to keep up with the latest changes in laws and practices. Additionally, the module should provide inspectors with the ability to pull up content relevant to a specific issue, enabling them to quickly address any potential problems that arise during the inspection process. With these features, the Digital Inspection Checklist Module can streamline the inspection process, saving time and ensuring thoroughness in inspections.

Reports Module

The reports module should be able to visualize key inspection metrics, such as inspection actions undertaken by sector, location, and enterprise type, violations detected by sector and issue, remediation rates by sector and issue, and other to be determined metrics. Inspectors should be able to access this module, which automatically draws from the input fields of the Complaints Module, OSH Accident Reporting Module, and Case Management Module. The module also generates preconfigured reports, such as a report based on Part IV of the ILO Labour Inspection Recommendation R081, pulling from a static set of input fields. In addition, inspectors should be able to generate unique reports pulling from user-selected input fields, providing customized insights into inspection data.

Case Management Module

The case management module is responsible for tracking and managing inspection actions and complaint investigations. It should include the following functionalities:

• Allow the officer to generate a contravention notice or letter of improvement. Once all the minimum fields are entered, a PDF should be generated. The system should automatically sign the notice and send it to the contravening party via email (if available) with a link for them to acknowledge receipt and commit to correct the issues raised.
• Allow the contravening party to upload evidence of dealing with the corrective action(s) and the officer to upload evidence of dealing or not dealing with corrective actions.
• Allow the officer to enter a decision on whether compliance has been met or not. If yes, the system should generate a compliance certificate; otherwise, the case is linked to the appeal or prosecution process.
• The system should generate a notice of prosecution and a charge sheet from templates and forward the file to the Office of the Director of Public Prosecution (ODPP).
• Be linked to the ODPP system, if ODPP allows, to enable registration of the case and have a diary for entering court proceedings and dates.
• Track and trace inspection actions (at a minimum labour and OSH inspections and accident/complaint investigations).
• Include all the steps in each inspection action, from initiation to conclusion.
• Record start and end dates and required timeframes for each step. Replicate required input fields for standard forms used in some steps.
• Allow digital reviews and authorizations for different user roles at required decision points.
• Record transfers of actions to other authorities.

User Dashboard

The User Dashboard should provide a real-time status of current and pending actions, including alerts for upcoming deadlines. Inspectors should be able to use the dashboard to manage and review their workload and outputs. Managers should also be able to monitor the performance of inspectors under their supervision or the inspection system. The dashboard should provide a centralized location for users to access information and track progress.

Economic Units Database

The master list of economic units should be searchable for the inspectors to research previous inspection actions and findings. It should also be searchable and sortable for the selection of economic units for an inspection plan. The master list is preferably integrated with the most comprehensive registry of economic units in the country, and each economic unit should be linked to a unique identifier like the Tax Identification Number (TIN). The list should be automatically updated with manual entries from users to ensure accuracy and timeliness of information. Having a well-maintained and up-to-date master list of economic units would aid in efficient and effective inspection planning and implementation.

Data Analysis Module

The Data Analysis Module should enable the review and analysis of data from the Reports Module and Economic Units Database to target non-compliant economic units for inspection. Inspectors should be able to classify enterprises based on their infringement history and other indicators of non-compliance. The module should be integrated or aligned with other relevant internal or external systems to provide useful data for targeting. The data set should be built to enable predictive analytics in the future, enhancing the efficiency and effectiveness of the inspection process.

2. Labour Department Specific Modules

Attestation Module

This module should allow employers to download forms and provide details such as the number of workers, country of destination, and occupation/sector. Once the form is completed, employers can book a date for attestation. After the attestation, the system should provide feedback and remarks.

3. OSH Department Specific Modules

Approval of Consultants/Institutions Module

The Approval of Consultants/Institutions Module should be able to facilitate the approval process for consultants and institutions. The module should enable the completion of forms, attachment of credentials/certifications, payment of fees, submission to DOSH, and interview by DOSH. It should also allow for the upload of reports and the generation of certificates. The module should be accessible to the public and inspectors.

Approved Work (OSH Audits, Fire Audits, Examination of Plants, Training) Module

This module should be able to manage approved work activities, such as OSH audits, fire audits, examination of plants, and training. The module should require notification to the officer 14 days prior to the activity, with the submission of the report within 30 days after the activity. The report should be available to the employer after review, with actions taken by officers/employer on recommendation.

Architectural Plans Approval/Construction Sites Module

This module should be able to manage the approval process for architectural plans and construction sites. The module should enable the submission of plans, computation of charges, payment of charges, and approval of licences. The module should also allow for collaboration between the public, inspectors, and the system.

Registration of Workplaces and Renewal of Registration Module

The Registration of Workplaces and Renewal of Registration Module should enable the registration and renewal of workplaces. The module should include two tabs for Workplace and BCR registration and renewals, each containing forms for registration and renewal. Once a registration form is filled, the system should present the self-assessment form for the respective application. All applications should be entered into a register and presented on the dashboard. The system should allow for automatic or manual assignment of applications to various inspectors based on their duty station. Inspectors should be able to review the filled forms and decide whether to approve the application or not. Once an application is approved, the system should generate the certificate automatically and send it to the applicant in PDF format. If the application is not approved, the system should send reasons for rejection to the applicant.

Written Documentation

The service provider will develop and handover full system documentation. These documents must be current at the time of the handoff and cover the final version of the system implemented.

Required technical documents include:

1. Design documents that outline the design and architecture of the electronic case management system, including its various modules, features, and functionality. These documents may include flowcharts, diagrams, and other technical specifications that describe how the system works.
2. System database schema that refers to the underlying structure of the electronic case management system’s database, which stores all the data associated with the system. This schema defines the various tables, fields, and relationships within the database and serves as a blueprint for the development and maintenance of the system’s data storage. The Systems Manual is for use by those responsible for on-going maintenance of the system.
3. Application interface requirements that contain the specifications and guidelines for the graphical user interface (GUI) of the electronic case management system. This includes the layout, appearance, and functionality of the various screens, forms, and menus within the system, as well as any other user-facing components.
4. Technical support/Operations Manual. The Operations Manual contains information required for the production control group to run batch portions of the system, if any. The Operations Manual must be reviewed by the manager of the production control group. (The production control group is the group within the administrative computing department that is responsible for running batch portions of production systems.) This would include:
   • Overview of the system architecture: Provide a high-level overview of the system’s hardware and software components.
   • Installation