Registering SaMD and AI-Based Software as a Medical Device in Malaysia

1. Key takeaways

Software can be a medical device in Malaysia, and the definition is deliberately broad. Section 2 of Act 737 makes clear that software may constitute a medical device. Software with a medical output — diagnosis, monitoring, or support for treatment decisions — is classified under the rules in the First Schedule to MDR 2012. The classification exercise is not a formality of labelling: it requires the medical output and the consequences of an erroneous result to be recorded, rather than assuming a low-risk treatment.

That last point is where most software submissions begin to drift. A product described as an aid or a support tool is still making a claim, and the claim determines the class. Once the output and its failure consequences are written down, the classification usually follows, and so does the evidence package. Starting from a preferred class and working backwards tends to produce a file that argues with itself.

• Legal status: software may be a medical device under section 2 of Act 737.
• Classification: First Schedule rules, applied to intended use, diagnostic or therapeutic nature, and the impact of an erroneous output.
• Documentation duty: record the medical output and the consequences of an erroneous result.
• Unclear boundaries: prepare evidence at the conservative tier, following the same logic as hardware classification.
• Core evidence: IEC 62304 lifecycle records, ISO 14971 risk management including algorithm failure modes, cybersecurity, and V&V reports.
• AI additions: training data representativeness, performance including subgroup results, and an update control strategy.

2. Legal basis

The framework reaches software through the device definition rather than through a separate software regulation. Section 2 of Act 737 establishes that software may be a device, and the First Schedule to MDR 2012 supplies the classification rules. For products already approved elsewhere, Circular Letter MDA No. 1/2025 governs the verification pathway. The standards below are the industry method standards applied to the evidence.

One qualification applies to the verification pathway. Where the software category differs between Malaysia and the source country, the Malaysian classification prevails, and the classification has to be argued before the pathway can be relied on. An approval from a recognised country does not carry its own classification with it; it supplies evidence, while the Malaysian rules supply the category.

3. Expert insights

Insight 1: the output defines the device. Software that displays a measurement, flags a trend, or recommends a course of action is making a medical claim, and the severity of the consequence if that output is wrong is the central classification input. Describing the product in terms of its user interface rather than its clinical function obscures exactly the information the classification depends on. The discipline is to state the output in clinical terms and then state what happens when it is wrong.

Insight 2: IEC 62304 and ISO 14971 answer different questions. The lifecycle standard demonstrates that the software was developed under control, with requirements, architecture, unit verification and integration testing traceable through the process. The risk standard demonstrates that the hazards arising from the software, including algorithm failure, were identified and controlled. A file that offers one without the other reads as half a submission, and reviewers tend to test the gap by asking for the missing half.

Insight 3: AI evidence is judged on representativeness, not on accuracy alone. Aggregate performance figures are the least informative part of an AI submission. What matters is whether the training data represent the population in which the device will be used, and whether performance holds across the subgroups within that population. Those two questions determine whether a headline figure means anything. An update control strategy completes the picture by stating how the model will be changed after approval.

Insight 4: change control is the most valuable decision made before submission. Whether an algorithm or model update goes through a CN or triggers a fresh registration determines how freely the product can iterate once it is on the market. That choice is made in the submission, not afterwards, because the registered description and the risk file set the boundaries within which later changes are assessed. Getting it wrong produces a compliant product that cannot be improved without re-registering.

4. Practical recommendations

• Write the output and its failure consequences first. Classification follows from that statement, not from a preferred position.
• Choose a CAB with software experience. A hardware-only review team tends to raise excessive requests on software documentation; ask directly about IEC 62304 and ISO 14971 review experience and comparable cases.
• Prepare at the conservative tier where the boundary is unclear. This mirrors the approach taken to hardware classification.
• Document the cybersecurity position. Treat it as part of the evidence set rather than as a later addition.
• Argue the Malaysian classification before invoking the pathway. A foreign approval does not settle the category.
• State the update strategy in the submission. Decide in advance which changes will follow the CN route and which will trigger re-registration.

The unifying point is that software rewards precision about claims. Every one of the difficulties above — classification, evidence sufficiency, pathway eligibility, post-market freedom — traces back to a statement of what the product does and for whom, written specifically enough to be tested.

5. Verification checklist

• □ Medical output described in clinical terms, with the consequence of an erroneous result recorded
• □ Classification argued under the First Schedule, at the conservative tier where the boundary is unclear
• □ IEC 62304 lifecycle documentation complete and traceable
• □ ISO 14971 risk management covering software and algorithm failure modes
• □ Cybersecurity addressed within the evidence set, with V&V reports
• □ AI products supported by training data representativeness, subgroup performance and an update control strategy
• □ Change control route for algorithm and model updates defined before submission

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