TISS é um meio eletrônico para envio de mensagens entre prestador e operadora e também entre operadora e ANS.
Ele padroniza a forma como os prestadores enviam os serviços executados e seus faturamentos para cobrarem da operadora. Por outro lado, a operadora deve informar toda essa movimentação de serviços e valores para a ANS.
Existem 11 mensagens que o prestador(ativo) envia para a operadora: Mensagem Descrição
Guias de faturamento do prestador. Os tipos suportados são Consulta, SADT, Resumo de Internação e Honorários. Não foi implementado corretamente o tipo Odonto.
Não implementado
Não implementado
Não implementado
Não implementado
Não implementado
Não implementado
Não implementado
Não implementado
Não implementado
Não implementado
Existem 14 mensagens que a operadora(passiva) responde para o prestador:
Sempre que o GSS recebe uma mensagem válida de ENVIO_LOTE_GUIAS, ele gera essa mensagem que indica o protocolo de identificação do envio feito pelo prestador.
Não implementado
Não implementado
Não implementado
Não implementado
Não implementado
Não implementado
Não implementado
Não implementado
Não implementado
Não implementado
Não implementado
Não implementado
Não implementado
Um prestador pode solicitar ou executar um serviço, exemplos:
Então temos dois tipos de prestadores:
O mesmo conceito serve para os profissionais. Se o profissional pertence ao prestador solicitante, então ele é profissional solicitante, caso seja de um prestador executante, ele é um prestador executante.
Todas as solicitações passam por um processo de autorização que pode ser automática (GSS) ou manual (auditoria).
Um serviço solicitado ou executado pode ser um procedimento, um pacote (conjunto de procedimentos) ou outras despesas (material, medicamento, diárias, taxas e gases).
A Coopus preferiu criar as solicitações de SADT e Internação ao seu modo sem respeitar o TISS. Os prestadores devem acessar estas tarefas no GSS para realizar as solicitações e indicar o andamento (quando for internações). Por esse motivo, toda essa comunicação não gera mensagens TISS.
Antes de um prestador enviar as guias de execução de SADT, ele deve usar uma tarefa do GSS para “eleger” a guia. Este é um conceito da Coopus e indica que o prestador está informando a Coopus que executou o serviço e que irá mandar um XML com a guia.
Tanto a tarefa de criação/análise das guias SADT como a tarefa de eleição de SADT (conhecida como autorizador de SADT) tiveram seus conceitos alterados muitas vezes e o resultado foi um funcionamento complexo assim como as tabelas de banco envolvidas e o código fonte.
A mesma ideia das SADTs vale para as guias de resumo de internação.
Desta forma, os conceitos de solicitação, autorização, eleição e execução funcionam no dia a dia da Coopus, mas eles possuem falhas de análises e códigos confusos que refletem num uso meio improvisado e que podem afetar no envio do TISS e na auditoria.
Toda execução de serviço feita por um prestador e cobrada através das guias de execução. Todas as informações destas execuções possuem suas respectivas mensagens XML do TISS no GSS com exceção das guias de consulta de odonto.
Uma vez que o GSS recebe o arquivo XML do TISS, ele realiza uma auditoria eletrônica para analisar se os serviços executados pelo prestador são válidos e foram autorizados e se os valores solicitados estão corretos de acordo com os contratos.
Após esse processo, são criados no banco de dados estruturas chamadas contas médicas que representam o faturamento dos prestadores.
A auditoria atual fica no pacote gss.auditor e realiza as pré-auditorias e auditorias das contas médicas.
Esta área tem a responsabilidade de recepcionar, analisar e auditar as cobranças enviadas pelos prestadores e após esses passos, informar à área financeira os pagamentos a serem realizados.
Hoje esta área recebe as cobranças dos prestadores eletronicamente pelo TISS. O GSS recepciona os arquivos do TISS e realiza uma auditoria eletrônica. A área de contas médicas faz uma auditoria administrativa e repassa para a área financeira para realizar os pagamentos.
Quando as guias envolvem internações, outras despesas ou alguma particularidade médica, o setor de auditoria médica faz uma análise manual que pode resultar no pagamento ou na negativa total ou parcial do faturamento.
A principal tarefa que a área de contas médicas usa no GSS é a contaMedica.
Outros conceitos como recurso e contestação de glosas (recursoGlosaPrestador, recursoGlosaOperadora e tempRecursoGlosa), demonstrativos de glosa (tempDisponibilizaGlosas e demonstrativoGlosaPrestador) e demonstrativos de pagamento possuem seu funcionamento parcial e deve envolver á área de contas médicas para entender em que situação se encontram.
A implementação do TISS no GSS vem desde 2013. De lá para cá, a ANS mudou muita coisa e a implementação seguiu um caminho definido pela Coopus. Esta versão atual suporta o TISS 3.03.03 e trata as seguintes guias de execução:
A partir de fevereiro/2020 o TISS na versão 3.03.03 expirou, como determinou a ANS. A Coopus passou a estar em desconformidade com a lei.
O pacote que contém as classes é gss.tiss. Algumas classes importantes para conhecimento:
Basicamente uma guia gerada automaticamente pelo GSS (TissGeraMensagemV3_03_00), digitada (TissGeraMensagemV3_03_00) ou enviada pelo prestador via upload é transformada num arquivo e posto num diretório específico. Periodicamente o GSS lê esse diretório e processa as mensagens.
A tarefa tissMensagemPrestador tem o objetivo de fazer o upload dos XMLs dos prestadores, realizar uma pré-auditoria e gerar o arquivo para ser processado. Em caso de erro, um relatório é exibido para o usuário.
O objetivo é que cada mensagem seja tratada pela versão nova do TISS. No final, todo este código pode ser removido.
Em 2019 começou um processo de refazer todo o código do GSS referente os TISS e auditoria médica. Atualmente a nova versão consegue:
O principal trabalho a ser feito deve ser:
Num segundo momento é interessante estudar e implementar todo o suporte para guias odontológicas. Existe até a tarefa atendimentoOdonto, mas é mais um caso de um pedido de desenvolvimento confuso, isolado e que nunca foi utilizada.
Os pacotes da nova versão e auditoria são:
Existe uma classe temporária chamada TesteTiss que possui um testador de consultas que compara a auditoria antiga com a nova e gera relatórios em CSV. Baseie-se nesse código para fazer os testes nos outros tipos de guias.
ATENÇÃO: não deu tempo de fazer um último passo para completar 100% as guias de consultas na versão nova. Sempre que uma mensagem de faturamento (ENVIO_LOTE_GUIAS) é processada, o GSS tem que criar uma mensagem de recebimento de lote (PROTOCOLO_RECEBIMENTO). O criador de mensagem já está pronto. Precisa terminado o código que está na linha 147 do método auditLote da classe AuditorConsulta.
A maioria das guias do TISS entram no GSS pelas tarefas tissMensagemPrestador e tissMensagemOperadora.
Após o upload do arquivo, o GSS faz uma pré-auditoria e depois cria o seu arquivo XML correspondente que seguirá o fluxo normal de auditoria e criação das contas médicas correspondentes.
Se durante a pré-auditoria forem identificados erros, o envio é abortado e um relatório de erros é exibido. Existem situações que é necessário que esse arquivo XML com erros de pré-auditoria entre no GSS sempre por culpa da Coopus que negociou errado o contrato com o prestador.
Quando essa situação acontece, o seguinte procedimento deve ser feito:
A versão nova do TISS recebe o XML, monta a sua estrutura e faz a auditoria. Em caso de problemas, o XML é rejeitado. Mais simples e eficiente.
A versão antiga tem um funcionamento antigo por conta das necessidades da época e pela pretensão que ela tinha, mas nunca foi confirmada pela gestão da Coopus.
Nesta versão antiga que está hoje em funcionamento, quando o GSS recebe um XML ele apenas faz uma análise inicial e uma pré-auditoria e armazena esse arquivo em um diretório específico (WEB-INF\tiss\prestadorOperadora). Um tratador, lê este diretório, processa o XML e gera as contas médicas correspondentes.
Porém erros podem acontecer, como alguma estrutura inválida no XML ou um dado que gera uma exception no código. Quando isso acontece, o arquivo é colocado no diretório WEB-INF\tiss\prestadorOperadora\erro e uma mensagem por email é enviada para o conhecimento dos responsáveis pelo sistema. Geralmente o que se deve fazer é fazer um debug, com o arquivo XML para
encontrar o erro e fazer a correção. Após uma subida de versão, é só mover o arquivo do diretório erro para o anterior e a mensagem será reprocessada com sucesso.
A ANS criou tabelas para padronizar os serviços executados pelos prestadores. As tabelas são:
Cada tabela possui uma tarefa no GSS correspondente para listagem atualização, porém faz um pouco mais de 5 anos que as atualizações das tabelas de materiais e procedimentos não ocorrem porque elas estão gigantescas (quase 1 milhão de registros) e o algoritmo de atualização ficou extremamente lento (entre 8 e 10 dias de processamento). É preciso revisar e montar uma estratégia para atualizá-las e como serão as futuras atualizações.
A tabela própria é populada automaticamente pelas tabelas Simpro e Brasindices. Também pode ser populada manualmente por conta da nova tabela de preço da operadora.
Por conta destas atualizações automáticas, um item pode ser definido como material e ser na verdade um medicamento e vice e versa. De tempos em tempos a área de contas médicas pede para trocar o tipo do item da tabela própria. Eles passam o código do item na tabela própria e para que tipo deve ser alterado: medicamento ou material.
Para fazer a troca, o seguinte script deve ser executado (faça sempre em homologação antes):
select ID, CODIGO, DESCRICAO, DATAINICIO, DATAFIM, ORIGEM, IDTISSTABELA from TUSSPROPRIA where CODIGO='?'; update TUSSPROPRIA set IDTISSTABELA=? where ID=?;
Primeiro, obtém-se o ID do item e depois troca-se o tipo do mesmo (19=Materiais, 20=Medicamentos).
Todo mês a Coopus envia para a ANS arquivos XMLs contendo todas as guias recebidas dos prestadores de duas competências atrás. Esse arquivo possui uma estrutura definida pela ANS (XSD) e é complexo de ser montado.
Toda vez que uma guia recebe data de entrada, um evento é criado (tabelas TissAnsEventoGuia, tabela TissAnsEventoGuiaItem e outras). Ao acessar a tarefa tissOperadoraANS, o usuário pode gerar os arquivos a serem enviados para a ANS (tabela TissAnsEventoArquivo).
O código precisa ser totalmente revisado, mas primeiramente um estudo deve ser feito para compreender o funcionamento do TISS Monitoramento para só então montar uma estratégia de desenvolvimento.
O código possui um erro grave de informar para a ANS que algumas guias possuem quantidade de solicitação iguais a 0. Todo começo de mês (primeiro dia útil) o seguinte script SQL deve ser executado em produção:
update TISSANSEVENTOGUIAITEM set QUANTIDADEINFORMADA = 1 where QUANTIDADEINFORMADA = 0 and TISSANSEVENTOGUIA in (select guia.TISSANSEVENTOGUIA from TISSANSEVENTOGUIA guia where guia.DATAPROCESSAMENTO >= '2019-01-01');
Sistema de Informações de Beneficiários - SIB/XML
SIB-Criticas-de-Preenchimento-dos-Campos-Versão_2.7.pdf
Todo mês a Coopus precisa enviar as informações dos beneficiários que entraram, saíram, foram reabilitados ou alterados. O envio é eletrônico e definido pelo SIB (criado pela ANS) com o mesmo conceito do TISS.
Quando uma operação (inclusão, exclusão, etc) acima acontece, o GSS cria um evento e armazena na tabela SibEvento. Existem outras tabelas relacionadas sempre começando com Sib.
Na tarefa administracaoSIB, o usuário pode:
O código do SIB está razoável. Tivemos muitos problemas para a sua implementação porque a documentação da ANS praticamente não existe e muito do que existe foi feito na tentativa e erro. Por exemplo, se um beneficiário é incluído e depois reabilitado, a mensagem de reabilitação vai só no próximo mês, porque no passado o sistema da ANS acusava erro no evento de reabilitação por deficiência técnica deles.
Para alguns credênciados PJ a geração do TISS acontece de forma automática através de um processo cadastrado no módulo Gerenciamento do GSS, clicar na aba Agendador localizar a linha do processo: Gera TISS de execução SADT, este processo está definido no pacote: gss.tarefa.saude.operadora.atendimentoServico, na classe AtendimentoServicoPublico através do método agendadorCriaTiss, que atualmente está parametrizado para executar todos os dias, repetidas vezes de 1 em 1 hora.