National Standard For EHRs Development and Implementation Zero Draft

National Standard for Electronic
Health Record System (EHRs)
Adama, Ethiopia 2021

Forward
Produced in Feb, 2021

Acknowledgments
FORWARD 1

ACKNOWLEDGMENTS 2
ACRONYM 4
TECHNICAL GLOSSARY 5
[BACKGROUND AND RATIONALE] 6
EHR SYSTEM ARCHITECTURE AND DEVELOPMENT PROCESS 7
FUNCTIONAL REQUIREMENTS FOR EHR SYSTEMS 8
INTRODUCTION 8
STANDARDS REFERENCED 8
E H R SYSTEM FUNCTIONAL REQUIREMENTS 9
CONTENTS OF E H R CORE FUNCTIONALITIES 12
E H R SYSTEM MODULES (SUB SYSTEMS) 18
MODULE FUNCTIONALITY REQUIREMENT AND MINIMUM DATA SET 18
STANDARDS FOR HER AND INTEROPERABILITY 60
INTRODUCTION 60
TERMINOLOGY STANDARDS 62
MESSAGING STANDARDS 68
DATA OWNERSHIP, SHARING, PRIVACY AND SECURITY 73
NORMATIVE REFERENCES 73
TERMS AND DEFINITION 75
OWNERSHIP OF ELECTRONIC HEALTH DATA 76
PROTECTED AND SENSITIVE PERSONAL IDENTIFIABLE INFORMATION 77
SECURITY SAFEGUARD THEMES 79
DATA ACCESS MECHANISM AND CONTROL 80
EHR ADMINISTRATIVE STANDARDS 81
RECOMMENDATION 82
E H R SYSTEM IMPLEMENTATION REQUIREMENT 83
INTRODUCTION 83
MINIMUM IMPLEMENTATION REQUIREMENTS FOR FACILITIES 84
RECOMMENDATIONS 89
REFERENCES 2
ANNEXES 3

Acronym
EHR Electronic Health Record
EMR Electronic Medical Record
DHIS District Health Information System
NHDD National Health Data dictionary
SNOMED Systematized Nomenclature of Medicine
SNOMED CT Systematized Nomenclature of Medicine — Clinical Terms
SNOMED GPS Systematized Nomenclature of Medicine — Global Patient Set
LOINC Logical Observation Identifiers Names and Codes
NCoD National Classification of Diseases
FHIR Fast Healthcare Interoperability Resources
API Application Programming Interface
NHS National Health Service
HL7 Health Level Seven International
DICOM Digital Imaging and Communications in Medicine
WHO World Health Organization
WHO-FIC WHO Family of International Classifications
ICD International Classification of Diseases
ICF International Classification of Functioning, Disability & Health
ICHI International Classification of Health Interventions
ICD-O International Classification of Diseases for Oncology
eHA Electronic Health Architecture
TS Technical Standard
CCR Continuity of care Record
ICHI International Classification of Health Intervention
ICF International Classification of Functioning, Disability & Health
ASTM American Society for Testing and Materials
CDA Confidential Disclosure Agreement
FSN Fully Specified Name
GBD Global burden of Disease
IDSR Integrated Disease Surveillance and Response (IDSR)
MOH Ministry of Health
IHTSDO International Health Terminology Standard Development Organization
MDL Master Drug List
UMDNS Universal Medical Device Nomenclature System
PHR Personal Health Record

Technical Glossary
Terms Definition
Interoperability The 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.
Actors People or information systems who interact with the EHR system.
Data Exchange The act of information exchange is often referred to as data sharing. Data
Sharing uses the term to refer to the collection of practices, technologies,
cultural elements, and legal frameworks that are relevant to transactions in any
kind of information digitally, between different kinds of organizations. This term
is more broadly applied to all types of data sharing, but can also be specifically
used for health-related data.
EMR Electronic medical records (EMRs) are a digital version of the paper charts in the
clinician's office.
EHR An Electronic Health Record is the systematized collection of patient and

population electronically stored health information in a digital format. These
records can be shared across different health care settings.
Module A self-contained software component that interacts with a larger system. A

software module (program module) comes in the form of a file and typically
handles a specific task within a larger software system.
Security
A collection of approaches that address issues covering physical, electronic, and
procedural aspects of protecting the information collected as part of health care.
Privacy
Privacy is both a legal and an ethical concept. The legal concept refers to the
legal protection accorded to an individual to control both access to and use of
personal information and provides the overall framework within which both
confidentiality and security are implemented.
Confidentiality Confidentiality measures protect information from unauthorized access and

misuse.
System A system architecture is the conceptual model that defines the structure,

Architecture behavior, and more views of a system. An architecture description is a formal
description and representation of a system, organized in a way that supports
reasoning about the structures and behaviors of the system.
[Background and Rationale]

A well-functioning health information system is a demanded entity in health service delivery improvement and
health outcomes. The practice of keeping medical records for individuals using a paper based system has been
a long practice in Ethiopian health facilities. During each encounter, health workers collect huge demographic,
clinical and administrative data about a patient and the services provided to help them understand the
patient's condition, set diagnosis and treat the patient. Despite some standardization efforts made during
HMIS reform and development of the hospitals service transformation plan in 2008/9, and 2016 respectively,
health facilities collect data using locally developed formats and different sets of data elements for the same
service. In addition, most clinics don’t have standardized checklists for data collection and care providers
record health data as semi structure and free text with handwriting. As a result, it has been very difficult to
make cross reference about the past medical history, diagnosis and treatment given due to poorly handled
paper medical charts and eligible handwritings. The practice of summarizing patient information and
producing aggregate reports have been error prone and less reliable. It has also been uncommon to see
duplication of medical records (with scattered patient information) and repeating investigations for lost results
contributing to poor patient satisfaction and inefficient provision of care.
Earlier time, the MOH in collaboration with a partner tried to implement a windows based application in some
public health facilities some ten years back but couldn’t go far for different behavioural, technical and
organizational factors. Currently, there are some private and public health facilities trying to automate some
or all parts of their services. Implementing EHR system can believed to provide the benefits of ensuring
continuity of care, safer medical practice by minimizing medical errors using decision supporting tools,
efficient use of facility resources, effective care by providing access to the source of current knowledge, and
availing individual health records at national level for big data analysis, research and reporting.
Building individual level longitudinal health records nationally can only possible through implementation of
interoperable electronic health recording systems that comply with certain nationally defined functional,
terminology, data exchange and security standards and implementation requirements. In this regard, the
ministry of health didn’t have a mechanism to guide and lead the development/customization of EHR systems
and coordinate investments towards establishing a responsive and interoperable EHR systems. Therefore,
aligning with the national digital health blueprint and strategy, MOH produced a national standard for EHR
system development and implementation to shape the future EHR ecosystem in the country.

Guiding principles of EHR System Development and Implementation
Availing longitudinal individual health data records at national level can be achieved either by establishing a
single EHR system that runs in all health facilities,standalone diagnostic centers and dispensing pharmacies or
by allowing multiple independent but interoperable EHR systems to be developed and deployed by health
facilities. Both approaches have their own pros and cons. The former goes with the motto of MOH, which is
one plan, one report and one budget, to bring uniformity of health data by promoting a unitary system. Such
an approach may be useful for low income countries as it highly reduces the cost associated with the
development/customization of the right software, dealing with interoperability issues and adoption of
international data exchange standards. It also demands less sophisticated technical skills to manage data
exchange with other external systems. it also requires huge initial investment and may leave the country
dependent on limited software vendors and technology platforms.
On the other hand, allowing multiple systems to operate in a country, the second approach, allows many
stakeholders to involve software development using different technology platforms and scale-up activities.
This approach supports one of the basic principles of Ethiopian health system which is democratization and
decentralization of the health system in the eyes of digitization. Since such approaches bring a wider range of
semantic and syntactic variations of health data collected by different EHR software, achieving good quality of
data exchange among health facilities and bringing uniformity of data at national level is not an easy task. In
fact , such an approach without strict monitoring and evaluation mechanisms in place is extremely dangerous.
Therefore, with due consideration of the costly business of managing interoperability issues and limited
resources, the MOH developed EHR systems standards and implementation requirements to support
establishment of a single source of truth for individual health records at national level by allowing those EHR
systems that fulfill the requirements to participate in the digital health ecosystem.
Aiming at establishing a robust, dynamic, standardized, interoperable and secured EHR systems to support the
health systems ensuring continuity of care, quality health service delivery, and equitable distribution of health
resources, The MOH formulated the following guiding principles to be strictly followed by different
directorates of MOH, agencies, regional health bureaus, health facilities, NGO, Software vendors and other
stakeholders during the selection, development/customization and implementation of an EHR
software/system.
● Encourage open source resources for the development and customization of an EHR software
● Follow human centered, collaborative and learning approach in the development or customization
process
● Ensure supporting continuity of care, safe medical practice, efficient and effective services
● Support automation of all service outlets of a health facility
● Support easy addition of future functional and data need (extendibility)

● Facilitate efficiency of existing workflow in providing health services
● Ensure inclusion of all key functionalities identified in the standard document
● Support principles and standards of graphical user interface (GUI)
● Ensure system learnability, memorability and easy of navigation
● Support the minimum data set and modules defined in the standard document
● Ensure implementation of selected terminology standards for structured data capturing for problem
list, procedures, diagnosis, laboratory tests, pharmaceuticals and other clinica data
● Support data exchange or messaging standards recommended by the national EHR TWG team
● Support high quality exchange of textual and other multimedia contents with other EHR and ancillary
systems via nationally defined interoperability layer
● Ensure privacy and confidentiality of client or patient information
● Support tailored deployment and implementation based on type and capacity of implementing health
facility
● Ensure deployment and proactive maintenance of adequate ICT infrastructure at implementing site
● Ensure minimum system response time and hundred percent system availability in 24hr/7days
● Focus on realization of perceived benefits of EHRs to the patient, facility and other stakeholders during
the implementation process
● Ensure EHR system implementation sustainability through strong M&E framework, change
management, local capacity building and adequate budget allocation.
E H R System Architecture and Development Process
System architecture

…..
Development process

Functional Requirements for EHR Systems
Introduction
Since the past few years, different EHR systems have been developed or customized by NGOs, private vendors
and health facilities with different capabilities tailored to the individual health facility’s needs. However, due
to the growing need for individual health data at national level and the complex nature of health facility’s
information system, most implemented electronic medical recording systems functionalities are limited to
automating certain aspects of health facilities and not yet capable of exchanging patient data among other e-
health systems. Moreover, data collected from such systems lacks uniformity as there is no mechanism in
place at national level to enforce EHR systems complying with the minimum data elements defined by MoH.
Therefore, with due consideration of the national HIS strategies and the digital health blueprint, It is important
to define the core set of functionalities, modules and minimum dataset for an EHR system in order to support
all service delivery outlets and bring its desired benefits to the individual, health facility and higher level. In
this document, eight core EHR functionality areas, ninety functionalities and fifteen modules (sub systems) are
described with a defined level of importance, and Institute of Medicine (IOM) is used as reference to select
these key functionalities. Capabilities that support safe, efficient, effective and patient centered medical
practices are given the highest priority for an EHR system to fulfill. The key functional areas shall define all
critical aspects of an EHR system. These are:
1. Basic demographic and clinical information

2. Order and referral management
3. Result Management
4. Decision Support
5. Administrative processes
6. Data management, use and Reporting
7. Exchange of Electronic Information
8. Patient Support
These functionalities and modules serve as a base for reviewing and evaluating an EHR system to be deployed
or running in the health facilities of this country.
Standards referenced
The functional requirements of an EMR system are mostly referenced from the HL7-electronic health record
system functional model. In addition, the Ethiopian hospital service transformation guideline is used as a
reference to determine the modules or sub systems that need to be included in EHR systems customized or
developed to the Ethiopian context. Other national and international references are also used, including:
● HL7 - Electronic Health Record System Functional Model, Release 2.0.1

● Standards and Guidelines for Electronic Medical Record Systems in Kenya, 2010
● ISO/TS 18303: Health informatics

● Ethiopian Hospital Services Transformation Guideline (EHSTG) Volume 1 and 2, MOH, 2016
● National HMIS Recording and reporting procedures manual, MOH, 2018
● National HMIS indicator reference guideline, MOH, 2018
● Hospital Performance Monitoring and Improvement Manual, MOH, 2016
● Health Services Transformation in Quality (HSTQ), MOH, 2018
E H R system functional requirements

The electronic health recording systems to be customized or developed shall have minimum functionalities
and data set to support all activities directly or indirectly related to provision of health services to individual
patients/clients. Capabilities that support identification of an individual uniquely and capturing demographic
and health information during the time each encounter is one of the groups of functionality an E H R system is
expected to meet. This definitely adds value to the quality of health service delivery by ensuring continuity of
care. The second category of EHR functionalities enable care providers to set any kind of clinical orders to
investigate a patient's health problems or treat conditions or refer/consult/transfer cases for the betterment
of services. The third group of EHR functionality supports easy management of previous and current results,
enhancing efficiency. Capabilities that support clinical and administrative decisions such as access to current
knowledge sources, reminders and alerts in the process of care are categorized as decision support
functionalities. These capabilities are expected to reduce potential medical errors and enable care providers to
provide effective services. The fifth group is about those functionalities that support health facility
administrative processes such as queue management, patient scheduling for services, billing and bed
management. These functionalities help hospitals to have better control on available resources and provide
equitable and efficient services towards improving patient satisfaction. The individual level data, nationally
defined aggregate service and disease reports, custom report, data visualization and analysis using built in
analytic tools is an ever growing demand in the health system. Thus, the six groups of capabilities serve data
management, use and reporting needs health facilities. To support provision of health services regardless of
where the individual is located, and to facilitate team work among care providers, an EHR system shall support
exchange of quality individual and aggregate data among different systems. The last but not the least group of
E H R functionalities focuses on capabilities that enable patients to access their own health records, receive
tailored educational material and transmit data from remotely located patient monitoring devices.
E H R functionality requirements
Demographic and Health information
This refers to individual patient or client related information regarding their demographic and health
information generated and captured during health facility encounters or visits. Complete demographic and
health information enables health care providers to diagnose and treat illness and injuries. An E H R system is
required to capture and render:
● Demographic data of an individual including but not limited to Unique identifier, Biometric, First
name, Middle Name, Last name, Gender, Date of Birth, Physical address -Region, Zone/Sub-city,

Woreda, Kebele, House Number; Phone number, Education level, Occupation, Marital status, and
Contact address.
● Clinical data such as chief complaint, history of present illness, past medical, social and family
histories, vital signs, findings of physical examination, investigation request and results, problem list,
procedures, immunization information, Medication list, progress note or follow up, nursing diagnosis
and care given, diagnostic images, referral information, consent notes and discharge summary.
● The system shall capture demographic and clinical data using structured formats and free texts
● The system shall capture chief complaints, problem lists (including diagnoses), medication, lab test,
procedures and immunization data using selected & adopted terminology standards.
● The system shall render a list of time tagged interaction summary for each encounter and service unit
level interaction with capability of selecting and expanding a particular interaction.
Order and referral management

Care providers using an E H R system shall be able to order clinical investigations, procedures, cares and other
services within or to other health facilities electronically. As a result, one can ensure effective and safer
practice of health services to individual patients. In addition, electronic communication of patient’s referral
information can facilitate collaborative work of health facilities towards providing the right health service to
the right individual by the right care provider at the right time. Therefore, critical E H R systems developed or
adopted and run in the Ethiopian health facilities shall support electronic referral and ordering clinical
services. Orders and referral services include but not limited to:
● Laboratory tests
● Diagnostic tests and imaging
● Prescriptions
● Procedures
● Nursing care
● Follow up care
● Diet/ dietary service
● Intra/inter/referral or linkage between departments/units
● Transfer in and out
● Consultations
Decision support
One of the key benefits of having an E H R system in a health facility setting is minimizing potential medical
errors, improving safer and effective practice of Medicine by care producers during each encounter. Thus, It is
also essential for an E H R system implemented in our setting to have functionalities that support the clinical
decision making process. This include but not limited to:
● Availing clinical guidelines

● Allow access to current clinical knowledge sources
● Alert, remind, prompt for erroneous drug prescription

● Alert for drug- drug interactions
● Alert of out of range values
● Reminders for Service Appointments and chronic care services
● Alert for allergies
Data management, use and reporting
Collecting individual level data for health facilities in electronic format makes the management of data,
analysis, use and reporting easy. Availability of shared health records at national level also provides a
unique opportunity to access individual level health data for other health facility consumption, to generate
national reports, perform big data analysis and carry out research. Therefore, an EHR running in a health
facility shall have capability to:
● Generate and send HMIS report and facility KPI report; and clinical data report
● Produce Custom report
● Visualize data with charts
● Display dashboards
● Support data entry validation
● Export data set with recommended format
Result management
All investigation results from laboratory, Diagnostic test and imaging, Pathology units from a facility and other
standalone diagnostic centers should be electronically collected and integrated with the patient chart. Care
providers should be able to find and review previous results to monitor the patient status and support his/her
clinical decisions on diagnosis and treatment of the patient. This improves efficiency of service provision by
minimizing time and reducing the cost for repeat investigations. An E H R system shall have capabilities to:
● Receive and send lab, diagnostic test and imaging results
● Display previous results
● Display charts for trends of test result numeric values
Administrative processes
To facilitate efficient management of health facility resources, improve patient satisfaction and attain better
control of financial flow, an E H R system shall be integrated with or have the following capabilities.
● Billing system
● Bed management system
● Queue management system
● Appointments management system
● User management

Exchange of electronic information
The practice of medicine demands exchange of data among care providers and health facilities,
diagnostic centers and other service providing settings where the individual patient/client receives
health services. To facilitate the data sharing activities, there is a need to build shared health records
at national level along with other services such as client registry, facility registry, HR system and PACS
(picture archival computerized system). This to happen, an E H R system should be capable of
supporting individual level data exchange within nationally defined E H R ecosystems and
recommended standards. Therefore, the developed or customized EHR shall be capable if interfacing
with:
- Patient monitoring Devices
- Laboratory machines and equipment
- Client registry for MPI service
- Shared health records
- Master facility registry
- Care provider registry (HRIS)
- Other ancillary systems such as PACS, Radiology information system, Laboratory information
system, Supply chain management system...etc.
Patient support
Patient centered approach for health service delivery is one of the quality dimensions MoH is promoting in the
country. Based on the national information act and data access and sharing policy, An E H R should support
data access to patients; and capture health data from remote medical devices used by individual patients. It
should also be capable of sending tailored educational instructions to patients.
Contents of E H R core functionalities

Based on the core E H R system functional areas described above, the national EH R standard development
team specified 102 functionalities that shall or should or may be supported by an E H R system in order to be
accepted and run in the Ethiopian healthcare settings.
Recommendations
● High (H): Functionalities an E H R system must support
● Medium (M): Functionalities an E H R system required to have or support
● Low (L): Functionalities an E H R system good to have or support
Functional specification for E H R Priority Level

A. General
1. The system shall support all services defined by MOH for each respective H All
health facility
2. The system shall capture all data elements required for individual patient H
management and program monitoring
3. The system should support paperless function and patient data exchange M
across all service delivery outlets and other facilities
4. The system shall associate unique identifier information (e.g., system ID, H
medical record number) with each patient medical record
5. The system shall support access to medical information to all health care H
providers involved in care provision
6. The system shall support displaying summary of services provided to patients H

by date, type of service, diagnosis or other criteria
7. The system shall support auto-capturing date and time for all transactions or H
events of each encounter
8. The system shall support send and receive shared health records from other E H
H R sources per pre-defined data set
9. System shall support security controls on medical records to ensure that data H
cannot be deleted or altered except within the current session and by an
authorized user
10. The system shall support maintaining audit logs. The audit log should have H
dates and time stamps for all entries
11. The system shall have data entry validation capabilities across all data entry H
forms
12. The system shall have the capability to capture dates and timestamps for all H
entries
13. The system shall have the capability to manage care providers information H
involved in care provision
14. The system shall provide the capability to manage free text comments associated with H
all demographic and clinical data entry
15. The system may have the capability to capture and render historical paper based data L
using different technologies such as scanning

16. The system shall provide the ability to manage a record for a patient when the identity H
of the patient is unknown
17. The system shall provide the ability to manage patient charts as obsolete, inactivated H
or nullified in accordance with local policies and procedures, as well as applicable laws
and regulation
18. The system should have a feature that support displaying an indicator that the health M
record of the patient/client is incomplete (for selected data elements)
19. The system shall support capability of setting price of services H

