What SaMD means

Software as a Medical Device (SaMD) is software intended for medical purposes, such as diagnosis, prevention, monitoring, or treatment, without being part of a hardware medical device. This definition is used consistently by major global regulators, including the FDA in the United States and the HSA in Singapore, though the details of implementation vary by jurisdiction.

What sets SaMD apart from ordinary health software is its function, not its form. An app that simply displays or stores patient data generally falls outside SaMD scope. Once the software • • • starts giving clinical recommendations, calculating risk, or supporting a diagnostic decision, it falls under this category.

Why function matters more than form

The question we get most often from digital health startups: our app displays lab results, does that count as SaMD? The answer depends on what the software does with that data. Displaying raw data generally is not SaMD. Interpreting that data to produce a clinical recommendation is what changes its status.

How SaMD is regulated in Indonesia

In Indonesia, SaMD is regulated under the same medical device framework as hardware, classified by risk level through the Ministry of Health. This means digital health developers are often surprised at how similar the evaluation process is to hardware, including the need for a technical dossier and clinical evidence.

How SaMD is regulated globally

FDA (United States) - uses a risk classification framework based on function and the level of clinical decision impact the software produces.

HSA (Singapore) - adopts a function and intended-use based approach in line with FDA principles, adapted for local regulatory context.

European Union (EU MDR) - places medical software under the same medical device regulatory framework, with emphasis on ongoing risk documentation, including for software that receives continuous updates.

One challenge emerging across jurisdictions: AI algorithms that keep learning from new data change after receiving market authorization, and regulators in various countries are still working out mechanisms for handling post-market model updates.

When your health software needs an Izin Edar in Indonesia

Map your software's function against these questions:

• Does the software give clinical recommendations or support a diagnostic decision? Likely SaMD;
• Does it only display or store data without clinical interpretation? Likely not SaMD.
• Does it calculate a risk score or trigger a specific medical action? Likely SaMD.

Mistakes we see often

Product teams often only think about their software's regulatory status after the product is built, not at the design stage. A feature originally meant to just "help" the user can shift the entire regulatory pathway if it turns out to influence a clinical decision, including adding significant technical dossier requirements.

Conclusion

SaMD is a category assessed by function, not form. Both in Indonesia and globally, regulators apply this principle consistently, even as implementation details differ. For digital health product teams, mapping software function at the design stage is far cheaper than adjusting after the product is built.

If you are developing health software and are not sure whether your product falls under SaMD, we can help check from the regulatory side. Reach us at info@derayglobalutama.com. info@derayglobalutama.com.