M I N I S T R Y O F H E A LT H

Software Requirements and

Design Specifications
Kenya Electronic Community
Health Information System
(eCHIS)

DIVISION OF COMMUNITY
HEALTH SERVICES
“AFYA YETU, JUKUMU LETU”
@2021 Government of Kenya
This publication is a Ministry of Health document.

Any part of this document may be freely reviewed,

quoted, reproduced, and translated in full or in part,
provided the source is acknowledged. It may not
be sold or used for commercial purposes or profit.
Software Requirements and Design Specifications
for the Kenya National Electronic Community
Health Information System (eCHIS)

Division of Community Health Services.

Ministry of Health Headquarters
P.O. Box 30016-00100
Nairobi, Kenya.
Website: https://www.health.go.ke/

Suggested Citation:
Ministry of Health, Division of Community Health
Services, Republic of Kenya. (2021). Software
Requirements and Design Specifications for the
Kenya National Electronic Health Community
System (eCHIS) Nairobi, Kenya.
Government of Kenya.
Table Of Contents
Foreword iv
Acknowledgment v
List of Abbreviations vi
1. Introduction 1
1.1 Purpose 1
1.2 Scope 1
1.3 Target Audience 1
2. Overall Description 2
2.1 Architecture 2
2.2 User Classes and Characteristics 3
2.2.1 Client 3
2.2.2 Community Health Volunteer (CHV) 4
2.2.3 Community Health Assistant (CHA) 4
2.2.4 Community Health Focal Person (CHFP) 4
2.2.5 Health Records and Information Officer (HRIO) 4
2.2.6 Healthcare Provider 5
2.2.7 Healthcare Manager 5
2.2.8 System Administrator 5
2.3 Functions 5
2.4 Operating Environment 6
2.5 Assumptions and Dependencies 6
3. External Interface Requirements 7
4. System Features 8
4.1 Transactional Features 9
4.1.1 Household Enrolment 9
4.1.2 Service Delivery 13
4.1.3 Commodity Management 17
4.1.4 Client Referral 21
4.1.5 Surveillance 22
4.1.6 Messaging 25
4.2 Reporting Features 26
4.2.1 Case-based Reports 27
4.2.2 Aggregate Reports 28
4.3 System Administration 30
4.3.1 User Management 30

/i
5. Non-functional Requirements 33
Appendix 1: eCHIS Software Design Specification - April 2021
1. Introduction 39
1.1 Background. 39
1.2 Objectives 39
1.3 Context 39
1.4 Constraints 41
1.5 Dependencies 42
1.5.1. Client Registry 42
1.5.2. CHW Registry 42
1.5.3. Interoperability Platform 42
2. eCHIS Enhancements 44
2.1 Client Referral 44
2.2 Commodity Supply Chain 44
3. eCHIS-DHP Interoperability 45
3.1 Introduction 45
3.1.1 Foundational Interoperability 45
3.1.2 Structural Interoperability 45
3.1.3 Semantic Interoperability 45
3.2 Interoperability for Client Referra 46
3.2.1 Community to Health Facility Referral 46
3.2.2 Health Facility to Community Referral 50
3.3 Interoperability for Commodity Supply Chain Management 52
3.3.1 Description 52
3.3.2 Workflow 52
3.3.3 Data structures 54
3.3.4 APIs 55
3.4 Community-Based Surveillance 55
3.4.1 Description 55
3.4.2 Workflow 55
Annexes: eCHIS In-Depth Evaluation Report - March 2021
1. Introduction 58
2. Methodology 59
3. Results and Discussion 61

ii /
4. Limitations
65
5. Recommendations 66
6. Annexes 67
List of Contributors
86

/ iii
Foreword
The Ministry of Health (MOH) is committed to the digitization of health care
across all Kenya Essential Package for Health (KEPH) levels. This includes Level
1 which is realized through frontline Community Health Volunteers (CHVs)
at the household level. The journey of adopting the electronic Community
Health Information System (eCHIS) began with the development of a National
Community Health Digitization Strategy (Phase I). Phase II of the process is
focused on designing, developing, testing and piloting the eCHIS prototype in
selected counties. Towards this end, this Software Requirements Specification
(SRS) document was developed through a consultative process involving the
MOH and its development partners as well as the supporting technical experts.
The SRS serves as a catalogue of the features and functionality expected to be
offered by the eCHIS. It also provides a framework for conducting an in-depth
technical review of existing digital solutions for community health. This will help
the MOH to identify the “shortest path to success” towards the achievement of
digitization for community health.

This SRS covers the overall eCHIS architecture and how it fits within the Health
Information System ecosystem in Kenya. It also identifies and describes the
intended users of the eCHIS along with their unique needs and characteristics.
In addition, this SRS covers specific system functionalities including
household enrolment, service delivery, commodity supply chain management,
community based disease surveillance, client messaging, data reporting and
user management. Lastly, the SRS articulates the expected non-functional
requirements for the eCHIS.

______________________ _____________________
Dr. Salim Hussein Dr. Joseph Sitienei
Head, Department of Primary Ag. Director, Directorate of Health
Health Care Policy, Research Monitoring and Evaluation

iv /
Acknowledgment
The eCHIS Software Requirements and Design Specifications document was
developed through broad stakeholder engagement that included the Ministry
of Health and its partners at both the national and county levels. Consultations
were conducted through virtual and in-person meetings, as well as focused
workshops aimed at maximising the healthy exchange of ideas towards the
technical design of the eCHIS. This participatory process was guided through
the leadership of the Ministry of Health, spearheaded by Dr. Joseph Sitienei,
Dr. Salim Hussein, Dr. Maureen Kimani, and Mr. John Wanyungu. Special thanks
also go to the officers in the Divisions of Community Health Services, Health
Informatics and Information Communication Technology among others for their
invaluable contribution towards this document. Gratitude is also extended to
partner organizations who contributed their financial and technical support
towards the process including Living Goods, Medic Mobile, AMREF, Lwala and
InSupply among others.

______________________
Dr. Maureen Kimani
Head, Division of Community Health

/v
List Of Abbreviations
Abbreviation Meaning

API Application Programming Interface

CBDS Community Based Disease Surveillance

CCHFP County Community Health Focal Person

CHA Community Health Assistant

CHFP Community Health Focal Person

CHRIO County Health Records and Information Officer

CHU Community Health Unit

CHV Community Health Volunteer

CHW Community Health Worker

eCHIS Electronic Community Health Information System

CR Client Registry

EHR Electronic Health Record

DHIS District Health Information System

DHP Digital Health Platform

DHIS2 District Health Information System (Version 2)

HIS Health Information System

HL7 Health Level 7

HRIO Health Records and Information Officer

IHRIS Integrated Human Resource Information System

KEPH Kenya Essential Package for Health

KHIS Kenya Health Information System

KMHFL Kenya Master Health Facility List

LIMS Logistics Information Management System

LMIS Logistics Management Information System

vi /
Abbreviations continued...

Abbreviation Meaning

MCHUL Master Community Health Unit List

MHFL Master Health Facility List

MOH Ministry of Health

NIIMS National Integrated Identity Management System

NOFBI National Optic Fibre Backbone

SCCHFP Sub-County Community Health Focal Person

SCHRIO Sub-County Health Records and Information Officer

SHR Shared Health Record

SRS Software Requirement Specification

/ vii
1. Introduction
1.1 Purpose
This document specifies both the functional and non-functional requirements
for the electronic Community Health Information System (eCHIS). The eCHIS is
a digital health intervention for community health that is expected to improve
the quality of community health services by; increasing efficiency, enhancing
program management and driving evidence-based decision-making through
timely and accurate data. In turn, this will contribute towards reduced morbidity
and mortality, better health outcomes and ultimately a healthier and more
productive population.

1.2 Scope
The eCHIS is envisaged as a digital health information system for the collection,
storage, processing, analysis, integration and security of community health data
in Kenya. It is intended to cover the entire continuum of KEPH Level 1 services.
These include household enrolment, service delivery, client referral, supply
chain management, community-based surveillance, client messaging, and
reporting at the community, sub-national and national levels. It also includes
interoperability with other digital systems used for health and other kinds of
information management in the country such as the National Integrated Identity
Management System (NIIMS), the Digital Health Platform (DHP), Logistics
Information Management System (LIMS), the Master Community Health Unit
List (MCHUL), the District Health Information System (DHIS), among others.

1.3 Target Audience

This specification is intended for the developers and implementers of the
eCHIS. It is meant to serve as the basis for the design, development, testing and
deployment of the eCHIS to ensure that it conforms to the expectations of the
system’s users and stakeholders.

1 / Software Requirements Specification for the Kenya National Electronic

Community Health Information System (eCHIS)
2. Overall Description
2.1 Architecture
The eCHIS is envisioned as a crucial part of the wider goal to digitize health
information in Kenya. At the point of care, the eCHIS will play a complementary
role to the facility based DHP. Besides linkages with the DHP, the eCHIS will also
interoperate with other systems such as the Client Registry (CR), Shared Health
Record (SHR), MCHUL and the DHIS2.

CLIENT REGISTRY

DHP ( )

Fig 1: The proposed eCHIS architecture. See detailed description below.

The eCHIS is depicted in red in the middle of the diagram above. The blue boxes
inside the eCHIS represent the core functionalities provided by the system
which include household enrolment, service delivery, client referral, supply chain
management and community based surveillance. As illustrated, community
health service is concerned with health promotion and preventive healthcare,

Software Requirements Specification for the Kenya National Electronic / 2

Community Health Information System (eCHIS)
as well as case management at the community level. The green boxes within
the eCHIS represent other supportive functionalities that facilitate the effective
delivery of community health service. They include client messaging, CHA-
CHV supervision, linkage to the MOH virtual academy, and data analytics and
reporting.

Clients interact with the eCHIS through CHVs who visit households and collect
information from household members through a mobile application. Household
members can also interact with the eCHIS through messages sent directly to
their phones. CHAs may also interact with households as part of their supervisory
and mentorship activities in the field. On their part, CHFPs, HRIOs and Health
Managers interact with the eCHIS primarily to access reports and analytics
through a web interface.

The boxes above and to the right of the eCHIS represent other applications
that the eCHIS interoperates with through the Interoperability Platform. The
Interoperability Platform is a general purpose health data interoperability engine
that is responsible for facilitating information exchange between various HIS.
The box to the right of the eCHIS represents a link health facility running the
DHP. The DHP provides, among other features, an EMR and a Stock Management
module at the health facility level. The eCHIS interfaces with the DHP to
facilitate upward and downward client referral, as well as commodity supply
chain management for commodities issued to CHAs for onward transmission to
CHVs. At the national level, the eCHIS is expected to have linkages with the CR
for identity resolution, the SHR for de-identified patient-level data aggregation,
MCHUL for Community Health Unit(CHU) management and DHIS2 for aggregate
data reporting.

2.2 User Classes And Characteristics

The delivery and management of community health services involves multiple
actors who play different but complementary roles. The following subsections
describe the characteristics and roles of each of the main user categories of the
eCHIS;

2.2.1 Client
The client is a member of the community and is the primary recipient of
community health services. Community health members fall into one or more
cohorts defined by sex, age group, pregnancy status, health status and so on.
These characteristics should be taken into account when enrolling community
members into specific community health services. Clients are normally organized
into households, with each household having one member as the household
head. Households are organized into small groups referred to as Community
Health Units (CHUs). Some community health services such as immunizations
are provided to individual community members. Other services, such as the
assessment of sanitation facilities, relate to the household as a whole. Besides
receiving direct visits from CHVs, clients can also remotely interact with the
community health system through bi-directional mobile-powered messages
or through referrals to link health facilities. Households may also be visited by
CHAs for supervision and quality assurance.

3 / Software Requirements Specification for the Kenya National Electronic

Community Health Information System (eCHIS)
2.2.2 Community Health Volunteer (CHV)
The CHV is the primary agent of community health service delivery at the
household level. Their main role is to provide community health services,
while also collecting key program data in an efficient and accurate manner.
CHVs are normally members of the communities in which they work, hence,
an intimate familiarity with those communities is assumed. CHVs comprise a
mixture of literate, semi-literate and sometimes even illiterate individuals. This
reality must be considered when designing the eCHIS in order to ensure that
it is user-friendly for such individuals. It is also important to note that CHVs
perform their community health work on a part-time and voluntary basis. Much
of their working time is spent in the field, and sometimes in resource limited
circumstances where electrical power or cellular connectivity may be limited.
CHVs may meet their clients both by appointment or on an ad hoc basis. Each
CHU is covered by a number of CHVs.

2.2.3 Community Health Assistant (CHA)

CHAs are responsible for supervising and overseeing CHVs. Unlike CHVs who are
part-time volunteers, CHAs are full-time salaried government employees charged
with the management of health services at the community level. Although CHAs
are also typically members of the communities where they serve, they oversee a
larger geographical area than CHVs, usually an entire CHU. Like CHVs, CHAs also
occasionally visit clients in their households. However, their visits are typically
supervisory in nature and are aimed at assessing and promoting service quality.
CHAs also mediate between CHVs and link health facilities. In particular, they are
responsible for facilitating commodity supplies to CHVs, as well as verifying and
escalating reports of notifiable diseases or events of public health interest. Their
other tasks include mentoring and training CHVs and also performing routine
data quality checks on the data collected and submitted by CHVs.

2.2.4 Community Health Focal Person (CHFP)

Community Health Focal Persons (CHFPs) serve as the managers of the
community health program at the sub county and county levels. At the county
level, this role is referred to as the County Community Health Focal Person
(CCHFP). At the sub-county level, the role is referred to as the Sub-County
Community Health Focal Person (SCCHFP). SCCHFPs responsibilities include
supervising and facilitating CHAs.

2.2.5 Health Records and Information Officer (HRIO)

Health Records and Information Officers serve as the managers of all paper-
based and electronic records at the sub-county and county levels. At the county
level, this role is referred to as the County Health Records and Information Officer
(CHRIO). At the sub-county level, the role is referred to as the Sub-County Health
Records and Information Officer (SCHRIO). The records managed by the HRIO
include summary reports of activities at health facilities and CHUs within their
jurisdiction.

Software Requirements Specification for the Kenya National Electronic / 4

Community Health Information System (eCHIS)
2.2.6 Healthcare Provider
The healthcare provider user class covers all healthcare providers at the health
facility level. This includes nurses, clinical officers, doctors, laboratory technicians,
radiologists, pharmacists and even physiotherapists and nutritionists. In general,
anyone who attends to clients at a health facility falls under this category.
Healthcare providers primarily interface with community health in terms
of processing upward client referrals (community-to-facility) and initiating
downward client referrals (facility-to-community). Facility to community
referrals are also known as counter referrals. For example, health providers may
refer clients to CHVs for psychosocial support or handover defaulter lists to
CHVs for tracing. They may also receive and attend to clients that are referred
to the health facility from the community.

2.2.7 Healthcare Manager

The healthcare manager user class covers all officers responsible for the
management of healthcare programs at national and subnational levels. Duly
authorized individuals employed by implementing partner organizations that
support the government in delivering healthcare also fall under this category.
Healthcare managers are mainly interested in routine performance and program
monitoring reports to enable them to make evidence-based decisions.

2.2.8 System Administrator

