Indonésia KMK 951/2026: Registro de Dispositivos Médicos de Software

O Ministro da Saúde da Indonésia publicou o Decreto nº HK.01.07/MENKES/951/2026 sobre a Diretriz para Autorização de Comercialização de Dispositivos Médicos Baseados em Software (Kepmenkes/KMK 951/2026). O decreto foi assinado em 7 de setembro de 2026 e entrou em vigor no mesmo dia. Ele adota a diretriz em seu anexo como a referência (acuan) para o governo, empresas de dispositivos médicos e outras partes interessadas que lidam com a autorização de comercialização (izin edar) de dispositivos baseados em software. A diretriz descreve a si mesma como uma explicação técnica dos requisitos e procedimentos para autorização de comercialização. Onde este artigo diz "deve", a própria diretriz utiliza redação obrigatória (wajib ou harus) ou lista o item entre as obrigações do titular (kewajiban). O decreto não contém disposições transitórias para produtos que já estejam registrados ou tenham solicitações sob análise.

Escopo

A diretriz abrange três grupos de produtos:

• Software as a Medical Device (SaMD): software autônomo com finalidade médica que não faz parte do hardware de um dispositivo médico. Isso inclui software para dispositivos médicos para diagnóstico in vitro (IVD) e software executado em plataformas de uso geral, como computadores, tablets e smartphones. O software que apenas aciona ou controla outro dispositivo médico não é SaMD. Os exemplos da diretriz são um aplicativo de monitoramento de glicose, um algoritmo que prevê o risco de ataque cardíaco a partir de dados digitais de ECG, software de visualização de raios X em uma estação de trabalho de uso geral e um aplicativo de monitoramento remoto de sinais vitais.
• Software in a Medical Device (SiMD): software incorporado a um dispositivo que oferece suporte à sua operação. Suas funções incluem, entre outras, operar ou controlar o dispositivo, alterar seu estado ou produzir resultados relacionados à sua função de hardware. De acordo com o fluxograma de classificação da diretriz, o SiMD é registrado como um acessório do dispositivo principal, e seus requisitos e classe de risco seguem esse dispositivo. Os exemplos da diretriz são processamento de sinais em scanners de MRI ou CT, automação de ventiladores, software de imagens de ultrassom e software de estimulação ou desfibrilação em marca-passos e ICDs.
• Dispositivos médicos com aplicações de inteligência artificial: a IA, incluindo aprendizado de máquina, processamento de linguagem natural e grandes modelos de linguagem (LLMs), é um dispositivo médico apenas quando tem uma finalidade médica. Os resultados de IA generativa, como imagens, texto, áudio ou vídeo, estão no escopo quando se destinam a diagnóstico, monitoramento, decisões terapêuticas ou cuidados ao paciente. A IA utilizada apenas para gerenciamento de dados administrativos, armazenamento ou outras funções operacionais que não afetam a função do dispositivo está excluída.

O mesmo fluxograma considera o software como não sendo um dispositivo médico quando ele apenas armazena, arquiva, comunica, realiza pesquisas simples ou aplica compressão sem perdas, ou quando não atua sobre dados específicos de um paciente individual. O software que atua sobre dados específicos de pacientes também não é um dispositivo médico segundo o fluxograma se não desempenhar nenhuma das funções listadas: aquisição, processamento ou análise de sinais, dados de IVD, MRI, NGS, CGM ou de detecção/diagnóstico auxiliado por computador; exibição, análise ou impressão de sinais contínuos, imagens médicas ou formas de onda de ECG; ou fornecimento de pontuações de risco de doenças, probabilidades ou saídas em tempo crítico.

Fabricação, distribuição e sistema de qualidade

A produção é realizada por um fabricante de dispositivos médicos, que deve possuir uma licença comercial indonésia sob o código KBLI relevante e cumprir as Boas Práticas de Fabricação de dispositivos médicos (CPB). A distribuição é realizada por um distribuidor de dispositivos médicos ou sua filial, que deve possuir uma licença comercial e cumprir as Boas Práticas de Distribuição (CDB). Tanto fabricantes quanto distribuidores devem aplicar um sistema de gestão da qualidade. A diretriz descreve um sistema de gestão da qualidade eficaz como aquele que inclui o controle de processos terceirizados, incluindo software comercial de prateleira (COTS), com o detentor do produto permanecendo responsável pela segurança e pelo desempenho.

