SaMD vs SiMD: Software como Dispositivo Médico sob FDA e EU MDR

TL;DR

O Software como Dispositivo Médico (SaMD) é um software que desempenha uma finalidade médica sem fazer parte de um dispositivo médico de hardware. O Software em Dispositivo Médico (SiMD) é um software que aciona ou está integrado a um dispositivo de hardware. A definição internacional provém do Fórum Internacional de Reguladores de Dispositivos Médicos (IMDRF). Ele define SaMD como "software destinado a ser utilizado para uma ou mais finalidades médicas que desempenha essas finalidades sem fazer parte de um dispositivo médico de hardware." ¹

Essa distinção determina como o software é classificado e submetido. Na UE, o SaMD é classificado por direito próprio, principalmente sob a Regra 11 do MDR. O software que aciona um dispositivo assume a classe desse dispositivo. Nos EUA, a FDA autoriza funções de software de dispositivos por meio de 510(k), De Novo ou PMA. A lista de dispositivos habilitados para IA da FDA demonstra esse padrão. Dos 1.614 dispositivos da lista, 96,2% chegaram ao mercado por meio de 510(k). O número autorizado por ano cresceu de 18 em 2016 para 335 em 2025. ²

2026 trouxe várias mudanças. A FDA revisou seus guias sobre suporte à decisão clínica e bem-estar geral em janeiro e seu guia de cibersegurança em fevereiro. A UE adiou para 2 de agosto de 2028 as obrigações de alto risco do AI Act para dispositivos médicos habilitados para IA. Este guia explica as definições, como identificar se um software é, de fato, um dispositivo médico, como a FDA e a UE o classificam, o que compõe uma submissão e como outros mercados importantes o tratam.

SaMD, SiMD e MDSW: o que significa cada termo

SaMD é um termo definido. SiMD é um rótulo descritivo sem uma definição legal vinculante. A UE utiliza um terceiro termo, MDSW, que abrange ambos.

O IMDRF é explícito quanto ao limite: "O software não atende à definição de SaMD se a sua finalidade pretendida for acionar um dispositivo médico de hardware." Afirma também que "aplicativos móveis que atendem à definição acima são considerados SaMD." A política de 2022 da FDA sobre funções de software de dispositivos estabelece que elas "podem incluir 'Software como Dispositivo Médico (SaMD)' e 'Software em Dispositivo Médico (SiMD)'." ³

Na UE, o documento MDCG 2019-11 Rev.1 substitui "software autônomo" por MDSW e observa que o termo antigo "não é mais utilizado no contexto dos Regulamentos de Dispositivos Médicos." A regra de aplicação 3.3 do MDR estabelece a consequência para a classificação: "O software que aciona um dispositivo ou influencia o uso de um dispositivo deve pertencer à mesma classe do dispositivo. Se o software for independente de qualquer outro dispositivo, deve ser classificado por direito próprio." ^{4 5}

O TGA da Austrália descreve o SiMD nos termos mais práticos. Esse software é "geralmente fornecido pré-instalado com o dispositivo de hardware" e "o SiMD é regulamentado como parte do dispositivo no qual está instalado." ⁶

Primeira pergunta: o software é, de fato, um dispositivo médico?

Muitos softwares de saúde não são dispositivos médicos. A finalidade pretendida e, nos EUA, cinco exclusões legais determinam isso.

Nos EUA, a seção 520(o) do FD&C Act, incluída pelo 21st Century Cures Act, exclui cinco tipos de funções de software da definição de dispositivo:

• suporte administrativo;
• manutenção ou incentivo a um estilo de vida saudável, sem relação com doenças;
• prontuários eletrônicos de pacientes, a menos que a função os interprete ou analise;
• transferência, armazenamento, conversão ou exibição de dados, a menos que interprete ou analise esses dados;
• determinado suporte à decisão clínica (CDS). ⁷

A exclusão de CDS aplica-se apenas quando o software não analisa imagens ou sinais médicos. O software deve exibir ou analisar informações médicas, apoiar a recomendação de um profissional de saúde e permitir que esse profissional revise de forma independente a base para tal recomendação.

A FDA revisou duas políticas fundamentais em janeiro de 2026:

• Suporte à decisão clínica. O guia foi republicado em 6 de janeiro de 2026 e corrigido em 29 de janeiro de 2026. O software que fornece uma diretriz específica de diagnóstico ou tratamento não atende ao terceiro critério. Nos casos em que apenas uma opção é clinicamente apropriada e o software atende aos demais critérios, a FDA pretende exercer discricionariedade na fiscalização. O software que fornece recomendações a pacientes ou cuidadores, e não a profissionais de saúde, continua sendo um dispositivo. ⁸
• Bem-estar geral. A política revisada de 6 de janeiro de 2026 afirma que a FDA "pode considerar determinados produtos que utilizam detecção não invasiva" para estimar parâmetros fisiológicos, como pressão arterial, saturação de oxigênio ou glicose, como produtos de bem-estar geral. Isso se aplica apenas sob certas condições. O produto deve ser não invasivo, não deve substituir um dispositivo autorizado pela FDA e não deve fornecer saídas que motivem uma ação clínica específica. ⁹

Na UE, o documento MDCG 2019-11 Rev.1 estabelece um fluxo de decisão. O software para "fins gerais, mesmo quando utilizado em um ambiente de saúde" ou para "fins de estilo de vida e bem-estar" não é um dispositivo nos termos do considerando 19 do MDR. O software que cria ou modifica informações médicas para um paciente individual geralmente é. A revisão de junho de 2025 enfatiza uma finalidade pretendida claramente redigida e o software modular, no qual apenas alguns módulos se qualificam.

Como o SaMD é classificado por risco

A estrutura do IMDRF é a linguagem comum. Cada autoridade reguladora a converte, então, em suas próprias classes legais.

A estrutura do IMDRF no N12 categoriza o SaMD segundo dois fatores. O primeiro é o estado da situação de saúde: crítica, grave ou não grave. O segundo é a relevância da informação para a decisão em saúde: tratar ou diagnosticar, direcionar a conduta clínica ou informar a conduta clínica. ¹⁰

O IMDRF adverte que esta "não é uma classificação regulatória". Em janeiro de 2025, publicou o N81, que complementa o N12 com considerações de risco específicas para software para todos os softwares de dispositivos médicos, incluindo softwares que fazem parte de hardware. ¹¹

A Regra 11 do MDR da UE transforma a mesma lógica em lei:

"O software destinado a fornecer informações utilizadas para tomar decisões com finalidades diagnósticas ou terapêuticas é classificado na classe IIa, exceto se tais decisões tiverem um impacto que possa causar: — a morte ou uma deterioração irreversível do estado de saúde de uma pessoa, caso em que é classificado na classe III; ou — uma deterioração grave do estado de saúde de uma pessoa ou uma intervenção cirúrgica, caso em que é classificado na classe IIb. O software destinado a monitorar processos fisiológicos é classificado na classe IIa, exceto se for destinado ao monitoramento de parâmetros fisiológicos vitais, em que a natureza das variações desses parâmetros seja tal que possa resultar em perigo imediato para o paciente, caso em que é classificado na classe IIb. Todos os demais softwares são classificados na classe I."

O MDCG 2019-11 Rev.1 inclui uma tabela ilustrativa que mapeia as categorias do IMDRF para as classes do MDR. Excluindo a Classe I, as situações críticas são mapeadas para a Classe III (tratar ou diagnosticar), IIb (direcionar) e IIa (informar). As situações graves são mapeadas para IIb, IIa e IIa, e as não graves para IIa em todos os casos. Devido à Regra 11, a maioria dos SaMDs de suporte à decisão na UE necessita de um organismo notificado. A proposta da Comissão Europeia de dezembro de 2025 para revisar o MDR e o IVDR reescreveria a Regra 11 em torno da matriz do IMDRF. Essa proposta ainda está pendente, portanto a atual Regra 11 permanece aplicável. ¹² Para o sistema completo de classes da UE, consulte nosso guia de classificação do EU MDR.

Nos EUA, o software é classificado como qualquer outro dispositivo: por código de produto e regulamento de classificação. A maior parte dos SaMDs enquadra-se na Classe II. Softwares de processamento de imagens radiológicas (código de produto QIH, 21 CFR 892.2050) e softwares radiológicos de triagem e notificação assistidos por computador (QAS, 21 CFR 892.2080) são típicos. Nosso guia de classificação da FDA explica como encontrar o código correto.