B. Basic Demographic and Health Information
B.1. Basic Demographic /Identification
20. The system should have a feature that support MPI service with the national M
client registry
21. The system shall generate a unique individual identifier for new clients (MRN) H
22. The system shall support resolving duplicate patient records H
23. The system shall support display of key demographic data at each interaction H
points
24. The system shall support updating demographic characteristics if necessary H

B.2. Clinical Information
Vital Signs
25. The system shall support capturing and displaying vital signs such as blood H
pressure, respiratory rate, pulse rate, Oxygen saturation, temperature, pain
score, weight, height and random blood sugar
26. The system should auto calculate nutritional status of individuals (Such as body M
mass index-BMI, Weight for age-WFA, Weight for Height-WFH…)
27. The system should alert out of range values for vital signs M
28. The system shall support generating reminders to take vital signs at intervals H
ordered by treating physician
29. The system shall support display of main vital signs and trends over time H
Patient History and physical examination
30. The system shall be capable of capturing chief complaint with its duration H

31. The system shall support capturing clinical data based on standard formats H
and protocols (Example: ART intake forms, ART follow up forms, Integrated RH
card etc…)
32. The system shall allow data entry for history of present illness, personal/social H
history, family history, NCD risk assessment, history of allergy and adverse
drug reactions
33. The System shall have capability of capturing past patient history as relates to H
medical, surgical, obstetrics/gynecology, pediatric and other care provided
34. The system shall capture immunization history and status based on selected H
terminology standard for vaccines
35. The system shall provide the ability to create and maintain a client-specific H
immunization schedule.
36. The system shall capture family planning, pregnancy care, childbirth and H
postnatal care data based on the national formats (capable of capturing data
for each visit)
37. The system shall support capturing physical examination findings as structured H
and free text form
Problem List
38. The system shall have capability to capture, maintain, display and report all H
active problems associated with the patient, based on the selected
terminology standard
39. The system shall capture all diagnosis of the patient, and condition of the H
patient (Severity, chronicity…) based on nationally selected diagnosis standard
40. The system should support capturing reasons for any diagnosis change in the M
course of patient treatment
41. The system shall be capable of mapping diagnosis to the national classification H
of diseases
42. The system shall be capable of capturing diagnosis as new or repeat; and as H
primary/main and other diagnosis
43. The system should be able to capture and track diagnosis status as M
presumptive and confirmed
44. The system shall provide the ability to manage the status of each problem H
identified (e.g., active, inactive, resolved)
45. The system shall provide the ability to render active problems H

46. The system should be able to sort problems as required by the care provider M
such as by severity, time of occurrence or other factors
Progress note and treatment plan
47. The system shall capture and display progress note and treatment plan based H
on the national standard format
48. The system shall display previous medication and investigation results H
49. The system should support capabilities of recording and rendering procedures M
and surgeries performed information with a description
50. The system shall provide the ability to manage adverse effects following H
medications
C. Order and referral management
51. The system shall support ordering laboratory tests coded with selected H
terminology standard
52. The system shall support managing orders status (such as completed, on H
progress, cancelled…)
53. The system shall support managing blood and blood products order H
54. The system shall support ordering diagnostic and imaging requests, based on H
selected diagnostic and imaging standard
55. The system shall support prescribing pharmaceuticals based on selected H

pharmacy standards including e-prescription
56. The system shall have the capability to manage prescription order including H
editing, cancelling prescriptions when a medication is prescribed by mistake
57. The system shall support ordering follow up care, nursing care based on H
selected nursing standard
58. The system shall support capabilities to manage consent order H

59. The system shall support managing consultations and referrals information H
60. The system may support display of the status of consultations and referrals (as L
completed, pending, cancelled…)
61. The system shall support capturing and rendering other orders such as dietary H
order, physiotherapy... etc.
62. The system shall display available medicines, laboratory tests, diagnostics and H
imaging services in the specific facility

63. The system shall support the ability to manage and render urgency status of H
orders
64. The system shall support transmitting orders to other systems H

D. Result Management
65. The system shall have the capability to receive, display and maintain current H
and previous laboratory test results with reference values
66. The system shall support capability of displaying alert message for out of range H
result values
67. The system should have the capability to access laboratory results from other M
laboratory Information Systems
68. The system shall have the capability to receive, display and maintain H
availability, safety and compatibility of blood and blood products
and previous diagnostic and imaging results (images) with description of the
findings and impressions
70. The system should have the capability to send and receive diagnostic and M
imaging results from/to radiologic information system, PACS (Picture Archiving
Computerized System)
and previous prescribed drugs dispensed to the client/patient
E. Decision Support
72. The system shall have the capability of accessing clinical guidelines and current H
clinical practices knowledge sources
73. The system shall have the capability of displaying alerts and reminders to all H
care providers, when there is an abnormal value or when there are events to
be attended based on certain clinical protocol specific to certain services
74. The system shall have the capability to display reminders/alerts for abnormal H
lab results, drug-drug interactions, allergies etc….
75. The system should support the ability to render a notification to the care M
providers when specific order or doses are due
76. The system shall have a reminder for immunization due date, Antenatal care H
visits, compute gestational age, expected date of delivery (EDD) and other
similar clinical decisions

77. System shall automatically triggers an alert upon documentation of a H
diagnoses or event required to be reportable to MOH and/or EPHI
F. Administrative processes
78. The system shall have the capability to capture and manage billing information H
and claim management for all transactions
79. The system shall have the capability to capture and manage bed information H
such as number of beds, rooms, wards etc…
80. The system shall support the ability to manage re-location of patients H
81. The system shall have the capability to manage patient appointments H
82. The system shall support queue management for all services H
83. The system shall have the capability to manage and display waiting lists for H
different services
84. The system shall have the capability to manage and issue medical certificates H
85. The system shall have the capability to manage different system users with H
different roles and privileges
G. Data management, Use and Reporting
86. The system shall have the capability of generating aggregate HMIS reports H
required by MOH, such as disease report (morbidity and mortality report),
service report
87. The system shall have the capability to electronically transmit aggregate H
national reports to national HIS systems such as DHIS2
88. The system shall have the capability to generate ad hoc custom reports H
89. The system shall have data analytics features such as data visualizer, H
dashboards... etc.
90. The system shall create and maintain patient-specific summary views and H
reports that include, at minimum: problem list, medication list, treatment
interruptions and restart dates, adverse drug reactions, care history, and
missed appointments
H. Exchange of Electronic Information
91. The system shall support the exchange of data using selected messaging standard and H
protocols with other systems
92. The system shall have Communication/messaging capabilities to exchange patient H

information among care providers (feedback mechanism)

93. The system may provide the ability to receive and render structured demographic and L
clinical information from registries
94. The system should provide the ability to harmonize system information with registry M
information
95. The system may support data capturing and rendering from laboratory equipment and L
patient monitoring medical devices
96. The system should provide the ability to exchange clinical information with pharmacies M
using messaging or service standards
I. Patient support
97. The system may have a patient portal that supports patients to access their L
own medical record, but cannot alter data, based on the recommended data
confidentiality protocol
98. The system may have educational materials for patients L

99. The system may alert patients through different communication mechanisms L
such as SMS, emails…
100. The system may support capturing and rendering patient information from L
patient sources such as remote monitoring devices
101. The system may send alert messages to patients/clients for their L
appointments, treatment instructions, follow ups...etc.
102. The system may provide the ability to render and annotate instructions L
pertinent to the patient as selected by the provider
E H R System Modules (sub systems)

This E H R standard specified fifteen module/ sub systems to support the entire health facility activities so that
a paperless environment can be created, and an E H R system can support provision of safe, effective and
efficient health services to individual patients/clients. The E H R system to be deployed in a health facility
should have the following modules. A queue management system should also be an integral part of the E H R
system.

1. Triage and Registration module
2. Liaison Module (including bed management service)
3. Outpatient Module
4. Emergency Module
5. Inpatient Module (including nursing care services)
6. Laboratory Module
7. Pharmacy Module
8. Diagnostic and Imaging Module
9. Billing Module
10. Maternal, Neonatal and Child health Module
11. Non-Communicable Diseases Management Module (DM, HPN, Cardiac, asthma, epilepsy…)
12. HIV chronic care management module
13. Tuberculosis management module
14. Rehabilitative and palliative care module
15. Reporting module
Module Functionality and Minimum Data Set Requirements

This document describes the functional and minimum data set requirements each module shall support in
addition to those relevant capabilities listed under the eight core functionality areas. Under this section,
module description, its capabilities and the minimum data elements are described for each module.
1. Outpatient Module
Description: This module supports all clinical services provided in outpatient departments of a health facility
including regular, referral and special clinics. It is inclusive of all the processes a patient may go through while
receiving care or services as an outpatient case. This module of an EHR system, shall have the following
capabilities and minimum data set.
Functionalities:
- Capable of identifying, sorting and selecting list of patients assigned to the specific outpatient service
unit
- Capable of displaying status of OPD patients as waiting, on progress, complete during the encounter
- Support summarizing and displaying patients’ previous interactions and sorting by date, diagnosis,
and service unit
- Capable of displaying specific previous patient interaction to view the information in detail
- Support capturing and displaying scanned documents such as referrals
- Capabilities to capture and display vital signs
- Capability of capturing and displaying patient history such as chief complaint with duration, history of
present illness, past medical/surgical/gynecological history, social/family history, allergy history as a
structured and as free text form
- Capable of capturing and displaying problem list/diagnosis in a structured form based on the selected
national terminology standard
- Capable of capturing and displaying NCD risk factors, screening information based on standard format

- Capable of capturing physical examination findings by system (organ system), in a structured form-
based on selected clinical terminology standard, and free text
- Capable of providing diagnosis menu by specialty such as Surgery, Gyn.Obs, Dental, ENT, Pediatrics,
Dermatology, Ophthalmology,IMNCI...etc. for easy of searching a specific diagnosis
- Support capturing and displaying diagnosis as main and other diagnoses, new and repeat;and status
as presumptive and confirmed diagnosis
- Capabilities to order laboratory tests, diagnostic and imaging investigations, and pathology tests
- Capable of displaying updated available list of laboratory tests, diagnostic and imaging studies, and
pathology tests with price
- Support electronic receiving and rendering laboratory, diagnostic and imaging, pathologic test results
- Capable of capturing and displaying Provider Initiated Testing and Counseling (PITC) information
- Capable of capturing and displaying treatment plan
- Capable of displaying medicines’ stock status by dispensing units and stores
- Support prescribing medicines electronically
- Support transferring patients to other outpatient units
- Capable of managing patient referral such as referring patient,displaying referral status of patients,
receive and send referral feedbacks
- Support care provider communications among others within the health facility and external staff for
consultation and other patient matters
- Support electronic patient admission and Capable of displaying facility’s bed information such as beds
occupied, free beds, ward type, bed number, bed transfer history...etc.
- Capabilities to manage patient appointments
- Capable of displaying a list of services provided in the facility, its cost, type of payment (cash, credit,
free, insurance…), and cash balance
- Capable of managing medical certificate, consent
- Capable of generating OPD specific standard and custom reports
Minimum Data Set

The minimum data elements for which data should be captured as structured or free text during provision of
outpatient service provision is described below.
SN Data Element /Field Data Form (data Category Relevance

type/Format source) (Report=R,
Service=S, Patient=P)
1 Chief complaint text patient form Clinical
2 Duration of chief numeric patient form

complaint (time)
3 Onset of chief complaint text patient form

(eg insidious or gradual)
4 Location of chief text patient form

complaint
5 history of present illness Free text patient form

6 Past Medical History free text past history
7 Surgical History free text patient form
8 Gynecologic history free text patient form
9 Family and social history free text patient form
10 Surgical interventions free text patient form
11 BMI (Kg/M2) numeric in nutritional

range assessment
12 Weight Numeric nutritional

assessment
13 Height/length Numeric nutritional

assessment
14 Head circumference (cm) numeric nutritional

assessment
15 MUAC numeric nutritional

assessmentssessm
ent
16 General appearance text physical clinical S,P

examination
17 Blood Pressure: Systolic Numeric Vital sign chart Clinical S,P
18 Blood Pressure: Diastolic Numeric Vital Sign chart Clinical S, P
19 Temperature (0c) Numeric Vital sign chart Clinical S, P
20 Pulse pressure Numeric Vital sign chart Clinical S, P
21 Respiratory rate Numeric Vital sign chart Clinical S, P
22 Oxygen saturation Numeric Vital sign chart Clinical S, P
23 Pain score Numeric Vital sign chart Clinical S, P
24 HEENT Text physical

examination
25 Glands Text physical

examination
26 Chest Text physical

examination

27 Cardiovascular Text physical
examination
28 Respiratory Text physical

examination
29 GI Text physical
examination
30 Renal Text physical

examination
31 Integumentary Text physical

examination
32 Musculoskeletal Text physical

examination
33 Other Text physical

examination
34 Lab tests Text Lab request and

result form
35 Lab Results Alphanumeric Lab request and

result form
36 Medications Prescribed Text Prescription form
37 other investigations Text Investigation form

requested
38 Investigation results Text Investigation form
39 Treatment plan Text Patient form
2. Inpatient Module
Description: This module supports all the inpatient activities or workflows provided to any admitted cases
ranging from reviewing newly admitted patient information to discharging or referring patients to higher level.
The functionalities and the minimum data set an inpatient module of an EHR should meet are described
below.
Functionalities:
- Display summarized previous key patient information ( summarized demographic information allergy,
chronic illnesses, current status and diagnosis…)
- Capable of displaying newly admitted patients’ list by date and time, specific unit and admission
diagnosis
- Capable of sorting,selecting specific admitted patient and display detailed admission information
- Capable of adding new admission note writing page

- Capable of capturing and displaying structured and free text while using admission note (chief
complaint, HPI, vital sign, P/E, assessment and plan)
- Capable of ordering laboratory requests, including urgency status
- Capable of ordering procedures
- Capable of ordering diagnostic and imaging requests
- Capable of ordering pathology request
- Capable of ordering followup care as per standard inpatient monitoring charts
- Capable of managing nursing care
- Capable of displaying available laboratory tests, diagnostic and imaging studies, pathology tests
- Capable of capturing and displaying PITC information
- Capable of receiving and displaying laboratory, diagnostic and imaging, pathologic results
- Capable of providing diagnosis menu by speciality
- Capable of ordering prescriptions
- Capable of displaying medicines’ stock status by dispensing units, stores etc...
- Capable of transferring patients to other departments
- Capable of referring patients to other health facilities
- Capable of communicating and consulting with other experts in the facility
- Capable of capturing and displaying clinical pharmacist notes
- Capable of capturing and displaying progress note with structured and free text forms
- Capable of managing medication administration (by nurses)
- Capable of managing preoperation, operation and post operation notes (as per the standard)
- Capable of scheduling for surgeries/procedures
- Capable of capturing and displaying anesthesia evaluation note (pre, intra and post operation)
- May have the capability of capturing and displaying data from medical monitoring devices (mechanical
ventilator,…..)
- Capable of viewing scanned documents such as referrals
- Capable of capturing and displaying discharge, death summary….
- Capable of referring patient electronically
- Capable to receive and send referral feedbacks
- Capable of managing medical certificates, consent based on standard forms
- Capable of displaying a list of services provided and its cost, type of payment (cash, credit, free,
insurance…), cash balance
- Capable of automatically deducting the cost of each procedure or service provided
- Capable of generating standard and custom reports
Minimum Data Set
SN Data Data Data Source Category Relevance(R-

element/field type/Format Report,S-
Service,P-
Patient)
1 Chief Complaint Text | types of Patient Clinical data S,P

CC form/card
2 Duration of C/C Numeric | days Patient Clinical data S,P

since CC started form/Card
3 Physician Text Patient Form Clinical data S,P

evaluation/admissi
on note
4 Risk factor Text patient form Clinical data S,P
5 Underlying Illness Text patient form Clinical data S,P
6 Past Medical Text patient form Clinical data S,P

History
7 Past Surgical Text patient form Clinical data S,P

history
8 Past gyn/obs Text patient form Clinical data S,P

History
9 Family history Text patient form Clinical data S,P
10 Personal/Social Text patient form Clinical data S,P

history
11 Allergy history Text patient form Clinical data S,P
12 Systolic Blood Numeric Vital sign form Clinical data S,P

Pressure
13 Diastolic BP Numeric V/S Form Clinical data S,P
14 Pulse Rate Numeric V/S Form Clinical data S,P
15 Respiratory Rate Numeric V/S Form Clinical data S,P
16 Temperature Numeric V/S Form Clinical data S,P
17 Oxygen Saturation Numeric V/S Form Clinical data S,P
18 Pain Score Numeric V/S form Clinical data S,P
19 Random Blood Numeric V/S Form Clinical Data S,P

Sugar
20 Weight Numeric V/S Form Clinical data S,P
21 Height Numeric V/S Form Clinical data S,P
22 Body Mass Index Numeric V/S Form Clinical Data S,P
22 General Text patient form Clinical Data S,P

Appearance

28 Findings in HEENT Text patient form clinical data S,
29 Findings in LGS text patient form clinical data P,S
30 Findings in Text patient Form clinical data P,S

Respiratory system
31 Findings in Text patient form clinical data P,S

Cardiovascular
system
32 Findings in GIS text patient form clinical data P,S
33 GUS Text Patient form clinical data P,S
34 MSS Text Patient form clinical data P,S
35 Integumentary Text patient form clinical data P,S
36 Nervous system Text Patient form clinical data P,S
37 Assessment text Patient form clinical data P,S
38 Treatment plan text patient form clinical data P,S
40 Investigation order text patient form clinical data P,S
41 Diagnostic test text patient form clinical data P,S

order
42 imaging study text patient form clinical data P,S

order
43 Pathology test text patient form clinical data P,S

order
44 Medication order text patient form clinical data P,S
45 Follow up order text patient form clinical data P,S
46 Nursing care order text patient form P,S
47 progress text patient form clinical data P,S
48 Dietary order patient form clinical data P,S
49 Advice/Counselling text patient form clinical data P,S
50 Appointment text patient form clinical data P,S

(date,working unit)
51 Investigation result numeric/text patient form clinical data P,S
52 Nursing text patient form clinical data P,S

assessment
53 Nursing progress text patient form clinical data P,S
54 Follow up care text patient form clinical data P,S
55 Nursing care text patient form clinical data P,S
56 Medication sheet text patient form clinical data P,S
57 medication profile text patient form clinical data P,S
58 drug therapeutic text patient form clinical data P,S

problem
59 Clinical pharmacist text patient form clinical data P,S

care plan
60 pharmacologic text patient form clinical data P,S

progress
61 medication text patient form clinical data P,S

reconciliation
62 length of stay numeric patient Clinical data R,S

register
63 Bed occupancy Numeric patient clinical data R,S

rate register
64 mortality rate Numeric patient clinical data R,S

register
65 Admission text patient form clinical data R,P,S
66 Admission rate numeric register clinical data R,S
67 Discharge status text patient clinical data P,R,S

register
68 percentage of bed percentage register clinical data R,S

sore
69 Adverse drug text patient form clinical data R,S

reaction
70 care provider text patient form clinical data R,S

name

