INDONESIA · SOFTWARE MEDICAL DEVICES
Indonesia’s new SaMD and AI medical device guideline: which products need local clinical validation?
On 7 September 2026 Indonesia’s Minister of Health signed KMK HK.01.07/MENKES/951/2026, the Guideline on Marketing Authorisation of Software-Based Medical Devices (Pedoman Izin Edar Alat Kesehatan Berbasis Perangkat Lunak), which took effect on the date of signature. For makers of AI imaging, diagnostic and clinical decision software, three questions need answering early: does the product have a medical purpose, does imported software trigger local clinical validation in Indonesia, and does the version submitted match the test evidence? (Source: KMK 951/2026, fourth operative clause)
The guideline allows local clinical validation to run in parallel with the marketing authorisation (izin edar) application, with the results due no later than one year after the authorisation is issued. The parallel application must still include the manufacturer’s clinical and performance evidence, so it does not mean software can be authorised first and validated from scratch afterwards.
First define the medical function: SaMD, SiMD and AI
SaMD and SiMD describe how software delivers a medical function; AI or machine learning describes the technology used. AI software can be standalone SaMD or embedded in a device as SiMD, so “it uses AI” does not by itself determine the product type or risk class. (Source: KMK 951/2026, Chapter I Section C; Chapter II Sections A, B and D, pp. 7–12)
| Product type | What the guideline looks at | What the manufacturer should provide first |
|---|---|---|
| Standalone software (SaMD) | Can stand alone and serves one or more medical purposes without being part of medical device hardware; may run on general computing platforms such as computers, tablets and phones. Software that only drives or controls another device is excluded. | Intended use, inputs and outputs, users, target population and clinical workflow. |
| Software in a device (SiMD) | Embedded in and part of a medical device, controlling its performance or providing specific functions; not intended for standalone use. | Host device configuration, hardware/software interfaces, version relationships and effect on safety and performance. |
| AI/machine learning functions | AI and machine learning fall within the medical device category only where there is a medical purpose (the guideline uses the term AIMD). | Role of the model, clinical claims, training and test data, output limits and human review. |
| Administrative or storage functions | Software that only supports non-medical functions such as data management, tracking or recording, and AI used for administrative data management or data storage, is outside the medical device definition. | Functional boundaries and why the software plays no part in medical decisions; do not rely on the product name alone. |
Chapter II Section C uses a flowchart (Figure 2.1) to distinguish SaMD from SiMD; this is not risk classification. The risk class still has to be determined separately from the intended use and the applicable classification rules. For combined software, we suggest listing the modules with a medical purpose, the administrative modules and the interfaces between them.
Which imported software needs local clinical validation in Indonesia?
Chapter III Section D states that certain imported software-based medical devices must undergo local clinical validation in Indonesia and sets out two criteria joined by “and/or”, so either one is enough to trigger it: (Source: KMK 951/2026, Chapter III Section D, items 1 and 3, pp. 21–22)
- Data criterion: further developed and/or retrained using data representing the Indonesian population;
- AI risk criterion: uses moderate- to high-risk AI technology, particularly for diagnosis, screening or clinical decision-making.
Note that the guideline does not define which Indonesian risk class “moderate to high risk” corresponds to. For borderline products, we suggest documenting the intended use, the role of AI in the decision and the proposed class before submission, and confirming with the Ministry of Health where necessary rather than assuming the criterion does not apply.
Local validation must show that the software produces clinically meaningful results for its intended use in the Indonesian target population, taking into account population characteristics, clinical practice, data sources and the setting of use. It may be carried out by hospitals, universities, accredited laboratories and Ministry of Health technical units with relevant functions (such as device safety); the guideline also calls for validation to be efficient, proportionate and risk-based. When choosing a partner, match research capability to the product’s clinical setting rather than simply checking that it can issue a report. (Source: as above, Chapter III Section D, items 2 and 4, p. 22)
The table below is MediPass’s suggested way to organise the project; it is not a form set by the guideline.
| Situation | Question to resolve | Suggested evidence |
|---|---|---|
| Plan to develop or retrain using Indonesian population data | Is the retrained model the same as the existing version, and does the criterion apply? | Data and model change description, local validation protocol, target version and acceptance criteria. |
| Moderate- to high-risk AI for diagnosis, screening or clinical decisions | Do the local population and workflow support the clinical claims? | Population and setting rationale, independent testing, clinical performance and risk controls. |
| Parallel application and local validation | Is the existing manufacturer evidence sufficient, and when will results be submitted? | Original clinical and performance evidence, local study plan, owners and tracking of the one-year deadline. |
| Other software products | Is the product genuinely outside the triggers, and is the overall clinical evidence sufficient? | Applicability rationale and technical/clinical evidence; not triggering local validation does not mean no clinical evidence is needed. |
Chapter III Section E sets out the general clinical evidence requirements. Table 3.2 recommends literature review, clinical experience or clinical trials according to the severity of the healthcare situation (critical, serious, non-serious) and the significance of the software’s information for healthcare decisions. It is not a trigger table for local validation; record the two assessments separately. (Source: as above, Chapter III Section E, pp. 23–24)
The parallel route and the one-year deadline
Under Chapter III Section D item 4, local clinical validation may run alongside the marketing authorisation application, which must include the manufacturer’s clinical and performance evidence. The local validation results must be submitted no later than one year after the authorisation is issued. While validation is under way, the product may be used to a limited extent in an evaluation context or under specific arrangements, provided there is no risk to patient safety. (Source: as above, Chapter III Section D, item 4, p. 22) This should not be read as permission for unrestricted commercial sale during validation.
If the local results differ significantly from the initial clinical evidence, administrative action may be taken under the applicable regulations. We therefore suggest that manufacturers fix the study version, inclusion and exclusion criteria, endpoints, data sources and result owners before submission, and agree who will start the assessment and correction if a performance deviation appears.
AI documentation needs more than an accuracy figure and a demo
Chapter III Section C requires verification and validation (V&V) documents to cover the software life cycle under IEC 62304 or an equivalent recognised standard, with design, development, validation and control documentation for AI devices submitted as set out in Table 3.1. (Source: as above, Chapter III Section C and Table 3.1, pp. 17–20)
| Table 3.1 area | Main content |
|---|---|
| Data | Input data types, selection criteria and the rationale for pre-processing; data sources, size, composition and the training/validation/test split; labelling, cleaning and handling of missing data, with no duplication across datasets; adequacy of the data, and identification and mitigation of bias. |
| Model | Architecture or reference base model, fit with the intended use, limitations and mitigations; performance evaluated on a test set independent of the training data. |
| Testing and clinical relevance | V&V protocols and reports tied to the performance specification, including acceptance limits; accuracy, sensitivity, specificity and reproducibility; a valid link between the output and the target clinical condition. |
| Use and versions | Workflow and how outputs are interpreted, including mechanisms requiring human intervention; the data update cycle for continuous learning or retraining; the registered version and version management for post-market traceability. |
If the tested version differs from the version submitted, a version comparison with justification is required, and additional validation where significant changes could affect safety, performance or intended use. The marketed version must be shown clearly on the device label and/or software interface. For continuous learning models, evidence of a control mechanism is needed to show that model changes do not affect safety, performance or intended use, together with arrangements for anomaly detection, rollback to the previous version, real-world data and ongoing V&V. For generative AI or large language models, the documentation should also cover output controls, mitigation of hallucination risk, usage restrictions and methods to evaluate the consistency and accuracy of generated medical information. (Source: as above, Chapter III Section C, items 3, 4 and 8–10, pp. 17 and 20–21)
We suggest keeping a single version evidence index that links “version to be marketed – algorithm or model – datasets – test reports – risk controls – labelling and IFU”. This avoids submitting files that are each the “latest” in their own department but do not match one another.
Before updating software, decide which change category applies
Chapter III Section G sorts changes into three categories by their effect on the product; “it is just a software update” is not enough to conclude that nothing needs to be filed. (Source: as above, Chapter III Section G, pp. 27–29)
| Change category | Examples in the guideline | Procedure |
|---|---|---|
| Affects indication, main function or clinical performance | Changes to how the product is controlled that alter its diagnostic or therapeutic function; algorithm changes affecting diagnostic or therapeutic function or clinical performance; new features affecting clinical function (such as integration with another device that influences medical decisions); adding or removing alarms that affect patient management; version changes affecting parameters such as accuracy or sensitivity; operating system or infrastructure changes that could affect performance or safety. | New marketing authorisation application. |
| No effect on safety, benefit and quality | Minor bug fixes that do not affect clinical function (such as interface display or format errors); new administrative or non-clinical features (such as display quality, report formats or printing). | Authorisation change (perubahan izin edar). |
| Neither of the above | – | Submit information on the change, with the data needed, to the Minister for further assessment. |
Every change must be documented in the quality management system. We suggest recording what changed, which outputs are affected and which risk analyses and validations need updating, and then deciding on the procedure.
Frequently asked questions
Does CE marking or a US FDA clearance exempt the product from local validation?
The guideline does not mention foreign approvals and contains no provision exempting or reducing local validation on that basis. Whether validation is triggered depends on the criteria in Chapter III Section D. Foreign clinical and performance evidence can be submitted as manufacturer evidence, but you still need to check that its version, intended use and population support the Indonesian application.
If we have not retrained on Indonesian data, are we outside the requirement?
Not necessarily. Moderate- to high-risk AI used for diagnosis, screening or clinical decisions is a separate criterion. Even where local validation is not triggered, the general clinical evidence under Chapter III Section E is still required.
Results are due within a year of authorisation. Can we look for a hospital after approval?
We would not recommend it. The parallel route already requires manufacturer evidence, and use during validation is restricted. Confirm the partner institution, protocol and timetable before applying, and treat one year as the latest date for results, not as preparation time.
Does software already registered in Indonesia need a new application under the guideline?
The guideline took effect on signature and contains no transitional provision for registered products. Subsequent software changes follow the procedures in Chapter III Section G; whether existing products need to submit additional documents should be confirmed with the Ministry of Health for the specific authorisation.
Official references
- Minister of Health Decree (KMK) No. HK.01.07/MENKES/951/2026 on the Guideline on Marketing Authorisation of Software-Based Medical Devices, fourth operative clause: effective on signature; Chapter I Section C and Chapter II: definitions; Chapter III Section C and Table 3.1 (pp. 17–21), Section D (pp. 21–22), Section E Table 3.2 (pp. 23–24), Section G (pp. 27–29), 7 September 2026, jdih.kemkes.go.id (PDF)
- JDIH Ministry of Health, status page for KMK HK.01.07/MENKES/951/2026 (status: in force), enacted 7 September 2026, jdih.kemkes.go.id
Prepared from official sources verifiable as of 9 September 2026. It distinguishes what the guideline requires from suggestions for project preparation; any specific product must be assessed against its actual use, software version and the applicable procedure.