TISS e TUSS: como a padronização conecta informações na saúde suplementar

Uma operadora recebe informações de hospitais, clínicas e outros participantes de sua rede. Esses dados precisam ser compreendidos, relacionados aos registros internos e utilizados nos processos correspondentes.

Quando cada sistema representa a mesma informação de uma forma diferente, a comunicação exige mais conferências e ajustes. Um código pode ter significado apenas no cadastro de origem. Uma quantidade pode ser interpretada com outra unidade. Uma atualização pode chegar sem o vínculo necessário com a solicitação original.

TISS e TUSS ajudam a construir referências comuns para essa comunicação. Embora apareçam juntos na rotina da saúde suplementar, possuem funções distintas.

Neste artigo, explicamos os principais conceitos e mostramos como a integração pode apoiar as operadoras a interpretar e direcionar informações recebidas no padrão TISS ou preparadas para uma troca nesse padrão.

O que é TISS?

TISS significa Troca de Informação de Saúde Suplementar. É o padrão estabelecido pela Agência Nacional de Saúde Suplementar, a ANS, para as trocas eletrônicas de dados de atenção à saúde dos beneficiários entre os agentes da saúde suplementar. [1]

Segundo a ANS, seus objetivos incluem padronizar ações administrativas, apoiar a avaliação e o acompanhamento econômico, financeiro e assistencial das operadoras e compor o registro eletrônico de saúde. A interoperabilidade também faz parte de sua diretriz. [1]

Isso significa que TISS deve ser compreendido como um conjunto de regras para a troca de informações. O arquivo transmitido é uma parte da implementação desse conjunto.

Para a operação, a pergunta central é: quais informações precisam ser trocadas, como devem ser representadas e quais regras se aplicam à mensagem?

Os cinco componentes do padrão TISS

A ANS organiza o padrão em cinco componentes. Cada um cobre uma dimensão da troca de informações. [2]

Essa divisão ajuda a avaliar uma integração por diferentes perspectivas. Uma mensagem pode ter sua estrutura reconhecida pelo sistema e, ainda assim, depender de verificações sobre o conteúdo, a terminologia ou o processo ao qual pertence.

Por isso, a implantação precisa envolver tanto a equipe técnica quanto os responsáveis pelos processos e pelos cadastros utilizados na operação.

O que é TUSS?

TUSS significa Terminologia Unificada da Saúde Suplementar. Ela integra o componente de representação de conceitos em saúde do TISS. [2]

A ANS disponibiliza tabelas com códigos padronizados para procedimentos, materiais, medicamentos, diárias, taxas, órteses, próteses e outros itens. Essas terminologias estão organizadas em tabelas numeradas. [3]

Na prática, a TUSS oferece referências para identificar o que está sendo informado. Ao trabalhar com seus códigos, o sistema precisa considerar também a tabela correspondente e o contexto do registro.

Em um projeto de integração, isso exige atenção aos cadastros: qual item o código representa, como ele se relaciona ao cadastro interno e quais características adicionais precisam acompanhar a mensagem?

Qual é a diferença entre TISS e TUSS?

Uma distinção útil é entender que TISS organiza a troca de informações e TUSS padroniza termos utilizados nessa troca.

Uma mensagem TISS pode utilizar códigos TUSS. A utilização de um código TUSS em uma planilha ou em um cadastro, por sua vez, não transforma esse conteúdo automaticamente em uma mensagem TISS.

Para que exista uma troca no padrão, é necessário atender aos requisitos aplicáveis à mensagem e aos demais componentes envolvidos.

TUSS, cobertura e preço são assuntos diferentes

A identificação de um item não deve ser confundida com uma decisão de autorização ou uma definição de valor.

A ANS mantém instrumentos distintos para a terminologia e para o Rol de Procedimentos e Eventos em Saúde, incluindo uma correlação entre TUSS e Rol. O Rol trata da cobertura obrigatória, considerando o tipo de plano e as regras aplicáveis. [4]

Portanto, um código recebido deve ser interpretado como uma referência de identificação. Ele não deve ser utilizado, isoladamente, como decisão automática sobre cobertura, autorização ou pagamento.

Na integração, essas dimensões precisam permanecer separadas: o que foi solicitado, quais verificações são necessárias, quem tem responsabilidade pela decisão e quais condições comerciais se aplicam.

Essa separação evita atribuir à terminologia uma função que pertence à análise do processo.

Por que a padronização é importante para as operadoras?

