On 20 October 2026, Indonesia’s Ministry of Health issued the Decision of the Minister of Health of the Republic of Indonesia No. HK.01.07/MENKES/951/2026 on Guidelines for Marketing Authorization of Software Medical Devices. The decision defines the regulatory scope of software medical devices and brings software lifecycle quality management, AI technical documentation, clinical evidence, local clinical validation, software changes and post-market monitoring within its regulatory framework.
Official source
Original text of Indonesia Ministry of Health Decision HK.01.07/MENKES/951/2026 (regalkes.kemkes.go.id)
1. Scope of Application
The guideline applies to the following three product categories:
| Product category | Basic definition |
|---|---|
| Software as a Medical Device (SaMD) | Standalone software with a medical purpose that is not part of the hardware of another medical device. |
| Software in a Medical Device (SiMD) | Software embedded within a medical device to control device operation or perform specific functions. |
| AI-enabled Medical Device | A system or application that uses artificial intelligence to fulfil a medical purpose. |
Artificial intelligence or machine learning technology does not automatically constitute a medical device. The decisive factors are whether the product has an intended medical purpose and whether its outputs are used for medical activities such as diagnosis, monitoring, treatment or clinical decision-making.
2. Core Regulatory Requirements
1. Clear distinction between SaMD and SiMD
- SaMD: The software independently fulfils a medical purpose and can run on general-purpose platforms such as computers, tablets or smartphones. Examples include software that analyzes electrocardiogram data to predict the risk of heart disease and software used for diagnostic interpretation of medical images.
- SiMD: The software is an integral part of a medical device and is primarily used for device control, signal processing or device-specific functions. Examples include signal processing modules in CT or MRI equipment and automatic control systems in ventilators.
Software used solely for administrative management, data storage or other non-medical purposes that do not affect medical device functionality is not automatically classified as a medical device merely because it uses digital technology.
2. Emphasis on software lifecycle quality management
Manufacturers and distributors of software medical devices must hold the appropriate business licences and meet the applicable Good Manufacturing Practice (CPB) or Good Distribution Practice (CDB) requirements.
The software quality management system must cover the entire product lifecycle, including:
- Product planning and requirements analysis;
- Design and development, verification and validation;
- Risk management and cybersecurity;
- Version control, configuration management and change traceability;
- Software deployment, maintenance, updates and retirement;
- Complaint handling, problem analysis and continuous improvement.
Reference standards include ISO 13485, ISO 14971, IEC 62304, IEC 62366-1, IEC 82304 and ISO 27001. Relevant AI and machine learning technology validation and performance evaluation standards also apply to AI-enabled medical devices.
3. More specific technical documentation for AI-enabled medical devices
The decision sets out more specific documentation requirements for medical devices using artificial intelligence or machine learning, principally covering:
| Documentation category | Core requirements |
|---|---|
| Datasets | Describe the input data types, data sources, scale and composition, and how the training, validation and test sets are divided. |
| AI model | Describe the model architecture, rationale for selection, suitability, limitations and risk mitigation measures. |
| Performance evaluation | Provide independent test data, evaluation metrics and results, including applicable metrics such as accuracy, sensitivity, specificity and AUC. |
| Clinical evaluation | Demonstrate a valid association between the software output and the target clinical condition, supported by appropriate clinical evidence. |
| Deployment and monitoring | Describe the actual use workflow, human intervention mechanisms, model version management and post-market monitoring arrangements. |
| Continuous learning | For continuously learning products, describe model updates, anomaly detection, rollback mechanisms, data quality and ongoing validation strategies. |
For products using generative artificial intelligence or large language models (LLMs), the documentation must also address output controls, hallucination risk mitigation, restrictions on use, and methods for evaluating the consistency and accuracy of medical information.
4. Certain imported software medical devices may require local clinical validation in Indonesia
Certain imported software medical devices require local clinical validation in Indonesia, with a particular focus on:
- Software that undergoes further development or retraining using data representative of the Indonesian population;
- Software using medium- or high-risk artificial intelligence technology, particularly for diagnosis, screening or clinical decision-making.
Local clinical validation may be conducted at hospitals, universities, accredited laboratories and relevant Ministry of Health technical units that meet the documentation requirements.
Local clinical validation may proceed in parallel with the marketing authorization application. However, clinical evidence and performance evidence provided by the manufacturer must be submitted with the application, and the local validation results must be submitted no later than one year after the marketing authorization is issued.
5. Clinical evidence and validation requirements
Clinical evidence is an important part of the registration dossier and may include:
- Relevant scientific literature and clinical practice guidelines;
- Comparative data for similar software already on the market;
- Clinical trial results supporting new functions or major changes to clinical functionality.
The decision also requires analytical validation and clinical validation for software medical devices. Appropriate evidence requirements must be determined according to product risk, clinical use and the influence of the software output on medical decisions.
6. Software labelling and version information must be traceable
The decision specifies corresponding identification requirements according to the software delivery method.
| Software delivery format | Main requirements |
|---|---|
| Delivery on physical media, such as CD, DVD or USB | A physical label and instructions for use must be provided. The instructions may be in paper or electronic form. |
| No physical media, such as downloaded or web-based software | Screenshots of interfaces displaying product identification information, such as the startup screen or product promotional materials, must be provided, together with the download address, download procedure, installation guide and instructions for use. |
Product identification information must include at least the product name, software version number, and the name and/or identity details of the product owner. The information must also support product traceability, safe use and performance identification.
7. Software changes may require a new marketing authorization application
The decision establishes different procedures for different types of software changes:
| Type of change | Procedure specified in the decision |
|---|---|
| Changes affecting the scope of application, principal functions or clinical performance | A new marketing authorization application is required. |
| Changes that do not affect safety, benefits or quality | Apply for a variation to the marketing authorization. |
| Other changes not falling into either category above | Submit information on the change and the necessary documentation to the Minister of Health for further evaluation. |
Changes that may affect clinical functionality include modifications to diagnostic or therapeutic algorithms, new functions affecting clinical decisions, changes to alarm functions affecting patient management, and system platform changes that may affect safety or performance.
3. Post-Market Supervision and Authorization Holder Responsibilities
The decision further clarifies the responsibilities of software medical device authorization holders and relevant business operators.
The main requirements include:
- Data protection and cybersecurity: Safeguard patient data and personal information, and implement cybersecurity risk controls and data protection measures.
- AI governance: Follow principles including inclusiveness, transparency and accountability, and identify and mitigate the risk of algorithmic bias.
- System interoperability: Commit to enabling software output data to interface with Indonesia’s National Health Information System (SIKN) or SATUSEHAT. Where such integration is implemented, open-system, interoperability and national-platform integration requirements must be met.
- Complaints and adverse event handling: Collect, evaluate and follow up on user complaints, adverse events and any necessary field safety corrective actions.
- Post-market performance monitoring: Continuously monitor software safety, functionality, clinical performance and cybersecurity vulnerabilities, and take corrective action or recall products where necessary.
Routine on-site inspections are conducted once a year. Additional inspections may be conducted as necessary in accordance with the law.
4. Implications for Medical Device Companies
Companies should pay particular attention to software classification, quality management, cybersecurity, clinical evidence and version change control. For certain imported software medical devices, they must also assess whether local clinical validation in Indonesia is required. For AI-enabled products in particular, companies should prepare documentation on datasets, algorithm performance and clinical evaluation in advance, and establish continuous monitoring and risk control mechanisms to reduce registration and post-market compliance risks.
This article is based on Indonesia Minister of Health Decision HK.01.07/MENKES/951/2026 and its annex. It is provided for general industry reference only and does not constitute legal or regulatory advice. Specific requirements are subject to the latest text published by Indonesia’s Ministry of Health.