TISS: o que é, como funciona e como reduzir glosas

O Padrão para Troca de Informação de Saúde Suplementar (TISS) está presente em praticamente todas as etapas do relacionamento entre hospitais, clínicas, laboratórios e operadoras de planos de saúde. Ele organiza desde a solicitação de autorização até a cobrança dos serviços, o processamento das contas e a apresentação de recursos de glosa.

Embora seja frequentemente associado apenas ao faturamento hospitalar, seu alcance é muito maior. O Padrão TISS também influencia a interoperabilidade entre sistemas, a qualidade dos dados assistenciais, a segurança da informação e a conformidade regulatória das instituições de saúde.

Neste guia, você entenderá como funciona a Troca de Informação de Saúde Suplementar, quais são seus componentes e como o padrão se aplica à operação hospitalar. Também serão abordadas as guias, a relação com a TUSS, a arquitetura tecnológica, a proteção de dados e as práticas necessárias para prevenir rejeições e glosas.

O que é o TISS?

TISS é a sigla associada ao padrão para Troca de Informação de Saúde Suplementar, estabelecido pela ANS. Sua finalidade é organizar a troca de dados administrativos e assistenciais entre os diferentes agentes do setor.

Na prática, o Padrão TISS funciona como uma linguagem comum. Ele determina como determinadas informações devem ser estruturadas, registradas e transmitidas, permitindo que sistemas de hospitais e operadoras interpretem os dados de maneira consistente.

Mas há um detalhe importante: o TISS não é um software, uma tabela de preços ou uma única guia de faturamento. Trata-se de um padrão amplo, composto por regras operacionais, terminologias, estruturas de dados, requisitos de segurança e métodos de comunicação.

Qual problema o Padrão TISS resolve?

Antes da padronização, cada operadora podia estabelecer modelos próprios para solicitações, autorizações, cobranças e demonstrativos. Um hospital que atendesse diversas operadoras precisava adaptar seus processos e sistemas a múltiplos formatos, aumentando a complexidade operacional.

Essa fragmentação favorecia problemas como:

• duplicidade de registros;

• preenchimento inconsistente;

• dificuldade de integração entre sistemas;

• retrabalho das equipes administrativas;

• demora na autorização de procedimentos;

• rejeições de arquivos e atrasos no pagamento;

• baixa rastreabilidade das informações.

A Troca de Informação de Saúde Suplementar foi estruturada para reduzir essas diferenças. Ao definir modelos e conceitos comuns, o padrão permite que prestadores e operadoras compartilhem informações com maior uniformidade, segurança e capacidade de processamento.

Objetivos assistenciais, administrativos e regulatórios

A aplicação do Padrão TISS não se limita ao envio de contas médicas. Os dados padronizados acompanham diferentes momentos da jornada do beneficiário e apoiam atividades assistenciais, administrativas, financeiras e regulatórias.

Entre seus principais objetivos estão:

• padronizar processos de verificação, solicitação, autorização e cobrança;

• organizar os demonstrativos de pagamento e os recursos de glosa;

• facilitar a comunicação entre prestadores e operadoras;

• melhorar a qualidade e a comparabilidade dos dados;

• apoiar avaliações econômicas, financeiras e assistenciais;

• contribuir para o registro eletrônico das informações de saúde.

Isso significa que uma falha originada na recepção ou durante o registro assistencial pode aparecer posteriormente no faturamento. Por esse motivo, a conformidade com o TISS não deve ser tratada como responsabilidade exclusiva da equipe de contas médicas.

Como o TISS reduz a assimetria de informações

A assimetria de informações ocorre quando os participantes de uma relação não possuem acesso equivalente a dados relevantes. Na saúde suplementar, isso pode acontecer quando hospital, operadora e beneficiário registram ou interpretam um mesmo atendimento de maneiras diferentes.

O padrão reduz esse problema ao estabelecer campos, códigos, documentos e mensagens padronizados. Com informações estruturadas, torna-se mais fácil identificar o que foi solicitado, autorizado, executado, cobrado, pago ou glosado.

Essa padronização também aumenta a rastreabilidade. Protocolos, mensagens de retorno e demonstrativos podem ser relacionados ao atendimento original, formando uma trilha útil para auditorias, conciliações e análises de divergências.

O impacto no faturamento, na auditoria e na gestão hospitalar

Quando o TISS é corretamente integrado aos processos hospitalares, seus efeitos alcançam todo o ciclo de receita. Cadastros consistentes, códigos atualizados e validações antecipadas reduzem a probabilidade de uma conta ser devolvida por problemas técnicos ou administrativos.

Os principais impactos esperados incluem:

• menor quantidade de erros de preenchimento;

• redução de rejeições técnicas;

• maior agilidade na conferência das contas;

• melhor controle de autorizações;

• aumento da rastreabilidade das cobranças;

• conciliação mais eficiente dos pagamentos;

• melhores condições para analisar e recorrer de glosas.

Para a diretoria de TI, o padrão orienta integrações entre o sistema de informação hospitalar, o prontuário eletrônico, o ERP e os canais das operadoras. Para a gestão administrativa, ele oferece uma base estruturada para acompanhar prazos, produtividade, retrabalho e perdas de receita.

O valor estratégico do Padrão TISS, portanto, não está apenas em cumprir uma exigência. Ele está em transformar dados assistenciais e administrativos em um fluxo mais confiável, mensurável e integrado.

Veja por que isso é importante: para obter esses benefícios, a instituição precisa compreender não apenas a finalidade do padrão, mas também quais obrigações regulatórias se aplicam a cada agente.

Leia também: 5 Benefícios do sistema hospitalar digital que reduzem custos

O padrão TISS é obrigatório?

O Padrão para Troca de Informação de Saúde Suplementar não é apenas uma recomendação técnica. Sua utilização é obrigatória nos processos e nas condições definidos pela ANS.

Isso não significa, entretanto, que todas as transações sejam obrigatoriamente eletrônicas ou que hospitais e operadoras tenham responsabilidades idênticas. A conformidade exige distinguir o que determina a norma, qual agente deve executar cada obrigação e quais processos dependem de adoção ou acordo entre as partes.

Qual norma estabelece a obrigatoriedade do Padrão TISS?

A principal referência regulatória é a Resolução Normativa ANS nº 501, de 30 de março de 2022. A norma estabelece o padrão obrigatório para a troca de dados de atenção à saúde dos beneficiários de planos privados entre os agentes da saúde suplementar.

A RN 501/2022 também revogou expressamente a RN 305/2012 e a RN 341/2013, que ainda aparecem em artigos, manuais internos e materiais de treinamento desatualizados. A RN 305 pode ser mencionada no contexto histórico, mas não deve ser apresentada como principal fundamento regulatório vigente.

Além da RN 501, a operação deve considerar:

• os componentes e arquivos técnicos publicados pela ANS;

• as versões vigentes e seus prazos de implantação;

• as terminologias que integram a TUSS;

• as regras contratuais entre operadoras e prestadores;

• as normas de segurança, privacidade e proteção de dados;

• as regras sancionatórias aplicáveis aos agentes regulados.

Como o padrão passa por atualizações periódicas, a análise não pode ficar limitada ao texto da resolução. A instituição também precisa acompanhar o Componente Organizacional, o Componente de Conteúdo e Estrutura, os schemas de Comunicação e os históricos da Terminologia Unificada da Saúde Suplementar.

O que determina a RN ANS nº 501/2022?

A RN 501/2022 estabelece as diretrizes, finalidades e regras gerais do Padrão TISS. Entre suas finalidades está a padronização de ações administrativas relacionadas à verificação, solicitação, autorização, cobrança, pagamento e contestação de glosas.

O padrão também busca favorecer a interoperabilidade entre os sistemas de informação da ANS, do Ministério da Saúde e dos demais agentes. Outra finalidade é reduzir a assimetria de informações e formar uma base de dados capaz de apoiar análises econômicas, financeiras e assistenciais.

Na prática, a resolução sustenta processos como:

• verificação de elegibilidade;

• solicitação e autorização de procedimentos;

• comunicação de internação e alta;

• cobrança de serviços de saúde;

• apresentação de demonstrativos de retorno;

• pagamento e conciliação;

• aplicação e recurso de glosas;

• envio de dados pelas operadoras à ANS.

A resolução deve ser interpretada em conjunto com os componentes técnicos. É nesses documentos que aparecem os campos, condições de preenchimento, mensagens, terminologias, arquivos e regras operacionais necessários para aplicar o padrão.

Responsabilidades das operadoras de planos de saúde

As operadoras ocupam uma posição central na Troca de Informação de Saúde Suplementar. Elas recebem informações dos prestadores, processam solicitações e cobranças e enviam à ANS os dados exigidos pela regulamentação.

Entre suas principais responsabilidades operacionais estão:

• disponibilizar meios eletrônicos compatíveis com o padrão;

• manter portal corporativo para a rede credenciada;

• fornecer informações técnicas necessárias à integração;

• informar os endereços dos webservices disponíveis;

• processar mensagens e disponibilizar os retornos;

• acompanhar as versões implantadas em sua rede;

• proteger a confidencialidade e a integridade dos dados;

• encaminhar periodicamente à ANS os dados sob sua responsabilidade.

A operadora também deve designar um Coordenador de Troca de Informação de Saúde Suplementar, conhecido como Coordenador TISS, e seu respectivo suplente. Esse profissional atua como referência técnica para a utilização do padrão e para o relacionamento com a rede prestadora.

Outro cuidado envolve os códigos próprios. Quando um termo passa a constar na TUSS e seu prazo de implantação termina, a operadora não pode continuar utilizando um código próprio para representar o mesmo conceito, salvo nas situações especificamente previstas.

Leia também: Glosa Hospitalar: o que é, causas e impacto no faturamento

