Facilitando um pouco as coisas na implementação no Padrão TISS – Parte 1
Leonel Fraga de Oliveira 30/06/2015 16:09

É, meus amigos do NM Tech! Faz muito tempo que não postava um artigo com viés mais técnico por aqui, não é mesmo? Ao adotar neste blog a política de “fazer dele um backup de soluções às minhas dificuldades, e que poderiam ajudar alguém” realmente tem o efeito de produzir poucas postagens, visto que ultimamente não tive a necessidade de fazer algo “fora do comum”.

Há um tempo atrás, necessitei implantar um sistema para faturamento de convênios de saúde privados. Este processo de comunicação entre prestador de serviço de saúde (clínicas particulares, hospitais privados ou públicos, laboratórios, etc.) e as operadoras de planos de saúde é padronizado através do Padrão TISS (Troca de Informação na Saúde Suplementar).

Logo ANS

O Padrão TISS é regulado pela Agência Nacional de Saúde Suplementar (ANS), e a intenção é “ações administrativas, subsidiar as ações de avaliação e acompanhamento econômico, financeiro e assistencial das operadoras de planos privados de assistência à saúde e compor o Registro Eletrônico de Saúde”.

Este protocolo, que é composto de guias impressas, tabelas de termos (exames, medicamentos, códigos diversos, etc.) e parâmetros para transferência eletrônica de dados está no momento da elaboração deste post na versão 3.02.01.

Para maiores informações, entre no link da ANS: http://www.ans.gov.br/prestadores/tiss-troca-de-informacao-de-saude-suplementar

Já leu o que está escrito lá, especialmente no link para a versão 3.02.01? Se sim, viu que há um “Componente de Comunicação”, e que ao baixá-lo e descompactá-lo mostrará diversos arquivos XSD e WSDL, que são respectivamente os schemas XML das guias (que é a versão digital das guias impressas e dicionário de dados cujo modelo está no “Componente de Conteúdo e Estrutura”) e dos webservices que podem ser implementados tanto pelas operadoras de saúde e pelos prestadores de serviço.

O escopo desta série de artigos é a comunicação Prestador –> Operadora, ou seja, vamos construir os arquivos XML das guias para envio para as operadoras de planos de saúde.

Vou admitir que você baixou os arquivos do site da ANS, já sabe como são as guias impressas, os dados que elas possuem, as tabelas de conteúdo padronizados, os schemas XML das guias.

Modelar um banco de dados para armazenar as guias digitadas não é tarefa complicada. Comece pelas tabelas de conteúdo padronizado. Quando fiz essa modelagem, adotei TAB_XX como nome, sendo “XX” o número da tabela TUSS (Terminologia Unificada da Saúde Suplementar). Isto me facilitou ao escrever os JOINS das tabelas de guias, ao vincular rapidamente o dado da guia com o número da tabela correspondente ao campo.

Inserir os dados nessas tabelas vai ser tarefa complicada à partir da planilha Excel. Resolvi escrevendo em uma das colunas a instrução INSERT concatenando com os valores, copiando essa coluna e executando em batch no banco de dados. Fique esperto com o número de linhas que serão executadas por vez, porque se der pau, você conseguirá navegar pelo arquivo rapidamente e corrigir o erro.

Mas como sou bonzinho, vou quebrar essa: no link abaixo disponibilizo instruções INSERT das tabelas TUSS. Não coloquei a estrutura das tabelas (CREATE TABLE), portanto entre em cada arquivo SQL e crie as tabelas e campos necessários. Utilizei sempre VARCHAR como tipo de dado (o tamanho varia conforme o campo, claro).

Download: Scripts de INSERT das tabelas TUSS (Terminilogia Unificada da Saúde Suplementar).

Nas tabelas que armazenam as guias, segui os nomes (adaptando da descrição, claro) e tipos de dado da planilha XLS (que possui uma versão em PDF) “Padrão TISS – Componente de Conteúdo e Estrutura” (o dicionário de dados que falei acima, que contém cada tipo de guia em uma aba, enquanto os arquivos ODT nomeados com as guias contém o modelo impresso), que contém estas informações bem explicadas até.

Um cuidado especial na modelagem deve ser tomado nos campos que são vinculados a uma tabela TUSS. Tomaremos por exemplo uma guia de SP/SADT nos campos correspondentes aos itens da solicitação (campos numerados 24, 25, 26): Código da Tabela, Código do Procedimento e Descrição. Como uma guia possui N itens solicitados, criaremos uma tabela chamada SADTItensSolicitados, contendo os campos um sequencial para facilitar manipulações, o código da tabela, o código do item e puxamos a descrição a partir do código da tabela, certo?

Errado! Para estas situações, as descrições dos itens DEVEM SER armazenadas na própria tabela de itens! Tá certo que modelamos cada tabela TUSS em uma tabela física do banco, mas o número da tabela do item é armazenado como um dado, e não um campo próprio, portanto não podemos utilizar um JOIN, como costumamos fazer.

Só devemos fazer joins com as tabelas TUSS quando um campo irá armazenar dados que estão presentes em uma única tabela TUSS. Vou dar alguns exemplos da própria guia SADT: Código CBO (valores da tabela TUSS nº 24), Código do Motivo de Encerramento (valores na tabela TUSS 39), entre outros.

Quer um exemplo de um registro-detalhe de uma SADT onde usamos um join para pegar uma descrição? Campos Via (nº 43, tabela TUSS 61) e Técnica (nº 44, tabela TUSS 48) da seção “Dados da Execução…” (que por sinal, modelei em uma outra tabela detalhe). O campo “Descrição” (campo 41) é vinculado ao “Código do Procedimento” (código 40), e este depende da tabela TUSS indicada no campo “Tabela” (campo 39). Nestes não dá para utilizar joins, sim armazenamos todos esses valores na tabela.

Percebeu a diferença? Então, quando um registro (normalmente detalhe) possui uma descrição em um campo e o código desta descrição é vinculado a um número de tabela que é armazenado em outro campo do mesmo registro, como nas tabelas de medicamentos e procedimentos, por exemplo não usamos joins.

Terminada a modelagem do banco de dados, hora de construir a UI e classes CRUD para o sistema. Este ponto deixo para você. Pode ser Web ou Desktop, tanto faz, confio na sua criatividade.

Depois de fazer a UI e o CRUD básico, vamos ao que interessa: a montagem e a pré-validação do arquivo XML para entregar para as operadoras de planos de saúde. Mas isso fica para o próximo artigo, porque este já está bem longuinho ;)

Leonel Fraga de Oliveira Leonel Fraga de Oliveira é formado em Processamento de Dados na Faculdade de Tecnologia de São Paulo (FATEC-SP - 2002) e anteriormente em Técnico em Eletrônica, pela ETE Professor Aprígio Gonzaga (lá em 1999).
Atualmente trabalha como Analista de Sistemas na Prefeitura Municipal de São Caetano do Sul - SP
Tem como hobbies DJing (também trabalha como DJ freelancer) e ciclismo, além da manutenção dos sites NeoMatrix Light e NeoMatrix Tech.
Gosta de música eletrônica, tecnologia, cinema (super fã de Jornada nas Estrelas), gastronomia e outras coisas mais.


Compartilhe nas redes sociais

   

Deixe seu comentário

comments powered by Disqus