-*

REPUBLIC OF UGANDA
MINISTRY OF HEALTH

GUIDELINES FOR THE

IMPLEMENTATION OF THE
ELECTRONIC MEDICAL RECORDS SYSTEM

DIGITALIZATION OF HEALTH FACILITY OPERATIONS

CLINICAL, ADMINISTRATION & FINANCIAL

JANUARY, 2024

1
DOCUMENT REVIEWS AND APPROVALS

Version Owner Author Publish Date

1 Ministry of Health Division of Health 18/09/2024

Information
Management

ii
Table of Contents

Foreword vi
Preface vii
Acknowledgement viii
Abbreviations and Acronyms ix
Key Definitions x
1.0 Introduction 1
1.1 Background 1
1.2 Goal 2
1.3 Purpose 2
1.4 General Objective 2
1.5 Specific Objectives 2
1.6 Scope 2
1.7 Methodology 3
1.8 Guiding Principles Used to Develop this Document 3
1.9 Policy, Reference Guidelines and International Standards 3
1.10 Revision and Updates 4
2.0 User Requirements, Design and Development 4
2.1 Overall Architecture 4
2.2 Personas/Actors of EMRS 4
2.3 System Functions 6
2.4 Design Process 7
2.4.1 EMRS Design Principles 8
2.5 EMRS Development Process 9
2.6 System Testing 10
2.7 EMRS Upgrades 11
2.8 EMRS Branding 11
3.1 Implementing EMRS 12
3.1.1 Public Sector Pre-Implementation Requirements. 12
3.1.2 Private Sector Pre-Implementation Requirements. 13

iii
 3.2 EMRS Deployment Phase. 13
3.2.1 Health Facility EMRS Work Plan 13
3.2.2 EMRS Deployment 13
3.2.2.1 Local Area Network and Software Configuration and Installation 14
3.2.2.2 EMRS Deployment End User Training 14
3.3 EMRS Post-Implementation Support 18
3.3.1 Continuous Capacity Building and Mentorship 18
3.3.2 Escalation of System Issues. 19
3.4 Transitioning from Other EMRS to MoH Recommended EMRS 20
3.5 EMRS Change Management 21
4.0 Data Management & Reporting 23
4.1 EMRS Data Management 23
4.2 EMRS Reporting 25
4.3 Private Sector EMRS Specific Requirements 27
5.0 Governance Framework 29
5.1 EMRS Implementation Arrangements 30
6.0 Monitoring and Evaluating the Guidelines 35
6.1 Implementation Guideline Use Monitoring 35
6.2 EMRS Deployment Monitoring 36
6.3 Evaluating the EMRS 38
6.4 Dissemination and Adoption of the Guidelines 39
Appendix A: Readiness Assessment 40
Appendix B: Hospital Walkthrough and ICT Assessment Tool 42
Appendix C: Sample Training Schedule 44
Appendix D: Sample EMRS Deployment Budget 46
Appendix E: EMRS Rollout Checklist 47
Appendix F: Standard Operating Procedure for EMR System Downtime 53
Appendix G: EMRS Support Structure 59
Appendix H: System Change Request Form 61
Appendix I: EMRS Guidelines Use Monitoring Framework 63
Appendix J: EMRS Deployment Monitoring Framework 64

iv
Appendix K: EMRS Evaluation Framework 67

v
Acknowledgement

The Ministry of Health expresses its profound gratitude to all divisions, departments and programs,
members of the Health Information Innovation and Research Technical Working Group who
contributed technical inputs leading to the successful completion of this document. Special
appreciation goes to the staff within the Division of Health Information Management (DHIM),
Information Communication Technology (ICT) Section and the Clinical Services Department for
the overall guidance to ensure that the guidelines are aligned with the Health Information and Digital
Health Strategic Plan 2020/21-2024/25 and the Ministry of Health Strategic Plan 2020/21-2024/25.

I acknowledge and thank all development and implementing partners that provided financial and
technical support for this process, specifically CDC, USAID, METS, SITES and the University of
Warwick. DHIM is grateful for all the support, sacrifice and contribution invested in the successful
development of these guidelines.

Finally, the Ministry of Health is grateful to the Local Governments including health facilities and
all those institutions and individuals who have not been specifically mentioned above, but who
directly or indirectly contributed to the successful development and finalization of these EMRS
implementation guidelines.

..................................................................

Mr. Paul Mbaka

Assistant Commissioner Health Services

Division of Health Information Management

viii
Abbreviations and Acronyms

BPR Business Processes Re-Engineering

BUHIC Build Uganda's Health Workers ICT Capacity

DHIS2 District Health Information Software version 2

ELMIS Electronic Logistic Management Information Systems

EMR Electronic Medical Record

EMRS Electronic Medical Record System

ERP Enterprise Resource planning

HL7 Health Level 7

HMIS Health Management Information System

HW Health Worker

ICD International Classification of Diseases

ICT Information and Communication Technology

LAN Local Area Network

M&E Monitoring and Evaluation

SDP Service Delivery Point

SMS Short Message System

SNOMED CT Systematized Nomenclature of Medicine - Clinical Terms

SOP Standard Operating Procedure

SRS System Requirements Specification

ix
 Key Definitions

Term Definition

Business Process Re-engineering (BPR) A business management strategy focusing on the analysis
and design of workflows, and business processes within an
organization.

Electronic Medical Record (EMR) An electronic record of health-related information on an

individual that can be created, gathered, managed, and
consulted by authorized clinicians and staff within one
health care organization.

Electronic Medical Records System A single system or collection of integrated systems that
(EMRS) automate both clinical and administrative processes in the
health facility settings.

Functional requirement A requirement that describes in detail the programmatic or

project needs and/or requested behavior of a system or
component. It specifies what the finished system or
component is expected to do and how a user shall interact
with it.

Health Facility Refers to Dispensary, Health Center, Hospital, Clinic etc.

Health Level 7 (HL7) A flexible standard by which various health care systems
communicate with each other; it is typically used for
transmission of patient level data.

International Classification of Diseases A statistical classification system used to assign diagnostic

(ICD) and procedural codes in order to produce coded data for
statistical analysis, epidemiology, reimbursement and
resource allocation.

Interoperability Ability for a system to securely communicate and exchange

data in an accurate, reliable, and meaningful way with
another information system so that the clinical or
operational purpose and meaning of the data are preserved
and unaltered.

Management Information System (MIS) A computer-based system that provides managers with the
tools to organize, evaluate and efficiently manage
departments within an organization.

Non-functional requirement A requirement that specifies criteria that can be used to

judge the operation of a system, rather than specific
behaviors.

x
1.0 Introduction

1.1 Background

The Ministry of Health (MoH) is committed to improving the application of digital health
technologies to facilitate the attainment of its overall objective of delivering high-quality health
services to all citizens. This aligns with the call of Uganda Vision 2040 and the National
Development Plan (NDP) III 2020/21 – 2024/25 which require sectors to adopt Information
Communication Technologies (ICTs) to optimize service delivery.

The Ministry of Health has prioritised digital health interventions as laid out in the Ministry of Health
Strategic Plan 2020/21 - 2024/25 (HSP). The plan advocates for “Acceleration of health research,
innovation and technology development” as a means of improving health service delivery. This has
further been detailed in the Uganda Health Information and Digital Health Strategic Plan 2020/2021
- 2024/2025. The vision of the strategic plan is a health sector in Uganda driven by evidence and
leveraging digital health to improve efficiency in service delivery.

Digitising health facility operations is aimed at reducing the burden of reporting stemming from the
use of paper-based tools and subsequent data quality issues. Significant improvements in health
service delivery has been reported in health facilities utilising the Electronic Medical Records
System (EMRS). The main achievements registered so far are reduced reporting burden and
improved data quality.

However, the processes related to implementation such as service workflow re-engineering,

functionalization of health analytics, meaningful information exchange, and governance of EMRS
have been mostly undefined to date. As Uganda continues on her journey to implement EMRS
nationwide, there is a need for implementation guidelines to direct operationalization and support
the achievement of intended results.

1
1.2 Goal

Health facility planning and operations driven by evidence, leveraging digital health solutions to
improve health service delivery.

1.3 Purpose

The guidelines seek to establish an effective, transparent and accountable framework for the
implementation of the Electronic Medical Records System.

1.4 General Objective

To standardize the processes and implementation of the Electronic Medical Records System in the
health sector.

1.5 Specific Objectives

1. Formulate and functionalise an appropriate governance framework for the implementation of

EMRS.

2. Define and standardise the processes for introducing, scaling, transitioning and sustaining the
EMRS.

3. To define the minimum functional and nonfunctional requirements for specific digital tools and
systems in health facilities.
4. Ensure interoperability of the EMRS with other Ministry of Health data systems to facilitate
efficient referral, commodity tracking, reporting and surveillance.
5. Establish appropriate change management strategies to foster the use of the EMRS.

1.6 Scope

All health service delivery points within the health facilities in both the public and private sectors shall
follow these guidelines and procedures in their operations. These guidelines are intended for the
following audiences:

a. The Ministry of Health Departments and Programs

b. Local Government

2
 c. Public and Private Health Facilities
d. Facility Health Workers
e. Technology and Implementing Partners
f. Development Partners and Donors/Funders
g. Researchers
h. All other Relevant stakeholders

1.7 Methodology

A highly consultative approach was used in the development of the EMRS guidelines. Stakeholders
from various entities such as the Ministry of Health (MoH), Local Governments (LGs),
Development Partners, Technology and Implementing Partners, Academia and other members of
the Health Information Innovation and Research Technical Working Group (HIIRE TWG)
supported the generation of a draft which was reviewed and later validated.

The validated guidelines were endorsed by the Ministry of Health’s HIIRE TWG and the Senior
Management Committee (SMC), and approved by Top Management for implementation within the
health sector.

1.8 Guiding Principles Used to Develop this Document

1. Client Centered
2. Equity
3. Privacy and Integrity
4. Efficiency
5. Transparency and Accountability

1.9 Policy, Reference Guidelines and International Standards

These guidelines are premised on the following existing frameworks;

❖ The National Health Policy (NHP) III

❖ Ministry of Health Strategic Plan 2021/2025
❖ Uganda Health Information and Digital Health Strategic Plan 2020/21 - 2024/2025
❖ Uganda Digital Health Enterprise Architecture, Standards and Knowledge Guidelines

3
1.10 Revision and Updates

These guidelines shall be reviewed and any proposed changes documented annually to maintain
relevance and/or responsiveness to an evolving healthcare ecosystem and context. Relevant sections
that shall need to be added to the document shall follow the standard MoH approval processes. A
new version number and date of approved updates shall be documented.

2.0 User Requirements, Design and Development

This section details the process for the generation of user requirements that inform the system
functionality and subsequent iterative system development and/or enhancement. For the Public
Sector, the Division of Health Information Management (DHIM) shall coordinate the user
requirements, system design and development process and provide overall guidance during this
phase with oversight from the HIIRE TWG. During this phase, the MoH ICT Unit shall be engaged
to assess and guide on the system hosting requirements as well as other technical inputs such as
security. For the Private Sector, health facility ownership will guide the user requirements, design
and development process.

2.1 Overall Architecture

The EMRS is part of the wider Uganda Health Information System architecture ensuring
the interoperability of the EMRS with other Ministry of Health data systems to facilitate referrals,
commodity tracking, reporting, analytics, and surveillance (including linkage to the eHMIS).

The EMRS fits within the overall enterprise architecture under the applications segment as further
described in the Uganda Digital Health Enterprise Architecture, Standards and Knowledge Products
Guidelines.

2.2 Personas/Actors of EMRS

The delivery and management of health services at the health facility level involves multiple actors,
who play different but complementary roles. The following subsections describe the characteristics
and roles of each of the personas of the EMRS.

a) Client

