SaMD and AI Software Registration in Thailand

1. Key takeaways

Software with a medical intended use, known as SaMD, is regulated as a device in Thailand and is classified according to its intended use. This differs from the treatment in Vietnam, where Decree 98, at Article 3.8, excludes software used for medical devices from the classification and circulation number procedures, and the Vietnamese rules must not be applied to Thailand. The risk level of the software is an explicit classification consideration among the Thai classification factors, and the determination rests on the intended use and the consequences that software failure could cause, not on the technical form of the software, so the same technical architecture may fall into different classes depending on what it is used for. For Class 3 and Class 4 SaMD, the clinical evidence expectations approach the level of the EU MDR and the US FDA, and AI-based continually learning algorithms carry two additional obligations: a locked version at submission and a post-market update strategy.

• SaMD with a medical intended use is regulated as a device and classified by intended use, in contrast to the Vietnamese treatment under Decree 98 Article 3.8.
• The software risk level is an explicit classification consideration; the basis is the intended use and the consequences of software failure, not the technical form.
• Class 3 and Class 4 SaMD face clinical evidence requirements approaching the EU MDR and the US FDA.
• AI-based continually learning algorithms require a locked version, meaning a definite algorithm version fixed at submission, and a post-market update strategy explaining how later version updates are handled, whether through a variation or a new submission.
• For software and apps, B.E. 2568 (2025) requires the label and instructions to be presented in electronic form and to include the version number and the UDI where applicable, plus the general mandatory information: product name, detailed description, use, contraindications, directions for use, contact details, storage method, warnings and precautions, and the document version or latest revision date.
• Software that works with a main device towards a shared medical purpose may be filed as part of a System grouping, with the label, user manual and product catalogue marked as used as a system; standalone SaMD is filed separately.

2. Legal basis

The classification foundation is the MoPH classification notification B.E. 2562 (2019), which lists the software risk level of SaMD as a classification consideration. The Thai FDA interpretation on clinical evidence for Class 3 and Class 4 SaMD sets expectations approaching the EU MDR and the US FDA, and the requirements for AI-based continually learning algorithms comprise the locked version requirement, fixing a definite algorithm version at submission, and the post-market update strategy, explaining whether later updates go through a variation or a new submission. The MoPH labelling notification B.E. 2568 (2025) singles out software and apps: the label and instructions must be presented in electronic form and include the version number and the UDI where applicable, together with the other general mandatory information. The Thai FDA grouping guidance governs the marking requirements for a System grouping, under which the label, user manual and product catalogue must state that the components are used as a system. IEC 62304, the software lifecycle standard, applies to the development side of the dossier.

3. Expert insights

What stalls software devices in Thailand is rarely the technical review; it is version management. The core problem that continual learning creates is the consistency between the registered version and the version in the market: if the algorithm keeps learning and its behaviour changes, the product on the market no longer matches the registered dossier, which is a compliance risk in its own right. The cure is decided at submission time, not afterwards: state clearly which updates count as planned changes inside the approved change control scope, and which require a new submission. The professional instrument for this is a version baseline file built before submission, recording the locked submission version number, the algorithm training data and performance boundaries, and the update classification rules that say which kind of update goes through a variation and which kind goes through a new submission. That file must be updated at every subsequent version iteration, because it is the only evidence a software manufacturer can produce to show that the version in the market and the version in the registration remain identical. Teams that skip the baseline file find that every update becomes a negotiation with their own records, and that inspections ask exactly the question the file would have answered.

4. Practical recommendations

• Classify the software by intended use and the consequences of software failure, using the Thai classification considerations in which the software risk level is an explicit dimension, and do not import the Vietnamese treatment under Decree 98 Article 3.8.
• For Class 3/4 SaMD, prepare the clinical evidence to the level approaching the EU MDR and the US FDA before submission.
• For AI-based continually learning algorithms, fix the locked version at submission and write the post-market update strategy stating which updates go through a variation and which require a new submission.
• Prepare the electronic-form label and instructions required by B.E. 2568 (2025) for software and apps, including the version number and the UDI where applicable, plus the general mandatory information.
• Where the software works with a main device towards a shared medical purpose, file it within a System grouping and ensure the label, user manual and product catalogue state that it is used as a system; file standalone SaMD separately.
• Build and maintain a version baseline file: the locked submission version number, the algorithm training data and performance boundaries, and the update classification rules, updated at every version iteration.

5. Verification checklist

• □ Verification basis date: 26 October 2026.
• □ MoPH classification notification B.E. 2562 (2019), the software risk level as a classification consideration.
• □ Thai FDA interpretation on clinical evidence requirements for Class 3/4 SaMD.
• □ Locked version and post-market update strategy requirements for AI continually learning algorithms.
• □ MoPH labelling notification B.E. 2568 (2025), electronic-form label and instructions for software and apps, version number and UDI requirements.
• □ Thai FDA grouping guidance, the marking requirements for a System grouping.
• □ IEC 62304, the software lifecycle standard.

How GRZAN can help. GRZAN provides medical device and IVD registration, quality system, authorised representative and local testing support across Southeast Asia, including Thailand. Our team prepares dossiers to ASEAN CSDT structure, manages submissions and deficiency responses with the Thai FDA, and supports post-market vigilance obligations. Business enquiries: info@grzanglobal.com