Continuous Learning AI Medical Devices: TMDA Submission Requirements
Updated: 2026-11-12 · GRZAN Regulatory Team · Verification date 2026-10-20
1. Key takeaways
Part X §3.2 of the Compendium of Guidelines sets separate submission requirements for AI-MDs with continuous learning capabilities. The official problem definition is direct:
AI-MD with continuous learning capabilities has the ability to change its behaviour post deployment. The learning process should be defined by the manufacturer and appropriate process controls should be put in place to effectively control and manage the learning process.
In other words: because it changes by itself after deployment, the manufacturer must define the learning process and put process controls in place.
For continuously learning AI-MDs, in addition to the requirements of Table 7, the following 7 items must be submitted (officially labelled as a non-exhaustive list):
- A description of the continuous learning process of the AI-MD during deployment;
- Safety mechanisms (which may be built into the system) to detect anomalies and inconsistencies in the output and how they are mitigated — including processes to detect and roll back to a previous algorithm version, and the criteria against which the system is measured (baseline);
- Where the AI-MD will learn from real-world data during deployment: the sources, data types, data pre-processing steps and extracted parameters of the collected data must be defined to ensure the process is unbiased; inclusion and exclusion criteria must be listed and should be identical to the attributes of the original training dataset;
- Processes to ensure the data integrity, reliability and validity of new datasets used for learning;
- Software version control — because the system may be updated frequently, and each deployment site may need to roll back to a previous version;
- Traceability procedures — spanning the real-world training data, the learning process, the software version number and the AI-MD output during clinical use; if biased real-world data produces inaccurate results during deployment, the manufacturer must be able to trace back to the specific data, remove it from the AI model, and retrain the model where necessary;
- Verification strategy and validation activities to ensure that the performance of the continuous learning remains within predefined boundaries/envelopes.
After item 5 above, the official text adds a further requirement for decentralized deployment: where an AI-MD is deployed in a decentralized setting, robust processes must be in place to address the risks of that model; other process controls to consider include maintaining traceability, performance monitoring and change management.
2. Legal basis
| Instrument | Reference / number | Publication date | Provisions |
|---|---|---|---|
| Compendium of Guidelines for Marketing Authorization of Medical Devices, Diagnostics and Laboratory Equipment | No Government Gazette number (TMDA guideline document) | June 2024 | Part X §3.2 (Additional Considerations for AI-MD with Continuous Learning Capabilities), Table 7 |
| Guidelines on Submission of Application for Change(s) to Approved Medical Devices and In-Vitro Diagnostics | TMDA/DMD/MDA/G/003 | June 2022 | §5.6, Appendix 6 (Decision Tree E: Changes to Software); §3.1, §3.2, §3.3 |
3. Expert insights
Insight 1: Roll-back is written by the authority as a mandatory item, with a baseline standard required.
The wording of the second requirement in Part X §3.2 refers to safety mechanisms that can include a process to detect and roll back to the previous algorithm version, which includes criteria by which the system is measured against (baseline). This means the manufacturer must pre-define: when roll-back occurs (trigger conditions), which version it rolls back to (version management), and what baseline is used to measure the system. All three elements are required — none can stand alone.
Insight 2: The requirement that training data inclusion and exclusion criteria be identical to the original training dataset attributes is a hard, auditable metric.
The official text reads that the inclusion and exclusion criteria should be listed and this should be identical to the attributes of the original training dataset. The word is identical, not similar. At review, this is a criterion that can be compared item by item, and discrepancies between the declared criteria and the original dataset attributes are straightforward findings.
Insight 3: The traceability chain is stretched by the authority down to the data level.
The traceability required by item 7 is not at the version level but at the data level: real-world training data, the learning process, the software version number and the clinical output must be connected end to end; and where inaccurate results arise during deployment from data bias, it must be possible to locate the specific data, remove it, and retrain where necessary. This places substantive demands on the data governance system, far beyond conventional document control.
Insight 4: Decentralized deployment requires separately documented risk control.
Where an AI-MD is deployed in a decentralized environment (for example, local deployments across multiple hospitals), the authority requires robust processes in place to address the risks involved in such a decentralized model, and lists controls for consideration: maintaining traceability, performance monitoring, and change management. This produces a submission structure different from that of centralized SaaS deployment, and it should be planned as its own chapter rather than an afterthought.
Insight 5: The interface between continuous learning and change management sits at Decision Tree E.
§5.6 and Appendix 6 of TMDA/DMD/MDA/G/003 provide the decision tree for software changes. Part X also states that a Change Notification will be required for changes to registered AI-MDs, covering performance specifications, input data types, device workflow, extent of human intervention, and AI model selection, among others. Iterations of a continuously learning model therefore fall on the dividing line between iterations within predefined boundaries (handled by process controls) and changes beyond those boundaries (handled by change notification).
4. Practical recommendations
- Write the predefined boundaries/envelopes as a quantified set of performance metrics — this is the dividing line between iteration within process controls and a reportable change.
- Document three elements of the roll-back mechanism: trigger conditions, target version, and baseline standard.
- Align the training data inclusion/exclusion criteria with the original training dataset attributes item by item, with a comparison table.
- Ensure the data governance system supports locating and removing specific samples — an explicitly stated capability requirement.
- Write a separate risk control chapter for decentralized deployment, covering traceability, performance monitoring and change management.
- Maintain an iteration log: anything exceeding the predefined boundaries goes through Decision Tree E as a change notification.
5. Verification checklist
- □ Description of the continuous learning process submitted.
- □ Roll-back mechanism submitted: trigger conditions + target version + baseline standard.
- □ Sources, types, pre-processing and parameter extraction of real-world data defined, with inclusion/exclusion criteria identical to the original training dataset attributes.
- □ Processes for data integrity/reliability/validity of new datasets submitted.
- □ Software version control established supporting frequent updates and roll-back.
- □ Risk control separately documented for decentralized deployment (traceability/performance monitoring/change management).
- □ Verification strategy submitted, ensuring performance remains within predefined boundaries.
- □ Iteration log established and linked to the Decision Tree E change triggers.
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 §3.2 and Table 7; TMDA/DMD/MDA/G/003 §5.6 and Appendix 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.
Disclaimer
Prepared by GRZAN from publicly available regulation. It is provided for general information only and does not constitute legal advice. Legislation and official fees are subject to change by the competent authority.
About GRZAN
GRZAN (Global Regulatory Zone Access Navigator) — the global market-access navigator for medical devices and IVDs.
GRZAN is a specialist consultancy for medical device and IVD market access, providing end-to-end regulatory solutions across the product lifecycle and making international market entry simpler and faster.
Key figures. More than 25 wholly owned subsidiaries worldwide covering 50+ countries and regions; chosen by 100+ listed and leading Chinese device manufacturers, with 4,000+ successful cases; 12+ years in the sector and 200+ regulatory training sessions and seminars delivered.
What we do. Global market access: multi-country registration programmes, technical documentation, regulatory advice. Clinical evidence: clinical evaluation reports (CER), usability studies, overseas clinical investigations. Quality systems: ISO 13485, MDSAP, FDA QMSR and BGMP implementation and audit readiness. Authorised representative and licence-holder services across Southeast Asia, Latin America, the Middle East, Africa, Europe and North America.
Why GRZAN. A real operating entity, with the certificate held by the manufacturer: our direct overseas subsidiaries act as the compliant local holder, so the regulatory relationship stays clear and you keep control rather than being tied to a distributor. Direct access to the team: no time-zone gap, no language barrier, no cultural gap. Review points anticipated: we know what FDA 510(k), EU MDR, Southeast Asian, Latin American and Middle Eastern reviewers look for, which shortens timelines and reduces deficiency letters. Pathway planning: pre-decision analysis and risk assessment before you commit.
Every engagement rests on three commitments: efficiency through pre-submission review, certainty through a clear pathway, and stability through a licence-holder that stays in place.
Take your devices global with GRZAN
We work with manufacturers worldwide to open new markets with a clear regulatory pathway.
Contact us