4
The client is the primary recipient of health services at the health facility level. Health facility clients
fall into one or more cohorts defined by sex, age group, pregnancy status, health and nutrition status
et cetera. These characteristics should be taken into account when enrolling health facility clients
into specific health facility services. Health facility services include but are not limited to casualty
and emergency, clinical consultation, radiology, laboratory, pharmacy and dispensary, mortuary,
outpatient services including but not limited to immunization, maternal and child health, dental, eye,
counseling, family planning, health promotion, nutrition, Antenatal Care (ANC), Postnatal care
(PNC), and inpatient services but not limited to maternity, intensive care, among others. Caregivers
of clients receiving health services are also included in this group. The clients shall be registered
within the EMRS and services delivered to them tracked longitudinally.

b) Health Workers

The Health Worker is the primary agent of health service delivery at the health facility level. Their
main role is to provide health facility services while passively collecting key program data. Health
Workers shall utilize the EMRS to deliver quality health services and capture and use data for
operational decisions such as tracking commodities, defaulters and referrals to higher-level health
facilities. Health Workers include Clinicians, Nurses, Records managers, Radiologist, Laboratory
Technicians, Surgeons, Consultants, and Supply Chain In charges among others.

c) Health Facility Supervisors

Health Facility Supervisors are responsible for managing the delivery of health services at the health
facility level. Health facility supervisors oversee service delivery points within their area of
assignment and provide support to other health workers. The involvement in the day-to-day health
facility operations is supervisory and aimed at assessing and promoting service quality. Other tasks
include training, mentoring and coaching health workers and also performing routine health data
quality checks. Health facility supervisors shall access EMRS dashboards and supervisor views
constituting key information necessary to provide insights on how best they can supervise and
support the health workers.

5
 d) Local Government

The Local Government shall be responsible for the management of healthcare programs at the local
government level. The Local Government shall lead and coordinate the implementation of the EMRS
at local government level (districts and cities). The Local Government shall access the EMRS
through dashboards and reports for routine performance monitoring and evaluation, program
monitoring, support supervision and reporting to enable evidence-based decisions.

e) Ministry of Health

The national-level team at the Ministry of Health is charged with the responsibility of system
administration, technical programming aspects, supervision, resource mobilization, and planning.
Escalation of any issue concerning the EMRS shall follow the application hierarchy right from the
health workers at the health facility level to the national level.

2.3 System Functions

The software requirements and system functionality documentation shall be developed and
maintained as the Electronic Medical Records System Software Requirements Specification
document. The document shall be updated quarterly based on user feedback, design sessions, User
Acceptance Tests, logged system issues, user requirements review, consultative engagements with
key stakeholders, following Health Management Information System (HMIS) revision among
others.

Overall, the patient workflows within the EMRS shall follow the Uganda Clinical Guidelines.

Below is a summary of key functionalities as a minimum and that shall further be customized
according to the user requirements documentation.

Patient Registration and ● Registration of patients or clients.

Management ● Managing new and already existing patients in the system.
● Assign a unique identifier to new patients.

6
 Client Referral ● Internal referrals within the facility from one unit to another or
amongst the different consultants with-in the same unit.
● Referrals to facilities below the level of the referring facility, at the
same grade or a grade above.

Stock Management ● Commodity dispensing, adjustments and stock status monitoring in

stores, pharmacy, laboratory and wards.

Disease Surveillance ● Reporting suspected cases of notifiable diseases and events of

public health interest.

Analytics and Reporting ● Generating real-time case-based and aggregate client reports and
analytics to drive evidence-based decision-making.

Data & Process Validation ● Validation rules that shall enable the verification of data and
processes to ensure adherence to set standards before a user is able
to save a record.
● Management of patient records.

Decision Support ● Functionality to ensure that the health worker’s decision-making

capability is improved.

System administration and ● Configuring the system with organizational hierarchies, users, user

Security roles, commodities and security mechanisms.

● Should be interoperable with approved Ministries, Department and
Agencies information systems.
● Ensure health data protection, privacy and confidentiality.

2.4 Design Process

A strong system design is crucial to the development and functionalization of the EMRS to produce
real-time quality information for patient information management and decision-making. Through
the design process, developers and programme teams understand the healthcare processes, persona
user stories, unique data use requirements for each persona, the different healthcare workflows and
7
how they are delivered at the health facility level, the way users interface with the EMRS, and how
to continue to build for interoperability.

The human-centred design approach and analytical development methods will be used to understand
the user requirements while considering the bottlenecks and challenges that users face.

The human-centred design takes a bottom-up approach and focuses on understanding an

intervention's users or stakeholders. It seeks to understand how people do their work, how they
perceive their health services, and how they experience challenges and may envision solutions.

While the analytical approach focuses on breaking down the process into the elements necessary to
solve it and takes a top-down approach. An analytical approach will often require an expert mindset
(consultant/technology firm) to collect information about how the intervention works in a linear,
causal process. The outcome is information-oriented, resulting in a user requirements document or
report.

Therefore a participatory approach that allows users and stakeholders to contribute to the design and
development process will be used in a blended manner, that is to say, utilizing both human-centered
design and the analytical approach.

For the Public Sector, the Division of Health Information Management will lead the design and
development process working with other relevant partners, departments and programs such as the
Clinical Services Department, Maternal and Child Health Department, Expanded Programme on
Immunization, AIDS Control Program, Tuberculosis and Leprosy Program, Environmental Health
Department, Malaria Control Division, Nutrition Division among others.

For the Private Sector, health facility ownership will lead the design and development process
following established guidelines and standard operating procedures.

2.4.1 EMRS Design Principles

The EMRS design principles shall guide every step throughout the EMRS design and development
processes.

1. Usability: Design and develop the EMRS application in a way that shall minimize the
complexity for end users interacting with it.
2. Scalability: Should be capable of continuing to perform as the EMRS scales both vertically
and horizontally over time in terms of enrolling end-users, data management and use.

8
 3. Availability: Ensure both system and data is available to digital health applications and their
end users whenever needed (within the bounds of confidentiality) to guarantee client safety
and business continuity.
4. Interoperability: Foster interoperability of the EMRS with other relevant digital health
systems as per the digital health enterprise architecture.
5. Collaboration: Adopt a governance approach that includes multi-sectoral stakeholders in
the decision-making and management of EMRS design and development.
6. Open standards: Use internationally accepted standards that promote interoperability for
data, workflows, and technology.
7. Data quality and integrity: Follow accepted data standards and create measures to uphold
the integrity and reliability of data captured, processed or stored by the EMRS.
8. Ethics: Equity, safe use, data privacy and protection: These principles are vital for ensuring
the social inclusion of the EMRS.
9. Access control: Enforce mechanisms to restrict access to both the system and data stored
within the system.

2.5 EMRS Development Process

The development process will follow a streamlined Software Development Life Cycle (SDLC). A
Systems Requirements Specifications (SRS) document detailing both functional and non-functional
requirements will be developed in line with the user requirements gathered.

The SRS document will then inform the Systems Design Document (SDD). Both documents will be
presented to the stakeholders including target user departments or units for validation and sign-off.

The System development process will, where possible, employ locally available resources to reduce
reliance on external sources. It is, however, recognized that some desired technical skills and
capacity may not be available within the Ministry of Health, sponsoring or implementing
organisation or in the country and will be outsourced according to the Government of Uganda
procurement guidelines where applicable or otherwise according to the sponsoring entity’s
procurement guidelines.

To ensure a user-centered design approach and quality software, the Agile development model will
be applied during the development process with extensive consultation and interaction with the end
users. Key stakeholders will be engaged during these steps from the Ministry of Health relevant

9
departments and other line state agencies including but not limited to the Ministry of Information
Communication Technology and National Guidance (MoICT&NG), National Information
Technology Authority Uganda (NITAU), National Identification and Registration Authority
(NIRA), Uganda Bureau of Statistics, and Local Governments to ensure interoperability and that
other key requirements for the system are addressed.

2.6 System Testing

The EMRS testing will comprise both internal system tests that will focus on technical aspects of
the system and User Acceptance Testing (UATs) where feedback on the developed/improved system
shall be solicited.

a) Internal system tests

The Internal system tests will focus on technical aspects that will ensure system performance such
as integration testing, unit testing, and functional and non-functional testing among others. These
tests will be conducted by the technology partners, the MoH ICT Section and DHIM. A report on
internal tests will be developed, maintained and signed off by the Ministry of Health (DHIM).

b) User Acceptance Testing

User Acceptance Testing (UAT) will be part of the software development process that focuses on
real-world testing by the intended end users.

UATs will be conducted for every software developed, revised workflows, new features,
integrations, system enhancements or upgrades.

A UAT report will be compiled and shared with relevant stakeholders through existing governance
structures, the report will incorporate feedback from users and the proposed system improvements.

A meeting with relevant stakeholders will be held to discuss the report and a road map to address
the issues raised will be agreed upon.

The User Acceptance Testing report will be signed off once all the raised issues are addressed and
validated by the user departments. For the Public Sector, the Division of Health Information
Management will be responsible for the sign-off of UATs while for the Private Sector, the ownership
of the health facilities will sign off the UTAs.

10
2.7 EMRS Upgrades
The EMRS shall be updated from time to time to ensure enhanced system performance. System
upgrades shall be categorised into major upgrades and minor upgrades.
All upgrades shall be tested comprehensively to minimise system downtime. For major upgrades,
the EMRS shall be upgraded annually to the most stable update available and the version shall be
updated in the software inventory system.
All health facilities implementing EMRS shall have the same version of the system and therefore a
mechanism shall be put in place to ensure uniformity in rolling out updates for EMRS across all
health facilities.

2.8 EMRS Branding

Public Sector EMRS shall be branded to have a national outlook consistent with the national
information systems for purposes of ownership.

The EMRS shall have the following branding;

1. The Uganda Emblem and Flag

2. White Background
3. Link to the Ministry of Health’s Health Information System Privacy Notice
4. MoH Contact Details
a. Website - https://www.health.go.ug
b. Email - hmissupport@health.go.ug
c. Address - Ministry of Health, P.o.Box 7272, Plot 6 Lourdel Road, Kampala - Uganda

The office in charge of communication at the Ministry of Health shall guide further on the EMRS
branding to ensure a national outlook.

EMRS in the Private Sector shall be branded following the guidance on branding by the ownership
of the health facilities where the EMRS is to be deployed.

11
3.1 Implementing EMRS

3.1.1 Public Sector Pre-Implementation Requirements.

This section guides the requirements and activities that need to be done before implementation
activities start.

1. EMRS National Rollout Roadmap

The rollout of EMRS shall be aligned to the National Digitization Roadmap developed and

updated by the Ministry of Health. The roadmap details areas of priority, timelines, rollout

plan and geographical coverage.

2. Implementation Approval by MoH

Implementation of the EMRS in the public sector shall be approved by the Ministry of Health to
ensure alignment with the National Digitization Roadmap.

The Ministry of Health is responsible for providing overall coordination of all parties involved
in the process, including but not limited to taking the lead in inception, reviewing progress,
continuing implementation efforts, and monitoring compliance with all EMRS to be
implemented. All parties intending to implement EMRS should seek guidance and approval from
MoH before engaging Local Governments. As part of the approval process, the implementation
plan shall be presented to the EMRS Working Group responsible for coordinating the
implementation of the EMRS.

Private sector implementers of the EMRS shall be guided by the MoH on how best to achieve
alignment with the National Digitization Roadmap and for further technical support.

3. Readiness Assessment

A readiness assessment using the Readiness Assessment Tool (Appendix A) for the proposed
health facilities shall be conducted to check the readiness of the facility to support the rollout of
the EMRS. This shall check if resources are planned to support the rollout of the EMR in the
selected health facility and this includes but is not limited to; finances, human resources,
hardware, and software. A detailed hospital walk-through focused on the Information
Communication Technology (ICT) needs for the health facility utilising the ICT assessment

12
 template in Appendix B shall also be conducted to quantify the ICT gaps and inform the