The system administrator user class covers the individuals responsible for
ensuring the smooth operation of the eCHIS at the various levels. This includes
the people responsible for providing technical support at the field, sub-county,
county and national levels. It also includes technology experts responsible for
setting up and operating eCHIS servers and other infrastructure. The permissions
assigned to individual system administrators should correspond to their scope
of work and area of jurisdiction.

2.3 Functions
The eCHIS shall provide the following key functionalities. Details of these
functionalities are covered in Chapter 4: System Features.

Household • Enrolment of household and household member data.

enrolment • Updating of household and household member data.

Service • Digital data collection forms and workflows for

delivery service delivery.
• Digital data collection forms and workflows for super-
vision.
Client referral • Data collection and workflows for referring clients
from the community to health facilities and vice versa.
• Interoperability with DHP to facilitate upward and
downward referral coordination.

5 / Software Requirements Specification for the Kenya National Electronic

Community Health Information System (eCHIS)
Commodity • Commodity ordering, order fulfilment, commodity
supply chain dispensing, adjustments and stock levels monitoring.
management
Surveillance • Reporting suspected cases of notifiable diseases and
events of public health interest.
• Verifying and escalating cases of notifiable diseases
and events of public health interest.
Messaging • Sending unidirectional and bi-directional messages
to clients to create general awareness, encourage
behaviour change or service client queries.
Reporting • Generating case-based and aggregate client, CHV and
CHA reports to drive evidence-based decision making.

System • Configuring the system with organizational hierarchies,

administration users, user roles, commodities etc.
• Providing technical support and keeping the eCHIS
alive and healthy.

2.4 Operating Environment

The eCHIS will be centrally hosted with mobile, web and application programming
interfaces:

Central Server • Centrally hosted cloud server with support for multi-
tenant architecture.
• Multiple logical partitions per county(tenants)
Android Client • Android-based mobile app for use by CHVs and CHAs
to access the eCHIS.
• Mobile app supports offline data collection.
Web Client • Web client for use by CHFPs, HRIOs and Health
Managers to access the eCHIS.
• Accessible via common desktop and mobile web
browsers.

API • Inbound and outbound Application Programming

Interfaces to facilitate interoperability with other
systems

2.5 Assumptions and Dependencies

This specification is based on the following assumptions:

1. CHVs will have a basic level of literacy or have their capacity built to be
able to use simple smartphone features and applications.
2. Third party applications e.g. the DHP that interface with eCHIS, will provide
information through well-defined Application Programming Interfaces.
3. Applications to which the eCHIS will send information will provide well
defined Application Programming Interfaces for receiving it.
4. A common interoperability layer or service bus will be provided for
facilitating the exchange of information between the eCHIS and other
systems.
Software Requirements Specification for the Kenya National Electronic / 6
Community Health Information System (eCHIS)
3. External Interface Requirement

External Interface Requirements

User Interfaces • Android app
• Web app
Hardware Interfaces • Android devices
• Laptop/desktop computers
Software Interfaces • DHP APIs
• DHIS2 APIs
• Client Registry APIs
• SHR APIs
• MCHUL APIs
Network Interfaces • National Optic Fibre Backbone (NOF-
BI)
• Cellular network
• Mobile internet

7 / Software Requirements Specification for the Kenya National Electronic

Community Health Information System (eCHIS)
4. System Features
The sections below describe the major features that shall be provided by the
eCHIS in order to satisfy the needs of the various user classes described before.
The features are classified according to the three main ways in which the system
will be used.

These are;
1. Transactional i.e. using the eCHIS to conduct the day-to-day business of
community service delivery. It mainly involves data entry.
2. Reporting i.e. using the eCHIS to generate and consume information
emanating from the transactional data stored in the system.
3. System administration i.e. using the eCHIS to add and manage
organizational hierarchies, users and user permissions as well as
performing troubleshooting and data quality checks.

Transactional uses of the eCHIS will facilitate interaction between community

health workers, the community and link health facilities. These uses are further
classified according to the six core components of community health provision,
namely;
1. Household enrolment
2. Service delivery
3. Commodity management
4. Client referral
5. Community-based surveillance
6. Client messaging.

Reporting uses of the eCHIS will facilitate the generation of information and
insights from the system to support quality assurance and program monitoring
as well as drive evidence-based decision-making. These uses are classified into
two categories;

1. Case-based reports i.e. reports offered at the lower levels to support

quality assurance activities while safeguarding client privacy and
confidentiality.
2. Aggregate reports i.e. reports offered at higher levels to support program
monitoring and drive evidence-based decision-making.

System administration uses of the eCHIS will provide the means to conduct the
following core activities;
1. Create and maintain organizational hierarchies
2. Create and manage users and their permissions
3. Perform technical troubleshooting
4. Perform routine system updates
5. Run data quality assurance algorithms.

NOTE 1: Both transactional and reporting use cases may involve interactions
between the eCHIS and other systems. For example, a client referral to a link
health facility - which is a transactional use case may necessitate interoperability
with the EHR system used at the facility. Similarly, an aggregate report generated

Software Requirements Specification for the Kenya National Electronic / 8

Community Health Information System (eCHIS)
through the eCHIS - which is a reporting use case may be sent to DHIS2. For
this reason, all interoperability use cases are covered under the relevant sub-
sections rather than in their own dedicated sections.

NOTE 2: The above classification of system features merely provides a more

convenient and logical way of specifying the requirements. Within the system
itself, there is no expectation that features specified under the same category
should be offered as standalone modules. The software implementation may
adopt whichever approach makes the most sense provided it meets the
requirements.

4.1 Transactional Features

4.1.1 Household Enrolment

Summary: The features described under the sub-headings below will support
the enrolment, updating and management of identity and demographic data on
individual households and their members.

4.1.1.1 Enrol Household

Priority High

User CHV

Interface Mobile app

Description: This feature will allow a CHV to enrol new households and household
members. A new household or household member is one that does not exist in
the eCHIS database.

Details: Household enrolment is a two-step process that involves recording

identity and demographic data for both the household itself and for its individual
members.

The following household characteristics shall be entered into the system to

complete the first step of the enrolment process.

Variable Description

County The county under which the household is enrolled (should

be populated automatically by the eCHIS based on the
logged in CHV)
Sub County The sub county under which the household is enrolled
(should be populated automatically by the eCHIS based on
the logged in CHV)
Ward The ward under which the household is enrolled (should be
populated automatically by the eCHIS based on the logged
in CHV)

9 / Software Requirements Specification for the Kenya National Electronic

Community Health Information System (eCHIS)
Location The location under which the household is enrolled (should
be populated automatically by the eCHIS based on the
logged in CHV)
KMCHUL The community unit under which the household is enrolled
(should be populated automatically by the eCHIS based on
the logged in CHV)
Link Facility The health facility to which the household is linked (should
be populated automatically by the eCHIS based on the
logged in CHV)
Name of CHV The CHV conducting the household enrollment (should be
populated automatically by the eCHIS based on the logged
in CHV)
Name of The village under which the household is enrolled (should
Village be entered by the CHV)
Start Date The date when the household was enrolled in the eCHIS
under (should be entered by the CHV)

End Date The date when the household was discontinued in the
eCHIS. (Should be left blank during enrolment)

Household The number assigned to the household during mapping

Number (Should be entered by the CHV)

The following details shall be entered into the system for each household
member to complete the second step of the enrolment process. Internally, the
eCHIS shall link every household member to the household under which they
are enrolled.

Variable Description

Date of Enrolment Date of Enrolment

Individual Code Individual Code

Name of Household Member Name of Household Member

Date of Birth Date of Birth

Sex Sex

Relationship with Household Relationship with Household Head

Head
Orphan Orphan

Birth Certificate Serial Birth Certificate Serial Number

Number

Software Requirements Specification for the Kenya National Electronic / 10

Community Health Information System (eCHIS)
NOTE 1: Ideally the individual code should be a symbol that uniquely identifies an
individual household member across the entire country. Initially, this code may
be assigned automatically by the eCHIS. However, it should eventually be drawn
from a centrally managed identity management system such as the National
Integrated Identity Management System (NIIMS), or another implementation of
a patient registry.

NOTE 2: Should other identity or demographic variables be added later to eCHIS,

care should be taken to only include immutable attributes in the enrolment
process. Immutable attributes are attributes of a household or household
member that are not liable to change on a routine basis. Mutable attributes will
be tracked separately as part of updating household data.

4.1.1.2 Update Household

Priority High

User CHV

Interface Mobile app

Description: This feature will allow a CHV to update mutable demographic

data on households and household members. In order to update this data, the
household must first have been entered into the eCHIS.

Details: Only mutable household data will be subject to routine updating.

Mutable data refers to data that is liable to change. For example, whether or
not a household has a functional latrine, or the pregnancy status of a household
member. Data that is not liable to change i.e. immutable data, must be captured
only once during household enrolment.

The data on each household and household member shall be updated on the
system once every year, with the very first occasion being immediately upon
registration in order to establish a baseline. The system may be configured to
remind the CHV to perform this task at the right time.

The following household characteristics shall be updated in the system once

every year.

Variable Description

Household has functional latrine Household has functional latrine

Household has access to safe Household has access to safe water

water
Household has handwashing Household has handwashing facilities
facilities

11 / Software Requirements Specification for the Kenya National Electronic

Community Health Information System (eCHIS)
Household has refuse disposal Household has refuse disposal facilities
facilities
Number of deaths in the month/ Number of deaths in the month/year
year
Comments Comments

The following details shall be updated in the system for each household member
once every year.

Variable Description

In school In school

Pregnant Pregnant

Mother and child health booklet Mother and child health booklet

MUAC (Red) indicating severe MUAC (Red) indicating severe

malnutrition malnutrition
MUAC (Yellow) indicating moderate MUAC (Yellow) indicating moderate
malnutrition malnutrition

Vitamin A given Vitamin A given

Penta 3 given Penta 3 given

Fully immunized Fully immunized

Measles Rubella at 2 years Measles Rubella at 2 years

Place of delivery Place of delivery

Known disability Known disability

NOTE 1: The system should only offer for data entry the appropriate variables
based on the demographic characteristics of the household member. For
example, some variables may only be relevant to children or women of child
bearing age. These specifications are clearly documented in the MOH 513 paper-
based tool.

4.1.1.3 Void Household

Priority Medium

User CHA

Interface Mobile app

Software Requirements Specification for the Kenya National Electronic / 12

Community Health Information System (eCHIS)
Description: This feature will allow a CHA to void a household which either
physically ceases to exist or voluntarily drops off the program.

Details: The importance of voiding a household in the eCHIS is to relieve the

system and its users of any responsibility to track that household in the future.
This may be necessary if the household physically ceases to exist, or voluntarily
opts out of being tracked through the eCHIS. The exact protocol for designating
a household for voiding will take place outside the eCHIS, but the system should
support the execution of the decision once it has been made.

The following household characteristics shall be updated in the system upon the
voidance of the household.

Variable Description

End Date The date when the household was discontinued (voided)
in the eCHIS.
Reason The reason the household was discontinued (voided) in
the eCHIS.

NOTE 1: Voiding a household should be implemented in such a way that

existing data on the affected household is maintained in the system for future
reference. In other words, voiding cannot be implemented through the deletion
of household data.

4.1.2 Service Delivery

Summary: The features described under the sub-headings below will support
the delivery of various community health services digitally. A service is a group
of related community health activities targeted at households or household
members and delivered as a single package. The list below covers all the
community health services that are currently defined.

1. Pregnancy, delivery and the new-born

2. Early childhood
3. Late childhood
4. Adolescent and youth
5. Adults
6. Elderly persons (over 60 Years)

Each of these services caters to the unique needs of its target population. The
eCHIS should be designed to accommodate not only these six services but also
any other service that may be defined in the future. In order to support this
level of flexibility, services within the eCHIS should cover five critical structural
components, namely;
1. Name i.e. the name of the community health service.
2. Target i.e. the population targeted by the service, defined by its
demographic characteristics.

13 / Software Requirements Specification for the Kenya National Electronic

Community Health Information System (eCHIS)
 3. Data i.e. the series of variables constituting the data gathered every time
the service is provided. These may be grouped in one or more data entry
forms.
4. Workflow i.e. the logical process for gathering the requisite data for the
service, including sequencing and skip logic.
5. Periodicity i.e. the standard frequency of provision for the service e.g.
monthly, quarterly etc. Ad hoc frequency should also be supported.

As variable entities are susceptible to changes, the eCHIS should provide a

flexible mechanism for defining services without committing to specific target
populations, data, workflows or periodicity. The system administrator should
then be able to define these specifics per service as part of an access-controlled
configuration process as described below.

4.1.2.1 Create Services

Priority High

User System Administrator

Interface Web app

Description: This feature will allow the System Administrator to define new
services.

Details: New services shall be defined on the basis of their target population,
data, workflows or periodicity. A new service is one that does not exist in the
eCHIS. Once a service has been created, it may be modified to suit emerging
needs or updated guidelines but it should not be created again.

Component Description

Service ID A unique identifier for the service (automatically generated

and assigned by the eCHIS).
Service name The name of the service.

Service target The population targeted by the service, defined by its

demographic characteristics.
Service data The series of variables constituting the data gathered every
time the service is provided. These may be grouped in one
or more data entry forms.
Service The logical process for gathering the requisite data for the
workflow service, including sequencing and skip logic.

Service The standard frequency of provision for the service e.g.

periodicity monthly, quarterly e.t.c. Ad hoc frequency should also be
supported.

Software Requirements Specification for the Kenya National Electronic / 14

Community Health Information System (eCHIS)
4.1.2.2 Modify Services
Priority High

User System Administrator

Interface Web app

Description: This feature will allow the System Administrator to update existing
services.

Details: Existing services may be modified to respond to emerging needs

or conform to new guidelines. As with creating new services, the process of
updating a service will involve updating its target population, data, workflows
and/or periodicity.

Component Description

Service name The name of the service.

Service target The population targeted by the service, defined by its

demographic characteristics.
Service data The series of variables constituting the data gathered
every time the service is provided. These may be grouped
in one or more data entry forms.
Service The logical process for gathering the requisite data for
workflow the service, including sequencing and skip logic.

Service The standard frequency of provision for the service e.g.

periodicity monthly, quarterly etc. Ad hoc frequency should also be
supported.

NOTE 1: As a service evolves through subsequent modifications, the system

should internally maintain a “service version” as a means of tracking this
evolution. The variables which constitute the data for the service should be
compatible across service versions. For example, data collected against old
variables that are no longer tracked should continue to exist in the eCHIS and
should be available for the periods during which the data was entered.

4.1.2.3 Publish Services

Priority High

User System Administrator

Interface Web app

Description: This feature will allow the System Administrator to publish new or
modified services to CHVs mobile devices for digital service delivery and data
collection.

15 / Software Requirements Specification for the Kenya National Electronic

Community Health Information System (eCHIS)
Details: Whenever new services are created or existing ones are modified, the
associated templates on CHV’s mobile devices shall be updated accordingly to
enable them to deliver services using the latest tools. The System Administrator
shall achieve this by publishing new and modified services to CHVs mobile
devices. Upon publication, CHVs shall receive a notification within the eCHIS
app notifying them of the availability of updated tools. The CHVs will then either
manually update their templates, or the system may do so automatically at the
next available opportunity that does not interrupt the CHVs workflow e.g. once
they visit the application home page.

