Software as a Medical Device: Regulatory Pathway in Ethiopia

1. Key takeaways

Ethiopia maintains a dedicated guideline for Software as a Medical Device (SaMD), EFDA-GDL-094, and at the same time lists software / firmware as a standalone item of non-clinical evidence in Section 3.4.5 of the non-IVD registration requirements guideline EFDA/GDL/097. Combined with the definitions article, which expressly includes software within the scope of medical devices, standalone software is unambiguously a regulated device in Ethiopia: it must be classified under the applicable classification system, submit software lifecycle and verification evidence in accordance with the dossier requirements, and assess at every algorithm update whether the change constitutes a variation requiring prior approval.

The practical consequence is that software teams should plan their Ethiopian submission as a device project from the start, not as a hardware registration with an appendix. The evidence standard, the classification analysis, the change-control regime and even the labeling mechanism all follow device logic. Organizations that discover this only after filing typically face requests to restructure the technical content — a delay that disciplined early mapping of the requirements would have avoided entirely.

2. Legal basis

3. Expert insights

Insight 1: software is written into the definitions article, so the attribute dispute essentially does not exist in Ethiopia. The definition of a medical device expressly includes software as a type of article. Companies do not need to argue, as in some markets, whether software counts as a device; they can move directly into classification and dossier work. This removes one whole front of regulatory debate that consumes months elsewhere, and it also means there is no advantage in framing a software product as a non-regulated accessory — the definitional question has already been settled at the level of the statute.

Insight 2: software evidence sits under non-clinical evidence, not under administrative documents. EFDA/GDL/097 places software / firmware within Chapter 3, non-clinical evidence, alongside physical and mechanical characterization, chemical and material characterization, electrical safety and electromagnetic compatibility, and radiation safety. This means software undergoes technical review of the same intensity as hardware — it is not submitted as an annex. The lifecycle documentation, verification and validation evidence must therefore be prepared to the same completeness standard as, for example, the electrical safety test reports, with traceable versions and defined scope.

Insight 3: classification follows the logic of with the device, or determined separately. Under the internationally accepted classification principles that Ethiopia applies: software intended to run a device, control a device or influence its functioning is usually classified at the same level as that device; software that serves as an accessory to a device (not necessary for the device to function) is classified separately. The criterion is not the size of the codebase but the role the software plays in the clinical use. The same binary choice determines whether one classification analysis suffices or two parallel ones are needed.

Insight 4: algorithm updates trigger change management, not silent upgrades. Article 21(1) of the Food and Drug Administration Proclamation No. 1112/2019 provides that any change introduced that affects the safety, quality or effectiveness of a registered device must be notified and approved before it is placed on the market. For SaMD, model retraining, expansion of indications and modification of key algorithms all require a change-impact determination first. A release process that ships first and assesses later is non-compliant by design; the impact assessment must sit upstream of the release decision, with its conclusion documented.

Insight 5: electronic labeling offers software products flexibility in delivery form. Section 5.3 of EFDA/GDL/097 contains provisions on electronic labeling (e-labeling), and EFDA-GDL-084 sets out the labeling requirements in detail. For standalone software with no physical packaging, the conditions for applying e-labeling must be confirmed case by case; availability cannot be assumed. The submission should state how the labeling will be delivered, displayed and kept current, so that the reviewer can verify the arrangement rather than guess at it.

4. Practical recommendations

1. Treat software as a device directly under the definitions article: no further attribute argument is needed.
2. Compile software evidence to the Chapter 3 non-clinical standard: including lifecycle and verification documentation.
3. Distinguish software that controls a device from software that is an accessory when classifying.
4. Bring algorithm updates into change management: determine first whether prior approval is required.
5. Confirm e-labeling applicability case by case and state the arrangement in the submission.
6. Manage version numbers across registration, variation and vigilance.

5. Verification checklist

• □ Software device requirements checked against EFDA-GDL-094
• □ Software / firmware non-clinical evidence compiled per Section 3.4.5
• □ Software classification determination completed and cited in the declaration of conformity
• □ Change-impact determination process for algorithm updates established
• □ Conditions and presentation method for electronic labeling confirmed
• □ Version control covers registration, variation and vigilance

Regulatory information verified as of October 29, 2026. The software device guideline, dossier entries and variation basis described in this article follow EFDA-GDL-094, EFDA/GDL/097 and Article 21(1) of Proclamation No. 1112/2019; when the guidance is updated, the content must be re-verified.

• Ethiopia local resource: GRZAN supports manufacturers from the Chinese mainland and overseas in working with the Ethiopian Food and Drug Authority (EFDA) on marketing authorization (MA) applications, the institutional competency certificate (CoC) and import permit applications, including local agent scheme design and agency agreement review, SRA reliance route justification, UMDN coding and classification determination, technical dossier preparation, and vigilance and post-market surveillance system setup.
• Service capabilities: product attribute determination and risk classification (non-IVD Class I–IV / IVD Class A–D), marketing authorization applications and re-registration, low-risk notification eligibility determination, Essential Principles conformity justification, English-language labeling and instructions-for-use localization, vigilance reporting and field safety corrective action support.
• Contact: hito.lin@grzan.cn; website www.grzan.cn. For EFDA registration pathway and classification strategy support for the Ethiopian market, write to info@grzanglobal.com.