SaMD stands for Software as a Medical Device: software, including AI-based diagnostic tools and clinical decision support algorithms, that performs a medical function entirely on its own, without being built into a piece of hardware. It has also become one of the most confusing corners of Indonesia’s device rules. Until now, a health-tech company launching a triage algorithm, or a hospital IT team vetting a vendor’s AI tool, had no reliable way to tell whether Kemenkes would treat it as a regulated medical device at all, let alone which classification tier, technical standards, or clinical evidence it would need to clear.
KMK No. HK.01.07/MENKES/951/2026 changes that. It is the first Kemenkes guideline written specifically for software-based devices, and it finally gives a formal answer to classification, standards, and evidence questions that used to be settled case by case, if at all.
Health-tech companies building diagnostic or decision-support software, hospital IT teams evaluating AI tools before deployment, and regulatory affairs staff trying to get the classification call right, not just fast: this article is for you. Along the way, we’ll cover how Kemenkes now separates SaMD, SiMD, and AI-enabled devices (AIMD/MLMD), walk through the decision logic evaluators actually use to classify a product, lay out the technical standards and clinical evidence your filing will need, unpack the sandbox and local validation pathways built specifically for AI, and close with a step-by-step look at the registration process itself.
In our experience, the single fact most manufacturers miss is this: even though Kemenkes published a formal classification pathway for software through KMK No. HK.01.07/MENKES/951/2026 on 7 September 2026, the day-to-day registration and classification decision for a specific SaMD product is still made through direct, case-by-case review at Kemenkes rather than through an automated self-declaration in Regalkes the way most hardware devices work. In practice, a developer still needs to bring the actual product, its intended use statement, and its algorithm documentation physically in front of a Kemenkes evaluator to get a binding classification. The written guideline exists; the operational workflow around it is still being worked out case by case.
Why SaMD Registration in Indonesia Just Got Its Own Rulebook
Software has technically fallen under Indonesia’s medical device definition since Undang-Undang No. 17 Tahun 2023 tentang Kesehatan, which defines alat kesehatan to include perangkat lunak alongside instruments and implants, and its implementing regulation PP No. 28 Tahun 2024. Before September 2026, though, Kemenkes evaluated standalone medical software against the same four-tier classification used for hardware under Permenkes No. 62 Tahun 2017, without a dedicated technical pathway for how a diagnostic algorithm or an AI-enabled tool should be distinguished from a general wellness app.
KMK No. HK.01.07/MENKES/951/2026 tentang Pedoman Izin Edar Alat Kesehatan Berbasis Perangkat Lunak, issued by the Minister of Health on 7 September 2026, closes that gap. This is exactly the regulatory development the industry has been building toward since 2024, when Kemenkes and international bodies first began circulating SaMD framework proposals; the 2026 Kepmenkes is the point where that groundwork became a standing, currently effective guideline.
What Counts as SaMD, SiMD, or an AI Medical Device in Indonesia?
Under KMK No. HK.01.07/MENKES/951/2026, Kemenkes sorts software-based medical products into three categories. Software as a Medical Device (SaMD) is standalone software that runs on general-purpose hardware without being part of a specific physical device. Software in a Medical Device (SiMD) is software embedded in and controlling a physical device’s performance, so it follows that device’s own risk class rather than being classified separately. Devices using artificial intelligence or machine learning, including AIMD (AI-enabled Medical Device) and MLMD (Machine Learning-enabled Medical Device), are treated as a third category that layers additional technical and clinical requirements on top of whichever SaMD or SiMD class applies.
| Category | Definition | Example |
| SaMD | Standalone software that runs on a general computer, tablet, or smartphone without being part of a specific hardware device | Continuous glucose monitoring app, digital ECG reading algorithm |
| SiMD | Software embedded in and controlling the performance of a physical medical device | Signal-processing module on an MRI machine, ventilator automation software |
| AIMD / MLMD | Medical devices, standalone or embedded, that use artificial intelligence or machine learning, including generative models and LLMs | AI-assisted radiology triage tool, generative clinical decision support assistant |
SaMD Classification Indonesia: The Kemenkes Decision Logic
KMK No. HK.01.07/MENKES/951/2026 sets out a stepwise decision flow Kemenkes evaluators use to sort a product. Simplified, the logic runs through these checkpoints in order:
1. Does the software control the performance of, or provide a function to, a specific physical medical device? If yes, it is SiMD and takes on that device’s existing risk class.
2. If not, does it act on patient-specific data beyond simple storage, filing, or retrieval? If no, it falls outside the medical device definition entirely.
3. Does it acquire, process, or analyze signals or data from defined sources such as in vitro diagnostic results, MRI output, next-generation sequencing, or continuous glucose monitoring? If yes, it is SaMD.
4. If not, does it display, analyze, or print continuous signals, medical images, waveforms such as ECG traces, or continuous sampling data? If yes, it is SaMD.
5. If not, does it generate a disease risk score, a probability of a condition, or a time-critical output? If yes, it is SaMD; if no, it sits outside Kemenkes’s software medical device scope.
This flow determines whether a product needs an Izin Edar at all before it can be marketed for clinical use in Indonesia, which is why we recommend running a candidate product through it with a regulatory advisor rather than assuming a health app is exempt.
IEC 62304 Medical Software Indonesia: The Standards KMK No. HK.01.07/MENKES/951/2026 Points To
Rather than inventing new technical standards, KMK No. HK.01.07/MENKES/951/2026 anchors its quality and safety expectations to standards already recognized internationally. For SaMD, SiMD, and AI-enabled devices, the guideline references:
- ISO 13485 for the quality management system covering the software’s design and maintenance.
- ISO 14971 for risk management across the software’s lifecycle.
- IEC 62304 for the medical software development lifecycle, the standard most directly relevant to IEC 62304 medical software Indonesia compliance work, covering how the software was designed, verified, and maintained.
- IEC 82304 for the safety of the finished health software product as deployed.
- IEC 63450, a newer standard specifically for technical verification of AI-enabled medical devices (AIMD).
- IEC 63521, a newer standard for performance evaluation of machine-learning-enabled medical devices (MLMD).
- ISO 60601-1 (Medical electrical equipment — general requirements)
- IEC 61010-1 (general safety requirements)
- IEC 62366-1 (usability engineering)
- ISO 27001 (Information Security Management System) — ini relevan sekali mengingat artikel sudah membahas keamanan siber/data AI, sebaiknya ditambahkan.
In our experience, the IEC 62304 lifecycle documentation is where international SaMD developers stumble first in an Indonesian filing, because global teams often hold this evidence internally in an engineering wiki rather than as the packaged, submission-ready dossier Kemenkes evaluators expect to see.
Clinical Evidence Expectations for SaMD Registration
KMK No. HK.01.07/MENKES/951/2026 scales clinical evidence to what the software actually does for the clinician, not only to how severe the underlying condition is. The clearest takeaway, and a useful standalone answer to a common question, is this: a clinical trial is required wherever the software treats or diagnoses directly, at every severity level, while software that only informs or supports clinical management can often rely on a literature review and documented clinical experience unless the condition is critical.
| What the software does | Typical clinical evidence expectation |
| Provides information only | Literature review plus documented clinical experience |
| Drives or informs clinical management | Literature review plus clinical experience; a dedicated clinical trial is added when the condition is critical or the output is diagnostic-adjacent |
| Treats or diagnoses directly | Literature review, clinical experience, and clinical trial data, regardless of how severe the underlying condition is |
AI Medical Device Kemenkes Registration: Sandbox and Local Clinical Validation
For AI medical device Kemenkes registration, KMK No. HK.01.07/MENKES/951/2026 introduces two mechanisms aimed at balancing innovation with patient safety. First, a regulatory sandbox lets a digital health innovation with limited clinical evidence for the Indonesian population be tested in a controlled setting, provided the product has already reached Technology Readiness Level 9, meaning it has been proven to operate successfully under real operating conditions elsewhere.
Second, imported software-based medical devices that use AI for medium- to high-risk purposes, such as diagnosis, screening, or clinical decision-making, must undergo local clinical validation in Indonesia, with results submitted to Kemenkes no later than one year after the Izin Edar is issued. In our experience, manufacturers who assume their overseas validation data is sufficient on its own are the ones most likely to be asked for this local validation step after the fact, which is why we recommend planning for it before submission rather than after a query.
Continuous Machine Learning and LLM-Based SaMD
KMK No. HK.01.07/MENKES/951/2026 also addresses models that keep learning after they reach the market. Business operators must submit documentation of their continuous machine learning control mechanism, covering anomaly detection and mitigation, real-world data management, traceability of the learning process, and an ongoing validation strategy. For devices built on generative models or large language models, the guideline specifically requires a plan to mitigate hallucination, meaning the model’s tendency to produce confident-sounding but factually incorrect output.
The guideline distinguishes changes serious enough to require a new Izin Edar application from smaller changes that only need to be reported as an update to existing registration data. In our experience, that line is not always obvious in practice for a model whose parameters shift gradually, so we treat any change to diagnostic or triage logic as a new-application question until Kemenkes confirms otherwise, rather than defaulting to the lighter reporting route.
How Medical Device Registration in Indonesia Differs for SaMD
Medical device registration in Indonesia for hardware generally follows a predictable path through Regalkes: self-declared classification, ASEAN CSDT dossier, PNBP payment, technical review, and NIE issuance. SaMD registration in Indonesia follows the same legal backbone under Permenkes No. 62 Tahun 2017, but KMK No. HK.01.07/MENKES/951/2026 adds a software-specific classification determination, IEC 62304 and AI-specific standards evidence, and, where applicable, the sandbox and local validation steps described above.
In our experience, the practical difference that matters most to a project timeline is that hardware files can often move through Regalkes largely on paper, while a SaMD or AI-enabled file typically still needs a direct sit-down or working session with Kemenkes evaluators to confirm classification and walk through the algorithm’s intended use, simply because the new pedoman is too recent for a fully standardized, arm’s-length review process to have settled in yet.
The SaMD Registration Process in Indonesia, Step by Step
1. Confirm Whether the Product Is SaMD, SiMD, or Out of Scope
Run the product’s intended use statement through the classification decision flow above, and document the reasoning, since Kemenkes will ask for it during review.
2. Secure a Local Entity, IDAK, and CDAKB
As with any medical device registration in Indonesia, a foreign SaMD developer needs a locally established entity holding a valid IDAK and CDAKB certificate to act as the Izin Edar license holder.
3. Assemble the Technical and Clinical Dossier
Compile the ISO 13485, ISO 14971, IEC 62304, and, where relevant, IEC 82304, IEC 63450, and IEC 63521 evidence alongside the clinical evidence tier the product’s function level requires.
4. Bring the Classification to Kemenkes Directly
Because the software-specific pathway is new, expect a direct classification check with Kemenkes evaluators rather than a purely self-declared class, particularly for anything touching diagnosis, triage, or AI-driven decision support.
5. Address Sandbox or Local Validation Requirements, If Applicable
Confirm early whether the product needs sandbox testing or post-approval local clinical validation, since both affect the realistic launch timeline.
6. Secure Wireless Compliance with Komdigi (for Bluetooth, RFID, or Wi-Fi)
If the device utilizes wireless connectivity (such as Bluetooth, Radio Frequency Identification / RFID, or Wi-Fi), you must obtain telecommunications equipment certification from the Ministry of Communication and Digital (Kementerian Komunikasi dan Digital / Komdigi).
The Market Opportunity Behind SaMD Registration in Indonesia
For all the compliance detail above, the timing is landing at a genuinely favorable moment commercially. Estimates vary by research house depending on how broadly “digital health” is defined, but they point the same direction: Indonesia’s digital health market was already valued at roughly USD 2.1 billion in 2023 (Ken Research), and Indonesia’s AI-in-healthcare segment specifically is estimated to grow from under USD 0.1 billion in 2022 to around USD 0.82 billion by 2030, a compound annual growth rate above 40 percent (Insights10). Broader connected-healthcare estimates from Mordor Intelligence put the segment even higher and growing at a similarly rapid pace through the early 2030s.
Several structural factors are driving that growth. SatuSehat, the government’s national health information platform, now connects the large majority of Indonesia’s hospitals and primary care facilities and holds records for hundreds of millions of patients, giving digital and AI-based tools a ready integration layer that did not exist a few years ago. Smartphone and internet penetration keep climbing, chronic disease burden keeps rising, and Indonesia’s ratio of specialists to patients remains far below regional norms, a gap that AI-assisted diagnostic and triage tools are well positioned to help close. For a SaMD developer, a young but clarifying regulatory pathway combined with a market hungry for scalable diagnostic support is a rare and time-limited combination. Getting classification and dossier work right early is not just a compliance box to check; it is what determines whether a product can launch while that growth window is open, rather than losing a year or more to back-and-forth with Kemenkes on classification alone.
How Product Registration Indonesia Can Help With Your SaMD Registration
Our Medical Device Registration service covers SaMD classification review, IEC 62304 and AI-standard dossier preparation, and direct coordination with Kemenkes evaluators under KMK No. HK.01.07/MENKES/951/2026. For developers without an established Indonesian entity, our License Holder Service lets us act as your local IDAK/CDAKB-holding representative and Izin Edar license holder for the software product.
Beyond the regulatory dossier itself, we also support the commercial side of entering Indonesia. That includes helping you identify and vet local distributor or hospital-network partners, advising on realistic pricing and reimbursement positioning given Indonesia’s mixed public and private payer landscape, and sequencing your registration timeline against a practical go-to-market plan, so your Izin Edar lands at the moment your commercial launch is actually ready to use it, not months before or after. Given how fast the local digital health market is growing, a registration delay is rarely just a compliance cost; it is a commercial one too.
Because this pathway is still new and evaluated case by case, we recommend a pre-submission classification review before committing to a launch date. It follows the same classification discipline we apply in Types of Medical Devices and Their Classification in Indonesia, extended to the software-specific rules under the new guideline.
Talk to Our Medical Device Registration Team
You don’t have to work out your product’s classification alone, and you shouldn’t wait until you’re already in front of Kemenkes to find out where it stands. Our Medical Device and IVD Registration team works with health-tech companies on exactly this kind of question every day, from confirming whether a tool is SaMD, SiMD, or AI-enabled under KMK No. HK.01.07/MENKES/951/2026 to mapping out the standards and clinical evidence your filing will need. Tell us about your product using the form below, and one of our regulatory specialists will get back to you shortly to talk through the fastest, most realistic path to market in Indonesia.