budgeting process.
4. National Trainer of Trainers
A national team shall be comprehensively trained following an updated standard training guide
on the use and support of the EMRS before the rollout of the EMRS at the national and sub-
national levels. This is to ensure there are adequate human resources at the national level to
support further training and mentorship at the health facilities that have adopted the use of the
EMRS. A comprehensive database of national trainers shall be maintained and updated regularly
to include trainers from the health facility levels to avoid attrition of the Trainer of Trainers.

3.1.2 Private Sector Pre-Implementation Requirements.

Private Sector pre-implementation requirements shall be guided by the ownership of the health
facilities which shall also determine the choice of EMR to be deployed.

3.2 EMRS Deployment Phase.

3.2.1 Health Facility EMRS Work Plan

The health facility with the support of the MoH and partners shall develop a detailed EMRS
deployment work plan and budget following the sample training schedule in Appendix C and
sample EMRS deployment budget in Appendix D detailing how the health facility shall roll out and
coordinate the deployment of the EMRS within the health facility.

The work plan shall clearly indicate when the deployment shall be scheduled, the resources to
support the deployment, and key persons leading on activities among others. The plan shall also
include how the entire exercise shall be supervised and supported including pre and post-deployment
support.

3.2.2 EMRS Deployment

In this phase, the EMRS shall be introduced to the National and Regional Referral Hospital
Management, Local Government leadership and Health Facility Teams Leadership . This stage shall
include training of health teams and the deployment of the EMRS shall strictly observe 100%
digitisation of the health facility for efficient health service delivery, reporting, and accountability.

13
3.2.2.1 Local Area Network and Software Configuration and Installation

Deployment of the EMRS shall include the following installation of the computing
infrastructure including the Local Area Network (LAN) and computing devices like servers,
deploying and configuring the new EMRS software in its target environment and EMRS
software acceptance testing.

EMRS deployment end-user training shall not commence until all the needed computing
infrastructure i.e LAN has been installed within the health facility and tested for
functionality.

The computing infrastructure installations shall be signed off the health facility in charge
once successful tests have been conducted with a test report shared with the health facility in
charge and the Ministry of Health IT Section or the respective private sector health facility
ownership.

Once the computing infrastructures have been installed, the next step is the configuration and
installation of the EMRS software. The installation shall include server and software
installation. This shall be done before the commencement of the EMRS deployment training.

The health facility IT staff shall be trained on how to manage the installed computing
infrastructure before handover of the same to the health facility administration.

3.2.2.2 EMRS Deployment End User Training

The EMRS deployment training shall include the following: basic computer training, EMRS
software end-user training and ICT governance training for managers. This shall follow the
processes below;

a) Entry Engagements

National and Sub-national level leadership engagement to introduce the program, seek
political support, and discuss resource mobilization shall be held. The leadership to be
targeted at the various levels shall include but not be limited to the following Hospital
Directors, CAO, RDC, LC5, DHO, DISO, DPC, District Biostats, and Health Assistants
among others that shall apply to all Local Governments. This shall apply to similar structures
for cities and municipal councils. Where regional and local government level partners exist
within the Regions and Local Governments, these shall be part of the engagements as well.

14
 For the Private Sector, engagements shall be guided by the health facility ownership.

b) Device Custody and Management Plan:

Information Communication Technology devices procured by MoH or partners shall be

declared to the national and sub-national leadership before hand over to the facilities. At the
national and regional levels, the inventory shall be captured within the health facility
inventory list. While at the local government level, the ICT equipment shall be captured
within the local government and health facility inventory lists for purposes of tracking.

All devices shall be engraved to enable easy identification and tracking, the engravement
numbers for the ICT equipment shall be captured within the inventory lists.

The ICT devices handed over shall be distributed according to the Health Facility EMRS
Digitisation Plan and ensure all service points are well equipped. The devices shall also be
redistributed depending on the need of the health facilities to ensure rational use of the ICT
equipment.

Sensitive equipment like servers shall be maintained by ICT National level teams, Hospital
Information Technology staff and Local Government ICT staff. Any other cadre shall seek
clearance for example Partner ICT staff shall seek clearance from the health facility
leadership.

Both private and public health facilities shall plan and budget for maintenance costs
associated with the continued use of the EMRS.

c) On-Boarding Training

1. Pre -Training/Preparation Phase

The training team shall ensure that all requirements detailed in the EMRS deployment
checklist (Appendix E) are met ahead of the training.

2. Regional and Local Government Level Training of Trainers

The trainer of trainers and supervisor training shall follow the updated standard
training guide. Participants to be trained as ToTs and supervisors shall include, IT
Officers, Biostatisticians, Medical Records Officers, Clinicians and Partner

15
 Representatives. ToTs and Supervisors shall be trained on the EMRS for a minimum
of five (5) days following the training guide and training scheduled (Appendix C).

3. Training of Health Workers

The health workers’ training shall follow the established training guide that shall
entail all the service areas in EMRS appropriate for the level of the health facility.
Health workers shall be trained on service areas for a minimum of five (05) days and
on the digital aspect for a minimum of eight (08) days in class not exceeding 65 health
workers each.

The eight days training on digital aspects shall include the basic ICT training aligned
to the Build Uganda's Health Workers ICT Capacity (BUHIC) curriculum. The ICT
basic training is aimed at providing basic computer skills needed for users to use a
computer. Where possible, the ICT basic training shall be conducted prior to the
training of health workers on EMRS by the national or local government level teams.

The training on health workers shall be conducted on a training instance that shall be
easily distinguishable from the production or live system. Health Workers shall be
availed with training credentials to the training instance once training on the digital
aspect commences.

Health workers shall be subjected to a mandatory test before and after training on the
EMRS to assess the extent of knowledge transfer. A minimum of 70% shall be
obtained by a health worker before successful completion of the training.

Failure by the health workers to obtain the mandatory 70%, the health workers shall
be re-trained on the service areas and the EMRS and subjected to a second test.

Failure by a health worker to obtain the mandatory 70% pass mark on a second
attempt, the health worker shall be monitored closely and mentored during their use
of the EMRS within the health facility.

16
d) On-Boarding to the Production EMRS

1. Configuration and Health Workers Activation in the Production/Live Instance

Upon completion of training of health workers or targeted system users, their

accounts shall be configured with their user profiles in the production/live instance
of the EMRS and their training accounts deactivated in the demo/training system.

2. Tooling and Reintegration into the Facility Structure

The trained users shall be equipped with the necessary work tools including but not
limited to the digital job aids, EMRS user guide, links to important resources like the
Ministry of Health E-Learning platform among others for reference purposes and
further support.

The trained health workers or targeted system users shall switch to the use of the
EMRS within five (5) days after the successful completion of the EMRS training.

After the five (5) days of transition, the HMIS manual registers shall only be used as
a backup mechanism in the event the EMRS is non-functional as per the Standard
Operating Procedures of the EMRS Downtime as indicated in Appendix F. Once the
EMRS functionality has been restored, all the data captured using the manual
registers shall be transferred as the Standard Operating Procedure.

e) Deployment Phase Closure and Signoff

Once the training has been concluded or aborted, the health facility leadership shall be briefed
on the progress, findings and recommendations of the deployment phase.

An activity report shall be generated by the technical team supporting the EMRS deployment
and signed off by the health facility in-charge or any other person delegated by the health
facility in-charge. A copy shall be kept at the health facility and another shared at the national
level by the team lead within 7 days of the closure of the activity.

All accountabilities shall be retired and outstanding issues settled within 14 days after exit
from the local government or health facility.

17
3.3 EMRS Post-Implementation Support

3.3.1 Continuous Capacity Building and Mentorship

This section includes modalities of conducting continuous capacity building and mentorship post-
deployment of EMRS. Relevant courses targeted at building health workers' capacity post-EMRS
deployment training shall be uploaded on the Ministry of Health eLearning platform to enable virtual
training. This shall be accessed https://elearning.health.go.ug/. The portal shall be kept with updated
EMRS training courses like basic ICT skills courses i.e. Build Uganda's Health Workers ICT
Capacity (BUHIC) and EMRS courses for health workers to access online for purposes of refresher
training. This shall be part of the sustainability plan to ensure the building of health workers'
capacity.

The online training portal shall be supplemented by the following activities;

a) Support Supervision and Mentorship

A team from the National Level guided by reports generated from the EMRS shall make
support supervision visits to targeted EMRS-implementing health facilities quarterly. Intern,
implementing health facilities shall conduct quarterly support supervision to targeted health
facilities under their supervision.

The Ministry of Health Standard HMIS Support Supervision tool shall be used for this
purpose and findings thereafter discussed with all stakeholders with clear action points and
well-defined timelines.

The health facility administration shall routinely perform support supervision and give
feedback on areas of improvement and areas of good performance.

b) Quarterly Performance Review Meetings

The EMRS performance review meeting shall be integrated into the local government and
health facility quarterly performance review meetings to review the general performance of
facilities, EMRS performance, uptake, data quality gaps identification, and develop
improvement plans.

c) Refresher Training
1. One full day monthly training for a minimum of three months consecutively after the
18
 initial deployment of the EMRS shall be conducted and thereafter a minimum of three
quarterly refreshers shall be held. The training shall majorly be informed by the
system changes, knowledge gaps identified in terms of system utilization, staff
changes, poor performance as guided by the monthly report, complex workflows and
modules as identified by the Health Workers (System Users) or their supervisors, and
new modifications in existing workflows among others.
2. Thereafter yearly refresher training is recommended to address any area of interest
as may be pointed out by the national and subnational levels or informed by changes
to the system.
3. Training on any new or updated workflow or system shall be scheduled on a need
basis.
d) Health Information System Support Teams

Further capacity building of the health facility staff shall be built through the Health
Information Systems (HIS) support teams. The HIS Support is a multi-sectoral
approach to harness resources relating to infrastructure, human resources, and overall
capacity for the proper functioning of digital health solutions.

Health facilities shall leverage support from both the government and partners to
address their capacity gaps. The HIS Support teams shall be linked to the national
level through the levels of support.

3.3.2 Escalation of System Issues.

System users shall utilise the support structures in place and communication channels to escalate
any system issue, downtime or feature that is needed for continued improvement of the EMRS. The
support structure is 5 tier (0-4) to support the various levels of EMRS implementation with the
escalation procedures in Appendix G.
The tier three (3), expert technical support at the national level shall be engaged through official
communication channels established and elaborated below;

1) MoH Call Center

The call center shall be the first point of contact for all help requests that originate from the
end users of the EMRS at different levels. In the event that the call center team is unable to

19
 resolve the issue, they shall be responsible for escalating tickets to the respective support
teams. Issues shall be logged in the call center Customer Relationship Management (CRM)
software for tracking and management until they are resolved. The current available toll-free
number is 0800-100-066.
2) Help Desk
The Ministry of Health help desk shall be utilised to support the help desk functions of
logging and tracking the EMRS end-user requests that come in, delegation to a responsible
person for resolution, escalation of complex issues and managing the feedback to the end
users. The Ministry of Health help desk shall be accessed through the
URL:https://helpdesk.health.go.ug/
3) Emails
EMRS end users shall request help or inquire about EMRS through the official HIS support
email address is hmissupport@health.go.ug
4) Health Information System Community of Practice
HIS Community of Practice online platform accessed through https://cop.health.go.ug/ shall
be utilised to solve common system issues. Some of the system user issues could have been
solved in the past and the solutions exist on the HIS Community of Practice webpages. Any
new system issue shall be posted and solutions proposed by stakeholders to facilitate
knowledge sharing and promote practical solutions.

Other information channels like phone calls, and social media like WhatsApp and Text messages
shall be utilised to escalate system issues for users to be able to get the needed support.

3.4 Transitioning from Other EMRS to MoH Recommended EMRS

Transitioning of health facilities using the organization or disease-specific or non-comprehensive
EMRS shall follow sections 3.1 to 3.2 with the following emphasis;