Responsabilidades dos hospitais e demais prestadores

Hospitais, clínicas, laboratórios e profissionais que se relacionam com operadoras também precisam observar o Padrão TISS. Suas responsabilidades começam na qualidade do registro e continuam até a transmissão, o acompanhamento do retorno e a guarda das evidências.

Para um hospital, as obrigações operacionais incluem:

• registrar corretamente os dados do beneficiário e do atendimento;

• utilizar guias e mensagens adequadas ao processo;

• aplicar códigos e terminologias vigentes;

• respeitar campos obrigatórios e condições de preenchimento;

• gerar arquivos compatíveis com as versões aceitas;

• proteger dados pessoais e informações assistenciais;

• acompanhar protocolos, rejeições, pagamentos e glosas;

• manter documentação que sustente a cobrança;

• atualizar sistemas e processos nos prazos aplicáveis.

A conformidade não pode ficar restrita ao faturamento. Recepção, autorização, enfermagem, corpo clínico, farmácia, suprimentos, centro cirúrgico, auditoria, TI e financeiro produzem ou utilizam informações que podem compor uma mensagem TISS.

Também é necessário separar obrigação regulatória de exigência contratual. A operadora pode estabelecer rotinas com sua rede, desde que elas não contrariem o padrão, a regulamentação ou os direitos do beneficiário.

Processos eletrônicos obrigatórios, opcionais e condicionados

Nem todos os processos previstos no TISS possuem a mesma condição de implantação. O Componente Organizacional distingue processos eletrônicos obrigatórios, opcionais e situações em que a troca em papel pode ser utilizada.

Entre operadoras e prestadores, aparecem como processos de implantação eletrônica obrigatória:

• cobrança de serviços de saúde;

• autorização de serviços, especificamente quanto à mensagem de lote de anexos;

• comunicação de internação ou alta do beneficiário;

• demonstrativos de retorno;

• recurso de glosas.

Determinados processos são classificados como de implantação eletrônica opcional, incluindo:

• verificação de elegibilidade;

• autorização de procedimentos, exceto a mensagem de lote de anexos;

• envio e recebimento de documentos.

Quando um processo opcional é adotado eletronicamente, a troca deve seguir as especificações do Padrão TISS. A classificação como opcional também significa que sua implantação não deve ser imposta unilateralmente fora das condições estabelecidas.

Há ainda processos em papel admitidos conforme contrato e regras específicas, além do plano de contingência aplicável quando o serviço eletrônico fica indisponível. A indisponibilidade tecnológica não deve provocar descontinuidade indevida do atendimento.

Penalidades: quando se aplicam e a quem se destinam

O descumprimento das regras pode produzir consequências regulatórias, contratuais, financeiras e operacionais. No entanto, é inadequado apresentar uma única multa como se ela se aplicasse automaticamente a hospitais, operadoras e profissionais em qualquer situação.

A regulamentação sancionatória da ANS alcança especialmente as obrigações dos agentes submetidos à sua fiscalização. O não envio de dados à Agência, o atraso ou o descumprimento das regras podem configurar infrações administrativas conforme a RN ANS nº 489/2022 e demais normas aplicáveis.

Para hospitais, as consequências podem envolver:

• rejeição de arquivos;

• devolução de contas;

• atraso no pagamento;

• glosas administrativas;

• descumprimento contratual;

• exposição indevida de dados;

• necessidade de retrabalho;

• responsabilização conforme a natureza da irregularidade.

A análise de uma penalidade concreta deve considerar o agente, a obrigação descumprida, o contrato e a norma vigente. Valores de multas não devem ser reproduzidos sem essa delimitação e sem verificação na fonte regulatória atualizada.

Uma medida segura é manter uma matriz de conformidade que relacione cada obrigação ao processo interno, à área responsável, à evidência de cumprimento e ao mecanismo de monitoramento.

Mas como essas obrigações são transformadas em especificações aplicáveis aos sistemas e às equipes? A resposta está nos cinco componentes do Padrão TISS.

Os cinco componentes do Padrão TISS explicados

Cada componente responde a uma parte diferente da troca de informações, mas todos funcionam de maneira integrada. Em termos simples, o Componente Organizacional determina as regras; o de Conteúdo e Estrutura define as informações; o de Representação de Conceitos padroniza os termos; o de Segurança e Privacidade protege os dados; e o de Comunicação estabelece como as mensagens serão transmitidas.

Organizacional: regras, agentes, prazos e governança

O Componente Organizacional estabelece as regras operacionais do Padrão TISS. Ele apresenta definições, agentes envolvidos, processos padronizados, condições de implantação, responsabilidades e prazos.

Esse componente também registra a versão do documento e o histórico das alterações. Por isso, é uma das primeiras fontes que a equipe deve consultar quando a ANS publica uma atualização.

Entre os assuntos tratados estão:

• finalidade e escopo;

• processos de troca entre operadoras e prestadores;

• processos de envio das operadoras para a ANS;

• regras de utilização e atualização da TUSS;

• condições para tabelas próprias;

• versões vigentes e prazos;

• requisitos de portal e coordenação TISS;

• referências sobre infrações e penalidades.

Para o hospital, o Componente Organizacional funciona como documento de governança. Ele ajuda a responder quais processos devem ser implantados, quem participa das trocas e até quando uma atualização precisa estar operacional.

Conteúdo e Estrutura: mensagens, guias e campos

O Componente de Conteúdo e Estrutura define a arquitetura das informações usadas nas mensagens eletrônicas e nos documentos do plano de contingência. É nele que se encontram os detalhes sobre termos, campos e condições de preenchimento.

Cada campo pode possuir uma condição específica. Dependendo da mensagem, seu preenchimento pode ser obrigatório, opcional ou condicionado a determinada circunstância.

Esse componente orienta elementos como:

• identificação da operadora;

• dados do beneficiário;

• identificação do prestador;

• profissional solicitante ou executante;

• datas de solicitação, autorização e atendimento;

• procedimentos e itens assistenciais;

• valores cobrados, pagos ou glosados;

• diagnósticos e indicações clínicas;

• números de guia, autorização e protocolo.

O fato de um campo existir no layout não significa que ele deva ser preenchido em todas as situações. Tanto a ausência de um dado obrigatório quanto o preenchimento indevido podem gerar inconsistências.

Em hospitais, os dados vêm de diferentes fontes. Informações cadastrais podem nascer na recepção, procedimentos no prontuário, materiais no centro cirúrgico e valores no sistema de faturamento.

Representação de Conceitos em Saúde: terminologias e TUSS

O Componente de Representação de Conceitos em Saúde estabelece os termos utilizados para identificar eventos e itens assistenciais. Esses conceitos são consolidados na Terminologia Unificada da Saúde Suplementar (TUSS).

A TUSS funciona como um vocabulário padronizado. Ela permite que um procedimento, material, medicamento, tipo de atendimento ou motivo de glosa seja representado de forma consistente entre diferentes sistemas.

Entre as terminologias mais relevantes estão as relacionadas a:

• diárias, taxas e gases medicinais;

• materiais e OPME;

• medicamentos;

• procedimentos e eventos em saúde;

• mensagens de glosa e negativa;

• unidades de medida;

• vias de acesso e administração;

• regimes e tipos de atendimento.

Os códigos possuem informações de vigência que precisam ser respeitadas. Um termo pode ser incluído, alterado ou inativado, exigindo sincronização entre cadastros internos, tabelas contratuais e sistemas das operadoras.

Mas atenção: a TUSS não deve ser tratada como tabela de preços. Ela padroniza a identificação dos conceitos, mas não determina quanto será pago pelo serviço.

Segurança e Privacidade: proteção dos dados

O Componente de Segurança e Privacidade estabelece requisitos para proteger os dados utilizados nas trocas. Seu objetivo é preservar sigilo, privacidade, confidencialidade, integridade e disponibilidade.

As mensagens podem conter dados pessoais sensíveis, informações clínicas e dados financeiros. Um arquivo transmitido sem controles adequados pode expor beneficiários e criar riscos legais, regulatórios e reputacionais.

Entre os controles relacionados ao componente estão:

• autenticação de usuários;

• restrição de acesso conforme função;

• proteção dos canais de comunicação;

• registro de atividades;

• preservação da integridade;

• guarda e descarte seguro;

• gestão de credenciais e certificados;

• continuidade dos serviços;

• prevenção e tratamento de incidentes.

Os requisitos podem possuir condições obrigatórias, recomendadas ou opcionais. Ainda assim, essa classificação não elimina outras obrigações previstas na legislação, nos contratos ou nas políticas da instituição.

Comunicação: XML, schemas e webservices

O Componente de Comunicação estabelece os meios e os métodos utilizados para transmitir as mensagens eletrônicas. A linguagem adotada é o XML, sigla para Extensible Markup Language.

Os arquivos XML organizam os dados em elementos estruturados. Para que uma mensagem seja tecnicamente compatível, sua estrutura deve seguir os schemas XSD disponibilizados pela ANS.

Esse componente inclui:

• schemas de tipos simples e complexos;

• estruturas das guias e mensagens;

• arquivos para webservices;

• descritores WSDL;

• elementos de assinatura digital;

• regras de identificação de versões;

• definições para monitoramento dos dados.

A validação estrutural do XML é necessária, mas não suficiente. Um arquivo pode estar de acordo com o XSD e ainda conter código inativo, divergência contratual ou dado incompatível com a autorização.

Como os cinco componentes se relacionam

Considere a cobrança de uma internação hospitalar:

1. O Componente Organizacional determina as regras e responsabilidades.

2. O Conteúdo e Estrutura define a mensagem, as guias e os campos.

3. A Representação de Conceitos fornece os códigos de procedimentos, materiais e medicamentos.

