Software para dispositivo médico: o que exigir de quem desenvolve

Software para a saúde e software para dispositivo médico são produtos diferentes, mesmo quando o código parece o mesmo. No primeiro, o cliente compra uma funcionalidade. No segundo, ele compra a funcionalidade e a prova de como ela foi feita, porque essa prova vai para dentro do processo dele na ANVISA, na FDA ou no organismo notificado europeu: como cada função foi especificada, que risco ela introduz, como foi verificada e onde isso está escrito.

Essa diferença muda o que um fabricante de equipamento médico, uma healthtech ou uma rede de clínicas deve exigir de quem desenvolve. E muda também o perfil de quem está do outro lado da mesa. Por isso a X-Apps investe na formação dos seus colaboradores para esse setor, e a equipe que conduz os projetos de saúde tem certificação no curso Introduction to SaMD, IEC 62304 and IEC 82304-1, da Medical Device HQ, com 21 horas de formação continuada. Este artigo explica o que esse certificado representa, onde passa a linha regulatória e o que pedir de um fornecedor antes de assinar.

O que o certificado em SaMD, IEC 62304 e IEC 82304-1 representa

As três siglas do nome do curso respondem a três perguntas diferentes, e são exatamente as perguntas que um comprador desse setor precisa fazer.

SaMD, de Software as a Medical Device, responde "esse software é, por si só, um dispositivo médico?". É o conceito que define se um produto entra ou não no regime sanitário, e o erro de enquadramento, para qualquer lado, é o mais caro de todos.

IEC 62304 responde "como desenvolver e manter esse software de forma controlada?". É a norma de ciclo de vida de software de dispositivo médico, a que a ANVISA cita por nome na RDC 657/2022 e a que a FDA aceita como declaração de conformidade nas submissões. Ela organiza planejamento, requisitos, arquitetura, implementação, verificação, liberação, manutenção, gerenciamento de configuração e resolução de problemas.

IEC 82304-1 responde "o produto de software completo é seguro para o uso pretendido?". Publicada em 2016, trata da segurança do produto de software de saúde que roda em plataforma de uso geral e vai ao mercado sem hardware dedicado, cobrindo o ciclo inteiro, da concepção ao descarte.

O fornecedor do curso declara três objetivos: saber criar software de alta qualidade, saber criar software seguro e saber gerenciar software de forma que agregue valor. Na prática, é a formação que permite a quem conduz um projeto ler uma instrução de uso, enquadrar o software, planejar a documentação que a norma pede e conversar com a área de qualidade do fabricante na língua dela.

Vale ser preciso sobre o que isso prova. Um certificado prova que o profissional foi formado para trabalhar dentro desse processo. Ele não certifica a empresa em norma alguma e não certifica o produto; a conformidade do produto é sempre demonstrada pelo fabricante, com evidência. Mas é justamente a evidência que o fornecedor produz, e produzi-la bem exige alguém que conheça a norma antes da primeira linha de código. Ter esse conhecimento dentro da equipe, e não terceirizado para um consultor externo, é o que separa um fornecedor que entrega código de um fornecedor que entrega o que vai para o dossiê.

Sistema de clínica não é dispositivo médico, e é aqui que a maioria erra

O mercado brasileiro de dispositivos médicos movimenta cerca de R$ 75 bilhões e está entre os dez maiores do mundo, segundo levantamento da Redirection International publicado pela Medicina S/A em fevereiro de 2026. Boa parte do software que esse mercado contrata não é dispositivo médico, e confundir as duas coisas custa caro nas duas direções: regularizar o que não precisa, ou não regularizar o que precisa.

A regra brasileira é a RDC 657/2022 da ANVISA, em vigor desde 1º de julho de 2022. Ela define software como dispositivo médico como o software que atende à definição de dispositivo médico, destinado a uma ou mais indicações médicas, e que realiza essas finalidades sem fazer parte do hardware de um dispositivo. Aplicativo de celular e sistema vendido por assinatura na nuvem entram, se a finalidade for médica.

A mesma resolução diz, logo no artigo 1º, a quem ela não se aplica: software para bem-estar; software da lista de produtos não regulados da agência; software usado exclusivamente para gestão administrativa e financeira em serviço de saúde; software que processa dados demográficos e epidemiológicos sem finalidade clínica; e software embarcado em dispositivo médico.

