ER_PCREQ5318_Validação_Faturamento_XML

Informações Gerais

Objetivo

      A presente especificação visa detalhar as etapas necessárias para validação do xml enviado pelos prestadores para Operadora, para que o sistema valide de acordo com as regras descritas neste documento, permitindo que o sistema apenas aceite os xmls totalmente válidos e os não-conformes não sejam carregados, permitindo deste modo, uma redução no número de glosas devido a erros dos prestadores.

      Deste modo, realizando a validação dos xmls no envio, evitamos uma série de inconveniências com os prestadores e temos uma redução significativa das glosas – devido a erros de digitações e outros – durante o lançamento das guias. Logo, o processo se tornará mais dinâmico e prático, permitindo melhorias para todos os envolvidos e os dados constantes no sistema – enviado pelos prestadores – serão sempre corretos.

Definição da Regra de Negócio

      Como desafio para uma rápida comunicação entre Prestadores e Operadora, para simplificação e rápido processamento dos atendimentos realizados pelos prestadores, a comunicação e o envio de arquivo xml é a forma mais prática e eficaz que temos.

      Porém, por se tratar de um processo onde podem ocorrer erros durante a digitação das guias e no caso de envio de xml com erros ser aceito pelo sistema, posteriormente, ocorrerá a glosa, o que demanda maiores interações entre prestador e operadora, além de um maior tempo para a resolução do problema.

      A fim de evitar estes problemas, o sistema deverá já no ato do envio de xml pelo prestador realizar uma série de verificações, para constatar a conformidade do xml e no caso de problemas, não permitir o envio e comunicar ao operador que está realizando o envio do xml sobre as incoerências encontradas, para que sejam solucionadas e tentado o envio novamente.

      Atualmente, o sistema já realiza algumas verificações quando do envio do xml, porém, terá que atender mais outras validações, para melhoria do foco desta especificação e tornar o processo mais assertivo, a fim de agregar valor e facilitar as operações e comunicações entre os envolvidos.

Observações Importantes

1.    O sistema deverá realizar as seguintes validações/verificações no momento do envio do xml pelo prestador:

   1.1.  Verificar beneficiário cancelado – o sistema não deve aceitar guias de beneficiários cancelados na data do atendimento.

   1.2.  Verificar número de carteira – o sistema não deve aceitar números de carteiras inválidos ou inativos na data de atendimento;

   1.3.  Verificar se a data de atendimento é maior que a data de envio do xml.

   1.4.  Verificar o código do procedimento, analisando se o procedimento está habilitado e atrelado para o prestador.

   1.5.  Verificar a data do atendimento, analisando se ela é anterior a data de inclusão do prestador no sistema, para evitar que o prestador faça cobranças retroativas de beneficiários do plano, como por exemplo: o beneficiário realiza um tratamento periódico com um médico particular. Este médico passa a ser um credenciado e tenta cobrar os atendimentos que foram realizados antes do credenciamento.

   1.6.  Verificar a senha do atendimento, constando que ela está preenchida e ativa.

   1.7.  Verificar procedimentos seriados em duplicidade, ou seja, para procedimentos como sessões de fisioterapia, sessões de fonoaudiologia e outros, apenas uma sessão deve ser cobrada por data. Logo, procedimentos seriados devem ser lançados apenas uma vez por data. Exemplo: tenho 10 consultas de fonoaudiologia, nunca deve-se permitir que sejam lançadas acima de uma consulta na mesma data.

   1.8.  Verificar o valor dos procedimentos na guia, nunca devem ser valores negativos.

   1.9.  Verificar se o lote está sendo enviado na data correta de envio.

   1.10. Verificar se o valor dos procedimentos está de acordo com o valor contratual cadastrado no sistema. Se o valor estiver diferente, deverá ser barrado o envio.

   1.11. Verificar o prazo para envio das guias – no prazo de 90 dias. O sistema deve validar guias onde a data de atendimento seja superior a 90 dias (parametrizável).

2.    De acordo com essas premissas, temos o seguinte cenário, pois alguns dos casos citados, o sistema já realiza, não sendo necessárias alterações. Assim, os itens de números 1.1, 1.2, 1.3, 1.5, 1.6, 1.9 e 1.11 já são contemplados na atual estrutura do Protheus, não necessitando alterações ou adequações, pois já estão prontas para uso.

 3.    Assim, neste documento, iremos descrever os demais casos, que o sistema não realiza e se faz necessário que sejam criadas as rotinas ou alteradas as existentes, para que o sistema possa validar de forma correta essas necessidades.

Regras de Negócio - Definições

1. Para o correto funcionamento, será necessário que o desenvolvedor realize as modificações em sua base de dados, pois serão utilizadas as tabelas BVN, BVP e BCT, para a criação das melhorias descritas abaixo, pois se trata das tabelas dinâmicas da TISS.
   
   
2. Para o funcionamento, será necessário verificar as variáveis existentes hoje no sistema, referente ao xml. Para isso, basta acessar o módulo principal do sistema e verificar no menu: Miscelanea / ANS / Versões da TISS.
   

    2.1.  Na tela que se abre, devemos escolher em qual xml iremos trabalhar e depois, clicar no botão Editar.
    2.2.  O sistema irá exibir todas as tags/variáveis existentes para o xml, onde será possível verificar se a tag/variável que necessita de modificação existe. O cadastro das tags é dinâmico e são relacionados no sistema.