4. A Segurança e Privacidade estabelece como os dados serão protegidos.

5. A Comunicação define a estrutura XML e o método de transmissão.

Uma falha em qualquer camada pode comprometer o resultado. O hospital pode utilizar a guia correta, mas enviar código TUSS inativo ou gerar XML incompatível com a versão aceita.

Essa visão integrada é essencial. Porém, ela traz uma nova questão: se os componentes podem mudar separadamente, como saber qual versão deve ser utilizada?

Qual é a versão vigente do TISS e como acompanhar as atualizações da ANS?

Não existe um único número capaz de representar todo o Padrão TISS. Cada componente possui seu próprio ciclo de atualização, e os termos da TUSS podem ter datas individuais de vigência.

Perguntar apenas “qual é a versão do TISS?” pode gerar uma resposta incompleta. O correto é identificar qual componente, qual processo e qual data de referência estão sendo considerados.

Referência consultada em 25 de julho de 2026: a documentação oficial disponível no portal da ANS apontava a publicação do Padrão TISS de maio de 2026. Como novas versões podem ser divulgadas, essas informações devem ser conferidas antes de qualquer implantação.

Por que o TISS não possui um único número de versão?

Uma publicação pode alterar apenas terminologias, enquanto outra pode modificar campos, regras de segurança ou estruturas XML. Isso permite atualizações mais específicas, mas aumenta a necessidade de governança.

Os componentes documentais geralmente usam uma identificação baseada em ano e mês. A versão 202605, por exemplo, corresponde a maio de 2026.

O Componente de Comunicação utiliza outra convenção, com números como 04.02.00. Essa numeração identifica a geração e a evolução técnica dos schemas e das mensagens eletrônicas.

A TUSS apresenta uma particularidade adicional. Embora o componente tenha uma versão de publicação, cada termo pode possuir suas próprias datas de vigência e implantação.

Na prática, o hospital precisa controlar:

• versão do documento organizacional;

• versão do conteúdo e da estrutura;

• versão do layout ou schema de comunicação;

• versão do componente de segurança;

• vigência individual dos códigos TUSS.

Versões identificadas na publicação de maio de 2026

Os números de Comunicação não devem ser interpretados como se um fosse apenas a continuação do outro. Eles se referem a conjuntos técnicos empregados em contextos diferentes, incluindo trocas entre prestadores e operadoras e o monitoramento dos dados enviados pelas operadoras à ANS.

A versão mais relevante para a integração hospitalar é aquela utilizada no fluxo com a operadora. Mesmo assim, a equipe deve consultar a descrição oficial de cada pacote antes de selecionar schemas ou configurar serviços.

Início de vigência, fim de implantação e fim de vigência

As datas associadas às versões representam momentos diferentes. Confundi-las pode levar tanto à implantação prematura quanto ao uso indevido de uma estrutura desatualizada.

• Início de vigência: data a partir da qual a versão ou o termo passa a ser válido.

• Fim de implantação: prazo máximo para concluir a adequação.

• Fim de vigência: data após a qual a versão ou o termo deixa de ser válido.

Na publicação considerada neste artigo, a ANS indicava 30 de junho de 2026 como data de fim de implantação para as versões 04.03.00 e 01.06.00 do Componente de Comunicação e para as versões 202511 de Conteúdo e Estrutura e de Segurança e Privacidade.

Como essa data já havia passado no momento da redação, as instituições abrangidas deveriam estar adequadas às condições correspondentes. Eventuais exceções ou períodos de convivência precisam ser verificados na documentação oficial e junto às operadoras.

Como identificar alterações na TUSS

As atualizações da Terminologia Unificada da Saúde Suplementar exigem controle mais granular. Não basta registrar que uma versão foi importada; é necessário avaliar o status de cada termo relevante.

No histórico das terminologias, a equipe deve observar:

• código da terminologia;

• código e descrição do termo;

• tipo de alteração;

• data de início de vigência;

• data de fim de implantação;

• data de fim de vigência;

• indicação de inclusão, alteração ou inativação.

Quando um termo é inativado, o sistema deve impedir seu uso em novos eventos após a data aplicável, mas preservar o histórico. Contas referentes a atendimentos anteriores podem precisar manter o código que era válido na data da prestação.

Uma rotina segura deve combinar:

1. Importação controlada dos arquivos oficiais.

2. Comparação entre a versão anterior e a nova.

3. Avaliação do impacto nos cadastros.

4. Definição de substitutos para códigos inativados.

5. Atualização das validações.

6. Comunicação às áreas usuárias.

7. Preservação do histórico.

Matriz de compatibilidade por operadora

Mesmo com um padrão nacional, cada operadora pode possuir cronograma, ambiente de homologação, endpoint e processo de credenciamento tecnológico próprios.

Uma matriz de compatibilidade deve registrar:

A matriz não legitima layouts paralelos incompatíveis com a ANS. Sua finalidade é documentar como cada operadora implementa o padrão e em que estágio está a integração.

Quem deve acompanhar as mudanças?

O controle não deve depender de uma única pessoa ou apenas de alertas enviados por fornecedores. O processo precisa ter responsáveis, periodicidade e evidências.

Uma governança adequada envolve:

• compliance ou regulação: interpretação normativa;

• faturamento: impacto em guias e regras;

• auditoria: reflexos assistenciais e documentais;

• TI: atualização de integrações e schemas;

• segurança da informação: certificados e controles;

• farmácia e suprimentos: materiais, OPME e medicamentos;

• fornecedores: desenvolvimento, correções e suporte.

A instituição deve consultar periodicamente o portal da ANS, registrar as publicações, comparar versões, executar testes e manter evidências da implantação. Essa disciplina reduz o risco de descobrir uma incompatibilidade apenas quando as contas começam a ser rejeitadas.

Controlar versões resolve uma parte do problema. A outra é compreender corretamente o vocabulário utilizado nas mensagens, e é nesse ponto que TISS e TUSS costumam ser confundidos.

TISS e TUSS: qual é a diferença e como se complementam?

Apesar da semelhança entre as siglas e de sua utilização conjunta, TISS e TUSS representam conceitos diferentes. O Padrão TISS organiza a troca de informações como um todo, enquanto a TUSS fornece parte do vocabulário usado nessas trocas.

Uma comparação simples ajuda: o TISS estabelece a estrutura e as regras da comunicação; a TUSS funciona como um dicionário de conceitos.

O que é a Terminologia Unificada da Saúde Suplementar?

TUSS significa Terminologia Unificada da Saúde Suplementar. Ela reúne códigos, termos e descrições utilizados para representar procedimentos, materiais, medicamentos e outros conceitos relevantes.

Sua função é permitir que hospitais e operadoras reconheçam um mesmo evento ou item de maneira consistente. Sem terminologia comum, diferentes instituições poderiam registrar o mesmo procedimento com nomes ou códigos incompatíveis.

Cada termo pode possuir:

• código da terminologia;

• código do termo;

• nome ou descrição;

• data de início de vigência;

• data de fim de implantação;

• data de fim de vigência;

• histórico de inclusão, alteração ou inativação.

A TUSS é dinâmica e precisa ser governada. Ela também não é uma tabela de preços: o valor depende do contrato, da negociação e do modelo de remuneração.

Por que TISS e TUSS não são sinônimos?

A TUSS integra especificamente o Componente de Representação de Conceitos em Saúde. Ela não define, isoladamente, o formato do XML, os canais de transmissão, os requisitos de segurança ou as responsabilidades dos agentes.

Uma guia segue a estrutura definida pelo TISS. Dentro dela, os procedimentos e itens são identificados por códigos da TUSS ou por códigos permitidos nas condições estabelecidas.

Principais tabelas TUSS para hospitais

Entre as tabelas mais utilizadas estão:

• Tabela 18: diárias, taxas e gases medicinais;

• Tabela 19: materiais e OPME;

• Tabela 20: medicamentos;

• Tabela 22: procedimentos e eventos em saúde;

• Tabela 38: mensagens, glosas, negativas e outras;

• Tabelas 63 e 64: agrupamento e forma de envio de itens para a ANS.

Outras tabelas representam unidades de medida, vias de administração, tipos de atendimento, regimes de internação e motivos de encerramento.

Considere uma internação cirúrgica. O procedimento pode ser representado pela Tabela 22, a diária pela Tabela 18, o implante pela Tabela 19 e os medicamentos pela Tabela 20.

Como verificar a vigência de um código

A existência de um código no cadastro interno não garante que ele possa ser utilizado. É necessário verificar se o termo estava vigente na data relevante para o atendimento.

A gestão deve considerar:

• inclusão: novo termo passa a integrar a terminologia;

• alteração: termo existente recebe ajuste;

• inativação: o código deixa de ser válido após a data definida.

Quando um termo é inativado, o sistema deve bloquear seu uso em novos registros sem apagar o histórico. A vigência deve considerar a data do atendimento, e não apenas o momento da transmissão.

Quando pode ser usada tabela própria?

A regulamentação admite que a operadora crie código próprio para termo que ainda não esteja contemplado nas terminologias aplicáveis. Essa possibilidade não autoriza manter indefinidamente um vocabulário paralelo.

As tabelas próprias previstas incluem:

• Tabela 00: termos próprios da operadora;

• Tabela 90: pacotes de odontologia;

• Tabela 98: pacotes.

Quando o conceito passa a integrar a TUSS e termina o prazo de implantação, o código próprio equivalente não deve continuar sendo usado fora das exceções previstas.

Para o hospital, códigos próprios exigem tabela de correspondência com código interno, código TUSS, código da operadora, período de validade, contrato e regra de conversão.

TUSS, CBHPM e SIGTAP

