Integrações no ecossistema de saúde: como proteger APIs, troca de dados e terceiros
Padrões de troca de dados, riscos das APIs, LGPD e avaliação de fornecedores, para hospitais, laboratórios, operadoras e aplicativos, com um checklist.
Em resumo: A segurança das integrações no ecossistema de saúde protege os dados de pacientes que circulam entre hospitais, laboratórios, operadoras, aplicativos e o poder público, por APIs, webservices e conectores. Essa troca usa padrões como o HL7 FHIR, adotado pela Rede Nacional de Dados em Saúde (RNDS), o DICOM, para imagens médicas, e o Padrão TISS, obrigatório na saúde suplementar. Os padrões definem o formato e, em parte, requisitos de segurança; a autenticação, a autorização, o registro, o monitoramento e o risco de cada fornecedor dependem de quem integra, assim como as obrigações da LGPD.
Quem troca dados de pacientes, e por onde?
Um atendimento passa por vários sistemas e empresas. Cada ligação entre eles é uma credencial, um ponto de acesso e, muitas vezes, um terceiro com acesso a dado de paciente.
Quando a integração leva dados a uma IA, vale também o guia IA na saúde com segurança; os riscos de IA generativa em geral estão no guia de Segurança de IA.
Quais padrões de troca de dados a saúde usa no Brasil?
Os padrões dizem como o dado é estruturado e trocado; nenhum deles, sozinho, protege a integração. Situação conferida nas fontes oficiais em 03/11/2026.
| Padrão | O que troca | Quem define | O que diz sobre segurança |
|---|---|---|---|
| HL7 FHIR | Dados clínicos e administrativos organizados em recursos, como paciente, exame, prescrição e cobrança, trocados por API REST, documentos ou mensagens | HL7 International. A versão publicada atual é a R5 (5.0.0, de 26/03/2023) | Não é protocolo de segurança: recomenda TLS em produção, autenticação (OAuth, com o SMART App Launch quando couber) e validação de toda entrada, e define recursos de auditoria e de proveniência |
| RNDS | Informação em saúde entre os estabelecimentos e a plataforma nacional, como resultados de exames e sumários de alta | Ministério da Saúde (Portaria nº 1.434/2020), com guia de implementação baseado no FHIR 4.0.1 | Integração por conector do estabelecimento, com requisições https; o token de acesso é obtido com o certificado digital do estabelecimento e vale 30 minutos |
| DICOM | Imagens médicas e informações relacionadas, de equipamentos de radiologia, cardiologia, radioterapia e outras áreas | Comitê do padrão DICOM, com secretaria da NEMA; reconhecido pela ISO como ISO 12052 | A parte 15 traz perfis de segurança e de gestão de sistemas, inclusive os de confidencialidade, que removem ou substituem atributos identificáveis |
| Padrão TISS | Dados de atenção à saúde dos beneficiários: verificação, autorização, cobrança, demonstrativos de pagamento e recursos de glosa | ANS, obrigatório pela RN nº 501/2022, sempre na versão vigente | Componente próprio de segurança e privacidade, mensagens em XML por webservice ou portal e plano de contingência para quando a troca eletrônica parar |
Fontes: HL7 FHIR, segurança no FHIR, SMART App Launch, guia de integração da RNDS, RNDS no Ministério da Saúde, guia de implementação FHIR da RNDS, DICOM, DICOM PS3.15, RN ANS nº 501/2022 e Padrão TISS na ANS.
Quais são os riscos de segurança nas APIs de saúde?
O OWASP API Security Top 10, edição de 2023, lista os riscos mais críticos de APIs. Os exemplos abaixo mostram como sete deles podem aparecer nas integrações de saúde.
| Risco (OWASP 2023) | Como aparece na saúde | Controle |
|---|---|---|
| Falha de autorização no nível do objeto (API1) | Trocar o identificador do paciente na chamada e receber o exame de outra pessoa | Conferir a permissão a cada objeto pedido, e não só no login |
| Autenticação quebrada (API2) | Token de um app ou de um conector roubado e reutilizado | Tokens de vida curta e credenciais de máquina em cofre, com rotação |
| Falha de autorização no nível da propriedade (API3) | A resposta traz campos a mais, como documento e diagnóstico, que a tela não mostra | Devolver só os campos de que a finalidade precisa |
| Falha de autorização no nível da função (API5) | Um parceiro chega a funções administrativas, como cancelar uma guia ou alterar um laudo | Separar e proteger as funções administrativas |
| Acesso irrestrito a fluxos sensíveis (API6) | Automação em massa de agendamentos ou de pedidos de autorização | Limites por fluxo e detecção de uso automatizado |
| Inventário inadequado (API9) | Versões antigas, ambientes de teste e pontos de depuração esquecidos, com dado real | Inventário de hosts e versões, e desativação do que não é usado |
| Consumo inseguro de APIs (API10) | O sistema confia no que chega do parceiro, e o atacante entra pelo terceiro | Validar todo dado recebido, como o próprio FHIR recomenda |
A lista tem ainda o consumo de recursos sem limite (API4), a falsificação de requisição pelo servidor (API7) e a configuração insegura (API8).
Como avaliar e acompanhar o risco de terceiros na saúde?
O NIST Cybersecurity Framework 2.0 trata a cadeia de fornecedores na categoria GV.SC, de gestão de riscos de cibersegurança na cadeia de suprimentos. As etapas seguem as subcategorias dela.
- Antes GV.SC-04
Conhecer e classificar
Liste os fornecedores e priorize pela criticidade: quem guarda dado de paciente, quem se conecta à rede e de quem depende o atendimento.
- Antes GV.SC-06
Avaliar antes de contratar
Faça a due diligence: controles, certificações, histórico de incidentes, resultados de testes e, em equipamentos, a lista de componentes de software (SBOM).
- No contrato GV.SC-05
Pôr os requisitos no contrato
Instruções de tratamento (LGPD, art. 39), aviso de incidente, subcontratados, país de processamento, auditoria e eliminação dos dados no fim.
- Durante GV.SC-07
Acompanhar a relação
Reavalie o risco ao longo do contrato e monitore os acessos e as integrações do fornecedor.
- Durante GV.SC-08
Incluir na resposta a incidentes
O fornecedor entra no plano, nos contatos de emergência e nos exercícios de resposta e recuperação.
- Depois GV.SC-10
Encerrar com segurança
Revogue credenciais e integrações e confirme a eliminação ou a devolução dos dados (LGPD, art. 16).
Fonte: NIST CSF 2.0, categoria GV.SC.
O que a LGPD pede quando o dado de saúde circula entre empresas?
Pela LGPD, dado referente à saúde é dado pessoal sensível (art. 5º, II). Numa integração, cada empresa precisa saber se é controladora, a quem competem as decisões sobre o tratamento, ou operadora, que trata em nome de outra (art. 5º, VI e VII).
| Ponto | O que a norma diz |
|---|---|
| Compartilhamento com vantagem econômica | Vedado entre controladores, exceto nas hipóteses de prestação de serviços de saúde, de assistência farmacêutica e de assistência à saúde, incluídos os serviços auxiliares de diagnose e terapia, em benefício dos titulares, para permitir a portabilidade pedida pelo titular ou as transações financeiras e administrativas desses serviços (LGPD, art. 11, § 4º) |
| Com quem se compartilhou | O titular tem direito de saber com quais entidades públicas e privadas o controlador compartilhou seus dados (art. 18, VII). Correções e eliminações são informadas a elas para que repitam o procedimento, salvo quando isso for comprovadamente impossível ou exigir esforço desproporcional (art. 18, § 6º) |
| Segurança de quem participa | Os agentes de tratamento e qualquer outra pessoa que intervenha em uma das fases do tratamento devem garantir a segurança da informação, mesmo após o término (art. 47) |
| Fim do tratamento | Os dados são eliminados após o término do tratamento, com conservação autorizada em casos como obrigação legal ou regulatória e estudo por órgão de pesquisa (art. 16) |
| Saúde suplementar | As operadoras mantêm protegidas as informações assistenciais do Padrão TISS que permitam individualizar o beneficiário, sem divulgá-las nem fornecê-las a terceiros (RN ANS nº 501/2022, art. 21) |
Fontes: LGPD, texto atualizado na Câmara e RN ANS nº 501/2022. Fornecedor de IA, transferência internacional e relatório de impacto: guia IA na saúde com segurança. Integrações de sistemas de IA na Resolução CFM 2.454 (Anexo III, IV e VII): guia da resolução.
Por onde começar? Checklist de segurança para integrações de saúde
Os itens são recomendações deste guia, com a regra de origem quando há.
Mapear
- Inventário de integrações Cada API, conector, webservice e troca de arquivos, com dono, dados e parceiro.
- Fluxo dos dados Que dado sai, para quem, por qual padrão e com qual base legal.
Proteger
- Identidade de máquina Uma credencial por integração, em cofre, com rotação e menor privilégio.
- Autorização por objeto Permissão conferida a cada paciente, exame ou guia pedido pela API.
- Testes Teste de intrusão nas APIs antes de abrir a parceiros e a cada mudança relevante.
Contratar
- Due diligence Fornecedor avaliado pela criticidade antes da assinatura (NIST CSF 2.0, GV.SC-06).
- Cláusulas Instruções de tratamento, incidentes, subcontratados, país de processamento e eliminação dos dados.
Monitorar
- Telemetria no SOC Registros das APIs e dos acessos de terceiros correlacionados, com alerta de uso fora do padrão.
- Contingência Plano para o atendimento seguir se uma integração parar, como o que o Padrão TISS exige (RN ANS nº 501/2022, art. 18).
- Encerramento Credenciais revogadas e dados eliminados ou devolvidos no fim de cada contrato.
Como a Vortex protege integrações no setor de saúde?
Na segurança para o setor de saúde, a fase Proteger da Vortex Security inclui as integrações com operadoras, laboratórios, parceiros e sistemas terceiros e o controle dos acessos de profissionais, terceiros e sistemas. A Vortex é líder em MSSP no Brasil, com +80 clientes ativos e +500 mil ativos protegidos.
A Vortex é Líder no ISG Provider Lens 2026 em Next-Gen SOC/MDR Services (Midmarket, Brasil). Para hospitais e redes de saúde, veja também a página de cibersegurança na saúde.
Perguntas frequentes
O que é HL7 FHIR?
É um padrão para troca de dados de saúde publicado pela HL7, que organiza a informação em recursos, como paciente, exame, prescrição e cobrança, trocados por API. A versão publicada atual é a R5, de 2023. No Brasil, a RNDS modela os dados em FHIR, com o guia de implementação baseado na versão 4.0.1.
O FHIR é seguro?
Segundo a própria especificação, o FHIR não é um protocolo de segurança nem define funções de segurança. Ele pressupõe um sistema de autenticação e controle de acesso e recomenda TLS em produção, OAuth para aplicações web (com o SMART App Launch quando couber) e validação de toda entrada, e define recursos de auditoria. A segurança de uma API FHIR depende de como cada empresa a implementa.
O que é a RNDS e como um hospital ou laboratório se integra a ela?
A Rede Nacional de Dados em Saúde é a plataforma do Ministério da Saúde para a interoperabilidade em saúde no país: por ela, um estabelecimento disponibiliza informação que outro consome. A integração é feita pelo sistema do estabelecimento, com um conector no padrão FHIR, e o acesso exige um token obtido com o certificado digital do estabelecimento.
O Padrão TISS é obrigatório?
Sim, na saúde suplementar. A RN nº 501/2022 da ANS fixa o Padrão TISS como obrigatório para a troca de dados de atenção à saúde dos beneficiários entre operadoras, prestadores, contratantes, beneficiários e a ANS, sempre eletrônica e na versão vigente (arts. 1º, 4º e 7º). As operadoras devem oferecer aos prestadores webservice e portal (art. 15, § 2º).
Quais são os riscos mais comuns em APIs de saúde?
O primeiro da lista do OWASP API Security Top 10, edição de 2023, é a falha de autorização no nível do objeto: trocar o identificador de um paciente na chamada e receber os dados de outro. Também pesam a autenticação quebrada, as respostas com campos a mais, as funções administrativas expostas, o inventário desatualizado de APIs e a confiança sem validação nos dados de parceiros.
Como avaliar um fornecedor que vai acessar dados de pacientes?
Pela criticidade: o que ele acessa, como se conecta e o que para se ele falhar. Antes de contratar, avalie controles, certificações e histórico de incidentes; no contrato, ponha as instruções de tratamento (LGPD, art. 39), o aviso de incidentes, os subcontratados e a eliminação dos dados no fim; durante a relação, monitore os acessos. O NIST CSF 2.0 organiza essas etapas na categoria GV.SC.
A operadora pode compartilhar dados de saúde com parceiros?
Com limites. A LGPD veda a comunicação ou o uso compartilhado de dados de saúde entre controladores com objetivo de vantagem econômica, exceto nas hipóteses de prestação de serviços de saúde, de assistência farmacêutica e de assistência à saúde, em benefício dos titulares (art. 11, § 4º). E, pelo Padrão TISS, as informações assistenciais que individualizem o beneficiário não podem ser divulgadas nem fornecidas a terceiros (RN ANS nº 501/2022, art. 21).
Fontes
Textos oficiais consultados em 03/11/2026.
- HL7 FHIR, versão R5 e FHIR Security, HL7 International.
- SMART App Launch, versão 2.2.0, HL7 International.
- Guia de integração da RNDS, Ministério da Saúde.
- Rede Nacional de Dados em Saúde: estrutura do projeto, Ministério da Saúde.
- Guia de implementação FHIR da RNDS, Ministério da Saúde.
- About DICOM e DICOM PS3.15: Security and System Management Profiles, NEMA.
- Resolução Normativa ANS nº 501/2022, Saúde Legis, Ministério da Saúde.
- Padrão TISS, ANS.
- OWASP API Security Top 10, edição de 2023, OWASP.
- The NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29, 26/02/2024.
- Lei nº 13.709/2018 (LGPD), texto atualizado, Câmara dos Deputados.
Quer saber como estão protegidas as integrações da sua instituição?
Conte quais sistemas e parceiros trocam dados com a sua instituição e um especialista da Vortex entra em contato.
Atualizado em