3. Após a verificação da existência das tags, será necessário acessar o sistema e no menu principal, acessar: Atualizações / Cadastros de Contas / Motivos de Críticas.
   

   3.1.  Na próxima tela, serão exibidas as críticas do sistema. Será necessário encontrar a parte de críticas referentes a importações (localize pela coluna Proprietário).
   3.2.  Aqui, pode-se utilizar alguma crítica já existente no sistema ou então, incluir uma nova, pois é nestas críticas que iremos associar os eventos necessários para as validações, conforme próximas etapas.
   3.3.  As alterações terão que ser realizadas nesta parte, pois estamos alimentando o padrão do sistema, que será carregado para os demais casos e atualizações do sistema.

4. Todas as alterações realizadas deverão ser repassadas posteriormente para o csv referente a parte de validações de xml, para serem carregadas via Wizard do PLS.
   
   
5. Todas as guias (Consulta / SADT e etc) deverão ser validadas com estas regras.
   
   
6. A primeira validação necessária se dá pela validação do código do procedimento, onde deve ser verificado se o procedimento está habilitado e atrelado para o prestador de forma contratual.
   

   6.1.  Atualmente, o sistema faz essa validação apenas no momento da mudança de fase, quando o xml já foi importado para o sistema.
   6.2.  Essa verificação terá que ser feita no momento do envio do xml pelo prestador, pois caso ele envie um arquivo com algum procedimento que não conste em seu rol de atendimento, o sistema terá que barrar esse xml.
   6.3.  Para executar essa função de verificação, utilizar a função PLSAUTPMDD, que está localizada no fonte PLSXAUT. Essa função irá receber o código da RDA, código da tabela padrão, código do procedimento, vetor de dados da RDA (aDadRDA) e outros, para então, verificar se o prestador pode ou não realizar o procedimento constante no arquivo.
   6.4.  A função PLSAUTPMDD e seus parâmetros devem ser inseridas no campo Dado/Express da tela de críticas selecionada e será disparada pela tag <ans:codigoProcedimento>, informada no campo Tag XML.
   6.5.  Se o retorno for falso (.F.), o processo de importação do xml deverá ser interrompido e a crítica exibida para o usuário.
   6.6.  Sempre que o procedimento não constar no sistema, o processo de envio será interrompido.

7. Do mesmo modo, será necessário validar o xml com relação aos procedimentos seriados, ou seja, aqueles que são feitos em sessões. O sistema terá que verificar na hora do envio do arquivo xml se existe mais de um procedimento seriado para a mesma data de atendimento. Se houver, o processamento terá que ser interrompido e o usuário comunicado sobre o fato.
   

   7.1.  Sempre que o procedimento for seriado, é necessário verificar se apenas um foi lançado por data.
   7.2.  Para isso, será necessário alterar o campo BJE_ISMEDI existente na BJE – Classes de Procedimento, alterando seu nome para BJE_TIPO e criando as opções: 0=Não Aplicavel;1=Medicamento;2=Seriado, para que o sistema possa identificar se a classe se trata de um medicamento ou procedimento seriado, para efetuar os filtros corretamente. O valor padrão do campo deve ser “0”.
   7.3.  Deste modo, podemos criar classes de procedimento e informar que se tratam de procedimentos seriados, escolhendo no combo a opção Seriado.
   7.4.  Todo procedimento que for seriado necessitará ser ligado a classe de procedimentos seriados, para que possamos efetuar o controle correto. Logo, toda vez que um procedimento for lançado na tabela Padrão (Atualizações / Procedimento / Tabela Padrão) e for do tipo seriado, será necessário escolher a classe de procedimentos seriados.
   7.5    O sistema deverá verificar se o procedimento é do tipo seriado e respeitar a regra de quantidade máxima e mínima, definida no grupo de cobertura e ou tabela padrão pela operadora. 
   7.6.  Para a criação da função de verificação destes procedimentos, será necessário acessar: Atualizações / Cadastros de Contas / Motivos de Críticas e então, criar a crítica referente a importação do XML, como Quantidade maior que o limite permitido na parametrização na tabela padrão.
   7.7.  Porém, aqui devemos prever duas situações:
             7.7.1.    Somente um atendimento na mesma data deve ser aceito. Pela atual estrutura do sistema de verificação do xml, ele realiza a verificação linha por linha e como o prestador pode lançar o mesmo procedimento na mesma data em outra guia que consta no lote, será necessário criar uma variável de controle neste processamento (a variável deve ser lançada na tela Versões TISS - ver item 2)  – no nível da prestadora e beneficiário – para verificar se o procedimento existe em outra guia para o mesmo beneficiário, na mesma data e prestadora. Se existir, a importação deverá ser interrompida e a crítica exibida.
             7.7.2.    Ou seja, essa variável deve armazenar os dados de beneficiário, prestador, atendimento seriado e data do atendimento, para  comparar procedimento por procedimento do xml se existe outro com os mesmos dados, para interromper o processo caso haja.
             7.7.3.    Nesta mesma situação, algum lote xml já pode ter sido processado e a informação salva no Protheus. Por isso, também será necessário criar a variável de controle de banco (a variável deve ser lançada na tela Versões TISS - ver item 2), para verificar se os procedimentos constantes no xml já não estão lançados para o mesmo prestador, beneficiário e data no sistema. Se sim, o xml não poderá ser importado e a crítica exibida para o usuário.

   7.8.  A função que irá realizar a verificação de quantidade será a PLSTratQtd(), localizada no fonte PLSXAUT. Deverá ser passado as variáveis de dados do usuário (aDadUsr), código da tabela padrão, código do procedimento, local de atendimento e outros, para que a função possa realizar as verificações corretas.
   7.9.  A função deverá ser inserida no campo Dado/Express da tela da crítica criada, referente a quantidade de procedimentos e a tag que irá disparar o evento será <ans:codigoProcedimento>.