Upon publication, the following data will be delivered to the CHV’s mobile
devices.

Variable Description

Service version The current version of the service. This is useful for
tracking compliance with the latest versions of data
collection tools.

4.1.2.4 Deliver Services

Priority High

User CHV

Interface Mobile app

Description: This feature will allow a CHV to digitally deliver community health
services while collecting all the requisite data.

Details: Upon the publication of services, CHVs will receive on their mobile
devices the full set of templates constituting the service delivery toolkit as
defined by the System Administrator. These templates will enable the CHVs to
digitally deliver the various services to the specified target populations while
collecting the relevant data according to the workflows and periodicity defined
in the template.

The following data shall be gathered as part of the service delivery process.

Data Description

As defined in the service Whatever set of variables defined as the

template by the System service data by the System Administrator.
Administrator May be grouped into one or more data entry
forms.

Software Requirements Specification for the Kenya National Electronic / 16

Community Health Information System (eCHIS)
4.1.2.5 Create Supervision Checklists
Priority Medium

User System Administrator

Interface Web app

Description: This feature will allow a System Administrator to create quantitative

ad hoc surveys for CHVs to administer at the community level.

Details: Upon the publication of services, CHVs will receive on their mobile
devices the full set of templates constituting the service delivery toolkit as
defined by the System Administrator. These templates will enable the CHVs to
digitally deliver the various services to the specified target populations while
collecting the relevant data according to the workflows and periodicity defined
in the template.

The following data shall be gathered as part of the service delivery process.

Variable Description

As defined in the Whatever set of variables defined as the service

service template by the data by the System Administrator. May be grouped
System Administrator into one or more data entry forms.

4.1.2.6 Modify Supervision Checklists

This is a high priority feature and will be provided to the CHV through a mobile
interface. It will allow the CHV to collect service data.

4.1.2.7 Publish Supervision Checklists

This is a high priority feature and will be provided to the CHV through a mobile
interface. It will allow the CHV to collect service data.

4.1.2.8 Conduct Field Supervision and Mentorship

This is a high priority feature and will be provided to the CHA through a mobile
interface. It will allow the CHA to collect service quality data.

4.1.2.9 Link to Content E.g. Manuals

This is a high priority feature and will be provided to the CHV through a mobile
interface. It will allow the CHV to collect service data.

4.1.3 Commodity Management

Summary: The features described under the sub-headings below will support
the ordering, receipt, issuance and disposal of commodities by the CHV. It will
also provide a basic level of inventory management for CHVs.

17 / Software Requirements Specification for the Kenya National Electronic

Community Health Information System (eCHIS)
4.1.3.1 Monitor Stock Levels
Priority Medium

User CHV

Interface Mobile app

Description: This feature will allow the CHV to monitor the amount of
commodities in their possession (stock on hand) based on the items previously
received and issued or otherwise disposed of.

Details: Each commodity in the eCHIS will be configured with a reorder level.
The reorder level may be static i.e. always the same regardless of historical
consumption data, or dynamic i.e. automatically adjusted to reflect historical
consumption data. On the basis of this reorder level, the system will notify the
eCHIS whenever the stock levels for a particular commodity or set of commodities
goes below the specified reorder level.

The following specific data will be shown to the CHV as part of the stock level
monitoring feedback.

Variable Description

Commodity The commodity whose stock is below the reorder level

Reorder level The quantity of the commodity that the CHV ought to
have before it’s time to reorder.

Stock on hand The quantity of the commodity that the CHV has on hand.

4.1.3.2 Make Commodity Order

Priority Medium

User CHV

Interface Mobile app

Description: This feature will allow the CHV to make commodity orders.

Details: At any point in time and provided that there are one or more commodities
that are below the stipulated reorder level, the CHV may raise an order for
resupply.

Software Requirements Specification for the Kenya National Electronic / 18

Community Health Information System (eCHIS)
The resupply order will contain the following information.
Variable Description

Commodity The commodity being reordered.

Stock at hand The quantity of the commodity that the CHV has on
hand.
Reorder quantity The quantity of the commodity that the CHV is
ordering.

NOTE 1: The commodity order raised by the CHV via the eCHIS mobile app shall
be forwarded through the interoperability platform to the Pharmacy Information
Management System (PIMS) at the link health facility for fulfilment.

4.1.3.3 Receive Commodities

Priority Medium

User CHV

Interface Mobile app

Description: This feature will allow the CHV to receive commodity orders from
the link health facility.

Details: On designated commodity resupply days, a CHV shall visit the link
health facility to collect the commodities that they ordered. During this visit, the
PIMS operator at the facility shall process the CHV’s order by restocking their
commodities. The PIMS shall then update the eCHIS accordingly by sending the
appropriate data through the interoperability layer.

The specific information sent to the eCHIS upon resupply shall be as follows.

Data Description

Order No An identifier for the order that originated from the CHV.
This includes a reference to the CHV user account for
accountability.
Commodities A set of all commodities resupplied and the quantities
resupplied.
Comment Any comments associated with partial order fulfilment or
any other remarks.

4.1.3.4 Issue Commodities

Priority Medium

User CHV

Interface Mobile app

19 / Software Requirements Specification for the Kenya National Electronic

Community Health Information System (eCHIS)
Description: This feature will allow a CHV to issue commodities at the household
level.

Details: A CHV may issue commodities at the household level in one of the
following two ways;
1. Under the guidance of a decision support algorithm within the eCHIS.
2. On an ad hoc basis according to their training, experience and
judgement.

Decision support for commodity issuance shall be defined as part of the workflow
of a service as described under the “Create a service” feature. It shall include
the commodity or commodities to be issued as well as the associated quantities
and dosages. CHVs shall also be able to issue designated commodities on an ad
hoc basis.

During each commodity issuance, the CHV will record the following data
.
Variable Description

Household The individual household member to whom the

member commodity or commodities are issued.
The set of all commodities issued to the individual,
Commodities
including their quantities.

4.1.3.5 Dispose Commodities

Priority Medium

User CHV

Interface Mobile app

Description: This feature will allow a CHV to otherwise dispose of commodities

from within the system by means other than issuance to clients.

Details: Ideally, the only means by which a CHV may dispose of commodities from
within the eCHIS is by issuing them to clients. In reality, however, commodities
may be disposed of for other reasons such as expiry or wastage. The eCHIS shall
allow the CHV to record the commodities and their quantities that are disposed
of in these alternative means. This will allow the eCHIS to accurately track stock
levels based on usable stock on hand.

Software Requirements Specification for the Kenya National Electronic / 20

Community Health Information System (eCHIS)
Commodity disposal shall involve the recording of the following data.

Variable Description

Commodity The commodity that is disposed of by any means other than

issuance to clients.
Quantity The quantity of the commodity that is disposed of.

Reason The reason for the disposal.

Comment Any extra information on the reason for the disposal for quali-
ty assurance purposes.

4.1.4 Client Referral

The eCHIS will provide the following features to support requisitioning, order
fulfilment and CHV-level inventory management.

Summary: The features described under the sub-headings below will support
the client referral mechanism for linking clients to health facilities. Clients may
be referred to health facilities under two distinct circumstances:
1. The client located by the CHV as part of a tracing exercise instigated by
the health facility e.g. because they have defaulted on their appointment.
2. The CHV finds a patient whose condition by nature necessitates medical
attention at a health facility.

4.1.4.1 Receive Defaulter Lists from Health Facilities

Priority High

User HCW, CHV, CHA, Health Manager

Interface Mobile app

Description: The feature will allow the healthcare workers to send a list of the
names of registered clients who have defaulted on treatment/services.

Details: The facility will have a client database with each client mapped to their
respective CHUs and CHVs. If there is a case of defaulter, the HCW sends out a
notification to the CHV/CHU through the CHA. The CHV then begins the process
of tracing the defaulter.

4.1.4.2 Refer Client to Health Facility

Priority High

User HCW, CHV, CHA

Interface Mobile app

21 / Software Requirements Specification for the Kenya National Electronic

Community Health Information System (eCHIS)
Description: The feature will allow the CHV to refer clients to the health facility
and push a notification to the HCW who should then be expecting the referred
client.

Details: The CHV will identify the candidate for referral through the defaulter
list received from the facility or conduct household client assessment to identify
reason for referral. The CHV then fills the referral form and submits. Upon
submitting, the HCW receives a notification of referral from the community. The
same notification also goes to the CHA. The CHV then sends the client to the
link facility and follows up once they have received services.

4.1.4.3 Notify Successful Client Referral

Priority High

User HCW, CHV, CHA

Interface Mobile app

Description: The feature will allow the HCW to send notifications to the CHV/
CHU after offering services to the referred client.

Details: Upon receiving the referred client, the HCW offers the required service
and fills the referral notification/task. Once the task is completed, a notification
is sent to the CHU/CHV alerting them that the client has successfully received
the services referred for.

4.1.4.4 Refer Client to the Community

Priority High

User HCW, CHV, CHA

Interface Mobile app

Description: The feature will allow the HCW to refer the client back to the
community and send notifications to the CHV/CHU after offering services to the
referred client.

Details: The HCW allows the client to go back and continue getting care at home.
The HCW sends a notification to the CHV/CHU with details on the instructions
for home care and the return dates if any.

4.1.5 Surveillance
The features described under the sub-headings below will help leverage digital
solutions to strengthen surveillance of events, diseases and conditions at the
community level.

Software Requirements Specification for the Kenya National Electronic / 22

Community Health Information System (eCHIS)
4.1.5.1 Detect Events
Priority High

User CHV

Interface Mobile app

Description: This feature will allow the CHV report details of events or diseases
in the community.

Details: The surveillance system will have pre-defined signals/alerts for use in
Community Event Based Surveillance (CEBS) and lay case definitions for use in
Community Based Disease Surveillance (CBDS). The CHVs undertake detection
by making observations during household visits or while going through their
day to day activities in the community. The community networks can also detect
events and diseases after sensitization on signals/alerts and lay case definitions
after which they report to the CHVs.

The event detection will contain the following information.

Variable Description

Type The event or disease detected

Person Social and demographic characteristics

Place Place of event/disease

Time Date and time stamps

4.1.5.2 Notify Events

Priority High

User CHV

Interface Mobile app

Description: This feature will allow the CHV to notify on any event or disease
and report to the next level in real-time.

Details: This will allow the CHV to make a report at any time on any event or
disease in the community.

23 / Software Requirements Specification for the Kenya National Electronic

Community Health Information System (eCHIS)
The notification form will contain the following information.

Variable Description

Type The event or disease detected

Location The geographical location the event/disease was

detected.
Date and Time Time characteristics of the event/disease

Population affected Estimate on the number of people affected in the

community

4.1.5.3 Investigate Events

Priority High

User CHV/Healthcare Provider

Interface Mobile app

Description: This feature will allow the CHV/Healthcare Provider to carry out an
investigation on the reported event.

Details: The CHV or a designated HCW will use the event notification data to
undertake an in depth investigation to establish more details on the report.

The investigation report will contain the following information.

Variable Description

Event/Disease The event/disease notified

Location The geographical location the event/disease was

detected.
Date and Time Time characteristics of the event/disease

Finding The result of the investigation

Recommendation What should be done to address the reported issue

and Action based on the findings

4.1.5.4 Citizen-based Reporting

Priority High

User Members of the public(Citizen)

Interface Mobile app

Software Requirements Specification for the Kenya National Electronic / 24

Community Health Information System (eCHIS)
Description: This feature will allow the citizens to report on events.

Details: Citizens will be able to make a report of any event identified in the
community. The citizen reporting data reporting form will contain the following
information;

Variable Description

Event The event identified or suspected by the citizen

Person Social and demographic characteristics

Place Place of event/disease

Time Date and time stamps

4.1.6 Messaging
The eCHIS application will have features to support one-way and two-way
targeted and non-targeted messaging between clients and system users in an
intuitive and simple way.

Priority High

User System users and clients

Interface Mobile and web app

4.1.6.1 One-way messaging

Summary
The eCHIS system will support sending of unidirectional messages to clients,
healthcare providers and healthcare managers. The recipients are not expected
to respond or reply.

Description
• The system will provide an interface for grouping of users to whom
messages will be sent.
• The system will provide an interface to define SMS messages/ SMS
campaigns with the following parameters

Variable Description

Message SMS message to be sent (160 characters). May be structured

or unstructured
Target The individuals/groups/cohorts that will receive the messages

Schedule The timing for sending of messages

Frequency The number of times messages need to be sent to the target

groups. Can either be one time or repetitive.

25 / Software Requirements Specification for the Kenya National Electronic

Community Health Information System (eCHIS)
 • The system will provide an interface to design SMS sequences.
• The system will have a provision to define messages to be sent based on
system events and configured rules. For example, based on escalation
matrices, system user identity verification, etc.

4.1.6.1.1 Targeted messaging

This feature will support one-way SMS messaging from an interface provided
within the eCHIS application targeted to specific system users and clients on
specific thematic areas based on defined criteria. For example, messages can be
sent to specific CHVS on healthcare policies, guidelines, alerts, etc.

4.1.6.1.2 Non-targeted messaging

The system will support general broadcast messages to groups of people

4.1.6.2.1 Two-way messaging

Summary

The system will be able to support interaction between users and clients. In
addition to the ability to send messages, the system will be able to respond
to structured messages from clients and system users based on predefined
workflows. The system should also support unstructured messages from clients
and have a provision for system users to respond to these messages. Refer to
the table above on the variable and description.

Description
The eCHIS system will have an interface to visually define SMS workflows that
have;
• Conditional logic and repeat logic
• Interpretation of vague messages to the highest degree possible

Targeted messaging
This feature will support two-way SMS messaging from an interface provided
within the eCHIS application targeted to specific system users and clients on
specific thematic areas based on defined criteria. This may include surveys,
client follow ups, appointment reminders etc.

4.2 Reporting Features

Summary: The features described under the sub-headings below will allow
designated users to securely access the eCHIS to analyse data and generate
reports to facilitate evidence-based decision making. The reporting in the
eCHIS will be aligned to the Monitoring and Evaluation Framework and eHealth
strategy. The report will be standardised to respond to the Kenya Health Sector
strategic plan(KHSSP), and the Health Sector Indicator manual, and will follow
the reporting timelines as described in the HIS policy and M&E framework. Users
will be able to access standard reports as well as create customized or ad hoc
reports to meet their specific needs. The eCHIS will allow users who create
custom or ad hoc reports to organize them into dashboards and save them for
future access without the need for recreation.

Software Requirements Specification for the Kenya National Electronic / 26

Community Health Information System (eCHIS)
4.2.1 Case-based Reports
Case- based reports will be reports on events, episodes or household visits
generated at person/people level. These reports should support search for
individual, people, or client encounters as well as upcoming activities by the
community health worker at the household level. They should allow the user
to view the profile, validate the captured information and produce information
products. A line list of activities should be able to be populated at individual/
person level in the household, which will include the following community unit
service received/offered; date of an event, age of the client, sex of the client,
service offered/received, service provider, rescheduling and appointments.

4.2.1.1 Client Lists

Priority High

User Health managers, HRIOs, CHFPs,

Interface Web app

Description: This feature will allow designated users to generate lists of clients
based on client characteristics for a defined time period. Additionally, client lists
may be filtered by organizational hierarchy.