Referências comuns tornam a comunicação mais organizada. Elas permitem que o projeto estabeleça critérios de preenchimento, interpretação e validação que possam ser compartilhados entre os envolvidos.

Na aplicação ao dia a dia, isso pode apoiar três objetivos.

Mais consistência na interpretação

Um registro deve continuar representando a mesma demanda depois de passar de um sistema para outro. A padronização ajuda a definir essa referência; os mapeamentos e as validações cuidam de sua aplicação entre cadastros e interfaces.

Menos transferências manuais

Quando o sistema de destino consegue utilizar os dados recebidos, a equipe pode reduzir a necessidade de copiar campos entre ferramentas. Esse resultado depende da integração implantada e deve ser medido na operação.

Melhor acompanhamento das informações

Solicitações, itens, respostas e atualizações precisam permanecer relacionados. Esse vínculo ajuda a localizar pendências e compreender a trajetória do registro, em vez de reconstruí-la por mensagens dispersas.

A padronização cria uma base comum. A integração torna essa base utilizável no processo.

Receber um XML não significa concluir a integração

XML é o formato adotado no componente de comunicação do TISS. [2] Sua presença em um arquivo, porém, não demonstra por si só que o conteúdo atende ao padrão ou pode ser utilizado sem outras verificações.

Um projeto pode organizar as validações em camadas:

• Estrutura: o conteúdo segue o esquema esperado para a mensagem e a versão?
• Conteúdo: os campos obrigatórios estão presentes e os valores são consistentes?
• Identificação: os códigos e suas tabelas possuem correspondência adequada?
• Contexto: a informação está relacionada à solicitação e aos itens corretos?
• Destino: o sistema que receberá os dados dispõe dos campos e da interface necessários?

Essas perguntas são um roteiro prático de engenharia, e não uma lista exaustiva dos requisitos da ANS.

Uma confirmação de recebimento também precisa ser diferenciada da aceitação de conteúdo e da aprovação de negócio. Cada resposta deve ter significado claro para as equipes.

E quando os dados vêm de outros formatos?

Os sistemas envolvidos podem utilizar APIs, arquivos CSV, webservices proprietários ou registros consultados no banco de dados.

Nesses cenários, a conversão precisa relacionar os campos da origem ao modelo necessário para a troca. Isso envolve mais do que alterar a extensão do arquivo ou transformar uma estrutura em XML.

É necessário verificar se a origem contém as informações exigidas, se os códigos possuem correspondência validada e se o processo permite gerar a mensagem prevista.

Quando falta um dado, a integração deve tornar essa ausência visível. Ela não deve inventar informações para preencher campos nem escolher silenciosamente uma correspondência ambígua.

Em outros casos, o caminho é inverso: a operadora recebe uma mensagem TISS e precisa transformar parte de seu conteúdo para uma interface interna ou para outro sistema. A representação de destino pode ser diferente, desde que preserve as informações necessárias e respeite o contexto da troca.

O cuidado com códigos internos e características dos itens

Considere um exemplo ilustrativo: um medicamento está cadastrado no ERP com um código interno, enquanto outro sistema utiliza uma referência diferente para identificá-lo.

Um mapeamento deve estabelecer a relação entre esses registros. A conferência pode envolver descrição, apresentação, concentração e unidade, conforme a natureza do item e o escopo da integração.

Isso também importa em OPME — órteses, próteses e materiais especiais. Uma descrição semelhante, isoladamente, não deve ser tratada como prova de equivalência entre produtos.

Além do código, quantidade, unidade e demais características relevantes precisam ser preservadas. Se a correspondência não estiver validada, o fluxo deve gerar uma pendência para o responsável adequado.

Esses controles ajudam a evitar uma falsa sensação de precisão: a mensagem chega ao destino, mas representa o item ou a quantidade de forma incorreta.

Como a Conexxa Health auxilia as operadoras

A Conexxa Health atua na conexão entre sistemas de gestão, plataformas de cotação e compras e fornecedores, especialmente nos fluxos de OPME e medicamentos.

Nesse contexto, apoia a operadora a compreender como as informações recebidas ou convertidas se relacionam com seus processos e com os sistemas que precisam utilizá-las.

O desenho da integração pode contemplar as seguintes etapas, conforme o escopo contratado e as interfaces disponíveis.

1. Compreender a origem e o significado dos dados

Identificar o sistema de origem, o tipo de mensagem, os campos disponíveis e a finalidade do envio. A consultoria aproxima a leitura técnica da necessidade operacional.

