Gestão de Informações em Saúde: Sistemas, Tecnologia e Implementação [2026]

Gestão de informações em saúde é daqueles termos que parecem autoexplicativos até que você tenta implementá-los. O Brasil tem hoje um mercado de R$4,2 bilhões em sistemas de informação hospitalar, regulamentações crescentes — LGPD, RNDS, TISS v3.05 — e uma infraestrutura nacional de interoperabilidade em expansão (ANAHP, 2025). E ainda assim, hospitais perdem receita por glosas originadas em inconsistências de dados, médicos tomam decisões com prontuários fragmentados, e estabelecimentos deixam de cumprir prazos de integração com a RNDS por falta de arquitetura técnica adequada.

A distância entre ter um sistema e efetivamente gerir as informações de saúde é onde a maioria das organizações perde dinheiro — e onde a qualidade assistencial é comprometida.

Este guia cobre o lado técnico e operacional da gestão de informações em saúde no contexto brasileiro: o ecossistema de sistemas hospitalares, o framework de ciclo de vida do dado adaptado à regulação nacional, gestão de identidade de pacientes, os padrões de interoperabilidade FHIR e RNDS, os requisitos técnicos da LGPD, métricas de qualidade de dados e como a automação está mudando a economia de cada processo-chave. Foi escrito para diretores de TI, gestores hospitalares, analistas de sistemas e líderes de operações que precisam fechar a lacuna entre o investimento em tecnologia e os resultados reais de informação.

O Que É Gestão de Informações em Saúde?

A gestão de informações em saúde (GIS) é o conjunto estruturado de processos, tecnologias e políticas que governam como os dados de saúde são coletados, armazenados, processados, protegidos e utilizados ao longo de todo o seu ciclo de vida — desde o cadastro do paciente na recepção até o descarte regulatório após décadas de retenção. Não se trata de uma função isolada, de um sistema específico ou de um conjunto de políticas documentadas: é a infraestrutura organizacional que determina como todos os dados de saúde são tratados, de ponta a ponta.

No Brasil, a GIS ganhou camadas regulatórias específicas nos últimos anos: a LGPD (Lei 13.709/2018) estabeleceu requisitos de proteção para dados sensíveis — categoria na qual os dados de saúde se enquadram; a Rede Nacional de Dados em Saúde (RNDS) criou uma infraestrutura nacional de interoperabilidade baseada no padrão FHIR R4; e a ANS mantém o padrão TISS v3.05 como protocolo obrigatório para troca de informações entre operadoras e prestadores de saúde suplementar. A SBIS (Sociedade Brasileira de Informática em Saúde) e o HL7 Brasil são as referências técnicas profissionais do setor.

O equívoco mais comum na GIS é equiparar gestão de informações a prontuário eletrônico. O PEP (Prontuário Eletrônico do Paciente) é a ferramenta mais visível, mas uma organização de saúde moderna gera dados em dezenas de sistemas: plataformas de faturamento, motores de codificação TUSS/CID-10, arquivos de imagem (PACS), sistemas de gestão de documentos, portais de operadoras, interfaces de laboratório, conexões com a RNDS e ferramentas de análise de saúde populacional. A gestão de informações em saúde é o framework que governa como todos esses dados são capturados, codificados, armazenados, protegidos, trocados e utilizados. Um PEP bem implementado operando dentro de um framework de GIS deficiente ainda produz dados fragmentados, erros de codificação, glosas e exposição à LGPD.

PEP vs. Sistema HIS vs. Infraestrutura de TI em Saúde: Comparação de Escopo

Dimensão	Sistema de Prontuário (PEP)	Sistema HIS Completo	Infraestrutura de TI em Saúde
Foco principal	Documentação do encontro clínico	Ciclo de vida e governança do dado	Infraestrutura e redes
Usuários primários	Médicos, enfermeiros	Gestão, faturamento, compliance	TI, diretor de tecnologia
Marco regulatório	CFM (Res. 1821/2007), ANVISA	LGPD, TISS/ANS, RNDS/MS, SBIS	ISO 27001, NIST, SBIS CERTS
Escopo	Encontro individual do paciente	Ciclo de vida empresarial do dado	Infraestrutura organizacional
Resultado mensurado	Precisão clínica	Qualidade do dado, conformidade, receita	Disponibilidade, postura de segurança

O Ecossistema de Sistemas de Informação em Saúde no Brasil

Uma arquitetura moderna de gestão de informações em saúde no Brasil não é uma plataforma única. É um ecossistema de sistemas especializados, cada um tratando uma camada específica do ciclo de vida do dado. Entender o que cada componente faz — e como eles precisam se integrar — é o pré-requisito para avaliar qualquer investimento em sistema de informação hospitalar ou identificar onde a arquitetura atual está falhando.

O erro mais comum é contratar sistemas melhores de cada categoria sem garantir a integração entre eles. Um motor de codificação TUSS que não retroalimenta o PEP para melhoria da documentação produz dados de codificação que ninguém age sobre. Um Índice Mestre de Pacientes não conectado a todos os sistemas de cadastro não consegue resolver duplicidades que ele não enxerga. A integração é o pré-requisito operacional de toda a arquitetura — não uma feature adicional.