Details: The client characteristics used to generate client lists include any of the
attributes collected during household enrolment, service delivery, client referral,
messaging and any other area of functionality where client-level data is collected.
Client characteristics can also be “calculated” from other characteristics. For
example, the system might store the attribute “Date of Birth” from which the
client characteristic “Age” may be calculated.

Example 1: A client list might be defined as “All clients who were tested for TB
in January 2020”. In this case, the characteristic is “TB Test Status” and the
defined time period is January 2020.

Client lists may further be filtered by organizational hierarchy.

Example 2: A client list might be defined as “All clients who were tested for
TB in January 2020 in Mombasa County”. In this case, the characteristic is “TB
Test Status”, the defined time period is January 2020 and the hierarchy filter is
“County- Mombasa County”.

NOTE 1:

4.2.1.2 CHV/CHA Lists

Priority High
User Health Managers, CHFP,HRIO, CHA,CHVs,

Interface Web app

27 / Software Requirements Specification for the Kenya National Electronic

Community Health Information System (eCHIS)
Description: This feature will allow designated users to generate lists of users
based on CHVs characteristics for a defined period of time.

Details: CHV characteristics used to generate the CHV list will include attributes
like the user name, the number of CHVs/CHAs in the area, the number of
households, the number of household members, the number of pregnant
mothers visited, ANC visits, skilled deliveries and the fully immunized. These
attributes should be collected during household visits.

4.2.2 Aggregate Reports

Aggregate reports will comprise aggregation of events by organization units
(community units, wards, sub county, county and national levels), Period
(daily, weekly, monthly, quarterly, bi -annually and annually), sex, age and
services provided (data elements, events). The reports should be in line with
the harmonised and standardised reporting protocols according to HIS policy
and Health Act, 2017. The aggregate reports will be customised to reflect the
standards of reporting which will include standard tools and formats of reporting
in the routine reporting.

4.2.2.1 Client Summaries

Priority High

User Health managers, HRIOs, CHFPs,

Interface Web app

Description: This feature will allow designated users to create service statistics
reports based on client characteristics for a defined time period. Additionally,
client statistics may be disaggregated by organizational hierarchy.

Details: The client characteristics used to generate client lists include any of the
attributes collected during household enrolment, service delivery, client referral,
messaging and any other area of functionality where client-level data is collected.
Client characteristics can also be “calculated” from other characteristics. For
example, the system might store the attribute “Date of Birth” from which the
client characteristic “Age” may be calculated.

Example 1: A client summary might be defined as “The total number of clients

who were tested for TB in January 2020”. In this case, the characteristic is “TB
Test Status”, the aggregation is “Count” i.e. “Total Number of Clients Tested for
TB” and the defined time period is January 2020.

Client summaries may further be disaggregated by other client characteristics

and/or organizational hierarchy.

Example 2: A client summary might be defined as “The total number of Male

clients who were tested for TB in January 2020 in Mombasa County”. In this case,
the characteristic is “TB Test Status”, the statistic is “Count” i.e. “Total Number

Software Requirements Specification for the Kenya National Electronic / 28

Community Health Information System (eCHIS)
of Clients Tested for TB”, the defined time period is “January 2020”, the client
characteristic disaggregation is “Sex =Male”, and the hierarchy disaggregation
is “County = Mombasa Country”.

NOTE 1: The eCHIS will support the ability to assemble individual client
summaries into a list of summaries. Such list of summaries will form a service
statistic report. Service statistic reports can be saved on the system for future
access or can be downloaded for archiving and sharing.

4.2.2.2 CHV/CHA Summaries

Priority High

User Health Managers, HRIOs, CHFPs,

Interface Web app

Description: This feature will allow designated users to create service statistics
reports based on CHV characteristics for a defined time period. Additionally,
CHV statistics may be disaggregated by organizational hierarchy.

Details: The CHV characteristics used to generate client lists include any of the
attributes collected when registering CHVs on the eCHIS. CHV characteristics
can also be “calculated” based on data entered by a CHV. For example, the
system might calculate the “Total number of households visited” or “The total
number of family planning commodities issued” for a particular CHV.

Example 1: A CHV summary might be defined as “The total number of households

visited in January 2020”. In this case, the characteristic is “Number of households
visited”, the aggregation is “Sum” i.e. “Total number of households visited” and
the defined time period is “January 2020”.

CHV summaries may further be disaggregated by other CHV characteristics

and/or organizational hierarchy.

Example 1: A CHV summary might be defined as “The total number of households

visited by AMREF Funded CHVs in January 2020 in Mombasa County”. In this
case, the characteristic is “Number of households visited”, the aggregation is
“Sum” i.e. “Total number of households visited” and the defined time period is
“January 2020”.

Example 2: A client summary might be defined as “The total number of Male

clients who were tested for TB in January 2020 in Mombasa County”. In this case,
the characteristic is “TB Test Status”, the statistic is “Count” i.e. “Total Number
of Clients Tested for TB”, the defined time period is “January 2020”, the client
characteristic disaggregation is “Sex =Male”, and the hierarchy disaggregation
is “County = Mombasa County”.

29 / Software Requirements Specification for the Kenya National Electronic

Community Health Information System (eCHIS)
4.3 System Administration

4.3.1 User Management

User roles management
Users shall be grouped based on the roles they have in the health services
provision. User roles and permissions shall be configured by the system
administrators.

User role functions should include the permissions such as add new user, modify
user details, view users and remove a user. The specific roles can be defined per
modules, sub-module and module function.

Group roles and permissions will be set as per the departments and departmental
roles within a facility.

User accounts Creation process

User creation will be done through the system administrator.

New user account process: Community health units’ staff that require to use
the system shall fill a user account request form which shall be approved by
their supervisor and forwarded to the head of department for approval. Upon
approval by the HOD, the form shall be forwarded to the system administrator
who shall create the user and send them an email notification with instruction
on how to access the system.

For the CHVs, upon filling the user account creation form, the CHA will access
the form and either approve it or reject it. Upon approval, the form will be sent
to the system administrator who will create the user account and configure the
hand held device to use the created user account credentials.

Update user rights process: The system users that are redeployed to new
duty stations shall fill in a user account update form that shall be approved by
their supervisor and forwarded to the head of department for approval. Upon
approval by the HOD, the form shall be forwarded to the system administrator
who shall update the user and send them an email notification with instruction
on how to access the system.

Deactivate a user: the HOD shall notify the system administrator for account
deactivation of the staff in her department that no longer require access to the
system or have left the department or organization. The system administrator
shall upon receiving the deactivate user request, deactivate the user.

Software Requirements Specification for the Kenya National Electronic / 30

Community Health Information System (eCHIS)
 New User Account Request Form
User Bio-data

Name of the staff (first name, last name) _______________________________

Personal number/staff number ________________________________________

Phone number_____________________________________________________

Email address______________________________________________________

Department_______________________________________________________

Roles in the department_____________________________________________

Signature_________________________________________________________

Date_____________________________________________________________

Tick appropriately

______New user _______User account update _____Deactivate user account

31 / Software Requirements Specification for the Kenya National Electronic

Community Health Information System (eCHIS)
Supervisor’s Section

User role to be assigned;

System Roles Tick appropriately

Registration clerk
Registration supervisor
Registration manager
Laboratory technician
Medical doctor
Nurse

Comment ________________________________________________________

Name of the supervisor _____________________________________________

Signature_________________________________________________________

Date_____________________________________________________________

Head of Department

Approved _________Yes ________No

Comment ________________________________________________________

Name of the HOD __________________________________________________

Signature ________________________________________________________

Date ______________________________________________ ______________

System Administrator

User account created _________Yes ________No

Signature ________________________________________________________

Date ____________________________________________________________

Software Requirements Specification for the Kenya National Electronic / 32

Community Health Information System (eCHIS)
5. Non-Functional Requirements
Non-functional requirements refer to the requirements that specify criteria that
can be used to judge the operation of a system, rather than specific behaviours
(functional requirements). Non-functional requirements ensure the optimal
usability and effectiveness of the system as a whole. The table below covers the
eCHIS non-functional requirements.

Attribute Definition and Approach

Security Definition:
The assurance that the data stored within a system and
transmitted from the system has the necessary security
measures in place to prevent unauthorized access.

Approach:
1. Define the mechanism in the system to deter
potential threats occurrence. For example;
malware, unauthorized users, network
compromises
2. Define the user management including
authorities’ definition, users grouping
functionality, user adding, deactivation and
removal functionalities. The user management
should cover the application and database
access as necessary
3. Implementation of best practices on
system security policies by expanding the
non-functional requirement to functional
requirement. For example; password
requirement, login requirement, inactivity
timeouts, audit log trails
4. Adopt internationally accredited system
security standards and protocols for the
application, network and data transmission

33 / Software Requirements Specification for the Kenya National Electronic

Community Health Information System (eCHIS)
Data Integrity Definition:
This focuses on the validity, consistency and accuracy of
data that is stored within the system.

Approach:
1. Identify the common threats that would
compromise on data quality and define
mitigations implemented in the system. For
example; human error, compromised hardware,
misconfiguration, security errors, errors in data
transfer, cyber-attacks.
2. Define the data integrity preservation checklist
applicable for use in the system’s audit. For
example; input validation, eliminate data
duplications, data audit trailing, data backup,
access controls.
3. Define the database management and security
measures to prevent database attacks. For
example; data store encryption function to
deter database injection attacks.
4. Develop the database maintenance policies
to address data duplicity, database translation
audit trails and data encryption modes and
management.
Interoperability Definition:
The ability of systems to exchange in an automated
methodology.

Approach:
1. The system should adhere to the Kenya Health
Information Systems Interoperability Standards
and Guidelines
2. The system should have APIs that are secure
and have data integrity management policies
3. Define the interoperability standards required
by the system. For example;
a) Information interoperability - seamless or
on-demand, data formatting.
b) Hardware interoperability - system
device-readiness, hardware generational
compatibility
c) Technical interoperability - environmental
definition. Development versus Production.
d) Business interoperability - definition of
the use cases that share processes and
information.

Software Requirements Specification for the Kenya National Electronic / 34

Community Health Information System (eCHIS)
Portability & Definition:
Compatibility This describes how elements from one platform can be
easily accessed and interacted with from a different envi-
ronment.

Approach:
Define the system’s compatibility requirements that
should be met by other applications, software, hardware
and networking aspects.

For example, this system should support the following

mobile operating systems; Android and iOS devices
Performance & Definition:
Scalability
The ability of the system to accommodate a large
number of users and extension of functionality without
affecting its access or use.

Approach:

1. Define the specific measurement scenarios of

the system’s throughput. For example, latency
and content type.
2. Specify the workload for measurement. For
example, the number of users accessing the
system at certain times in a day
3. Assess response time against a defined
threshold. For example, instantaneous
response time = x, delayed response time = y.
4. Test the current maximum load that the system
can handle and prepare to increase it in the
near future. For example, stress testing
5. Define a test for the system’s modules
extension and their regression effects on other
components of the system.

35 / Software Requirements Specification for the Kenya National Electronic

Community Health Information System (eCHIS)
Reliability Definition:
The ability of a system to run without expressing a failure
for any given period of time under a set of predefined
conditions.

Approach:
1. Define the normal usage conditions and upti-
mes in probability percentage. For example,
the system guarantees x% reliability implying
that under the normal conditions, the system
guarantees x% probability that it will not expe-
rience failures.
2. Define the acceptable mean uptimes between
failures
3. Define the mean time to recovery.
Maintainability Definition:
This is a measure of time taken for a system mainte-
nance, upgrade or performance optimization.

Approach:
1. Define the maintenance time frame in
probability percentage. For example, x%
maintainability in y time implies that there
is a x% probability that the system can be
maintained within y time
2. Define the acceptable mean times between
failures
3. Define the system roll backs functionality and
timelines
4. Define the system’s support mechanisms that
are inbuilt or require external interventions

Availability Definition:
The likelihood that the system will be accessible for the
users at any given point in time.

Approach:
1. Define system availability timelines estimates
during testing and production
2. Define the system recovery and business conti-
nuity measure. For example, define the redun-
dancy modes of system hosting and database
synchronization models.

Software Requirements Specification for the Kenya National Electronic / 36

Community Health Information System (eCHIS)
Usability Definition:
The ease in which the users are able to utilize the system
with minimal difficulty and having the need addressed by
the system achieved.

Approach:
1. Run a prototype usability test with the
targeted audience
2. Reference the prior system that was in use as a
benchmark
3. Conduct a comprehensive user requirements
gathering and field study where necessary
to understand the context and ensure that
the system matches up to the user needs.
For example; laws, regulations, culture, date
formatting.

37 / Software Requirements Specification for the Kenya National Electronic

Community Health Information System (eCHIS)
APPENDIX 1:
eCHIS SOFTWARE DESIGN SPECIFICATION
April 2021

Software Requirements Specification for the Kenya National Electronic / 38

Community Health Information System (eCHIS)
1. Introduction
1.1 Background
The Ministry of Health (MOH) is committed to the digitization of healthcare
services across the Kenya Essential Package for Health (KEPH) levels. This
includes Level 1 which is realized through frontline community health volunteers
(CHVs) at the household level. The journey of adopting the electronic Community
Health Information System (eCHIS) began with the development of a National
Community Health Digitization Strategy (Phase I). Phase II of the process is
focused on designing, developing, testing and piloting the eCHIS prototype
in selected counties. To support this process, a Software Requirements
Specification (SRS) document was prepared through a consultative process
involving the MOH and its development partners. The SRS serves as a catalogue
of the features and functionality expected to be offered by the eCHIS. In addition
to developing the SRS, the ministry also reviewed existing digital interventions
for community health with a view to characterizing and understanding their
level of comprehensiveness, maturity and conformance with the requirements
specified in the SRS.

By evaluating existing community health digital interventions against the SRS,

the MOH identified critical feature gaps that need to be addressed before
the eCHIS can be piloted ahead of nationwide scale-up. Enhancing existing
digital solutions to meet the requirements of the community health division
rather than developing a new information system from scratch represents the
“shortest path to success” for the implementation of the National Community
Health Digitization Strategy. This document proceeds from the SRS and the in-
depth eCHIS evaluation (see annexure) to describe in detail the design of the
components to be enhanced and developed to achieve a pilot-ready eCHIS.

1.2 Objectives
This software design specification aims to achieve the following objectives:
1. To describe the design of system components that will be enhanced
before the eCHIS prototype is piloted.
2. To describe the interoperability approach for enabling the eCHIS and the
Digital Health Platform(DHP) to exchange data in order to facilitate client
referral coordination, supply chain management and other areas.
3. To identify the other systems required to support seamless interoperability
between the eCHIS and the DHP.

1.3 Context
The eCHIS represents one component in a comprehensive suite of Health
Information Systems (HIS) designed to promote optimal healthcare service
delivery using digital technology. Other applications in the suite include the
DHP, which digitizes patient management at the health facility; the Client
Registry (CR), which will provide identity resolution services to other systems;
the Shared Health Record (SHR), which will aggregate de-identified client-level

39 / Software Requirements Specification for the Kenya National Electronic