Para a implementação do sistema de gestão da qualidade, a diretriz lista normas que podem ser usadas como referências, sem edições. Elas incluem ISO 13485, ISO 14971, IEC 60601-1 e IEC 61010-1 (que o decreto rotula como normas ISO), IEC 62366-1, IEC 62304, IEC 82304, IEC 63450, IEC 63521 e ISO 27001.

Documentos de registro

Verificação e validação de software. Esses documentos devem seguir o ciclo de vida de desenvolvimento de software conforme a IEC 62304 ou uma norma reconhecida equivalente. No mínimo, eles devem abranger a versão do software, rastreabilidade, controle de alterações, interoperabilidade e cibersegurança. Se a versão testada for diferente da versão submetida, o solicitante deverá fornecer uma comparação de versões com justificativa. Validação adicional é necessária quando houver alterações significativas que possam afetar a segurança, o desempenho ou a finalidade de uso. A versão do software comercializada deve constar no rótulo do dispositivo e/ou na interface do software.

Software conectado. O software conectado a outros dispositivos, sistemas externos, redes ou à internet necessita de mais informações no dossiê. Deve descrever mecanismos de troca de dados que protejam a confidencialidade, integridade e disponibilidade, juntamente com a identificação de vulnerabilidades, análise de risco, mitigação e evidências de que os controles são eficazes.

Gerenciamento de risco. O gerenciamento de risco deve ocorrer durante todo o ciclo de vida do software, com referência a normas como a ISO 14971. Cada alteração no software deve ser avaliada quanto a riscos adicionais.

Dispositivos de IA e aprendizado de máquina. Projeto, desenvolvimento, validação, implantação e qualquer treinamento ou retreinamento de modelos de IA devem ocorrer dentro do sistema de gestão da qualidade. A Tabela 3.1 da diretriz estabelece o que um dossiê de IA/ML deve conter:

Dispositivos que utilizam aprendizado de máquina contínuo também devem documentar como as alterações do modelo são controladas para que não afetem a segurança, o desempenho ou a finalidade de uso. Essa documentação abrange frequência de atualizações, detecção e mitigação de anomalias, tratamento de dados de mundo real, integridade do conjunto de dados, controle de versão com reversão (rollback) para um algoritmo anterior, rastreabilidade entre dados, treinamento e resultados, e uma estratégia de validação contínua. Dispositivos que utilizam modelos generativos ou LLMs também devem descrever controles de saída, mitigação de alucinações, limites de uso e como a consistência e a acurácia das informações médicas geradas por eles são avaliadas durante a adaptação contínua.

Evidência clínica

A evidência clínica pode consistir em qualquer um dos seguintes:

• uma revisão da literatura e diretrizes de prática clínica relevantes;
• uma comparação com software similar já no mercado, onde houver;
• resultados de ensaios clínicos, especialmente para respaldar novas alegações ou alterações significativas na função clínica.

Os ensaios clínicos pré-mercado dependem do risco do dispositivo e de quão significativa é a sua informação para as decisões clínicas. A diretriz classifica a evidência clínica como bem estabelecida ou inovadora, e essa classe é usada como base para decidir se evidências adicionais são necessárias. A evidência deveria ser escolhida de maneira proporcional e sem ônus indevido. Para softwares de alto risco, a avaliação clínica pode necessitar de revisão independente. A validação analítica e a validação clínica são obrigatórias para todos os dispositivos baseados em software. A validação clínica ocorre tanto antes quanto depois da comercialização. Uma nova finalidade de uso ou uma nova população-alvo exige que a avaliação clínica seja repetida.

A diretriz introduz a Tabela 3.2 como evidência clínica recomendada, embora o próprio título da tabela a denomine como a evidência clínica "necessária" para a autorização de comercialização. Ela é organizada pela gravidade da situação de saúde e pela relevância das informações do software para a decisão em saúde:

A gravidade da situação não altera a evidência listada; apenas a relevância das informações o faz.

Validação clínica local para determinados softwares importados

Determinados dispositivos baseados em software importados necessitam de validação clínica local na Indonésia. Sua finalidade é demonstrar que o software gera resultados clinicamente significativos para a população-alvo indonésia. Isso se aplica a softwares importados que:

