Terms of Reference (TOR) for design and

development of an electronic medical system

Investing in digital health for Non-Communicable

Disease (NCD) quality management

Proposal to be submitted to: [email protected]

Closing date of submission: 28 July 2017 (UTC +3:00)
Nairobi
Glossary
ToR Terms of Reference

EMS Electronic Medical System

API Application Programming Interface.

User User is used to mean health care workers and Ministry of

Health officials from 4 Nairobi sub-counties

UI User Interface

Responsive An approach to web design aimed at crafting sites to

Web provide an optimal viewing experience— easy reading

Design and navigation with a minimum of resizing, panning, and

scrolling —across a wide range of devices and platforms /
operating systems (from desktop computer monitors to
mobile phones, Android, Windows, etc.)
Scalable Ability of a system to handle growth in data, users and
modules
Coding Coding is the transformation of healthcare diagnosis,
procedures, medical services and equipment into universal
medical alphanumeric codes

CAPTCHA A program that will distinguish human from machine input,

typically as a way of blocking form submissions by
spambots

WYSIWYG A WYSIWYG is an editor or program that allows a

(What You developer to see what the end result will look like while
See is What the interface or document is being created.
You Get)

(ii)
 Table of Contents
1. Executive Summary: 1
2. Background: 2
3. Objective of the project: 3
4. Scope of the assignment: 3
5. Work schedule of the assignment: 3
6. Main Objective of the System 3
7. Technical Requirements: 3
8. Security 5
8.1. Password policy 5
8.1.1. Introduction 5
8.1.2. Password changes 5
8.1.3. Minimum password length: 5
8.1.4. Complex passwords required 5
8.1.5. Limit on consecutive unsuccessful attempts to enter a password 5
8.1.6. Encryption 6
9. Responsibility 6
9.1 User 6
9.2 Developer 7
10. Downstream Work: 7
10.1. Warranty 7
11. Qualifications and Competences 7
12. Annexure I 8
12.1 System Requirement Specification 8
12.1.1. Database 8
12.1.2. Application 8
12.1.3. Communication 9
12.1.4. Interoperability 9
12.1.5. System error correction 9
12.1.6. Patient ID 9
12.2 Modules: 9
12.3 Disaster contingency plan 10
12.4 Technology Transfer 11
12.5 Deployment of the system 11
12.6 Training 12
12.7 Documentation 12
12.8 Technical Support 12
12.9 Ownership of Source Code 12
13. Annexure II 13

(iii)
1. Executive Summary:
Malteser International (MI), through the German Ministry for Economic Cooperation
and Development, in collaboration with the Nairobi City County Health Services
Department and the African Institute for Health and Development (AIHD) plans to
implement a project aimed at strengthening the health care system through improved
capacity in management of selected NCDs within Nairobi’s informal settlements. The
project will use an innovative technology to build the capacity of healthcare workers
to adhere to clinical guidelines in the management of hypertension and Diabetes
Mellitus (DM). The system will provide a platform to easily digitize data leading to
improved NCD health information in 45 health facilities in four sub-counties of Nairobi
County.

1|P age
2. Background:
Currently, patient level data is mainly recorded using a manual system i.e. patient
card, clinical notes and register. This information is summarized at the end of the
month by the health workers and forwarded to health managers at various levels.
There are lots of problems faced due to the current practices of information collection.
The information captured is not organized and does not evaluate the clinical
adherence to recommended clinical guidelines.
The proposed digital platform will mostly be utilized at first or second level health
facilities in Nairobi. The development of technologies supporting this project, require
tools and components that are user friendly, easy to sustain and possibly be replicated
in various other facilities and settings in the future. The developer should interpret and
prescribe suitable solutions, considering current industry standards, ease of use and
maintenance, as well as sustained future outlook.

2|P age
3. Objective of the project:
● To create a platform that will assist health managers to address the
challenge of weak capacity in the diagnosis and treatment of patients with
hypertension and diabetes through improved patient and data management
at the basic health care level.
● Digitalize patient level data with the aid of a coding system that is aligned to
existing national guidelines for hypertension and diabetes.
● Alignment of system to existing e-Health tools such as the District Health
Information System 2 (DHIS 2) through innovative mechanisms.