O documento de perguntas e respostas que a ANVISA publicou em setembro de 2022 desce ao caso concreto. Plataforma de prontuário eletrônico que só registra e exibe informação não é dispositivo médico. Sistema de agenda, comunicação e telemedicina, mesmo com imagens e exames dentro do prontuário, também não. Sistema de auditoria de guias e indicadores, não. O que muda a resposta é uma função: quando o sistema passa a fazer triagem automática, sugerir diagnóstico, sugerir tratamento ou classificar risco com base em diretrizes, ele vira SaMD, e a ANVISA cita o exemplo do sistema de suporte à decisão que calcula risco cardiovascular e sugere exame e medicamento, enquadrado na classe II ou III. O primeiro corte do enquadramento cabe numa pergunta: o software só registra e mostra, ou ele conclui, sugere, calcula ou comanda alguma coisa com finalidade clínica? O que só registra e mostra fica fora.

Há um terceiro grupo: o software que entra no processo do próprio equipamento, porque comanda o hardware ou porque o equipamento não funciona sem ele. A RDC 751/2022, que hoje define as classes de risco, é explícita: software cujo objetivo é controlar o hardware de um dispositivo médico não é SaMD. Ele é software embarcado ou acessório de uso exclusivo, e a RDC 657 manda regularizá-lo junto com o equipamento, no processo do fabricante. A ANVISA confirma isso na pergunta sobre software exclusivo de um equipamento de diagnóstico in vitro, instalado num computador comum e sem o qual o equipamento não funciona: é informado no processo do equipamento, não em processo separado, e o artigo 3º da RDC 657 estende a regra a qualquer dispositivo médico. Trocar dados com o equipamento é outra situação. A mesma RDC 751 diz que um SaMD pode interagir com o hardware de outros dispositivos, e a ANVISA respondeu que software de interfaceamento com equipamento de laboratório só é SaMD quando faz diagnóstico ou triagem automática, ou quando controla o equipamento. Software que só recebe dados do equipamento e, a partir deles, conclui ou sugere algo clínico é SaMD por conta própria.

Para quem contrata, isso muda quem assina o quê. Quem registra na ANVISA é o fabricante legal: a empresa que coloca o produto no mercado sob o seu nome, mesmo quando o projeto ou a fabricação são feitos por terceiros em nome dela. O fornecedor que desenvolve para esse fabricante não registra nada; o que o fabricante precisa dele é a evidência que vai dentro do dossiê. A conta muda de lado quando a própria software house vende o SaMD como produto seu, por licença ou assinatura: nesse caso ela é o fabricante, precisa da autorização de funcionamento, e as exigências deste artigo passam a ser dela.

A mesma lógica vale para o que fica fora de propósito. Um portal de conteúdo ou um assistente de IA voltado a profissionais de saúde pode ser desenhado para não dar diagnóstico, tratamento, dosagem ou protocolo clínico. Não é cautela genérica: é a decisão de desenho que mantém a ferramenta do lado não regulado da linha, e ela precisa ser tomada e documentada no início.

A finalidade decide a classe, e a classe decide a porta de entrada

Quando o software é SaMD, a RDC 751/2022 o enquadra pela Regra 11, que reproduz a estrutura da regra de mesmo número do regulamento europeu de dispositivos médicos. Software que fornece informação para decisão diagnóstica ou terapêutica é classe II. Se a decisão errada puder causar morte ou deterioração irreversível da saúde, classe IV. Se puder causar deterioração grave ou intervenção cirúrgica, classe III. Software que monitora processos fisiológicos é classe II, e classe III quando monitora parâmetro vital cuja variação coloca o paciente em perigo imediato. Qualquer outro SaMD é classe I.

A classe define a porta. Classes I e II entram por notificação, com formulário e dossiê técnico que fica na empresa. Classes III e IV entram por registro, com relatório técnico apresentado à agência. O fabricante ou detentor precisa de autorização de funcionamento em qualquer classe e, nas classes III e IV, pode precisar também do certificado de boas práticas de fabricação.