As sete camadas do ecossistema de informação em saúde no Brasil, na ordem do fluxo de dados:

1. Sistema HIS Central — MV, Tasy, RD Saúde, Pixeon, Wareline

O sistema de informação hospitalar (HIS) é a espinha dorsal do ecossistema. O MV (Soul MV) lidera o mercado com aproximadamente 35% de participação em hospitais de médio e grande porte; o Tasy (Philips Healthcare) ocupa cerca de 20%; RD Saúde, Pixeon e Wareline completam o mercado nacional. O HIS central captura dados estruturados de cadastro, admissão, alta, transferência, ordens clínicas e resultados. Cada função downstream — faturamento, codificação, auditoria, análise — depende da qualidade e completude do que é documentado no HIS. A escolha do HIS e sua configuração determinam os resultados de GIS mais do que qualquer outra variável isolada.

2. Repositório Clínico de Dados

O repositório clínico (CDR — Clinical Data Repository) é um armazém de dados centralizado e estruturado que agrega informações de múltiplos sistemas-fonte — HIS, laboratórios, PACS, farmácia, UTI — em um único registro longitudinal do paciente. Ao contrário do HIS, otimizado para fluxos de atendimento em tempo real, o CDR é otimizado para análise, gestão de saúde populacional e recuperação de dados transversais entre encontros. Organizações com programas de saúde baseada em valor ou contratos de pagamento por desempenho não conseguem operar sem um CDR adequadamente arquitetado: a estrutura transacional do HIS nunca foi projetada para análise longitudinal de populações.

3. ECM Hospitalar — Gestão de Documentos Clínicos

Nem todo dado de saúde é estruturado. Documentos digitalizados, termos de consentimento assinados, laudos de referência, resultados de imagem e cartas de encaminhamento existem como conteúdo não estruturado que o HIS não consegue armazenar ou recuperar adequadamente. Sistemas de ECM (Enterprise Content Management) hospitalar gerenciam esse conteúdo: captura, indexação, roteamento e acesso em conformidade com a LGPD. A Resolução CFM 1821/2007 reconhece o prontuário eletrônico como equivalente ao físico, desde que atendidos requisitos de autenticação e integridade. Um prontuário completo inclui tanto os dados estruturados do HIS quanto o conteúdo não estruturado gerenciado pelo ECM.

4. Sistema de Codificação CID-10 e TUSS

A codificação traduz a documentação clínica nos códigos padronizados que sustentam o faturamento, a troca de informações entre operadoras e prestadores, e os relatórios regulatórios. No Brasil, os padrões primários são: CID-10 (Classificação Internacional de Doenças, 10ª revisão) para diagnósticos, adotado pelo MS e pela ANS; e TUSS (Terminologia Unificada da Saúde Suplementar) para procedimentos na saúde suplementar, regulamentada pela ANS via padrão TISS. Plataformas de codificação assistida por IA que analisam o texto do prontuário e sugerem os códigos mais adequados estão reduzindo significativamente a taxa de erros de codificação. Erros de codificação são, no mínimo, glosas — no pior caso, violações regulatórias passíveis de auditoria pela ANS ou pelo CFM.

5. Plataforma de Análise Clínica e Saúde Populacional

Dados clínicos têm valor analítico que vai muito além do encontro individual. Plataformas de análise integram dados do HIS, CDR e repositórios externos para produzir relatórios de qualidade assistencial (indicadores ONA, ANAHP), análises de risco populacional e suporte à decisão clínica. No setor público, os sistemas DATASUS (SINAN, SIM, SINASC, SIA, SIH) cumprem essa função para o SUS. Para a saúde suplementar, operadoras e grandes redes hospitalares investem em Business Intelligence específico para dados de saúde, integrado aos dados de faturamento e TISS.

6. Integração com ANS — Padrão TISS v3.05

O TISS (Troca de Informações em Saúde Suplementar), atualmente na versão 3.05, é o padrão ANS que regula o intercâmbio eletrônico de informações entre operadoras e prestadores de saúde suplementar. Abrange o ciclo completo: solicitação de autorização prévia, guia de consulta, guia de SADT, guia de internação, guia de resumo de internação (GRI) e demonstrativos de pagamento. A conformidade com TISS não é opcional — é requisito para o faturamento na saúde suplementar. Erros de conformidade TISS são a principal causa técnica de glosas por problema de informação, e a integração automatizada do TISS é uma das automações de GIS com maior retorno mensurável.

7. Conexão RNDS — Rede Nacional de Dados em Saúde