• tenham sido desenvolvidos adicionalmente e/ou retreinados utilizando dados que representem a população indonésia; e/ou
• utilizem IA com nível de risco moderado a alto, em particular para diagnóstico, triagem ou tomada de decisão clínica.

A validação pode ocorrer em:

• hospitais, universidades ou laboratórios acreditados;
• unidades técnicas do Ministério da Saúde responsáveis pela segurança de equipamentos e instalações de saúde, ou por serviços de genômica biomédica e da saúde.

A unidade biomédica e de genômica pode fornecer orientação aos demais centros onde necessário. A validação pode tramitar em paralelo com a solicitação de autorização de comercialização se as evidências clínicas e de desempenho do fabricante estiverem anexadas. Os resultados devem ser submetidos no prazo máximo de um ano após a emissão da autorização de comercialização. Durante a validação, o produto pode ser utilizado de modo limitado para avaliação ou sob acordos específicos, desde que a segurança do paciente não seja colocada em risco. Se os resultados divergirem significativamente das evidências clínicas originais, medidas administrativas poderão ser adotadas segundo as regulamentações aplicáveis. A diretriz estabelece que a validação local deveria ser eficiente, proporcional e baseada em risco, e não deveria constituir obstáculo ao acesso à inovação.

Sandbox regulatório e maturidade tecnológica

Para softwares que careçam de evidências clínicas adequadas de acurácia, precisão de interpretação, segurança ou desempenho na população indonésia, a empresa poderá conduzir seu próprio ensaio clínico de acordo com a diretriz de ensaios clínicos para dispositivos médicos. Alternativamente, poderá realizar testes limitados por meio de um sandbox regulatório sob as regulamentações aplicáveis. A mesma seção estabelece que os produtos de inovação em saúde digital que pleitearem autorização de comercialização como dispositivos médicos devem ter atingido o Nível de Maturidade Tecnológica (TKT) 9. O TKT 9 significa que foi comprovado que o sistema opera com sucesso em seu ambiente operacional real, em conformidade com a sua finalidade de uso. A diretriz não define "produto de inovação em saúde digital" nem informa se esse requisito se aplica além dos produtos de sandbox.

Rotulagem

A rotulagem pode assumir a forma de rótulo, instruções de uso, guia de operação ou outras informações pertinentes. No mínimo, deve identificar o nome do produto, o número da versão do software e o detentor do produto. Também deve declarar a finalidade de uso, instruções, informações de desempenho e informações de segurança, incluindo advertências, de forma clara. Softwares fornecidos em mídia física (CD, DVD ou USB) necessitam de rótulo físico e instruções de uso, impressas ou disponibilizadas por meio de link. Softwares disponibilizados por download ou baseados na web devem ser registrados com capturas de tela da interface, como tela de apresentação (splash screen) ou folheto, que exibam os elementos de identificação e o número da versão. Os usuários também devem receber o link para download, o procedimento de download, o guia de instalação e o procedimento operacional.

Alterações pós-aprovação

A diretriz divide as alterações em um dispositivo baseado em software aprovado em duas categorias, além de uma regra subsidiária:

Toda alteração deve ser documentada no sistema de gestão da qualidade.

Obrigações do titular da autorização de comercialização

O titular deve observar princípios éticos para dispositivos baseados em software:

• inclusão e não discriminação;
• segurança e proteção;
• humanidade;
• acessibilidade;
• transparência;
• credibilidade e responsabilização;
• proteção de dados pessoais;
• sustentabilidade;
• propriedade intelectual.

Incidentes de proteção de dados devem ser notificados sob as regulamentações aplicáveis. Para dispositivos com IA/ML, as Boas Práticas de Aprendizado de Máquina (GMLP) são obrigatórias segundo dez princípios. Eles se estendem desde a finalidade de uso e expertise multidisciplinar até o monitoramento pós-mercado e gerenciamento de mudanças, incluindo os riscos de atualizações e retreinamento. Para softwares de IA/ML, a gestão de dados deve seguir princípios que incluem:

• segurança e privacidade dos dados dos pacientes;
• transparência e responsabilização dos recursos de IA;
• minimização de dados;
• retenção e exclusão com base no consentimento do paciente;
• armazenamento em nuvem com elevados padrões de segurança;
• política de notificação de incidentes e violações de dados;
• mitigação de ameaças cibernéticas.