Hospital que desenvolve o próprio software tem um regime à parte. O artigo 5º da RDC 657 dispensa de regularização o SaMD desenvolvido internamente, de uso exclusivo do serviço de saúde, nas classes I e II, desde que não interfira em dispositivo médico regularizável. A contrapartida é documental: registros completos de validação, com histórico de alterações, guardados por pelo menos dez anos depois do descarte, sob pena de o software ser considerado não regularizado. Para o hospital que contrata uma empresa para construir esse software "interno", a consequência é direta: a dispensa de registro não dispensa a evidência, e é o hospital que responde por ela.

O que a ANVISA pede no dossiê, e o que isso significa para quem contrata

O artigo 12 da RDC 657 lista o que o relatório técnico de um SaMD de classe III ou IV precisa trazer além do que vale para qualquer dispositivo: arquitetura de software; arquitetura de hardware e requisitos técnicos mínimos; plataforma; compatibilidade, interoperabilidade e comunicação com outros produtos; arquitetura e controles de cibersegurança; verificação e validação; gerenciamento de risco; anomalias residuais identificadas e como são mitigadas; avaliação clínica, com descrição dos algoritmos; e a declaração de conformidade com normas internacionais.

O artigo 13 diz quais normas, no mínimo, essa declaração cobre: IEC 62304, de ciclo de vida de software; IEC 62366-1, de usabilidade; e ISO 14971, de gerenciamento de risco, nas versões citadas na resolução ou em versões mais atuais. A ANVISA esclareceu depois que a declaração é exigida para as classes II, III e IV, que ela precisa ser um documento assinado pelo fabricante, e que a simples lista de normas usadas no dossiê não vale como declaração. Quem não declara alguma das normas precisa justificar e entregar, no lugar, o documento correspondente à norma que faltou: o descritivo do ciclo de vida do produto para a IEC 62304, o relatório de usabilidade para a IEC 62366-1 e o relatório de gerenciamento de risco para a ISO 14971.

Há exigências também sobre o que acompanha o produto. O artigo 7º manda que as instruções de uso, ou o próprio software, tragam os procedimentos de atualização, os requisitos mínimos de hardware e software, o princípio de funcionamento com descrição dos algoritmos, alertas e advertências, especificações de interoperabilidade e informações de cibersegurança. O artigo 8º pede identificação de produto e versão que permita rastrear a produção, no lugar do lote. E o artigo 16 alcança a vida do produto depois do registro: mudança que cria funcionalidade ou indicação clínica nova, que afeta de forma significativa segurança ou eficácia, ou que descaracteriza a identidade visual do software precisa ser peticionada à agência. Para quem contrata, o plano de releases do fornecedor precisa separar, desde o início, o que é manutenção do que é alteração que passa pela ANVISA.

E a RDC 848/2024, que fixa os requisitos essenciais de segurança e desempenho, fecha o círculo no artigo 50: o software de um dispositivo médico, ou que seja ele próprio o dispositivo, "deve ser desenvolvido, fabricado e mantido de acordo com o estado da arte, levando em consideração os princípios de ciclo de vida do desenvolvimento, gerenciamento de riscos, incluindo a segurança das informações, verificação e validação". Os artigos seguintes pedem requisitos mínimos de rede e de segurança de TI declarados pelo fabricante e proteção contra acesso não autorizado.

Leia essa lista com os olhos de quem compra. Nenhum item dela diz "o fornecedor precisa ter o certificado X". Todos dizem "o fabricante precisa demonstrar como o software foi feito". Quem assina a declaração é o fabricante. Quem produz a maior parte da evidência, quando o desenvolvimento é terceirizado, é quem desenvolve. Se o fornecedor entrega o sistema funcionando e não entrega arquitetura, requisitos rastreáveis, protocolo e relatório de teste e a lista de anomalias conhecidas, o fabricante não tem com que assinar. É por isso que a formação de quem coordena o projeto pesa: ela é o que faz essa evidência nascer junto com o código, e não ser reconstruída depois.

IEC 62304 traduzida: três classes de segurança e o que cada uma exige

O conceito central da IEC 62304 para quem contrata é a classe de segurança do software, que não é a mesma coisa que a classe de risco do dispositivo na ANVISA. A norma tem três: A, quando o software não pode contribuir para uma situação perigosa, ou quando pode contribuir mas o risco fica aceitável depois de medidas de controle externas ao software, verificadas; B, quando pode contribuir mesmo depois dessas medidas, mas o dano possível não é grave; e C, quando o dano possível é grave ou pode levar à morte. A classe define quanta documentação e quanta verificação a norma exige.