4. Scope of the assignment:

This assignment is to design, develop and deploy a customized EMS. The detailed
scopes of the assignment are specified in Annexure I.

5. Work schedule of the assignment:

The client's expectation of time schedule is produced in Annexure II.

6. Main Objective of the System

To ensure health workers adhere to national clinical guidelines for hypertension and
diabetes through the use of a digitized platform which then leads to a more qualitative
analysis of data and decision making on all levels.

7. Technical Requirements:
Overview of the proposed platform
The proposed system shall contain the following technical
requirements/functionalities, but not limited to:
● Diabetes management module; will contain specialized EMR case sheets for
3|P age
 diabetes Type I, diabetes Type II, pre-diabetes and gestational diabetes.
● Hypertension management module.
● Integration; allow integration of existing e-Health tools such as DHIS2 (API
Provision)
● Easy to use, intuitive user-experience and interface.
● Easy management of users and patient information.
● Responsive Web Design technologies
● System should allow for easy administration of all components by the Super-
User/Admin.
● Follow-up visits; the system should contain intelligent recalls and follow-ups that
auto-creates appointments in the calendar. As an added option the system can
send a confirmation to the patient by sms/email and remind the patient to turn
up on the day of the appointment.(sms cost to be incurred by clinic)
● Secure, using industry standard security and encryption methods.
● Implement data validation for both client and server.
● Don't Repeat Yourself (DRY) principle in coding is recommended.
● Implement Search, Create, Read, Update, Delete (SCRUD) operations.
● Adopt Role-Based Access Control (RBAC) to authorize system
resources allocation to users based on roles.
● Ensure compatibility to all the browsers (Mozilla Firefox, internet Explorer,
Google Chrome, Opera, Safari).
● Scalable and upgradeable as and when the number of users and
content increases.
● Maintain and ensure that the solution supports maximum concurrent
users.
● The portal should run optimally (page load time below 30 seconds) on
a PC connected to a network with minimum bandwidth of 512 kbps.
● Image and other content customization features should be inbuilt
within the system to allow standard content sizes (e.g. standard image
sizes for easy uploading and processing).
● The system should allow input of imagery and FAT32 compression
for storage and transmission of data.

4|P age
 ● Provide user help functionality on major components (e.g. FAQs)
● Maintain consistent aesthetics and UI of the software.

8. Security

8.1. Password policy

8.1.1. Introduction
Usernames and passwords are utilized in order to access the EMS. They also
protect patient data from unauthorized individuals, both internally (other staff)
and externally (hackers).

8.1.2. Password changes

System should ensure users change their passwords periodically. The Systems
Administrator should select an appropriate time frame for changing passwords.

8.1.3. Minimum password length:

The length of passwords must always be checked automatically at the time that
users construct or select them. The system must enforce passwords of at least
eight (8) characters.

8.1.4. Complex passwords required