Além de TISS e TUSS, gestores encontram a Classificação Brasileira Hierarquizada de Procedimentos Médicos (CBHPM) e o SIGTAP, utilizado no SUS.

Essas estruturas podem possuir correspondências, mas seus códigos não são automaticamente intercambiáveis. Um hospital que atende SUS e planos privados precisa separar regras e manter mapeamentos controlados.

Com o vocabulário esclarecido, resta saber onde esses códigos aparecem. A resposta está nas guias, nos anexos e nos demonstrativos que estruturam cada etapa do atendimento.

Guias TISS: tipos, finalidades e quando utilizar cada documento

Embora a expressão “guia TISS” seja usada de forma ampla, nem todo documento do padrão é uma guia. O TISS também contempla anexos clínicos, demonstrativos, mensagens de autorização, protocolos e recursos de glosa.

A escolha correta depende da finalidade. Solicitar uma internação, cobrar uma conta encerrada e contestar uma glosa são processos diferentes e utilizam documentos distintos.

Guia de Consulta

A Guia de Consulta é utilizada em atendimentos eletivos realizados por profissional habilitado. Sua aplicação está associada a consultas que não envolvem procedimentos adicionais executados no mesmo documento.

Entre as informações normalmente relacionadas estão:

• identificação da operadora;

• número da guia;

• dados do beneficiário;

• identificação do prestador;

• profissional executante;

• conselho e especialidade;

• data do atendimento;

• tipo de consulta.

A Guia de Consulta não deve ser confundida com a SP/SADT. Se o atendimento incluir procedimentos, exames ou terapias que exijam detalhamento, deve-se avaliar a guia correspondente.

Guia SP/SADT

A Guia de Serviços Profissionais/Serviço Auxiliar de Diagnóstico e Terapia (SP/SADT) é uma das mais utilizadas na saúde suplementar. Ela atende a solicitações e cobranças de serviços profissionais, exames, terapias e procedimentos realizados fora de uma conta de internação.

Pode ser empregada em:

• exames laboratoriais;

• exames de imagem;

• pequenas cirurgias ambulatoriais;

• fisioterapia;

• terapias seriadas;

• procedimentos diagnósticos;

• atendimentos de urgência, conforme as regras aplicáveis.

Na cobrança, o hospital deve verificar se os procedimentos executados correspondem ao que foi autorizado. Divergências de código, quantidade, data ou prestador podem resultar em devolução ou glosa.

Guia de Solicitação de Internação

A Guia de Solicitação de Internação encaminha à operadora os dados necessários à análise da internação. Ela descreve o motivo da solicitação, o caráter do atendimento e os principais elementos clínicos e administrativos disponíveis.

A solicitação pode incluir:

• identificação do beneficiário;

• prestador e profissional solicitante;

• indicação clínica;

• diagnóstico;

• tipo e regime da internação;

• previsão de materiais ou procedimentos;

• data sugerida;

• diárias solicitadas.

A autorização deve ser armazenada com número, validade, condições e itens aprovados. Quando houver prorrogação, mudança de procedimento ou item não previsto, o hospital precisa seguir o fluxo de complementação aplicável.

Guia de Resumo de Internação

A Guia de Resumo de Internação consolida as informações da internação efetivamente realizada. Enquanto a solicitação apresenta o que se pretende realizar, o resumo descreve o que ocorreu.

O documento pode reunir:

• datas e horários de admissão e alta;

• tipo e regime de internação;

• motivo de encerramento;

• diagnósticos;

• procedimentos realizados;

• profissionais envolvidos;

• valores;

• diárias, taxas, materiais e medicamentos;

• autorização e guias relacionadas.

A qualidade do resumo depende dos registros produzidos durante toda a permanência. Antes do envio, a auditoria deve comparar autorização, prontuário e cobrança.

Guia de Honorário Individual

A Guia de Honorário Individual é empregada na cobrança de honorários de profissionais que participaram de atendimento vinculado a uma internação.

Ela pode identificar:

• profissional executante;

• conselho e registro;

• grau de participação;

• procedimento;

• data de execução;

• quantidade;

• valor;

• vínculo com a internação.

O grau de participação merece atenção, pois cirurgião, auxiliares, anestesista e outros participantes podem possuir formas distintas de registro e remuneração.

Também é necessário verificar quem possui legitimidade para faturar. Dependendo do contrato, a cobrança pode ser apresentada pelo hospital, por uma pessoa jurídica médica ou pelo profissional.

Guia de Outras Despesas

A Guia de Outras Despesas detalha itens complementares relacionados a outra guia, como materiais, medicamentos, taxas, diárias e gases medicinais.

Em regra, sua função é complementar a conta principal. Entre os cuidados estão:

• selecionar a tabela correta;

• utilizar código vigente;

• informar unidade de medida compatível;

• registrar quantidade e valor;

• relacionar a data de utilização;

• manter vínculo com a guia principal;

• evitar duplicidade.

Essa guia exige integração com farmácia, almoxarifado, centro cirúrgico, hotelaria e faturamento. Uma divergência entre ampola, frasco, miligrama e unidade de consumo pode alterar significativamente a cobrança.

Guia de Tratamento Odontológico

A Guia de Tratamento Odontológico (GTO) atende aos processos da odontologia suplementar. Ela pode apoiar solicitação, autorização, execução e cobrança de procedimentos odontológicos.

Seus campos contemplam informações específicas, como dentes, regiões da boca, faces dentárias e etapas do tratamento. Instituições sem operação odontológica podem tratar o tema de forma resumida, direcionando o aprofundamento a conteúdo especializado.

Anexos de OPME, quimioterapia e radioterapia

Determinadas solicitações exigem informações clínicas e técnicas adicionais. Nesses casos, o padrão prevê anexos específicos, especialmente para OPME, quimioterapia e radioterapia.

O anexo de OPME pode detalhar materiais, características, quantidades e justificativas. Os anexos de quimioterapia e radioterapia podem incluir diagnóstico, planejamento terapêutico, medicamentos, doses, ciclos e informações clínicas.

Esses anexos não substituem a guia principal. Eles complementam a solicitação e precisam manter coerência com prescrição, prontuário e procedimento solicitado.

Demonstrativos de retorno e pagamento

Depois de processar a cobrança, a operadora devolve informações por meio de mensagens e demonstrativos. Esses retornos permitem identificar o que foi recebido, analisado, pago ou glosado.

Entre os documentos relevantes estão:

• demonstrativo de análise de conta;

• demonstrativo de pagamento;

• demonstrativo relacionado ao recurso de glosa;

• protocolos e respostas de processamento.

O hospital precisa relacionar esses documentos às contas de origem. Uma conta marcada como enviada não deve ser considerada encerrada até que pagamento e eventuais glosas sejam conciliados.

Recurso de glosa e plano de contingência

O recurso de glosa é utilizado para contestar uma recusa total ou parcial de pagamento. Ele deve apresentar identificação da cobrança, item contestado, justificativa e documentação de suporte.

A equipe precisa controlar:

• código e motivo da glosa;

• prazo para recurso;

• responsável;

• documentação;

• data de envio;

• protocolo;

• resposta;

• valor recuperado.

O plano de contingência é utilizado quando a troca eletrônica fica indisponível. Ele deve definir canais alternativos, responsáveis, critérios de acionamento e procedimentos para regularização posterior.

Como escolher o documento correto

A seleção deve partir da finalidade, e não apenas do local do atendimento. Uma mesma jornada pode envolver vários documentos conectados.

Um fluxo simplificado de decisão utiliza estas perguntas:

1. A instituição está solicitando, executando, cobrando ou contestando?

2. O atendimento é consulta, procedimento ambulatorial ou internação?

3. Existe necessidade de anexo clínico?

4. A informação complementa outra guia?

5. Há autorização ou protocolo a ser referenciado?

6. Qual versão está vigente?

7. O envio será eletrônico ou seguirá contingência?

Compreender cada documento reduz erros de enquadramento. Mas ainda falta acompanhar como todos eles se conectam, desde a elegibilidade do beneficiário até o pagamento ou o recurso de glosa.

Como funciona o fluxo TISS: da elegibilidade ao pagamento da conta hospitalar

As guias, anexos e demonstrativos apresentados na primeira parte fazem parte de um fluxo contínuo. Cada documento registra uma decisão, uma execução assistencial ou uma movimentação financeira dentro do Padrão TISS.

Embora o faturamento seja uma etapa central, o processo começa antes do atendimento. Dados incorretos na elegibilidade ou na autorização podem acompanhar toda a jornada e aparecer posteriormente como rejeição, glosa ou atraso no pagamento.

O fluxo pode ser resumido desta forma:

Elegibilidade → solicitação → autorização → atendimento → fechamento → validação → envio → retorno → pagamento ou glosa → recurso

Verificação de elegibilidade do beneficiário

A verificação de elegibilidade confirma se o beneficiário possui vínculo válido com a operadora e se existem condições cadastrais para o atendimento. Ela não equivale, por si só, à autorização de todos os procedimentos que possam ser realizados.

Nessa etapa, o hospital verifica:

• identificação do beneficiário;

• validade do vínculo;

• operadora e produto;

• dados cadastrais;

• orientações operacionais;

• necessidade de autorização específica.

O resultado deve ser registrado no sistema. Data, horário, canal e protocolo ajudam a demonstrar quais informações estavam disponíveis quando o atendimento foi iniciado.

A verificação eletrônica de elegibilidade é um processo de implantação opcional. Quando adotada eletronicamente, contudo, deve seguir as especificações aplicáveis ao TISS.

Solicitação e autorização de procedimentos

Depois de confirmar a elegibilidade, o hospital identifica se o serviço exige autorização prévia. Essa necessidade pode variar conforme procedimento, contrato, produto, rede e condição clínica.

