Quando um software de saúde vira dispositivo médico? O ponto que pode mudar todo o projeto de uma healthtech

Uma healthtech pode começar como plataforma de organização e, ao longo do desenvolvimento, incorporar alertas, cálculos, recomendações ou análise de imagens. A mudança parece apenas tecnológica, mas pode alterar a natureza regulatória do produto.

A pergunta central é a finalidade pretendida pelo fabricante e o que o software efetivamente faz. Se a função se enquadra em finalidade médica, o produto pode ser considerado software como dispositivo médico, conhecido pela sigla SaMD. Nesse caso, entram em cena classificação de risco, regularização sanitária, documentação técnica, controles de qualidade, segurança e acompanhamento pós-mercado.

A RDC Anvisa nº 657/2022 estabelece regras para regularização de software como dispositivo médico. A classificação de risco se conecta à RDC nº 751/2022. A Anvisa incluiu a revisão da RDC nº 657 em sua Agenda Regulatória 2026 e 2027, mas a norma continua vigente enquanto não for substituída. Por isso, projetos em curso precisam cumprir o regime atual e acompanhar eventuais mudanças.

Nem todo software usado na saúde é dispositivo médico

Sistemas de agenda, faturamento, comunicação administrativa, gestão de estoque ou bem-estar geral podem ficar fora do conceito de dispositivo médico quando não executam finalidade médica. Por outro lado, software destinado a diagnosticar, prevenir, monitorar, tratar ou auxiliar decisões clínicas pode entrar no enquadramento.

O nome do produto não decide sozinho. Chamar uma função de apoio, inteligência ou bem-estar não neutraliza a finalidade apresentada em telas, materiais comerciais, contrato, instruções de uso ou treinamento da equipe de vendas. A Anvisa examina o uso pretendido e as características do produto.

Também não é seguro concluir que a presença de um profissional de saúde retira o caráter de dispositivo. Um software pode apoiar o profissional e ainda assim possuir finalidade médica regulada. A intensidade da recomendação, a informação utilizada, a relevância clínica e o impacto de um erro ajudam a compreender o risco.

A classificação de risco orienta o caminho regulatório

Os dispositivos médicos são enquadrados em classes de risco. Para software, a regra de classificação considera, entre outros fatores, a finalidade da informação produzida e a gravidade das consequências de uma decisão incorreta. Quanto maior o potencial de dano, maior tende a ser a classe e a exigência regulatória.

Em termos gerais, dispositivos das classes I e II seguem o regime de notificação, enquanto os das classes III e IV dependem de registro. Notificação não significa ausência de obrigação nem uma declaração de que a Anvisa avaliou individualmente toda a eficácia do produto. O fabricante permanece responsável pelo enquadramento, documentação, segurança, qualidade e conformidade.

Uma classificação incorreta pode afetar cronograma, custo, evidências, arquitetura e comunicação. Por isso, o raciocínio regulatório deve ser documentado desde a definição do produto e revisto sempre que a função, o público, o tipo de dado ou a alegação mudar.

Cinco perguntas que ajudam a identificar o risco

1. Qual é a finalidade declarada? O software organiza informações ou pretende apoiar diagnóstico, monitoramento, prevenção ou tratamento?

2. Quem utiliza o resultado? Paciente, profissional de saúde, laboratório, hospital ou gestor?

3. O que acontece se o resultado estiver errado, atrasado ou indisponível?

4. A decisão clínica depende do software ou existe revisão independente e efetiva?

5. As telas, campanhas, demonstrações e contratos fazem promessas mais amplas do que a documentação técnica sustenta?

O enquadramento deve acontecer antes de o produto ficar rígido

Quando a análise regulatória é deixada para o fim, a empresa pode descobrir que precisa alterar interface, fluxo de validação, documentação, base de testes, infraestrutura e material comercial. Em produtos de saúde, conformidade não é uma camada adicionada depois. Ela influencia requisitos do sistema.

O desenvolvimento deve manter rastreabilidade entre necessidade, requisito, versão, teste e liberação. Alterações do modelo, conjunto de dados, limiar de alerta ou forma de apresentação podem modificar desempenho e risco. Em produtos com aprendizado de máquina, é essencial definir quais mudanças são controladas, quando haverá nova validação e quem autoriza a liberação.

A empresa também precisa planejar segurança cibernética, correções, gestão de vulnerabilidades, continuidade e comunicação de incidentes. Uma falha em software de saúde pode afetar confidencialidade, disponibilidade e decisões clínicas ao mesmo tempo.

LGPD e Anvisa tratam de problemas diferentes

Regularização sanitária não substitui proteção de dados. Um produto pode estar regular perante a Anvisa e ainda tratar dados em desacordo com a LGPD. Também pode observar a LGPD e, mesmo assim, estar irregular do ponto de vista sanitário. As duas análises devem avançar em conjunto.

Dados referentes à saúde são dados pessoais sensíveis. Seu tratamento depende de uma hipótese do artigo 11 da LGPD, além de finalidade, necessidade, transparência, segurança e respeito aos direitos do titular. Consentimento não é a única base e não funciona como autorização ilimitada. A hipótese de tutela da saúde também não cobre qualquer uso comercial de dados por qualquer empresa.

Uma política de privacidade publicada no site é apenas parte da conformidade. A operação precisa ter registro de atividades, controles de acesso, retenção, resposta a incidentes, gestão de fornecedores, avaliação de compartilhamentos e documentação da base legal.

Controlador e operador são definidos pela realidade