1) Local Government engagement meetings shall involve the affected health facility
supervisors and any partners supporting the specific EMRS to be discontinued.
2) An inventory of the already issued devices used in the rollout of the EMRS to be discontinued
shall be handed over to the local government management for inclusion in the local
government inventory and tracking.

20
 3) The health facilities shall work with technical teams on the ground to ensure the database
from the EMRS to be discontinued is backed up and a copy kept by the health facility on an
encrypted device. A copy of the same shall be kept at the Ministry of Health data centre as a
backup mechanism.
4) Private health facilities shall ensure that the data from the EMRS to be discontinued is backed
up and safely kept following the ICT policy or backup procedures in place.
5) In some cases, with clearance from the Ministry of Health for public health facilities, the old
EMRS may be kept functional and operational depending on the unique need the EMRS is
servicing i.e it may be specialized and may not warrant replacement within a specific clinic
of speciality. In that case, two EMRS shall be utilized within the health facilities until further
guided by the Ministry of Health.

3.5 EMRS Change Management

This guideline ensures standardized methods; processes and procedures are used for all changes,
and maintain proper balance between the need for change and the potential detrimental impact of
changes. Effective change management is very crucial in Health facility settings for controlling
changes to EMRS and other supporting systems within the live Health facility environment.

Changes to all information processing facilities, systems, software, or procedure shall be strictly
controlled according to formal change management procedures.
1. Change Initiation: All system changes shall be initiated by filling in the system change
request form (Appendix H) form, which shall be signed by the respective heads of
department.
2. Change Authorization: Authorization for any changes, whether urgent or not, shall be given
by the head of the Division of Health Information Management. If satisfied that the reason
for the change is sound and that there is no adverse effect as a result of the change.
3. Testing of Changes: All testing shall be done from a test environment. No change shall be
applied to the live/production environment without having been tested in the test
environment.
4. Change approval: The concerned user departments shall check the system to see whether
the results produced are as expected and a user acceptance testing (UAT) form shall be signed
off.
21
5. Change Scheduling: To minimize disruption to the normal working operations of the health
facility, no changes shall be effected in the system during normal working hours unless
absolutely necessary. All changes shall be scheduled during weekends, public holidays or
after business working hours.
6. Change Communication: All planned system changes shall be communicated in advance
to the concerned parties to minimize business disruption and inconveniences. For
the avoidance of doubt, no scheduled system change should be effected in the live EMRS
during a busy business cycle.
7. Change Recovery and Safety Measures: Before effecting any change in the production
environment, a backup on a clearly labelled storage media shall be taken and kept for good.
In the event that the change made produces unexpected results, the backup taken before the
change was effected has to be used to restore the system to the point before the change.
8. Change Documentation and Tracking: All system changes, whether approved or not shall
be documented and filed. The documentation shall include a duly completed and signed-off
“change request form”, the test results and any other comments/documents used.

22
4.0 Data Management & Reporting

Effective data management for EMRS is critical to ensure data accuracy, security, privacy, and
accessibility while maintaining compliance with legal and regulatory standards.

Compliance with the Personal Data Protection and Privacy Act 2019 is critical as the EMRS collects
individual-level data which is classified as personal data according to the law. To ensure compliance
with the law, the Uganda Health Data Protection, Privacy and Confidentiality Guidelines shall be
followed while implementing the EMRS in the health facilities. Below is further guidance on
specific activities;

4.1 EMRS Data Management

1. Data Entry and Standardization

a. All data entered into the EMRS shall on a minimum conform to the primary
national Health Management Information System (HMIS) tools approved by the
Ministry of Health.
b. Health facilities shall implement regular audits and training programs for users to
ensure accurate and timely data entry.
2. Data Security
a. The EMRS shall implement a Role-Based Access Control (RBAC) to limit access to sensitive
data based on job roles and responsibilities.
b. User credentials (username and password) shall not be shared with any other person
besides the account holder.
c. Regular security assessments shall be conducted periodically to identify and mitigate
vulnerabilities in the system.
d. Only health facility staff shall have access to the individual level data or records for
clients within their health facility. The district and national levels shall have access
to system reports with the exception of the time during responses to public health
emergencies like outbreaks for surveillance purposes. However, only access to
relevant data shall be granted.
e. Official or approved emails shall be used to share EMRS reports to avoid disclosing
sensitive information.

23
 f. Section 3 of the Ministry of Health ICT Policy Guidelines shall be followed to ensure
system and data security.
3. Data Backup and Recovery
a. Automated backups for the EMRS at the health facilities shall be established with
offsite storage for disaster recovery. The backups shall be conducted on a daily basis
during the off-peak hours to minimise system interruption.
b. All system and data backups shall be tested on a monthly basis to ensure they are
functional.
c. The data backup, recovery and disaster recovery plan shall follow Section 9 Ministry
of Health ICT Policy Guidelines.
4. Data Sharing
a. All data requests shall be addressed to the Director General Ministry of Health.
b. The Uganda Health Data Access, Sharing and Use Guidelines shall be followed to ensure
data is shared securely while maintaining data protection, privacy and confidentiality.
c. Any health data requests for research and innovation purposes shall require administrative
clearance by the Ministry of Health and this shall follow the Uganda Health Data Access,
Sharing and Use Guidelines.
5. Data Retention, Archiving and Disposal
a. The data retention, archiving and disposal shall follow Section 5.6 of the Uganda
Health Data Protection, Privacy and Confidentiality Guidelines.
6. Data Audit Trails
a. All EMRS shall maintain detailed audit logs that record all system activities,
including data access, modifications, and deletions. Logs shall be tamper-proof and
regularly reviewed.
b. For purposes of accountability, mechanisms shall be implemented to track and
address unauthorized access or suspicious activity identified in audit logs.
7. Incident Management and Response
a. A data breach shall be reported to the Personal Data Protection Office and the
Ministry of Health immediately after becoming aware of it.
b. Management of data security breaches shall be in accordance with Section 5.7 of
the Uganda Health Data Protection, Privacy and Confidentiality Guidelines.

24
 c. Further incident management and response shall be handled according to Section
10.0 of the Ministry of Health ICT Policy Guidelines.
8. Health Information Exchange
a. EMRS shall ensure compliance to the Uganda Health Information Exchange and
Interoperability Guidelines for seamless data sharing across the healthcare providers.
By adhering to established standards and guidelines, the EMRS guarantees that
patient information is exchanged accurately, efficiently, and confidentially. This
commitment to the health information exchange standards as stated in the Uganda
Digital Health Enterprise Architecture, Standards and Knowledge Guidelines not
only enhances coordination and continuity of care but also promotes trust and
reliability in the management of electronic medical records.
b. The EMRS implemented within the health facilities shall be integrated with DHIS2
for seemingless reporting. The health facilities shall adhere to the reporting timelines
as detailed in Section 4.3 of these guidelines below.
c. To achieve a single source of truth, the EMRS shall integrate with the National Health
Information Exchange (NHIE) Registries i.e National Health Facility Registry,
National Health Products Registry, National Health Workers Registry and the
National Client Registry.

4.2 EMRS Reporting

The reporting requirements shall be based on the approved national HMIS tools. The reports shall
be for purposes of synthesis, monitoring of usage and functionality. The data shall be pushed from
the EMRS to the electronic Health Management Information System (Uganda eHMIS/DHIS2) on a
monthly basis following the schedule below;

1. All data captured in the EMRS shall be synchronised or pushed automatically daily to the
EMRS servers based at the health facilities..

2. The HMIS reports generated from the EMRS shall be pushed to Uganda eHMIS/DHIS2
every 7th of every month following.

25
 3. Local Government and health facility level health managers shall review and validate the
pushed EMRS datasets in Uganda eHMIS/DHIS2 from 8th - 15th of every month for
purposes of ensuring completeness and accuracy.

4. Uganda eHMIS/DHIS2 shall be locked for entry or validations of data past 15th of every
month to allow for analysis of consistent data for the reporting period.