O que mostram os dados de mercado dos EUA

O software habilitado por IA é a parcela que mais cresce entre as autorizações de dispositivos da FDA, e quase a totalidade passa por 510(k).

A lista de dispositivos médicos habilitados por IA da FDA continha 1.614 registros em sua atualização de setembro de 2026, com decisões finais até 29 de junho de 2026. Desses, 1.553 (96,2%) foram liberações 510(k), 40 foram concessões De Novo e 21 foram aprovações PMA. A radiologia foi o principal painel de análise para 1.230 deles (76,2%), seguida pela área cardiovascular (154) e pela neurologia (73). A FDA observa que a lista "não é um recurso abrangente de dispositivos médicos habilitados por IA".

Uma segunda medição provém da análise da Pure Global sobre a exportação 510(k) do openFDA. As liberações sob códigos de produto cujo nome de dispositivo na FDA inclui "software" aumentaram de 7 em 2016 para 187 em 2025, de 0,2% para 5,8% de todas as liberações 510(k). Em 2025, 94 dessas 187 eram softwares de processamento automatizado de imagens radiológicas (QIH). ¹³ Isso subestima a contagem de SaMDs, porque muitos dispositivos de software enquadram-se em códigos de produto sem "software" no nome. Ainda assim, trata-se de uma linha de tendência consistente.

O que a FDA espera em uma submissão de SaMD

A via de submissão é a mesma que para hardware. A documentação é específica para software, e quatro guias a estruturam.

1. Nível de documentação de software. O guia de junho de 2023 da FDA substituiu o antigo "nível de preocupação" por dois níveis de documentação. A Documentação Aprimorada aplica-se "quando uma falha ou defeito de qualquer função de software do dispositivo puder apresentar uma situação perigosa com risco provável de morte ou lesão grave". A avaliação é feita antes da aplicação dos controles de risco. Caso contrário, aplica-se a Documentação Básica. ¹⁴
2. Cibersegurança. A Seção 524B do FD&C Act, em vigor desde 29 de março de 2023, aplica-se a "dispositivos cibernéticos". Esses são dispositivos que incluem software, podem se conectar à internet e podem ser vulneráveis a ameaças de cibersegurança. As submissões devem incluir um plano de monitoramento de vulnerabilidades, processos de atualização e correção e uma lista de componentes de software. ¹⁵ O guia de cibersegurança da FDA foi revisado pela última vez em 3 de fevereiro de 2026 para se alinhar ao QMSR. ¹⁶
3. Planos de controle de mudanças predeterminados (PCCPs). A Seção 515C permite que a FDA autorize previamente modificações futuras planejadas, de modo que alterações feitas dentro do plano não exijam uma nova submissão. O guia de PCCP da FDA para funções de software de dispositivos habilitados por IA foi finalizado em 4 de dezembro de 2024 e revisado em 18 de agosto de 2025. Ele abrange 510(k), De Novo e PMA. ¹⁷ Um guia geral de PCCP para todos os dispositivos ainda é uma minuta de agosto de 2024. ¹⁸
4. Ciclo de vida de IA. A minuta de guia da FDA de 7 de janeiro de 2025 sobre funções de software de dispositivos habilitados por IA estabelece recomendações para o ciclo de vida e para submissões de comercialização. Elas cobrem gerenciamento de dados, descrição do modelo, validação de desempenho, viés, transparência e monitoramento pós-mercado. O documento ainda era uma minuta em outubro de 2026. ¹⁹ A FDA também solicitou comentários até 19 de outubro de 2026 sobre um documento de discussão sobre IA generativa. ²⁰

Sob o QMSR, projeto e desenvolvimento (cláusula 7.3 da ISO 13485) aplica-se a todos os dispositivos de Classe II e III e aos dispositivos de Classe I automatizados com software. A validação de software, portanto, faz parte do sistema da qualidade, bem como da submissão. Consulte nossa tabela de correspondência do 21 CFR 820 para a ISO 13485.

Requisitos da UE além da Regra 11