2. Definir os mapeamentos necessários

Relacionar campos, códigos e referências entre a origem e os destinos, com regras acordadas com a instituição. Informações padronizadas e cadastros internos precisam manter correspondências administráveis.

3. Preparar a informação para o processamento

Organizar os dados em um modelo comum para o fluxo de integração, preservando a identificação da solicitação e de seus itens. Esse modelo interno apoia a comunicação sem alterar o padrão oficial nas trocas em que ele se aplica.

4. Direcionar os dados aos destinos configurados

Encaminhar a demanda conforme as rotas e o workflow definidos pela operação. Uma informação pode ser destinada a uma plataforma de cotação ou compras, por exemplo, de acordo com o desenho e os conectores habilitados.

O conteúdo enviado deve ser adequado à finalidade e à interface do destino. Nem todo sistema recebe XML TISS; em alguns casos, será necessário representar os dados na API ou no formato suportado por ele.

5. Acompanhar devolutivas e pendências

Relacionar respostas ao registro de origem e acompanhar atualizações previstas no escopo. Logs e registros de processamento ajudam a identificar o que foi enviado, qual retorno ocorreu e onde é necessária uma ação.

Em ambientes que exigem uma conexão local, o Conexxa Middleware pode apoiar a leitura, a normalização e o envio dos dados a partir da infraestrutura do cliente, conforme as permissões e a arquitetura acordadas.

Um exemplo aplicado ao fluxo de compras

Imagine uma demanda de medicamento registrada no sistema da operadora, originada de dados recebidos ou preparada a partir de seu cadastro interno.

Primeiro, são identificados os campos e as referências necessários. Em seguida, os mapeamentos e as validações previstos conferem se os itens podem seguir para o processamento.

O workflow direciona a solicitação à plataforma de cotação configurada. A resposta é relacionada ao pedido de origem, e as devolutivas previstas podem ser encaminhadas ao ERP ou aos demais destinos definidos.

Se houver uma divergência, ela deve aparecer como pendência compreensível, preservando o vínculo com a demanda.

Esse é um exemplo de arquitetura, não um fluxo obrigatório do TISS. A cotação comercial possui suas próprias interfaces e regras; sua integração pode aproveitar informações de uma demanda assistencial sem confundir os dois processos.

Atualizações exigem governança

Os componentes do TISS são versionados. A ANS mantém um histórico com competências, datas de vigência e limites de implantação. [5]

Por isso, a instituição precisa acompanhar as publicações e avaliar os efeitos sobre mensagens, tabelas e mapeamentos. Uma atualização pode exigir revisão mesmo quando a interface de transporte continua funcionando.

É útil definir responsáveis pelos cadastros, pelas regras de conversão, pelos testes com os destinos e pelo tratamento de falhas.

Também devem ser considerados os acessos, as credenciais e o conteúdo dos registros de auditoria. A rastreabilidade precisa ajudar a operação sem expor desnecessariamente informações dos beneficiários.

Conclusão: transformar dados padronizados em continuidade operacional

TISS e TUSS têm papéis complementares. O padrão organiza a troca; a terminologia oferece referências comuns para identificar o que está sendo informado.

Seu valor operacional depende de como esses dados são recebidos, interpretados, relacionados e utilizados pelos sistemas envolvidos.

Para as operadoras, integrar significa preservar o contexto da informação e fazê-la chegar ao ponto em que pode apoiar a próxima etapa. Isso exige mapeamentos claros, destinos configurados e acompanhamento das devolutivas.

A Conexxa Health atua nessa conexão: ajuda a organizar o caminho entre a origem dos dados e os sistemas de gestão, cotação, compras e fornecimento que participam da operação.

Sua operadora precisa conectar informações recebidas em TISS ou preparar dados de outros sistemas para uma troca padronizada? Conheça a Conexxa Health e converse sobre o desenho de integração da sua operação.

Fontes e referências

1. ANS — TISS: Padrão para Troca de Informação de Saúde Suplementar. Conceitos, objetivos e diretriz do padrão. Acessar.
2. ANS — Padrão TISS, setembro de 2026. Componentes do padrão e identificação das versões. Acessar.
3. ANS — Códigos da TUSS. Consulta e organização das terminologias. Acessar.
4. ANS — Atualização do Rol de Procedimentos. Papel do Rol e referências de correlação com a TUSS. Acessar.
5. ANS — Histórico das versões dos componentes do padrão TISS. Versionamento, vigência e implantação. Acessar.