A RNDS é a camada de interoperabilidade nacional mandatada pelo Ministério da Saúde, baseada no padrão FHIR R4. Ela permite que estabelecimentos compartilhem dados clínicos — registros de vacinação, resultados laboratoriais, sumários de alta, dispensação de medicamentos — com outros estabelecimentos e com o próprio paciente, usando o CNS (Cartão Nacional de Saúde) como identificador central. A Portaria MS 1.792/2022 tornou a integração obrigatória para estabelecimentos habilitados pelo MS. A implementação técnica da RNDS é detalhada na seção de interoperabilidade abaixo.

"O maior erro na implementação de sistemas hospitalares no Brasil não é escolher o software errado — é escolher o certo e deixar cada módulo operar em silo. Integração não é uma feature: é a condição de existência de uma estratégia de informação em saúde."

Gestão do Ciclo de Vida do Dado em Saúde

Dados que não são ativamente governados deterioram em qualidade, acumulam risco regulatório e criam custos operacionais que escalam com o volume de dados — o que em saúde significa custos que se compõem indefinidamente. A gestão do ciclo de vida do dado em saúde é o framework que garante que cada fase seja tratada com políticas definidas, controles técnicos e estruturas claras de responsabilização.

No contexto brasileiro, esse framework tem dimensões regulatórias específicas: a LGPD exige que o ciclo de vida do dado seja documentado e que cada fase tenha base legal identificada; o CFM estabelece prazos mínimos de retenção de prontuários; e a RNDS impõe obrigações de compartilhamento ativo de determinados dados clínicos. As seis fases do ciclo de vida do dado em saúde, com os requisitos técnicos e operacionais brasileiros para cada fase:

1. Criação. Entrada de dados no ponto de cuidado: cadastro demográfico, documentação clínica, pedidos e resultados. É onde a qualidade do dado é estabelecida ou destruída — o princípio "garbage in, garbage out" aplica-se com total força na saúde. Erros de cadastro nessa fase — CPF incorreto, nome divergente, plano desatualizado — cascateiam em glosas por elegibilidade, registros duplicados e falhas de faturamento. No contexto LGPD, a criação é o momento de coletar o consentimento quando necessário (Art. 11, I) e de informar o titular sobre o tratamento (princípio da transparência, Art. 6º, VI). Investimento em captura de dados na entrada — verificação de elegibilidade em tempo real nos portais das operadoras, validação demográfica automatizada, integração com CADSUS para validação de CNS — gera retorno composto em todas as fases subsequentes.
2. Processamento. Codificação (CID-10, TUSS, grupos DRG para hospitais), revisão de documentação clínica, validação de guias TISS e estruturação para faturamento e análise. É onde o encontro clínico é traduzido no registro financeiro e administrativo. Erros nessa fase — códigos TUSS incorretos, diagnósticos sem especificidade suficiente, guias TISS com campos obrigatórios ausentes — produzem glosas. O processamento é onde a maioria dos investimentos em automação de GIS entrega o ROI mais rápido e mensurável.
3. Armazenamento. O armazenamento ativo de dados de saúde exige decisões arquiteturais sobre infraestrutura de nuvem versus local, redundância (backups offsite para continuidade de operações), criptografia em repouso (AES-256 é o padrão atual), controle de acesso (baseado em função, documentado, auditável) e disponibilidade do sistema. A LGPD exige medidas técnicas e administrativas aptas a proteger dados pessoais sensíveis de acessos não autorizados (Art. 46). A certificação SBIS CERTS (Certificação de Segurança para Sistemas de Informação em Saúde) é o referencial técnico nacional para avaliação de controles de segurança em sistemas hospitalares.
4. Uso. Dados de saúde ativos são utilizados em gestão do ciclo de receita (faturamento TISS, contestação de glosas, controle de recebíveis), análise de saúde populacional, pesquisa clínica, relatórios de qualidade assistencial e interoperabilidade via RNDS. A LGPD exige que o uso dos dados seja compatível com a finalidade para a qual foram coletados (princípio da finalidade, Art. 6º, I). Uso de dados clínicos para fins secundários — como marketing, pesquisa comercial ou análise não assistencial — exige identificação de base legal adicional.
5. Arquivamento. Registros que não são mais usados ativamente, mas precisam ser retidos por exigência legal, movem-se para armazenamento de arquivo. A Resolução CFM 1821/2007 estabelece prazo mínimo de retenção de prontuários de 20 anos a partir do último atendimento para o paciente adulto; para menores de idade, o prazo é de 20 anos ou até 10 anos após o paciente atingir a maioridade, prevalecendo o maior prazo. Estratégias de armazenamento em camadas — armazenamento quente para registros ativos, morno para arquivos recentes, frio para retenção de longo prazo — podem reduzir custos de infraestrutura em 60–80% sem comprometer a acessibilidade dentro dos prazos legais.
6. Descarte. O descarte de dados de saúde deve seguir os requisitos da LGPD (Art. 16), que prevê eliminação dos dados pessoais após o término do tratamento, com exceções para obrigação legal de retenção. Fisicamente, mídias com dados de saúde devem ser destruídas de forma a impossibilitar a recuperação (fragmentação, degaussing para mídias magnéticas, destruição física para SSDs). Eletronicamente, a eliminação criptográfica (crypto-shredding) é o método mais eficaz para dados em nuvem. Um certificado de destruição deve ser documentado e retido. Dados que permanecem além do prazo necessário criam risco continuado de vazamento sem finalidade que o justifique — uma exposição regulatória que a LGPD penaliza diretamente.

