Decree 951/2026: when software and AI need a medical-device licence

On 7 September 2026 the Minister of Health issued Ministerial Decree HK.01.07/MENKES/951/2026 on Guidelines for the Marketing Authorisation of Software-Based Medical Devices. It took effect on the day it was issued. It answers a question that comes up more and more in hospital procurement meetings: which software and AI features are treated as medical devices, and so need a marketing authorisation (izin edar).

What it covers

The guidelines cover three kinds of product:

• Software as a medical device (SaMD): standalone software used for a medical purpose.
• Software in a medical device (SiMD): software inside a medical device.
• Medical devices with artificial-intelligence applications.

The deciding factor is medical purpose. An AI or machine-learning system only counts as a medical device when its output is meant to serve as the basis for clinical judgement, diagnosis, monitoring of a medical condition, choice of therapy, or other medical action. AI used for non-medical functions — administrative data management, data storage, or operational functions that do not affect a medical device’s function — falls outside the definition.

In practice, hospital records and administration systems generally sit outside the scope. A tool that helps read radiology images, a risk score computed from an ECG, or a system that suggests diagnoses can fall inside it.

What the products must show

• Local clinical validation for certain imports. Imported software that has been retrained on data representing Indonesia’s population, or that uses moderate- to high-risk AI for diagnosis, screening, or clinical decisions, needs clinical validation in Indonesia. It can be done at hospitals, universities, accredited laboratories, or Health Ministry technical units. Results are due within one year of the marketing authorisation.
• Controls on generative models. If a product uses a generative model or a large language model, its registration file must describe how the model’s output is controlled, how hallucination risk is mitigated, what use is restricted, and how the accuracy of generated medical information is evaluated.
• Data and security. Among other things: patient data security and privacy, transparency and accountability of AI features, a policy for reporting incidents and personal-data breaches, and mitigation of cyber threats.
• Ready to connect to SATUSEHAT. Manufacturers commit that the examination data their software produces can be integrated with the National Health Information System or SATUSEHAT.
• Post-market oversight. Including complaint handling, adverse-event reporting, and a routine field inspection once a year.

The details are in the decree’s annex.

What hospitals should ask vendors

1. What intended use does the product state? The intended use written in the product’s documents, not its marketing language, decides whether it is a medical device.
2. If it is a medical device, what is its marketing authorisation number?
3. For imported moderate- to high-risk AI, where is local clinical validation being done, and when are the results due? A hospital asked to host validation needs ethics approval and data governance in place.
4. How do the product’s outputs reach the medical record and SATUSEHAT? Results kept only in the vendor’s system do not become part of the patient’s record.
5. Who handles incidents, and how is the hospital told?

Our position

The core functions of Adievia HMS and Adievia Praktik are medical record-keeping, administration, billing, and reporting — functions that these guidelines place outside the definition of a medical device. The AI assistant on our website answers questions about our products, not clinical questions. If we ever add a feature whose output is meant to support diagnosis or therapy, these guidelines are what we will assess it against before release.

This article is not regulatory advice. For a specific product, refer to the decree itself and consult the Health Ministry.