Community Health Information System (eCHIS)
data; the Kenya Master Health Facility List (KMHFL), which serves as registries
for community units; and the Kenya Health Information System(KHIS), which is
used for routine service statistics reporting at the county and national levels.
Also included in the list of HIS used by the MOH are the Integrated Human
Resource Information System (IHRS), which serves as a registry of healthcare
workers; and the Logistics Management Information System (LMIS), which is
used to manage the supply chain of medical supplies.

Unlike the other applications which are deployed at the health facility or higher
levels, the eCHIS is unique in that it is deployed at the community level to
facilitate the delivery of KEPH Level 1 services. It is envisaged that the eCHIS
will also be interoperable with other applications in order to facilitate healthcare
delivery and health records management for all clients regardless of their point
of contact with the healthcare system. For example, the eCHIS is expected
to support interoperability with the DHP to facilitate community-to-facility
and facility-to-community client referral as well as commodity supply chain
management for health commodities used at the community level. Similarly,
the eCHIS is also expected to interoperate with KHIS in order to support routine
aggregate community health service statistics for national and subnational
reporting. The high-level architecture diagram below shows the various HIS
used or envisaged for future deployment by the MOH, as well as their expected
relationship and interactions with the eCHIS.

Software Requirements Specification for the Kenya National Electronic / 40

Community Health Information System (eCHIS)
 CLIENT REGISTRY

DHP ( )

A high-level architecture diagram of the eCHIS showing its planned interactions withother HIS.

1.4 Constraints
The design of the eCHIS components described in this document is subject to
the following constraints:
1. Mobile access: All functionality intended for Community Health Volunteers
(CHVs) and Community Health Assistants (CHAs) must be accessible via
handheld Android devices.
2. Offline use: CHVs and CHAs must be able to use the eCHIS offline and
then synchronize data with the server when internet connectivity becomes
available.
3. Identity resolution: The eCHIS must be able to resolve client identities
against a Client Registry in order to ensure consistent client identification
with DHP and other systems.

41 / Software Requirements Specification for the Kenya National Electronic

Community Health Information System (eCHIS)
 4. Structural interoperability: The interoperability between eCHIS and other
HIS must achieve at least structural interoperability or higher.

1.5 Dependencies
The successful implementation of a fully interoperable and production-ready
eCHIS is dependent on the following external components. These components
are necessary to achieve structural interoperability. In order to achieve semantic
interoperability, a terminology service is also required. However, the pilot phase
of the eCHIS aims for structural interoperability. Semantic interoperability will
be incorporated in future versions of the application.

1.5.1. Client Registry

In order for the eCHIS to exchange data with the DHP, it is critical for clients to
be consistently and unambiguously identified across both systems. Failure to do
so has serious clinical and operational implications. For example, a misidentified
client can be treated based on another client’s condition or be billed for services
offered to someone else. To achieve consistent and reliable client identification,
both the eCHIS and DHP architectures envisage a third-party service known as
the client registry.

The client registry shall serve as an accurate and up-to-date electronic database
containing the demographic information on every client who receives healthcare
services in Kenya. It shall also offer the capability to service client resolution
queries from duly authenticated third-party applications such as the eCHIS
and the DHP, according to well-defined communication protocols. The CR
shall provide functionality to query for client identity, enrol new clients, update
existing clients, merge duplicate clients and archive deceased clients.

1.5.2. CHW Registry

In addition to uniquely identifying clients, proper identification of Community
Health Workers (CHWs) including CHVs and CHAs across all levels is important
to ensure a seamless implementation of interoperability between the eCHIS and
DHP. The proposed CHW registry, therefore, will serve as an accurate and up-to-
date record of every CHW. The registry will include information about each CHW
by cadre, CHU, and other details necessary to promote optimal coordination
and human resource management.

It will also include functionality to add new CHWs, update data on existing ones,
and remove those who transition out of community health service. The registry
shall be accessible directly, as well as through both the eCHIS and the DHP to
facilitate consistent CHW identification during referral coordination and other
workflows.

1.5.3. Interoperability Platform

The DHP and eCHIS architectures also anticipate the implementation of a general-
purpose interoperability platform. The role of the interoperability platform is to
serve as an enterprise service bus responsible for routing messages between
various endpoints. In addition, the interoperability platform will handle network

Software Requirements Specification for the Kenya National Electronic / 42

Community Health Information System (eCHIS)
optimization and failure recovery mechanisms such as message queuing and
retries, as well as message routing that is agnostic to physical network addresses.
The goal of the interoperability platform is to achieve loose coupling between
communicating systems, while at the same time defining a simple, high-level
communication protocol for applications. In the absence of the interoperability
platform, direct point-to-point communication between the eCHIS, DHP and
other systems will be used.

43 / Software Requirements Specification for the Kenya National Electronic

Community Health Information System (eCHIS)
2. eCHIS Enhancements
The following key enhancements arise from the SRS and the eCHIS in-depth
evaluation (see annexure). They represent the gaps that must be addressed
ahead of the eCHIS pilot in the field. As mentioned in the introduction, the
implementation of these features represents the “shortest path to success”
towards the achievement of a pilot-ready eCHIS implementation. The gaps take
into account the totality of all features available in the most comprehensive
eCHIS reviewed and identify what is missing to complete those particular
implementations.

2.1 Client Referral

The eCHIS shall provide a comprehensive feature for client referral with the
following characteristics:
1. The ability for the CHV to fill out a digital version of the MOH 100 client
referral form on their mobile app.
2. The ability for the eCHIS to automatically send the data from the digital
MOH 100 client referral form to the DHP instance at the client’s link facility.
3. The ability for the eCHIS to automatically receive a client’s counter-referral
form from the health facility and present it to the CHV for processing.

2.2 Commodity Supply Chain

The eCHIS shall provide a comprehensive feature for commodity supply chain
with the following characteristics:
1. The ability for the CHA to view CHV commodity movement records and
identify resupply needs.
2. The ability for the CHA to fill out a commodity requisition form on the
eCHIS.
3. The ability for the eCHIS to automatically send the requisition form to the
DHP instance at the CHA’s link health facility.
4. The ability for the eCHIS to receive and present to the CHA a commodity
resupply offer emanating from the DHP.
5. The ability for the CHA to accept or decline a commodity resupply offer,
indicating the reasons thereof.
6. The ability for the eCHIS to automatically update CHA commodity stock
once a resupply offer has been accepted and fulfilled.
7. The ability for the CHA to issue commodities to individual CHVs through
the eCHIS and have their commodity stock levels updated accordingly.
8. The ability for CHVs to dispense commodities during service delivery and
have their stock levels updated accordingly.
9. The ability for CHVs to perform adjustments to their stock levels including
recording expired, damaged or lost commodities.
10. A comprehensive audit trail to track the movement of stocks throughout
the supply chain.

Software Requirements Specification for the Kenya National Electronic / 44

Community Health Information System (eCHIS)
3. eCHIS-DHP Interoperability

3.1 Introduction

According to the Health Information and Management Systems Society,

interoperability in the healthcare system is defined as, “the ability of different
information systems, devices and applications to access, exchange, integrate and
cooperatively use data in a coordinated manner, within and across organizational,
regional and national boundaries, and to provide timely and seamless portability
of information, as well as optimize the health of individuals and populations”.
Interoperability is achieved through data exchange architectures, application
interfaces and standards that enable data to be accessed and shared
appropriately and securely across the complete spectrum of care, within all
applicable settings with relevant stakeholders, including individuals. The goal of
data exchange schema and standards should be to allow for the sharing of data
among healthcare community participants irrespective of which applications or
vendors they use, thereby transcending organizational boundaries and promoting
effective healthcare delivery. Therefore, interoperability offers the potential to
help healthcare organizations to break down the barriers that block meaningful
communication among Health IT systems. Health systems interoperability is
recognized as having the following 3 levels. The initial implementation of eCHIS-
DHP interoperability aims to achieve at least structural interoperability (Level 2).

3.1.1 Foundational Interoperability

Foundational interoperability is the least sophisticated level and refers to the
ability of systems to exchange data securely without any requirement for either
of them to interpret the information received. This is the most basic level of
interoperability that systems must meet in order to be considered to be sharing
data. The format of the data exchanged at this level is not governed by any
standards. Consequently, foundational interoperability on its own is not very
useful. However, it forms the foundation for higher levels of interoperability.

3.1.2 Structural Interoperability

Structural interoperability represents an intermediate level of sophistication and
improves on functional interoperability by introducing standardized information
exchange formats. On this level, the focus is on packaging the shared data
according to standards agreed upon. The standards may be international, e.g.,
Health Level 7 (HL7), or local, i.e., internal formatting agreements, that the
communicating systems must adhere to within a particular organization or
set of organizations. Structural interoperability guarantees that the systems
exchanging data can do so in a way that preserves the integrity of the original
and allows them to process the data to a minimal degree, e.g., by extracting the
constituent fields and saving them to a database.

3.1.3 Semantic Interoperability

Semantic interoperability represents the highest level of sophistication. It allows

45 / Software Requirements Specification for the Kenya National Electronic

Community Health Information System (eCHIS)
participating systems to interpret and therefore, be able to use the data received
as part of an information exchange transaction. To achieve this, systems must
share a common understanding of the data at the data field level. This calls
for a centrally shared reference or dictionary to support the unambiguous
interpretation of the meanings of terms. Such a reference is sometimes also
referred to as metadata, i.e. “data about data” and is typically managed centrally
by a local or international organization mandated to do so. By coupling the health
information exchange standards discussed under structural interoperability
with a shared vocabulary, systems can transmit data in a single, self-contained
information package that both preserves the integrity of the original, and
ensures that it can be interpreted at the destination.

3.2 Interoperability For Client Referral

3.2.1 Community to Health Facility Referral

3.2.1.1 Description
A community-to-facility referral occurs when a CHV identifies a client who needs
to be sent to a health facility for one or more of a variety of health reasons
that the CHV cannot handle at the community level. Reasons for a referral may
include danger signs e.g., reduced foetal movement in pregnancy, or clients
who have defaulted on their clinic appointments. The CHV is trained to identify
referral cases. The role of the eCHIS is to facilitate the referral process once
the need for a referral has been identified. In order for a referral to be digitally
sent to a health facility, the health facility must be running an Electronic Health
Record(EHR). For the purposes of this description, DHP is assumed to be the
default EHR. However, the process is applicable to other EHR implementations.

Normally, a community-to-facility referral is targeted at the client’s link health

facility. However, the design described below takes into consideration the fact
that a client may exercise their right to seek healthcare at a clinic that is different
from their link health facility. For this reason, the community-to-facility referral
workflow not only provides for the eCHIS to send a client referral to the client’s
link facility, but also allows any authorized health facility to query for a client’s
referral information on demand.

Once a client is referred from the community to a health facility, the underlying
expectation is that the client makes a clinic visit. Ideally, the client is expected to
indicate to the healthcare provider that their visit is in fulfilment of a community-
based referral. However, the eCHIS referral workflow is designed to work
correctly regardless of whether or not the client reveals the referral nature of
their visit. This is achieved by requiring healthcare providers to query the eCHIS
for a client’s list of active referrals whenever they are processing the client.

When a healthcare provider processes a client, who was referred to the health
facility from the community, he or she is expected to issue a counter-referral.
A counter-referral may simply be a note to say that the client honoured the
referral, or a more substantive response such as an explicit instruction for the

Software Requirements Specification for the Kenya National Electronic / 46

Community Health Information System (eCHIS)
client to be offered psychosocial support at the community level. The utility of a
counter referral is to either; (a) notify the CHV to stop following up a client who
has honoured his referral or (b) instruct the CHV to further follow up the client
to execute specific orders from the healthcare provider.

3.2.1.2 Workflow
The flowchart below summarizes the process of performing a complete
community-to-facility client referral. Each node represents a distinct step in the
process and is explained below the diagram

Referral
CHV visits note No DHP queries eCHIS for
a household available? referral note(ad-hoc)

Yes

CHV identifies need DHP notifies HCP

for client referral of referral note

CHV fill out HCP processes

referral form the client

Referral form is HCP fills out counter-

stored on eCHIS referral form

eCHIS sends referral Counter-referral form Referral

note to DHP is stored on DHP Complete

DHP DHP sends

No CHV processes
acknowledges counter-referral
. receipt? to eCHIS
counter-referral

Yes

eCHIS
Client visits Yes eCHIS notifies CHV
acknowledges
health facilty of counter-referral
receipt?

No

DHP queries eCHIS for eCHIS queries DHP for

referral notes(router) counter referrals (routine)

A flowchart depicting a complete community-to-facility referral

47 / Software Requirements Specification for the Kenya National Electronic

Community Health Information System (eCHIS)
1. CHV visits a household: A CHV makes a routine or ad hoc visit to a
household. During the visit, the CHV offers the normal community health
services.
2. CHV identifies the need for client referral: The CHV identifies the need
for client referral e.g., by screening for pneumonia signs and symptoms.
3. CHV fills out referral form: To initiate a referral, the CHV fills out a digital
referral form on the eCHIS.
4. Referral form is stored on the eCHIS: Before sending a referral note to
the health facility, the eCHIS stores a copy of the referral form for future
reference.
5. eCHIS sends a referral note to DHP: The eCHIS then pushes the referral
note to the client’s link health facility through the DHP.
6. DHP acknowledges receipt: If DHP receives the referral note from the
eCHIS, it immediately acknowledges receipt.
7. DHP queries eCHIS for referral notes (routine): The DHP periodically
queries for/pulls any unacknowledged referral notes from the eCHIS.
8. Client visits health facility: The client eventually visits the health facility
either to honour their referral or simply as a normal visit.
9. Referral note available: The DHP checks whether it has an unprocessed
referral note for the client.
10. DHP queries eCHIS for referral note (ad hoc): If an unprocessed referral
note is not available, the DHP attempts to query the eCHIS in case one is
available.
11. DHP notifies HCP of referral note: If a referral note is available, either
from a previous push or from the ad hoc pull, the DHP notifies the HCP.
12. HCP processes the client: The HCP processes the client e.g., by clerking
the client, ordering investigations, performing diagnosis and prescribing
medication.
13. HCP fills out a counter-referral form: The HCP issues a counter-referral to
either indicate that the client has been processed or to request community-
level follow up.
14. Counter-referral form is stored on DHP: Before sending the counter-
referral back to the community, the DHP stores a copy for future reference.
15. DHP sends a counter-referral form to eCHIS: The DHP then pushes the
counter-referral to the client’s CHU through the eCHIS.
16. eCHIS acknowledges receipt: If eCHIS receives the referral note from the
DHP, it immediately acknowledges receipt.
17. eCHIS queries DHP for counter-referrals (routine): The eCHIS periodically
queries for/pulls any unacknowledged counter-referrals from the DHP.
18. eCHIS notifies CHV of counter-referral: The eCHIS notifies the relevant
CHV of the counter-referral received from the health facility.
19. CHV processes counter referral: The CHV accesses the counter-referral
and processes it as necessary e.g., by executing the HCP’s instructions.
20. Referral complete: The community-to-facility referral and counter-
referral loop is completed and the referral is marked as completed.

Software Requirements Specification for the Kenya National Electronic / 48