All the synchronised data shall be accessed through the Uganda eHMIS/DHIS2. For real time data
from the EMRS, dashboards (https://emrs-dashboards.health.go.ug/) shall be utilized to access
indicator performance for various administrations at various levels.

Annual, Quarterly and Monthly performance reports indicating various indicators as per the National
HMIS reporting format shall be produced and accessed within Uganda eHMIS/DHIS2. The expected
reports with the frequency to be submitted by the EMRS is detailed in the Table 02 below;

Table 02: National HMIS Reports to be submitted through the EMRS

Sn Report Code Report Description Frequency

1 HMIS 033b Weekly Epidemiological Surveillance Weekly

2 HMIS 097b VHT/ICCM Quarterly Report Quarterly

3 HMIS 097c VHT/ICCM Monthly Report Monthly

4 HMIS 104 NTDS MDA Implementation Report Bi-Annual

5 HMIS 105 OPD Monthly Report Monthly

6 HMIS 105a Specialized Outpatient monthly report Monthly

7 HMIS 105B.1 Child Immunization Addendum Report Monthly

8 HMIS 105C Palliative Care Monthly Report Monthly

9 HMIS 106a HIV Quarterly Report Quarterly

10 HMIS 107a Sub County Annual Population Projection Report Annual

11 HMIS 107c Health Facility Human Resource Inventory Annual

26
 12 HMIS 107 Health Unit Population and Annual Report Annual

13 HMIS 108a Specialised Inpatient Monthly Report Monthly

14 HMIS 108 IPD Monthly Report Monthly

15 HMIS 110 District Health Facility WASH Report Quarterly

16 HMIS 127b Visceral Leishmaniasis Inpatient Monthly Report Monthly

17 HMIS 128b Visceral Leishmaniasis Outpatient Monthly Report Monthly

18 HMIS MAL 002 Malaria Vector Monthly Reporting Form Monthly

4.3 Private Sector EMRS Specific Requirements

Implementation of the EMRS in the private sector shall enhance the efficiency and quality of
healthcare services, streamline patient record management and offer private healthcare providers
with a robust, secure, and user-friendly platform to access and update patient information in near
real-time. The EMRS shall not only reduce administrative burdens like reporting but also facilitate
better coordination and continuity of care, ultimately leading to improved patient outcomes.

Below are the specific requirements besides the general guidance on EMRS implementation to be
adhered to by the Private Sector.

1. Certification of the Private Sector EMRS by the Ministry of Health to ensure system security,
and compliance to standards i.e. Uganda Digital Health Enterprise Architecture, Standards
and Knowledge Guidelines, Uganda Clinical Guidelines and other relevant guidelines.
2. The certified EMRS shall integrate with the national electronic Health Management
Information System (eHMIS)/DHIS2 to facilitate mandatory reporting into the national
reporting system. The certified EMRS shall also integrate with the national core health
registries i.e. National Health Facility Registry, National Client Registry, National Health
Productions Registry and National Health Workers Registry.
3. The certified EMRS shall produce at a minimum the national HMIS reports to enable
reporting to the national eHMIS/DHIS2 as outlined in Section 4.2 of the guidelines.
27
4. All Private Sector certified EMRS shall submit birth and death notifications to the national
reporting system (electronic Health Information Management System/DHIS2)
5. The Private Sector certified EMRS shall submit client-level data to the Ministry of Health
Data central reporting system (i.e. eHMIS/DHIS2 and National Data Warehouse) during
public health emergencies such as pandemics, outbreaks, or other public health emergencies.
The Government of Uganda retains the authority to request or sanction a copy of the health
data by the EMR for purposes of epidemiological and reporting purposes.
6. EMRS and its health data shall not be hosted on the cloud outside of Uganda without
the approval of the Personal Data Protection Office and the National Information Technology
Authority Uganda (NITAU). This shall be done in accordance with the Data Protection and
Privacy Act 2019.
7. All processed health data by the EMRS shall be owned by the Government of Uganda but
held in trust by the data controller in this case the ownership of the health facility.
8. The health facility clients reserve the right to access their health data or records at no cost
besides printing costs.
9. Health data access by Non-Government third parties shall be authorized by the Ministry of
Health and shall follow the Uganda Health Data Access, Sharing and Use Guidelines.
10. The EMRS health data shall be used for research and innovation purposes in accordance with
the National Guidelines for Research involving Humans as Research Participants. Ministry
of Health shall provide administrative clearance for the use of the EMRS health data for
research and innovation.
11. Compliance to the guidelines by the private sector health facilities shall be monitored through
health facility self-assessments every quarter submitted to the Ministry of Health. External
assessment shall be conducted annually by the Ministry of Health.

28
5.0 Governance Framework

The Governance of EMRS shall follow the existing governance and management structures at the
national and decentralized levels, as summarized in Figure 3.

Technical oversight is the mandate of the Division of Health Information Management (DHIM)
under the Department of Planning, Financing and Policy which guides and coordinates all
stakeholders involved in health data collection, processing and storage. This function is similarly
decentralized at the Local Government level, as summarized in Figure 3. The main task of the Health
Information Innovation and Research Technical Working Group (HIIRE TWG) is reviewing and
advising on Health Information System (HIS) and Digital Health policy-related and strategic related
issues from the user departments and other stakeholders.

The Ministry of Health (MoH) has Technical Working Groups (TWGs) in its governance and
management structures which act as advisory committees to Departments and the Senior
Management Committee. The TWGs serve as structures to deliberate on, review and advise on
policy, strategic and technical issues within the Ministry of Health.

Figure 3: Governance Structure

The Health Data Collaborative, a subcommittee of the HIIRE TWG shall be charged with the
coordination of the implementation of the EMRS. Specifically, under the Health Data Collaborative
(HDC) Subcommittee, the Health Sector Digitization Coordination Working Group supports the
HDC in the coordination of the EMRS implementation within the country. The day to day operations
29
shall be handled under the EMR Implementation Technical Working Group of the Health Sector
Digitization Coordination Working Group.

All the other HIIRE TWG subcommittees like the Data Management Subcommittee and Digital
Health Subcommittees shall provide technical input towards the implementation of the EMRS in the
country.

The Digitisation Steering Committee chaired by the Permanent Secretary of the Ministry of Health
has been established as a special committee to ensure fast tracking of the implementation of the
EMRS and other digital initiatives in the country.

Governance of the Private Sector EMR implementation shall be under the leadership of the
ownership of the health facilities and will interface with the Governance Structure illustrated in
Figure 3 through the HIIRE TWG.

5.1 EMRS Implementation Arrangements

EMRS implementation shall require that all the responsibilities of all stakeholders are spelt out in
order to streamline the implementation arrangements and strengthen the governance framework.

The table below spells out the different responsibilities of different entries at different levels.

30
SN Entity Level Responsibility

1 Top Management National ● Strategic leadership, guidance and oversight.

● Approval of EMRS for use in the health sector.
● Monitoring and Supervision of EMRS
implementation

2 Senior National ● Strategic leadership, guidance and oversight.

Management ● Endorsement of EMRS for use in the health sector.
Committee (SMC) ● Monitoring and Supervision of EMRS
implementation

3 Health National ● Approve EMRS for piloting

Information, ● Recommend EMRS to SMC for full scaleup
Innovation and ● Monitoring and Supervision of EMRS
Research (HIIRE) implementation
Technical ● Give technical guidance and quality assurance
Working Group ● Ensure the EMRS conform to set standards
● and guidelines.
● Review and recommend developed EMRS standards,
and guidelines for approval by the SMC.

4 MoH/Planning, National ● Coordinate implementation of EMRS

Finance, Policy ● Recommend EMRS for pilot and use following a
Department technical evaluation.
● Prioritize areas of implementation in line with the
Digital Health and Health Information Strategic Plan
● Coordinate and ensure EMRS data and system
management with the support of stakeholders.
● Quality assurance of EMRS
● Coordinating integration of EMRS with other system
● Authorizing changes and modification to the EMRS
● Supervision of implementation teams.
● Develop standards and guidelines for EMRS
implementation
● Coordinate capacity building programmes with
stakeholders on EMRS
● Coordinate the development and implementation of a
sustainability plan for EMRS with stakeholders.

5 MoH/IT National ● Provide hosting infrastructure for EMRS

● Security of EMRS and hosting environment
● Ensure data and EMRS backup
● Recommend hosting strategies for EMRS
● Coordinate with external entities in case of
outsourced hosting for the EMRS

31
 ● Coordinating and Managing access to EMRS hosting
environments/backend.
● Coordinating and Managing access to EMRS

6 MoH/User National ● Participate in the EMRS requirements specification

Departments ● Programmatic guidance on functionality of the EMRS
● Participate and sign off on user acceptance tests for
EMRS
● Resource mobilization and funding for the EMRS

7 Ministry of National ● Strategic leadership and guidance.

ICT&NG ● Advise and guide on technologies for EMRS
technologies.
● Monitoring and Supervision of digital health
initiatives.
● Resource mobilisation and funding for EMRS
implementation
● Assess the gaps in HR capacity.

8 Ministry of Energy National ● Strategic leadership and guidance on energy

and Mineral solutions.
Development ● Advise and guide on clean energy to power EMRS.
● Plan and ensure that health facilities are connected to
the national electrical grid.
● Monitoring and Supervision of power sources for
health facilities.
● Resource mobilization and funding for power
solutions for EMRS implementation
● Guide and advise on power backup solutions for the
EMRS implementation.

9 Partners National/ ● Technical assistance for implementation of EMRS

Local ● Resource mobilization and funding for
Government implementation of EMRS
● Capacity building of MoH and Local governments on
management and use of the EMRS.
● Participate in the development of standards and
guidelines for the EMRS implementation.
● Support monitoring and evaluation of the EMRS.
● Participate in the EMRS implementation roadmap.
● Support the optimisation, implementation and
adaptation of the EMRS

32
10 Local District/Cities/ ● Lead the implementation of the EMRS at the local
Governments Municipality/ government level
Subcounty ● Coordination of implementation at local government
level (districts and cities) with partners
● Supervision of implementation teams
● Participate and sign off on EMRS user acceptance
tests.
● Implement the EMRS sustainability plan with the
support of MoH and stakeholders.
● Resource mobilization.
● Performance Monitoring and evaluation

11 Health facilities Regional/ ● Ensure periodic data quality assurance and

District/Cities/ assessment.
Municipality/ ● Support health workers on the use of EMRS
Subcounty ● Conduct capacity building of the health workers on
EMRS
● Generate list of users of EMRS for approval by the
Department Planning, Financing and Policy.
● Supervision of health workers within
their catchment area

12 National ● Guiding on EMRS implementation modalities

Digitization ● Coordinate EMRS stakeholders.
Coordination ● Joint planning, monitoring and evaluation of the
EMRS
Working Group ● Make recommendations on the development and
implementation of the EMRS.

13 EMR ● Discuss the implementation experiences for the

Implementation different EMRS implementing health facilities.
Technical ● Resolve operational challenges affecting EMRS
Working Group implementation.
● Document EMRS issues, new system requirements
and features and share with the Division of Health
Information Management.
● Review EMRS performance reports for implementing
health facilities.
● Make recommendations on the development and
implementation of the EMRS.

14 Technology National ● Development of EMRS and other functional-based

developers health tools based on user requirements.
● Testing of EMRS instances and training of users
● Conduct installation and customisation of EMRS in
health facilities

33
 ● Coordination of EMRS upgrade, maintenance and
scalability
● Ensure user friendly, reliable and robust EMRS
environments.

15 Private sector National ● Software and hardware provision to support EMRS

implementation.
● Training and support services
● Financial investment
● Research, innovation and development
● Market competition and improvement
● Comply with EMRS national guidelines

16 Academia National ● Research

● Training
● Monitoring and Evaluation
● Come up with Innovations to address EMRS
implementation challenges.

34
6.0 Monitoring and Evaluating the Guidelines
Monitoring and Evaluation is vital to ensure the successful implementation and smooth operation of
EMRS. As part of Monitoring and Evaluation, quality assurance exercise shall run throughout the
life cycle of the EMRS implementation, especially during installation and configuration of the
EMRS infrastructure (software and hardware), training of staff on EMRS and deployment of the
EMRS to ensure compliance with the national EMRS implementation guidelines. Compliance with
the guidelines shall be monitored through health facility self-assessments every quarter submitted to
the Ministry of Health. External assessment shall be conducted annually by the Ministry of Health.
Furthermore, it is necessary to track and evaluate the implementation and functioning of the system
in order to understand how well the implementation objectives have been met and the effect of
EMRS on the day-to-day health facility operations.

6.1 Implementation Guideline Use Monitoring

Monitoring the use of the Guidelines for Implementing the EMRS shall be based on a specific
framework designed to track compliance and effectiveness. Important to note is that dissemination
and training on the use of the guidelines is a key requirement before monitoring its use can become
a practical reality. Therefore, the guidelines shall be monitored using three major parameters,
namely, dissemination, training, and compliance. These are described further below and shall be
tracked and assessed to measure guideline use. The guideline-use monitoring framework consists of
the parameters or components, key monitoring questions, result statements, indicators, and means
of verification.

● Dissemination: Refers to broadcasting the guidelines to a target audience through printed or

electronic media such as print, electronic documents, or other forms of media as appropriate.
Copies of the guidelines shall be printed and distributed at national and sub-national levels.
The electronic copy of the guideline shall be uploaded on the Ministry of Health Knowledge
Management Portal for public access and consumption.
● Training: Refers to orienting and/or sensitizing key stakeholders on the key components of
the guideline document including its value and their roles and responsibilities to ensure
awareness and accelerate compliance.

35
 ● Compliance: Refers to the state of implementing the EMRS in accordance with established
guidelines or standards, or the process of becoming so (compliant).

Refer to Appendix I for a detailed Guideline-Use Monitoring Framework.

6.2 EMRS Deployment Monitoring

The EMRS implementation is anchored within the overall Uganda Health Information and Digital
Health Monitoring and Evaluation Framework. Notably, it is critical to continue monitoring EMRS
deployment nationwide to ensure that the software is working as it should, every activity is
implemented as planned, and that external factors are not affecting the potential effectiveness of the
EMRS intervention.

Findings from deployment monitoring activities shall be synthesized, disseminated, and remedial
action taken to address identified challenges. This shall ensure optimization of EMRS
implementation across board and foster successful evaluation efforts. Consequently, four (4) key
parameters of EMRS deployment monitoring shall be considered, namely, functionality, stability,
fidelity, and quality. They are described further below and shall be tracked and assessed to ensure
that the intervention is “doing things right”.

Similar to guideline-use monitoring, the EMRS deployment monitoring framework shall consist of
parameters or components, key monitoring questions, result statements, indicators, and means of
verification.

● Functionality: Refers to the degree to which EMRS provides functions that meet stated and
implied needs when used under specified conditions, or the ability of EMRS to support the
desired intervention. For instance, the desired functionality of the EMRS application based
on agreed upon user requirements. Monitoring functionality shall be done pre- and post-
deployment to ensure adequate system functionality at all times. Pre-deployment monitoring
shall entail testing and providing feedback on various aspects including but not limited to
skip patterns, validation checks, form schedules, form content, user interface design, data
export/import functionality, data accuracy, and dashboard calculations. Post-deployment
and/or at a later maturity stage (i.e., where the EMRS applications have been fully designed
and only enhancements are required to meet evolving policy changes and information needs),
basic system functionality monitoring shall be conducted before introducing the EMRS to
36
 new users (e.g., a different cadre of health workers) and new geographic areas that might
pose different levels of connectivity or when using new technologies.

● Stability: Refers to the likelihood that EMRS functions shall not change or fail during use
or the ability of EMRS to remain functional under both normal and anticipated peak
conditions for data loads. Monitoring stability shall be done concurrently with functionality
monitoring both pre- and post-deployment. Initial (pre-deployment) system stability
monitoring shall be conducted during quality assurance testing sessions before the EMRS is
declared ready for deployment (field-ready). Post-deployment, stability shall be monitored
to mitigate any events that may result in improper delivery of the EMRS intervention such
as unexpected crash or stop, slow response times especially during peak times or when
overloaded, and any erratic performance hindering management and use of EMRS.
Considering that the EMRS heavily relies on physical (non-cloud-based) servers based at
the health facilities for operation, server outage shall be monitored. Considering stability is
a critical aspect to ensure successful implementation of EMRS intervention, continued
stability monitoring processes shall be automated and systems configured accordingly to
enable proactive and timely reactive response.
● Fidelity: Refers to a measure of whether or not an intervention is delivered as intended in
terms of technical and user perspectives. For instance, the technical fidelity of EMRS (i.e.,
functionality and stability) and the enabling environment such as any external barriers that
might cause it not to function as intended, and compliance of EMRS end-users to stipulated
data use and system administration standard operating procedures. Monitoring fidelity of
EMRS intervention shall occur throughout implementation with the required level of effort
gradually decreasing depending on the time it takes to identify and resolve issues. Standard
monitoring procedures and reporting mechanisms shall be established and automated to aid
timely decision-making.
● Quality: Refers to the measure of excellence, value, conformance to specifications,
conformance to requirements, fitness for purpose and ability to meet or exceed expectations.
For instance, the standards related to capabilities of EMRS end-users and content of the
inputs used for the programmatic interventions that eEMRS is designed to deliver such as
algorithms for decision support, data collection forms, and reports. This content should be of
37
 the highest quality possible informed by existing practice, literature and formative research
in the local context to increase effectiveness of the EMRS intervention. EMRS quality
monitoring shall focus on ensuring (a) data quality and regularity by checking for outliers of
non-compliant users; and (b) quality of content to be delivered is as expected and inline with
existing standards and appropriate for participating communities.

Refer to Appendix J for a detailed EMRS Deployment Monitoring Framework.

6.3 Evaluating the EMRS

The evaluation shall entail any measures that shall be taken and analysis performed to assess;

a) The interaction of users and/or the health system with the EMRS intervention and strategies
b) Changes attributable to the implementation of EMRS.

