Indonesia KMK 951/2026: Marketing Authorization of Software Devices

Indonesia's Minister of Health has issued Decree No. HK.01.07/MENKES/951/2026 on the Guideline for Marketing Authorization of Software-Based Medical Devices (Kepmenkes/KMK 951/2026). The decree was signed on 7 September 2026 and took effect the same day. It adopts the guideline in its annex as the reference (acuan) for government, medical device businesses and other stakeholders that handle marketing authorization (izin edar) of software-based devices. The guideline describes itself as a technical explanation of the requirements and procedures for marketing authorization. Where this article says "must", the guideline itself uses mandatory wording (wajib or harus) or lists the item among the holder's obligations (kewajiban). The decree contains no transitional provision for products that are already registered or have applications under review.

Scope

The guideline covers three groups of products:

• Software as a Medical Device (SaMD): stand-alone software with a medical purpose that is not part of a hardware medical device. This includes software for in vitro diagnostic (IVD) devices, and software running on general-purpose platforms such as computers, tablets and smartphones. Software that only drives or controls another medical device is not SaMD. The guideline's examples are a glucose-monitoring app, an algorithm that predicts heart-attack risk from digital ECG data, X-ray review software on a general workstation and a remote vital-signs app.
• Software in a Medical Device (SiMD): software embedded in a device that supports its operation. Its functions include, but are not limited to, operating or controlling the device, changing its state, or producing output related to its hardware function. Under the guideline's classification flowchart, SiMD is registered as an accessory of the main device, and its requirements and risk class follow that device. The guideline's examples are signal processing in MRI or CT scanners, ventilator automation, ultrasound imaging software and pacing or defibrillation software in pacemakers and ICDs.
• Medical devices with artificial intelligence applications: AI, including machine learning, natural language processing and large language models (LLMs), is a medical device only when it has a medical purpose. Generative AI outputs such as images, text, audio or video are in scope when they are intended for diagnosis, monitoring, therapy decisions or patient care. AI used only for administrative data management, storage or other operational functions that do not affect a device's function is excluded.

The same flowchart treats software as not a medical device when it only stores, archives, communicates, performs simple searches or applies lossless compression, or when it does not act on data specific to an individual patient. Software that acts on patient-specific data is also not a medical device under the flowchart if it does none of the listed functions: acquiring, processing or analyzing signals, IVD, MRI, NGS, CGM or computer-aided detection/diagnosis data; displaying, analyzing or printing continuous signals, medical images or ECG waveforms; or giving disease risk scores, probabilities or time-critical output.

Manufacturing, distribution and quality system

Production is carried out by a medical device producer, which must hold an Indonesian business license under the relevant KBLI code and meet Good Manufacturing Practice for medical devices (CPB). Distribution is carried out by a medical device distributor or its branch, which must hold a business license and meet Good Distribution Practice (CDB). Both producers and distributors must apply a quality management system. The guideline describes an effective quality management system as including control of outsourced processes, including commercial off-the-shelf (COTS) software, with the product owner remaining responsible for safety and performance.

For implementing the quality management system, the guideline lists standards that may be used as references, without editions. They include ISO 13485, ISO 14971, IEC 60601-1 and IEC 61010-1 (which the decree labels as ISO standards), IEC 62366-1, IEC 62304, IEC 82304, IEC 63450, IEC 63521 and ISO 27001.

Registration documents

Software verification and validation. These documents must follow the software development life cycle under IEC 62304 or an equivalent recognized standard. At a minimum they must cover software version, traceability, change control, interoperability and cybersecurity. If the version tested differs from the version submitted, the applicant must provide a version comparison with justification. Additional validation is required where there are significant changes that could affect safety, performance or intended use. The marketed software version must appear on the device label and/or the software interface.

Connected software. Software connected to other devices, external systems, networks or the internet needs more information in the dossier. It must describe data exchange mechanisms that protect confidentiality, integrity and availability, together with vulnerability identification, risk analysis, mitigation and evidence that the controls are effective.