8. Será necessário criar a validação com relação aos valores negativos. Caso o prestador insira um valor negativo em algum procedimento, será necessário cancelar o envio.
   

   8.1.  Será necessário criar uma função para verificar se o valor do procedimento é negativo, Se sim, o envio deverá ser cancelado.
   8.2.  Após a criação da função, será necessário acessar: Atualizações / Cadastros de Contas / Motivos de Críticas e então, verificar a existência de crítica de Importações referente a valor negativo ou incorreto. Caso não haja, pode-se inserir uma nova crítica.
   8.3.  A função criada terá que ser colocada no campo Dado/Express e será disparada pela tag <ans:valorUnitario>.
   8.4.  OBS: Nos arquivos XML de guia de consulta, a informação de valor unitário não consta no XML.

9.  O sistema não deve permitir o envio de xml onde o valor apresentado pela prestadora seja diferente do valor contratado.
   

   9.1.  Será necessário a criação de uma função para verificar se o valor apresentado pelo prestador é igual ao valor contratado junto a operadora. Essa função deverá receber parâmetros de valor unitário, quantidade realizada, redução ou acréscimo, data e hora, para poder calcular o horário especial, caso tenha ocorrido, para depois conferir com o valor contratado.
   9.2.    Lembramos que será necessário calcular o horário especial, caso tenha ocorrido com o prestador, para que o valor seja fidedigno ao contratado, de acordo com os valores contratuais lançados no sistema. 
   9.3.  Após a criação da função, é necessário acessar a tela de Motivos de Críticas (Atualizações / Cadastros de Contas / Motivos de Críticas) e selecionar a crítica desejada referente a importação. Caso a crítica não exista, basta criar uma nova, referente a esse motivo de valor apresentado diferente do contratado.
   9.4.  A função criada deverá ser colocada no campo Dado/Express e será disparada pela tag <ans:valorUnitário>, pois é a última tag a ser consultada, pois as tags <ans:quantidadeExecutada>, <ans:reducaoAcrescimo>, <ans:horaInicio> e <ans:dataExecucao> já estarão preenchidas com os valores do xml e poderá ser feito a validação dos valores, de acordo com estas variáveis.

   
   

10. Após o lançamento dessas validações, é necessário efetuar testes para confirmar a aderência das validações na importação do arquivo xml.
    
    
11. Estando correto a etapa anterior, será necessário buscar a informação de qual csv deve ser utilizado para lançar as alterações destas telas, para que o sistema carregue as alterações via Wizard do PLS (no momento da presente especificação, o Wizard ainda não está operacional, necessitando que o desenvolvedor veja qual arquivo é o correto para essa imputação de dados). 

Tabelas Utilizadas

• BVN – Validação das Críticas TISS.

• BVP – Variáveis Versões TISS.

• BCT – Motivos de Glosas 

Observação
Em consonância com as melhores práticas de programação e necessidades no desenvolvimento do requisito, poderão ser incluídos mais fontes ou outras funções de apoio e consulta, para executar da melhor maneira possível o proposto neste documento. 

Protótipo de Tela

Protótipo 01 – Tela de verificação das variáveis utilizadas para importações TISS. Elas serão usadas para parâmetros das funções na tela de críticas.

 
Protótipo 02 – Inserção da função PLSAUTPMDD, para a tag <codigoprocedimento>, na tela de críticas. 

Protótipo 02 – Inserção da função PLSTRATQTD, para a tag <quantidadeexecutada>, na tela de críticas. 

Opcional

Fluxo do Processo

Fluxograma 01 - Fluxo de Processo para codificação

Fluxograma 02 - Fluxo de processo do envio de xml

Caso 01 - Caso de Uso da funcionalidade.

Dicionário de Dados

Tabela BJE - Classes de Procedimento