A base legal LGPD aplicável a cada fase do ciclo de vida precisa ser documentada. Para dados de saúde em contexto assistencial direto, a base mais frequente é a tutela da saúde (Art. 11, II, f), que dispensa o consentimento quando o tratamento é realizado por profissionais de saúde no exercício de suas funções. Para usos secundários — pesquisa, análise estatística agregada, comunicação com terceiros — a base legal deve ser identificada separadamente para cada uso. O consentimento pode ser necessário quando outra base não se aplica.

Índice Mestre de Pacientes e Gestão de Identidade

Entre 8% e 12% dos registros em um sistema hospitalar típico são duplicatas — dado da AHIMA que se reproduz no contexto brasileiro com agravantes específicos. No Brasil, a ausência histórica do CPF como identificador universal nos sistemas legados criou um problema de identidade estrutural: pacientes registrados com variações de nome, endereços diferentes, números de carteirinha distintos por operadora, ou simplesmente como "Paciente Particular" em sistemas que não capturavam CPF sistematicamente, acabaram com múltiplos cadastros no mesmo HIS.

Registros duplicados não são um problema apenas de qualidade de dados — são um risco clínico direto e uma fonte de perda de receita. Um médico que atende um paciente sem acesso ao seu histórico completo de alergias ou medicações — porque o histórico está em outro cadastro — está operando com informação incompleta. Um faturamento enviado para o endereço errado porque o cadastro ativo tem dados desatualizados gera inadimplência que nada tem a ver com a capacidade de pagamento do paciente. Uma análise populacional rodando sobre uma base em que o mesmo paciente aparece três vezes produz resultados distorcidos que comprometem qualquer decisão baseada nos dados.

A RNDS e o CNS como Identificador Nacional

A RNDS (Rede Nacional de Dados em Saúde) adota o CNS (Cartão Nacional de Saúde) como identificador central para correlacionar registros de saúde de um mesmo paciente entre diferentes estabelecimentos e sistemas. O CNS é emitido pelo Ministério da Saúde via CADSUS (Cadastro Nacional de Usuários do SUS) e está vinculado ao CPF. Esse modelo posiciona o CNS como o identificador único nacional para saúde — permitindo localizar o histórico de um paciente independentemente de onde foi atendido, dentro do SUS ou em estabelecimentos privados habilitados que integram com a RNDS.

Para a saúde suplementar, onde o identificador primário historicamente era o número da carteirinha da operadora — diferente para cada operadora, sem padrão nacional —, o CPF passou a ser o identificador mandatório para guias TISS a partir de atualizações recentes da ANS. A convergência em torno do CPF/CNS como identificadores únicos cria a base técnica para resolver o problema de duplicidade que afeta o mercado desde os primeiros sistemas hospitalares informatizados.

MPI Hospitalar — Solução Técnica para Deduplicação Interna

No nível hospitalar, o Índice Mestre de Pacientes (IMP) — ou Master Patient Index (MPI) em inglês, e IMPE quando estende-se à esfera empresarial com múltiplas unidades — atribui um identificador único de empresa a cada paciente em todos os sistemas e encontros. Quando um paciente é atendido na emergência, na consulta ambulatorial e no centro cirúrgico do mesmo hospital em episódios distintos, o MPI garante que todos os três encontros estejam vinculados ao mesmo registro de paciente — independentemente da variação de nome, endereço ou número de plano apresentado em cada ocasião.

Plataformas modernas de MPI utilizam algoritmos de correspondência probabilística: em vez de exigir coincidência exata em um único campo identificador, avaliam múltiplos atributos — nome, data de nascimento, CPF, CNS, endereço, telefone, número de plano — e atribuem um escore de confiança a cada correspondência potencial. Registros acima do limiar de confiança são mesclados automaticamente; casos limítrofes são sinalizados para revisão humana. Organizações que implementam soluções de MPI com correspondência probabilística consistentemente reduzem taxas de duplicidade de 8–12% para menos de 0,5% — uma redução com impacto imediato e mensurável em segurança clínica e precisão de faturamento.

"Um em cada doze registros em um sistema hospitalar típico pertence a uma identidade duplicada (AHIMA). Cada duplicata é uma falha de qualidade de dados, um risco clínico potencial e um passivo de faturamento."

FHIR, HL7 e RNDS — O Motor de Interoperabilidade no Brasil

O maior problema estrutural na gestão de informações em saúde não é falta de dados — é falta de dados que fluem entre sistemas. Um paciente atendido no pronto-socorro frequentemente chega sem que o médico de plantão tenha acesso ao seu histórico de atendimentos anteriores, mesmo dentro do mesmo grupo hospitalar. Isso não é falha de documentação clínica: é falha de interoperabilidade sistêmica — e tem custo direto em exames duplicados, erros de medicação e decisões clínicas baseadas em informação incompleta.