Fonte: IEC 62304:2006 com a emenda 1 de 2015, título e emenda conferidos na página oficial da IEC; requisitos por classe conforme o resumo das classes de segurança do Johner Institute, lido em 02/10/2026. Medidas de controle de risco externas ao software podem reduzir a classe, desde que verificadas.

Na prática, a classe é uma decisão conjunta com a área de qualidade do fabricante, tomada antes do código, e o procedimento interno de qualidade do fabricante pode pedir mais do que a norma pede para aquela classe. Em caso de dúvida, o documento que manda é esse procedimento, não a preferência de processo do fornecedor. É assim que funciona quando o fornecedor entra no processo de quem registra, e é o tipo de conversa que a formação em IEC 62304 prepara.

Dois conceitos vizinhos aparecem logo em seguida. O primeiro é o SOUP, sigla da norma para software de origem desconhecida: toda biblioteca, framework e componente de terceiro que entra no produto. A norma exige identificar nome, versão e fabricante de cada um, avaliar as anomalias conhecidas e justificar por que aquele componente serve ao uso pretendido. Para quem contrata, isso significa que a escolha de um framework deixa de ser gosto do desenvolvedor e vira decisão documentada. Um fornecedor que não consegue listar o que usa não consegue montar o inventário de componentes que a lei americana passou a exigir para dispositivos conectados.

O segundo é a divisão de trabalho entre normas irmãs. A IEC 82304-1 cuida do produto de software de saúde como um todo, inclusive instalação, manutenção e descarte. A IEC 81001-5-1, de 2021, trata das atividades de segurança cibernética ao longo do ciclo de vida: modelagem de ameaças, desenvolvimento seguro, tratamento de vulnerabilidades e gestão de correções. A ISO 14971 cuida do risco e a IEC 62366-1 da usabilidade, e a 62304 remete às duas.

A documentação que um fabricante espera de quem desenvolve

Quando um fabricante de dispositivo médico terceiriza software, a lista do que ele espera receber segue a estrutura das próprias normas. É a lista que quem contrata deveria colocar na proposta, não na entrega.

Famílias de documentação organizadas pelas normas que a RDC 657/2022 cita e pelas normas irmãs de produto e cibersegurança, com a nossa descrição do conteúdo de cada uma.

Quatro consequências práticas saem dessa lista.

A rastreabilidade vira a espinha do projeto. As necessidades de usuário viram casos de teste, e cada funcionalidade passa a ter o caminho inteiro escrito: necessidade, requisito, decisão de arquitetura, código, teste e resultado. Testes e documentação precisam viver onde a área de qualidade do fabricante consiga sempre a última versão, sem pedir.

As instruções de uso viram entregável do fornecedor. É o tipo de documento que um fornecedor de software comum nunca escreve e que, nesse setor, o artigo 7º da RDC 657 exige, com seção de cibersegurança incluída.

A proteção de dados muda a API. Uma revisão de HIPAA, GDPR ou LGPD costuma fazer uma listagem de pacientes devolver apenas os campos mínimos para a tela ser desenhada, em vez do registro inteiro. É uma decisão pequena de engenharia que só aparece quando alguém olha o produto com a lente de quem vai ser auditado.

E os requisitos de infraestrutura chegam por escrito. Backup, no projeto comum, é um item de operação. No regulado, é um requisito com dono, com teste e com registro.

Para o comprador, a conclusão é uma só. Se o fornecedor entrega o link do repositório e um vídeo da tela funcionando, você comprou código. Se ele entrega a cadeia de rastreabilidade, a análise de risco do componente, o inventário de componentes de terceiros, os protocolos e relatórios de teste e a instrução de uso, você comprou o que vai para o seu dossiê. A diferença de preço entre as duas entregas existe, e é menor do que o custo de reconstruir a evidência depois, quando o auditor perguntar.

Se o produto vai para os Estados Unidos

Fabricante brasileiro que exporta, ou fabricante estrangeiro que contrata desenvolvimento no Brasil, encontra na FDA a mesma lógica com outros nomes.