Risk management. Risk management must run throughout the software life cycle, by reference to standards such as ISO 14971. Every software change must be assessed for additional risk.

AI and machine learning devices. Design, development, validation, deployment and any training or retraining of AI models must take place within the quality management system. Table 3.1 of the guideline sets out what an AI/ML dossier must contain:

Devices that use continuous machine learning must also document how model changes are controlled so they do not affect safety, performance or intended use. That documentation covers update frequency, anomaly detection and mitigation, real-world data handling, dataset integrity, version control with rollback to an earlier algorithm, traceability between data, training and outputs, and an ongoing validation strategy. Devices using generative models or LLMs must also describe output controls, mitigation of hallucination, limits on use, and how the consistency and accuracy of the medical information they generate are evaluated during continuous adaptation.

Clinical evidence

Clinical evidence may consist of any of the following:

• a literature review and relevant clinical practice guidelines;
• a comparison with similar software already on the market, where one exists;
• clinical trial results, especially to support new claims or significant changes in clinical function.

Premarket clinical trials depend on the device's risk and on how significant its information is to clinical decisions. The guideline classes clinical evidence as well-established or novel, and this class is used as the basis for deciding whether additional evidence is needed. Evidence should be chosen proportionately and without undue burden. For high-risk software, the clinical evaluation may need independent review. Analytical validation and clinical validation are required for all software-based devices. Clinical validation takes place both before and after marketing. A new intended use or a new target population requires the clinical evaluation to be repeated.

The guideline introduces Table 3.2 as recommended clinical evidence, although the table's own title calls it the clinical evidence "needed" for marketing authorization. It is organized by the seriousness of the healthcare situation and the significance of the software's information to the healthcare decision:

The seriousness of the situation does not change the evidence listed; only the significance of the information does.

Local clinical validation for certain imported software

Certain imported software-based devices need local clinical validation in Indonesia. Its purpose is to show that the software produces clinically meaningful output for the Indonesian target population. It applies to imported software that:

• has been further developed and/or retrained using data representing the Indonesian population; and/or
• uses AI with a moderate to high risk level, in particular for diagnosis, screening or clinical decision-making.

Validation may take place at:

• hospitals, universities or accredited laboratories;
• Ministry of Health technical units responsible for the safety of health equipment and facilities, or for biomedical and health genomics services.

The biomedical and genomics unit may provide mentoring to the other sites where needed. Validation can run in parallel with the marketing authorization application if the manufacturer's clinical and performance evidence is attached. The results must be submitted no later than one year after the marketing authorization is issued. During validation, the product may be used in a limited way for evaluation or under specific arrangements, provided patient safety is not put at risk. If the results differ significantly from the original clinical evidence, administrative action may follow under the applicable regulations. The guideline states that local validation should be efficient, proportionate and risk-based, and should not hinder access to innovation.

Regulatory sandbox and technology readiness

For software that lacks adequate clinical evidence of accuracy, precision of interpretation, safety or performance in the Indonesian population, the business may run its own clinical trial under the medical device clinical trial guideline. Alternatively, it may carry out limited testing through a regulatory sandbox under the applicable regulations. The same section states that digital health innovation products applying for marketing authorization as medical devices must have reached Technology Readiness Level (TKT) 9. TKT 9 means the system has been proven to operate successfully in its actual operating environment, in line with its intended use. The guideline does not define "digital health innovation product" or say whether this requirement applies beyond sandbox products.

Labeling

Labeling may take the form of a label, instructions for use, an operating guide or other relevant information. At a minimum it must identify the product name, software version number and the product owner. It must also state the intended use, instructions, performance information and safety information, including warnings, clearly. Software supplied on physical media (CD, DVD or USB) needs a physical label and instructions for use, either in print or as a link. Software that is downloaded or web-based must be registered with interface screenshots, such as a splash screen or brochure, showing the identification elements and version number. Users must also be given the download link, download procedure, installation guide and operating procedure.