Any commissioned evaluations focused on EMRS shall be designed to ensure assessment and
evidence generation on its usability, effectiveness, value for money and affordability at the very
least, depending on the degree of maturity i.e, early or middle or late stage. The following evaluation
components shall constitute the EMRS evaluation framework in addition to the evaluation types:

● Feasibility: Assess whether EMRS works as intended in various contexts and health facility
levels across Uganda.
● Usability: Assess whether the EMRS is used as intended.
● Effectiveness: Assess whether the EMRS achieves the intended results in an uncontrolled
(non-research) setting.
● Implementation research: Assess the uptake, institutionalization, and sustainability of
EMRS in Uganda, including policies and practices.

Depending on EMRS degree of maturity and evidence needs, several evaluation types categorized
as formative or summative may be commissioned and/or conducted.

● Formative evaluations: Studies aimed at informing the design and development of effective
intervention strategies conducted before or during implementation of an intervention.
● Summative evaluations: Studies conducted at the end or a certain phase of the intervention
to determine the extent to which expected outcomes have been achieved.

38
Refer to Appendix K for a high-level EMRS Evaluation Framework.

6.4 Dissemination and Adoption of the Guidelines

The framework shall guide the collection of information regarding the implementation of the EMRS
to facilitate reporting, feedback, and dissemination.

a) Dissemination and adoption of the guidelines

The EMRS implementation Guidelines shall be disseminated for adoption through:

1. Presentation of the guidelines to stakeholders.

2. Posting of the guidelines on the MoH websites and the electronic Library (Knowledge
Management Portal) for access by the stakeholders.
3. Organising quarterly workshops to train stakeholders and innovators.
4. Leveraging on EMRS activities like refresher training etc to disseminate the guidelines.

39
 Appendix A: Readiness Assessment

No. Service Area e.g. No. of Is service Challenges Support No. Trained Next
Registration, Eye Available Area Using the Faced in that Given / Mentored Steps
Clinic, etc. Computers System Area
(Yes/No)

Server Assessment
Type HDD RAM CPU OS Service Support Warranty Life Version Virtuali Softwa Is the
(Windo Provider period period span of OS zation re server
ws, Techn applic connected
Linux) ology ations to a
Backup
SN system?

Server Purpose
Manufacturer

Hardware Model

Support Level
Operating System
OS Version
RAM
Type

# of Processors
CPU
Cores/Processor

Speed

40
 Type, Speed, Size, and # of Disks
Total Raw Size (GB)

Internal Disk Useable Size (GB)

Disk Configuration

Free Space (GB)

Type, Speed, Size, and # of Disks
Total Raw Size (GB)

External Disk Useable Size (GB)

Disk Configuration

Free Space (GB)

Installed Software

41
 Appendix B: Hospital Walkthrough and ICT Assessment Tool

Introduction

Health Facility Details

Local Government
Sub-county/Division
Village/Ward
Name Facility
Facility Level
Name of Health Facility Director/MS
Tel No. of Incharge
Name of IT or Data person
Tel No. of Contact person

Delete all the information in read and

replace with information in that
hospital

Service Points

Information on Point of service areas ( inpatient,

administration,wards service areas etc)
How many
No of
POINT OF Description health No. of
No. of Does area existing
SERVICE of work area workers functiona No. of No. of
beds requisition function No. of No. of
(Ward name eg (e.g are l existing existing Required
(where commoditie al Required Required
Male surgical consultation, supposed Laptops Tablets in Compute
applicabl s from store desktop Laptops Tablets
ward, Pead administrativ to sit/work in the the room rs
e) (Yes/No) s in the
ward) e) in this room
room
room

42
 Wireless LAN Assessment

Wireless/ LAN Access Points

Location LAN Existing No. of Status Indoor Outdoor Comments No. of
(Department, Availability Wireless Users (Existing) (Existing) Switches
Section, ) Points Needed

43
 Appendix C: Sample Training Schedule
TENTATIVE TRAINING SCHEDULE REGIONAL REFERRAL

1. MEETING ADMINISTRATORS {
2. MEETING HEAD OF UNITS
3. TRAINING OPD MODULES
4. TRAINING IPD MODULES
5. RADIOLOGY
6. LAB
7. PHARMACY
8. STORES
9. MORGUE
Date Module Department Time

• Patient Management Records & Nurses 2:00Pm

• Nursing (administering
treatment
etc)
Consultation Doctors & Clinicians Two sessions
Morning from 09:00Am – 12:00pm

Afternoon Session from

2pm – 4pm
Radiology Radiographer 9:00 am – 12 pm

Lab All Lab Staff Two Sessions

Morning
From 9Am – 12Pm

Afternoon
From 2Pm – 4Pm
• Inpatient & Theatre Doctors Two Sessions
• Ward Management Clinicians Morning
(NICU, Labour Monitoring, Theatre Staff From 9Am – 12Pm
ICU) Nurses
Afternoon
From 2Pm – 4Pm
Pharmacy & Dispensing Pharmacists & Dispensers Two Sessions
Morning
From 9Am – 12Pm

Afternoon
From 2Pm – 4Pm

44
 Supply chain Management All Store Staff Two Sessions
Morning
From 9Am – 12Pm

Afternoon
From 2Pm – 4Pm
Employee Portal (All Staff) All Ward In-Charges Two Sessions
Morning
From 9Am – 12Pm

Afternoon
From 2Pm – 4Pm
Support & Customization Set and Hospital IT and Trainers Two Sessions
Identifying the Focal Person Morning
From 9Am – 12Pm

Afternoon
From 2Pm – 4Pm
Feedback meeting with all the Hospital IT and Trainers 8:30Am
Staffs All Staff

45
 Appendix D: Sample EMRS Deployment Budget

Detailed Budget and Model for Software Deployment for a Single Health Facility

Unit of Frequenc Unit of

Health facility Unit Cost Units Amount
1.9 Measure y Frequency
Project Initiation (Definition of Scope, Team Charter, 175000 2 Persons 1 # of days 350,000
Project plan, Hospital Workflow Workshop, Project Role and
Responsibilities, Computer & Networking Infrastructure
1.9.1 Assessment)
Solution Design (Requirements Gathering, Gather 175000 2 Persons 2 # of days 700,000
Information about end users and Approvers, Price and
Service Lists, Inventories, Services Packaging & Insurance
1.9.2 Categorization)
Staff Training (Front Office and Outpatients Staff Training, 175000 3 Persons 8 # of days 4,200,000
Inpatient Staff Training, Administrative Staff Training,
1.9.3 Management Training)
Implementation (Server Installation & Configuration, End 175000 2 Persons 3 # of days 1,050,000
1.9.4 User Computer Customization, Network Configuration)
1.9.5 Customization & Realization (Template Branding, HR & 175000 3 Persons 5 # of days 2,625,000
User profiles creation, Accounts Customization, Pricing and
Service Packaging, Inventory and Assets Registration,
Insurance Customization)
System Testing (Outpatient Mock Operation, Inpatient 175000 2 Persons 1 # of days 350,000
Mock Operation, Billing and Accounting & Human Resource
1.9.6 optimization)
1.9.7 Project Closure (Sign-off) 175000 2 Persons 1 # of days 350,000
1.9.8 Fuel 5500 190 Kms/Liters 1 1,045,000
1.9.9 Communication 100000 2 Persons 1 # of days 200,000
1.9.14 Subtotal 10,870,000

46
 Appendix E: EMRS Rollout Checklist

No Question RESPONSE

1 MoH EMRS rollout team 1.

2.

3.

2 Local Government

3 Sub County

4 Facility name

5 Level

6 Authority

7 ED/Director/MS/In-charge Name:

Role:

Phone Contact:

8 EMR system used ð Clinic Master

ð eAFYA

Description

The EMRS Rollout planning checklist is intended to aid the trainers in planning for EMRS
implementation. It can be used to plan for the EMR system go-live event and to identify any issues
that need to be addressed beforehand.

Instructions

Keep updating it daily. A copy to be attached as part of the report.

47
 Section Check(☒) Date Comment

1.0 Section 1: Team Debrief and movement ☐

1.1 Discuss the rollout roadmap and movement plan ☐

1.2 Team code of conduct ☐

1.3 Discuss the expected output from the teams (Daily ☐

activity reports)

1.4 Required documents are in place (introduction letter, ☐

attendance forms, printed checklist, infrastructure tool
etc)

2.0 Section 2: Inception

2.1 Engage the hospital Management which includes the ☐

administration, the local government health officials
by calling and sending them an email.

2.2 Hold a meeting with Director/DHO to explain the ☐

rollout and required support

2.2a Get the hospital Organogram, Staff List (Departmental ☐

Staff Lists), Units List (OPD & IPD Units), Hospital
Layout (should this be available), Departmental Heads
Contact information (name, email, tel, designation,
unit) to design training agenda

2.3 Determine the rollout strategy with hospital head ☐

2.4 Set date for demo to management and kick off meeting ☐

2.5 Get Implementing Partner Support List from the ☐

hospital

2.6 Reached out to the district for support (Health ☐

facilities)

48
2.7 Reached out to Implementing Partners for Support ☐

3.0 Section 3: Hospital Walkaround and Assessment ☐

3.1 Identify and document the different service points, ☐

with data points and computers already in place

3.2 LAN/WLAN Coverage (OPD & IPD): ☐20% ☐40% ☐

☐ 60% ☐ 80% ☐100%

3.3 Available power options at the facility: ☐Umeme ☐

☐Solar ☐Generator ☐Others…

3.4 Server/ server room in place and functional ☐

3.5 IT Equipment in place (Computer, laptops) ☐

3.6 Count and document the beds in the wards ☐

3.7 Identify and document the unit stores in the facility ☐

3.8 Identify and document the hospital workflow ☐

3.8 Find out the baselines for all units ☐

3.9 Find out and document the clinic days ☐

3.10 Look at the physical security (Door locks, burglar ☐

proof) and make recommendations

3.11 Evening Team meetings to review the days’ activity ☐

and plan for the next day

4.0 Section 4: Training schedule:

4.1 Work with the focal person to Come up with a training ☐

schedule

49
4.2 Circulate the schedule to the staff by using the staff ☐
communication platform/notice board.

4.3 Set up training room fully loaded with computers

5.0 Section 5: Entry Kick off Meeting

5.1 Set up an EMR implementation kick off meeting ☐

with the Key stakeholders include but are not limited
to: Local Government Health Officials, Hospital
Directors/Medical Superintendents, Hospital
Administrators, Senior Nursing Officers, Records
Personnel, Hospital/Local Government IT Office, a
Store representative and all heads of departments

Key Agenda Items for the meeting include:

identifying a project focal person at the hospital,
Confirmation of equipment delivery and distribution
plan, Scope of system deployment, Proposed
deployment timelines & activity work plan, Roles of
the stakeholders involved and a demo of the system

6.0 Section 6: Basic ICT Skills Training

6.1 Users who need the basic ICT Skills training have been ☐
identified

6.2 Training has been Scheduled ☐

6.3 Training has been carried out ☐

7.0 Section 7: EMR System training ☐

7.1 Users have been trained according to the schedule by ☐

module/cadre.

7.2 Appointments with users who are not always available ☐

at the hospital have been made.

8.0 Section 8: IT Equipment Installation and

distribution/redistribution
50
8.1 Distribution list for the new equipment ☐
(Desktop/laptops) has been made with support from
the hospital administration.

8.2 Desktop/laptop setup in different service points ☐

8.3 Desktop/laptop configuration ☐

8.4 Connect the computers to the network ☐

9.0 Section 9: System setup (get support from IT and

installation team)

9.1 The server room and server have been set up and ☐
configured

9.2 The system has been set up on the Server ☐

9.3 Thin client server has been setup and configuration ☐

(Where applicable)

9.4 Servers have a power backup ☐

10.0 Section 10: Go-Live preparation

10.1 User accounts have been created for all users ☐

10.2 Every user has completed the training necessary to use ☐

the EMRS

10.3 Every user has completed basic computer navigation, ☐

keyboarding, and other applicable training; provide
refresher if necessary

10.4 The practice support team has been trained and is ☐

aware of their roles/functions for go live.

10.5 Every user has a user ID and password, and they ☐

remember them.

10.6 Every user has been assigned the required rights. ☐

51
10.7 Everyone can log on and has the correct privileges. ☐

10.8 The EMR system has been customized ☐ Stores ☐Lab ☐

☐ Radiology

10.9 Data has been entered (Stock, supply categories) ☐

10.10 All service points have the required computers and the ☐
EMRS application can be accessed.

10.11 Communication channels like WhatsApp groups have ☐

been set up where users can be supported from.

11.0 Section 11: Go-Live

11.1 Go-live meeting held with staff to communicate the

change and go-live date

11.2 Units to go live fast have been communicated

12.0 Section 12: Post Go-Live

12.1 User Hand Holding and mentorship on workstations ☐

12.2 EMR System User support ☐

13.0 Section 13: Closure Meeting with HODs

13.1 Shared a report and showing the performance so far. ☐

13.2 Discussed how the HODs are going to support the ☐

users in absence of the MOH team.

52
Appendix F: Standard Operating Procedure for EMR System Downtime

Republic of Uganda
Ministry of Health

Standard Operating Procedure (SOP) for Handling Electronic

Medical Record (EMR) System Downtime
Objective:

This Standard Operating Procedure (SOP) outlines the protocol to be followed by all
health workers when an Electronic Medical Record (EMR) System is down to ensure
continuity of care, patient safety, and data integrity.

Key definitions

● Downtime: Is a period during which production or business processes come to a

halt due to application/ system unavailability, technical glitch, network outage or

natural disaster [Adam Marget et al]

● Uptime: Is a measure of an application/system's availability to its end users

● Downtime procedure: refers to a predefined set of steps that healthcare

organisations follow during system or network downtime.

Types of downtime

Planned vs. Unplanned Downtime

Unplanned downtime (also known as unscheduled downtime) is when a lapse in

operations occurs because of an unplanned machine, network outage, power outage,

53
natural disaster or server error. It’s outside your control and doesn’t abide by the

institution's schedule.

Planned downtime (scheduled downtime) is when you schedule these down periods at a

convenient time to the institution and minimize any negative impact for the users. It’s

scheduled, proactive maintenance that allows you to install upgrades and perform routine

maintenance in order to ensure optimal functionality of machines and services. This can

include replacing old or outdated machine parts, performing regular system updates and

patches, and a wide range of other tasks intended to increase the reliability of services.

Types of Planned Downtime

a) Fixed downtime: This adheres to a set schedule- you determine a specific start

