Device Identification in Kenya: GMDN Codes, Configurations and UDI

Content verified as of 30 October 2026.

1. Key takeaways

• The device identification module requires the Global Medical Device Nomenclature (GMDN) code and the device sub-category or generic device group, together with the risk class and the classification rationale.
• The classification rationale must map rule by rule to the selected rules; where multiple rules apply, the highest class is taken — the same highest-class principle Kenya shares with GHTF/IMDRF.
• A list of the configurations intended for registration must be submitted; it is one of the 12 Class B/C/D documents and the core document defining the scope of the registration.
• Grouping forms include single devices, families, systems and sets; a change of device grouping and adding devices under different proprietary names to the same family listing are among the five red lines that require a fresh CSDT submission.
• Beyond the submission level, the unique device identification (UDI) has become a supply chain reality through the national traceability system: batch-level traceability went live on 3 August 2026, transition to full serialisation follows on 1 January 2027, and the deadline for onboarding was 31 October 2026.

2. Legal basis

3. Expert insights

Insight 1: The GMDN code is not a formality but the first driver of classification. The most common error in this module is treating the GMDN code as an administrative field and picking an approximate term casually. There are three layers of consequence. First, the GMDN term determines the generic device group and thereby shapes the reviewer’s understanding of intended use. Second, if the intended use of the chosen term does not match the label proposed for registration, the same intended use comparison in the abbreviated route fails. Third, cross-checking the term against the classification examples may yield a higher class than the company self-assessed, triggering a classification dispute. The GRZAN method is to reverse-check the GMDN term against the guideline examples first, then write the classification rationale, closing the loop.

Insight 2: The configuration list is a scope boundary document; writing it wide or narrow both carry costs. The list defines what the registration certificate will cover. Written narrowly, every new model or accessory later requires a change notification or even a fresh submission; written widely, reviewers will demand supporting verification evidence for every configuration listed. Here two readings diverge: whether accessories, consumables and software versions belong in the main device list or should be submitted separately. GRZAN’s judgement: items used with the main device that affect performance go in the list with evidence; items marketed independently and usable alone are submitted separately. List items should be granular down to specification and model level, noting for each whether it is sterile and whether it is reusable.

Insight 3: The temptation of family grouping and the red lines around it. Family grouping can spread registration costs substantially, but the guidelines draw two hard red lines: a change of device grouping requires a fresh CSDT, and adding devices under different proprietary names to the same family listing — even where the family grouping conditions are met — likewise requires a fresh submission. The intent is to prevent certificate scope expanding under the family banner. Companies planning product lines often err by squeezing same-type devices of different brands into one application. GRZAN recommends fixing a family definition document before submission: devices in a family should share intended use, technical principle and one proprietary name, with differences limited to specification and size.

Insight 4: UDI is shifting from optional to essential infrastructure. The CSDT does not list UDI as a mandatory module, but the national authentication and traceability system is already in place: batch-level traceability first, with transition to full serialisation on 1 January 2027; practitioners and facilities had to onboard by 31 October 2026, with no extension and no negotiation, and those not onboarded will not be issued 2027 practice or facility licences. For device companies this means the data carriers on labels and packaging, the batch ledgers and the upstream and downstream data interfaces must all be reworked on the same timeline, or the product will stall at the onboarding stage of downstream customers.

4. Practical recommendations

1. Choose the GMDN code first, then classify. GRZAN recommends fixing the GMDN term and generic device group before writing the classification rationale, so the two never contradict each other.
2. Add an explanatory page to the configuration list. For each item state model, specification, sterility and reusability, and note where the supporting evidence sits.
3. Fix the family definition document first. Before submission, fix in writing the shared elements and difference boundaries of the family; devices with different proprietary names do not enter the same family.
4. Schedule UDI and traceability rework in parallel. Align label data carriers, batch ledgers and data interfaces to the 1 January 2027 full serialisation milestone.
5. Verify downstream onboarding status. Confirm with the LAR and distributors that they onboarded by 31 October 2026, avoiding a break in the licence chain.
6. Set an early warning for grouping changes. Any product iteration that adds a proprietary name or alters the grouping structure should first be assessed for whether it triggers a fresh submission.

5. Verification checklist

• □ Have the GMDN code and the device sub-category or generic device group been fixed and matched to the intended use?
• □ Does the classification rationale map rule by rule and explain the highest-class determination?
• □ Is the configuration list granular to specification and model level, with sterile and reusable attributes marked?
• □ Is the family definition fixed, with the family sharing one proprietary name, intended use and technical principle?
• □ Have the two fresh-submission red lines — change of device grouping and adding different proprietary names to the same family — been excluded?
• □ Are the UDI data carrier and batch ledger reworks aligned to both 3 August 2026 and 1 January 2027?
• □ Have downstream LARs and distributors onboarded by 31 October 2026?
• □ Can every item in the configuration list be traced to corresponding design verification or preclinical study evidence?

Regulatory information verified as of 30 October 2026.

In African markets, the GRZAN regulatory team focuses on jurisdictions such as Kenya, Nigeria, South Africa and Egypt and maintains a verification mechanism built on primary regulatory sources. Every regulatory conclusion it issues rests solely on official gazettes, the original text of competent authority guidelines and public legal databases, with the verification date stated; any figure, timeline or amount that cannot be located in an official source is marked as a practical estimate and is never presented as presumption.

GRZAN services cover market access strategy and risk classification; preparation and review of registration dossiers in CSDT, STED and CTD formats; selection and management of local authorized representatives (LARs); quality management system and GMP/GSDP compliance support; post-market vigilance, change management and recall response; import clearance and PVoC coordination; regulatory intelligence subscriptions and corporate compliance ledgers.

For a Kenya market access plan for a specific product, contact the GRZAN regulatory team at info@grzanglobal.com.