Desenvolvimento seguro em saúde digital: uma revisão

Depois de mais de uma década vendo “segurança” ser tratada como etapa final de um projeto de software de saúde, em vez de fundação, decidi reunir num só lugar o que normas internacionais, regulação brasileira e internacional, e literatura acadêmica recente já estabelecem sobre desenvolvimento seguro nesse setor — e apontar onde a distância entre a norma escrita e a prática de mercado ainda é grande. Sou médico com CRM ativo, dois MBAs, mais de 15 anos em saúde digital e mais de 13 anos de SUS — a maior parte deles cuidando de populações vulneráveis, principalmente no sistema socioeducativo, além de gestão em saúde, saúde mental e atuação como médico regulador e intervencionista do SAMU. Fundei a Sciereli HDC, holding de ciência de dados e segurança da informação em saúde que reúne saude.dev (consultoria e ecossistema), Paranoi (privacidade e OPSEC) e Sciereli Labs (pesquisa).

É uma revisão bibliográfica, não um manifesto: as normas, relatórios e papers citados abaixo são de terceiros, e todos estão referenciados na seção Fontes ao final. Nos pontos em que menciono produtos que construí, marco explicitamente como “Como isso aparece no meu trabalho” — para não confundir o consenso da literatura com prática própria.

O tamanho do problema, em números

Segurança em saúde digital não é preocupação abstrata. Segundo o Cost of a Data Breach Report de 2025 da IBM, o setor de saúde é, pelo 15º ano consecutivo, o mais caro do mundo para sofrer uma violação de dados — um custo médio de US$ 7,42 milhões por incidente, mesmo com queda em relação ao ano anterior (US$ 9,77 milhões), num momento em que a média global caiu para US$ 4,44 milhões. O tempo médio para identificar e conter um incidente de saúde passa de 279 dias.

O HIPAA Journal registrou 772 violações de grande porte em 2025 nos Estados Unidos — recorde histórico, uma média de mais de duas por dia —, afetando quase 140 milhões de pessoas. Entre 2009 e 2025, o acumulado passa de 1 bilhão de registros expostos.

No lado europeu, o primeiro Health Threat Landscape da ENISA (2023) mostrou que ransomware responde por 54% das ameaças ao setor, com prestadores de assistência concentrando 53% dos incidentes — hospitais sozinhos, 42%. O Data Breach Investigations Report 2025 da Verizon aponta ainda um salto de 34% na exploração de vulnerabilidades como vetor inicial de ataque no setor.

Esses números têm uma leitura direta: dado de saúde é o alvo mais valioso e mais mal defendido do mercado. E, cada vez mais, virou também um alvo de fornecedor — a nova categoria Software Supply Chain Failures, incluída no OWASP Top 10:2025, reflete a mesma tendência que o FDA e o IMDRF já vinham endereçando com exigência de SBOM (Software Bill of Materials) para dispositivo médico.

O que a regulação já exige — não é sugestão

Um erro comum é tratar segurança de software de saúde como boa prática opcional. Não é. Está na lei, na norma técnica e na regulação sanitária, com peso jurídico diferente em cada jurisdição:

Norma / Lei	Escopo	Exigência-chave	Onde se aplica
LGPD (Lei 13.709/2018), Arts. 46-49	Tratamento de dado pessoal	Medidas técnicas e administrativas de segurança desde a concepção do sistema	Todo tratamento de dado pessoal no Brasil
RDC ANVISA 657/2022	Software como Dispositivo Médico (SaMD)	Informação de cibersegurança na instrução de uso, proteção contra acesso não autorizado	SaMD comercializado no Brasil
RDC ANVISA 751/2022	Classificação de risco e registro de dispositivo médico	Classes I-IV conforme Regra 11 (transposição da lógica IMDRF)	Todo dispositivo médico, inclusive SaMD
Resolução CFM 2.314/2022	Telemedicina	Registro em Sistema de Registro Eletrônico de Saúde (SRES) com NGS2/ICP-Brasil	Teleconsulta, telediagnóstico, telemonitoramento
IEC 62304:2006+AMD1:2015	Ciclo de vida de software de dispositivo médico	Processo formal de desenvolvimento, verificação e gestão de risco	Software embarcado em dispositivo médico
IEC 81001-5-1:2021	Segurança de software e sistemas de TI em saúde	Atividades de segurança em todo o ciclo de vida do produto	Software de saúde em geral, não só dispositivo
ISO 27799:2016	Gestão de segurança da informação em saúde	Aplica a ISO/IEC 27002 ao contexto clínico	Organizações de saúde, prontuário eletrônico
FDA Cybersecurity Guidance (2025)	Dispositivo médico comercializado nos EUA	SBOM e plano de gestão de vulnerabilidade no dossiê de submissão (§524B do FD&C Act)	Fabricantes que registram na FDA

A RDC 657/2022 está atualmente em revisão pela ANVISA, com foco em software adaptativo — sistemas que mudam de comportamento com o tempo, como modelos de IA clínica — incorporando o conceito de Predetermined Change Control Plan (PCCP) já adotado pelo FDA. É a norma tentando alcançar a tecnologia, não o contrário.

Secure SDLC: onde a prática precisa alcançar a norma