Community Health Information System (eCHIS)
3.2.1.3 Data Structures
Upon the referral of a client from the community to a health facility, the eCHIS
generates a JSON message in the following format:
{
“SHId”:”sdfds”,
“DHPId”:”85”,
“Date”:”2021/03/25 16:00:30”,
“FirstName”:”John”,
“MiddleName”:”Smith”,
“LastName”:”Doe”,
“Sex”:”male”,
“DateOfBirth”:”2020/01/05 00:00:00”,
“Phone”:”0710981830”,
“ChuId”:”089933”,
“ReferralReason”:”Diarrhoea”,
“Treatment”:”ORS”,
“comments”:”Kindly attend to the patient”,
“ChvId”: “0sdfs”,
“ChvName”:”Onyango Ouma”,
“ChvPhone”:”0711223344”
}
Upon the issuance of a counter-referral of a client from the health facility back
to the community, the DHP generates a JSON message in the following format:
{
“OfficerName”: “Bernard Onyancha”,
“OfficerNumber”: “+254710900100”,
“ChvId”: “9903ED01”,
“DHPId”: “0011A”,
“ReferralNotes”: “Tuberculosis confirmed”,
“DateOfVisit”: “2021/03/09 00:00:00”,
“CallMadeToChv”: “Yes”
}

3.2.1.4 APIs
Service APIs

URL Payload

dhp_url JSON (Referral, see data structure above)

echis_url JSON (Counter- referral, see data structure

above)

49 /Software Requirements Specification for the Kenya National Electronic

Community Health Information System (eCHIS)
3.2.2 Health Facility to Community Referral

3.2.2.1 Description
A facility-to-community referral occurs when a healthcare provider identifies a
client who needs to be sent to a CHV for one or more promotive and preventive
healthcare services that are rendered at the community level. Reasons for a
referral may include a client’s need for home-based care, psychosocial support,
counselling, drug adherence supervision among others. The healthcare provider
is trained to identify referral cases. The role of the eCHIS is to facilitate the
referral process once the need for a referral has been identified. In order for
a referral to be digitally sent from a health facility, the health facility must be
running an EHR. For the purposes of this description, DHP is assumed to be the
default EHR. However, the process is applicable to other EHR implementations.
Unlike a community-to-facility referral which may be honoured by the client
at a clinic different from their link facility, facility-to-community referrals are
necessarily processed at a client’s CHU. Also, facility-to-community referrals are
different from community-to-facility counter-referrals in that they necessarily
contain substantive instructions to the CHV. Community-to-facility counter-
referrals, on the other hand, may either contain substantive instructions to the
CHV, or simply note that the client honoured their appointment and therefore
do not need to be followed up for it at the community level.

3.2.2.2 Workflow
The flowchart below summarizes the process of performing a complete facility-
to-community client referral. Each node represents a distinct step in the process
and is explained below the diagram.
CHV visits
a household

Client visits
health facilty

HCP identifies
need for referral

HCP fills out

referral form

Referral form is
stored on DHP

DHP sends referral

note to eCHIS

eCHIS
eCHIS queries DHP No acknowledges Referral
for referral (routine) receipt? Complete

Yes

eCHIS notifies CHV processes

CHV of referral referral

A flowchart depicting a complete facility-to-community referral

Software Requirements Specification for the Kenya National Electronic / 50

Community Health Information System (eCHIS)
 1. Client visits health facility: A client makes a visit to a health facility. During
the visit, the client receives the normal services offered at a health facility.
2. HCP identifies need for community referral: In the course of service
provision to the client, the HCP identifies a need for community referral
e.g. for psychosocial support.
3. HCP fills out a referral form: To initiate a referral, the HCP fills out a digital
referral form on the DHP.
4. Referral form is stored on DHP: Before sending a referral note to the
community, the DHP stores a copy of the referral form for future reference.
5. DHP sends a referral note to eCHIS: The DHP then pushes the referral
note to the client’s Community Area through the DHP.
6. eCHIS acknowledges receipt: If eCHIS receives the referral note from the
DHP, it immediately acknowledges receipt.
7. eCHIS queries DHP for referral (routine): The eCHIS periodically queries
for/pulls any unacknowledged referral notes from the DHP.
8. eCHIS notifies CHV of referral: If a referral note is available, either from a
previous push or from the ad hoc pull, the eCHIS notifies the CHV.
9. CHV processes referral: The CHV processes the client e.g. by developing
a care plan according to referral instructions.
10. Referral complete: The facility-to-community referral loop comes to an
end and the referral is marked as completed.

3.2.2.3 Data Structures

Upon the referral of a client from a health facility to the community, the DHP
generates a JSON message in the following format:
{
“DateOfVisit”: “2021/02/27 45:10:02”,
“ClinicianName”: “Everlyne Wanja”,
“DHPId”: 9903,
“Sex”: “Male”,
“DateOfBirth”: “1997/06/29 00:00:00”,
“CommunityHealthUnit”: “0002”,
“ReasonsForReferral”: “Counselling”,
“ReferralNotes”: “Provide psychosocial support”
}

3.2.2.4 APIs
Service APIs

URL Parameters

echis_url JSON (Facility referral, see data structure above)

51 / Software Requirements Specification for the Kenya National Electronic

Community Health Information System (eCHIS)
3.3 Interoperability For Commodity Supply Chain Management
3.3.1 Description
At the community level, the CHA is responsible for requisitioning community
service commodities from the link health facility. The CHA then distributes the
commodities to CHVs for dispensing to households as needed. Commodities at the
health facility will be managed using the DHP. As such, it will be the responsibility
of the DHP to coordinate the supply and management of commodities from
KEMSA and other suppliers. The role of the eCHIS in commodity supply chain
management, therefore, begins at the health facility level and downwards to the
community level where the commodities are dispensed to clients. The CHA will
rely on the data in the eCHIS and coordinate with individual CHVs to determine
when to reorder commodity supplies. For this reason, the eCHIS will also be
responsible for tracking commodity issuance to CHVs as well as commodity
dispensing from CHVs to clients. In so doing, the eCHIS will maintain a running
log of what commodities are in what state i.e., requisitioned, issued, dispensed
etc.

The process of commodity supply chain management at the community level

therefore entails the following steps:
1. The CHA determines the need for commodity restock and logs a resupply
request with the pharmacy at the health facility.
2. The pharmacy at the health facility processes the resupply request and
issues to the CHA the commodities requested.
3. The CHA issues the commodities obtained from the health facility
pharmacy to individual CHVs.
4. The CHVs dispense the commodities obtained from the CHA in the normal
course of delivering community health services.
5. The CHA monitors stock movements from themselves to CHVs and from
CHVs to clients and uses this information to make the next resupply
request.

The procedures described above may take place on either the eCHIS or on the
DHP depending on the specific needs to be fulfilled. In some cases, the eCHIS
and the DHP have to interoperate. The workflow section below describes the
design details of the interoperability use cases where the eCHIS and DHP need
to share data to facilitate commodity supply chain management.

3.3.2 Workflow
The flowchart below summarizes the process by which a CHA requisitions
commodities from the link health facility. Each node represents a distinct step in
the process and is explained below the diagram.

Software Requirements Specification for the Kenya National Electronic / 52

Community Health Information System (eCHIS)
 CHA notices
low stock levels The end
on eCHIS

CHA prepares stock Commodity/ stock

order reporting

CHVs may also perform

CHA enters stock
stock adjustments
order on DHP
via eCHIS

Main pharmacy CHVs dispense stocks

restocks CHA via DHP via eCHIS

CHA issues stocks to

CHA collects stocks
CHVs via eCHIS

A flowchart depicting the process of requisitioning commodities from the health

facility by the CHA.

1. CHA notices low stock levels on eCHIS: The CHA routinely reviews stock
reports on the eCHIS to identify a low stock condition based on stock
movement within the eCHIS.
2. CHA prepares stock order: To initiate commodity resupply, the CHA
prepares a stock order indicating the commodities and quantities to be
ordered.
3. CHA enters stock order on DHP: The CHA enters the stock order in the
DHIS to initiate the restocking process at the main pharmacy at the link
facility.
4. Main pharmacy restocks the CHA via DHP: The main pharmacy processes
the order and restocks the CHA (treated as a “mini-pharmacy” at the
health facility).
5. CHA collects stocks: The CHA arranges to collect the commodities for
issuance to CHVs at the community level.

53 / Software Requirements Specification for the Kenya National Electronic

Community Health Information System (eCHIS)
 6. CHA issues stocks to CHVs via eCHIS: The CHA can see the stock levels
for various CHVs on the eCHIS. The CHA issues commodities to CHVs
accordingly.
7. CHVs dispense stocks via eCHIS: The CHVs dispense stocks in the
community as needed using the eCHIS to track stock movements.
8. CHVs may perform stock adjustments via eCHIS: eCHIS allows CHVs
to perform stock adjustments as necessary e.g. to account for expiry or
losses.
9. Commodity Stock Reporting: The stock ordering, issuance, dispensing
and adjustment data is used to inform commodity management reports.

3.3.3 Data structures

A commodity requisition by the CHA is sent to the DHP as a JSON message in
the following format:
{ “Date”: “2021/03/25 16:00:30”,
“ChuId”: “089933”,
“comments”: “Please expedite”,
“ChvId”: “0sdfs”,
“ChvName”: “Onyango Ouma”,
“ChvPhone”: “0711223344”,
“CommodityList”: [{
“CommodityId”: 1001,
“CommodityName”: “ORS”,
“CommodityQuantity”: “200”,
“QuantityUnits”: “Sachets”
},
{
“CommodityId”: 1016,
“CommodityName”: “Paracetamol”,
“CommodityQuantity”: “80”,
“QuantityUnits”: “Blister packs”
}
]
}

A commodity resupply offer by the health facility pharmacist is sent to the

eCHIS as a JSON message in the following format:
{
“Date”: “2021/03/25 16:00:30”,
“FacilityId”: “2798”
“ChuId”: “089933”,
“comments”: “Not enough ORS”,
“ChvId”: “0sdfs”,
“ChvName”: “Onyango Ouma”,
“ChvPhone”: “0711223344”,
“CommodityList”: [{
“CommodityId”: 1001,
“CommodityName”: “ORS”,

Software Requirements Specification for the Kenya National Electronic / 54

Community Health Information System (eCHIS)
 “CommodityQuantity”: “180”,
“QuantityUnits”: “Sachets”
},
{
“CommodityId”: 1016,
“CommodityName”: “Paracetamol”,
“CommodityQuantity”: “80”,
“QuantityUnits”: “Blister packs”
}
]
}

3.3.4 APIs
Service APIs

URL Parameters

DHP_url JSON (Requisition, see data structure

above)
eCHIS_url JSON (Offer, see data structure
above)

3.4 Community-Based Surveillance

3.4.1 Description
Community-Based Surveillance covers the reporting of notifiable diseases and
public health events of interest identified in the community to the Sub-County
Disease Surveillance Focal Person (SCSFP). The Sub-County Disease Surveillance
Focal Person is then responsible for submitting verified reports to the Division
of Disease Surveillance and Reporting at the national level for action.

3.4.2 Workflow
The flowchart below summarizes the process by which a CHV files a surveillance
report, gets it verified by the CHA, who then reports it to the Sub-County Disease
Surveillance Focal Person for investigation and reporting to the Division of
Disease Surveillance and Reporting at the national level. Each node represents
a distinct step in the process as explained below the diagram.

55 / Software Requirements Specification for the Kenya National Electronic

Community Health Information System (eCHIS)
 CHV becomes
aware of a notifiable The end
disease or event of
public health interest

CHV files a report on the SCSFP submits the report

disease or event through to DDSR via the surveillance
the eCHIS system

CHA receives the report SCSFP investigates

from the CHV the report

CHA verifies the report CHA forwards the report

filed by the CHV to the SCSFP

Verified?

A flowchart depicting the process of filing a surveillance report from the community to DDSR.

1. CHV becomes aware of a notifiable disease or event of public health

interest: The CHV discovers a notifiable disease through direct observation
or a tip off from the community.
2. CHV files a report on the disease or event through the eCHIS: The CHV
enters the nature and time of the event in the eCHIS.
3. CHA receives the report from the CHV: The CHA views all reported events
from his or her CU on a dashboard on the eCHIS.
4. CHA verification outcome: The CHA verifies each case reported by the
CHV by calling or visiting the affected area/CU.
5. CHA forwards the report to the SCSFP: If the CHA verifies the report to
be credible, he or she sends it to the SCSFP via phone call or email.
6. SCSFP investigates the report: The SCSFP further investigates the case.
7. SCSFP submits the report to DDSR via the Surveillance System: If the
case is found to be valid, the SCSFP submits it to the DDSR through the
Surveillance System.

Software Requirements Specification for the Kenya National Electronic / 56

Community Health Information System (eCHIS)
ANNEXES

eCHIS In-Depth Evaluation Report

March 2021

57 / Software Requirements Specification for the Kenya National Electronic

Community Health Information System (eCHIS)
1. Introduction
1.1 Background
The Ministry of Health (MOH) is committed to the digitization of healthcare
across the Kenya Essential Package for Health (KEPH) levels. This includes
Level 1 which is realized through frontline Community Health Extension Workers
(CHEWs) at the household level. The journey of adopting the electronic
Community Health Information System (eCHIS) began with the development
of a National Community Health Digitization Strategy. As part of that process,
a comprehensive landscape assessment was undertaken to identify, document
and describe the available digital technologies used for community health within
the country. Among the recommendations of the landscape assessment report
was to conduct a more detailed evaluation of the features and implementation
scope of the community health digital solutions it identified as a way to validate
and augment the information gathered from system implementers.

The second phase of the digitization of community health service delivery is

focused on the development, testing and piloting of the eCHIS prototype in
selected counties. Towards this goal, the MOH and its partners held a workshop
to firm-up and kick off the activities of Phase II. The eCHIS Technical Working
Group (TWG) resolved to take advantage of this workshop to develop and
demonstrate in-depth criteria for reviewing existing CHIS. This report covers the
development, execution and results of that evaluation criteria.

1.2 Objectives
The objective of the CHIS in-depth evaluation was to:
1. Develop common criteria for evaluating and identifying gaps in existing
Community Health Information Systems.
2. Demonstrate the application of the criteria by evaluating CHIS with
representation at the Phase II Workshop.

Software Requirements Specification for the Kenya National Electronic / 58

Community Health Information System (eCHIS)
2. Methodology
2.1 Criteria Development
A team of technology experts drawn from the Ministry of Health and its
development partners was invited to propose a criteria for the evaluation of
existing digital health interventions for community health. The criteria was
reviewed and agreed upon by a wider group, with representation from the areas
of community health, monitoring and evaluation, and training and capacity
building. Membership for the wider review group was also drawn from the
Ministry of Health and its partners. The resulting evaluation criteria broadly
covered the functional and non-functional requirements of Community Health
Information Systems articulated in the Software Requirements Specification.
Under each category, specific areas of focus were selected to represent various
CHIS functionalities. These included household enrolment, service delivery,
supply chain management, surveillance, among others. Under each area of focus,
a set of procedures was defined to ascertain the availability of specific system
features. The procedures were codified in the form of a checklist (Annex A). A
simple Pass/Fail rating rather than a point scale was chosen in order to minimize
evaluator bias. A Pass simply means that a particular feature is available “in some
form” and “to some degree”. It does not rate the “quality” of the functionality.
On the other hand, a Fail means that the feature is not available altogether.

2.2 Criteria Application