3. Liaison Module
Description: XXXX
Functionalities:
- Capable of capturing and displaying number of beds in the facility (free, occupied) by department,
ward and sex
- Capable of managing wards, rooms and beds
- Capable of displaying “admission request lists” by admission diagnosis, date, time, admitting physician,
department and ward
- Capable of assigning patients to the appropriate ward, room and bed
- Capable of managing patient appointment schedules including priority setting (Displaying waiting list,
priority patients,
- Capable of scheduling patients for post discharge follow up (to referral clinics/units)
- Capable of managing referral-ins and referral-outs (capable of capturing detail referral information)
- Capability to receive and send referral feedbacks
- Capability to display services received and financial information/payment status about the patient
- Capable to display discharge summary, including post-mortem care
- Capable of capturing and displaying clearance form
- Capable of capturing and displaying death certificate based on a standard form
- Capable of displaying the status of the patients/clients by progress status and final decision, date and
time, final outcome
- Capable of capturing and displaying social services provided to patients
Minimum Data Set
SN Data Data Form Category Relevance (Relevant=R,

Element type/Format Service=S, Patient=P)
/Field
1 Ward Number Numeric Liaison S,P
2 Ward Name Text Liaison R, S, P
3 Room Numeric Liaison S,P

Number
4 Floor Number Numeric Liaison
4 Bed Number` Numeric Liaison S,P,R
5 Medical Numeric Demographic

Record
Number
6 Patient Full Text Demographic S.P

Name

7 Date of Date Liaison S,P,R
Admission
8 admitting Text Uesr S,P

physician
9 Admitting Text OPD S, P, R

department
10 Appointment Date/Time Service S,P,R

date
11 Referred to Service S,P,R
12 Referred from Date Service S,P,R
14 Referred Date Date Service S,P,R
15 Service type Text Service S,P,R

given
16 Price for the Decimal Service S,P,R

service
17 Discharge Date Liaison S,P,R

date
18 Discharge Text Service S,P,R

reason
4. Triage and Registration Module

Description: XXXX
Functionalities:
- Capable of capturing and displaying patient triage information included in the standard triage format
- Capable of capturing basic demographic information such as full name, age, sex, adress, based on a
standrd medical record format (Demographic section of an individual medical record)
- Capable of labelling patients/clients based on the type and severity of case
- Capable of assigning patients to different departments/units
- Capable of assigning Medical Record Number (MRN) automatically for new clients/patients
- Capable of capturing scanned documents such as referrals and other documents
- Capable of displaying inactive medical records
- Capable of displaying summary demographic information about patients/clients
- Capable of displaying the status of the patients/clients by progress status and final decision, date and
time, final outcome
- Capable of interfacing with client registry (MPI)
- Capable of displaying clients/patients with appointments

- Capable of displaying and printing service ID and appointment cards
- Capable of displaying payment method and status of payment
Minimum Data Set
SN Data Element /Field Data type/ Format Form Category Relevance

(Relevant=R,
Service=S,
Patient=P)
1 Patient Type (New, Text Demographic S,P

exiting)
2 New Patient ID Numeric Demographic R, S, P
3 First Name Text Demographic S,P
4 Middle Name Text Demographic S,P
5 Last Name Text Demographic S,P
6 Sex Text Demographic S,P
7 Birth date Date: dd/mm/yyyy Demographic S, P, R

Date
8 Region Text Demographic S,P,R
9 Zone Text Demographic S,P,R
1 Woreda Text Demographic S,P,R
11 Kebele numeric Demographic S,P,R
12 House Number Alphanumeric DEmographic S,P,R
13 Mobile number Alphanumeric Demographic S,P
14 Direct Telephone Alphanumeric Demographic S, P
15 Patient Condition Text Demographic S,P,R

(Severity)
16 Assigned to clinic Text Demographic S,P,R
17 Referral document BLOB Demographic S,P,R
18 Appointment date Date Service S,P,R
19 Payment Type Text Service S,P,R

20 Registration Fee Decimal Service S,P,R
20 Payment status Boolean Service S,P,R
5. Emergency Module
Description: XXXX
Functionalities:
- Capable of identifying, sorting and selecting list of patients assigned to the emergency unit
- Capable of displaying status of emergency patients, by category (Red, yellow, green….)
- Capable of adding new patient form
- Capable of summarizing and displaying patient previous interactions (by date, diagnosis, service unit,
…)
- Capable of displaying specific previous patient interaction to view patient information
- Display summarized previous key patient information (summarized demographic information allergy,
chronic illnesses…)
- Capable to record and display vital signs
- Capable of capturing and displaying patient history: Chief complaint with duration, history of present
illness, past medical/surgical/gynaecological history, social/family history, allergy history as a
- Capable to record and display problem list/diagnosis in a structured form based on the selected
national standard
- Capable of capturing physical examination findings by system (organ system), in a structured form and
free text
- Capable of indicating diagnosis as new and repeat; as main and other diagnosis; presumptive and
confirmed diagnosis
- Capable of ordering laboratory requests, by urgency status
- Capable of transferring patients to other units
- Capable of displaying referral status of patients
- May have the capability to receive and send referral feedbacks
- Capable of communicating with other experts in the facility
- Capable of admitting patients for an inpatient care
- Capable of making appointments
- Capable of displaying list of patients with appointment by date
- Capable of displaying available beds

- capable of managing medical certificates, consent
- Capable of capturing and displaying progress note with structured and free text forms
- Capable of transferring to other units or facilities
- Capable of documenting patient outcome /discharge status
- Display and track list of medicines and supplies in the emergency unit
- Capable of displaying and assigning patients to the appropriate category of beds
- Capable of managing medication administration (by nurses)
- Capable of capturing and displaying procedures performed
Minimum Data Set
SN Data Element /Field Data type/Format Relevance (Relevant=R,

Service=S, Patient=P)
1 Date of Birth Data / dd/mm/yyyy R, S, P
6. Laboratory Module
Description: this module describes standard laboratory information that will be included in EMR for the
purpose of information exchange between healthcare professionals. It focused on bidirectional exchange of
test requests and test results between health care providers, laboratories and patients. it includes
preanalytical, analytical and post analytical phases of the laboratory process.
Functionalities:
- Capable of displaying summary demographic data of patients/clients and diagnosis by different
searching methods
- Capable of displaying laboratory requests from different units, by date and time (All requests and
individual detail request information)
- Display laboratory requests by urgency status
- Capable of listing and sorting requested laboratory tests
- capable of managing pathology services (tests, requests and results)
- Capable of capturing and displaying list of laboratory tests, define its price and reference values
- Capable of capturing and displaying sample information using standard formats
- Capable of generating barcodes
- Capable of capturing and displaying specimen transaction logs, occurrence management logs
- Capable of capturing and displaying blood requests and services based on a standard format

- Capable of receiving lab requests from other facilities and interfacing with reference laboratory
- Capable of interfacing with laboratory machines and equipment
- Capable of managing laboratory reagents, chemicals and supplies
- Capable of capturing and displaying internal quality control data as per the national standard
- Capable of capturing laboratory results
- Capable of managing result validation
- Capable of notifying requesting care providers/phlebotomists about rejected/discarded samples
- Capable of displaying laboratory service payment status
- Capable of sending laboratory results
- Capable of alerting out of range laboratory values
Minimum Data Set
SN Data Element /Field Data Form (data Category Relevance

type/Format source) (Report=R,
Service=S,
Patient=P)
1 patient identification numeric

number
2 unique identifier of the

patient
3 date of birth dd/mm/yyyy demograph S, P

y
4 sex male/female demograph S,P

y
5 region text
6 zone text demograph

y
7 woreda numeric demograph

y
8 kebele numeric demograph

y
9 telephone numeric demograph

y
10 status of the patient text demograph

y

11 laboratory text
departments/sections
12 first name text demograph

y
13 middle name text demograph

y
14 last name text demograph

y
15 name of requesting text

physician
16 location/department alphanumeric
17 telephone numeric
18 destination for the alphanumeric

report and contact
details
19 clinical diagnosis text
20 list of laboratory tests alphanumeric
21 available laboratory alphanumeric

tests
22 examination requested text
23 test urgency/priority text
24 type of primary sample text
25 amount of primary numeric

sample
26 type of sample text

container (description of
any additives)

27 sample transport text
conditions
28 special time of sample alphanumeric

collection
29 history of administration text

of drugs
30 anatomic site of origin text
31 test price estimates numeric
32 payment status text
33 sample collected by text
34 date of primary sample alphanumeric

collection
35 sample transported by text
36 date and time of sample text

receipt
37 sample received by text
38 specimen transaction alphanumeric
39 comments on specimen numeric

quality
40 specimen text
acceptance/rejection
41 reason for rejection text
42 presence of sample text

interference

43 notification alerts to text
authorized health
professionals
44 person notified the alert text
45 type of text
machine/equipment
46 examination text
procedure/principle
where appropriate
47 quality control and alphanumeric

statistical analysis
48 authorities and text

responsibilities (access,
enter and change
patient data and
information, and
authorize the release of
examination results and
reports.
49 test done by text
50 identification of the text

person reviewing the
result and authorizing
release of the report
51 date of the report text
52 Turn around time numeric

monitoring tool
53 date of the report numeric
54 reference interval text
55 panic/critical result text

notification
56 interpretive comments text

on results
57 reagent/stains/ alphanumeric
media...management
58 occurrence text
management log
59 blood and blood

products management
tool
59 organ function tests numeric
ALT
AST
ALP
creatinine
BUN
CBC with differential
CBC
immunophenotyping
(flowcytometrey)
7. Diagnostic and imaging Module

Description: In this module, the minimum requirements for EHR ready EMR system is listed. This module
includes Imaging, and diagnostic Procedural services (Endoscopy, Colonoscopy, etc…) given at a health facility
level providing these services.XXXX
Functionalities:

- Capable of displaying summary demographic, diagnosis, pregnancy, allergy, metal implants, known
chronic diseases, date and time, etc… by different searching methods
- Capable of capturing and displaying patient demographic data and requests from other facilities
- Capable of assigning and register unique identifier for diagnostic and imaging service
- Capable of capturing and displaying list of diagnostic and imaging tests, also defining the price
- Capable of displaying diagnostic and imaging service payment status
- Capable of displaying diagnostic and imaging requests from different units, by date and time (all
requests and individual detail request information), , ordering physician with qualification, reason for
the order
- Capable of listing and sorting requested diagnostic and imaging studies by date and time,
modality,status….
-
- Capable of managing appointment and tracking patients as deemed necessary
- Capable of capturing and displaying preprocedure ‘advice’ notes
- Capable of ordering pharmaceutical related to the procedure
- Capable of ordering laboratory tests
- Capable of capturing and reporting adverse drug reactions
- Capable of adding consent form
- Capable of capturing and displaying diagnostic and imaging result
- Capable of interfacing with diagnostic and imaging equipment
- Capable of interfacing PACS server (including supporting telemedicine services)
- Capable of interfacing RIS, if available
- Capable of managing diagnostic and imaging pharmaceuticals stored at the unit
- Capable of capturing and displaying procedure note
- Capable of forwarding the captured image to other facilities
- Capability of managing available diagnostic and imaging tests
Minimum Data Set
SN Data Element Data type/Format Form Category Relevance

/Field (Report=R,
Service=S,
Patient=P)
1 Date of Birth Date | Demography R, S, P

dd/mm/yyyy
2 Imaging Numeric Radiology P,S

ID/Study ID
2 Patient Category Text Demographic S,P,R

(internal,
External)
2 Patient Record Text Demography S,P

Number (MRN)

3 First Name Text Demography S,P
4 Middle Name Text Demography S,P
5 Last Name Text Demography S,P
Phone no. Numeric S, P
Address Text S, P, R
Diagnostic Text Service S, P, R

study/interventi
on ordered
Reason for Text Service S,P,R

order
Referring/ Text Service S,P,R

Ordering
physician
Order date Date Time Stamp R,S
Reading priority Alphanumeric Service S,P,R

Status
Patient order Text Service S,P,R

status
6 Diagnostic Text Service SPR

ModalityCategor
y
7 Known Chronic Text Service SPR

disease
Allergic reaction Text Service S,P,R
Protocol of alphanumeric Service S,P,R

study
Protocol Date Date Time Stamp R,S
Diagnosis Text Service S,P,R
Laboratory Alphanumeric S,P,R

Results
History & Text S,P,R

Physical
Examination

Previous Image/Blob S,P, R
Imaging studies
Previous Text S,P,R

Imaging studies
report
Previous Image Date Time Stamp R,S

study report
date
Pre procedure Text/Boolean S,P,R

checklist
Procedure Note Text S,P,R
Drug name Text S,P,R
Drug dosage Text S,P,R
Procedure Text S,P,R

performed by
Patient consent Text P,S,R
Procedure date Date Time Stamp R,S
8 Diagnostic image/ BLOB Service S,P,R

image
Diagnostic Text S,P,R

report
9 Diagnostic Date/Time Time Stamp S,P,R

report Date
Reported by Text S,P,R
9 Diagnostic Price Decimal Service S,P,R
10 payment status Boolean Billing S,P,R
11 Appointment Date/Time Service S,P,R

date
12 Advice note Text Service S,P,R
13 List of Text pharmaceutical S,P,R

pharmaceutical
List of Text Laboratory S,P,R

laboratory tests

TAT monitoring
tool
User
privileges/roles
8. Pharmacy module
Description: XXXX
Functionalities:
- Capable of receiving and listing prescriptions as per the standard prescription formats (Normal,
Narcotics and psychotropics prescriptions)
- Capable of displaying prescription orders for individual patients/clients
- Capable of displaying summary demographic, allergy history and diagnosis of patients
- Capable of capturing drug therapy commentary to the prescriber, if there is an identified issue
- Capable of displaying list of available pharmaceuticals along with full drug information in the
dispensing unit and in the store
- Capable of handling medicines that require compounding
- Capable of capturing prescription information for patients from other health facilities/over the
counter medicines
- Capable of deducting cost of pharmaceuticals dispensed
- Capable to display payment type (credit, exempted, insurance, paying) of patients/clients
- Capable of displaying payment status and receipt number for paying patients;
- Capable to capture and display type of dispensing counselling provided with a standard format
- Capable of displaying and printing pharmaceuticals counselling information
- Capable of sending and receiving e-prescriptions to and from institutions
- Capable of displaying and printing undispensed medicines
- Capable of forecasting and supply planning of pharmaceuticals
- Capable of capturing list of pharmaceuticals/formularies based on a selected standard
- Capable of producing requests from service delivery units (internal facility request and re-supply (IFRR)
to facility warehouse
- Capable of producing requests from (RRF) facility warehouse to EPSA or private suppliers
- Capable of receiving pharmaceuticals from facility store to service units
- Capable of receiving pharmaceuticals from EPSA or other sources to facility store
- Capable of issuing pharmaceuticals from facility to facility
- Capable of managing inventory and stock management including loss/adjustment
- Capability to display list of expired/unusable stock at service delivery point
- Capability to manage drug information service
- Capable of sending alert or reminder for medicines out of stock or with near expiry date
- Clinical pharmacy service
Minimum Data Set
SN Data Element /Field Data type/Format Form (Data source) Category Relevance
(Report=R,
Service=S,

Patient=P)
1 Diagnosis text prescription R,S,p
2 Drug name-Generic Text prescription R,S
3 Drug strength Text prescription R,S
4 dosage form prescription
5 dose text: program, RDF, prescription R,S,P

donation...
6 frequency text; prescription R,S,P

QD,BID,TID,QID,PRN
7 duration text prescription R,S,P
8 quantity text prescription R,S,P
9 route of administration text prescription R,S,P
10 Date of prescription written dd/mm/yy prescription R,S,P
11 prescribers information text prescription R,S,P

(Name, qualification,
registration number,
signature)
12 evaluator information (Name, text prescription R,S,P

qualification, registration
number, signature)
13 counsellor’s information text prescription R,S,P

(Name, qualification,
registration number,
signature)
14 reporting period dd/mm/yy RRF

15 maximum stock level text RRF
16 minimum stock level text RRF
1718 emergency order level text RRF
19 product code text RRF
20 product description text RRF
21 unit of issue text RRF
22 beginning balance text RRF
23 quantity received text RRF
24 loss/adjustment text RRF
25 ending balance (inpharmacies, text RRF

SDU and Stores)
26 calculated consumption text RRF
27 days out of stock text RRF
28 maximum stock quantity text RRF
29 quantity needed to reach text RRF

maximum
30 quantity ordered text RRF
31 near expiry stock description text RRF
32 detail of completed text,dd/mm/yy RRF

by,verified by approved by
(Name,sign,date)

33 reporting period dd/mm/yy IFRR
34 maximum stock level text IFRR
35 minimum stock level text IFRR
36 emergency order level text IFRR
37 product code text IFRR
38 product description text IFRR
39 unit of issue text IFRR
40 beginning balance text IFRR
41 quantity received text IFRR
42 loss/adjustment text IFRR
43 ending balance text IFRR
44 calculated consumption text IFRR
45 days out of stock text IFRR
46 maximum stock quantity text IFRR
47 quantity needed to reach text IFRR

maximum
48 quantity ordered text IFRR
49 near expiry stock description text IFRR
50 detail of completed text,dd/mm/yy IFRR

by,verified by approved by
(Name,sign,date)

51 product name bin card
52 product strength bin card
53 product dosage form bin card
54 unit of issue bin card
55 date bin card
56 receiving/issuing vaucher bin card

number
57 received from or issued to bin card
58 quantity received bin card
59 quantity issued bin card
60 loss adjustment bin card
61 balance bin card
62 batch number bin card
63 expiry date bin card
64 remark bin card
65 product name stock record card
66 product strength stock record card
67 product dosage form stock record card
68 unit of issue stock record card

69 maximum stock level stock record card
70 emergency order level stock record card
71 date stock record card
72 receiving/issuing vaucher stock record card

number
73 received from or issued to stock record card
74 quantity received stock record card
75 quantity issued stock record card
76 loss adjustment stock record card
77 balance stock record card
78 unit price stock record card
79 batch number stock record card
80 expiry date stock record card
81 remark stock record card
82 receiver detail model 19
83 date model 19
84 s.no model 19
85 drug code model 19
86 Description of Drugs, model 19

Reagents, Medical Supplies,

87 unit model 19
88 quantity received model 19
89 unit cosst model 19
90 total cost model 19
91 batch number model 19
92 expiry date model 19
93 remark model 19
94 delivered by, received by model 19

(name,sign)
95 issuer detail(name) model 22
96 date model 22
97 s.no model 22
98 drug code model 22
99 Description of Drugs, model 22

Reagents, Medical Supplies,
100 unit model 22
101 quantity issued model 22
102
unit cost model 22

102
total cost model 22
unit selling price model 22

retail price per retail unit model 22
remark model 22
issued by, received by model 22

(name,sign)
patient demography cash/credit sales ticket
date dd/yy/mm cash/credit sales ticket
product code cash/credit sales ticket
product description cash/credit sales ticket

(Drug/Reagent/ Supplies/
Name Strength, Dosage Form)
retail unit cash/credit sales ticket
retail quantity cash/credit sales ticket
retail price cash/credit sales ticket
total retail price cash/credit sales ticket
signature of dispenser and cash/credit sales ticket

casher
Name of Patient and Bed Drugs & Medical Supplies health

Number (for inpatient) insurance Consumption
Registration Book
card number Drugs & Medical Supplies health

insurance Consumption
Registration Book

age Drugs & Medical Supplies health
Registration Book
sex Drugs & Medical Supplies health

Registration Book
name of insurer(sponsor Drugs & Medical Supplies health

organization) insurance Consumption
Registration Book
product code Drugs & Medical Supplies health

Registration Book
product description Drugs & Medical Supplies health

Registration Book
total quantity Drugs & Medical Supplies health

Registration Book
retail price Drugs & Medical Supplies health

Registration Book
total retail price Drugs & Medical Supplies health

Registration Book
patient/care giver signature Drugs & Medical Supplies health

Registration Book

Service provider detail Drugs & Medical Supplies health
(name,date,sign) insurance Consumption
Registration Book
name of service provider Daily Cash Dispensary Summary

Form
number of tickets used Daily Cash Dispensary Summary

Form
total cash collected (medicine, Daily Cash Dispensary Summary

compounding fee) Form
over/under collected Daily Cash/ credit Dispensary

Summary Form
total number of drugs Daily Cash Dispensary Summary

dispensed by type Form
total adjusted sales Daily Cash Dispensary Summary

Form
total number of voided tickets
signature Daily Cash Dispensary Summary

Form
date SDU, Pharmacies Inventory form
S.no SDU, Pharmacies Inventory form
product code SDU, Pharmacies Inventory form
product description SDU, Pharmacies Inventory form

retail unit SDU, Pharmacies Inventory form
batch number SDU, Pharmacies Inventory form
retail price SDU, Pharmacies Inventory form
expiry date SDU, Pharmacies Inventory form
physical quantity SDU, Pharmacies Inventory form
unit cost SDU, Pharmacies Inventory form
total cost SDU, Pharmacies Inventory form
location information (type SDU, Pharmacies Inventory form

and number of bin)
remark SDU, Pharmacies Inventory form
inventory registered by, SDU, Pharmacies Inventory form

counted by, recounted
by(name,sign)
responsible persons SDU, Pharmacies Inventory form

(name,sign)
date store inventory form
S.no store inventory form
product code store inventory form
product description store inventory form
retail unit store inventory form
batch number store inventory form

discrepancy store inventory form
expiry date store inventory form
physical quantity store inventory form
unit cost store inventory form
total cost store inventory form
remark store inventory form
location information (type store inventory form

and number of bin)
inventory registered by, store inventory form

counted by, recounted
by(name,sign)
responsible persons store inventory form

(name,sign)
product description Stock Status Analysis Form (SSA)
Unit Stock Status Analysis Form (SSA)
Total Stock at hand & ordered Stock Status Analysis Form (SSA)
Expiry Date Stock Status Analysis Form (SSA)
Average Monthly or last Stock Status Analysis Form (SSA)

month Consumption if
increasing
Months of Stock (MOS) Stock Status Analysis Form (SSA)

Stock could be enough for
months
Until expiry, the amount of Stock Status Analysis Form (SSA)

stock that could be consumed
Overstock (will expire Stock Status Analysis Form (SSA)
unless measure is taken )
additional stock needed for Stock Status Analysis Form (SSA)

the next 4 months (stock in
unit,stock in months)
Total cost of beginning stock Monthly Financial Reporting Form R,S

at dispensing outlets/Service (MFRF):
delivery (SD) units
Total cost of stock received Monthly Financial Reporting Form R,S

from store during the month (MFRF):
Cost of stock available for sale Monthly Financial Reporting Form R,S
(MFRF):
Total cost of medicines Monthly Financial Reporting Form R,S

dispensed/administered (MFRF):
(cash,credit, insurance)

damaged (MFRF):

expired (MFRF):
Total cost of ending balance Monthly Financial Reporting Form R,S

(calculated) (MFRF):
Total cost of stock on hand Monthly Financial Reporting Form R,S

(from physical inventory) (MFRF):
discrepancy Monthly Financial Reporting Form R,S

(MFRF):

at the pharmacy store (MFRF):
Total cost of stock received by Monthly Financial Reporting Form R,S

the pharmacy store (MFRF):
(MFRF):
Total cost of medicines issued Monthly Financial Reporting Form R,S

to dispensing outlets & SD (MFRF):
units

damaged (MFRF):

expired (MFRF):


discrepancy Monthly Financial Reporting Form R,S

(MFRF):

(Store + Dispensary + SD (MFRF):
Unites)
Total cost of stock received Monthly Financial Reporting Form R,S

(by the Pharmacy Store) (MFRF):
(MFRF):

dispensed at dispensing (MFRF):
outlets & service delivery
units (converted from total
sales into cost)

damaged (Store + Dispensary (MFRF):
+ SD Unites)

expired (Store + Dispensary + (MFRF):
SD Unites)


Discrepancy, if any Monthly Financial Reporting Form R,S

(MFRF):
Total Sales (at price) = sum of Monthly Financial Reporting Form R,S
daily sales of the month (MFRF):
Total Cost of Sales (Credit, Monthly Financial Reporting Form R,S

Cash) = Total Sales/(1+Profit (MFRF):
margin)
Gross profit= Total Sales – Monthly Financial Reporting Form R,S

(Total Cost of Sales) (MFRF):
Total Expenses = (Salary, Monthly Financial Reporting Form R,S

Stationary, Telephone, (MFRF):
Transportation etc…)
Net income = Gross profit – Monthly Financial Reporting Form R,S

(Total Expense) (MFRF):
Total number of patients Number of cash sales tickets

Served by cash R,S
Total number of patients number of credit sales tickets or

Served by credit number patients on credit sales R,S
register
Total number of patients Number patients on free sales

Served for free register /free patients R,S
Total number of patients Number patients on staff sales

Served by staff service register R,S

Total number of patients Number patients on maternity
Served by maternity service sales register R,S
Total number of patients Number of cash sales tickets plus

served per month number of credit sales tickets or R,S
number patients on credit sales
register plus number of free
patients including staff
Average number of patients Total number of patients served

served per day per month divided by total R,S
number of working days
Average number of patients Total number of patients served

served per dispenser per divided by number of dispensers R,S
month
Number of medicines use Number of medicines (by type)

counseling sessions held dispensed to credit, cash, and R,S
monthly per dispenser free clients by each dispenser
obtained from daily summary
Number of drug use Number of medicines (by type)

counseling held monthly per dispensed to credit, cash and free R,S
health facility clients (Obtained from daily
summary)
Average number of Number of medicines (by type)

medicines per encounter or dispensed to credit, cash, and R,S
patient free clients divided by number of
patients obtained from daily
summary
Average price of medicines Total sales divided by (number of

dispensed per patient cash sales ticket plus number of R,S
credit sales ticket or number of
patients on credit sales register)
Average price of a single Total sales divided by total

medicine number of medicines by type R,S

Affordability of medicines Average prices of medicines
dispensed in the health dispensed for a single patient of R,S
facility those who spend out-of-pocket
compared with 10% of per capita
income of smallest salary paid to
a single government employees
Consumption to Stock Ratio Cost of Medicines sold during the

period divided by stock available R,S
for sale times 100
Stock available for sale is

beginning stock plus received stock
Percentage availability of Number of indicator medicines

indicator medicines (at least available continuously during the R,S
15 medicines used to treat reporting period divided by total
10 top diseases) number of indicator medicines
times 100
Stock turnover rate Cost of medicines sold during the

period divided by average R,S
inventory Average inventory is
beginning plus ending divided by
two
Wastage (expired Total medicines wasted during

the reporting period divided by R,S
+ damaged) rate in percent total stock available in Birr of the
reporting period times 100
patient demography compounding prescription

registration form
card number compounding prescription

registration form
diagnosis compounding prescription

registration form
description of the preparation compounding prescription

registration form

ingredients (name, strength compounding prescription
and quantity) registration form
quantity dispensed compounding prescription

registration form
control number compounding prescription

registration form
compounder’s detail (name, compounding prescription

sign, date) registration form
date compounding process registration

form
batch number/control compounding process registration

number form
batch quantity compounding process registration

form
description of ingredients compounding process registration

(name, source, batch number, form
quantity)
description of steps during compounding process registration

preparation form
beyond use date compounding process registration

form
yield, loss, reason compounding process registration

form
compounder name,sign,date compounding process registration

form
end control before product compounding process registration

release (quality assurance, form
parameters, comment)
approver name,sign, date compounding process registration

form
date record for reverse logistics
From/to record for reverse logistics
item description record for reverse logistics
unit record for reverse logistics
quantity returned record for reverse logistics
reason for return/ non use record for reverse logistics
sending, receiving and carrier record for reverse logistics

certification (name,sign and
date)
patient information inpatient medication profile form
past medical history inpatient medication profile form
past medication history and inpatient medication profile form

adherence
ADR and or allergies inpatient medication profile form
immunization status inpatient medication profile form
current medications inpatient medication profile form

(indication, drug and dosage
regimen, start date, end date)
pharmacist assessment and inpatient medication profile form

care plan
recommendations and inpatient medication profile form

interventions

discharge medications and inpatient medication profile form
counselling
patient information pharmaceutical care progress note

recording sheet
card number pharmaceutical care progress note

recording sheet
260 patient information medication reconciliation form
261 history of allergies medication reconciliation form
263 medication information medication reconciliation form
264 pre admission medication medication reconciliation form

(regimen, plan on admission,
plan on transfer, plan on
discharge,
adjustments/changes made)
265 current medication (regimen, medication reconciliation form

plan on admission, plan on
transfer, plan on discharge,
adjustments/changes made)
9. Billing Module
description
functionalities:
- Capable of setting billing or payment type ( credit, free, insurance, self care-by payment method)
- Capable of managing insurance and credit services
- Capable of managing service price
- Capable of displaying customers’ demographic data, payment and service type
- Capable of computing total price, balance,....
- Capable of generating invoice including serial number, reason for payment
- Capable of generating billing reports
- Capable of handling transactions (invalid or voidable transactions,....)
-
Minimum Data Set
SN Data Element /Field Data type/Format Category Relevance

(Report=R,
Service=S,
Patient=P)
1 Billing ID or invoice Autonumber Autogenerated

number
2 Billing Date Date/time Time stamp RSP
3 Medical Record Numeric Demographic PS

Number
4 First Name Text Demographic P,S
5 Middle Name Text Demographic P,S
6 Last Name Text Demographic P,S
7 Payment type (credit, Demographic Service PSR

insurance, Self care..)
8 Payment Text Service PSR

Method(Bank
transfer, Cash)
9 Services ID Text Service PSR
10 Description Text Service
11 Date of Service Date/Time Service PSR

obtained
12 Unit of Measurement Text Service
13 Amount of the service Numeric Service SP

given
14 Unit price of the Decimal Service SPR

service
10. Maternal, neonatal and child health module

Description: XXXX
Functionalities:
- Capable of identifying, sorting and selecting list of patients assigned to respective service units
- Capable of displaying status of patients/clients (as waiting, on progress, complete…)
- Capable of adding new patient/client standard service specific formats
- Capable of displaying list of summerized patient’s/client’s previous interactions (by date, parity,
gravidity, abortion, gestational age, diagnosis, service unit, demographic information,allergy, chronic
illnesses…)

- Capable of displaying specific previous patient’s/client’s interaction to view detailed information
- Capable of capturing and viewing scanned documents such as referrals
- Capable of capturing and displaying family planning service information based on standard format
(including list of methods, counselling, side effect, etc..)
- Capable of capturing and displaying comprehensive abortion care service based on standard formats
- Capable of capturing and displaying cervical cancer screening and treatment services based on
standard formats
- Capable of capturing and displaying ANC service information based on standard formats
- Capable of capturing and displaying PMTCT service information based on standard format
- Capable of capturing and displaying labor and delivery (including partograph,...) related information
based on standard format
- Capable of capturing and displaying postnatal service information based on standard format
- Capable of managing immunization and growth monitoring service information based on standard
format
- Capable of managing IMNCI service information based on standard format
pregnancy, past medical/surgical/gynaecological history, social/family history, allergy history as a
national standard
free text
confirmed diagnosis
- Capable of ordering laboratory requests
- Capable of admitting patients for inpatient care (high risk maternal ward, NICU,...)
- Capable of displaying list of patients/clients with appointment by date
- capable of managing medical certificates, birth certificate, consent
Minimum Data Set

SN Data Element Data type/Format Format (Data Category Relevance
/Field Source) (Report=R,
Service=S,
Patient=P)
General medical and obstetric history
Past medical Text | DM, HPN, Cardia, Woman’s Card; General Medical S, P
history renal, T, HIV etc... Integrated RH information
card
Previous Obstetric Date | DD/MM/YYYY Woman’s Card; Previous Obstetric S, P

history_Year of Integrated RH history
pregnancy card
Previous Obstetric Text | Delivery, abortion Woman’s Card; Previous Obstetric S, P

history_Outcome Integrated RH history
of pregnancy card
Previous Obstetric Text | SVD, C/S etc... Woman’s Card; Previous Obstetric S, P
history_mode of Integrated RH history
delivery card
Previous Obstetric Text | Yes/no, type of Woman’s Card; Previous Obstetric S, P

history_Complica complication Integrated RH history
tions card
Status of Current Pregnancy
Multiple Text | Yes/No Integrated RH Current Pregnancy S, P

pregnancy card
Age more than 40 Text | yes/no Integrated RH Current Pregnancy S, P

card
Age less than 16 Text | yes/no Integrated RH Current Pregnancy S, P

card
RH Text | yes/no Integrated RH Current Pregnancy S, P

isoimmunization card
Vaginal bleeding Text | yes/no Integrated RH Current Pregnancy S, P

card
Pelvic mass Text | yes/no Integrated RH Current Pregnancy S, P

card
Laboratory Investigations and Prescriptions
Laboratory tests Date | DD/MM/YYYY Lab order form General Medical S,P
performed_Date information

Laboratory tests Text | the lab test Lab order form General Medical S,P
performed_type information
of test
Laboratory tests Text | test result Lab order form General Medical S,P
performed_result information
Prescriptions Date | DD/MM/YYYY prescription General Medical S,P

provided_Date order form information
Prescriptions_Dru Text | medicine prescription General Medical S,P

g name order form information
Family Planning Data
Date of visit Date | DD/MM/YYYY Woman’s card Family Planning S
Blood Pressure Numeric | Woman’s Card Vital Sign S, P

Systolic/Diastolic
Weight Numeric | in Kg Woman's card S, P
Type of FP clients Text | New or Repeat Family Planning R, S, P
Type of FP Text | Name of Woman’s Card Family Planning R, S, P

method provided contraceptive
Reason for Text | list of reasons for Woman’s Card Family Planning S, P
method switch changing FP methods
Date of next visit Date | DD/MM/YY Woman’s Card Family Planning S, P
TT immunization data
Date of Date | DD/MM/YYYY Woman’s Card TT vaccination S, P

vaccination
TT vaccination Text | TT1 to TT5 Woman’s Card TT Vaccination R, S, P

provided
Counselling and testing
Counselling date Date | DD/MM/YYYY Woman’s Card Counselling and S, P

testing
Counselling Text | yes/No Woman’s Card Counselling and S, P

service testing
provided_STI

service testing
provided_HIV

service testing
provided_FP

service testing
provided_Others
Testing result for Text | positive, negative Woman’s Card; Counselling and R, S, P
HIV Integrated RH testing
card
Testing result for Text | positive, negative Woman’s Card; Counselling and R, S, P
VDRL Integrated RH testing
card
Antenatal care service
General Text | Pallor, jaundice, Integrated RH Initial Evaluation, S, P

examination chest, heart etc,.... card Promotive and
Preventive Care
Gyn exam Text | Vulva, vaginal Integrated RH Initial Evaluation, S, P

exam, pelvic mass, card Promotive and
uterine size, cervical Preventive Care
lesion etc,....
Danger signs Text | Yes/No; the sign…. Integrated RH Initial Evaluation, S, P

card Promotive and
Preventive Care
Date of visit Date| DD/MM/YYYY Integrated RH Current Pregnancy S, P

card Follow up
Visit number Number | 1, 2, 3, 4…. Integrated RH Current Pregnancy R, S, P

card Follow up
Gestational Age Numeric| in weeks Integrated RH Current Pregnancy S, P

card Follow up
BP Numeric | Integrated RH Current Pregnancy S, P

Systolic/Diastolic card Follow up
Weight Numeric | in Kg Integrated RH Current Pregnancy S, P

card Follow up
Pallor Text | yes/No Integrated RH Current Pregnancy S, P

card Follow up
Uterine height In weeks Integrated RH Current Pregnancy S, P

card Follow up
Fetal Heartbeat Numeric | Integrated RH Current Pregnancy S, P

card Follow up

Uterine test Text | Test and its result Integrated RH Current Pregnancy S, P
card Follow up
Blood group and Lab order form Current Pregnancy S, P

RH test result Follow up
Iron folate Alpha-numeric | name Integrated RH Current Pregnancy S, P

and dose card Follow up
Next appointment Date | DD/MM/YYYY Integrated RH Current Pregnancy S, P

date card Follow up
Danger signs and Text | name of sign and Integrated RH Current Pregnancy S, P
investigations type of investigation card Follow up
Intrapartum care (Monitoring labour)
Date and time of Date and time Partograph Labor follow up S, P

admission
Rupture of Text \ Yes or no Partograph Labor follow up S, P

membranes
Rupture of Time | HH:MM:SS Partograph Labor follow up S, P

membranes_Time
Fetal heartbeat Per minute Partograph Labor follow up S, P
Amniotic fluid Partograph Labor follow up S, P
Moulding Text Partograph Labor follow up S, P
Cervical dilation In cm Partograph Labor follow up S, P
Contractions per Number Partograph Labor follow up S, P

10 min
Oxytocin (U/L) U/L Partograph Labor follow up S, P
Oxytocin Drops per minute Partograph Labor follow up S, P

(drops/min)
Drugs and fluids Name of drug and fluid Partograph Labor follow up S, P
given
Pulse Number per minute Partograph Labor follow up S, P
BP Systolic/Diastolic Partograph Labor follow up S, P
Temperature In degree Celsius Partograph Labor follow up S, P
Urine_Protein Alphanumeric Partograph Labor follow up S, P
Urine_Acetone Alphanumeric Partograph Labor follow up S, P
Urine_Volume Alphanumeric Partograph Labor follow up S, P

Delivery Summary
Delivery date and Date and Time | Integrated RH Delivery Summary R, S, P

time DD/MM/YYYY; card
HH:MM:SS
Mode of delivery Text | Spontaneous, C/S, Integrated RH Delivery Summary R, S, P

episiotomy,instrumental. card
..
Active third stage Text | Erogetrine, Integrated RH Delivery Summary S, P

of labour oxytocin, misoprostol card
management etc...
Placenta Text | Completed, Integrated RH Delivery Summary S, P

incomplete , etc... card
Laceration Text | Yes/No, 1st Integrated RH Delivery Summary S, P

degree, 2nd degree, 3rd card
degree
Newborn_number Text | Single, multiple Integrated RH Delivery Summary S, P

card
Newborn_Sex Text | male, female Integrated RH Delivery Summary R, S, P

card
Newborn_Apgar Numeric Integrated RH Delivery Summary S, P

score card
Newborn_Weigt Numeric | in grams Integrated RH Delivery Summary R, S, P

card
Newborn_height Numeric | in cms Integrated RH Delivery Summary S, P

card
Newborn_GA Text|term, preterm Integrated RH Delivery Summary R, S, P

card
Still birth Text | Yes or no Integrated RH Delivery Summary R, S, P

card
Still birth_status Text | Macerated, fresh Integrated RH Delivery Summary S, P

card
Newborn_vaccine Text | BCG, Vit K, TTC Integrated RH Delivery Summary S, P

and medication etc... card
Obstetric Text | List of Integrated RH Delivery Summary R, S, P

complications complications card
Postnatal care
Date and number Date |DD/MM/YYYY Integrated RH Postnatal care R, S, P

of visit card
VItal signs (BP, Numeric Integrated RH Postnatal care R, S, P

pulse, Temp…) card
Uterine Text Integrated RH Postnatal care R, S, P

contraction card
Urine Text Integrated RH Postnatal care R, S, P

card
Vaginal discharge Text Integrated RH Postnatal care R, S, P

card
Preventions Text | Vit A, EPI... Integrated RH Postnatal care R, S, P

provided card
Newborn status Text | healthy, sick…. Integrated RH Postnatal care R, S, P

card
linkage of HIV pos Text Integrated RH Postnatal care R, S, P

to HIV clinic card
Immunization and GM
Date of Date and number Immunization Immunization and R, S, P

registration and card GM
number of visit
Antigens received Text | the name of Immunization Immunization and R, S, P

antigen provided card GM
Neonatal tetanus Text | Status of maternal Immunization Immunization and R, S, P

protection TT immunization card GM
Weight Numeric | in kg Immunization Immunization and R, S, P

card GM
WFA Z score Immunization Immunization and R, S, P

card GM
Under 5 clinic services

11. Non-Communicable Diseases (NCD) Module
Description
Functionalities:
- Capable of identifying, sorting and selecting list of patients assigned to the unit
- Capable of displaying the status of NCD patients (waiting, on progress, complete…)
- Capable of summarizing and displaying patient previous interactions (by date, diagnosis, service unit,
…)
chronic illnesses, status of the NCD, investigation results, other relevant information…)
national standard
free text
- Capable of capturing and displaying NCD information as per a specific NCD format
confirmed diagnosis
Minimum Data Set

(Report=R,
Service=S,
Patient=P)
1 Date of Birth Date | dd/mm/yyyy Demography R, S, P
12. HIV Care /ART follow up Module

Description: HIV Care/ART follow up module is a module that has the functionality of registering and capturing
data related to patients who are chronic HIV care. It also includes information about clients who receive HIV
testing services. The module should include all required functionalities and data elements based on the
standard “ART patient monitoring guideline”, which is developed and implemented by the Ministry of Health
of Ethiopia. It should include capturing and displaying data from HIV intake forms A and B, chronic HIV care
follow up form, HIV testing forms and other standard HIV related formats. The minimum functionalities and
data elements of the module are described below.
Functionalities:
- Capable of summarizing and displaying patient information/dashboard (basic demographic
information, Address, MRN, unique ART number, type of test, other relevant information…)
- Capable of capturing and generating unique ART number
- Capable of managing HIV test information by different modalities (VCT, index testing etc…) based on a
standard format
- Capable of capturing and displaying ART intake forms
- Capable of capturing and displaying ART follow up form
- Capable for capturing and displaying TB screening information for registered HIV patients
- Capable of generating reminders to care providers whenever there are missed appointments, lost, lost
to follow up (LTFU) pts, drop
- Capable of displaying list of patients who are eligible for viral load test
- Capable of capturing and displaying patients who are on DSD (Differentiated service delivery model)
- Capable of capturing and displaying enhanced adherence counselling form
- Capable of capturing and displaying PMTCT information ( both for the mother and HIV exposed
infants)
- Capable of ordering and receiving viral load tests and its result
- Capable of managing transfer-in and transfer-out patients
- Capable of managing pre-exposure and post-exposure prophylaxis based on a standard form
- Capable of identifying, sorting and selecting list of ART patients assigned to different ART units
- Capable of displaying status of ART patients (waiting, on progress, complete…)
chronic illnesses…)

national standard
- Capable of displaying risk factors for NCDs
- Capable of capturing and displaying NCD screening and its result based on standard format
free text
confirmed diagnosis
- Capable of generating cohort report
Minimum Data Set
S.No. Data element Data type/format Form (Data Category Relevance

source) (Report=R,
Service=S,
Patient=P)
Socio-demographic and family care

Name Text| First name, ART intake Socio- S, P
Father, Grand form demographic
father’s name and family care
Date of birth Date | ART intake Socio- R, S, P

DD/MM/YYYY form demographic
and family care
Date of registration Date | ART intake Socio- S, P

and family care
Sex Text | Male or ART intake Socio- R, S, P

Female form demographic
and family care
Marital status Text|Married, ART intake Socio- S, P

single, separated, form demographic
widow etc and family care
Address: Region Text| name of ART intake Socio- S, P

region form demographic
and family care
Address: Zone/Woreda Text | Zzone, ART intake Socio- S,P

woreda form demographic
and family care
Address: household Alpha numeric ART intake Socio- S,P

number form demographic
and family care
Telephone Number|+251----- ART intake Socio- S, P

form demographic
and family care
Contact information Text| Name ART intake Socio- S, P

form demographic
and family care

MRN Number | 000000 ART intake Socio- S, P
six digits form demographic
and family care
Unique ART number Number | ART intake Socio- S, P

form demographic
and family care
Date of HIV test Date | ART intake Socio- S, P

and family care
Date tested HIV positive Date | ART intake Socio- S, P

and family care
Past medical history Text Socio- S, P

demographic
and family care
Past opportunistic Text Socio- S, P

infection demographic
and family care
Past Text Socio- S, P

prophylaxis/treatment demographic
and family care
All other data in intake Text, numeric Socio- R, S, P

form A and B demographic
and family care
Status at entry to HIV care
Functional status Text ART intake Status at S, P

form entry to HIV
care
Weight Numeric ART intake Status at S, P

form entry to HIV

care
Height/length Numeric ART intake Status at S, P

form entry to HIV
care
MUAC Numeric ART intake Status at R, S, P

form entry to HIV
care
BMI/Weight for age Numeric ART intake Status at R, S, P

form entry to HIV
care
Nutrition screening Text ART intake Status at R, S, P

status/Food support form entry to HIV
care
Viral load Numeric ART intake Status at R, S, P

form entry to HIV
care
TB/HIV co-infection
Screening for TB Text ART followup TB/HIV co- R, S, P

form infection
TB screening result Text ART followup TB/HIV co- R, S, P

form infection
GeneXpert and its result Text ART followup TB/HIV co- R, S, P

form infection
TB treatment start and Date | ART followup TB/HIV co- S, P

end date DD/MM/YYYY form infection
INH prophylaxis Text ART followup TB/HIV co- R, S, P

form infection

Other prophylaxis Text ART followup TB/HIV co- S, P
form infection
ART follow up and summary
Date ART is started Date | ART followup ART follow up S, P

DD/MM/YYYY form
Original regimen Text|Code of 1st ART followup ART follow up R,S,P

line regimen form
Substitution regimen 1st Text|Code of 1st ART followup ART follow up R,S,P
line line regimen form
Reason for substitution Text|Code of ART followup ART follow up S,P

reason form
Switched regimen to 2nd Text|Code of 2nd ART followup ART follow up R,S,P
Reason for switch Text|Code of ART followup ART follow up S,P

reason for switch form
Switched regimen to 3rd Text|Code of 2nd ART followup ART follow up R,S,P
Reason for switch Text|Code of ART followup ART follow up S,P

reason for switch form
Functional status Text|Coded status ART followup ART follow up S,P

form
Weight Numeric ART followup ART follow up S, P

form
Height/length Numeric ART followup ART follow up S, P

form

MUAC Numeric ART followup ART follow up R, S, P
form
BMI/Weight for age Numeric ART followup ART follow up R, S, P

form
Nutrition screening Text ART followup ART follow up R, S, P

status/Food support form
Date Viral load is tested Date | ART followup ART follow up S, P

DD/MM/YYYY form
Viral load Alpha numeric ART followup ART follow up R, S, P

(detectable/undetectable form
Enrollment date to Date | ART followup ART follow up R, S, P

appointment spacing DD/MM/YYYY form
model
Cotrimoxazole start date Date | ART followup ART follow up R, S, P

DD/MM/YYYY form
Cotrimoxazole stop date Date | ART followup ART follow up S, P

DD/MM/YYYY form
Use of family planning Text (FP used) ART followup ART follow up R, S, P
form
ART interruption date Date | ART followup ART follow up R, S, P

DD/MM/YYYY form
Lost status Text (Yes/No) ART followup ART follow up R, S, P

form
Lost date Date | ART followup ART follow up R, S, P

DD/MM/YYYY form
Lost to follow up status Text (LTFU or not) ART followup ART follow up R, S, P
form

Lost to follow up date Date | ART followup ART follow up S, P
DD/MM/YYYY form
Drop status Text (drop from Rx ART followup ART follow up R, S, P

o not) form
Drop date Date | ART followup ART follow up R, S, P

DD/MM/YYYY form
Death date Date | ART followup ART follow up R, S, P

DD/MM/YYYY form
Transfer out date Date | ART followup ART follow up R, S, P

DD/MM/YYYY form
Other information
New diagnosis/OIs Text Patient form Patient card R,S,P
Admission Patient form Patient card R, S, P
Laboratory tests done Text Lab request R,S,P

from
Laboratory result Alphanumeric Lab request S,P

form
Prescriptions Text Prescription S,P

from
Referral to PMTCT Text ART follow up S,P

form
Referral to other facilities Text Referral from
13. Tuberculosis Module

Description: XXX

Functionalities:
- Capable of summarizing and displaying patient information/dashboard (basic demographic
information, Address, MRN, Diagnosis, type of TB, other relevant information…)
- Capable of capturing and generating unique TB number
- Capable of capturing and displaying TB diagnosed patients on standard DOTS and DR TB treatment
registration forms
- Capable of capturing and displaying standard TB follow up forms (DOTS and DR TB Rx follow up forms)
- Capable of capturing, sending and receiving TB related laboratory investigations such as DST, smear
and culture tests based on standard forms
- Capable of ordering and capturing TB treatment drugs based on the national treatment protocol
- Capable of generating reminders to care providers whenever there are missed appointments, lost to
follow up (LTFU) pts, etc…
- Capable of referring and receiving TB patients to other units or other facilities such as Treatment
follow up sites (TFCs)
- Capable of admitting TB patients to TB ward
- Capable of capturing and displaying TB patient followup information from TB wards
- Capable of capturing and tracking TB contacts information
- Capable of capturing and displaying TB patient appointment information
- Capable of prescribing TB drugs as per the national TB treatment standard and patient type
- Capable of capturing and displaying TB treatment adherence support information based on the
standard format
- Capable for capturing and displaying HIV test information for registered TB patients
- Capable of managing transfer-in and transfer-out patients
- Capable of identifying, sorting and selecting list of TB patients
- Capable of displaying status of TB patients (waiting, on progress, complete…)
national standard
- Capable of displaying risk factors for NCDs
- Capable of capturing and displaying NCD screening and its result based on standard format
free text
confirmed diagnosis

- Capable of generating TB cohort report
Minimum Data Set
SN Data Element Data type/Format Form (Data Category Relevance

/Field source) (Report=R,
Service=S,
Patient=P)
Basic Demographic data

Date of Birth Date | dd/mm/yyyy Patient folder Demography S, P
Age Numeric Patient form Demography R,S,P
Date of Date | DD/MM/YYYY Patient card Demography S, P

registration to TB
clinic
Patient folder
Sex Text | Male or Female Demography R, S, P
Patient folder
Marital status Text|Married, single, Demography S, P
separated, widow etc
Address: Region Patient folder S, P
Address: Patient folder Demography S, P

Zone/Woreda
Address: Patient folder Demography S, P

household

number
Telephone Number|+251----- Patient folder Demography S, P
Contact Text| Name Patient folder Demography S, P

information
MRN Number | 000000 six Patient folder Demography S,P

digits
Entry to TB Treatment program (Non-DR TB)
Unit TB number Number | TB register Demography S,P
TB most at risk Text | Standard groups TB register R,S,P

group
Anti-TB treatment Date | DD/MM/YYYY TB register S,P

start date
Category of Text | Category as New, TB register R,S,P

Patient Relapse, etc..
Laboratory test Date | date lab is done Lab order form Lab test S,P
date
Laboratory test Text | Type of test done Lab order form Lab test R,S,P
type
Laboratory test Text Lab form Lab test R,S,P

result
Weight Numeric| in kg Tb register Nutritional S,P

assessment and
status
Height Numeric | in kg Tb Register Nutritional S,P

assessment and

status
BMI Numeric | Tb register Nutritional R,S,P

assessment and
status
MUAC Numeric Tb register Nutritional R,S,P

assessment and
status
Nutritional status Text | Normal, MAM, TB register Nutritional R,S,P

SAM assessment and
status
Intensive phase Text | regimen name TB register TB treatment R,S,P

treatment- drug
Intensive phase Numeric | dose of drug TB register TB treatment R,S,P

treatment- dose
Intensive phase Text| received the drug TB register TB treatment R,S,P

treatment- daily or not on a daily basis
monitoring chart
Continuation Text | regimen name TB register TB treatment R,S,P

phase treatment -
drug
Continuation Numeric | dose of drug TB register TB treatment R,S,P

phase treatment -
dose
Continuation Text| received the drug TB register TB treatment R,S,P

phase treatment - or not on a daily basis
monitoring chart
TB-HIV Co-infection
HIV test date DD | DD/MM/YYYY TB-HIV Co- S,P

infection

HIV test result Text | positive or TB-HIV Co- R,S,P
negative infection
Population Text | category of the TB-HIV Co- R,S,P

category of HIV patient infection
test
CPT start date Text | date CPT started TB-HIV Co- R,S,P
infection
Linkage to chronic Text | yes or not linked TB-HIV Co- R,S,P

HIV care infection
Nutritional assessment and Intervention
Nutrition Text and numeric | Nutritional

assessment and assessment and
its result intervention
Type of Text Nutritional

nutritional assessment and
treatment intervention
provided
Outcome of Nutritional
nutritional RX assessment and
intervention
Treatment outcome
Treatment Text | Cured, Rx Treatment R, S, P

outcome completed, LTFU, Rx outcome
failure, transferred to
DR-TB Rx ...
DRUG RESISTANCE TB REGISTRATION AND TREATMENT
DR TB registration Date | DD/MM/YYYY DR TB form DR TB S,P

date registration

DR TB number Numeric DR TB form DR TB S,P
registration
Type of Text | RR, MDR, Pre- DR TB form DR TB R,S,P

Resistance XDR, XDR registration
Site of infection Text| Pulmonary, Extra DR TB form R, S,P

pulmonary
Registration Text | New, relapse, Rx DR TB form DR TB R,S,P

group after LTFU, etc.. registration
Drug sensitivity Date Lab test

test date
Drug sensitivity Text | Result for each Lab test

test result type of anti TB drug
14. Rehabilitative care module

Description: XXX
Functionalities:
- Capable of identifying, sorting and selecting list of patients assigned to the rehabilitative care units
- Capable of displaying the status of rehabilitative care patients (waiting, on progress, complete…)
- Capable of adding service specific form for new patient
- Capable of displaying summary of patient’s previous interactions (by date, diagnosis, service unit, …)
chronic illnesses, prosthetics, orthotics and surgical interventions…)
- Capable to display vital signs
- Capable of capturing and displaying rehabilitation care information as per standard format
national standard
- Capable of capturing and displaying diagnosis
- Capable of displaying available diagnostic and imaging studies
- Capable of receiving and displaying diagnostic and imaging results

- Capable of ordering physiotherapy procedures and prosthetics
- Capable of managing medical certificates, consent
Minimum Data set

(Report=R,
Service=S,
Patient=P)
1 Date of Birth Date | dd/mm/yyyy Demography R, S, P
15. Reporting Module

Description: XXX
Functionalities:
- Capable of generating standard monthly, quarterly and annual HMIS service report
- Capable of generating disease (morbidity and mortality) report based on national classification of
diseases
- Capable of generating case based / surveillance reports
- Capable of generating custom reports based on need
- Capable of generating registers for each program area
- Capable of sending report to a national selected eHIS system (DHIS2) and other systems
- Capable of generating charts/visualizing performance with interactive dashboard
- Capable of exporting reports in different formats (Word, Excel, CSV, JSON, XML, PDF…)
- Capable of displaying flagging performance level of health facilities
- Capable of sending and receiving clinical information with CDA (Clinical document Architecture)
format

Standards for EHR and Interoperability
Introduction
Interoperability means the ability of different Health solutions to exchange meaningful information via the
accepted standards. Interoperability is essential to facilitate decision-making and reduce waste by minimizing
or even eliminating duplication of efforts while improving safety and reducing errors at the same time.
Furthermore, it encourages successful data to exchange so that patients can stop ferrying their medical
records from treatment to treatment by enabling the technology, interoperability standards, and clinical
workflows to be better and ultimately provide better care to patients., yet it can be very difficult to find
consistent, understandable and trustworthy information on which to base our decisions.
As a result of these deficiencies, there is a clear and pressing need to develop a coherent and integrated
approach to health information, based on standards and international best practices. A robust health
information environment will allow all stakeholders, the general public, patients and service users, health
professionals, and policymakers to make choices or decisions based on the best available information. Hence
EHR implementations should consider data exchange and interoperability using known and accepted
standards. This section explains syntactic and semantic interoperability standards and suggests essential
interoperability aspects of an EHR system.
EHR interoperability standards specification and use within EHR is developed in consideration of applicability
in low resource settings. The health sectors existing infrastructure brings its own challenge and assumptions
should be taken to work in such environments. It also takes into mind that interoperability standards are
dynamic and evolving over time. Strict enforcement to use recent standards may not be feasible as legacy and
proprietary EHR systems may exist. A comprehensive specification is outlined with minimum requirements of
EHR to enable interoperability and data exchange.
GOAL
The goal of this section is to encourage EHR interoperability, recommend data exchange accepted
protocols/standards for use in new Electronic Healthcare Records (EHRs) development efforts, So as to
encourage innovation and data use for a positive impact on achieving national digital health goals.

Scope
The Scope of the interoperability standard is to enable EHR systems to be able to exchange health data based
on known and accepted standards, interoperability of information in the EHR, interoperability of EHR systems
and specifies data exchange standards to send and receive messages in the specified EHR modules. Standards
referenced by the selected standard will also be considered as recommended in the EHR standard.
List of Standards
In order to encourage harmonization and effective use of data and the information that can be inferred from
EHR data, this standard document has identified well-known and accepted standards. and provided
recommended and candidate standards that apply in different domains and modules of an EHR. In making use
of the recommended standards, please consider the following items:
● Please go through license agreements of the targeted standards and make sure they comply with
national policies and local interests. Implementers are expected to comply with the license agreement
of the standards they use.
● The EHR development and data exchange specifications are developed to mature the national eHA,
EHR development efforts should align their objectives accordingly
● Please align the adaption with national efforts and make sure to follow the latest developments
● Make sure the latest updates of standards are reflected in your adoption
No Type Standard Name Intended Purpose Remark
1 Classification Codes NCoD National Classification

of Disease
ICD-10 Disease Classification
ICD-10-PCS Procedural Codes
2 Lab and Observation LOINC Test, measurement,
observations
3 Terminology SNOMED-CT Clinical Data concepts
4 Data Exchange ● HL7 FHIR Represent and share Even though it is

information possible to use three
Latest Version: v4.0.1:
of them, we highly
R4
recommend
Organization: HL7 developers use the
latest FHIR V4
standard

● HL7v3
Latest Version: v3.x
Organization: HL7
● HL7v2.4
Latest Version: v2.x
Organization: HL7
● CDA
Latest version: 2.0; Define the structure

2005 of medical records
such as discharge
Organization: HL7
summaries and
progress notes, as a
way to better
● CCD:
exchange this
Latest version: 1.0 information between
providers and
Organization: HL7
patients.
ASTM
Standard for the

communication and
● DICOM
management of
Latest Version: medical imaging and
DICOM related data
Organization: NEMA
● CCR
Latest Version: CCR

Terminology Standards
With the complex nature of the health system, collecting bulky data about the diagnosis, clinical orders, and
procedures makes the AS-IS transfer of systems resources more complex. So globally, structured codes and
terms have been prepared to define the semantics of information using consistent and computable
mechanisms to be ingested by the consumers.
Semantic interoperability is the main essence behind the development and adoption of different terminology
standards. Countries have been into the preparation and localizing of different terminology standards at the
national and sub-national levels. Organizations govern the use of terminology standards in a local setting by
mapping the resources and concepts across different terminology standards.
Some advantages and values of using terminology standards:-
● Safe and effective clinical care: Those data collected at the point of care can be represented with
common standards and clinical and patient safety systems can share an integrated information
infrastructure whereby data are collected and reused for multiple purposes to meet more efficiently
the broad scope of data collection and reporting requirements. Common data standards also support
the effective assimilation of new knowledge into decision support tools, such as an alert of a new drug
contraindication, and refinements to the care process.
● Creating longitudinal care record: Longitudinal care of a client could not be achieved without
standards. Those different systems may call the same data element by a different name or may refer
to data elements with different definitions by the same name, all while contending with different
technical requirements and constraints. Electronic medical recording (EMR) applications leverage
longitudinal care by interacting with other EMR systems to create a holistic electronic health record
(EHR) system which handles lifetime information of a single patient. This exchange of longitudinal data
of a single patient among different healthcare settings and health application software is achieved via
interoperability. The gap in capturing, defining, and presenting data should be standardized before
interoperability standards are endorsed. This is critical since any data element that leaves room for
misinterpretation might create an error in consumption on the other end.
● Data Quality: Terminology data standards can affect the quality of data positively or negatively
depending on the type of health data standard used and the dimension of data quality expected to be
influenced. The quality of data is expected to be approached in two perspectives.
○ Quality conformance to specifications
○ Quality fit for purpose
So, different types of terminology data standards affect different dimensions of health data quality
differently. For example, if we consider validity as one dimension and discuss the effect of data
standard on validity. It is obvious that to have a defined format, a standardized data set is needed.
Hence we can conclude that data standards positively affect the validity of data.
● Interoperability between Systems: Seamless data exchange between systems is a means for the good
work that health data standards are built for. This seamless data exchange between systems is
referred to as interoperability. Interoperability is an enabler to achieve a given organization or
countries electronic health architecture that defines how applications and components are expected

to interact so that a single source of truth or data from the point of service application passes through
different mediums and get aggregated in the national analytical data depots for decision and policy
making.
● Report Aggregation and Evaluation: Trying to aggregate data or report from a work of health care
setting without known data elements defined and indicators calculated is impossible. Even the paper-
based data collection procedure should be in a structured systematic way so that the collected data
from one facility or organizational unit is compiled with others to give a full picture. Besides that,
collecting stored data from electronic systems is expected to follow a similar representation of data
elements between systems so that misinterpretation and miscalculation are avoided. For example, the
representation of gender in different systems might affect the aggregation of data. If one system
represents gender as M and F and the other as Female and Male, it might require some
rearrangements and correction of one format to the other. But prior standardized aggregate elements
have such kinds of misconceptions.
Based on purpose and value; terminology standards can be classified as:-
1. Reference terminology standard

2. Aggregation terminology standard
Reference or clinical terminology standards defines all terms and codes of clinical procedures and
interventions of a client at a given point of health service. On the other hand, Aggregation terminology focuses
on concepts and resource classification for the compilation of routinely collected secondary data for analysis
and interpretation.
Referenced Terminologies
Referenced terminology is "a collection of concepts and relationships that provide a common reference point
for comparisons and aggregation of data about the entire health care process, recorded by multiple different
individuals, systems or institutions." commonly used and globally known reference terminologies standards
such as SNOMED CT, LOINC and RxNorm are widely used in clinical coding.
Aggregate Terminologies
In this section aggregate terminology and coding standards that are to be used in clinical practices, testing &
diagnostics, classifications of diseases etc. will be defined. This considers local initiatives currently being used
at the health sector as well as adoption and mapping of globally available terminologies and coding systems
that enhances interoperability between EHR systems, ancillary systems and other healthcare systems that
interact with EHR.
Aggregated terminologies are used to classify, record and aggregate related concepts together. WHO FIC
codes are one the most widely used classification systems internationally.
WHO Classification Codes: WHO Family of International Classifications (WHO-FIC)
● WHO ICD-10: International Classification of Diseases (ICD) and its derivative classifications

● WHO ICF: International Classification of Functioning, Disability and Health (ICF)
● International Classification of Health Interventions (ICHI)
● International Classification of Diseases for Oncology (ICD-O)
As part of HMIS reform a Local initiative was started and developed the National classification of
disease(NCoD) the main target being revising the classification of disease morbidity and mortality to focus on
diseases that are relevant for epidemiological surveillance, planning, and management purposes.
Candidate Terminology Standards

Though the development and implementation of terminology standards have been in practice in a different
context and setting across national and global spaces, there have to be pre-defined selection criteria to select
a suitable standard amongst the many existing ones. a selected terminology standard should fit for the
purpose of eHealth Architecture roadmap. The governance criteria related to licensing and intellectual
property should also be considered while selection. Failing to do so could lead the implementer and the
country at large to cost and adoption implications.
1.1 Reference terminology: SNOMED CT
SNOMED CT is a comprehensive, clinically validated, semantically rich, healthcare terminology vocabulary in

the world. A multilingual system, SNOMED CT covers many aspects of healthcare, including patient histories,
details of procedures, and the spread of epidemic disease. This standard is developed by the International
Health Terminology Standard Development Organization (IHTSDO). It is a resource that facilitates evolutionary
growth in expressivity to meet emerging requirements representation with validated clinical content. It does
not attempt to standardise the whole of the medical language nor does it intend that all clinicians should use
the same terms. Instead, SNOMED CT attempts to provide the language to adequately reflect the meaning and
use of medical concepts.
SNOMED CT provides coverage in diseases, findings, procedures, body structures, pharmacy products and
other health care concepts. The hierarchical nature of SNOMED CT enables recording and documentation of
clinical data at the appropriate level of detail that can later be analyzed from other perspectives and
groupings. It provides a standardized way to represent clinical phrases captured by the clinician and enables
automatic interpretation.
The integration of a clinical terminology such as SNOMED CT into computer-based patient records provides a
comprehensive and functional terminology for clinical care. SNOMED CT can be utilized to index, store and
retrieve patient information for clinical purposes. SNOMED CT helps ensure comparability of data records
between multiple practitioners, across diverse platforms and computer systems. This standard is currently
used in more than eighty countries and has the possibility of mapping it to other international standards. The
core components of SNOMED CT are: -

1. Concept: Every concept represents a unique clinical meaning, which is referenced using a unique,
numeric and machine readable SNOMED CT identifier. The identifier provides an unambiguous unique
reference to each concept and does not have any ascribed human interpretable meaning.
2. Description: Two types of description are used to represent every concept – Fully Specified Name
(FSN) and Synonym.
3. Relationship: A relationship represents an association between two concepts.
There is a managed list of existing SNOMED CT unique identifiers, fully specified names(FSN), preferred terms
in international English, and status flags. implementers should support GPS in sharing patient health
information coded with SNOMED CT for the free usage of SNOMED services.
Implementation Strategy: Clinical Terminology
● Implementers shall use SNOMED CT for clinical health record system.
● Implementers shall use SNOMED GPS as SNOMED CT reference set.
1.2 Reference terminology: LOINC

LOINC (Logical Observation Identifiers Names and Codes) provides a set of universal names and ID codes for
identifying laboratory and clinical test results. LOINC facilitates the exchange and pooling of results, such as
blood hemoglobin, serum potassium, or vital signs, for clinical care, outcomes management, and research.
Considering the laboratory production code as an identification code for the test result causes interpretation
issues between different medical information producers. So, Regenstrief institute developed LOINC to rescue
the issue of test and medical data exchange problems.
LOINC (Logical Observation Identifiers Names and Codes)
● Provides standard identifiers, names, and codes for representing clinical observations and laboratory
test results.
● Includes medical and laboratory code names, nursing diagnosis, nursing interventions, outcomes
classification, and patient care data set.
● LOINC codes are classified as Laboratory and Clinical. Under each of these main categories, codes are
distributed into specific categories. LOINC code covers clinical observations and laboratory test results.
Each LOINC record corresponds to a single test result. The record includes defining: -
● Component (analyte) - e.g., potassium, hemoglobin, hepatitis C antigen.

● Property measured - e.g., a mass concentration, enzyme activity (catalytic rate).
● Timing - i.e., whether the measurement is an observation at a moment of time, or an observation
integrated over an extended duration of time - e.g., 24-hour urine.
● System - the type of sample - e.g., urine, blood.

● Scale - e.g., whether the measurement is quantitative (a true measurement), ordinal (a ranked set of
options), nominal (e.g., E. coli; Staphylococcus aureus), or narrative (e.g., dictation results from x-rays)
● Method - where relevant, the methodology used to produce the result or other observation.
Implementation strategy: Lab and Observation
● LOINC coding shall be used for processing Laboratory results and reports.
● incase of implementation of the national drug list there should be a mapping between LOINC.
1.3 Referenced Terminology: RxNorm

RxNorm is a normalized naming system for drugs and a tool provides normalized names for clinical drugs and
links its names to many of the drug vocabularies commonly used in pharmacy management and drug
interaction systems. Because these systems use many different sets of drug names, it can be difficult for one
system to communicate with another. To address this challenge, RxNorm provides normalized names and
unique identifiers for medicines and drugs. The goal of RxNorm is to allow computer systems to communicate
drug-related information efficiently and unambiguously.
Implementation strategy : RxNorm
● RxNorm coding shall be used for processing pharmacy prescription and dispensary.
● incase of implementation of the national drug list there should be a mapping between RxNorm.
1.4 Aggregation terminology: ICD
Of the WHO-FIC classification the most widely used system is the ICD classification system. The International
Classification of Disease (ICD) is a global health information standard for diagnosis, procedure, billing and
other clinical and health aggregation, prepared by WHO. ICD is used in different epidemiological conditions
such as defining disease, disease patterns, managing health care, and monitoring the outcome. ICD
classification system is in continuous improvement, it ensures that the code set will gradually cover more
codes to meet the future needs of medical practitioners internationally. The coding terminology provides a
comprehensive set of alphanumeric codes for identified diseases and symptoms.
WHO has been releasing versions of ICD at different times. Currently there is a new ICD11 introduced to the
system. The reason to revise are many but to mention some: -
1. Identifying new diseases and conditions

2. Disease and condition disaggregation [from 14400 to 55,000]
3. Removing conditions that are no longer considered as disorders.
Implementation Strategy: Classification Codes

● NCoD shall be used as a standard national disease classification.
● There shall be a possibility to map NCoD to ICD10/11 for international
● Where a need arises for the use of procedural classification, it is recommended to use the ICD-10-
PCS.
● ICD 11 is released and efforts should be made to adopt ICD 11 if possible and Mapping of ICD 10 to
ICD 11 should be considered.
1.5 Universal Medical Device Nomenclature System (UMDNS)

The nomenclature of medical devices is a coding system used to genetically identify medical devices and
related health products. Having a nomenclature system in place for medical devices facilitates their
management and regulation by standardizing terms that enable communication despite linguistic and other
barriers. Several naming systems for medical devices exist and each is used by a different group of
professionals depending on the needs of that particular group, needs such as maintenance, procurement,
accounting, stock keeping, regulatory affairs, adverse medical device event reporting, and customs operations.
The Global Medical Devices Nomenclature System (GMDN) and the Universal Medical Devices Nomenclature
System (UMDNS) are the two nomenclature systems being primarily used for medical devices .
National Landscape
Efforts have been put into the introduction of National Health Data dictionary(NHDD) in standardized data
elements clusters and data set specifications and glossary items. one of the standardized lists of items
described by NHDD is the National classification of disease(NCod).
1.1 National Classification of Diseases (NCoD)
● NCoD is part of the effort by the Ministry of Health(MOH) to harmonize the classification systems to
focus on diseases that are relevant for epidemiological surveillance, planning, and management
purposes.
● NCoD is a simplified disease classification system; it is organized according to the ICD-10 framework
with specification of ICD-codes corresponding to each diagnosis or disease categories.
● It is fully harmonized with different international standards like ICD-10, Global burden of disease
(GBD) and Integrated Disease Surveillance and Response (IDSR) protocols (using disease names in IDSR
list).
● It is fully mapped to the ICD-10.
● There are different versions of NCoD as per the health institution level.
○ Primary Level Health Care (Mini Edition): Includes 617 diseases
○ Secondary Level Health Facility (Compact edition): includes 1,849 diseases.
○ Tertiary Level Health care providers (Extended Edition): includes 2055 diseases.

The NCoD is a structured tabular list of diseases and conditions; It is divided into chapters, categories,
sub-categories and contents; It consists of
Unique Identifiers, Tabular List of Chapters, Disease and Conditions List;
1.2 National Drug List

A master drug list for national implementation is under development. Global terminology standards aimed to
be used as referred and aggregated level are expected to be aligned and mapped with this national drug list.
1.3 National Laboratory List

A laboratory order and investigation list for national implementation is under development. Global
terminology standards aimed to be used as referred and aggregated level are expected to be aligned and
mapped with this national laboratory list.
Recommendation Terminology Standards

Terminology standards discussed here, as the candidate standards, should be the priority in implementation
as they address the best possible answers to the aforementioned selection criteria. Though implementers are
encouraged to act and follow the direction given here, there is a window space to use other known standards
with the possibility of mapping to the selected ones. So implementers should follow implementation guides
and contextualized and localized national and sub national standards, if any, in harmony with the discussed
standards here.
Messaging Standards
Messaging standards outline the structure, content and data requirements of electronic messages to enable
the effective and accurate sharing of information.The term ‘message’ refers to a unit of information that is
sent from one system to another. Messaging standards specify the technical aspects of sending messages so
that one health information system application can interact with another and have a common
understanding. The message will have its own syntactic structure to follow so that the sender and receiver
communicate smoothly.
Most terminology standards cannot stand alone but need a messaging format or standard to accompany them
to accommodate extra information about a patient, clinician, or other resource and deal with the transfer
mechanism from sender to receiver. Within the health setting, EHR Systems coexist with several other systems
such as Laboratory Information systems, Pharmacy Information systems, the District Health Information
System and Demographic Surveillance systems. Exchange of information between systems is important for
several reasons, including increased efficiency through decreased entry of duplicate data, decreased errors in
medical information through the same mechanism, and increased availability of health information promoting
better clinical decision making and improved continuity of patient care.

The most known messaging standards are HL7 V2, V3, FHIR are the chronologically ordered releases of HL7.
Besides these there is HL7 CDA to represent a clinical document and DICOM to handle medical imaging. Each
release has got its own cornerstone in the long-lasting messaging standard development.
HL7 standards are both based on the messaging (HL7 v2.x, HL7 v3 messaging, FHIR) as well as on the
document (HL7 v3 documents – CDA) paradigm.
The main characteristics of messages and documents are:
Documents: main aim is human-readability, persistence, self-containment (wholeness and context).
The v3 Clinical Document Architecture (CDA) is a HL7 standard for the representation and machine processing
of clinical documents in a way that makes the documents both human readable and machine processable.
Documents are persistent in nature, have “static” content and tend to be used “post occurrence”, i.e. once the
actual process is done. Documents are about persisting "snapshots" as understood at a particular time.
Messages: main aim is machine processability;capable of providing real-time information; messages may have
receiver responsibilities (i.e. cause response messages to be sent).
Messaging standards have the potential to enable the following benefits to patients:
● Speeding up the patient referral process to enable the patient to start on their journey of care more
quickly.
● Reducing the need for duplicate and repeat diagnostic testing.
● Speeding up the sharing of patient discharge details and facilitating continuing care for patients during
transfer between secondary care and primary care.
● Complete, accurate and searchable health information, available at the point of diagnosis and care,
allowing for more informed decision making to enhance the quality and reliability of healthcare
delivery.
Candidate standards
The five candidate standards identified as potential messaging standards are:-
1. Health Level 7 version 2.x

2. Health Level 7 version 3
3. Health Level 7 Clinical Document Architecture (CDA)
4. Health Level 7 Fast Healthcare Interoperability Resources (FHIR) and
5. Digital Imaging and Communications in Medicine Committee (DICOM). An overview of each standard
is described below.

1.1 Health Level 7 version 2.x
The HL7 v2.x standard provides specifications for messages to support the sharing of information on admission
to and transfer within and between healthcare facilities. It provides messages to support many scenarios,
including the ordering of laboratory investigations, radiology tests and medications for patients and sending
the results of the tests ordered to the ordering clinicians. It can support transmission of referrals and
discharge summaries between clinicians and sharing of appointment scheduling information.
In order to define messages for different contexts, the standard specifies a set of building blocks for messages
known as message segments which may be reused when constructing messages. Each segment consists of
multiple fields which are constructed using pre-defined data types.
1.2 Health Level 7 version 3

The HL7 v3 messaging standard was created to support large scale health information systems and attempts to
support all healthcare workflows. Benefits include reduced ambiguity, maximum reuse and increased
consistency in HL7 messages. The HL7 v3 standard is published as a large web-based document that contains
specific subject areas, also known as domains, such as laboratory, pharmacy, medications and patient
administration.
The v3 messaging standard uses the Reference Information Model (RIM) and a formal methodology called the
HL7 Development Framework (HDF) to increase the detail, clarity and precision of message specifications. HL7
v3 messaging combines a formal methodology with established models and value sets needed to express the
full range of specifications for eHealth interoperability, including specifications for prescribing, referrals, and
discharge summaries.
1.3 Health Level 7 Clinical Document Architecture

In addition to creating messaging standards, HL7 also develops standards for representing clinical documents,
such as referrals and discharge summaries, known as the Clinical Document Architecture (CDA) standard. CDA
is a good option for countries who have limited resources as they can adopt simple CDA-based architectures.
CDA is regarded as a standard that is easier to implement than the v3 standard. The normative version of the
CDA, release two, was published in 2005. CDA has the benefit of being based on a common information model
known as the Reference Information Model (RIM). An information model provides a framework for organizing
data so that it can be delivered and re-used in a variety of different ways. CDA ultimately allows for shared
information at the point of care and promotes reusability across a sufficiently wide range of documents.
The development of CDA was driven by the need for clinical information to be interpreted by both human
readers and computer systems. CDA supports a combination of free text for human readability and adds
structure and coding to the document to enable machine processing. CDA provides for different levels of
conformance to the standard. The different levels enable implementers to develop simple documents, known
as level 1, that are displayed and presented to clinicians in a readable format or more complex documents that
are coded for machine processing, known as level 2 and 3.

1.4 Health Level 7 Fast Healthcare Interoperability Resources
FHIR is the most recent standard created by the HL7 organization. FHIR is a standard that enables the secure
electronic sharing of health information and the real-time exchange of information using web technologies.
FHIR is suitable for use in a wide variety of contexts, including data sharing between electronic health records,
mobile phone applications, cloud communications and server communication in large institutional healthcare
providers.
FHIR was first proposed in July 2011. There are two distinctive features that the FHIR standard has focused on
compared to other HL7 standards — security and the use of resources. FHIR is considered more secure than
previous standards as all health data exchanged using FHIR is required to be transmitted using secure
protocols.
The basic building blocks in FHIR are called resources. There are various types of resources defined in
the standard, including clinical, identification, workflow, administrative, infrastructure, conformance
and financial resources. The philosophy behind FHIR is to build a base set of resources that, either by
themselves or when combined, satisfy the majority of common information exchange scenarios in
healthcare. FHIR also supports resource profiles. Profiles describe the information handled by the
system on a per use case. They define a series of variations on the same set of resources for different
scenarios.
The primary objective of FHIR is to ensure that it is easy to implement and that it provides a rigorous
mechanism for exchanging data between healthcare applications.
FHIR takes advantage of and has a strong foundation in web services. Web-based technologies are well
understood and widely supported by the implementation community. Examples of technologies endorsed by
FHIR include HTML and Cascading Style Sheets for user interface integration, either JSON or XML for data
representation and OAuth for authorization.
1.5 Digital Imaging and Communications in Medicine Committee (DICOM)

DICOM is a standard for handling, storing, printing, and transmitting information in medical imaging. It
includes a file format definition and a network communications protocol. The communication protocol is an
application protocol that uses TCP/IP to communicate between systems. DICOM files can be exchanged
between two systems that are capable of receiving image and patient data in DICOM format. The National
Electrical Manufacturers Association (NEMA) holds the copyright to this standard. It was developed by the
DICOM Standards Committee, whose members are also partly members of NEMA. DICOM enables the
integration of scanners, servers, workstations, printers, and network hardware from multiple manufacturers
into a picture archiving and communication system (PACS). DICOM is known as NEMA standard PS3, and also
as ISO standard 12052:2006, Health informatics – Digital Imaging and Communication in Medicine (DICOM)
and includes workflow and data management standards.

Recommendation
The standards used to communicate information unambiguously between different systems vary and may
include bespoke, proprietary standards or commonly used international messaging standards. To safely send
and receive information such as referrals and laboratory orders and results between different types of
systems, registries and other components of the Ethiopian eHealth Architecture, a standard exchange format
is required.
To provide direction and to assist the health IT community to make decisions in relation to health messaging
standards, the following recommendations are made:-
● The FHIR standard should be considered for new initiatives on a use case by use case basis when it
becomes a normative standard and is mature enough for implementation.
● The HL7 v2.4 messaging standard should continue to be supported.
● The CDA standard should be used for exchange of documents.
● DICOM standard for laboratory data and imaging.
MoH will continue to work with the health informatics community to analyze use cases, select the most
appropriate standard to use and develop specifications based on project requirements.
National Landscape for messaging standards

Culture of electronic data exchange and interoperability among and between systems comes after the
adoption and implementation of terminology standards. So far, efforts have been into introduction of data
dictionaries for different reference and aggregated terminology needs. As a result of the introduction of these
terminology standards different data exchanges are demonstrated. But, the national profiling process of
messaging standards is demanded.

Data Ownership, sharing, privacy and security
Normative References
The following standards, in whole or in part, are normatively referenced in this document and are indispensable for its application.
No Type Standard Name Intended Purpose
● ISO/TS 14441:2013 Health informatics —

1. Data access Security and privacy requirements of EHR ● Implementers security and privacyConformity test
mechanism and systems for use in conformity assessment. and certification test.
control
● ISO 22600:2014 Health informatics - Privilege ● Defines principles and specifies services needed
Management and Access Control (Part 1 through for managing privileges and access control to data
3) and/or functions.
● ISO 27799:2016 Health informatics Information

2. Integrity security management in health using ISO/IE ● The threats to the privacy, confidentiality,
integrity and availability.
● ISO 13606:2019 Health informatics Electronic
health record communication ● Syntactic and semantic capabilities (through a dual
model approach) as well as terminology, security
and interface considerations for the standardized
exchange of EHR.
● ISO 22857:2013 Health informatics — Guidelines ● The encryption key, certification, and
3. Encryption/Digital on data protection to facilitate trans-border management
Certificate flows of personal health data and
● provides guidance on data protection
● ISO/TS 21547:2010 Health informatics — requirements to facilitate the transfer of

Security requirements for archiving of personal health data across national or
electronic health records — Principles jurisdiction( normative for international data
access)
● ISO/TR 21548:2010Health informatics —
Security requirements for archiving of electronic ● define the basic principle needed to securely
health records — Guidelines preserve health records in any format for the
long term.
● ISO 17090 Health informatics - Public Key
infrastructure ● ISO/TR 21548:2010 is an implementation
guide for ISO/TS 21547. ISO/TR 21548:2010
● Ethiopian National PKI Technical Standards
will provide a methodology that will facilitate
Guideline INSA version 1.02012 E.C
the implementation of ISO/TS 21547 in all
organizations that have the responsibility to
securely archive electronic health records for
the long term.
● ISO/TS 18308 defines legal requirements purely

i. Audit logs from a security perspective, including ● Defines the set of requirements for the
authentication, audit log, nonrepudiation, and so architecture of a system that processes, manages
on. and communicates electronic health record (EHR)
information.
● ISO 27789:2013(en) Health informatics — Audit
trails for electronic health records ● ISO 27789:2013 specifies a common framework
for audit trails for electronic health records (EHR),
● Active Standard ASTM E2147. Standard in terms of audit trigger events and audit data, to
Specification for Audit and Disclosure Logs for keep the complete set of personal health
Use in Health Information Systems. information auditable across information systems
● 45 CFR 170.210 - Standards for health and domains.
information technology to protect electronic
health information created, maintained, and
exchanged.

When point of service EHR applications connect with other systems and registers in the Enterprise architecture, a defined infrastructure
has to be inplace to address the needed business process and workflow. Data exchange and interoperability between participating
systems or components demands a solution for the issues of security and privacy patient information. special implementation
specification and conformance testing should be followed to make sure participating systems have the necessary measures.
Terms and Definition
Data ownership is the act of having legal rights and complete control over a single piece or set of data. It defines and provides information
about the rightful owner of data assets and the acquisition, use, and distribution policy implemented by the data owner.
Security: Can be defined as a collection of approaches that address issues covering physical, electronic, and procedural aspects of
protecting the information collected as part of health care.
Privacy: is both a legal and an ethical concept. The legal concept refers to the legal protection accorded to an individual to control both
access to and use of personal information and provides the overall framework within which both confidentiality and security are
implemented.
Accountability: completeness and correctness of data to maintain its integrity
Responsibility: Sharing of data is not harmful to the public interest or the national interests and security, and not affecting the privacy and
ownership rights of individuals.

Transparency: Transparency implies actions of openness and accountability while maintaining
security. Transparency doesn't imply success or failure of information security; it dictates actions at
questionable cross roads.
Confidentiality: Relates to the right of individuals to the protection of their data during storage,
transfer, and use, to prevent unauthorized disclosure of that information to third parties.
Ownership of Electronic Health data
The increasing health data captured, processed, stored through the EHR system needs to be properly
managed, on the other hand, interactive actors’ legal ownership, rights, obligations, expectations,
roles, trust, and the need to improve existing health data protection and privacy should be
maintained. The data owners are actors who claim the possession, copyrights, and complete control
over a single piece or set of data to ensure their control and ability to take legal action if their
ownership is illegitimately breached by an internal or external entity. According to the draft national
data access and sharing policy, health act, and health information proclamation those different
actors are expected to have different privileges, roles, and levels of trust. The data owner has a role
to Amend/Add and Audit trail/ Limit time, trust on the level of access/ Consent.
Implementation Strategy: Data ownership
● The ultimate ownership of the health data resides with the client.
1.1.1 Data access and Sharing
As stipulated in the IRR Maximizing the availability, accessibility, quality, and use of health
information for decision-making processes, through the appropriate use of information
communication technology to ultimately impact the access, quality, and equity of healthcare delivery
at all levels is important. EHR systems must have a secured built in application programming
interface (API) or synchronization tool which can be built or added on to an existing EHR or ancillary
application to support synchronizing health data with each other and the central system to allow
them to communicate access and share data. The API and synchronization tool should have different
security layers of authentication and authorization mechanisms in place to prevent the health data
from unauthorized access. Intra and cross EHR data sharing policy concerns and issues should be
addressed in different policy directives implementation guidelines and operating procedures.
implementers are advised to follow those documents and implementer accordingly.

Implementation Strategy: Data access and sharing
● Data to be accessed and shared shall be anonymized, available, and made accessible for
data users to use, wherever it is found legal, ethical and ensures the confidentiality of
information provided by respondents is respected.
● Data to be accessed and shared shall follow the national data access and sharing directive
and protocol.
1.1.2 Health data grant conditions
Access to health data is a cornerstone for producing timely and objective research, which builds a
transdisciplinary evidence base that helps inform efforts to improve health, well-being, equity,
privacy, and security. All health data grants are subject to special terms and conditions provided by
health sector services and must ensure compliance with all relevant legislation and government
regulation relating to interacting actors, including any subsequent amendments introduced while
work is in progress. Grants must notify the intended actor of any change in its status, that might
affect the security, ownership, privacy aspects and shall have adequate business continuity plans in
place to ensure that operational interruptions to the research are minimized.
Implementation Strategy: Data grant conditions
● Health data grant to other actors shall follow necessary legal procedure. guaranteed
actors shall inform any changes of the data to the owner.
● Grant and access of client data for medicolegal reasons shall follow necessary legal
procedures.
1.1.3 Health Data culling process
Health data shall not be kept for longer than necessary for that purpose, retention and culling
periods have to be standardized across the health sector and should be explicitly explained in the
health act, guideline, national data access, and sharing directive. Activating and deactivating health
data permanently or temporarily should be easily identified by the date flagged against the database
or catalogs which indicate the future culling date. Health records should be culled from the system
on a scheduled time frame basis and the system must thoroughly notify records to ensure that they
are ready for subsequent actions. Deactivation date must be recorded in the system against the

individual record, and the Inventory of records must be updated to reflect the batch of records
deactivated in the cull and must be confidentially kept and notified for confirmation.
Implementation Strategy: Data culling process
● There shall not be permanent deletion of client data. Role and timestamp based data
deactivation should be implemented so that actors of the EHR follow accordingly.
Protected and sensitive personal Identifiable information
Representation of information that either directly or indirectly identifies an individual upon whom
clinical service is performed should be identified and preserved. Personal identifiable information(PII)
are identifiers such as:-
Direct identifier
1. Name
2. Address
3. Medical Record Number or other identifying number or code
4. telephone number
5. email address
Indirect identifier
A combination of the information below listed data elements
1. Gender
2. Ethnicity
3. Date of birth and other similar descriptions
4. Relatives, next of kin personal information

Actors Role and Responsibility
NO Roles Descriptions Responsibilities
1 Care An individual or group, a physician, ● View, create, edit, delete contents in the system
provider nurse, specialized treatment center
● Share trust among the system and other shared prov
who provides health care service to
a client.
2 Institution/ A facility or administrative office ● Store, provide access to and/or from, and provide
Facility where clients and Care provider and communication mediums
meet or health data is generated or
used
3 Implementer An individual or groups or ● Can define, create, edit, configure/setup, delete, acce
organizations or company who
● Monitor/Adjust the care provider collaboration to th
develop and/or supply the EHR
system interaction
solution to the institution
● Grant/deny unauthorized access/privilege and ensu
system
4 Clients A person who visits the ● Can view/read the information or give data to the sys
institution/facility for at least one
● Can give consent for the data provided
service and is the source of data.
5 System Software or hardware that interacts ● Can read, write or delete and share the data from the
with the EHR System in the
institution

Security Safeguard Themes
1.1.4 Rationale and purpose

Longitudinal and continuum of care of an individual client tracked in different courses of intervals and
interventions needs data sharing and exchange between different actors of the EHR system. Leveraging data
access could lead to Evidence-based medicine but exposing data among different actors of the system leads to
security breaches and counterfeits. EHR adoption depends on different adoption preconditions and criteria.
One of the determinant adoption criteria shifting the adoption curve from paper-based to electronic health
records is the security and privacy standard. Complying to a given modality of data saving and sharing matters
to worry most about how individuals' data is going to be treated following standardized privacy and security
standards.This has an advantage in encouraging privileged data demand and information use among
stakeholders.
The Ethiopian enterprise architecture, "eHealth Architecture (eHA)" document, stipulates and discusses the
data exchange and interoperability of applications and registries. EHR as a concept and workflow is expected
to have a security and privacy functionality and standard operating procedure following global and national
standards, policies, and directives. Though technology selection is up to the implementers, the issue of data
access, sharing, privacy, and security should act according to agreed, and contextualized security standards.
Privacy and Security standard adoption criteria should be described and discussed from the perspective of an
EHR implementation plan.
Privacy and Security safeguard thematic areas are adopted here from the privacy and security rules of the
Health Insurance Portability and Accountability Act(HIPAA). Organizational or administrative safeguard,
physical safeguard, and technical safeguard should be taken into consideration while ensuring;-
● Identity management, enterprise security, disclosure, and trust among actors of the health
data owner.
● Prepare business continuity plan aiming at security breaches and hazardous natural and
environmental occasions counterfeiting protected personal information
● Socializing and enforcing privacy and security policies and directives to enrich the human
element towards following certain procedures as a cultural practice and habits.
1.1.5 EHR Security Safeguard Standards
During EHR implementation, security technical standards must consider the privacy and security
aspects and emphasize electronic personal information controlling and access. The EHR as a solution
and business process, in general, should possess and consider the following standards. Standards for
privacy and security standards alongside technical safeguard characteristics are listed below: The EHR
should satisfy and comply with referenced standards by the national EHR document to address
cybersecurity and data ownership issues.

1.1.6 Privacy and Security Technical characteristics
An EHR system provides an integrated view of healthcare records by enabling interoperable module
applications. The EHR system plays a significant role in advancing the healthcare service delivery to
make sure individuals' data is kept safe and accessed with shared responsibility. Technical
specifications of the participating systems shall include the implementation specification concerning
privacy and security. EHR solutions are expected to address standard specifications and guidelines
discussed in this section.
Data access mechanism and control

Implementation Strategy: Data access mechanism and control
● The EHR solution shall support the pseudo-anonymity technique to de-identify personal health
data so that the confidentiality of the protected personal information remains intact when third-
party access is permitted.
● Notwithstanding the type of access, whether local within the system or in a time of exchange
between solutions, Actors claiming access to the EHR solution shall pass-through multifactor
authentication and authorization measures using a password and access token.
● Role-based Access control for authentication and authorization shall be the minimum
requirement. But, If possible, Attribute-based access control is preferable.
● Implementers shall depose the use of strong authentication and data protection policies and
operating procedures.
● Data access procedure shall consider a change in its access space to entertain different emergency
exceptions. Authorized and unauthorized access plus planned and unplanned exceptions shall
define the need for an emergency authentication process.
● Data access operations must be through access rights verification, and all access information
should be logged.
● An Institution or a provider representing the institution should define, assign and maintain access
roles.
● The ultimate owner of the data is the client. But Actors shall have data access grant, trust, and
delegation procedures based upon an agreed consented process. The focus of this document here
is given to EHR solutions than PHR. Patient portals, to access EHR records to support consumer
health informatics, are encouraged but clients' privilege to update and edit individual records are
not allowed.
● The system shall terminate a login session and report a user account after a maximum of three

consecutive invalid login attempts.
● Token based authentication mechanisms shall be inplace at the time of data exchange between
other systems.
● User name and a password with at least eight characters (a mixture of uppercase, lowercase
special characters and numbers) shall be used.
● The system should enforce and alert users to change passwords in a three month interval.
● The system session shall timeout and lock itself if it remains idle for five minutes.
● the System shall terminate if there above three attempts of invalid login attempts.
Integrity
Implementation Strategy:Integrity
● There should be a possibility to exchange partial or complete records while maintaining integrity.
● The EHR solution shall maintain the integrity of the data at rest and data at motion.
● The system shall have a data validation and verification mechanisms at the time of data capturing
Encryption
Implementation Strategy: Encryption
● The system shall have a builtin encryption technique for data management at motion and at rest.
● EMR solution should provide a Public Key Infrastructure(PKI). And shall confirm the legitimacy of
users and systems by enabling stronger, certificate-based security and identity services and
management tools to maximize network efficiency and security.
Audit Logs
Implementation Strategy: Audit Logs
● EHR solutions shall record audit information on all patient record transactions. The solutions shall
provide auditable resources, activities, services, and events when needed.
● The system should provide services for logging and storing events, such as creating, updating,
transmitting, receiving, and maintaining contents. These could be contents such as user name and
id, event time and status.

● The logs should be Immutable, Time-stamped, Auditable, Pseudonymised.
● The audit trails should be accessible and understandable to the client. The EHR solution should
create a secure audit log package with versioning, identification, and provision for describing
functional roles for role-based access each time a user accesses, creates, updates, or archives
personal health information.
● EHR solution Shall have an indelibility requirement that no permanent deletion of any Health
record should be allowed.
EHR Administrative Standards
The organization must place a legal hold and preserve audit log information from an EHR system to prevent
unauthorized access and use of the system for deliberate destruction, loss, and alteration of individual health
records. And the EHR system shall use the administrative data security safeguarding mechanisms and the
organization shall prepare business continuity, disaster recovery, contingency, risk analysis, and process
management plans for technical, administrative, and other security holes and incident management on EHR
towards ensuring the security of EHR system and clients’ data, additionally the organization must implement
the backup procedures, standard operating procedures, and the security safeguarding mechanism in place
with supporting tools detailing the privilege and authorization level for actors. And shall enforce security
measures against abnormal use of client’s data in EHR to socialize and build trust to all actors.
Implementation Strategy: Administrative safeguard
● The institution should implement standard operating procedure on the security management
process referring to national security guidelines and policies.
● The standard operating procedure shall discuss risk analysis and management to reduce risk and
vulnerabilities for EHR business continuity.
● The institution shall manage role based EHR service grant and sanction when violations happen.
● The institution shall assign a security official responsible for the development and implementation
of policies and procedures regarding privacy and security.
EHR physical Standards
EHR Physical safeguard standards emphasize the protection of workstations, network devices, and buildings,
amongst many others. Physical standards mentioned here shall give support to the technical standards stated
above. Security and Privacy officers shall follow equivalence and conformance procedures and guidelines to
harmonize the whole process in one pipeline.
Implementation Strategy: Physical safeguard
● Facility access control and devices usage and security control mechanisms should be defined.

● Data backup and restore procedures should be defined.
● Physical access controls shall be defined and entry control mechanisms shall be discussed. entry
and exit logs should be tracked so that every user's operation remains identified.
● Operational standards shall consider Radio Frequency Identification ( RFID) in user access,
equipment inventory inspections, and tracking.
Recommendation
The increased growing demand to demonstrate result brings Leadership and governance in frontline towards
building a robust secured, transparent health system, which ensures that strategic policy frameworks exist and
are combined with effective oversight, coalition-building, regulation, national policies attention to system
administration, security, privacy, and accountability, which is an intrinsic aspect of governance that concerns
the management of relationships between various interacting actors, stakeholders, including devices, systems,
individuals, firms, health systems, and other entities towards strengthening the security, privacy, transparency
and ownership through financing, monitoring, delivering and use the provided health services.
The health sector should create a coordinating body for safeguarding, governing the data ownership, access,
sharing, privacy, security, accountability for/at all levels of the health sector actors, and system functionality to
oversee preparedness for and responses to any threats related to data access, sharing, ownership, privacy,
and other health data-related security threats. The coordinating body should have a budget, logistics, and the
authority necessary to coordinate and govern all activities across the system, data, and the health sectors.

E H R system Implementation Requirement
Introduction
Implementing electronic health records at any facility requires a minimum requirement on the ground which
are needed for the smooth running and sustainability of the system. Having a shared health record requires
standard ICT infrastructure, skilled workforce, finance, leadership and governance etc . This implementation
requirement will specify the pre implementation requirements of EHR at a facility level and also the need for a
central shared service ICT infrastructure requirement. These requirements serve for all kinds of health facilities
at all levels of the health hierarchy. The quantity and specification of the proposed items could vary from
facility to facility depending on the type and size of the facility but at least this guideline serves as a check least
to see if all the necessary ICT infrastructure is in place at a facility before going to EHR implementation.
Scope
The scope of the implementation requirement is concerned with the minimum pre and post implementation
requirements both at individual facility level and at the central shared service level. Health facilities at all
levels of the health hierarchy and government, private and all other types of health facilities are considered in
the minimum implementation requirement. This Implementation scope addresses the minimum
requirements of electronic health records at facility level and central level where the shared record of clients’
information is kept. It also describes the network connectivity within facilities and the central level (MOH).
1. Objective
The main objective of implementation requirement standard is to set a minimum requirement for EHR
resources required for pre-implementation and operational stage at all types of health facilities in the health
sector and set a checklist of items and resources l required for EHR implementation.
The Specific objectives are to specify the minimum requirements of:
● Hardware requirements
● Software requirements
● Workforce requirements
● Network and connectivity requirements
● Asset management
● Change management
● Training
● Finance/budget
● Implementation
● Monitoring and Evaluation
● Power supply
● Mini data centers
● Readiness Assessment

Minimum Implementation Requirements for facilities
1.1 Pre-implementation
Implementing electronic health record systems(EHR) requires a wide range of prerequisites which have to be
inplace for the effective and sustainable use of the system. To implement an electronic health record system ,
a facility needs to fulfill the following minimum requirements.
1.1.1. Readiness Assessment

Every health facility intending to use an EHR system must first be assessed to determine its level of readiness
for implementation which enables facilities to evaluate the readiness of a site, and if necessary, to take action
to ensure that all requirements are met for successful EHR system implementation. THe assessment should
include organizational culture, management and leadership, operational readiness and technical readiness
1.1.2. Hardware requirements

Health facilities are expected to meet all the necessary hardware requirements for EHR implementation. The
required number and type of hardware devices might vary from facility to facility but needed to meet the
expected minimum specifications for the type of facility intended to be used. Based on the number of service
units and users of the system , the number and performance capacity of each hardware type varies.
The hardware devices should support both a stationary and mobility needs of services at a facility. Some
services at a facility could be served using fixed devices and others like inpatient and emergency departments
require mobile devices like tablets.
Hardware requirements include Personal computers, Server computers, mobile devices, printers, barcode
printer, barcode reader, Scanner, UPS, Biometrics devices and the likes.
Facilities need to have sufficient numbers of personal computers at each service unit. The computers have to
be connected to LAN and to a central server. Since patient data is to be stored in a central location every
facility needs to have server computers/computers which are capable of storing patient data the facility serves
and can serve the concurrent access of all the end users.
The Ethiopian EHR implementation follows E-first modality which requires patient data to be captured
electronically first and a summary of that data to be printed and put in the patient folder. For this purpose,
every facility is expected to have enough quantity of printers at suitable locations to print patient summary
data
Health workers at a facility are usually work by doing rounds at different wards and for this purpose there
should be enough number of mobile devices which can access patient record in the EHR
1.1.3. Software requirements

In order for an EHR system to run properly, in a facility and not to be targeted by malicious attacks, there
should be antivirus software installed at every personal and server computers.The antivirus software should be
regularly updated and needed to be a professional one with a proper license.
Besides facilities need to have either windows or linux based operating systems for the computers to be used to
run the EHR application. The minimum version of the operating systems for Server should be Microsoft
Windows Server 2012 with hyperV and for desktop computers Microsoft windows 10 or linux/ubuntu/ 14.04 or
Red Hat Enterprise Linux 7.
Mobile devices, like tablets, should support the minimum version of android 8.0 or IOS 10.0 operating system.
1.1.4. Workforce requirements

For successful implementation and sustainability of the EHR system at any health facility, skilled manpower
with IT/HIT background and an end user well-trained on ICT usage is essential. In addition to that an
appropriate organizational structure designed for the IT department is expected at all facilities. The
implementation team or workforce includes skilled manpower with the necessary expertise or skill mix.There
should be a help desk at all the facilities at all times to ensure the availability of the system.
The EHR system to be deployed at any facility should take into consideration the skill level of end users and
organizational culture and it should be some opportunity for training and capacity building which capacitates
the end user to fully utilize the application for better service delivery. The EHR system should have a high
Intuition capability which takes into consideration the ICT skill level of all kinds of users at a facility.
1.1.5. Network and connectivity requirements

All the service units of a facility need to have a local area network (LAN) implemented.This network should
also be connected to the local hub and/or central shared health record.
● There should also be a wide area network (WAN) connecting every facility either by virtual private
network(VPN), like HealthNet, or through the internet to connect central shared health records.
● The band width of the connection should be strong enough for patient data transmission at a facility
level and data exchange with other facilities via the shared services.
● Wireless connectivity at each facility is required since the EHR implementation requires mobile devices
like tablets. The strength of the wireless connectivity and the wireless access points specification
depends on the type of the facility.
● The Security of the LAN and Wireless connectivity of the facility should fulfill end-to-end encryption,
access control tools (like wireless key or Password) and physical security to secure patient data
transfer within a facility and central data center.
1.1.6. Asset management

In order to properly manage ICT equipment which are important for smooth running of the EHR system,
facilities should have a planned asset management strategy in such a way that ICT equipment are uniquely
identified and documented. Preventive & corrective maintenance should also be tracked. There should also be
a procedure and guideline that ICT equipment should be replaced or newly installed.
To smoothly run the service ICT equipment accessories and spare parts should be available at a facility for
quick replacement of parts like keyboards, mouse, monitor, toners, papers etc..
1.1.7. Change management
Facilities planning to implement an EHR system need to have a change management strategy which enables
them to smoothly transit to the new system. The change management strategy should be part of the facilities
strategic document and clearly depicts how new systems like EHR are to be adopted and sustained. There
should also a mechanism on how champions are selected, incentivized and set a clear strategy on how to
migrate previous data.
How the data generated from the EHR system be used at local level for decision making should also be
indicated on the strategy.
A service level agreement (SLA) among the IT department and the service giving units in the health facility in
order to ensure effective response to any support request on the EHR system.
The change management implementation contains the facility changing processes and changing the EHR
system. The overarching purpose of change management is to accelerate the speed at which health facilities
move successfully through the change process so that anticipated benefits of an EHR are achieved faster.
Facilities should establish a Change management Team, TWG and steering committee in the facility.
Some of the major activities expected are:
● responsibility enabling and championing digital transformation throughout the facility.

● They must have adequate time, be committed, excited, experienced or trained to fulfil their
important roles
● They should track the minor and major issues on the EHR system and plan the mitigation
strategy
● They should have a mechanism to ensure usage of data generated by the system for decision
making and planning.
● They should prepare a change management strategy and implementation plan.
● The team should design a business continuity plan for sustainability and smoothness of service
delivery in the facility.
● There should be a disaster management and recovery plan to ensure there is no or minimum
disruption of services.

● There should be a clear change request workflow and feedback mechanism that is visible for
all.
● ICT team also has to document all change requests and corresponding mitigations.
● To manage requests for major and minor change request, the change management team
should prepare tools like change request form, change management log, etc
● Every change should have passed the following steps: Generate change request, Log Change
request status, Evaluate Change request, Authorize and Implement.
1.1.8. Training
Health facilities implementing EHR systems need to have clear strategies on user training. The strategy should
indicate mechanisms for new employees joining the facility to start using the system. Facilities also should
avail training resources and space for EHR capacity building purposes. Facilities should also put in place a
Mentorship program for a specific period of time to enable end users properly use the system.
1.1.9. Finance
For the sustainability of an EHR implementation , a facility needs to set aside a budget for the procurement of
computers, spare parts, consumables like papers & inks, generator fuel and various recurrent
expenditures.The budget should be clearly indicated in the facility annual budget plan.
1.2 During Implementation /Operation of EHR
The section targets program managers who are implementing and managing EHR systems.
1.1.10. Requirement
1. A comprehensive implementation and management plan covering all phases of EHR implementation
shall be developed in conjunction with all relevant stakeholders.
2. EHR implementers shall identify a team at the facility-level, representing all EHR stakeholders, to guide
the implementation process.
3. A phased approach to EHR rollout will be adopted to minimize service interruptions.
4. The implementation team should plan for a post-implementation review within two weeks of EHR
rollout.
1.1.11. Guidance

1. Preparatory phase: Address budgetary and specification issues surrounding hardware and
software purchases, governance structures for implementation, and identification of staff,
their roles and training needs in line with defined competencies.
2. Implementation phase: Specify processes for installation of hardware and software, usability testing,
user acceptance testing, and appropriateness testing.
3. Transition: Specify how EHR users will transit from using the existing manual or paper- based health
records system to the new electronic system and address data migration issues such as entry of
backlog data.
4. Post-implementation review: following the implementation of an EHR system, stakeholders should
conduct a joint review to identify areas of success and concern, and to document lessons learned for
the improvement of future implementations. In the plan it is important to specify the timeline and
persons responsible for conducting the review.
Major focus areas should include:-
● Assigning data manager or administrator to ensure taking backup consistently

● State backup schedule and assign responsible person
● Provide training whenever update or new component is added on the system
● Tracking all issues identified and fix or report on time to the appropriate section
● Monitoring and evaluation mechanisms should be applied for all activities.
1.1.12. Power supply requirements
For Successful implementation of EHR systems it requires a reliable power supply system. A variety of electric
power sources may be available for different facilities, including the main power grid, solar power, generator
power or wind power.For continuous availability of an EHR system at a facility it is required to have an
alternative power supply which can fully take over the main supply in case of interruptions.
The following Power supply requirements should be fulfilled : -
● Servers,Switches and workstations must be powered by an Uninterruptible Power Supply (UPS)

sufficient to power the system for long enough to ensure safe shutdown, and to prevent corruption of
databases.
● Testing and maintenance of power backup units must be done to ensure their reliability.
● Surge protection and voltage stabilization should be provided to protect all computer equipment
within EHR installations against power surge damage.
● All batteries, whether those in laptops or in UPS units, should be tested with sufficient frequency to
detect any loss in capacity below the threshold for useful operation.

● Regular documentation of power testing should be maintained. Every facility needs to implement a
maintenance schedule for power systems such as generators and UPSs.
1.1.13. Mini/Local Data center
The EHR system implementation at specific facilities must have a locally established Mini data center equipped
with all the necessary Servers, Networking equipment, UPS and cooling systems and security mechanisms.
Depending on the type and size of facility the data center equipment might vary from facility to facility but
must have the minimum basic functionalities required for EHR implementation.
1.3 Monitoring and Evaluation
All EHR implementations shall have a monitoring and evaluation plan to guide implementation and evaluate
the successes and challenges.
The implementation team should identify and document key process milestones that will be used to monitor
the EHR installations, define key questions and outcome indicators for periodic evaluation of the EHR systems,
the established change management team, TWG and Steering committees based on the overall objectives and
expectations.
The M&E, should answer the following questions:
a) Does the EHR improve patient care?
b) Does the EHR improve record keeping?
c) Does the EHR improve reporting?
Recommendations
EHR system implementation entails proper planning and mobilizing resources. It is also required to properly
install ICT infrastructure and train staff for smooth deployment of the system. Some of the basic things that
must be taken into account before and during the EHR System are:
● It is advisable to implement the EHR system parallel to the Manual (Paper based) option until the
digital one matured enough
● The Change management should prepare the implementation plan and mitigation strategies
● Depending on the existing situation of the facility, it is advisable to implement EHR in phase-based
approach

● Health Facilities should make sure that the data generated by the EHR system is used for local
decision making and planning
● The initial step of EHR implementation is to come up with a detailed strategic plan for the activities
ahead. Assign duties and responsibilities for the team members, identify the physician champions, and
create a space for mutual support and dependence, follow implementation plan and correct any issue
at the initial stage.
● Facilities should benchmark those facilities from already implemented the EHR system and take
lessons from their practical experience
● Backup of EHR data should be automated within the system wherever possible to ensure consistency.
● Facilities should migrate patient data which has been captured previously either on paper on digitally.
The data should at least contain the previous three years patient health record
● Facilite should make sure that A secure physical environment is provided for computer equipment
● Computers used for handling and storing health information should be dedicated to that function and
not used for other purposes such as personal document processing, audio and video file downloads,
Internet browsing, or other unrelated functions .
● All computer systems must have virus detection software installed and updated regularly.

2. Citations and References
No Type Standard Name Intended Purpose Remark
1 Standard Electronic health To recommend adopting standards,

records in India implementation specifications, and to enhance
the interoperability, functionality, utility, and
security of Health information technology
2 Handbook Handbook for The EHR implementation handbook is a

Electronic Health milestone in our understanding of the
records challenges that arise in planning and executing
implementation an EHR Implementation and impact of such an
implementation on healthcare processes and
organizations.
3 Manual Electronic Health Designed to serve as a basic reference when

Records: Manual for
exploring the development and implementation
Developing Countries
of Electronic Health Record
(EHR) systems.
4 Standard Standards and Provides guidance for EHR system developers

Guidelines for and implementers, as well as health facilities in
Electronic Kenya that are contemplating or currently using
EHR systems to manage patient data
Medical Record
Systems in Kenya

References
● Electronic Health Record by Published by John Wiley & Sons, Inc., Hoboken, New Jersey.
Copyright # 2013 by The Institute of Electrical and Electronics Engineers, Inc.
● Electronic health record standards by India, department of health and family welfare, Nirman
Bhawan, New Delhi-110108, April 2013
● Guidance on Terminology Standards for Ireland, health information and quality authority, July
2017
● General-Practice-Messaging-Guidance-version-4.0 for Ireland health information and quality
authority
● MOH draft National data access and sharing directive, February 2020
● Ethiopian PKI X.509 Certificate Policy, Draft Version 1.0 Information Network Security Agency,
INSA 2012 E.C
● Information Revolution, Ministry of Health, MOH, Ethiopia
● Standards and Guidelines for Electronic Medical Record Systems in Kenya, By Ministry of
Medical Services Ministry of Public Health and Sanitation
● List of medicines for drug shop (LMDS) fourth edition, Ethiopian Food, Medicine and Health Care
Administration and Control Authority, November 2012.
● http://80.82.78.35/get.php?
md5=7fc78217287058a1fb30173851999397&key=0M1XX7HLCTX940JB
● EHR-Standards-2016-MoHFW.pdf

Annexes
2.1. Minimum Specifications of Required EHR Infrastructure
Items Health center Primary General Specialized Specification Remark

Hospital hospital hospital
Computer Minimum one Minimum Minimum Minimum Core I7 with 8 ● Adequate computer should
Desktop one one one GB of RAM and be provided based on
/laptop Desktop Desktop Desktop 4 CPUs readiness assessment
computer for /laptop /laptop /laptop ● Number of computers is
each clinic computer computer computer based on the number of
for each for each for each service units(Desk units) at a
clinic clinic clinic
facility
Minimum
one
Desktop
/laptop
computer
based on
clinical Unit
Printer Networked Networked Networked Networked Medium duty ● Quantity is based on the
printer printer printer printer for health number of places where
centers and patient summary data
primary produced or number of nurse
hospitals and station
heavy duty ● Pre implementation
printer for
assessment should address
others
the required quantity
Scanner A4 scanner A4 scanner A4 scanner A4 and A3 Medium *Quantity is One per

scanner scanner facility/MRU
*not mandatory for Health

centers
Barcode Barcode Printer Barcode Barcode Barcode Barcode ❖ Quantity is one per MRU
Printer Printer Printer Printer Printer ❖ *not mandatory for Health
centers
Barcode Barcode reader Barcode Barcode One USB Barcode ❖ Quantity is based on service
Reader reader reader Barcode reader units requiring barcode
reader for reader
each *not mandatory for Health

laboratory centers
UPS One UPs per PC One UPs per One UPs per One UPs per With enough ❖ Depending the situation a
, Server & PC , Server PC , Server PC , Server capacity to facility can implement
switches & switches & switches & switches transition the shared UPS for PCs and
devices to Servers
alternate
source of
power
Server Medium end Medium One High One High ❖ One server per health center
server end server end and end and Server and primary hospitals and
one one Minimum ❖ Two servers for the General
Medium Medium requirement and Specialized hospitals(1
end servers end servers high end server and 1
❖ Processor
medium end server)
2xIntel
Xeon
Gold
6242
2.8G,
16C/32T,
10.4GT/s,
22M
Cache,
Turbo,
family
❖ Memory
Capacity :
32GB
RDIMM,
2666MT/
s, Dual
Rank
❖ Operatin
g System
Support:
Ubuntu,
Hyperviso
r,
Microsoft
Windows
Server,
VMware

ESXi
Dimensions:
Form factor:
Rack
mountable
(2U)
❖ Hard
Drives:
(5) 1.2TB
10K RPM
SAS
12Gbps
512n
2.5in Hot-
plug Hard
Drive
External device for device for Establish Facilities shall ❖ The facility should take
storage device data backup data backup Disaster maintain a backup and defines
1TB USB Hard
Recovery backup plan standards for Daily Backup,
disk
site or that On-site and Off-site backup,
5TB USB >=10TB USB documents Backup Log Template,
Hard disk /Network backup Backup of Patient Data
Hard disk >=10TB procedures
❖ Backup Medium size can be
USB/ and routines.
defined based on the facility
Network data size.
Hard disk ❖ Backup should be kept at
separate place other than
the Storage Server
LAN All service units All service All service All service CAT 6 UTP for ❖ Number of nodes should be
connectivity should be units should units should units should intera- facility greater or equal to the
connected via be be be connectivity number of computers per
LAN connected connected connected and fiber cable service units
via LAN via LAN via LAN for back end ❖ Pre implementation
connection. assessment(number of
nodes, uplink/back bone
connection option, etc.)
should address the required
quantity
❖ Back end and building to
building could be connected
by fiber optic cable

depending on the site.
Wireless Minimum one Minimum Minimum Minimum Industry ❖ The number of access point
connection per floor one per one per one per standard could be determined based
/based on floor floor /based floor /based floor /based wireless on network coverage and
distance/ on floor on floor on floor devices signal strength for each
distance/ distance/ distance/ service units
❖ Adequate number of access
points to cover all service
units with good strength
WAN/VPN At least one At least one At least one At least one VPN data, ❖ The Bandwidth size could be
connection line connection connection connection connection determined based on
line line line throughput or size of data
● 6Mb/s
transact(shared) to the
data ● 8 Mb/s ● 10 Mb/s ● 12
central shared Server
data data Mb/s
data
IT Two Three Five Five Degree on ❖ Depending on the size and

professionals Computer type of facility, required
● System ❖ System ❖ System ❖ System
science or professionals must be
admin Admin Admin Admin related fields determined during the
● Technical ❖ Networ ❖ Networ ❖ Networ and minimum readiness assessment.
Support k k k 2 years work
Admin Admin Admin experience for
and/or and/or and/or System(EHR)
❖ Technic ❖ Three ❖ Three and Network
al Technic Technic Administration
Support al al
Support Support
Mini data Required Required Required Required Server, The Size of data center could be
center UPS,Security decided based on facility type
mechanism, and size
cooling option
and Network
equipments,Ra
ck
Operating Minimum Minimum Minimum Minimum Licensed Licenced Windows server

system Windows 10, Windows Windows Windows Windows
64bit /Linux 10, 64bit 10, 64bit 10, 64bit Server 2012
Ubuntu 16.04 /Linux /Linux /Linux and above with
and above/ for Ubuntu Ubuntu Ubuntu hypervisor
desktop 16.04 and 16.04 and 16.04 and
computers and above/ for above/ for above/ for
Microsoft desktop desktop desktop

windows server computers computers computers
2012 and and and
datacenter Microsoft Microsoft Microsoft
edition with windows windows windows
hyper v for server 2012 server 2012 server 2012
servers datacenter datacenter datacenter
edition with edition with edition with
hyper v for hyper v for hyper v for
servers servers servers
Antivirus Licenced Licenced Licenced Licenced The type of Minimum licence is for one year
antivirus for antivirus for antivirus for antivirus for antivirus is run
each desktop/ each each each in different
Laptop/ desktop/ desktop/ desktop/ types of
computers and Laptop/ Laptop/ Laptop/ operating
Servers computers computers computers systems...
and Servers and Servers and Servers
2.2. Readiness Assessment Checklist

Category Response Remark
General Data
Facility Name
Facility Type
Region
Zone/Subcity
Woreda
Respondent Name

Data collector Name
Baseline Data
Number of functional departments
Number of Service delivery points
Number of inpatient Departments
Number of emergency units
Number of Outpatient service units
Number of Drug dispensing units /pharmacy

units/
Number of drug stores
Number of Lab service units
Number of MRU Windows
Number of Triage Units
Number of Nurse stations
Average Number of patient seen per-day
Technical Staffs
Number of Specialists
Number of GPs
Number of Health officers

Number of Nurses (all types)
Number of Midwives
Number of Lab technologists
Number of Pharmacists
Number of others
Supportive Staffs
Number of Admin and Finance officers
Number of Cashiers
Number of MRU workers
ICT Structure and Professionals
Availability of IT Structure (Yes/No)
Number of IT professionals
Number of IT professionals with BSc/MSc
Number of IT professionals with diploma
Number of Permanent IT professionals
Number of Contractual IT professionals
Other Software Information
Other Software Available(Yes/No)
Software1 Name and Purpose

Laboratory with LIS (Yes/No)
EHR implemented (other than MRU)? (Yes/No)
Number of Service units using EHR
Ever used EHR for patient management?

(Yes/No)
Ever used the previous EMR for monitoring

Facility's performance (Yes/No)?
Ever eHMIS/PHEM extracted data from EMR

(Yes/No)?
ICT infrastructure
Availability of Generator as power backup

(Yes/No)?
If Yes, Generator capacity (KVA)
Number of Computers available (excluding

admin units)
Number of Functional Computers with Network

card
Number of Server computers
Number of portable devices (Laptop/Tablet)
LAN /WAN Connectivity

Functional LAN? (yes/No)
Availability of VPN? (Yes/No)
Number of Departments with LAN connection
Connectivity test done ? (Yes/No)
Number of Nodes per department
Wireless connection availability? (Yes/no)
Departments covered by wireless network
Internet/VPN Connection Bandwidth
Printers
Number of printers available
Number of Network printers
Number of functional UPS
EHR Readiness Data
Leadership /Management/ (Yes/No)
Is the Strategic plan integrated with EHR

implementation?
Is EHR considered as a key tool to meet goals?
Do EHR implementation goals and objectives

are set?
Do Leadership understand EHR benefits?

Management is willing to plan and implement
EHR?
Does the management willing to allocate

appropriate resources?
Finance and Budget (Yes/No)
Facility can allocate budget for IT maintenance?
Facility can allocate budget for the ongoing EHR

implementation process?
Budget is available to hire IT professionals?
Information /Data management (Yes/No)
Management recognized the importance of a

single unified health IT system?
Management recognized timeliness,

completeness and accuracy as data quality
features?
Does data/information from EHR can be used

to support decision making?
IT infrastructure, Management & Support (Yes/No)
Computers LAN and other hardware devices

requirement assessment for EHR
implementation performed?
The existing IT infrastructure is compliant to

EHR standards?
Staffs are trained on EHR?
IT staffs are experienced in EHR system

implementation and providing support?
IT staff hiring for EHR implementation is

included in the facility's annual plan?
Workflow and Process
Current service units workflow and processes

are identified and documented?
Service units where EHR can best applied are

identified?
Ways how EHR improve workflows/ processes

are identified?
Clinical /Administrative/ staffs
Facility has identified and trained those staffs

that can lead the EHR implementation?
Motivational incentives are planned for the

staffs implementing EHR?
Facility has planned to use champions/ super

EHR users?
Staffs understand data flow and their roles in

providing care?
A staff assigned as project manager?
Training and Support
Budget allocated for EHR training for staffs?
EHR training plan includes all relevant staffs &

doesn't affect the routine hospital activities?

Management agreed to support staffs at the initial
stage of the change and learning curve of EHR?
EHR training is planned to be institutionalized?
Communication
EHR staff sensitization conducted?
EHR implementation stakeholders are identified?
EHR implementation stakeholders achieved

good understanding of EHR benefits?
Each stakeholder understands their roles for the

implementation success?

National Standard For EHRs Development and Implementation Zero Draft

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

National Standard For EHRs Development and Implementation Zero Draft

Uploaded by

Copyright:

Available Formats

National Standard for Electronic

Health Record System (EHRs)

Adama, Ethiopia 2021

Produced in Feb, 2021

Produced in Feb, 2021

Produced in Feb, 2021

Produced in Feb, 2021

EHR An Electronic Health Record is the systematized collection of patient and

Module A self-contained software component that interacts with a larger system. A

Confidentiality Confidentiality measures protect information from unauthorized access and

Produced in Feb, 2021

[Background and Rationale]

Produced in Feb, 2021

Produced in Feb, 2021

E H R System Architecture and Development Process

Produced in Feb, 2021

Produced in Feb, 2021

1. Basic demographic and clinical information

● HL7 - Electronic Health Record System Functional Model, Release 2.0.1

Produced in Feb, 2021

E H R system functional requirements

Produced in Feb, 2021

Order and referral management

● Availing clinical guidelines

Produced in Feb, 2021

Data management, use and reporting

Produced in Feb, 2021

Contents of E H R core functionalities

Functional specification for E H R Priority Level

Produced in Feb, 2021

6. The system shall support displaying summary of services provided to patients H

Produced in Feb, 2021

19. The system shall support capability of setting price of services H

B.1. Basic Demographic /Identification

24. The system shall support updating demographic characteristics if necessary H

Produced in Feb, 2021

Produced in Feb, 2021

Progress note and treatment plan

C. Order and referral management

55. The system shall support prescribing pharmaceuticals based on selected H

58. The system shall support capabilities to manage consent order H

Produced in Feb, 2021

64. The system shall support transmitting orders to other systems H

Produced in Feb, 2021

G. Data management, Use and Reporting

H. Exchange of Electronic Information

92. The system shall have Communication/messaging capabilities to exchange patient H

Produced in Feb, 2021

98. The system may have educational materials for patients L

E H R System Modules (sub systems)

Produced in Feb, 2021

Module Functionality and Minimum Data Set Requirements

Produced in Feb, 2021

Minimum Data Set

SN Data Element /Field Data Form (data Category Relevance

1 Chief complaint text patient form Clinical

2 Duration of chief numeric patient form

3 Onset of chief complaint text patient form

4 Location of chief text patient form

5 history of present illness Free text patient form

Produced in Feb, 2021

7 Surgical History free text patient form

8 Gynecologic history free text patient form