Hospital, clínica, profissional, plataforma e fornecedor de nuvem podem exercer papéis diferentes em cada fluxo. O controlador toma decisões referentes ao tratamento; o operador trata dados em nome do controlador. O contrato ajuda a organizar responsabilidades, mas o nome dado pelas partes não altera a função efetivamente exercida.

Uma healthtech que decide finalidades próprias, reaproveita dados para desenvolver produto ou combina bases pode não atuar apenas como operadora. Essa conclusão depende do fluxo concreto. Papéis incorretos produzem avisos de privacidade incompletos, contratos incompatíveis e respostas inadequadas a titulares.

Nuvem e transferências internacionais

Dados de saúde podem passar por provedores estrangeiros, suporte global e subcontratados. É necessário identificar países, finalidades, medidas de segurança e mecanismo de transferência internacional. A Resolução CD/ANPD nº 19/2024 disciplina instrumentos como cláusulas padrão contratuais.

A escolha de infraestrutura também deve considerar disponibilidade, segregação, criptografia, registros de acesso, restauração, descarte e possibilidade de migração. O menor preço não compensa um contrato que impeça investigar incidentes ou recuperar dados essenciais.

Telemedicina não transforma a plataforma em prestadora do ato médico

A Lei nº 14.510/2022 autorizou e disciplinou a telessaúde em todo o território nacional. Na medicina, a Resolução CFM nº 2.314/2022 regula modalidades e preserva autonomia, deveres profissionais e necessidade de registro. A tecnologia é meio de prestação, não justificativa para reduzir os deveres clínicos.

Contratos e fluxos devem separar responsabilidades da plataforma, do estabelecimento e do profissional. Termos genéricos que atribuem todo o risco a uma única parte podem não refletir a atuação real. Também é necessário cuidar de identificação, consentimentos quando cabíveis, prontuário, qualidade da comunicação, contingência e continuidade do atendimento.

Comunicação comercial pode alterar o risco

Uma promessa de detectar doença, indicar tratamento ou substituir avaliação profissional pode ser relevante para o enquadramento sanitário e para a responsabilidade perante consumidores. Marketing, vendas e produto precisam usar a mesma finalidade pretendida e as mesmas limitações.

Expressões como precisão total, diagnóstico instantâneo ou eliminação de risco exigiriam suporte técnico excepcional e podem ser enganosas. A comunicação adequada descreve público, uso, limitações, condições necessárias e papel do profissional, sem ampliar o produto além do que foi testado e regularizado.

Checklist jurídico e regulatório para o produto

• documentar a finalidade pretendida e manter consistência entre produto, contrato e publicidade
• avaliar se a função é SaMD e registrar a justificativa do enquadramento
• definir classe de risco e caminho de regularização antes do lançamento
• mapear requisitos, versões, testes, evidências e critérios de liberação
• integrar segurança cibernética e gestão de incidentes ao ciclo de desenvolvimento
• mapear dados pessoais, bases legais, retenção, titulares e compartilhamentos
• definir papéis de controlador e operador conforme as decisões reais
• revisar nuvem, subcontratados e transferências internacionais
• alinhar responsabilidades da plataforma, dos profissionais e das instituições
• monitorar reclamações, falhas, desempenho e mudanças regulatórias após o lançamento.

Em healthtech, a pergunta regulatória não deve aparecer apenas na véspera do lançamento. Ela faz parte da definição do produto.

Conclusão

A fronteira entre software administrativo e dispositivo médico depende da finalidade, da função e do risco. Pequenas mudanças de produto ou de comunicação podem deslocar essa fronteira. A análise precoce permite escolher arquitetura, evidências e cronograma de forma consciente.

O projeto mais seguro integra regulação sanitária, proteção de dados, contratos, segurança e responsabilidade profissional. Essa visão evita que cada área resolva apenas uma parte e deixe contradições que aparecem justamente quando o produto começa a escalar.

Fontes oficiais consultadas

Anvisa, regulamentação de dispositivos médicos e classes de risco (https://www.gov.br/anvisa/en/regulation-of-products/medical-devices).

Anvisa, Manual para Regularização de Equipamentos Médicos, versão atualizada em 2026 (https://www.gov.br/anvisa/pt-br/centraisdeconteudo/publicacoes/produtos-para-a-saude/manuais/manual-regularizacao-gquip/view).

RDC Anvisa nº 657/2022, software como dispositivo médico (https://www.gov.br/anvisa/pt-br/assuntos/produtosparasaude/temas-em-destaque/arquivos/2024/rdc-657-2022-en.pdf).

Anvisa, perguntas e respostas sobre a RDC nº 751/2022 (https://www.gov.br/anvisa/pt-br/centraisdeconteudo/publicacoes/produtos-para-a-saude/manuais/perguntas-respostas-rdc-751-de-2022).

Lei Geral de Proteção de Dados, texto compilado (https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/L13709compilado.htm).

Lei nº 14.510/2022, telessaúde (https://www.planalto.gov.br/ccivil_03/_ato2019-2022/2022/lei/l14510.htm).

CFM, regulamentação da telemedicina pela Resolução nº 2.314/2022 (https://portal.cfm.org.br/noticias/apos-amplo-debate-cfm-regulamenta-pratica-da-telemedicina-no-brasil/). Acessos em 17 ago. 2026. Conteúdo geral; cada caso exige análise própria.

Próximo passo

Se a sua empresa está diante de uma decisão parecida, o caminho mais seguro é avaliar o cenário concreto antes de assinar, contratar ou lançar. Uma análise inicial permite identificar riscos, prioridades e a ordem correta das providências.