Software and AI Medical Devices: TMDA Registration Requirements

1. Key takeaways

Part X of the June 2024 Compendium of Guidelines, the Guidelines on Medical Devices Incorporating Software (pages 175–195), is one of the most significant additions in Tanzania in the past two years. The official scope statement reads:

This document applies to the software of all risk classifications and is intended to cover regulatory requirements spanning the entire product life cycle. Additionally, it addresses key software-related regulatory requirements such as cybersecurity and requirements for Artificial Intelligence (AI) medical devices.

The document covers four themes: 1.1.1 pre-market product registration requirements, 1.1.2 change notification, 1.1.3 cybersecurity, and 1.1.4 artificial intelligence.

Sections that must be specially prepared for a software device submission (§2.0):

• Essential Principles (the checklist of essential principles of safety and performance)
• Labelling requirements
• Software versioning and traceability
• Software verification and validation
• Clinical evidence
• Risk management
• Supporting documents for cybersecurity

These seven sections form a parallel documentation track alongside the general STED, and TMDA reviewers expect them to be identifiable as discrete chapters rather than scattered across the dossier.

2. Legal basis

3. Expert insights

Insight 1: The Essential Principles checklist applies to all devices — the official text names Class A specifically.

Part X §2.1: the essential requirements checklist describes the essential design and manufacturing requirements; requirements relevant to the specific device must be identified, and where a requirement is judged not applicable, the reason must be recorded. The text adds: this applies to all medical devices, including Class A medical devices. This sentence closes off any idea that lower-class software devices may skip the Essential Principles.

Insight 2: The submission requirements for AI devices are codified in an official table (Table 7).

Table 7 of Part X lists the additional considerations for AI-MD registration, with four core items:

1. Clinical association: the presence of a valid clinical association between the AI-MD’s output and its targeted clinical condition should be presented.
2. Deployment workflow: the anticipated or recommended workflow during deployment of the device should be presented and explained; where human-in-the-loop intervention exists in the system, the workflow must clearly indicate the extent of intervention and the stage at which it occurs.
3. Training data update cycle: the interval of the training data update cycle (for example, in months or in years) must be provided.
4. Software versioning and traceability procedures: for post-market traceability, the exact version of the AI-MD to be supplied must be provided, together with an explanation of how the version number is assigned and traced.

Insight 3: Training data updates trigger change notification — the item most easily missed.

Table 7 states expressly: if a new set of data collected changes the original specification and performance of the device, a Change Notification should be submitted to the Authority. For registered AI-MDs, a change notification is likewise required for changes to performance specifications, input data types, device workflow, extent of human intervention, and AI model selection, among others. The decision logic given in section 5 applies equally to AI-MDs.

Insight 4: The definitions align SaMD with IMDRF terminology.

Part X §1.4 defines STANDALONE SOFTWARE (also known as SaMD in IMDRF context) — software and/or mobile applications intended to run independently, not for controlling or influencing the operation of other hardware medical devices. It also defines AI, AI-MD, CYBERSECURITY, MOBILE APPLICATION, OTS/COTS SOFTWARE (off-the-shelf/commercial off-the-shelf software), PRODUCT OWNER, REGISTRANT and other terms, giving reviewers and applicants a shared vocabulary.

Insight 5: GN 315 wrote software provisions long before the guideline, and they remain in force.

Regulation 29(6): where a device is constituted by or incorporates software, the software must be designed to perform as intended by the manufacturer, and the software performance must be verified. Regulation 11(i)(iii) lists, where appropriate, software verification studies among the detailed summary of all studies. Software verification in Tanzania therefore rests on a dual structure: a statutory obligation plus guideline elaboration.

4. Practical recommendations

1. Organize software documentation into the seven sections of Part X, separately from the general STED.
2. Prepare AI devices against the four items of Table 7, especially the valid clinical association between output and clinical condition — an explicit official evidentiary requirement.
3. Write the training data update cycle into the registration dossier, and set change trigger thresholds based on it.
4. Document the software version naming rules and traceability procedures, for use in post-market tracing and change determination.
5. Use Decision Tree E at the change stage (TMDA/DMD/MDA/G/003 §5.6 and Appendix 6), not the decision trees designed for hardware changes.

5. Verification checklist

• □ Software documentation organized into the seven sections of Part X §2.0.
• □ Essential Principles checklist completed item by item, with justification recorded for non-applicable items (including Class A).
• □ For AI-MD prepared: the valid clinical association of output with clinical condition, the deployment workflow (including the extent and stage of human-in-the-loop intervention), the training data update cycle, and the version and traceability explanation.
• □ Thresholds set for training data updates triggering a change notification.
• □ Software version naming and traceability documented.
• □ Change determination uses Decision Tree E (software).
• □ The statutory software verification duty of GN 315, regulation 29(6), satisfied.

Regulatory information verified as of 29 October 2026. All provisions cited in this document were checked against the official published texts of TMDA (the June 2024 Compendium of Guidelines, Part X §1.1.1–§1.1.4, §1.4, §2.0, §2.1, Table 7; TMDA/DMD/MDA/G/003 §5.6; GN. No. 315, regulations 11(i)(iii) and 29(6)), and will be re-checked when the regulations are updated.

• Tanzania local resources: licensed Local Responsible Person (LRP) and distributor resources can be coordinated to cover online submission, sample delivery, quality audit cooperation and port clearance.
• Service capabilities: classification determination, registration and notification pathway selection, technical documentation (CSDT/STED) preparation and localization, GMDN and grouping strategy, clinical evidence organization, software and AI device submissions, change management, vigilance and PMS reporting, annual retention fees and renewal management.
• Contact: hito.lin@grzan.cn; website www.grzan.cn.