Software as a medical device · Southeast Asia

Software as a Medical Device (SaMD) Registration in Five ASEAN Markets

Whether cloud-based image analysis software is a medical device depends on the medical task it promises to perform, not on hardware, AI or a subscription model. The five markets differ on SaMD qualification, risk classification, market-entry route and update obligations, and Indonesia issued a dedicated software and AI device guideline in 2026. MediPass clarifies status and class market by market, organises validation evidence, and files and holds the registration through our own companies in all five countries.

Singapore HSA · Malaysia MDA · Thai FDA · Vietnam MoH · Indonesia MoH

Assess my software product See what we do →

Settle the software boundary before class and evidence

SaMD means standalone software that achieves a medical purpose on its own. Software that controls a ventilator or drives a scanner is embedded software or part of a device and is not filed as SaMD just because it can run on a PC; software that only stores or transmits health data without analysis is not a medical device in several markets; software that processes results from human specimens has to be assessed as possible IVD software. Singapore keeps its non-IVD SaMD classification table separate from the IVD rules, and Vietnam’s consolidated decree carves out “software used for medical devices” in Article 3(8).

MediPass fixes the product boundary with one architecture diagram and one intended-use statement: disease or physiological state, population, user, input data, output and how the output influences care. We then determine status and class for each market and organise three kinds of evidence separately: software verification, clinical association and clinical validation. For AI products we also map training, validation and deployed versions and plan for continuous learning and model updates.

Book a SaMD assessment

What we do for SaMD

From qualification to local licence holding, MediPass delivers the full SaMD registration through its own entities in five markets. A typical software project runs through four steps.

Step 01Status & class

Decide whether the software is a medical device and determine the class per market

We test the intended use against each market’s medical device definition, distinguish SaMD, embedded software, software accessories and non-medical software, and check whether the product is IVD software. We then determine the class: Singapore’s GL-07 R2 table (significance of the output to the care decision combined with the state of the condition), Malaysia’s MDA/GD/0009 active-device rules, the Thai FDA SaMD classification table (Rules 9, 10 and 12) and the Vietnamese and Indonesian provisions.

At the end of this step you have, for each of the five markets, whether the software is regulated as a medical device, its class, and the clauses each conclusion relies on.

Step 02Evidence & gaps

Organise software verification, clinical association and clinical validation

The three kinds of evidence answer different questions: does the implementation meet its specification, why is the output related to the target condition, and is it clinically meaningful in the target population and setting. We map your documentation to HSA GL-04 R4 life-cycle requirements, the Thai Class 2–3 dossier list (CSDT, verification and validation, risk analysis, quality system) and Indonesia’s 951/2026 guideline, and mark the gaps. Cybersecurity (for example HSA GL-10 R1 best practice) and third-party component inventories are reviewed at the same time.

Before quoting, we confirm whether the software can be filed in each target market; once the project starts we review the documentation item by item and deliver an evidence gap list, including data representativeness, known limitations and human-review points for AI products.

Step 03Deployment & updates

Plan cloud deployment, the local entity and the update pathway

An offshore server is not an exemption. Table 5 in section 4 of Singapore’s GL-04 sets out the local entity’s wholesaler’s licence and quality-system requirements for cloud software, and Class B, C and D software still needs product registration. Indonesia’s 951/2026 requires eligible imported software (retrained on Indonesian population data, or medium-to-high-risk AI) to submit local clinical validation results within one year of authorisation, and sorts updates into new authorisation, variation or information filing.

We define a version-freeze and change strategy for each market so that model iterations are built into the market-entry plan rather than handled reactively after launch.

Step 04Filing & holding

Filed and held by MediPass’s own companies in five markets

MediPass has its own licensed company in Singapore, Malaysia, Thailand, Vietnam and Indonesia. Each can act as applicant, authorised representative or local registration holder: submitting, answering regulator queries, maintaining the certificate and carrying post-market obligations. The registration stays independent of distributors and hospital deployment contracts.

See the local entities and credentials in five markets.

Change of registrant and licence-holding services

SaMD regulatory requirements in five markets