Changes after approval

The guideline divides changes to an approved software-based device into two categories, plus a fallback rule:

Every change must be documented in the quality management system.

Marketing authorization holder obligations

The holder must observe ethical principles for software-based devices:

• inclusiveness and non-discrimination;
• safety and security;
• humanity;
• accessibility;
• transparency;
• credibility and accountability;
• personal data protection;
• sustainability;
• intellectual property.

Data-protection incidents must be reported under the applicable regulations. For AI/ML devices, Good Machine Learning Practice (GMLP) is mandatory under ten principles. They run from intended use and multidisciplinary expertise through to post-market monitoring and change management, including the risks of updates and retraining. For AI/ML software, data management must follow principles that include:

• security and privacy of patient data;
• transparency and accountability of AI features;
• data minimization;
• retention and deletion based on patient consent;
• cloud storage with high security standards;
• an incident and data-breach reporting policy;
• cyber-threat mitigation.

The holder must also commit that the software's output data can be integrated with the National Health Information System (SIKN) or SATUSEHAT. If integrated, the product must be designed as an open system, support applicable interoperability standards and be able to connect to the national health data exchange platform.

Post-market supervision

The Minister supervises software-based devices. One route is reports from businesses, which include:

• complaint handling, covering adverse events and field safety corrective actions (FSCAs);
• technical monitoring, covering cybersecurity vulnerabilities;
• post-market clinical performance validation using relevant data, including real-world data.

Where monitoring shows a risk, corrective action may include safety warnings and/or product recall. Monitoring records must be kept available for supervision. Supervision also includes routine field inspections once a year and incidental inspections when needed.

What this means for manufacturers

Pure Global analysis:

• Classify the software first. Use the guideline's flowchart to decide whether software is SiMD, SaMD or not a medical device. SiMD is registered as an accessory of the main device and follows its requirements and risk class. The guideline itself sets no SaMD risk-class rules.
• Map SaMD to the clinical evidence table. Table 3.2 uses the same two axes as the IMDRF SaMD risk categorization framework (N12): the state of the healthcare situation and the significance of the information. A manufacturer that has already categorized its software under N12 can see where it sits. A clinical trial is listed only in the "treat or diagnose" column. Whether a trial is needed also depends on whether the evidence is well-established or novel, and on any new clinical claims.
• Imported moderate- to high-risk AI (particularly for diagnosis, screening or clinical decisions): plan local clinical validation before launch. It can run alongside the application, but the one-year deadline starts when the marketing authorization is issued, so arrange sites and data access early. The guideline does not say which risk classes count as moderate to high, so confirm this with the Ministry. For any imported software, further development or retraining on data representing the Indonesian population is itself a criterion for local validation.
• Release management: add an Indonesia impact check to the software release process. Algorithm changes affecting diagnostic or therapeutic function or clinical performance, adding or removing alarms that affect patient management, and operating-system or infrastructure changes that could affect performance or safety all require a new marketing authorization, not a change to the existing one. Every change must be documented in the quality management system, and the version must be shown on the label and/or interface. Recording an Indonesian change category for each release therefore links the regulatory route to the version users see.
• AI development and life cycle: the ten GMLP principles the holder must apply track the ten guiding principles in IMDRF's GMLP document (N88, 2025), although the decree does not cite N88. GMLP work done for other markets is a reasonable starting point, but the decree does not say how compliance is to be evidenced. Datasets must represent the intended patient population, and local validation and the sandbox refer to performance in the Indonesian population. Expect questions about Indonesian representativeness.
• Products already registered or under review: the decree took effect on 7 September 2026 and has no transitional provision. Confirm with the Ministry of Health how it applies to pending applications and to the next change or renewal of existing registrations. Do not assume that earlier documentation remains sufficient.

Pure Global's Indonesia market page covers the overall registration route. Our research on AI as a medical device and global market access compares how other regulators treat AI software.