Kenya's Pharmacy and Poisons Board has issued its Guideline on Regulation of Medical Device Software in Kenya (MDSW), document HPT/PER/GUD/099, Revision 0, dated February 2026 and published on the Board's guidelines portal in April 2026 (PPB download page; PPB announcement). The guideline covers Software as a Medical Device (SaMD, software that is itself the device), Software in a Medical Device (SiMD, software embedded in hardware), and AI-enabled medical devices, and it applies irrespective of technology or platform: a mobile app or a cloud service that performs a medical function is inside the perimeter. The guideline states no separate commencement date on its face.
The classification does the work. The guideline adopts the International Medical Device Regulators Forum's four-category matrix, crossing the state of the healthcare condition (critical, serious, non-serious) against the significance of what the software does (treat or diagnose, drive clinical management, inform clinical management). Software that treats or diagnoses a critical condition is Category IV; a wellness or lifestyle app that merely informs sits in Category I, where general good software development practice and a quality management system may suffice. Each step up the matrix adds documentation: validation and verification evidence, risk management files, clinical evidence, post-market surveillance. Annex I lists examples of software that does not meet the threshold for regulation at all, so the first legal question for any Kenyan health app is now a classification question.
Registration is real, not rhetorical. Applications go through the Board's Medical Devices Software portal, supported by conformity checklists against the IMDRF essential principles of safety and performance, and the registrant-authorisation machinery of the Health Act 2017 applies. Manufacturers abroad appoint a local registrant to submit on their behalf, the same structure Kenyan pharma and device importers already know.
Data protection is written into the device rulebook. The guideline directs that developers, implementers and users of medical device software comply with the Data Protection Act No. 24 of 2019 and the Digital Health Act No. 15 of 2023 by name, and it treats cybersecurity as a device-safety property, with security requirements running through the registration documentation. For compliance teams this is the notable structural move: patient-data handling is no longer only the ODPC's question. A health app with weak data practices can now fail device registration on grounds the data-protection regulator never gets to.
AI gets its own lane. The guideline adopts the ten guiding principles of Good Machine Learning Practice for AI and machine-learning devices, including expectations around iterative model modification and learning from real-world data, and flags algorithmic bias as an ethical concern that documentation must address. Kenya's approach tracks the IMDRF line rather than inventing a domestic AI test, which matters for vendors already documented for other IMDRF-aligned markets.
Why it matters. Kenya's health-tech sector is mobile-first: telemedicine platforms, symptom checkers, diagnostic decision support, chronic-disease management apps. Much of that stack has operated with no device-law analysis at all. The matrix pulls exactly the ambitious end of the market, diagnosis and treatment functionality, into the highest-scrutiny categories, and AI vendors face the most documentation. Two regulators now share the perimeter: the ODPC for personal-data compliance under the DPA 2019, the PPB for the software's safety, performance and security as a device. Market entry that used to be one legal workstream is now two.
Who is affected. Developers of health apps and clinical software with Kenyan users; hospitals and clinics deploying or commissioning such software; AI diagnostics vendors, local and foreign; foreign SaMD manufacturers, who need a Kenyan registrant; and investors doing diligence on Kenyan health-tech, for whom an unclassified product is now an unquantified liability.
What to do now:
- Classify every product against the four-category matrix before anything else, and check Annex I before assuming a wellness app is exempt. The classification determines the whole documentation burden.
- Map the product's data flows against the DPA 2019 and the Digital Health Act 2023 as part of the device file, not as a separate exercise; the guideline joins the two regimes.
- If the product uses AI or machine learning, build the Good Machine Learning Practice documentation now, including how model updates will be controlled and re-evaluated after registration, which the guideline addresses through its change and re-evaluation provisions.