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.<\/p>\n\n\n\n
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 \u2022 \u2022 \u2022 starts giving clinical recommendations, calculating risk, or supporting a diagnostic decision, it falls under this category.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
FDA (United States)<\/strong> - uses a risk classification framework based on function and the level of\nclinical decision impact the software produces.<\/p>\n\n\n\n HSA (Singapore)<\/strong> - adopts a function and intended-use based approach in line with FDA\nprinciples, adapted for local regulatory context.<\/p>\n\n\n\n European Union (EU MDR)<\/strong> - places medical software under the same medical device\nregulatory framework, with emphasis on ongoing risk documentation, including for software\nthat receives continuous updates.<\/p>\n\n\n\n One challenge emerging across jurisdictions: AI algorithms that keep learning from new data\nchange after receiving market authorization, and regulators in various countries are still working\nout mechanisms for handling post-market model updates.<\/p>\n\n\n\n Map your software's function against these questions:<\/p>\n\n\n\n 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\nregulatory pathway if it turns out to influence a clinical decision, including adding significant\ntechnical dossier requirements.<\/p>\n\n\n\n SaMD is a category assessed by function, not form. Both in Indonesia and globally, regulators\napply 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.<\/p>\n\n\n\n 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<\/a>.<\/p>\n\n\n\nWhen your health software needs an Izin Edar in Indonesia<\/h2>\n\n\n\n
\n
Mistakes we see often<\/h2>\n\n\n\n
Conclusion<\/h2>\n\n\n\n