A solicitação deve conter informações suficientes para a análise da operadora, incluindo:

• procedimento solicitado;

• código TUSS;

• indicação clínica;

• diagnóstico;

• profissional solicitante;

• prestador executante;

• data prevista;

• quantidade;

• anexos de suporte.

A autorização precisa ser armazenada com número, validade, condições e itens aprovados. Registrar apenas uma imagem ou texto livre dificulta as validações posteriores.

Quando a operadora autoriza parcialmente, solicita complementação ou substitui algum item, a resposta deve ser analisada antes da execução programada. As áreas assistencial e administrativa precisam receber a mesma informação.

Alterações clínicas podem exigir uma nova solicitação ou a complementação da autorização. O hospital deve preservar a rastreabilidade entre o pedido original, as mudanças, as respostas e o atendimento efetivamente realizado.

Comunicação de internação e alta

A comunicação de internação registra a admissão do beneficiário e relaciona o episódio assistencial à autorização correspondente. A comunicação de alta informa o encerramento da permanência.

Esse processo pode envolver:

• data e horário da internação;

• caráter do atendimento;

• tipo e regime de internação;

• acomodação;

• diagnóstico, quando aplicável;

• data e horário da alta;

• motivo de encerramento.

A qualidade desses registros afeta assistência e faturamento. Uma data de alta divergente pode alterar diárias, taxas, medicamentos e outros componentes da conta.

A comunicação também precisa acompanhar prorrogações, transferências e mudanças relevantes. Caso os sistemas assistencial e financeiro utilizem fontes diferentes, deve existir uma rotina de conciliação.

Registro assistencial e captura de itens

Durante o atendimento, profissionais e sistemas produzem os dados que sustentarão a conta. Essa captura inclui procedimentos, medicamentos, materiais, diárias, taxas, gases, honorários e informações clínicas.

Os registros podem se originar em:

• prontuário eletrônico;

• prescrição médica;

• checagem de enfermagem;

• farmácia;

• centro cirúrgico;

• almoxarifado;

• laboratório;

• diagnóstico por imagem;

• hotelaria;

• sistemas de terceiros.

Se um material for utilizado, mas não registrado, pode deixar de ser cobrado. Se for lançado duas vezes, pode gerar cobrança indevida e aumentar o risco de glosa.

Cada item deve manter vínculo com paciente, episódio, data e setor responsável. Para determinados materiais e procedimentos, também é necessário relacionar autorização, lote, número de série ou documentação específica.

A captura automática reduz digitação manual, mas não elimina a necessidade de controle. Interfaces mal configuradas podem replicar erros em grande escala.

Fechamento e auditoria da conta

Após a alta ou o encerramento do atendimento, a conta entra em fechamento. Nessa fase, os dados assistenciais e administrativos são consolidados para formar a cobrança.

Antes do envio, a instituição deve verificar:

• autorização válida;

• compatibilidade entre procedimentos autorizados e executados;

• registros clínicos necessários;

• códigos TUSS vigentes;

• quantidades e unidades de medida;

• valores e regras contratuais;

• vínculo entre guias e anexos;

• duplicidades ou itens ausentes;

• identificação dos profissionais;

• datas de atendimento, internação e alta.

A auditoria pode ser clínica, administrativa e financeira. Cada perspectiva identifica riscos diferentes e contribui para a qualidade final da conta.

Uma conta não deve ser liberada apenas porque todos os campos estão preenchidos. O conteúdo precisa ser coerente com prontuário, autorização e contrato.

Geração, validação e transmissão do lote

Depois de aprovada internamente, a cobrança é convertida em mensagens compatíveis com o Padrão TISS. As guias podem ser agrupadas em lotes conforme as regras do processo.

Antes da transmissão, o sistema deve validar:

• estrutura do XML;

• versão e namespace;

• campos obrigatórios;

• formatos de datas e identificadores;

• códigos e terminologias;

• totais e consistência matemática;

• duplicidade de guias;

• assinatura digital, quando exigida;

• regras específicas da operadora.

A validação estrutural confirma se o arquivo segue o schema. As regras de negócio verificam se as informações fazem sentido diante da autorização, do atendimento e do contrato.

O envio pode ocorrer por webservice ou portal. Independentemente do canal, o hospital deve registrar arquivo, data, horário, versão e sistema responsável.

Protocolo e acompanhamento

A transmissão não termina quando o sistema informa que o arquivo foi enviado. É preciso confirmar se a operadora recebeu e processou o lote.

O acompanhamento deve distinguir estados como:

• enviado;

• recebido;

• em processamento;

• processado;

• processado parcialmente;

• rejeitado;

• cancelado;

• aguardando correção.

Quando há falha de comunicação, o hospital deve consultar o protocolo antes de reenviar. Uma nova transmissão sem essa verificação pode gerar duplicidade.

Se ocorrer rejeição, a equipe precisa identificar se o problema afeta todo o lote ou uma guia específica. A correção deve preservar o histórico do envio original e do reprocessamento.

Demonstrativo de pagamento e conciliação

Depois da análise, a operadora disponibiliza demonstrativos com o resultado das contas. O hospital deve comparar esses dados com o valor faturado e com o crédito efetivamente recebido.

A conciliação responde a três perguntas:

1. Quanto foi apresentado?

2. Quanto foi reconhecido pela operadora?

3. Quanto foi efetivamente pago?

Diferenças podem decorrer de glosas, retenções, coparticipações, ajustes contratuais, compensações ou problemas de processamento. Cada ocorrência precisa ser classificada corretamente.

Uma conciliação eficiente relaciona:

• lote e protocolo;

• guia e item;

• valor cobrado;

• valor liberado;

• valor glosado;

• código da glosa;

• data de pagamento;

• crédito bancário.

O pagamento não deve ser conciliado apenas pelo total do depósito. Sem detalhamento por conta e item, pequenas divergências podem permanecer ocultas.

Glosa, recurso e encerramento do ciclo

Quando a operadora recusa total ou parcialmente um item, ocorre a glosa. O hospital deve verificar o motivo e decidir se a cobrança será corrigida, aceita ou contestada.

As causas podem incluir:

• ausência de autorização;

• código incompatível;

• quantidade divergente;

• documentação insuficiente;

• cobrança em duplicidade;

• valor fora do contrato;

• item não coberto;

• falha de processamento.

Quando houver fundamento, o recurso deve ser apresentado no prazo aplicável. A justificativa precisa estar acompanhada da documentação necessária.

O ciclo só deve ser considerado encerrado quando a conta estiver conciliada, as glosas tiverem sido tratadas e os saldos estiverem corretamente classificados.

Mas há um ponto decisivo: falhas identificadas no pagamento podem ter começado na recepção, na autorização ou no registro assistencial. Para sustentar o fluxo de ponta a ponta, o hospital precisa de uma arquitetura tecnológica igualmente integrada.

Integração TISS: XML, webservices, portais e sistemas hospitalares

Em hospitais de maior porte, as informações necessárias ao TISS raramente estão concentradas em um único sistema. Elas circulam entre aplicações assistenciais, administrativas e financeiras.

O desafio não está apenas em gerar um arquivo XML. É preciso garantir que a mensagem represente corretamente o atendimento registrado em diferentes fontes.

Uma arquitetura simplificada segue este caminho:

Sistemas assistenciais → integração → faturamento → validação TISS → transmissão → operadora → retorno → conciliação

Como o XML estrutura as mensagens TISS

XML significa Extensible Markup Language. Trata-se de uma linguagem utilizada para organizar dados em uma estrutura interpretável por diferentes sistemas.

Em uma mensagem TISS, o XML pode representar:

• identificação da operadora;

• dados do prestador;

• beneficiário;

• número da guia;

• procedimentos e itens;

• datas, quantidades e valores;

• autorizações e protocolos;

• totais do lote;

• assinatura digital, quando aplicável.

Cada informação aparece em um elemento previsto pela estrutura oficial. Posição, formato e relação entre os elementos precisam respeitar a versão utilizada.

Um XML pode estar bem-formado e ainda não atender ao TISS. Ele também precisa seguir o schema correto e as regras de preenchimento.

O namespace identifica o vocabulário e a versão associados ao arquivo. Um namespace incorreto pode causar rejeição antes da análise do conteúdo.

Para que servem os schemas XSD?

XSD significa XML Schema Definition. Os schemas publicados pela ANS definem quais elementos podem aparecer, em que ordem e com quais formatos.

Um XSD pode determinar:

• se o elemento é permitido;

• tipo de dado;

• quantidade de ocorrências;

• tamanho máximo;

• padrão de data ou identificador;

• relação entre elementos simples e compostos.

Na validação, o sistema compara o XML com o schema correspondente. Se a estrutura não atender à definição, o arquivo deve ser corrigido antes da transmissão.

É essencial usar arquivos XSD da mesma versão da mensagem. Os schemas também não devem ser alterados internamente para aceitar documentos incompatíveis, pois isso pode fazer o validador local aprovar o que será recusado pela operadora.

Webservice ou portal?

Os principais canais disponibilizados pelas operadoras são webservices e portais corporativos.

O webservice permite enviar solicitações ou cobranças sem intervenção manual em cada transação. Também pode receber respostas estruturadas para atualizar automaticamente o fluxo interno.

O portal oferece interface para digitação, upload, consulta e download. Pode ser útil em baixo volume, processos específicos ou situações de contingência.

Em hospitais de grande porte, depender apenas do portal tende a aumentar trabalho manual e risco operacional. Mesmo quando o envio ocorre por esse canal, arquivos e protocolos devem ser relacionados às contas internas.

WSDL e camadas de validação

WSDL significa Web Services Description Language. O arquivo descreve como o webservice pode ser acessado, quais operações oferece e quais mensagens espera receber.