• Evidência clínica. O MDCG 2020-1 solicita três componentes para todo MDSW: associação clínica válida (validade científica), desempenho técnico ou analítico e desempenho clínico. Esses componentes seguem o IMDRF N41. ²¹
• Requisito geral de segurança e desempenho 17. O Anexo I exige que o software seja desenvolvido "em conformidade com o estado da arte, levando em consideração os princípios do ciclo de vida de desenvolvimento, gerenciamento de risco, incluindo segurança da informação, verificação e validação."
• O AI Act. O Regulamento (UE) 2024/1689 considera de alto risco os sistemas de IA em dispositivos médicos que necessitam de avaliação de conformidade por um organismo notificado. O Digital Omnibus, Regulamento (UE) 2026/1744, publicado no Jornal Oficial em 24 de julho de 2026, transferiu essas obrigações para 2 de agosto de 2028. ²² O MDCG 2025-6 explica como o MDR e o AI Act interagem. O documento declara que o AI Act "não afeta a classificação de risco de dispositivos médicos". Sua referência a uma data em agosto de 2027 é anterior ao Omnibus. ²³

Como outros grandes mercados tratam o SaMD

Fontes: ²⁴, ²⁵ e ²⁶. Para acesso ao mercado específico de IA em mais de 30 países, consulte nosso relatório de pesquisa sobre IA como dispositivo médico.

As normas por trás de um dossiê de SaMD

• IEC 62304:2006+A1:2015 estabelece os processos do ciclo de vida do software e as classes de segurança de software A, B e C. A Edição 2 ainda é uma minuta de comitê, e a IEC prevê a publicação em outubro de 2028. Planeje com base na versão consolidada de 2015. ²⁷
• IEC 82304-1:2016 abrange produtos de software de saúde executados em plataformas de computação de uso geral sem hardware dedicado, o que é típico para SaMD. ²⁸
• IEC 81001-5-1:2021 estabelece as atividades de segurança ao longo do ciclo de vida do software de saúde. ²⁹
• O gerenciamento de risco da ISO 14971 e a engenharia de usabilidade da IEC 62366-1 aplicam-se ao SaMD como a qualquer dispositivo. Nosso guia de ISO 14971 abrange o dossiê de risco.

SaMD versus SiMD: o que muda no seu dossiê

Erros comuns

• Redigir a finalidade pretendida por último. A classificação, a evidência clínica e o status de bem-estar ou CDS decorrem todos dela. Redija-a primeiro e mantenha as alegações de marketing dentro dela.
• Presumir que "suporte à decisão" signifique "não é um dispositivo". Nos EUA, todos os quatro critérios de CDS devem ser atendidos. Na UE, a Regra 11 enquadra a maioria dos softwares de suporte à decisão na Classe IIa ou superior.
• Tratar um aplicativo móvel como uma categoria inferior. Um aplicativo que atende à definição de SaMD é SaMD.
• Citar o antigo "nível de preocupação". A FDA o substituiu por Documentação Básica e Aprimorada em junho de 2023.
• Planejar com base na data de 2027 do AI Act. As obrigações de alto risco para dispositivos médicos habilitados por IA aplicam-se agora a partir de 2 de agosto de 2028.
• Lançar atualizações de algoritmos sem um plano. Sem um PCCP, uma alteração significativa geralmente exige uma nova submissão.

Como a Pure Global ajuda

Determinamos se o software é um dispositivo e redigimos a finalidade pretendida. Classificamos o software segundo a FDA, a Regra 11 do MDR da UE e outros sistemas, e preparamos dossiês de 510(k) e De Novo com documentação Básica ou Aprimorada, segurança cibernética e conteúdo de PCCP. Nossa equipe também oferece suporte a submissões a organismos notificados da UE e a registros em mais de 30 mercados. Consulte nossa página de regulamentação de SaMD ou entre em contato com nossa equipe.

Como construímos os números

• Dispositivos habilitados por IA: nossa contagem da lista de dispositivos médicos habilitados por IA da FDA (CSV), conforme atualizada em setembro de 2026. As decisões vão até 29 de junho de 2026, e 2026 é um ano parcial. A participação das vias de submissão provém do prefixo do número de submissão (K, DEN ou P).
• Códigos de produto com software no nome: códigos de produto no arquivo de códigos de produto da FDA datado de 12 de outubro de 2026 cujo nome do dispositivo contém "software", cruzados com a exportação de 510(k) do openFDA datada de 12 de outubro de 2026. A Pure Global mantém ambos em seu data lake. As contagens são por ano civil da decisão.