and stop time for maintenance/ recovery to occur.

b) Flexible downtime: Provides for a window of time during which downtime shall

happen, though the exact start time is unknown

Causes of Downtime

There are several causes of downtime. Some of the main causes are explained below:

a) Human Error: Regardless of whether accidental or due to negligence, human

error is one of the most common causes of unplanned downtime.

b) Hardware/Software Failure: Obsolete hardware or software increases the

chances of application failure and system outage.

c) Device Misconfiguration: Device misconfiguration is another major cause of

unplanned downtime.

54
 d) Bugs: Bugs in a server’s operating system can impact its performance as well

as lead to security issues.

e) Cybersecurity Threats: Cyber threats, including sophisticated ransomware and

phishing attacks, are one of the most dangerous and common causes of IT

downtime.

f) Natural Disasters: Natural disasters, such as hurricanes, floods and earthquakes,

can disrupt power supply and communication or even damage hardware.

How to Prepare for EMRS Downtime

1. Be prepared for EMRS downtime (Be expectant)

2. Train for downtime from the beginning.
3. Create an incidence response downtime plan
4. Practice for an outage
5. Designate a person to document during EMRS downtime
6. Run backups and store backups in different locations
7. Know who to contact in the event of a data breach

Scope:

This SOP applies to all health facilities with an EMR system for patient/client care
management.

Responsibilities:

1. Clinical Staff:
a. Adheres to downtime procedures and documentation protocols outlined in
this SOP.
b. Continues to provide patient care using the relevant paper-based processes
and registers during downtime.
c. Communicates effectively with other health workers and patients/clients to
ensure continuity of care.
2. IT Officer/EMRS Focal Person:

55
 a. Monitors system performance and initiates downtime protocols when
necessary.
b. Documents and reports EMR system downtime to the national IT support
team using the relevant ticketing system (EMRS Help Desk) or official
communication channels in place.
c. Coordinates with the national IT support team and vendors to troubleshoot
and resolve downtime issues.
3. Health Facility In charge
a. Oversees the implementation and maintenance of EMR system downtime
procedures.
b. Ensures staff training and readiness for EMR system downtime.
c. Coordinates with national IT support team and EMR system vendors for
technical support and resolution of downtime issues.

Procedure:

1. Initiating Downtime Protocol:

i. Upon identification of an EMR system failure or outage, the IT Officer/EMRS
Focal Person shall assess the situation and determine if downtime
procedures need to be activated.
ii. If downtime procedures are required, the IT Officer/EMRS Focal Person shall
initiate the downtime protocol and notify clinical staff via the designated
communication channels immediately.
2. Notification and Communication:
i. Clinical staff shall be notified immediately of EMR system downtime through
the health facility's designated communication system (e.g., WhatsApp
group, phone call, email, text alerts).
ii. Clear communication shall be provided regarding the expected duration of
downtime and alternative documentation procedures.
3. Transition to Downtime Procedures:
i. Clinical staff shall transition to paper-based Health Management
Information System (HMIS) documentation (registers, forms and reports)
and manual processes for patient/client care during downtime.
ii. HMIS pre-printed paper tools shall be made available at all points of care
for use during downtime.
4. Patient Identification and Safety:

56
 i. Clinical staff shall verify patient identification using standard paper
protocols to ensure patient safety during downtime.
ii. Allergies, medications, and other critical patient information shall be verified
verbally with patients or caregivers during downtime.
5. Documentation and Record Keeping:
i. Clinical staff shall document patient care activities, assessments,
medications, and other relevant information on the HMIS paper-based tools.
ii. Data captured on the paper tool shall be transferred to the EMRS within 24
hours once the system is restored.
6. Continuity of Care:
i. Clinical Staff shall collaborate effectively with the EMRD focal person to
ensure continuity of care and smooth transitions between shifts during
downtime.
ii. Critical patient information shall be communicated verbally during handoffs
and shift changes to ensure seamless care delivery.
7. Monitoring and Resolution:
i. The IT Officer/EMRS Focal Person shall monitor the status of the EMR
system and work with the national IT support staff and vendors to resolve
downtime issues promptly.
ii. Regular updates shall be provided to the clinical staff regarding the progress
of downtime resolution and expected system restoration times.
8. Post-Downtime Review:
i. Following the resolution of EMR system downtime issues, a post-downtime
review shall be conducted to assess the effectiveness of downtime
procedures and identify opportunities for improvement.
ii. Lessons learned from EMR system downtime incidents shall be
documented, and recommendations for system enhancements or staff
training shall be implemented as appropriate.
9. Training:
i. All clinical staff shall receive training on EMR downtime procedures during
orientation and regularly scheduled training sessions.
ii. Updates and refresher training on EMR system downtime procedures shall
be provided as needed to ensure staff readiness and competence.
10. Documentation and Recordkeeping:

57
 i. Documentation of EMR system downtime incidents, including timelines,
actions taken, and resolutions, shall be maintained at the health facility or
using the systems’ issues tracker/ticketing system.
ii. Incident reports and documentation logs shall be reviewed periodically for
quality assurance and compliance purposes.
11. Document Review and Approval:

Version Owner Author Publish Name/Title Signature

Date

1 Ministry of DHIM 12/01/2023 xxx

Health

12. Dissemination:

This SOP shall be disseminated to all EMR system-implementing health facilities and
relevant stakeholders and made accessible through the Ministry of Health’s Knowledge
Management Portal (KMP). A copy shall also be made available on the Health Facilities’
notice boards.

13. Contact the Ministry of Health

Any questions, inquiries or emergencies to raise to the Ministry of Health shall be through
the;
a) The Call Center Toll-Free 0800-100-066
b) E-mail: Email: info@health.go.ug
c) Address: Plot 6, Lourdel Road, Nakasero P.O Box 7272, Kampala
Uganda.
d) Website: www.health.go.ug/

58
 Appendix G: EMRS Support Structure

Support Description Support team & Resources Support needs

Tiers

Tier 0: Users identify issues, retrieve Support team This level shall require self-
support information and attempt support resources to be
Self-help or - End users
to resolve the issue. created, maintained, and
end-user - Peer support
updated to support users.
If they fail to resolve the issue, Resources
they report the issue to tier 1 Tier 1 personnel shall receive
- SOPs
support - User manual and respond to requests
- FAQs through the available
- Community of practice channels.
- Support channels

Tier 1: Support for basic user issues such Support teams Lower-level technical
as solving usage problems and personnel shall be trained to
Basic - Records Assistants
simple user requests that need HIS solve known problems and
technical - Health Information Assistants
team involvement. respond to requests using
support (HIA)
- Medical Records Assistants standard guidelines and
If no solution is available, tier 1
- Data Clerks procedures
personnel escalate incidents to a
higher tier. Resources
- SOPs
- FAQs
- Community of practice
- User manual
- Support channels

Tier 2: Experienced and knowledgeable Technical teams Support personnel with

technicians assess issues and technical working experience
- Regional Referral Biostats
provide solutions for problems and knowledge of the
- Regional Bio-stat
Experienced that cannot be handled by tier 1. solution, not necessarily the
representative
technical - HMIS HSD managers engineers or programmers of
If no solution is available, tier 2
support - District Biostatisticians the solution.
support escalates the incident to
tier 3. - IP HMIS managers