No contexto do TISS, pode apoiar operações como:

• envio de lotes;

• solicitação de procedimentos;

• consulta de status;

• cancelamento de guia;

• envio de anexos;

• recurso de glosa;

• verificação de elegibilidade;

• solicitação de demonstrativos.

A existência da operação no pacote técnico não significa que ela esteja implantada em toda relação entre prestador e operadora. É necessário verificar quais serviços estão disponíveis.

A validação deve ocorrer em diferentes camadas:

1. XML bem-formado: verifica a sintaxe.

2. Validação XSD: confere a estrutura oficial.

3. Validação de preenchimento: avalia campos obrigatórios e condicionados.

4. Validação semântica: verifica códigos, datas e relações.

5. Validação contratual: compara autorização, valores e negociação.

6. Validação assistencial: confirma suporte clínico e documental.

Um arquivo aprovado nas duas primeiras camadas ainda pode ser recusado nas demais. Essa distinção evita atribuir toda rejeição a um problema técnico.

Integração com HIS, ERP, PEP, LIS, RIS e PACS

A arquitetura deve identificar qual sistema é a fonte oficial de cada informação.

Entre os sistemas envolvidos estão:

• HIS: sistema de informação hospitalar;

• ERP: gestão administrativa, contábil e financeira;

• PEP: prontuário eletrônico do paciente;

• LIS: sistema de informação laboratorial;

• RIS: sistema de informação radiológica;

• PACS: armazenamento e comunicação de imagens;

• sistemas de farmácia e suprimentos;

• módulos de autorização e faturamento;

• plataformas de auditoria e ciclo de receita.

Uma matriz de propriedade do dado pode ser organizada assim:

Quando dois sistemas podem alterar o mesmo campo sem regra de precedência, surgem divergências. A integração deve definir fonte oficial, momento da atualização e tratamento de conflitos.

Também é recomendável utilizar identificadores consistentes para beneficiário, atendimento, internação, guia e lote. Sem essas chaves, torna-se difícil relacionar eventos de sistemas diferentes.

Certificado digital e assinatura XAdES

Determinadas mensagens exigem assinatura digital. O objetivo é preservar integridade, identificar a origem institucional e oferecer não repúdio.

A documentação considerada neste artigo enfatiza o uso de certificado e-CNPJ referente à instituição transmissora. Quando o agente atua como pessoa física, utiliza-se o e-CPF.

A assinatura segue o padrão XAdES, em formato Enveloped, nas condições técnicas aplicáveis. Nesse formato, os dados da assinatura são incorporados ao próprio XML.

A gestão do certificado deve incluir:

• titularidade correta;

• cadeia de confiança;

• prazo de validade;

• armazenamento seguro da chave privada;

• controle de acesso;

• renovação antecipada;

• testes após substituição.

Um certificado expirado pode interromper transmissões mesmo quando todo o restante está correto. Alertas de vencimento precisam fazer parte do monitoramento.

Logs, protocolos e prevenção de duplicidade

É necessário reconstruir o que foi enviado, quando ocorreu, qual resposta foi recebida e como o sistema reagiu.

Os logs devem registrar, conforme a política de segurança:

• data e horário;

• operação;

• operadora;

• versão;

• identificadores do lote e da guia;

• resultado;

• código de retorno;

• tempo de resposta;

• tentativa de reenvio.

Isso não significa armazenar dados sensíveis em texto aberto. Os registros devem conter apenas o necessário e receber controles de acesso e retenção.

A idempotência evita que uma repetição técnica produza efeitos duplicados. Se houver dúvida sobre a resposta da operadora, o sistema não deve reenviar automaticamente sem consultar protocolo e status.

Mesmo quando o serviço externo não oferece mecanismo explícito de idempotência, o hospital pode usar identificadores, estados transacionais e bloqueios internos.

Homologação e testes de regressão

Antes de migrar uma versão ou integrar nova operadora, o hospital deve utilizar o ambiente de homologação disponível. Testar apenas um arquivo simples não representa a operação real.

O plano deve incluir:

• consultas;

• SP/SADT;

• internações;

• honorários;

• materiais e medicamentos;

• OPME;

• lotes com várias guias;

• cancelamentos;

• retornos;

• recursos de glosa;

• respostas de erro.

Também devem ser testados cenários negativos, como campo ausente, código inativo e certificado inválido. Isso confirma se o sistema identifica o problema antes do envio.

Os testes de regressão verificam se a atualização comprometeu processos que funcionavam anteriormente. Cada caso deve ter entrada, resultado esperado, versão, evidência e responsável pela aprovação.

APIs e FHIR não substituem automaticamente o TISS

APIs modernas podem facilitar a integração interna, e o padrão FHIR tem ganhado relevância na interoperabilidade em saúde. Essas tecnologias podem coexistir com o TISS.

Um hospital pode utilizar APIs ou recursos FHIR internamente e converter os dados para a mensagem exigida na relação com a operadora. Contudo, os formatos não são automaticamente intercambiáveis.

A adoção de uma API só substitui determinado fluxo quando existe especificação oficial ou acordo válido que preserve os requisitos regulatórios. Uma interface moderna sem a mensagem necessária pode ser tecnicamente elegante, mas não conforme.

Quanto maior o número de integrações, maior a atenção exigida sobre proteção de dados. É o que veremos a seguir.

Segurança, privacidade e LGPD no tratamento de dados TISS

As mensagens TISS movimentam informações clínicas, cadastrais e financeiras. Quanto mais automatizado o fluxo, maior a necessidade de controlar quem acessa os dados, como eles são transmitidos e por quanto tempo permanecem armazenados.

O Componente de Segurança e Privacidade estabelece requisitos específicos para proteger os dados de atenção à saúde. Esses controles devem atuar em conjunto com a Lei Geral de Proteção de Dados (LGPD), o sigilo profissional e as políticas internas.

Por que os dados são sensíveis?

As mensagens podem identificar diretamente o beneficiário e revelar diagnóstico, tratamento, internação, medicamentos e procedimentos. Pela LGPD, informações de saúde são dados pessoais sensíveis.

Um arquivo pode combinar:

• identificadores do beneficiário;

• data de nascimento;

• número da carteira;

• diagnóstico;

• procedimentos;

• medicamentos;

• datas de internação e alta;

• profissionais;

• valores assistenciais.

Mesmo sem o nome completo, a combinação de identificadores pode permitir a individualização. Substituir um campo nominal por código não torna o conjunto automaticamente anônimo.

O risco também não está restrito ao vazamento externo. Acesso interno excessivo, uso incompatível e retenção sem critério também podem violar a privacidade.

Requisitos de segurança e privacidade

O componente aborda princípios como:

• confidencialidade;

• integridade;

• disponibilidade;

• autenticação;

• controle de acesso;

• rastreabilidade;

• preservação do sigilo;

• continuidade dos serviços.

Confidencialidade impede acesso não autorizado. Integridade busca evitar alteração indevida, enquanto disponibilidade assegura que os dados estejam acessíveis quando necessário.

A classificação de um requisito como opcional não elimina outras obrigações. Contratos, legislação e análise de risco podem exigir controle mais rigoroso.

Controle de acesso e menor privilégio

O acesso deve ser concedido conforme a função profissional. Cada pessoa deve visualizar ou alterar apenas as informações necessárias às suas atividades.

Uma política adequada considera:

• perfis por função;

• separação entre consulta, alteração e transmissão;

• autenticação individual;

• revisão periódica das permissões;

• bloqueio após tentativas malsucedidas;

• revogação no desligamento;

• autenticação adicional em operações críticas;

• controle de contas técnicas.

Credenciais compartilhadas dificultam auditoria e responsabilização. Contas de serviço precisam ter finalidade documentada e acesso limitado.

Criptografia em trânsito e em repouso

Os dados precisam ser protegidos durante a transmissão e enquanto permanecem armazenados.

Na transmissão, os canais devem utilizar protocolos seguros e configurações atualizadas. Certificados de servidor precisam ser válidos, e conexões inseguras não devem ser aceitas apenas para contornar falhas.

No armazenamento, a instituição deve proteger:

• bancos de dados;

• arquivos XML;

• anexos clínicos;

• backups;

• pastas de integração;

• servidores;

• estações administrativas;

• ambientes de homologação.

A criptografia em repouso deve ser acompanhada de gestão segura das chaves. Pastas temporárias também merecem atenção, pois podem manter arquivos sensíveis esquecidos após o processamento.

Certificados e não repúdio

O certificado digital ajuda a comprovar a origem da mensagem e a preservar sua integridade. A assinatura oferece propriedades diferentes da criptografia do canal.

Ela pode:

• identificar a origem;

• permitir detecção de alterações;

• reforçar autenticidade;

• contribuir para o não repúdio.

Isso não significa que a assinatura esconda o conteúdo. A confidencialidade depende do canal e dos demais controles.

Logs, retenção e descarte

Logs permitem reconstruir atividades e investigar falhas. Entretanto, registrar tudo sem critério pode criar um novo repositório de dados sensíveis.

Sempre que possível, os registros devem usar identificadores técnicos em vez de reproduzir diagnósticos, nomes ou documentos completos.

A política de retenção deve definir:

• finalidade da guarda;

• prazo;

• fundamento;

• local;

• nível de acesso;

• forma de arquivamento;

• procedimento de descarte.

Não existe um único prazo aplicável a todo dado apenas porque ele circulou pelo TISS. Quando a guarda deixa de ser necessária, o descarte deve alcançar arquivos temporários, cópias e demais repositórios aplicáveis.

Incidentes e continuidade operacional

Mesmo com controles preventivos, incidentes podem ocorrer. O hospital deve estar preparado para identificar, conter, investigar e corrigir eventos.

São exemplos:

• envio para operadora errada;