A agência adota a definição de SaMD do IMDRF, o fórum internacional de reguladores, e ela diz o mesmo que a da RDC 657, então o enquadramento feito para a ANVISA serve de ponto de partida. A diferença que pesa para quem contrata está na documentação. A orientação sobre o conteúdo das submissões de software, publicada em junho de 2023, trabalha com dois níveis. O nível ampliado vale quando uma falha do software pode criar uma situação perigosa com risco provável de morte ou lesão grave, avaliado antes das medidas de controle de risco; o nível básico vale para o resto, com duas exceções que a própria orientação lista: software de banco de sangue recebe o nível ampliado em qualquer caso, e dispositivos de classe III na classificação americana, assim como a parte de dispositivo em produtos combinados com medicamento ou biológico, também, salvo justificativa detalhada na submissão. Nos dois níveis, a FDA espera descrição do software, arquivo de gerenciamento de risco, especificação de requisitos com rastreabilidade, arquitetura, testes de verificação e validação, histórico de versões e a lista de anomalias não resolvidas com avaliação de impacto. E aceita, no lugar do resumo das práticas de desenvolvimento, uma declaração de conformidade com a IEC 62304.

Duas mudanças recentes aumentam o peso disso. Desde 2 de fevereiro de 2026 está em vigor o novo regulamento de sistema de qualidade da FDA, o QMSR, que incorpora por referência a ISO 13485:2016. E a seção 524B da lei americana, para os chamados cyber devices, exige nas submissões um plano para monitorar e tratar vulnerabilidades depois do lançamento, processos que deem segurança razoável e um inventário de componentes de software, o SBOM. A orientação da FDA sobre cibersegurança foi atualizada em fevereiro de 2026.

Para quem contrata, a consequência é de calendário e de custo. Um fornecedor que mantém o inventário de componentes e a rastreabilidade desde o primeiro sprint entrega a documentação da submissão americana como subproduto do trabalho. Um fornecedor que não mantém transforma a submissão numa reconstrução, meses depois, feita por quem não escreveu o código.

O que pedir ao fornecedor antes de assinar

O fabricante não contrata por selo. Ele contrata pela evidência que consegue colocar no dossiê dele, e a melhor forma de saber se vai recebê-la é perguntar cedo: qual classe de segurança da IEC 62304 vocês propõem para este componente, e por quê; como vocês registram os componentes de terceiros e as vulnerabilidades conhecidas; onde vai morar a rastreabilidade e quem vai ter acesso a ela; e quem, na equipe, tem formação nas normas que a ANVISA cita. São quatro perguntas que qualquer comprador desse setor pode fazer na proposta, e que separam quem já conhece o processo de qualidade de um fabricante de quem só promete.

Na X-Apps, essas perguntas têm resposta antes do contrato. Com colaboradores formados e certificados em SaMD, IEC 62304 e IEC 82304-1 na condução dos projetos de saúde, montamos com a área de qualidade do cliente o plano de documentação antes da primeira linha de código e entregamos a evidência junto com o software. O processo não garante aprovação em agência nenhuma. O que ele faz é deixar a resposta escrita antes de o auditor perguntar: como o software foi especificado, que risco introduz e como foi verificado.

Fontes

• ANVISA, Resolução RDC nº 657, de 24 de março de 2022, texto consolidado, lido em 02/10/2026; e Perguntas e Respostas sobre a RDC 657/2022, versão 1, de 01/09/2022.
• ANVISA, Resolução RDC nº 751, de 15 de setembro de 2022, definições e Regra 11 do Anexo I; e Resolução RDC nº 848, de 6 de março de 2024, artigos 49 a 53.
• IEC, páginas oficiais das publicações IEC 62304:2006+AMD1:2015, IEC 82304-1:2016 e IEC 81001-5-1:2021, lidas em 02/10/2026; resumo das classes de segurança pelo Johner Institute.
• FDA, Content of Premarket Submissions for Device Software Functions, orientação final de junho de 2023; página do Quality Management System Regulation; página da orientação Cybersecurity in Medical Devices, versão de fevereiro de 2026. Lidas em 02/10/2026.
• Medicina S/A, 19/02/2026, análise da Redirection International sobre o tamanho e a posição do mercado brasileiro de dispositivos médicos.
• Medical Device HQ, página do curso Introduction to SaMD, IEC 62304 and IEC 82304-1.