All five markets treat standalone software that meets the medical device definition as an active medical device, but the classification basis, the maturity of dedicated guidance and update requirements differ markedly. The table compares frameworks; a specific product’s class still has to be argued rule by rule.

MarketSaMD classification basisDedicated guidanceUpdate and validation points
SingaporeGL-07 R2 SaMD/CDSS classification (effective July 2025) + GN-13 rulesGL-04 R4 software life cycle (Dec 2025) · GL-10 R1 cybersecurity (Aug 2026)Cloud software per GL-04 Table 5; changes per GN-21 R7; dedicated data for machine-learning functions
MalaysiaMDA/GD/0009 active-device rules; standalone software classified by its own intended useMDA/GD/0063 borderline products, MDA/GD/0062 classification examplesChanges currently under MDA/GD/0020; MDA/GD/0072 takes effect with MedCAST 3.0
ThailandThai FDA SaMD classification table (Rules 9, 10, 12) → Class 1–4Thai FDA SaMD pages: screening, classification, registration, changesClass 2–3 dossiers require CSDT, verification and validation, risk analysis and QMS evidence
VietnamDecree 98/2021 consolidated text: software within the definition, but Art. 3(8) carves out “software used for medical devices”No standalone SaMD guidance identifiedObtain a clear route decision on standalone medical function, hardware relationship and supply model
IndonesiaPermenkes 5/2026 Class A–D + Kepmenkes 951/2026 SaMD/SiMD/AI guideline (effective 7 Sep 2026)Kepmenkes HK.01.07/MENKES/951/2026Eligible imported software must submit local clinical validation within one year of authorisation; updates sorted into three categories

Singapore

HSA · GL-07 R2Risk classification of SaMD and clinical decision support software

GL-07 R2 took effect on 21 July 2025 and combines the significance of the output to the care decision, the state of the patient’s condition and the GN-13 rules. Some software that drives clinical management moves to Class B by footnote when it analyses physiological processes or anatomical images, so international risk categories cannot be copied straight into Singapore classes.

View SaMD notesHide notes

GL-04 R4 (December 2025) sets software life-cycle requirements; section 9 asks for dedicated information on machine-learning functions, including continuous learning and post-market monitoring, and Table 5 in section 4 sets the local entity’s wholesaler’s licence and QMS requirements for cloud software. GL-10 R1 (August 2026) is the cybersecurity best-practice guide. Routes follow GN-15 R15 and changes GN-21 R7.

MediPass Pte. Ltd. holds HSA importer’s and wholesaler’s licences and can act as the Singapore registrant and the local entity for cloud software.

Malaysia

MDA · MDA/GD/0009Standalone software classified as an active device by its own use

MDA/GD/0009 2nd edition classifies standalone software as an active device by its intended use, with separate principles for software that drives or influences a device. Diagnosis, diagnosis in critical situations and vital-sign monitoring must each be checked against the active-device rules; “all SaMD is Class B” is not a valid shortcut.

View SaMD notesHide notes

The MDA/GD/0063 borderline document lists health-data storage and transmission software without processing as an example of a non-device, which cannot be stretched into “all health apps are exempt”. Post-registration changes still follow MDA/GD/0020; MDA/GD/0072 takes effect only when MedCAST 3.0 launches. Applications are filed by a Malaysian authorised representative.

Medipass Sdn. Bhd. holds MDA establishment licences as authorised representative, importer and distributor and can act as your Malaysian AR.

Thailand

Thai FDA · Class 1–4SaMD pages: screening, classification, registration and changes

Thai FDA qualifies software under the “medical purpose” concept in Section 4 of the Medical Device Act, distinguishing standalone software, embedded software, software accessories and non-medical software; its classification table applies Rules 9, 10 and 12.

View SaMD notesHide notes

Diagnosis in critical situations, treatment planning, screening or monitoring of acutely dangerous vital parameters sit at a different level from clinical-information functions in non-critical situations. The registration page separates Class 1 from Class 2–3 dossiers, the latter listing CSDT, verification and validation, risk analysis and QMS evidence. Use this official framework rather than draft guidance circulating online.