• acesso não autorizado;

• comprometimento de certificado;

• alteração indevida;

• perda de protocolos;

• malware no servidor;

• exportação não autorizada.

O plano de resposta deve priorizar:

1. Conter o incidente.

2. Preservar evidências.

3. Identificar dados e titulares afetados.

4. Avaliar risco e impacto.

5. Corrigir a causa.

6. Cumprir obrigações de comunicação.

7. Documentar as decisões.

8. Prevenir recorrências.

A continuidade também precisa considerar indisponibilidade de portal, webservice, certificado ou sistema interno. Canais alternativos não devem ser improvisados com aplicativos pessoais ou contas não autorizadas.

TISS e LGPD são complementares

Cumprir os requisitos de segurança do TISS ajuda a proteger as informações, mas não garante conformidade integral com a LGPD.

O hospital também precisa avaliar:

• finalidade do tratamento;

• base legal;

• papéis de controlador e operador;

• direitos dos titulares;

• minimização;

• compartilhamentos;

• retenção;

• resposta a incidentes.

O consentimento não deve ser apresentado como base automática para todo tratamento de dados em saúde. A LGPD prevê diferentes hipóteses legais, cuja aplicação depende da finalidade e do contexto.

Da mesma forma, os papéis de controlador e operador não podem ser definidos apenas porque uma instituição é hospital ou operadora. É necessário analisar quem toma as decisões sobre cada tratamento.

Segurança e qualidade operacional estão diretamente relacionadas. Integrações mal monitoradas dificultam não apenas a proteção dos dados, mas também a identificação de erros, rejeições e glosas.

Erros no TISS, rejeições e glosas: causas e como corrigir

Os termos erro, rejeição e glosa não devem ser usados como sinônimos. Cada ocorrência representa uma etapa diferente e exige um tratamento específico.

Erro, rejeição ou glosa?

Um erro de arquivo ocorre quando a mensagem apresenta problema técnico ou estrutural. XML malformado, namespace incorreto e incompatibilidade com o schema são exemplos.

A rejeição indica que o lote, a guia ou uma informação não foi aceito para processamento. Pode decorrer de falha técnica, campo inconsistente, duplicidade ou regra de negócio.

A glosa ocorre quando a operadora recusa total ou parcialmente o pagamento após analisar a cobrança. A conta pode ter sido recebida tecnicamente, mas algum aspecto assistencial, administrativo ou contratual foi questionado.

A classificação correta evita retrabalho. Encaminhar XML inválido para auditoria médica não resolve o problema técnico; reenviar arquivo idêntico não corrige divergência contratual.

Versão ou namespace incompatível

Se o hospital gerar uma versão não aceita, o processamento pode ser interrompido. O namespace também deve corresponder à estrutura oficial.

As causas incluem:

• atualização parcial;

• schema antigo;

• configuração diferente entre unidades;

• operadora cadastrada com versão incorreta;

• homologação diferente da produção;

• fornecedor que atualizou apenas parte do pacote.

A equipe deve comparar o XML com a versão configurada e com a versão aceita pela operadora. Também precisa confirmar se todos os arquivos XSD pertencem ao mesmo conjunto.

XML fora do schema

Um XML apresenta erro estrutural quando contém elemento desconhecido, ordem incorreta, formato inválido ou quantidade diferente da permitida.

Exemplos:

• data em formato incompatível;

• elemento ausente;

• texto acima do limite;

• tipo de dado incorreto;

• elemento repetido;

• caractere inválido;

• fechamento incorreto de tag.

Quando um erro é detectado, a mensagem do validador deve ser relacionada à origem do dado. Corrigir manualmente o XML sem ajustar o sistema fará o problema reaparecer.

Campos ausentes ou inconsistentes

Nem todo campo obrigatório é definido apenas pelo XSD. Alguns dependem do tipo de atendimento ou da presença de outro dado.

São exemplos:

• profissional executante ausente;

• autorização não informada;

• regime incompatível;

• data incoerente;

• quantidade sem unidade;

• indicação clínica necessária;

• motivo de encerramento incompatível.

As regras devem ser aplicadas o mais próximo possível da captura. Esperar a geração do lote para descobrir uma informação clínica ausente torna a correção mais lenta.

Código TUSS inválido ou inativo

A existência de um código não garante que a cobrança esteja correta. O termo precisa estar vigente e ser coerente com o tipo de item.

Os problemas incluem:

• código inativo;

• tabela incorreta;

• código SIGTAP em fluxo TISS;

• código próprio mantido indevidamente;

• procedimento incompatível com a guia;

• unidade de medida inadequada;

• material registrado como medicamento.

A equipe deve consultar o histórico da terminologia e a data do atendimento. O código não deve ser substituído apenas por semelhança textual.

Divergência entre autorização, atendimento e cobrança

É necessário comparar o que foi solicitado, autorizado, executado e cobrado. As quatro informações podem divergir por erro ou evolução clínica legítima.

As diferenças mais comuns são:

• código executado diferente do autorizado;

• quantidade superior;

• procedimento adicional;

• material não previsto;

• autorização expirada;

• prestador diferente;

• data fora do período;

• ausência de justificativa.

Nem toda diferença representa cobrança indevida. O problema surge quando a alteração clínica não é comunicada ou documentada.

Dados cadastrais

Dados incorretos podem impedir que a operadora relacione a guia ao beneficiário ou prestador.

É necessário verificar:

• identificação do beneficiário;

• validade da carteira;

• nome e data de nascimento;

• registro da operadora;

• CNPJ ou CPF;

• CNES, quando aplicável;

• conselho profissional;

• especialidade ou CBO;

• código do prestador.

Cadastros mestres precisam de responsáveis e mecanismos de sincronização. Corrigir o ERP sem atualizar o faturamento não resolve a inconsistência.

Leia também: ERP hospitalar

Valores divergentes do contrato

O TISS padroniza a troca, mas não define automaticamente o preço. Uma glosa contratual pode decorrer de:

• tabela desatualizada;

• vigência incorreta;

• percentual não aplicado;

• pacote cobrado como conta aberta;

• item do pacote cobrado separadamente;

• diária divergente;

• valor de material fora da negociação;

• taxa duplicada.

A gestão de contratos precisa atuar integrada ao faturamento. Um aditivo só produz efeito operacional quando suas regras são configuradas, testadas e comunicadas.

Como interpretar os retornos

A resposta da operadora deve ser lida em conjunto com a mensagem enviada. Um código isolado pode não fornecer contexto suficiente.

A análise precisa identificar:

1. Arquivo ou lote de origem.

2. Guia ou item afetado.

3. Etapa do problema.

4. Código e descrição.

5. Campo relacionado.

6. Correção, reenvio ou recurso.

7. Prazo aplicável.

A Tabela 38 da TUSS organiza mensagens de glosas, negativas e outras ocorrências. Os retornos devem ser importados de forma estruturada sempre que possível.

Diagnóstico rápido

Análise de causa raiz

Corrigir uma conta resolve o caso individual, mas não impede a repetição. A análise de causa raiz identifica onde o problema foi criado e por que não foi detectado antes.

As causas podem ser classificadas em:

• cadastro;

• autorização;

• registro assistencial;

• terminologia;

• contrato;

• integração;

• configuração;

• treinamento;

• processo;

• indisponibilidade externa.

Para cada ocorrência, a equipe deve perguntar:

• Onde o erro surgiu?

• Em qual etapa deveria ter sido detectado?

• Por que o controle falhou?

• Quantas contas podem estar afetadas?

• Qual correção sistêmica é necessária?

• Como sua eficácia será verificada?

Reduzir glosas exige mais do que correções pontuais. O hospital precisa transformar essas práticas em um programa estruturado de implantação e governança.

Como implementar ou atualizar o Padrão TISS em um hospital

A implantação deve ser conduzida como projeto institucional. Atualizar apenas o gerador de XML não é suficiente quando os dados de origem, os contratos e os processos continuam incorretos.

Para implementar ou atualizar o Padrão TISS em um hospital, é essencial contar com um sistema hospitalar integrado, capaz de padronizar o envio de informações às operadoras, validar guias, reduzir erros de faturamento e acompanhar as atualizações exigidas pela ANS. A tecnologia também facilita a integração entre recepção, assistência, auditoria e setor financeiro, tornando o processo mais seguro, ágil e eficiente.

Diagnóstico e inventário

O primeiro passo é compreender a situação atual.

A avaliação deve considerar:

• operadoras atendidas;

• volume de guias;

• versões;

• canais;

• sistemas;

• integrações;

• processos manuais;

• certificados;

• rejeições e glosas;

• capacidade de homologação;

• documentação.

O inventário precisa registrar sistema de origem, destino, informação, frequência, tecnologia, responsável, criticidade e monitoramento. Planilhas e rotinas informais também devem entrar no levantamento.

Mapeamento de operadoras e contratos

Para cada operadora, registre:

• nome e registro;

• produtos;

• contrato e aditivos;

• versão aceita;

• webservice;

• portal;

• Coordenador TISS;

• credenciais;

• certificado;

• prazos;

• regras de autorização;

• homologação.

Os contratos devem estar vinculados às tabelas de preço, pacotes e regras de faturamento. Uma integração tecnicamente correta pode gerar glosa se utilizar condição contratual inadequada.

Matriz RACI

A matriz RACI esclarece quem executa, aprova, é consultado ou informado.

• R — Responsável: executa.

• A — Aprovador: responde pela decisão.

• C — Consultado: contribui.

• I — Informado: acompanha.

Cada atividade deve possuir um aprovador claramente identificado. A matriz precisa refletir a estrutura real da instituição.

Atualização de cadastros e terminologias

Antes de implantar novo layout, o hospital deve revisar:

• beneficiários;