Participants resolved to demonstrate the utility of the CHIS evaluation criteria by
applying it to all CHIS with representation at the Phase II workshop. Evaluators
were asked to apply each procedure in the checklist to individual CHIS and assign
it a Pass or a Fail depending on whether the procedure could be successfully
executed. Verification of each procedure through an actual demonstration was
strongly encouraged. Where such a demonstration was not possible, evaluators
could still assign a Pass provided the CHIS developer or implementer reported
that the procedure could, in fact, be executed successfully. In any case, evaluators
were required to indicate whether or not a given procedure was demonstrated,
or simply scored based on second-hand information.
Each procedure in the evaluation criteria consisted of a description as well
as the result expected to warrant a Pass or a Fail. In addition to scoring each
procedure, evaluators were also asked to indicate whether the procedure was
actually demonstrated or simply reported. The examples below show how
procedures were defined and applied.

Procedure Definition

Procedure Enrol a new household onto the system based on the MOH
513 form.
Result Pass if a new household is successfully enrolled and Fail If a
new household cannot be successfully enrolled.
Demo Yes if the functionality is demonstrated and No if the
functionality is simply reported but not demonstrated.

59 / Software Requirements Specification for the Kenya National Electronic

Community Health Information System (eCHIS)
 Procedure Application (CHIS X)

Procedure Pass/Fail Demo Comment

Enrol a new household onto the system Pass Yes None

based on the MOH 513 form.
Reactivate a deactivated household Pass No None
Re-assign a client to a different house- Fail No None
hold

The populated sample checklist above implies that:

1. CHIS X is able to enrol a new household based on the MOH 513 form, and
this was verified through a demonstration.
2. CHIS X is able to reactivate a deactivated household. However, this was
simply reported but not verified through a demonstration.
3. CHIS X is not able to reassign a client to a different household i.e. this
feature is not available on the system.

The checklist was applied to a total of 5 CHIS namely; CHT, CommCare, cStock,
MJali and SmartHealth. The evaluation was conducted by teams of between 5
and 8 individuals, with representation from the Ministry of Health and partner
organizations (Annex B).

2.3 Scoring
In order to be able to compare gaps between the different CHIS evaluated, a
percentage score was computed for each area of focus in the criteria. This was
calculated as the total number of Passes achieved divided by the total number
of possible Passes for that area multiplied by 100. For instance, there were 10
distinct procedures defined under Household Enrolment. Therefore, for a CHIS
that achieved 9 out of 10 Passes, the percentage score was computed as 9/10 x
100 = 90%. Scores were calculated for each area of focus for both functional and
non-functional categories. The scores were then averaged to compute a single
score for each category. The scores from each category were then averaged
to yield a single final score. The next chapter covers the results of this scoring
procedure.

Software Requirements Specification for the Kenya National Electronic / 60

Community Health Information System (eCHIS)
3. Results And Discussion
The tables below summarise the results of the in-depth CHIS evaluation and
the associated scores. The full set of scoring results is available as Annex C in
this report. In interpreting these results, it is important to bear in mind that the
percentage score in any focus area represents the proportion of test procedures
that were either executed successfully or that were reported to be possible to
execute successfully.

3.1 Functional Specifications

3.1.1 Results

Focus Area/ CHT Com- cStock MJali SmartHealth

System mCare
Household 100% 90% 0% 50% 100%
Enrolment
User Management 80% 90% 90% 90% 80%

Service Delivery 71% 71% 0% 7% 93%

Supply Chain 11% 11% 56% 0% 56%

Surveillance 80% 20% 0% 20% 100%

Messaging 100% 80% 20% 0% 100%

Reporting 100% 100% 0% 40% 100%

Offline Capability 100% 100% 100% 100% 100%

AVERAGE SCORE 80% 70% 33% 38% 91%

3.1.2 Discussion
Focus Area Discussion

Household Enrolment Household enrolment is a well-supported area of

functionality for both CHT and SmartHealth, with both
successfully demonstrating the successful execution
of all test procedures. CommCare also has strong
support for this area of functionality but fell short of
demonstrating the ability to reassign clients to new
households. Mjali has basic support for household
enrolment but was not able to demonstrate a number
of critical features in this area. cStock offers no
support for household enrolment as it is intended
exclusively as a digital solution for commodity supply
chain management.

61 / Software Requirements Specification for the Kenya National Electronic

Community Health Information System (eCHIS)
User Management User management is supported to a significant degree
by all CHIS implementations evaluated. However,
critical gaps were identified, particularly in terms of
enabling CHVs to manage their own user accounts.
This includes performing actions such as password
changes or resets. 3 out of the 5 systems evaluated
also do not require CHVs to change their passwords
upon first login, which can raise potential security and
accountability problems as passwords are not fully
private.

Service Delivery Service delivery is a broad and complex area of

functionality. The procedures defined to evaluate this
area sought to check the degree of flexibility available
in various CHIS for defining new workflows, data
collection forms and data validations. SmartHealth
showed the widest scope of features which included
creating and updating workflows to support new
and existing community health programs as well as
facilitating CHV supervision. CHT and CommCare
were also reasonably strong in this area, but suffered
minor weaknesses such as the inability to push
updates to CHVs and embed help content within the
app. MJali was not able to demonstrate the majority
of procedures in this area and cStock, as a dedicated
supply chain management tool, simply does not
support any service delivery capabilities.
Commodity Supply This was the weakest area of functionality among all
Chain Management 5 CHIS evaluated. cStock demonstrated significant
strength in this area with support for 5 of the 9
procedures defined for this section. However, it still
fell short in the areas of commodity dispensing,
adjustments and returns. SmartHealth was also
able to show all the functionality in cStock except
for commodity ordering. Both CHT and CommCare
demonstrated basic support for commodity
dispensing. It is important to note, however, that except
for cStock much of the functionality demonstrated
in this area was implemented though simple data
collection forms. As such there is a need to upgrade
this capability into a more sophisticated and useful
inventory management system.
Surveillance Surveillance is a fairly well supported area of
functionality by both SmartHealth and CHT. CommCare
and Mjali also have rudimentary support for this area
of functionality, specifically in terms of allowing CHVs
to record cases of notifiable disease and report public
health events respectively.

Software Requirements Specification for the Kenya National Electronic / 62

Community Health Information System (eCHIS)
Messaging This area of functionality relates to the ability of the
system to send text or other messages to clients. CHT
and SmartHealth have strong messaging capabilities
with both passing all the test procedures defined
for this area. CommCare also supports most core
messaging functionality except structured messages
based on preconfigured workflows. cStock supports
only broadcast messages while MJali does not offer
any messaging capabilities.
Reporting Flexible reporting is well supported across the board,
with CHT, CommCare and SmartHealth scoring 100%
in all test procedures for this area. cStock did not
support any of the reporting test procedures defined
in the checklist. However, its backend is based on
DHIS2 and therefore capable of being extended to
accommodate emerging reporting needs. MJali also
has reporting capability but this only covers client-
based reports. MJali reporting functionality does not
allow for the generation of CHV-based reports.

3.2 Non-Functional Specifications

3.2.1 Results
Focus Area/System CHT Com- cStock MJali SmartHealth
mCare
Code Licensing 100% 100% 0% 100% 100%

Audit Trail 100% 100% 100% 0% 100%

Security 100% 20% 100% 40% 100%

Backup/Disaster 100% 67% 100% 0% 100%

Recovery

Interoperability 50% 50% 50% 0% 50%

Performance/ 100% 0% 0% 0% 100%

Scalability
AVERAGE SCORE 92% 56% 58% 23% 92%

3.2.2 Discussion
Focus Area Discussion

Code Licensing All CHIS evaluated are open source except cStock.
However, it was intimated that cStock source code
can be made available to the MOH on demand.

63 / Software Requirements Specification for the Kenya National Electronic

Community Health Information System (eCHIS)
Offline Capability All 5 CHIS evaluated support offline capability and
can be used in the field with or without active internet
connectivity.
Audit Trail CHT, CommCare, cStock and Smart Health all reported
audit trail capability.
Security CHT, cStock and Smart Health passed all the test
procedures under the security category. Some of
CommCare’s security features could not be established
as the responding implementer is not responsible for
hosting the system. MJali lacks some critical security
features such as password salting and hashing, SSL
and PKI.
Backup and Disaster Backup and disaster recovery procedures were found
Recovery to be robust for CHT, cStock and Smart Health.
CommCare also has some backup and disaster
recovery capabilities. However, not all of them could
be evaluated since the implementer does not host the
system directly.
Interoperability Support for interoperability is scanty, with none of the
systems passing more than half the test procedures
for this area.

Performance and Only CHT and Smart Health reported having

Scalability established procedures and tools for performance
and stress testing.

3.3 Overall Scores

Category/System CHT CommCare cStock MJali SmartHealth

Functional 80% 70% 33% 38% 91%

Specifications
Non-functional 92% 56% 58% 23% 92%
Specifications
AVERAGE SCORE 86% 63% 46% 31% 91%

Software Requirements Specification for the Kenya National Electronic / 64

Community Health Information System (eCHIS)
4. Limitations
This evaluation report is subject to the following limitations.
1. The report covers the results of the CHIS whose implementers were
represented in the eCHIS Phase II workshop.
2. The evaluation criteria covers the presence or absence of features, not the
quality of their implementation.
3. The evaluation criteria does not cover all possible functional and non-
functional requirements.
4. Not everything covered in the evaluation criteria was possible to
demonstrate. This was mainly because of the lack of necessary permissions,
time or capacity.
5. Although all features (available or missing) were treated the same for the
purposes of the scoring, in reality some features are more mission-critical
than others.
6. Where the score for a procedure was left blank, a Fail was assigned
since it could not be established whether the procedure could have been
successfully executed.

65 / Software Requirements Specification for the Kenya National Electronic

Community Health Information System (eCHIS)
5. Recommendations
1. The results of this in-depth evaluation can augment the findings of the
landscape assessment and support the MOH in identifying key gaps in
existing CHIS.
2. The eCHIS implementation team can reach out to individual CHIS
implementers and based on their area of strength identify and adopt key
success factors as necessary.
3. The evaluation criteria described in this document can form the basis for
a future CHIS certification framework.

Software Requirements Specification for the Kenya National Electronic / 66

Community Health Information System (eCHIS)
6. Annexes
6.1 ANNEX A: EVALUATION CHECKLIST

PROCEDURE EXPECTED RESULT Pass/Fail Demo Comments

Pass/Fail
1. FUNCTIONAL SPECIFICATIONS

1.1 HOUSEHOLD ENROLLMENT

Enrol a new New household

household onto successfully enrolled
the system (MOH
513)
Update an Household
existing successfully
household (MOH updated
513)
Deactivate Household
an existing successfully
household deactivated
Reactivate a Household
deactivated successfully
household reactivated
Re-assign Household
household to a successfully
different CHU re-assigned to a new
CHU
Enrol client into a Client successfully
household enrolled into a
household
Update client Client data
data within a successfully
household - updated
Change first and
last name
Deactivate Client no longer
client within a available for CH
household services
Reactivate Client becomes
client within a available for CH
household services
Re-assign a client Client available for
to a different CH service provision
household under a different
household

67 / Software Requirements Specification for the Kenya National Electronic

Community Health Information System (eCHIS)
1.2 USER MANAGEMENT

* Create an Organizational
organizational hierarchy successfully
hierarchy within the created
system (National
> County > Sub-
county > Ward >
Facility > CHU >
Cluster)
Create a user role User role created with
based on the selected system
pre-defined privileges
privileges
Update an existing User role updated
user role based with the selected
on pre-defined system privileges
privileges
Delete/remove an User role deleted
existing user role
Create a user User account
(username, created with the
default password, specified details
telephone number,
email address, first
name, last name,
designation)
Assign a user to User assigned
any level within to a level in the
the organizational organizational
hierarchy hierarchy e.g. CHU
Assign one or more Roles assigned to the
roles to a user user. User inherits the
privileges defined in
the assigned role.
New user logs into eCHIS requires the
the eCHIS for the new user to change
first time his/her password

User resets his/her eCHIS allows the user

password to securely change
his/her password

Software Requirements Specification for the Kenya National Electronic / 68

Community Health Information System (eCHIS)
Disable a user User account
account disabled but
continues to exist in
the system. The user
can no longer log into
the system.

1.3 SERVICE DELIVERY

Create a new New data collection

workflow (with the workflow defined
associated data with a form, skip logic
collection and data
form/validations/ validation
skip logic etc.)
Update an existing Existing workflow
workflow (with the updated new/
associated data modified
collection form/ variables, skip logic
validations/skip and data validation
logic etc.)
Deactivate an Existing workflow
existing workflow deactivated. It is no
(with the associated longer
data collection available for
form/validations/ use/data entry.
skip logic etc.)
Reactivate a Existing workflow
deactivated reactivated. It
workflow (with the becomes available for
associated data use/data entry again.
collection form/
validations/skip
logic etc.)
Workflow eligibility User can configure a
is configurable by workflow so that only
client characteristics clients with particular
characteristics are
eligible
Workflow created or CHV receives a
updated notification and can
update his/her copy
of
the workflow

69 /Software Requirements Specification for the Kenya National Electronic

Community Health Information System (eCHIS)
CHV activates a CHV is restricted from
workflow for a activating a workflow
household member for a household
for whom it does not member for
apply whom it does not
apply
Create supervision Supervision checklist
checklists to be filled successfully created.
when CHAs visit
CHVs on supervisory
visits
Update supervision Supervision checklist
checklists to be filled successfully updated.
when CHAs visit
CHVs on supervisory
visits
Deactivate Supervision checklist
supervision checklists successfully
to be filled when deactivated. No
CHAs visit CHVs on longer available for
supervisory visits use.
Reactivate Supervision checklist
supervision checklists successfully
to be filled when reactivated.
CHAs visit CHVs on Becomes available for
supervisory visits use again.
Supervisory checklist CHV receives a
created or updated notification and can
update his/her copy
of the workflow

Link to the MOH eCHIS users can go

virtual academy directly from the app
to the MOH virtual
academy
Access user guide Users can access an
within the eCHIS in-built user guide
within the system

1.4 COMMODITY
SUPPLY CHAIN
MANAGEMENT

Raise an order Order is raised

and electronically
submitted

Software Requirements Specification for the Kenya National Electronic / 70

Community Health Information System (eCHIS)
Receive stock Receive stock
within the eCHIS
and allocate it to
individual CHU/CHAs
Restock (CHA-CHV)

Dispensing stock CHV can dispense

(CHV-HH) commodities
through the CHIS
Disposal of stock CHV can designate
(expiry, damage etc.) expired or damaged
commodities
Monitor stock levels CHAs can monitor
(CHA) their stock levels

Monitor stock levels CHVs can monitor

(CHV) their stock levels

Return stock (CHV- CHVs can return stock

CHA) to CHA upon request

Return stock (CHA- CHA can return stock

Facility) to facility
upon request
1.5 SURVEILLANCE

CHV notifies cases of CHP can notify cases

notifiable diseases/ to the CHA via the
conditions through CHIS
the eCHIS to the CHA
CHV reports PH CHV can report PH
events through the events to CHA via
eCHIS to the CHA CHIS
CHA can run through CHA can invoke
a workflow to workflow to validate
validate reports of PH PH even reports
events

eCHIS has outbound CHIS can send PH and