HL7 v2 — O Legado que Ainda Sustenta o Mercado Brasileiro

O HL7 versão 2 (v2) é o padrão legado que ainda sustenta a maioria das integrações em sistemas hospitalares brasileiros. Mensagens HL7 v2 — alertas ADT para admissões, altas e transferências; mensagens ORU para resultados laboratoriais; mensagens ORM para pedidos clínicos — estão presentes em praticamente todo HIS em operação no país. Funcionam, mas são frágeis: cada integração HL7 v2 é uma implementação ponto-a-ponto e personalizada, exigindo desenvolvimento de interface customizada para cada conexão. Um hospital conectado a 15 laboratórios externos, centros de imagem e clínicas especializadas tem 15 projetos separados de interface HL7 v2 para construir e manter. Não há padronização inerente no conteúdo das mensagens além da estrutura de segmento — o mesmo elemento de dado pode ser codificado de forma diferente por cada sistema.

FHIR R4 — O Padrão da RNDS e o Futuro da Interoperabilidade no Brasil

O FHIR R4 (Fast Healthcare Interoperability Resources, versão 4) é o padrão moderno de interoperabilidade adotado pela RNDS como base técnica de integração nacional. Diferente do HL7 v2, o FHIR utiliza APIs RESTful e formatos de dados JSON/XML — tornando a integração de dados de saúde tecnicamente tão acessível quanto qualquer integração de serviços web modernos. Um endpoint de API FHIR retorna objetos de Recurso padronizados — Paciente (Patient), Observação (Observation), Medicamento (Medication), Encontro (Encounter) — que qualquer sistema compatível com FHIR pode processar sem lógica de interface customizada.

A Portaria MS 1.792/2022 adotou formalmente o FHIR R4 como padrão técnico da RNDS e tornou a integração obrigatória para estabelecimentos habilitados pelo Ministério da Saúde. Essa portaria posiciona o Brasil alinhado ao movimento global de adoção do FHIR: nos Estados Unidos, o CMS exigiu FHIR R4 para todas as operadoras reguladas; na Europa, a EHDS (European Health Data Space) adota FHIR como padrão de referência. O IHE Brasil — capítulo nacional da Integrating the Healthcare Enterprise — desenvolve perfis de integração FHIR adaptados ao contexto regulatório brasileiro, incluindo perfis específicos para integração com a RNDS. O HL7 Brasil coordena a adaptação dos padrões HL7 internacionais para a realidade nacional.

O FHIR não substitui o HL7 v2 de um dia para o outro: ele coexiste com integrações legadas e gradualmente as substitui à medida que organizações modernizam sua arquitetura de integração. A estratégia prática para a maioria dos hospitais brasileiros é manter as integrações HL7 v2 existentes enquanto constroem a camada FHIR para novas integrações — especialmente a conexão com a RNDS — e planejam a migração gradual das integrações legadas mais críticas.

RNDS — Obrigações, Escopo e Implementação Técnica

A RNDS é a infraestrutura nacional de interoperabilidade do Ministério da Saúde, operada pelo DATASUS. Os dados no escopo atual da RNDS incluem: Registro de Atendimento Clínico (RAC), Registro de Imunobiológico Administrado (RIA), Registro de Dispensação de Medicamento (RDM), Resultado de Exame Laboratorial (REL) e Sumário de Alta (SA).

Tecnicamente, a integração com a RNDS exige: certificado digital ICP-Brasil para autenticação de cada estabelecimento; credenciamento no portal rnds.saude.gov.br; desenvolvimento das APIs de envio (POST) e consulta (GET) conforme os perfis FHIR publicados pelo DATASUS; e testes em ambiente de homologação antes da ativação em produção. Para sistemas HIS com integração RNDS nativa — versões recentes do MV Soul MV e Tasy incluem módulos de integração RNDS — parte do trabalho de desenvolvimento é realizado pelo fornecedor do HIS. Mas a habilitação no portal RNDS, os testes de conformidade e a responsabilidade pela qualidade e completude dos dados enviados são sempre do estabelecimento de saúde, não do fornecedor do sistema.

TISS v3.05 e TUSS — Padrões da Saúde Suplementar

O TISS (Troca de Informações em Saúde Suplementar), versão 3.05, é o padrão ANS que regula o intercâmbio eletrônico entre operadoras de planos de saúde e prestadores de serviço. Define os formatos de mensagem XML, os campos obrigatórios e as regras de validação para todo o ciclo de autorização e faturamento. Erros de conformidade TISS — campo obrigatório ausente, código TUSS inválido, CID-10 incompatível com o procedimento, dados do beneficiário divergentes — são processados pelas operadoras como glosas técnicas, sem opção de recurso até que a correção técnica seja realizada.

