Registering SaMD and AI Devices in Indonesia: KMK 951/2026 and Local Clinical Verification

1. Key takeaways

Software is a medical device in Indonesia, and since September 2026 it has had its own rulebook. UU 17/2023 expressly wrote software (perangkat lunak) into the definition of a medical device. Before that, standalone medical software could only be assessed by stretching the four-class hardware rules, without a dedicated pathway. The gap closed with KMK No. HK.01.07/MENKES/951/2026 — a Ministerial Decree dated 7 September 2026, titled the Guidelines for Marketing Authorisation of Software-Based Medical Devices — the first Kemenkes document dedicated to software-based devices, setting out the classification logic, technical standards and evidence requirements for SaMD, SiMD (software in a medical device) and AI-enabled devices (AIMD/MLMD).

Its hardest provision is the local clinical verification obligation. From 7 September 2026, imported AI products used for diagnosis, screening or clinical decisions must undergo local clinical verification in Indonesia, with results submitted within 1 year after the marketing authorisation is issued. For AI imaging, AI-assisted diagnosis and clinical decision support products, this single clause shapes the whole market-entry calendar.

• Legal status of software: a medical device under UU 17/2023, which names software (perangkat lunak) in the device definition.
• Governing instrument: KMK No. HK.01.07/MENKES/951/2026 of 7 September 2026, covering SaMD, SiMD and AI-enabled devices (AIMD/MLMD).
• Hardest rule: imported AI products for diagnosis, screening or clinical decisions require local clinical verification, results due within 1 year after licensing.
• Classification is not automatic: Kemenkes decides SaMD registration and classification case by case.
• Core evidence set: software verification report, algorithm documentation, IEC 62304 lifecycle evidence, cybersecurity documentation, and clinical evidence or local verification results as applicable.

2. Legal basis

Four instruments carry the framework. KMK No. HK.01.07/MENKES/951/2026 (7 September 2026) is the dedicated software decree. UU No. 17/2023 supplies the device definition that includes software. PP No. 28/2024, the implementing regulation, positions AI and robotic devices within the national health information system. IEC 62304 supplies the software lifecycle standard that the evidence expectations build on. The references below were verified on 26 October 2026.

The practice layer matters as much as the written layer. Industry feedback indicates that even with the written guidance in hand, registration and classification decisions for specific SaMD products remain primarily a Kemenkes case-by-case review, rather than the automatic self-declaration flow available in Regalkes for most hardware. Developers need to bring the product itself, the intended use statement and the algorithm documentation in front of the reviewing authority to obtain a binding classification conclusion — the decree gives the framework, but the dialogue gives the answer.

3. Expert insights

Insight 1: the 1-year local verification deadline is a clock that starts at licensing, so it must be planned before licensing. The requirement that imported AI products for diagnosis, screening or clinical decisions submit local verification results within 1 year after the marketing authorisation issues means the verification programme and the registration programme overlap by design. A team that begins selecting a verification institution and confirming the protocol in the very month of licensing is already late relative to the deadline; a team that starts at project initiation treats the year as what it is — the delivery window for a clinical programme that cannot be compressed.

Insight 2: classification for software is a conversation, not a lookup. For most hardware, the class follows from the rules and self-declaration runs automatically in Regalkes. For SaMD, the industry experience is that Kemenkes decides case by case. That changes the preparation: the developer must arrive with the product, the intended use statement and the algorithm documentation ready to be examined, because the classification conclusion — and with it the evidence obligations — emerges from that examination rather than from a table lookup.

Insight 3: the software evidence set is additive to the CSDT, not a replacement for it. Beyond the standard CSDT sections, software products should prepare a software verification report (from the manufacturer or an independent laboratory), algorithm documentation, IEC 62304 software lifecycle evidence, cybersecurity documentation where the product is networked or data-driven, and clinical evidence or local verification results depending on classification and use. The additive structure is helpful for planning: the classic dossier workstream continues, and the software modules are built alongside it under IEC 62304 discipline.

4. Practical recommendations

• Plan backwards from the hard constraint: local verification results must be delivered within 1 year after the licence is issued.
• Start verification institution selection and protocol confirmation in the month of licensing — or earlier — to avoid a schedule conflict between the certificate and the verification results.
• Engage Kemenkes early on classification. Bring the product, the intended use statement and the algorithm documentation forward for a case-by-case conclusion rather than assuming a self-declaration route.
• Build the software evidence module set deliberately: verification report, algorithm documentation, IEC 62304 lifecycle evidence, cybersecurity documentation where networked or data-driven.
• Treat cybersecurity documentation as mandatory scope for any networked or data-driven product, not as an optional annex.
• Match clinical evidence to classification and use, and for imported diagnostic, screening or clinical-decision AI, assume local verification applies.
• Track the PP No. 28/2024 positioning of AI devices where the product will connect to the national health information system.

The failure mode this guidance exists to prevent is the certificate-and-verification collision: a licence granted, a year running, and no verification programme with institutional capacity reserved. Reversing the plan from the deadline — institution chosen, protocol agreed and slot booked before or at licensing — converts the hardest rule in the software regime into a scheduled deliverable.

5. Verification checklist

• □ Product assessed as a medical device under UU No. 17/2023, software included in the definition
• □ Classification route examined against KMK No. HK.01.07/MENKES/951/2026 (7 September 2026)
• □ Case-by-case classification dialogue prepared: product, intended use statement, algorithm documentation
• □ Software verification report arranged from the manufacturer or an independent laboratory
• □ IEC 62304 software lifecycle evidence compiled
• □ Cybersecurity documentation prepared for networked or data-driven products
• □ Imported AI products: local clinical verification scheduled, results deliverable within 1 year after licensing
• □ PP No. 28/2024 implications assessed for national health information system integration

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