• operadoras e produtos;

• prestadores;

• profissionais e conselhos;

• especialidades e CBO;

• procedimentos;

• medicamentos;

• materiais e OPME;

• unidades de medida;

• contratos e preços.

Inclusões, alterações e inativações da TUSS devem ser comparadas com os códigos internos. Quando houver códigos próprios, é necessário manter correspondências controladas.

Também é preciso respeitar a vigência. Uma atualização sem contexto pode alterar indevidamente contas de atendimentos anteriores.

Adequação dos sistemas

A equipe de TI deve transformar alterações regulatórias em requisitos técnicos.

A análise deve verificar:

• novos elementos;

• campos alterados;

• mudanças de obrigatoriedade;

• novos tipos de mensagem;

• formatos;

• schemas;

• assinatura;

• tabelas de domínio;

• retornos;

• compatibilidade histórica.

Desenvolvimento, homologação e produção devem permanecer separados. Customizações locais merecem atenção, pois uma atualização pode funcionar no produto padrão e falhar no ambiente do hospital.

Homologação com operadoras

A homologação confirma se hospital e operadora conseguem trocar mensagens na versão pretendida.

O processo inclui:

1. Acesso ao ambiente.

2. Configuração de endpoints e certificados.

3. Envio de testes.

4. Validação dos retornos.

5. Correção das divergências.

6. Repetição dos cenários.

7. Registro da aprovação.

8. Agendamento da produção.

A homologação deve incluir o caminho de retorno. Confirmar apenas o envio não demonstra que protocolos, demonstrativos e erros serão processados corretamente.

Testes e treinamento

O conjunto de testes deve abranger cenários simples, contas complexas, materiais, medicamentos, anexos, honorários, cancelamentos, retornos e erros intencionais.

Cada caso precisa ter resultado esperado. Também devem ser avaliados volume e desempenho.

O treinamento deve ser adaptado ao papel de cada área:

• recepção: elegibilidade e cadastro;

• autorização: solicitações e protocolos;

• assistência: documentação clínica;

• farmácia: códigos e unidades;

• auditoria: coerência da conta;

• faturamento: guias, retornos e glosas;

• TI: integrações e monitoramento;

• gestão: riscos e indicadores.

Treinamentos genéricos não resolvem falhas específicas. As equipes precisam praticar as mudanças que encontrarão na rotina.

Implantação, contingência e rollback

A entrada em produção deve considerar risco, volume e capacidade de suporte. Mudanças próximas ao fechamento mensal podem ampliar o impacto de falhas.

Antes da implantação, confirme:

• backup das configurações;

• pacote aprovado;

• certificados válidos;

• comunicação às áreas;

• suporte disponível;

• critérios de sucesso;

• procedimento de rollback;

• plano de contingência.

O rollback é o retorno à configuração anterior quando a nova versão apresenta falha grave. Seus critérios podem incluir rejeição generalizada, impossibilidade de gerar guias, falha de assinatura, perda de dados ou inconsistência financeira.

Depois da entrada em produção, acompanhe transmissões, filas, rejeições, erros e chamados. O projeto não deve ser encerrado no primeiro envio bem-sucedido.

Cronograma de 30, 60 e 90 dias

Primeiros 30 dias — diagnóstico

• inventariar sistemas;

• mapear operadoras;

• analisar atualização;

• definir RACI;

• identificar riscos;

• elaborar testes.

Até 60 dias — configuração

• atualizar terminologias;

• corrigir cadastros;

• instalar pacotes;

• ajustar integrações;

• configurar certificados;

• iniciar homologações.

Até 90 dias — implantação

• concluir homologações;

• treinar equipes;

• executar mudança;

• acompanhar produção;

• corrigir incidentes;

• medir resultados.

O cronograma deve ser ajustado ao prazo oficial da ANS. Se a data regulatória for menor, o projeto precisa ser antecipado.

Sem métricas, porém, a instituição sabe que implantou a versão, mas não consegue demonstrar se houve melhoria. É por isso que a última etapa é transformar o fluxo em indicadores.

Indicadores TISS: como medir qualidade, eficiência e impacto financeiro

Os indicadores devem acompanhar aspectos técnicos, operacionais e financeiros. Um painel limitado ao valor faturado pode ocultar rejeições, atrasos e custos de retrabalho.

Cada KPI precisa ter:

• fórmula;

• fonte;

• periodicidade;

• responsável;

• segmentações;

• meta ou limite;

• regra para exceções.

Taxa de rejeição técnica

A fórmula básica é:

Taxa de rejeição = quantidade rejeitada ÷ quantidade transmitida × 100

A instituição deve definir se a unidade é lote, guia ou item. Misturar unidades distorce o resultado.

Também é recomendável segmentar por:

• versão;

• operadora;

• código de erro;

• unidade;

• sistema;

• tipo de guia.

Uma elevação repentina após atualização pode indicar falha de configuração. Concentração em uma operadora pode sinalizar problema específico de integração.

Índice de glosa e recuperação

O índice de glosa inicial pode ser calculado assim:

Glosa inicial = valor inicialmente glosado ÷ valor apresentado × 100

Para avaliar os recursos:

Recuperação sobre o recorrido = valor revertido ÷ valor recorrido × 100

Também é possível medir:

Recuperação sobre a glosa total = valor revertido ÷ valor inicialmente glosado × 100

A primeira fórmula avalia a efetividade dos recursos. A segunda mostra quanto da perda inicial foi recuperado.

Uma recuperação elevada pode demonstrar boa atuação da equipe, mas também indicar que muitas glosas evitáveis estão sendo tratadas apenas depois do pagamento.

Percentual de automação

A fórmula sugerida é:

Contas automatizadas = contas enviadas sem intervenção manual ÷ total enviado × 100

A instituição precisa definir o que considera intervenção manual. Editar XML, corrigir cadastro, alterar código ou reenviar pelo portal são exemplos.

Automação elevada não significa qualidade. Se o processo transmite rapidamente dados incorretos, o hospital apenas automatizou o erro.

Esse indicador deve ser analisado junto à rejeição e à glosa.

Tempo entre alta e envio

O intervalo influencia diretamente o ciclo de receita.

É útil medir:

1. Alta até fechamento.

2. Fechamento até auditoria.

3. Auditoria até transmissão.

A fórmula total é:

Tempo de alta até envio = data da transmissão − data da alta

A mediana pode ser mais representativa do que a média, pois contas complexas geram valores extremos. A análise também deve separar internação, ambulatório e contas de alta complexidade.

Tempo de autorização

A fórmula é:

Tempo de autorização = resposta − solicitação válida

O termo “solicitação válida” é importante. Se o hospital envia documentação incompleta, o período de complementação precisa ser analisado separadamente.

O painel pode distinguir:

• autorização imediata;

• pendência;

• complementação;

• negativa;

• autorização parcial;

• tempo interno;

• tempo da operadora.

Prazo de recebimento

Uma fórmula operacional é:

Prazo de recebimento = data do crédito − data de envio da conta aceita

A expressão “conta aceita” separa atraso financeiro de rejeição técnica. Quando o arquivo não foi processado, o prazo de pagamento pode ainda nem ter começado.

Além da média, acompanhe o envelhecimento dos saldos em faixas, como até 30, de 31 a 60, de 61 a 90 e acima de 90 dias.

Índice de retrabalho

A fórmula sugerida é:

Retrabalho = contas com correção ou reenvio ÷ total enviado × 100

As causas devem ser classificadas em:

• cadastro;

• autorização;

• documentação;

• TUSS;

• contrato;

• XML;

• indisponibilidade;

• erro de usuário;

• integração.

Também é útil converter o retrabalho em horas e custo. Essa medida ajuda a justificar automações, treinamento e correções sistêmicas.

Completude e qualidade cadastral

A fórmula básica é:

Completude = registros com campos críticos válidos ÷ registros avaliados × 100

Completude não significa apenas presença. Um campo preenchido com valor genérico ou desatualizado continua apresentando baixa qualidade.

O hospital deve avaliar:

• completude: o dado existe;

• validade: atende à regra;

• consistência: não contradiz outro campo;

• atualidade: representa a situação vigente.

Dashboard executivo

Um dashboard pode ser dividido em quatro blocos:

Qualidade técnica

• rejeição;

• erros por versão;

• indisponibilidade;

• tempo de processamento.

Eficiência operacional

• alta até envio;

• automação;

• retrabalho;

• contas pendentes.

Desempenho financeiro

• valor apresentado;

• glosa;

• recuperação;

• prazo de recebimento;

• saldo em aberto.

Qualidade dos dados

• completude;

• códigos inativos;

• contas sem autorização;

• divergências de unidade.

O painel deve permitir filtros por operadora, unidade, especialidade, período e tipo de atendimento. Cada alerta precisa estar ligado a um responsável e a uma ação esperada.

Algumas relações ajudam na interpretação:

• automação alta e rejeição alta: corrigir regras automatizadas;

• rejeição baixa e glosa alta: investigar autorização, documentação ou contrato;

• glosa e recuperação altas: prevenir causas evitáveis;

• alta até envio elevada: localizar gargalos internos;

• envio rápido e recebimento lento: revisar contrato e conciliação;

• retrabalho concentrado: investigar processo ou treinamento local.

Com indicadores bem definidos, o TISS deixa de ser visto apenas como obrigação técnica. Ele passa a fornecer evidências sobre qualidade dos dados, eficiência operacional e desempenho financeiro.

Quer transformar a conformidade com o Padrão TISS em uma operação mais integrada, segura e eficiente? Conheça o Sistema Colmeia e veja como a tecnologia pode apoiar a gestão assistencial, administrativa e financeira do seu hospital, reduzir tarefas manuais e ampliar a visibilidade sobre o ciclo de receita.