Ethiopia's EHR Standard: What the Ministry of Health Requires
In 2021 the Ministry of Health published a 136-page national standard for electronic health record systems. It lists 102 functions, 15 modules, the coding and security rules a system must follow, and what a facility must have in place first. Here is what it says, in plain terms.

If you are buying, building or selling an EMR in Ethiopia, there is a national document that already describes what the system should do. Most clinic owners have never read it.
The Standard for Electronic Health Record System (EHRs) in Ethiopia was published by the Federal Ministry of Health in July 2021 (MoH EHR standard, via JSI). It runs to 136 pages. It sets out the functions an EHR must support, the coding standards it must use, the security rules it must follow, and what a facility needs in place before it switches one on.
The Ministry wrote it because the alternative wasn't working. In the foreword, a State Minister describes a lack of common standards that "resulted in fragmented and siloed solutions which don't exchange health and health related data with one another." Data from public and private EMRs was supposed to flow into the national health information system automatically. "So far this is not possible," the foreword says, "due to the absence of EMR standards in the country."
This post summarises the standard for orientation. It isn't an official interpretation. Read the document itself before making procurement decisions.
Who it applies to
Everyone, on paper. The scope covers "all health facilities/care providers dealing with individual patient health recording (public, private, other government & non-government health facilities), EHR software developers/vendors and implementers, EHR system regulators/evaluators in Ethiopia." It applies whether the system is built in-house, customised, or bought off the shelf.
The Minister's message is direct: "The standard should be followed by all facilities that plan to develop and implement any EHR system/solution."
Is it mandatory?
The language says yes. The enforcement is less clear.
The standard itself states that it "does not include legal frameworks for abiding the rules/standards set by it." It says existing EMR systems should be updated to match it, and that "to be nationally certified... an existing EMR system should go through evaluation by the national appropriate governance body." We could not find a public list of certified systems as of November 2026.
The direction of travel is toward checking. In early 2025 the Ethiopian Standards Institute and the Ministry released a draft hospital accreditation standard (ES 7191:2025) for public comment. It includes EMR criteria: that the EMR "integrates seamlessly with other existing systems, such as laboratory, pharmacy, and billing systems, to prevent data silos," that hospitals keep audit trails for all electronic health information, and that staff get ongoing training (ES 7191:2025 draft, MoH).
The practical reading: whether or not anyone audits your clinic against it this year, the EHR standard is the best available specification for what a good system in Ethiopia looks like. Use it as your buying checklist.
102 functions, each with a priority
The core of the standard is a table of 102 functions grouped into eight areas. They cover demographics and health information, orders and referrals, results, decision support, administration, data and reporting, data exchange, and patient support.
Each function is rated:
- High (H): "Functionalities an EHR system must support". 79 of the 102 carry this rating.
- Medium (M): functions the system is "required to have or support". 13 functions.
- Low (L): functions that are "good to have". 9 functions.
(One function, deactivating the files of deceased patients, has no rating in the table. The executive summary says "ninety functionalities"; the table itself lists 102.)
Some of the High priority functions, in the standard's words:
- "Generate a unique individual identifier for new clients (MRN)" and "support resolving duplicate patient records."
- "Support maintaining audit logs," with dates and timestamps for all entries.
- "Manage different system users with different roles and privileges."
- "Support queue management for all services" and "manage patient appointments."
- "Display reminders/alerts for abnormal lab results, drug-drug interactions, allergies."
- Reminders for immunisation due dates and antenatal visits, and calculation of gestational age and expected date of delivery.
- "Automatically trigger an alert upon documentation of a diagnosis or an event required to be reportable to MOH and/or EPHI."
- "Generating aggregate HMIS reports required by MOH" and "electronically transmit aggregate national reports to national HIS systems such as DHIS2."
- "Capture and manage billing information and claim management for all transactions."
And some that are only Low: a patient portal, educational materials for patients, and sending patients appointment reminders by message. That last one is worth noticing. Reminders are one of the cheapest ways to reduce no-shows, but the standard treats them as a nice-to-have, not a requirement.
The 15 modules
The standard lists 15 modules (subsystems) and says "the inclusion of the modules depends on the type of health facility":
- Triage and registration
- Liaison (including bed management)
- Outpatient
- Emergency
- Inpatient (including nursing care)
- Maternal, neonatal and child health
- Non-communicable diseases (diabetes, hypertension, cardiac disease, asthma, epilepsy and others)
- HIV chronic care
- Tuberculosis
- Laboratory
- Diagnostic and imaging
- Pharmacy
- Rehabilitative and palliative care
- Billing
- Reporting
It also says a queue function "should also be an integral part of the EHR system." Each module chapter lists its own functions and the minimum data set it must capture.
The coding rules most buyers never ask about
This is the part that decides whether your data can ever leave your clinic in a usable form. The standard adopts:
| What is being recorded | Standard the EHR must use |
|---|---|
| Clinical terms | SNOMED CT (the Global Patient Set) |
| Lab tests and results | LOINC, mapped to the national lab list |
| Medicines | RxNorm, mapped to the national drug list |
| Diagnoses for reporting | NCoD (National Classification of Diseases), with mapping to ICD-10/11 |
For exchanging data between systems, it says HL7 v2.4 "should continue to be supported," CDA "should be used for exchange of documents," and DICOM should be implemented for imaging. FHIR, the newer web-based standard, "should be considered for new initiatives on a use case by use case basis" once it is mature.
You don't need to understand these standards in depth. You need to ask a vendor which ones their system uses, and get the answer in writing.
Security: what the standard prohibits
The security chapter reads like a list of habits common in Ethiopian clinics, each one ruled out:
- No shared logins. "Sharing of individual user's credentials and or use of common credentials is prohibited."
- Role-based access at minimum. Each user sees what their role allows. Anyone accessing the system should pass "multifactor authentication and authorization measures using a password and access token."
- Every access is logged. Audit logs should be "Immutable, Time-stamped, Auditable, Pseudonymised," and understandable to the patient.
- Encryption. "The system shall have a builtin encryption technique for data management in motion and at rest."
- No permanent deletion. "There shall not be permanent deletion of client data." Records are deactivated, with the role and time recorded.
- The patient owns the data. "The ultimate ownership of the health data resides with the client." A patient portal may show records but must not let anyone edit or delete them.
These line up closely with Ethiopia's data protection law, which treats health data as its most sensitive category. See Proclamation 1321/2024: Patient Data Is Now a Legal Duty.
What it asks of the facility, not the software
A whole chapter is about readiness. Before going live, the standard expects a facility to:
- Complete a readiness assessment. A checklist is annexed, covering culture, leadership, operations and technical readiness.
- Have the hardware. Enough computers at each service unit, printers, tablets for ward rounds, and UPS units.
- Secure the power. Servers, switches and workstations "must be powered by an Uninterruptible Power Supply (UPS)" long enough for a safe shutdown, with an alternative supply that "can fully take over the main supply in case of interruptions."
- Connect it. A local network across service units, plus a wide-area connection by VPN (such as HealthNet) or the internet.
- Have a local data centre. "A locally established Mini data center," scaled to the size of the facility.
- Staff it. IT staff with health IT skills, and a help desk "at all times."
- Train people properly. A training strategy that covers new staff, and a mentorship programme for a set period.
- Budget for it. Computers, spare parts, paper, ink and generator fuel should appear in the annual budget.
- Write down the backup plan. Media, frequency, who is responsible, where backups are kept, and how to restore.
- Migrate old records. Bring over "at least... the previous three years" of patient records, from paper or an old system.
Two of its recommendations are worth reading against the Ethiopian evidence. The standard advises running the EHR "parallel to the Manual (Paper based) option until the digital one matured enough." Research in Addis Ababa found that dual paper-and-digital workflows were a named barrier to EMR use: the digital copy was the one that got skipped (our research note). If you run both, set a date to stop.
And the standard's emphasis on training is backed by the data. Training was the strongest modifiable predictor of whether health workers used an installed EMR (Tegegne et al., 2023).
The standard's own selection criteria
The standard lists what facilities should weigh when buying or building a system:
- Module capability
- Vendor reputation (quality of product, service and support)
- Interoperability with other systems
- Licensing and ownership model
- Scalability
- Hardware and infrastructure requirements and their cost
- Whether it meets the needs of patients, providers and the business
- The product roadmap
- Feedback from current customers
The licensing and support criteria carry a lesson from Ethiopia's own history. The national hospital EMR adopted in 2013, SmartCare, was found to be outdated in at least one region after its supporting project phased out (Tolera et al., 2022). Ask who will support the system in five years, and what happens to your data if they don't.
A checklist to take into a vendor demo
Built from the High-priority requirements above. Ask the vendor to show each one:
- Register a new patient. Is an MRN generated? Try registering the same patient twice. Does it catch the duplicate?
- Log in as two different staff members. Do they see different things? Can you find the audit log of who opened a record?
- Order a lab test and enter an abnormal result. Does an alert appear?
- Prescribe two drugs that interact, or one the patient is allergic to. Does it warn?
- Generate last month's HMIS report. Can it be sent to DHIS2?
- Which disease classification does it use? Does it map to NCoD and ICD-10?
- Export one patient's full record. In what format?
- Try to delete a record. It should only be possible to deactivate it.
- Where is the data stored, and how is it backed up and restored? (If the data is hosted outside Ethiopia, Proclamation 1321/2024 has rules on cross-border transfer.)
- Can it bring in three years of your existing records?
What the standard doesn't settle
The standard is from 2021, and some of it is written with hospitals in mind. It anticipates this, saying its criteria "may be tailored to fit different types of facilities" across Ethiopia's three-tier health system. A five-room outpatient clinic doesn't need an inpatient or emergency module. Its "local mini data centre" requirement was written before cloud hosting was common in Ethiopian clinics, so ask how a cloud-hosted system fits it.
We also couldn't find a published, current list of systems the Ministry has certified against it. If certification matters to your procurement, for example for a donor-funded or public tender, ask the Ministry's health information technology directorate directly.
The standard sets out what an Ethiopian EHR should do. Most of it is specific enough to test in a 30-minute demo.
Sources
- Federal Ministry of Health, Ethiopia. Standard for Electronic Health Record System (EHRs) in Ethiopia. July 2021, 136 pp. Resource page via JSI Data Use Partnership. All quotations above, unless otherwise linked, are from this document.
- Ethiopian Standards Institute and Ministry of Health. Ethiopian Hospital Accreditation Standards ES 7191:2025, draft for public comment. 2025. Sections 2.9.2 and 2.9.8 (EMR and health information criteria).
- Tegegne MD, Wubante SM, Kalayou MH, et al. Electronic Medical Record System Use and Determinants in Ethiopia: Systematic Review and Meta-Analysis. Interactive Journal of Medical Research 12:e40721, 2023.
- Tolera A, Oljira L, Dingeta T, Abera A, Roba HS. Electronic medical record use and associated factors among healthcare professionals at public health facilities in Dire Dawa, eastern Ethiopia. Frontiers in Digital Health 4, 2022.
- Bekele TA, Gezie LD, Willems H, et al. Barriers and facilitators of the electronic medical record adoption among healthcare providers in Addis Ababa, Ethiopia. DIGITAL HEALTH 10, 2024.
This post summarises a public Ministry of Health document for orientation. It is not an official interpretation or legal advice. Check the current text with the Ministry of Health before relying on it.
See Bloom in your clinic
Fewer no-shows, less paper, cleaner billing — in one calm system your team will actually use. Book a short demo and we'll show you how.