Resources
- SOPs
- Technical and end-user
manuals
- Support channels

59
Tier 3: Highly experienced or Technical teams Support personnel with high
knowledgeable or national technical working
- MoH HMIS Support Team
experts and technicians assess experience, expert knowledge
- HIS support teams
Expert issues and provide solutions for of the solution but may not
- Consultants
technical problems that cannot be handled Resources necessarily be the engineers
support by tier 2. or programmers who
- SOPs designed and created the
They duplicate problems and - Technical manuals solution.
understand possible causes and - HIS Support channels
attempt to provide solutions to the
problem.
If no solution is available, tier 3
support escalates the incident to
tier 4.

Tier 4: This is the highest technical Technical teams Highly skilled product
resource available for problem specialists, and may include
- Consultants
resolution. the creators, chief architects,
Developer Resources or engineers who created the
The technicians attempt to
technical product or solution.
duplicate problems and define - Official emails
support
root causes, using product - HIS Support channels
designs, code, or specifications
and make new fixes.

60
 Appendix H: System Change Request Form

Ministry of Health Information and Communications Technology Section System Change

Request Form

Change Request ID: _________________ Report ID: __________________

Originator/Requester (Name, Position and Contact):

Department/Consultant/Partner:

Problem Statement: Provide a brief

description of the requested change, for
upgrades indicate current and target
builds/versions
Where & When Changed Requested: Date Location Time

Description of Problem: Provide a

detailed description of the problem,
circumstances leading to the requested
change
Supporting Information: Provide
screenshots of an error or printout of an
error in a document / report

Reasons and Justification: Describe

the reason why the change has been
requested and the justification for the
request.
Affected Areas: System / Subsystem / Documentation Affected
According to the Perception of the Workflow Workflow
Requester Affected Affected

61
Downtime Implication:
Will the change cause/require system
downtime
Alternate Actions:
Describe alternatives to the change
according to the Perception of the
Requester

Priority to Implement:
Describe priority assigned by the
requester

Approvals
Change Requester (Role, Name and
signature)
Head User
Department/Division/Section
(Department Name and Signature)

Head Health Information Management

Division (Name and Signature)

Head ICT Section (Role, Name and

signature)
Assignment
Engineer Assigned to execute (Role,
Name)

Engineer Notes

62
Appendix I: EMRS Guidelines Use Monitoring Framework
Guideline-Use Monitoring Framework
Parameter 1: Dissemination
Key Monitoring Questions:
1.1 What is the version of the current guideline document?
1.2 Has the current guideline document been disseminated?
1.3 If yes under [1.2] above, through which channels?
1.4 What is the proportion of target entities possessing at least one copy of the guideline document? – disaggregated by the
National, District, Health Facility, Partners.
Indicator:
% of target entities who received at least one copy of the guideline document, disaggregated by: (a) National; (b) District; (c)
Health Facility; (d) Partners
Means of Verification:
Reports (e.g., dispatch, supportive supervision)
Result Statement:
Existing version of the Guidelines for Implementing the Uganda electronic Community Health Information System
disseminated to key stakeholders nationwide.
Parameter 2: Training
Key Monitoring Questions:
2.1 Has training on the current version of the guidelines been conducted?
2.2 If yes under [2.1], what was the proportion of individuals trained on the various components of the guideline document?
– disaggregated by (a) National; (b) District; (c) Health Facility; (d) Partners
Indicator:
% of target entities oriented on guideline document, disaggregated by: (a) National; (b) District; (c) Health Facility; (d)
Partners
Means of Verification:
Reports (e.g., training, supportive supervision)
Result Statement:
Key stakeholders nationwide oriented on the existing version of the Guidelines for Implementing the Uganda electronic
Community Health Information System.
Parameter 3: Compliance
Key Monitoring Questions:
3.1 Are the various target groups implementing EMRS in accordance with established guidelines? Please provide comment by
target group and key area as appropriate
● Target Group: (a) National; (b) District; (c) Health Facility; (d) Community Health Workers; (e) Partners
● Key Component: (a) EMRS User Requirements, Design and Development; (b) Implementing EMRS; (c) System and
Data Access; (d) Governance Structure (e)Monitoring and Evaluation

Indicator:
Target entities are compliant with existing versions of the guidelines – disaggregated by (a) National; (b) District; (c) Health
Facility; (d) Partners.
*Use Likert scale: 1-5, where 1 = strongly agree, 2 = agree, 3 = neutral, 4
Means of Verification:
Reports (e.g., design workshop, training, supportive supervision)

63
Result Statement:
Key stakeholders nationwide are compliant with existing Guidelines for Implementing the Electronic Medical Records System.

Appendix J: EMRS Deployment Monitoring Framework

EMRS Deployment Monitoring Framework
Result Statement:
By 2025, the health sector has institutionalized the use of patient-level digital systems at the point of care.

Parameter 1: Functionality
Key Monitoring Questions:
1.1 Does the technology or system work?
1.2 Does the technology or system operate as intended?
1.3 Does the technology or system perform its intended functions effectively?
1.4 Is the technology effectively adapted to the local context in terms of language, literacy, modifications for network
coverage, etc?
Indicator List:
1. % service points of care with a functional computing device/computer/laptop at the time of deployment
2. % service points of care within a health facility with access to a power source for powering of the EMRS
3. # of alternative functional power sources in place
4. % end-users with access to local technical support for troubleshooting
5. % devices that are not currently operational (misplaced/broken/not working)
6. % end-users who are literate in the language used by the digital health intervention
7. % data fields or elements from original paper-based system that are captured by the technology
8. # hours of initial training on the use of the EMRS attended by end-users
9. # hours of refresher training on the use of the EMRS attended by end-users
Means of Verification:
Reports (e.g., data/performance reviews, supportive supervision, regional/national telecommunication reports, surveys)

Parameter 2: Stability
Key Monitoring Questions:
2.1 Does the system consistently operate as intended?
Indicator List:
1. # hours of system/server downtime over reference period (i.e., last 1 month or 3 months)
2. % end-users reporting successful synchronization with server over reference period (i.e., last 1 month or 3 months)
3. % end-users reporting failed synchronization with server over reference period (i.e., last 1 month or 3 months)
Means of Verification:
Reports (e.g., system-generated/audit trail)
Parameter 3: Fidelity
Key Monitoring Questions:
3.1 How do people interact with technology or systems?
3.2 Do the realities of the field implementation alter the functionality and stability of the system, changing the EMRS
intervention from that which was intended?
3.3 Has the digital health system or technology been widely adopted?
3.4 Do the users find the technology easy to use?
3.5 Do the end-users find the health data/information received from the EMRS intervention useful?
3.6 Are the end-users able to communicate with the EMRS as intended?

64
3.7 Are the end-users responsive to the information received through the system?

Indicator:
1. % end-users that pass the assessment test during the training phase.
2. % end-users who demonstrate proficiency in use of the EMRS
3. % intended end-users observed using the EMRS
4. # transmissions sent by intended end-users over reference period (i.e., last 1 month or 3 months)
5. % end-users who rate the EMRS as “easy to use”
6. % end users who rate the EMRS as “transmits information as intended”
7. % end-users who report satisfaction with the content of health data/information received via the EMRS
8. % end-users motivated/intending to use the EMRS
9. # forms/amount of data transmitted by end-users via EMRS within a reference period (i.e., last 1 month or 3
months)
10. % data fields or elements/forms that are left incomplete over reference period (i.e., last 1 month or 3 months)
Means of Verification:
Reports (e.g., system-generated/audit trail, design workshop, training, data/performance reviews, supportive supervision)
Parameter 4: Quality
Key Monitoring Questions:
4.1 Is the content and the delivery of the EMRS intervention of high enough quality to yield intended outcomes?
4.2 How does EMRS improve service delivery?
4.3 How do improvements in service delivery affect health outcomes?
Indicators:
Client-Level;
1. # minutes (reported or observed) between EMRS prompt received about programmatic intervention and seeking
care from provider (e.g., HW, midwife, nurse, clinician)
2. # days duration of illness episode: disaggregated by illness/condition
3. # minutes spent with HW in relation to health intervention at the last visit
4. % target individuals or caregivers who report contact with a qualified health-care provider using EMRS in relation to
a programmatic intervention over reference period
5. % target individuals or caregivers who report adequate knowledge about signs and symptoms
6. % target individuals or caregivers who report adequate knowledge about the health issues relevant to a
programmatic intervention
7. % changes in reported individual level out-of-pocket payments for illness management over reference period
(through managing the illness by phone-based consultation instead of visiting a health care facility, e.g., travel cost)
Provider-Level;
1. # minutes (reported or observed) for last client counseling about a health intervention using EMRS
2. # minutes or hours (reported or observed) spent on health record-keeping about a health intervention over reference
period
3. # minutes (reported or observed) used per individual HW to report important adverse events (e.g., stock-outs)
4. # of HWs who report adequate knowledge of the health issue relevant to a health intervention

65
 5. % care standards relating to a health intervention observed to be met using EMRS during client-provider
consultation
6. % HWs observed to be using EMRS during their patient consultations
7. % target HWs who use EMRS in relation to relevant health interventions through tablets over reference period
8. Amount of cost savings (estimated) due to improvement in service delivery/efficiency/other factors.
9. # clients (average or total) attended by a HW using EMRS over reference period

Health System-Level;
1. # minutes (cumulative) over reference period for all HWs using EMRS to enter data related to a health intervention
2. # days over reference period for which a HW reports stock-out of a commodity essential for provision of a health
programmatic intervention
3. % change in reported stock-out events of a commodity essential for service delivery over reference period,
disaggregated by relevant health interventions
4. % change in data entry errors over reference period
5. % target end-users who receive training on management and use of EMRS to deliver quality service delivery,
disaggregated by initial and refresher training
6. # individuals seeking health care over reference period, disaggregated by relevant health interventions
7. % individuals in a specific geographical area who receive health care through EMRS over reference period,
disaggregated by relevant health interventions
8. % change in costs of transporting HMIS paper forms and manual data entry over reference period
9. % change in costs of human resources for data entry
10. % change in costs associated with timely and appropriate management of illness
11. % changes in reported individual out-of-pocket payments for management of illness
12. Total population-level savings in out-of-pocket payments attributed to timely and appropriate care seeking
Means of Verification:
Reports (e.g., system-generated/audit trail, design workshop, training, data/performance reviews, supportive supervision)

66
Appendix K: EMRS Evaluation Framework
EMRS Evaluation Framework
Formative Evaluation Type: Process Evaluation Timeline:TBD
Objective: Measure outputs attributed to EMRS intervention activities and inputs;
done either as a one-time assessment and/or continuously.
Key Question(s):
● Is the EMRS intervention operating as intended?

Evaluation Type: Implementation Evaluation Timeline:TBD

Objective: Monitor the fidelity of the EMRS intervention holistically or technology
system.
Key Question(s):
● Is EMRS implementation occuring in accordance with the original and
existing implementation guidelines and standard operating procedures
and/or protocols?

Summative Evaluation Type: Performance or Outcome Evaluation Timeline:TBD

Objective: Measure the effectiveness of EMRS intervention activities on immediate
and intermediate changes in key outcomes, including knowledge, service provision,
utilization and coverage.
Key Question(s):
● Are the health services available? What is EMRS intervention’s effect on
changes in service delivery?
● Are the health services being utilized?
● Did EMRS increase coverage of the relevant health interventions? Is the
target population being reached?

Evaluation Type: Impact Evaluation Timeline:TBD

Objective: Measure the long-term net effects or impact of the intervention on key
health outcomes, including mortality, morbidity, and disease risk, at the health
facility level or higher.
Key Question(s):
● Were there improvements in disease or mortality patterns, or health-
related behaviors?

Evaluation Type: Economic Evaluation Timeline:TBD

Objective: Determine a probable value for money from investment made in EMRS
roll-out.
Key Question(s):
● What is the incremental cost-effectiveness of the EMRS intervention as
compared to existing services?

67