O TUSS (Terminologia Unificada da Saúde Suplementar) é a tabela de codificação de procedimentos da saúde suplementar, regulamentada pela ANS. Diferente do CID-10 — que codifica diagnósticos — o TUSS codifica os procedimentos executados pelo prestador. A correta correspondência entre procedimento executado, código TUSS informado e CID-10 associado é o requisito técnico central para aprovação de guias TISS. Incompatibilidades entre esses elementos — por exemplo, um código TUSS de procedimento cirúrgico associado a um CID-10 de diagnóstico clínico não cirúrgico — são identificadas pelo sistema da operadora e resultam em glosa técnica automática.

LGPD e Segurança de Dados em Saúde — Requisitos Técnicos

A LGPD (Lei 13.709/2018) não é uma formalidade burocrática que se resolve com uma política de privacidade publicada no site. É um conjunto de obrigações operacionais e técnicas que afetam cada sistema que processa dados de pacientes — o que, em uma organização de saúde, significa praticamente todos os sistemas. Com penalidades da ANPD chegando a 2% do faturamento bruto anual, limitadas a R$50 milhões por infração, o custo de falhas de conformidade é concreto e crescente.

Dados de Saúde como Dados Sensíveis — Art. 11 da LGPD

A LGPD classifica dados de saúde como dados pessoais sensíveis (Art. 5º, II), o que impõe requisitos mais estritos do que os aplicáveis a dados pessoais comuns. O Art. 11 da LGPD estabelece que o tratamento de dados sensíveis somente pode ocorrer quando necessário para: cumprir obrigação legal ou regulatória; executar políticas públicas; realizar estudos por órgãos de pesquisa com dados anonimizados; exercer regularmente direitos; proteger a vida ou a incolumidade física do titular; ou para a tutela da saúde, exclusivamente por profissionais de saúde, serviços de saúde ou autoridade sanitária. Para dados de saúde tratados em contexto assistencial direto — PEP, sistemas de prescrição, resultados laboratoriais — a base legal mais aplicável é a tutela da saúde (Art. 11, II, f).

LGPD versus HIPAA — Escopo Mais Amplo, Abordagem Diferente

O HIPAA (Health Insurance Portability and Accountability Act), o marco regulatório de privacidade em saúde nos Estados Unidos, se aplica apenas a categorias específicas de entidades — prestadores de saúde, planos de saúde e clearinghouses — e a seus parceiros de negócios diretos. A LGPD tem escopo fundamentalmente mais amplo: aplica-se a qualquer organização que processe dados de pessoas físicas no Brasil, independentemente de setor, porte ou localização geográfica da organização (Art. 3º). Uma clínica de pequeno porte, uma farmácia, uma empresa de wearables de saúde e um grande hospital estão todos sujeitos às mesmas obrigações da LGPD em relação aos dados de seus pacientes e clientes. Essa diferença de escopo é o ponto mais importante para organizações de saúde que operam no Brasil com referências do mercado norte-americano.

Requisitos Técnicos — O Que os Sistemas Precisam Implementar

A LGPD exige que controladores e operadores adotem "medidas de segurança, técnicas e administrativas aptas a proteger os dados pessoais de acessos não autorizados e de situações acidentais ou ilícitas de destruição, perda, alteração, comunicação ou difusão" (Art. 46). Na prática, isso se traduz nos seguintes controles técnicos que todo sistema HIS deve implementar:

• Criptografia em repouso e em trânsito: Dados de saúde armazenados devem ser criptografados (AES-256 é o padrão atual). Dados transmitidos entre sistemas — incluindo integrações TISS, RNDS e acessos via API — devem utilizar TLS 1.2 ou superior.
• Controle de acesso baseado em função (RBAC): Cada usuário deve ter acesso apenas ao mínimo necessário de dados para exercer suas funções. Um recepcionista não precisa de acesso à documentação clínica; um médico não precisa de acesso ao faturamento de outros pacientes. O RBAC garante essa separação de forma documentável e auditável.
• Identificação única de usuário: Credenciais compartilhadas são uma violação regulatória e uma falha de segurança operacional. Cada profissional deve ter credenciais individuais, com autenticação multifator para sistemas com dados sensíveis de alto volume.
• Logs de auditoria abrangentes: Cada acesso a dados de saúde deve ser registrado com identificação do usuário, data e hora, e dado acessado. Logs de auditoria são o instrumento primário de investigação em casos de vazamento ou acesso não autorizado — e são exigidos pela ANPD para comprovação de conformidade.
• Política documentada de retenção e descarte: O ciclo de vida do dado precisa ser formalizado, incluindo o momento e o método de descarte. A LGPD exige que dados sejam eliminados após o término do tratamento (Art. 16), com exceções documentadas para obrigações legais de retenção.
• Nomeação de DPO (Encarregado de Proteção de Dados): Organizações de saúde que processam dados sensíveis em escala devem designar formalmente um Encarregado, conforme Art. 41 da LGPD. O DPO é o ponto de contato com a ANPD e com os titulares dos dados.