O titular também deve se comprometer a garantir que os dados de saída do software possam ser integrados ao Sistema Nacional de Informações em Saúde (SIKN) ou SATUSEHAT. Se integrado, o produto deve ser projetado como um sistema aberto, suportar os padrões de interoperabilidade aplicáveis e ser capaz de se conectar à plataforma nacional de troca de dados em saúde.

Supervisão pós-mercado

O Ministro supervisiona os dispositivos baseados em software. Uma das vias são os relatórios das empresas, que incluem:

• gestão de reclamações, abrangendo eventos adversos e ações corretivas de segurança de campo (FSCAs);
• monitoramento técnico, abrangendo vulnerabilidades de cibersegurança;
• validação de desempenho clínico pós-mercado utilizando dados relevantes, incluindo dados de mundo real.

Onde o monitoramento evidenciar um risco, a ação corretiva pode incluir alertas de segurança e/ou recolhimento de produto. Os registros de monitoramento devem ser mantidos disponíveis para a supervisão. A supervisão também inclui inspeções de campo de rotina uma vez ao ano e inspeções extraordinárias quando necessário.

O que isso significa para os fabricantes

Análise da Pure Global:

• Classifique o software primeiro. Utilize o fluxograma da diretriz para decidir se o software é SiMD, SaMD ou se não é um dispositivo médico. O SiMD é registrado como acessório do dispositivo principal e segue seus requisitos e classe de risco. A diretriz em si não define regras de classe de risco para SaMD.
• Mapeie o SaMD na tabela de evidências clínicas. A Tabela 3.2 utiliza os mesmos dois eixos da estrutura de categorização de risco de SaMD do IMDRF (N12): o estado da situação de saúde e a relevância da informação. O fabricante que já tenha categorizado seu software sob o N12 pode verificar onde ele se posiciona. O ensaio clínico está listado apenas na coluna "tratar ou diagnosticar". A necessidade de um ensaio também depende do fato de a evidência ser bem estabelecida ou inovadora, e de quaisquer novas alegações clínicas.
• IA de risco moderado a alto importada (especialmente para diagnóstico, triagem ou decisões clínicas): planeje a validação clínica local antes do lançamento. Ela pode tramitar em paralelo com a solicitação, mas o prazo de um ano começa a contar a partir da emissão da autorização de comercialização; portanto, providencie os centros e o acesso aos dados com antecedência. A diretriz não informa quais classes de risco são consideradas de moderadas a altas, portanto confirme isso com o Ministério. Para qualquer software importado, o desenvolvimento adicional ou o retreinamento com dados representativos da população indonésia constitui, por si só, um critério para validação local.
• Gerenciamento de versões: adicione uma avaliação de impacto para a Indonésia ao processo de liberação de software. Alterações de algoritmo que afetem a função diagnóstica ou terapêutica ou o desempenho clínico, a inclusão ou remoção de alarmes que afetem o manejo do paciente e alterações no sistema operacional ou na infraestrutura que possam afetar o desempenho ou a segurança exigem uma nova autorização de comercialização, e não uma alteração da existente. Toda alteração deve ser documentada no sistema de gestão da qualidade, e a versão deve constar no rótulo e/ou na interface. Registrar uma categoria de alteração indonésia para cada versão, portanto, vincula a via regulatória à versão que os usuários visualizam.
• Desenvolvimento e ciclo de vida de IA: os dez princípios de GMLP que o titular deve aplicar acompanham os dez princípios orientadores do documento de GMLP do IMDRF (N88, 2025), embora o decreto não cite o N88. O trabalho de GMLP realizado para outros mercados é um ponto de partida razoável, mas o decreto não especifica como a conformidade deve ser comprovada. Os conjuntos de dados devem representar a população de pacientes pretendida, e a validação local e o sandbox referem-se ao desempenho na população indonésia. Espere questionamentos sobre a representatividade indonésia.
• Produtos já registrados ou em análise: o decreto entrou em vigor em 7 de setembro de 2026 e não possui disposição transitória. Confirme com o Ministério da Saúde como ele se aplica a solicitações pendentes e à próxima alteração ou revalidação de registros existentes. Não presuma que a documentação anterior continue sendo suficiente.

A página de mercado da Indonésia da Pure Global aborda a via geral de registro. Nossa pesquisa sobre IA como dispositivo médico e acesso ao mercado global compara a forma como outros órgãos reguladores tratam os softwares de IA.