MediPass Healthcare Solutions (Thailand) Co., Ltd. files and holds Thai SaMD registrations.

Vietnam

MoH · Decree 98/2021 consolidatedSoftware within the definition, with an Article 3(8) carve-out

Article 2 of the consolidated text brings qualifying software within the medical device definition, while Article 3(8)(a) excludes “software used for medical devices” from the classification, circulation-number and trading-eligibility rules. This neither exempts every medical app nor means all SaMD simply follows ordinary registration.

View SaMD notesHide notes

Our check did not identify standalone SaMD guidance in Vietnam. We recommend obtaining a clear route decision before filing, based on the software’s standalone medical function, its relationship to hardware and the supply model; products combined with hardware are judged on the highest risk of the final intended use.

Công ty TNHH Medipass Việt Nam has completed the Class B, C and D trading declaration and can act as applicant and registration holder in Vietnam.

Indonesia

MoH · Kepmenkes 951/2026Guideline on marketing authorisation for software-based medical devices (effective 7 Sep 2026)

Covers SaMD, SiMD and AI medical devices. Imported software that is retrained on data representing the Indonesian population, or that is medium-to-high-risk AI (diagnosis, screening, clinical decisions), must undergo local clinical validation, with results submitted no later than one year after the izin edar is issued.

View SaMD notesHide notes

Updates fall into three categories: changes affecting indication, principal function or clinical performance require a new authorisation; changes that do not affect safety, benefit or quality are filed as variations; other changes are reported to the Ministry with supporting data. Continuous-learning and generative AI carry additional data requirements. All of this sits within the Permenkes 5/2026 A–D classes and izin edar framework.

PT Medipass Indonesia Sejahtera holds IDAK and CDAKB certification and can act as your registration holder in Indonesia.

Plan a five-market SaMD assessment

Tell us the intended use, architecture, target markets and existing approvals. MediPass first confirms whether the software can be filed in each market, then provides a registration roadmap and an itemised quotation.

Request an assessment and quote

Frequently asked questions

The physician keeps the final decision. Does that mean our software is not a medical device?

Not by itself. Decision support, screening and risk stratification can still have a medical purpose. What the software processes, what the output is used for and each market’s boundary conditions must be reviewed; Singapore’s GL-07 has specific classification considerations for clinical decision support software.

We have a CE mark or another approval. Does it cover the five markets?

No. Existing approvals can support eligible routes but do not replace local qualification, registration or exemption decisions. Singapore’s GL-07 table is not a copy of the IMDRF categories either.

Our servers are offshore and users access via a browser. Do we still need local registration?

Yes. Table 5 in section 4 of Singapore’s GL-04 sets out the wholesaler’s licence and QMS requirements for the local entity giving access to cloud software, and Class B, C and D software still needs product registration. A MediPass local company can act as that entity.

Does every minor software update require re-registration?

Not necessarily. Record the change and its effect on intended use, safety and performance, then apply the local rules to decide between a new application, a variation or an information filing. Indonesia’s 951/2026 distinguishes three update categories; Malaysian changes currently follow MDA/GD/0020.

Must AI products run a local clinical trial to enter Indonesia?

Not always. Kepmenkes 951/2026 requires local clinical validation only for two kinds of imported software: software retrained on data representing the Indonesian population, and medium-to-high-risk AI (diagnosis, screening, clinical decisions). Validation may run in parallel with the application, with results due within one year of authorisation.

If MediPass holds the registration, who owns it?

The certificate is held by the MediPass local company, with ownership and control assigned to the manufacturer by agreement. You contract freely with hospitals and distributors; MediPass does not sell products. See change of registrant and licence-holding services.

Bringing medical software to Southeast Asia?

Tell us the intended use, architecture, target markets and existing approvals. MediPass first confirms whether the software can be filed in each market, then provides a registration roadmap and an itemised quotation.

Enquire about SaMD registration

Or email contact@aseanmedipass.com.

If the software’s intended use or validation plan still needs to be clarified with HSA, see our HSA pre-market consultation preparation and coordination support.

Chat on WhatsAppWhatsApp 咨询