A SBIS mantém o programa CERTS (Certificação de Segurança para Sistemas de Informação em Saúde), que avalia se sistemas HIS atendem aos requisitos técnicos de segurança em conformidade com a LGPD e com padrões nacionais e internacionais. A certificação SBIS CERTS é um indicador relevante de maturidade de segurança ao avaliar e contratar fornecedores de HIS no Brasil.

Qualidade de Dados em Saúde — Métricas e Benchmarks

Qualidade de dados em saúde não é uma métrica de conformidade — é uma métrica financeira direta. Dados de baixa qualidade produzem guias TISS glosadas por erros de codificação, solicitações de autorização prévia negadas por ausência de suporte diagnóstico, pedidos de medicamentos referenciando histórico de alergias incompleto, e análises populacionais rodando sobre uma base que não representa com precisão a população atendida. O custo downstream da baixa qualidade de dados é ordens de magnitude maior do que o custo da infraestrutura de monitoramento, governança e remediação necessária para mantê-la. Organizações que tratam qualidade de dados como preocupação de back-office pagam por essa decisão em taxas de glosa e perda de recebíveis.

A AHIMA define sete dimensões para qualidade de dados em saúde, aplicáveis com adaptações ao contexto brasileiro:

• Acurácia: O dado representa corretamente a realidade — o CPF do paciente está correto, o CID-10 corresponde ao diagnóstico documentado, o código TUSS corresponde ao procedimento executado.
• Acessibilidade: O dado está disponível para usuários autorizados quando necessário — o médico de plantão acessa o histórico do paciente, o faturamento recupera a documentação clínica para contestar uma glosa.
• Completude: Todos os elementos de dados obrigatórios estão presentes — campos TISS preenchidos, CID-10 informado, documentação de necessidade médica disponível para procedimentos que a exigem.
• Consistência: Os valores de dados são consistentes entre sistemas e encontros — o mesmo paciente não aparece com datas de nascimento diferentes no HIS e no sistema de faturamento.
• Atualidade: O dado reflete o estado atual — endereço atualizado, plano de saúde vigente, medicações em uso correntes.
• Granularidade: O dado está no nível de especificidade adequado para o uso pretendido — o CID-10 informado tem a especificidade de 4 caracteres quando a operadora exige, não apenas 3.
• Relevância: O dado é adequado para a finalidade pela qual foi coletado — dados coletados para fins assistenciais não são usados para fins incompatíveis sem base legal LGPD identificada.

O impacto da qualidade de dados nas glosas é direto e mensurável. Dados fragmentados são glosas previsíveis: quando o CPF no cadastro não bate com o CPF na guia TISS, a glosa por divergência cadastral é automática. Quando o código TUSS informado na guia não corresponde ao procedimento descrito no prontuário, a glosa técnica é certa. Quando a autorização prévia foi obtida para um código TUSS e o procedimento foi codificado com outro, a glosa linear é sistematicamente aplicada. Os dados da ANAHP revelam que hospitais brasileiros perderam R$5,8 bilhões em glosas em 2024 — e que 98% dessas glosas são revertidas quando contestadas. A maior parte do problema é de qualidade e gestão do dado, não de mérito clínico.

KPIs de Gestão de Informações em Saúde e Benchmarks do Setor

KPI	Benchmark de Referência	Fonte
Acurácia de codificação TUSS/CID-10	≥95% na primeira submissão	SBIS / referência ANS
Taxa de duplicidade de cadastro	<1% da base ativa	AHIMA / referência setorial
Taxa de glosas iniciais	<8% do faturado	ANAHP (meta de gestão)
Completude do prontuário em 30 dias	≥95% dos episódios	CFM / ONA
Taxa de conformidade TISS na submissão	≥98% sem rejeição técnica	ANS / referência operacional
Disponibilidade do sistema HIS	≥99,9% (SLA contratual)	Referência setorial
Taxa de integração RNDS ativa	100% para habilitados MS	Portaria MS 1.792/2022

Operacionalizar qualidade de dados exige três componentes que raramente estão todos presentes ao mesmo tempo: ferramentas de monitoramento que meçam continuamente a qualidade contra limites definidos; políticas de governança que atribuam responsabilidade pela qualidade do dado a funções específicas para cada tipo de dado (alguém precisa ser responsável quando o cadastro de um paciente está desatualizado ou quando a codificação de um episódio está incompleta); e fluxos de remediação que definam o que acontece quando um limite de qualidade é violado — quem é notificado, qual processo de correção é acionado, como a resolução é documentada. Monitoramento sem governança produz relatórios que ninguém age sobre. Governança sem monitoramento produz políticas que ninguém consegue fazer cumprir.

Como a Automação Está Transformando a GIS no Brasil

O papel da automação na gestão de informações em saúde não é substituir profissionais — é eliminar o processamento manual que consome capacidade profissional e introduz erros em escala. Os processos de GIS com maior volume são precisamente os mais vulneráveis a erros humanos sob pressão de volume: verificação de elegibilidade, codificação TUSS/CID-10, correspondência de identidade de pacientes, autorização prévia e reconciliação de glosas. A automação trata os casos rotineiros em velocidade de máquina e sinalizando apenas exceções e casos limítrofes para revisão humana — não remove o julgamento clínico e regulatório, concentra-o onde é necessário.

