Com o objetivo de esclarecer dúvidas que ainda existem no mercado sobre o padrão TISS (Troca de Informação em Saúde Suplementar), implantado pela Agência Nacional de Saúde Suplementar (ANS), a SBPC/ML tem reproduzido diversas perguntas e respostas sobre o assunto que estão no site da ANS (www.ans.gov.br). Em seu site, além de perguntas e respostas, a Agência possui um fórum on line de discussão sobre o TISS.


Para facilitar a compreensão, seguimos o modelo do site da ANS que agrupa as perguntas por temas.


I - Porque padronizar

1) Em que grupo de prestadores TISS se enquadram os profissionais que possuem consultórios isolados, mas para efeito jurídico, fazem parte de clínicas, ou seja, na hora do pagamento destes profissionais, os valores são unificados e pagos diretamente a clínica, e na clínica é que ocorre a divisão do que é pertinente a cada médico?

Os profissionais que possuem consultórios isolados mas para efeito jurídico, fazem parte de clínicas e são faturadas pela mesma se enquadram no Grupo II, para contagem de prazos para implantação do TISS.


II - Guias e campos

2) Como proceder para receber uma guia de SP/SADT para cobrança de um ou mais exames em nome do prestador que é um laboratório, mas o pagamento e realizado diretamente a mais de um médico cooperado e não diretamente ao prestador que cobrou?

A guia tem de vir em nome do médico que receberá o pagamento e não em nome do laboratório, uma para cada médico que for receber alguma coisa. O conceito geral é uma guia para cada prestador que está cobrando a Unimed. Mas atenção: há uma exceção no que se refere a exames de imagem (RX, ecografias, tomografias, ressonância), onde o custo operacional do equipamento e o filme são pagos para a clínica e o honorário para o médico cooperado. Neste caso, a conta vem em uma guia de SADT onde os campos 30 e 31 (contratado executante) designam a clínica e os campos 40a e 41 referem-se ao médico (contratado executante complementar).


3) Em uma guia de outras despesas é necessário apresentar os serviços listados por data ou é possível agrupar serviços do mesmo tipo para apresenta-los unicamente?

Na guia de outras despesas não é necessário descrever todos os serviços data-a-data conforme são realizados. É possível demonstrá-los uma única vez totalizando as quantidades e valores do serviço.


4) Como proceder quando o CNPJ ou CPF do profissional executante ou profissional médico não for conhecido pelo prestador?

Nesses casos deve-se preencher os campos correspondentes com o número do conselho profissional (CRM) nos formulários em papel.


5) Como proceder quando a informação a ser preenchida no campo "plano" não for conhecida?

No caso em questão deve ser informado o nome do convênio/operadora em substituição à informação.


6) A mensagem de demonstrativo de retorno é obrigatória ou a operadora pode se negar a enviá-la ao prestador?

O demonstrativo de retorno deve ser enviado obrigatoriamente sempre que o prestador o solicite. O demonstrativo de retorno deve ser enviado respeitando o que foi solicitado pelo prestador, número do lote, período de processamento etc. Para o caso de solicitações realizados por período de vigência, fica facultado a operadora definir datas limites para a solicitação.


7) No caso dos pedidos médicos e solicitações realizadas em formulário em papel, é possível apresentar mais de um item na mesma linha?

Sim. No caso de insuficiência de linhas e por questões econômicas, no caso de pedidos médicos e solicitações, pode ser solicitado em uma única linha (descrição) mais de um procedimento.


III - Alteração no Padrão TISS

1) Será possível utilizar a versão 2.01.01 do padrão de comunicação e segurança ao invés da versão 2.01.02?

Não. A versão anterior, 2.01.01, apresentava algumas falhas que impossibilitavam sua correta implementação. Não era possível validar os arquivos XML utilizando a versão anterior. A versão 2.01.02 deve ser implantada seguindo os prazos dispostos na Resolução Normativa n° 153, de 29 de maio de 2007.


2) Para quem deve ser enviadas as sugestões de alterações no padrão TISS?

As solicitações de alteração do TISS devem ser encaminhadas ao Comitê de Padronização em Saúde Suplementar - COPISS, através de seus membros, representantes do setor. É vedado ao COPISS o julgamento de discutir ou não uma questão apresentada pelo mercado. Vale ressaltar que o COPISS é um órgão consultivo e, portanto, a ANS não está obrigada a aceitar nenhuma de suas recomendações.


IV - O aplicativo

1) Como será realizado o suporte técnico dos aplicativos disponibilizados? Qual canal será utilizado?

A Agência Nacional de Saúde Suplementar não irá oferecer nenhum tipo de suporte técnico às ferramentas disponibilizadas. Não é objetivo da ANS ser provedora de soluções tecnológicas. Os aplicativos disponibilizados são implementações de referência e têm o objetivo de servir como auxílio à adequação dos sistemas já existentes e o desenvolvimento de novas soluções.


2) Por que todos os itens do menu do aplicaTISS encontram-se desabilitados? Como faço para resolver tal problema?

Devido a uma falha na cópia e confecção dos CDs de instalação do aplicaTISS uma de suas tabelas domínio não está devidamente populada o que ocasiona tal problema. A ANS está providenciando a substituição dos CDs distribuídos.