O NIST formalizou essa lacuna com o Secure Software Development Framework (SP 800-218), depois de anos de incidentes de cadeia de suprimentos de software. A lógica dele — e da IEC 81001-5-1, no eixo específico de saúde — é a mesma: segurança entra em cada etapa do ciclo de vida, não numa auditoria de véspera de deploy.

Na prática, isso significa: modelagem de ameaça (threat modeling) antes da primeira linha de código para um novo módulo clínico; revisão de código com regras de segurança automatizadas (o próprio OWASP ASVS 5.0.0 estrutura 350+ requisitos verificáveis, do nível básico ao crítico); testes que incluem caminho de dado inválido e malicioso, não só o caminho feliz; um pipeline de deploy que gera e versiona o SBOM do que está sendo publicado; e monitoramento contínuo que realimenta a próxima rodada de modelagem de ameaça — daí a seta pontilhada fechando o ciclo no diagrama.

É o modelo que aplico na consultoria do saude.dev: compliance LGPD/HIPAA/GDPR, desenvolvimento seguro, auditoria e pentest como parte do mesmo processo, não como serviços vendidos separadamente depois que o produto já está pronto. Na prática, a lacuna mais recorrente que encontro em auditoria pré-registro não é ausência de norma conhecida — times sabem citar ASVS ou IEC 62304 de cabeça — é ausência de rastro: nenhum artefato de threat model versionado, nenhum SBOM gerado no pipeline, nada que comprove que o processo descrito no papel aconteceu de fato no repositório.

Interoperabilidade não é sinônimo de controle de acesso

Um dos enganos mais caros em projetos de saúde digital é assumir que adotar HL7 FHIR resolve segurança por tabela. Não resolve — resolve formato. A própria documentação oficial do FHIR, no módulo Security and Privacy, é explícita: especifica o uso de OAuth 2.0/OpenID Connect (protocolos padrão de autenticação e autorização, via SMART App Launch — o perfil que define como um app de terceiros se conecta a um sistema de saúde), exige TLS para dado de produção, define o recurso AuditEvent para trilha de auditoria, e suporta RBAC/ABAC (controle de acesso por papel ou por atributo do usuário) e rótulos de segurança — mas deixa claro que a implementação de HIPAA, LGPD ou GDPR continua sendo responsabilidade de quem implementa, não algo que o padrão resolve sozinho.

No Brasil, a RNDS segue essa mesma lógica de padronização de transporte — e o recém-editado Decreto 12.560/2025 atualiza as regras de uso da RNDS e das Plataformas SUS Digital — mas a decisão de negócio sobre quem acessa o quê continua sendo decisão de arquitetura de quem constrói o sistema consumidor.

Privacidade desde o design, não como retrofit

A literatura acadêmica sobre segurança e privacidade em prontuário eletrônico já tem mais de uma década de revisões sistemáticas — de 2013 (Journal of Biomedical Informatics) a 2015 (Health Information Management) e 2021 (Journal of the Canadian Health Libraries Association) — e o diagnóstico se repete: sistemas de saúde tendem a tratar privacidade como controle de acesso posterior, não como propriedade do dado desde a coleta.

Minimização de coleta, pseudonimização com token estável (não hash reversível) e controle de reidentificação na camada de análise são três garantias distintas, cada uma com sua própria superfície de falha.

Duas frentes de pesquisa recentes reforçam esse caminho sem depender de anonimização irreversível: aprendizado federado, que treina modelo sem que o dado do paciente saia da instituição de origem (revisão de escopo publicada na npj Digital Medicine em 2025, que atualiza o artigo seminal de 2020 sobre o tema), e criptografia homomórfica, que permite computar sobre dado cifrado sem nunca descriptografá-lo (revisão publicada em 2025 no Journal of Cybersecurity and Privacy). São exatamente as duas linhas de pesquisa que a Sciereli Labs mantém ativas — não por acaso: é onde a literatura sinaliza que a próxima geração de privacidade em saúde digital está sendo construída.

Onde a saúde encontra o OPSEC

Há uma lente que a literatura de segurança em saúde raramente cobre: a proteção do profissional e do dado quando o alvo não é o sistema, é a pessoa. Médico, gestor de saúde ou pesquisador que lida com dado sensível de paciente de alta exposição — autoridade, executivo, figura pública — herda um perfil de risco que HIPAA/LGPD não endereçam diretamente.

Não é o mesmo problema do SDLC seguro de um sistema hospitalar — mas é a mesma pergunta de fundo, aplicada a uma pessoa em vez de um sistema: qual é a superfície de exposição, e o que foi feito, concretamente, para reduzi-la.

O que fica

Nenhum framework, norma ou paper resolve isso sozinho. A convergência que essa revisão mostra — ISO/IEC 27001 e IEC 81001-5-1 do lado de processo, OWASP do lado de prática de código, FDA/IMDRF e ANVISA do lado de exigência regulatória, e uma literatura acadêmica cada vez mais madura sobre privacidade computacional — é o mapa. Construir de acordo com ele, desde o primeiro commit, ainda é trabalho de quem desenvolve.

Se você lidera um produto de saúde digital e quer conversar sobre onde seu ciclo de desenvolvimento está em relação a esse mapa — auditoria, arquitetura de privacidade, compliance LGPD/HIPAA ou resposta a incidente —, me escreva.