Processos de GIS: Desempenho Manual vs. Automatizado

Processo de GIS	Desempenho Manual	Desempenho Automatizado	Referência
Acurácia de codificação TUSS/CID-10	68–72% na primeira submissão	95%+ com IA assistida	AHIMA 2024 / adaptado BR
Taxa de duplicidade de cadastro	8–12% da base MPI	<0,5% com IMPE + IA	AHIMA / referência setorial
Autorização prévia — tempo de processamento	Manual, por portal de operadora	Fluxo automatizado via RPA	AMA 2024 / adaptado BR
Verificação de elegibilidade	Manual por telefone ou portal	Tempo real, antes do atendimento	Experian Health 2025
Validação de conformidade TISS	Revisão manual pré-envio	Automática 100% pré-submissão	ANS RN 501 / referência setorial
Integração RNDS	Registro manual ou em lote	Automática em tempo real	Portaria MS 1.792/2022

Automação de Codificação CID-10 e TUSS

A codificação assistida por IA analisa o texto do prontuário — incluindo notas clínicas em linguagem natural, diagnósticos e descrições de procedimentos — e sugere os códigos CID-10 e TUSS mais adequados para o episódio. O revisor humano valida e aprova as sugestões, intervindo diretamente apenas nos casos que o sistema sinaliza como incertos. O resultado é acurácia de codificação consistentemente acima de 95% na primeira submissão — contra 68–72% na codificação manual (AHIMA, 2024) — e uma redução proporcional nas glosas técnicas por erro de codificação e incompatibilidade TUSS/CID-10. Para hospitais brasileiros com volume significativo de internações e SADT, o impacto no ciclo de receita é direto e mensurável.

Integração Automática com TISS para Autorização Prévia

O processo de solicitação de autorização prévia para procedimentos SADT, cirurgias e internações envolve múltiplas etapas em múltiplos portais de operadoras — cada uma com sua interface, seus formulários e seus prazos de resposta próprios. A automação via RPA orquestra esse fluxo: extrai os dados do sistema HIS, preenche a solicitação no portal da operadora correspondente, anexa laudos e justificativas clínicas, monitora o status e notifica a equipe sobre aprovações, pendências ou negativas. Para clínicas e hospitais que processam dezenas ou centenas de autorizações por mês, o ganho de produtividade é substancial — e a eliminação de erros de preenchimento reduz diretamente as glosas por ausência ou incorreção na autorização prévia. Veja o impacto completo no artigo sobre autorização prévia e automação para médicos.

Conexão Automatizada com RNDS

A integração com a RNDS exige o envio estruturado de dados clínicos — Registro de Atendimento Clínico, resultados laboratoriais, registros de vacinação, sumários de alta — em formato FHIR R4, com autenticação via certificado digital ICP-Brasil. Sem automação, o processo exige intervenção manual para cada registro a ser enviado: extração de dados do HIS, transformação para o formato FHIR correto, autenticação e submissão via API. Com integração automatizada — via módulo nativo do HIS ou via middleware de integração dedicado — o processo ocorre em segundo plano, em tempo real ou em lotes programados, sem intervenção humana na rotina. Estabelecimentos habilitados pelo MS que ainda não automatizaram a integração RNDS estão em não conformidade com a Portaria MS 1.792/2022 e expondo seu credenciamento a risco regulatório crescente.

Sua integração com a RNDS está operacional? Seu sistema de codificação está gerando glosas evitáveis por erro TUSS ou CID-10? Realizamos um diagnóstico gratuito de faturamento e informação — com dados reais, não suposições. Agende aqui.

O Custo de Não Automatizar

Os dados da ANAHP mostram que hospitais brasileiros perderam R$5,8 bilhões em glosas em 2024, representando 15,89% do faturado. A mesma pesquisa revela que apenas 1,96% das glosas são mantidas após recurso — o que significa que 98% são revertíveis quando contestadas. O problema não é de mérito clínico: é de capacidade operacional para contestar sistematicamente cada glosa, dentro dos prazos. Equipes de faturamento operando manualmente, processando centenas de demonstrativos de pagamento de operadoras distintas com regras distintas, não têm essa capacidade.

A automação da gestão de informações em saúde cria essa capacidade — não contratando mais pessoas, mas garantindo que o processo do dado — desde a captura até o faturamento — seja tão preciso que as glosas evitáveis não ocorram, e que as que ocorrem sejam contestadas automaticamente, integralmente e dentro do prazo. Para a análise financeira completa do ROI da automação em saúde, veja o artigo sobre ROI da automação com IA em saúde. Para o impacto específico nas glosas, o artigo sobre glosas médicas e automação de faturamento detalha as cinco automações com maior retorno imediato no ciclo de receita hospitalar.