3) Será enviada uma nova versão do aplicaTISS com o acerto da versão enviada com problemas?

Sim. Foi disponibilizado na última reunião do COPISS, realizada em 1º de junho de 2007, a todas as entidades presentes na reunião, um novo CD com o aplicativo e seu código-fonte para distribuição ao mercado. As falhas encontradas na versão anterior foram em decorrência de falhas de gravação do conteúdo no CD.


V - Comunicação

1) Como vão funcionar as solicitações de autorização realizadas através de URA e centrais telefônicas?

As solicitações de atendimento realizadas através de centrais telefônicas devem contemplar todas as informações de preenchimento obrigatório definido no padrão de conteúdo e estrutura.


VI - Segurança

1) É necessário usar as validações de segurança para as trocas de informação realizadas com as empresas de conectividade? E no caso da conectividade ser uma empresa terceirizada para realizar a transação eletrônica, é necessário utilizar as normas de segurança entre o contratado e o contratante?

Sim. Todas as trocas eletrônicas de informações em saúde identificadas devem estar protegidas independente da origem e destino da mesma, canal de comunicação ou agente de comunicação.


2) O método de criptografia RIJNDAEL é obrigatório? Se não for, cada prestador pode usar um diferente? Como faremos para sincronizar os nossos métodos criptográficos com os dos prestadores?

O RIJNDAEL foi o método escolhido para a implementação ponto a ponto do TISSNet. Esta implementação é mera sugestão, já que o padrão de comunicação restringiu-se aos webservices. Não há padrão para comunicação ponto a ponto em batch.


3) O XML precisa ser criptografado individualmente ou apenas o mecanismo de transporte (webservices) precisa ser criptografado, deixando o conteúdo do XML original?

Usando webservices não há transmissão direta de XML, mas transporte de objetos usando tradução transparente para XML. Há padrões para proteção de conteúdo de mensagens que transitam em função de webservices. Todo o trabalho de criptografia deve ser deixado para a infra-estrutura de serviço e, portanto, fora da aplicação. Os mecanismos atuais de proteção do canal oferecem segurança adequada à necessidade do TISS. Não há necessidade de criptografia adicional. O TISSNet implementa uma criptografia adicional para poder ser operado em modo ponto a ponto sobre canal aberto (não SSL), mas este modo de operação não foi padronizado pelo COPISS, nem é de uso obrigatório.


VII - Padrão Eletrônico

1) Como montar uma mensagem de status do protocolo quando a solicitação do status conter um número de lote inválido ou não for encontrado (código de status: 7)?

Deve-se abrir o detalhamento do lote contido na mensagem de resposta. O número do protocolo, no caso inválido, quem manda é o prestador, portanto não há problema, basta repetir na resposta. O número do lote pode ser zerado ou simplesmente inserido um valor padrão (ex. 999999999999), a data é a atual, numero da fatura é zerado ou inserido valor padrão, os valores devem ser zerados também e o status é 7.


2) No caso dos campos opcionais tornados obrigatórios pela operadora, é possível redefini-los no próprio XSD da ANS?

Não. Nos casos de campos opcionais que se tornaram obrigatórios a verificação tem que ser realizadas através da própria aplicação.


3) No caso das entidades que utilizarem formulários em papel e mensagens eletrônicas será necessário manter compatibilidade entre a numeração?

Fica a cargo de cada entidade definir a parte operacional da troca de formulários, seja ele em papel ou eletrônico. No caso de uma mensagem eletrônica complementar ao fluxo de um atendimento iniciado em formulários de papel, o cuidado a ser observado deve ser a ligação entre as guias em papel e as mensagens eletrônicas. No caso dos formulários em papel apenas serem cópias das transações eletrônicas deve-se tomar o cuidado de permitir a rastreabilidade das informações em ambas as mídias.


4) A ANS se refere a um "despachante" para selecionar um "digestor" apropriado para a interpretação da mensagem recebida via webservices. A ANS irá disponibilizar os "digestores" possíveis de serem utilizados ou deixará a critério de cada operadora definir o seu ou isso é exclusivo para uso do TISSnet?

Os digestores são executores de serviço, e têm que entender a base de dados de cada operadora ou prestador. Seria impossível fazer digestores genéricos. O padrão serviço -> despachante -> digestor foi usado no TISSNet para facilitar a adoção da implementação de referência. Como o TISS é um padrão de conteúdo e estrutura, não de software, nada disso é de uso obrigatório.


5) O padrão DOM (Document Object Model) não é um substituto para o PDF, portanto, para proteger um arquivo XML contra alterações, somente seria possível com a utilização de um mecanismo de hash (tipo de dígito de controle que é estabelecido quando da criação do arquivo). No caso de mudança de conteúdo do XML, o hash resultante não seria mais compatível com o original. Isto é realmente é necessário?

O hash aumenta a segurança da informação contida nas mensagens TISS, permitindo que cópias na origem sirvam como contraprova em caso de disputa. Consideramos o hash um passo necessário na direção de tornar a mensagem XML um documento eletrônico. O hash permite que, em caso de adulteração de informações pelo receptor, o transmissor ofereça uma contra prova mais eficiente.



Para tirar mais dúvidas sobre o TISS clique aqui ou nosite da Sociedade Brasileira de Patologia Clínica.


Mais informações sobre o TISS: www.ans.gov.br