The system must enforce a password that contains at least:
-1 lowercase and 1 uppercase letter.
-1 special character (!@#$%^&*)
-1 number (0–9)

8.1.5. Limit on consecutive unsuccessful attempts to enter a password

The system should be able to prevent password guessing attacks, the number
of consecutive attempts to enter an incorrect password must be three (3)
unsuccessful attempts. The involved user account must be suspended until
reset by the Systems Administrator.

5|P age
 8.1.6. Encryption
Passwords must always be stored in an encrypted format in the database.
Developer must use universally accepted encryption standards that helps
protect against the threat of malicious activity by performing real-time encryption
and decryption of the database.

The developer shall also adhere to following security requirements:

Information Security which is based on the following elements:
o Confidentiality - ensuring that information is only accessible to those
with authorized access.
o Integrity - safeguarding the accuracy and completeness of information
and processing methods.
o Availability - ensuring that authorized users have access to information
when required.
o Compliant use - ensuring that the platform meets all legal and
contractual obligations.
o Responsible use - ensure appropriate controls are in place to enforce
ethical and law-abiding behaviour, conservation of common resources,
and respect for other users within the system.
● The software should provide audit trails and logs mechanism for content
changes performed by system users.
● Maintain time series data so that certain information is not lost with passage
of time and repeated updating.
● Include up-to-date CAPTCHA program as a remedy to stop spam and
other intrusions wherever required.
● Handle session hijacking and session replay.
● Input validation to prevent attacks such as buffer over -flow, cross-site
scripting and SQL Injection.

9. Responsibility
9.1 User
● Shall ensure bi-weekly updates are reviewed and comprehensive requirement
6|P age
 specifications are provided within review period.
● Shall maintain the delay register and notify the developer of all delays in
writing; shall appoint the point of contact or project focal person(s).
● Inform the stakeholders and arrange for joint sessions with developers.

9.2 Developer
● Shall provide the portal development platform acceptable to user.
● Shall provide all details regarding licenses if required (based on selected
solution).
● Shall maintain the delay register and inform the user on the delays.
● Shall appoint a project manager who shall be the point of contact; and
● Shall recommend suitable hosting environment (server specifications and
similar) to host the portal safely and efficiently.

10. Downstream Work:

10.1. Warranty
Provide a two year warranty after the user acceptance signoff. During this period, the
developer is responsible for the following technical support:
● Update patches,
● Fix bugs,
● Make post-deployment changes to the system based on feedback from user
experience.

11. Qualifications and Competences

● At least 5 years’ experience working in M-Health and e-Health sector
preferably in Africa.
● Familiarity with Government of Kenya, and specifically Ministry of Health
policies, systems and procedures.
● Experience in web-based software development.
● Advanced knowledge in database implementation, configuration, and
troubleshooting of database instances.
● Familiarity with standard ICT industry best practices, with emphasis on

7|P age
 change control and contemporary system security methodologies.
● Excellent understanding of health sector governance and management
issues.
● General knowledge of GIS (Geographic Information System) themes
and operation
● Demonstrated project management experience of varying scope
● Commitment to accuracy
● Previous experience with NGO related projects / track record is a plus

12. Annexure I
Detailed scope of the assignment
The assignment is to design, develop and deploy an interoperable EMS that focuses
on adherence to national hypertension and diabetes guidelines that is easily
accessible to health management teams. The details of the assignment includes
following:

12.1 System Requirement Specification

12.1.1. Database
The database should be normalized.
The system must encrypt patient data, usernames and password stored in the
database using Advanced Encryption Standards (AES).

12.1.2. Application
All request and data transfer between the server and the database must be done over
an SSL connection.
The application shall have tutorial documentation, for the purpose of educating new
users as well as acting as a reference. Clear procedures and proper protocol must be
explained in detail, as often these tasks must respect both legal and business
concerns. These procedures shall be presented in step- by -step instructions which
are accompanied by both screenshots and -application tooltips. The goal here is to
produce an interface which can self-teach its own practice to any first time users.

8|P age
 12.1.3. Communication
All communication between the server, session app and system application will be
done over SSL.
The database will communicate via an encrypted remote connection using SSL.

12.1.4. Interoperability
System should support:
• Data transfer and sharing on much more than a local or enterprise-wide scale
• Knowledge transfer and integration
● Medical terminology transfer, mapping and integration
● Image transfer
● Integration with clinical and non-clinical applications

12.1.5. System error correction

The system must require high levels of error correction and input validation.

12.1.6. Patient ID
The system must identify the patient by a unique alphanumeric identifier derived from
a function performed during patient registration.
Note. The developer will create an Algorithm that will be used to create unique patient
identifier.

12.2 Modules:
The major features includes, but not limited to:
● Digital coding of national guidelines for clinicians to fill;
o Patient summary,
o Medical history,
o Laboratory information,
o Drug/prescription history,
o Appointments and scheduling with reminders.
● Reporting & Analytics(monthly/weekly/yearly);
o Smart analytics shows the information in context to the previous period
9|P age
 with computed percentages for analysis.
o Extensive list of reports so that you can measure every aspect:
▪ Patient list/summary reports
▪ Diagnosis registry report
▪ Lab reports
▪ Drug interactions report
▪ Referrals report
● General system requirements;
o Integration(API)
o Frequently Asked Questions (FAQs)
o Clinical data repository
o Integrated pharmacy & inventory

12.3 Disaster contingency plan

Backup & Recovery
Backup of information is fundamental to the reliability and recoverability of the EMS.
A documented backup plan which defines the backup routines of the system shall be
provided. A backup plan aims at ensuring that information in backups is complete
and sufficient.
The system should automatically perform regular backups of all critical items
including; patient data, system logs, reports and the database in an encrypted format.
The backups shall be stored in an off-site storage location or preferably a secure
cloud storage. The backups will regularly be tested to ensure integrity of the backups

Disaster Recovery/Management
The developer shall provide a disaster recovery plan which is properly documented,
tested and maintained to ensure that in the event of a major failure of the EMS or a
corrupted database, essential level of service will be provided.
The disaster recovery plan should include:
● Emergency procedures, describing the immediate action to be taken in case of
a major incident.
● Fall back procedure, describing the actions to be taken to relocate essential
activities or support services to a backup system.
10 | P a g e
 ● Restoration procedures, describing the action to be taken to return to normal
operation at the original system.
● Specific disaster management plan for critical applications shall be developed,
documented, tested and maintained on a regular basis.
● Responsibilities and reporting structure shall be clearly defined which will take
effect immediately on the declaration of a disaster.
● Each component/aspect of the plan should have a person and a backup
assigned to its execution.
● Periodic training of personnel and users associated with the EMS should be
conducted defining their roles and responsibilities in the event of a disaster.
● Test plan shall be developed, documented and maintained. Periodic tests shall
be carried out to test the effectiveness of the procedures in the plan.
● The results of the tests shall be documented for management review.
● Disaster recovery plan should be updated regularly to ensure its continuing
effectiveness.

Verification
There shall be a regular audit of all backup media. It is recommended that this
exercise be carried out at least once every three months. A complete set of back-up
media shall be restored, on a temporary location, and then inspected for accurate
data reconstruction.
A report on the outcome of the audit shall be generated and recorded in the back-up
inventory file.

12.4 Technology Transfer

The developer needs to engage with the ministry of health team during the project
period, this is to harness transfer of technology as minor corrections and support will
be done in house. However the developer must note that the ministry of health team
have limited IT knowledge.

12.5 Deployment of the system

The developer is required to come up with a schedule of activities highlighting
11 | P a g e
 milestones and expected deliverables such as; signing of contract, collecting user
requirements, the different phases of system development, deployment and roll
out.
The developer should also support user in terms of stabilization and making the
system acceptable by the end users.

12.6 Training
The developer is required to provide training to the users on the management
and administration of the system. This is to provide an understanding of the
system, its database and infrastructure configurations used during the
implementation of the system.

12.7 Documentation
Content Design Document (high level design, data model), user manuals
(including screenshots) and any other documentation of the assignment have to
be completed and handed over to the user.

12.8 Technical Support

The developer shall render all support activities related to the following up until the
warranty period expires:
● Troubleshooting at both application level and user level,
● Assist focal official/client in operation of the portal,
● Fixation of bugs, incorporation of minor changes, etc.

12.9 Maintenance of Database

Maintenance of the database after completion, roll-out and full utilization by the
chosen supplier for the duration of the project life (till 06.2019) should be quoted
separately from the development. The maintenance amount should be tapered.

12.10 Ownership of Source Code

The developer is required to hand over the final product by 30.06.2019.
The final product(one off/subscription based); all source code, intellectual property,
documentation and all items specific to this product will be under the client’s exclusive
ownership.
12 | P a g e
13. Annexure II

Project life: 01.10.2016 – 30.06.2019

Number of facilities: 45

Users per facility: 2–3

Expected no. of clients to be stored in the database: 10,000 – 20,000

The implementation schedule for the development of the system is as following:

S/N Activity Timeline Deliverables

Assignment kick-off, Commencement SRS Document

1 Initial Date + Week1
Assessment and SRS
Architecture Design and Commencement Proposed prototype
2 Prototype Development Date + Week2

Portal Development and Commencement Completed System

3 Deployment, Testing Date + Week5
Stabilization & UAT Commencement UAT sign-off
4 Date + Week6
User Commencement Training
Trainings/Workshops Date + Week6 Documentations
5
and Manuals
Support and Commencement
6 Maintenance Date + Week 6
Onwards
Assignment Exit Sign-off Commencement
7 Date + Week 12

13 | P a g e