API to send disease notifications
information to a to surveillance system
dedicated
surveillance system
SCDSC can get
notifications on PH
events reported and
validate

71 / Software Requirements Specification for the Kenya National Electronic

Community Health Information System (eCHIS)
1.6 MESSAGING

eCHIS allows user

to configure and
broadcast messages
to CHVs at any level
in the organizational
hierarchy
eCHIS automatically
sends targeted
messages to
clients based
on their specific
characteristics e.g.
defaulting a clinic
visit
eCHIS allows user
to configure and
broadcast messages
to clients at any level
in the organizational
hierarchy
eCHIS should allow
for the
scheduling of
untargeted client
messages
eCHIS should be able
to send
structured messages
to clients and through
a pre-configured
workflow facilitate
live interaction
1.7 REPORTING

Configure and run

a client list report
based on client
attributes (bound to
a definite period)
Filter a client list
report based on
client attributes
and organizational
hierarchy levels

Software Requirements Specification for the Kenya National Electronic / 72

Community Health Information System (eCHIS)
Configure and run a
CHV list report based
on CHV attributes
(bound to a definite
period)
Filter a CHV list
report based on
CH V attributes
and organizational
hierarchy levels

Configure and
run a client
summary based
on aggregation
functions on client
attributes (bound to
a definite period)
Disaggregate a client
summary based on
client attributes and
organizational
hierarchy levels
Collate selected
client summaries
into a single service
statistic report
Configure and run a
CHV summary based
on aggregation
functions on CHV
attributes (bound to
a definite period)
Disaggregate a CHV
summary based
on CHV attributes
and organizational
hierarchy levels
Collate selected
CHV summaries
into a single service
statistic report
Test for ability to
work in conditions
with slow or no
connectivity (offline
data collection)

73 / Software Requirements Specification for the Kenya National Electronic

Community Health Information System (eCHIS)
2. NON-FUNCTIONAL SPECIFICATIONS

2.1 Offline Support

Test for ability to System works offline

work in conditions internet connectivity
with no connectivity
(offline data
collection)
2.2 SOURCE CODE LICENSING

Access source code Source code is

from a public repo accessible in a public
Source code is repository
2.3 AUDIT TRAIL

Audit trail available System administrator

can access audit log
showing the who,
what and when of
actions taken on the
system

2.4 SECURITY

User passwords are User passwords are

salted and hashed salted and hashed in
the
database
Data in transit is HTTP connection
encrypted using 256- is encrypted with a
bit encryption(TLS/ valid SSL certificate
SSL) (HTTPS)

Access to system Logging into the

server is secured system server is
using PKI secured using PKI

Server is behind a The server is secured

hardware/software behind a firewall
firewall
Database is secured A username and
by username and password is required
password to access the
database
2.5 BACKUPS AND DISASTER RECOVERY

Ability to do System maintains

scheduled and scheduled backups
maintain backups

Software Requirements Specification for the Kenya National Electronic / 74

Community Health Information System (eCHIS)
There should be the System demonstrates
ability to restore restore backups

The system System has in-built

should provide for redundancy and
redundancy and failover
failover mechanisms
2.6 INTEROPERABILITY

Data standard
to support data
exchange - HL7 and
related
Integration with System can send
DHIS2 standard MOH
reports to DHIS2
2.7 PERFORMANCE AND SCALABILITY

Established procedures and There are established

tools for performance and procedures and tools
stress testing for performance
testing

6.2 Annex B: Evaluation Teams

CHT SMART MJALI COMM CARE C-STOCK
HEALTH
1. Derrick Robert George Daniella Danielson
2. Simon Emmanuel Aloice Francis Sophie
3 Michael Korir K Dorothy Gitahi Rose
4 Georgine Aisha Linet Priscilla Enock
5. Josephine Benjamin Samuel Ayub Joyline
6. Joshua George O Eric N Wesley
7. Wanyungu Ken Teresa
8. Carol Diane

75 / Software Requirements Specification for the Kenya National Electronic

Community Health Information System (eCHIS)
6.3 Annex C: Evaluation Score Sheet
FEATURE/ CHT CommCare CStock MJali SmartHealth
CHIS
Household 100.00% 90.00% 0.00% 50.00% 100.00%
Enrolment
Enrol a new 1 1 0 1 1
household
onto the
system (MOH
513)
Update an 1 1 0 1 1
existing
household
(MOH 513)
Deactivate an 1 1 0 0 1
existing
household
Reactivate a 1 1 0 0 1
deactivated
household
Re-assign 1 1 0 0 1
household
to a different
CHU
Enrol client 1 1 0 1 1
into a
household
Update client 1 1 0 1 1
data within a
household -
Change first
and last name
Deactivate 1 1 0 1 1
client within a
household
Reactivate 1 1 0 0 1
client within a
household

Re-assign 1 0 0 0 1
a client to
a different
household

Software Requirements Specification for the Kenya National Electronic / 76

Community Health Information System (eCHIS)
User 80.00% 90.00% 90.00% 90.00% 80.00%
Management
Create an 1 1 1 1 1
organizational
hierarchy within
the system
(National >
County >
Sub-county >
Ward > Facility
> CHU > Cluster)
Update an 1 1 1 1 1
existing user
role based on
pre-defined
privileges
Update an 1 1 1 1 1
existing user
role based on
pre-defined
privileges
Delete/remove 1 1 1 1 1
an existing user
role
Create a user 1 1 1 1 1
(username,
default
password,
telephone
number, email
address, first
name, last name,
designation)
Assign a user 1 1 1 1 0
to any level
within the
organizational
hierarchy
Assign one or 1 1 1 1 1
more roles to a
user
New user logs 1 0 0 0 1
into the eCHIS
for the first time

77 / Software Requirements Specification for the Kenya National Electronic

Community Health Information System (eCHIS)
User resets his/ 0 1 1 1 1
her password
Disable a user 0 1 1 1 0
account
Service Delivery 71.43% 71.43% 0.00% 7.14% 92.86%
Create a new 1 1 0 1 1
workflow
(with the
associated data
collection form/
validations/skip
logic etc.)
Update an 1 1 0 0 1
existing
workflow (with
the associated
data collection
form/
validations/skip
logic etc.)
Deactivate 1 1 0 0 1
an existing
workflow (with
the associated
data collection
form/
validations/skip
logic etc.)

Reactivate a 1 1 0 0 1
deactivated
workflow (with
the associated
data collection
form/validations/
skip logic etc.)
Workflow 1 1 0 0 1
eligibility is
configurable by
client
characteristics
Workflow 0 0 0 0 1
created or
updated

Software Requirements Specification for the Kenya National Electronic / 78

Community Health Information System (eCHIS)
CHV activates 1 1 0 0 1
a workflow for
a household
member for
whom it does
not apply
Create 1 1 0 0 1
supervision
checklists to be
filled when CHAs
visit CHVs on
supervisory visits
Update 1 1 0 0 1
supervision
checklists to be
filled when CHAs
visit CHVs on
supervisory visits
Deactivate 1 1 0 0 1
supervision
checklists to be
filled when CHAs
visit CHVs on
supervisory visits
Reactivate 1 1 0 0 1
supervision
checklists to be
filled when CHAs
visit CHVs on
supervisory visits
Supervisory 0 0 0 0 1
checklist created
or updated
Link to the MOH 0 0 0 0 0
virtual
academy
Access user 0 0 0 0 1
guide within the
eCHIS
Commodity 11.11% 11.11% 55.56% 0.00% 55.56%
Supply Chain
Management
Raise an order 0 0 1 0 0
Receive stock 0 0 1 0 1

79 / Software Requirements Specification for the Kenya National Electronic

Community Health Information System (eCHIS)
Restock (CHA- 0 0 1 0 1
CHV)
Dispensing stock 1 1 0 0 1
(CHV-HH)
Disposal of stock 0 0 0 0 1
(expiry,
damage etc.)

Monitor stock 0 0 1 0 1
levels (CHA)
Monitor stock 0 0 1 0 0
levels (CHV)
Return stock 0 0 0 0 0
(CHV-CHA)
Return stock 0 0 0 0 0
(CHA-Facility)
Surveillance 80.00% 20.00% 0.00% 20.00% 100.00%
CHV notifies 1 1 0 0 1
cases of
notifiable
diseases/
conditions
through the
eCHIS to the
CHA
CHV reports PH 1 0 0 1 1
events through
the eCHIS to
the CHA
CHA can run 1 0 0 0 1
through a
workflow to
validate reports
of PH events
eCHIS has 0 0 0 0 1
outbound
API to send
information to
a dedicated
surveillance
system

Software Requirements Specification for the Kenya National Electronic / 80

Community Health Information System (eCHIS)
SCDSC can get 1 0 0 0 1
notifications
on PH events
reported and
validate
Messaging 100.00% 80.00% 20.00% 0.00% 100.00%
eCHIS allows 1 1 1 0 1
user to
configure and
broadcast
messages to
CHVs at any
level in the
organizational
hierarchy
eCHIS 1 1 0 0 1
automatically
sends targeted
messages to
clients based
on their specific
characteristics
e.g. defaulting a
clinic visit
eCHIS allows 1 1 0 0 1
user to
configure and
broadcast
messages to
clients at any
level in the
organizational
hierarchy
eCHIS should 1 1 0 0 1
allow for the
scheduling of
untargeted
client messages

81 / Software Requirements Specification for the Kenya National Electronic

Community Health Information System (eCHIS)
eCHIS should 1 0 0 0 1
be able to send
structured
messages to
clients and
through a pre-
configured
workflow
facilitate live
interaction
Reporting 100.00% 100.00% 0.00% 40.00% 100.00%

Configure and 1 1 0 1 1
run a client list
report based on
client attributes
(bound to a
definite period)
Filter a client 1 1 0 1 1
list report
based on client
attributes and
organizational
hierarchy levels
Configure and 1 1 0 0 1
run a CHV list
report based on
CHV attributes
(bound to a
definite period)
Filter a CHV 1 1 0 1 1
list report
based on CHV
attributes and
organizational
hierarchy levels
Configure and 1 1 0 1 1
run a client
summary based
on aggregation
functions on
client attributes
(bound to a
definite period)

Software Requirements Specification for the Kenya National Electronic / 82

Community Health Information System (eCHIS)
Disaggregate a 1 1 0 0 1
client summary
based on client
attributes and
organizational
hierarchy levels
Collate selected 1 1 0 0 1
client
summaries into
a single service
statistic report
Configure and 1 1 0 0 1
run a CHV
summary based
on aggregation
functions on CHV
attributes (bound
to a definite
period)
Disaggregate a 1 1 0 0 1
CHV summary
based on CHV
attributes and
organizational
hierarchy levels
Collate selected 1 1 0 0 1
CHV summaries
into a single
service statistic
report
Offline Support 1 1 1 1 1
Test for ability 1 1 1 1 1
to work in
conditions
with slow or no
connectivity
(offline data
collection)
AVERAGE 80.32% 70.32% 33.19% 38.39% 91.05%
SCORE:
FUNCTIONAL
Source Code 100% 100% 0% 100% 100%
Licensing

83 / Software Requirements Specification for the Kenya National Electronic

Community Health Information System (eCHIS)
Access source 1 1 0 1 1
code from a
public repository

Audit trail 100% 100% 100% 0% 100%

Audit trail available 1 1 1 0 1
Security 100% 20% 100% 40% 100%
User passwords 1 0 1 0 1
are salted and
hashed
Data in transit 1 1 1 0 1
is encrypted
using 256 bit
encryption(TLS/
SSL)
Access to system 1 0 1 0 1
server is secured
using PKI
Server is behind a 1 0 1 1 1
hardware/software
firewall
Database is 1 0 1 1 1
secured by
username and
password
Backup and 100.00% 66.67% 100.00% 0.00% 100.00%
Disaster Recovery
Ability to do 1 1 1 0 1
schedule and
maintain backups
Ability to restore 1 1 1 0 1
backups
The system 1 0 1 0 1
should provide for
redundancy and
failover
Interoperability 50.00% 50.00% 50.00% 0.00% 50.00%
Data standard 0 1 0 0 0
to support data
exchange - HL7
and related
Integration with 1 0 1 0 1
DHIS2

Software Requirements Specification for the Kenya National Electronic / 84

Community Health Information System (eCHIS)
Performance and 100.00% 0.00% 0.00% 0.00% 100.00%
Scalability
There are 1 0 0 0 1
established
procedures and
tools for
performance and
stress testing
AVERAGE SCORE: 91.67% 56.11% 58.33% 23.33% 91.67%
NONFUNCTIONAL
AVERAGE SCORE 85.18% 64.23% 43.97% 31.94% 91.32%

85 / Software Requirements Specification for the Kenya National Electronic

Community Health Information System (eCHIS)
List Of Contributors
No. Name Section
1 Dr. Salim Hussein Department of Primary Health Care
2 Dr. Joseph Siteinei Directorate of Health Policy,
Research Monitoring and Evaluation
3 Dr. Ayub Manya Monitoring, Evaluation and Research-
Head
4 Dr. Maureen Kimani Division of Community Health - Head
5 Onesmus Kamau Division of Health Informatics
6 Dr. Wesley Oghera Division of Health Informatics

7 Nancy Amayo Division of Health Informatics

8 Sophia Karanja Division of Health Informatics
9 Diana Kamar Division of Health Informatics
10 John Wanyungu Division of Community Health
11 Jeremiah Mumo Division of Health Informatics

12 Joshua Githinji Division of Community Health

13 Aisha Timmy Division of Community Health

14 Treazar Ogumbo HRH - Afya House

15 Joyline Korir Division of Community Health

16 Ken Mwenda Division of Community Health

17 Josephine Ayaga MOH - DNCH

18 Eric Nderitu MOH - ICT

19 Priscilla Mithamo MOH - ICT

20 Samuel Cheburet Division of Health Informatics

21 Dr. Nyagah Lilly Division of M and E
22 Rose Muthee Division of M and E

23 Dr. Phillip Ngere DDSR

24 Caroline Maina DDSR
25 Benjamin Mutugi KEMSA
26 Samuel Mwangi KMTC

27 Francis Mogire CHEW - Kiambu County

28 Enock Makori Community Focal Person - Kiambu
County

29 Ambrose Kimaiyo MOH - Health IT/ICT

No. Name Section

30 Dickson Kirathe MOH - DHP

31 Elvis Kirui MOH - M&E

32 Linet Okoth LVCT
33 Dianne Thakura Living Goods
34 Ruth Ngechu Living Goods
35 Peter Maina Living Goods
Kamonde
36 Kevin Korir Living Goods
37 Robert Ouko Living Goods
38 Danielson Kennedy In-Supply Health
39 Rachael Wanjiru Living Goods
40 Dorothy Anjuri Red Cross Kenya Society

41 Emmanuel Nyachoke Living Goods

42 Georgine Mbeki Living Goods
43 Lesley Githinji Living Goods
44 Michael Korir Medic Mobile
45 Simon Mbae Medic Mobile
46 George Oele AMREF
47 Aloise Gikunda AMREF
48 Danielle Ressler LWALA
 M I N I S T R Y O F H E A LT H

Division of Community Health Services

Ministry of Health Headquarters

P.O. Box 30016-00100
Nairobi, Kenya.
Website: https://www.health.go.ke/