Page tree

 Este documento é material de especificação dos requisitos de inovação, trata-se de conteúdo extremamente técnico.          

  

Controle e validação de guias mistas

Especificação

Produto

Microsiga Protheus

Módulo

SIGAPLS

Segmento Executor

Saúde

Projeto

M_SAU_PLS002

IRM

PCREQ-5685

Requisito

PCREQ-6235

Subtarefa

PCSFL-214

Release de Entrega Planejada

12.1.8

Réplica

 Não

País

( X ) Brasil  (  ) Argentina  (  ) Mexico  (  ) Chile  (  ) Paraguai  (  ) Equador

(  ) USA  (  ) Colombia   (  ) Outro _____________.

 

 

Objetivo

 

A presente especificação visa detalhar as regras de negócio envolvidas e desenvolvimento envolvidas na operação de guias mistas. Guias mistas é o processo onde determinado procedimento é coberto pelo convênio, mas o beneficiário arcar com as despesas de forma particular e depois visa a restituição destes valores, via reembolso. Um exemplo deste processo seria no caso de um parto, onde toda a equipe e procedimentos estão cobertas, mas a beneficiária acaba contratando seu médico de confiança e paga seus honorários a parte e após, solicita a restituição do valor para a Operadora.

Por se tratar de um processo de certa frequência, se faz necessário o controle destas operações, para que não ocorram falhas de comunicação, perdas de tempo, erros financeiros e outros entraves para todos os envolvidos. Logo, é de extrema importância o controle das etapas deste processo na Operadora, para deixar as operações simples e transparentes para todos os envolvidos.

Portanto, iremos descrever as regras de negócio com relação as guias mistas, para servir como rumo durante a etapa de codificação e visando o entendimento por todos que necessitam trabalhar com as guias mistas.

 

 

Definição da Regra de Negócio

 

O beneficiário da operadora – mesmo possuindo uma ampla rede de atendimentos e diversos procedimentos cobertos – pode escolher seu médico, clínica ou outro ente para realizar o procedimento desejado, pagando o honorário diretamente para este e depois, solicitar o reembolso do valor pago para a Operadora.

Porém, haverá casos onde mesmo o cliente pagando o honorário diretamente para o seu prestador, haverá outras despesas que serão pagas pela Operadora. Como exemplo, podemos citar o caso de uma cirurgia de blefaroplastia (levantamento de pálpebras), onde existe cobertura pelo plano, mas o paciente deseja que a cirurgia seja realizada pelo seu médico oftalmologista de confiança – arcando com o custo de seus honorários – mas o restante da equipe e demais insumos serão de responsabilidade da Operadora. Neste caso, temos o exemplo da guia Mista, onde o médico será pago pelo beneficiário e demais itens serão pagos pela Operadora.

Deste modo, é necessário realizar o controle correto desta guia, para evitar pagamentos errôneos ou possíveis fraudes no decorrer de todo o trâmite. Logo, é necessário um controle correto – e ao mesmo tempo simples – para a Operadora administrar tais guias e evitar possíveis problemas com todos os interessados.

Assim, devemos atentar para algumas particularidades do processo, descritas logo abaixo:

  • Priorização do pagamento do reembolso do beneficiário.
  • Nos casos onde a Operadora já realizou o pagamento ao prestador (mesmo este já tendo recebido diretamente pelo beneficiário) e chegar uma solicitação de reembolso, o sistema deverá emitir alertas – indicando esta situação ao operador do sistema – para que haja comunicação interna entre os setores da Operadora e possam decidir entre realizar a glosa do pagamento ou cobrar este valor do prestador.
  • Nos casos onde o reembolso já foi pago pela Operadora e chegar uma guia no Contas Médicas, constando o mesmo procedimento/item do reembolso, este item/procedimento deverá ser glosado automaticamente.

Essas são as condições que devem ser observadas durante a avaliação das guias mistas. O pagamento do reembolso para o usuário é prioridade, mas segue no processo normal de análise de todo o procedimento sobre reembolso.

Em seguida, devemos observar com atenção nos casos onde o prestador envia uma guia com o item/procedimento já pago pelo beneficiário e tentar receber novamente da Operadora e quando o reembolso já foi efetuado ao beneficiário, mas o prestador envia a guia para receber novamente e neste momento, o item deverá ser glosado. As situações acima deverão ser controladas de forma que permite que a Operadora tenha conhecimento destes casos e possa atuar de forma rápida e eficaz, a fim de solucionar estas diferenças.

Além disso, também será necessário realizar algumas mudanças nas telas de Protocolo de Reembolso e Autorização de Reembolso, que serão descritas no escopo das alterações.

 

Escopo

 

Alteração das telas de Protocolo e Autorização de Reembolso:

  1. Será necessário colocar na tela de Autorização e Protocolo de Reembolso uma nova guia na parte de eventos, que será a guia de Composição dos Procedimentos/Itens, pois é a guia que mostra a valorização da composição dos procedimentos inseridos na guia.
    Esta atividade está prevista na Especificação: Composicao Item Procedimento Protocolo_Reembolso

 

Guia Mista – Controle de guia paga ao prestador e recebimento posterior de reembolso em mesmo procedimento

  1. Nos casos onde o prestador envia uma guia com algum procedimento/item já pago pelo beneficiário e está guia é devidamente paga pela Operadora, mas algum tempo depois o beneficiário solicita reembolso neste item, é necessário que o sistema emita alertas sobre o ocorrido.
    Desta forma, toda vez que uma solicitação de reembolso for analisada pelo operador, será necessário verificar no Contas Médicas se já existe alguma guia com o mesmo procedimento que consta no reembolso, pois se sim, é necessário alertar o operador sobre o fato.
  2. Criar função – com nome de PLSVRCMR – para verificar se nos Contas Médicas (tabelas BD5, BD6 e BD7, mas no caso, a tabela BD7 é a que será usada) já não existe o mesmo registro que está sendo solicitado no reembolso.
    1. Para verificar na tabela BD7 os casos de duplicidade, deverão ser utilizadas as seguintes informações: Beneficiário (matrícula), Data do procedimento, código do procedimento, código da RDA, código da especialidade  e outras informações em comum (pode-se utilizar SQL para a procura de dados).
    2. Caso exista, será necessário avisar o operador com mensagem na tela (MSGYESNO ou similar), para exibir que já existe o procedimento(s) em Contas Médicas e se deseja continuar a operação.
  3. Essa validação deverá ser realizada no botão Salvar da tela de Protocolo de Reembolso, para que antes que seja salva, chame a função de verificação no Contas Médicas e possa exibir o alerta.
    OBS: No fonte PLSA001A, a função PBOWFinal() é a responsável pelo ação de Salvar o protocolo e gerar uma Autorização. Logo, a chamada da função terá que ser realizada nesta rotina.
  4. Também será necessário chamar essa função de validação quando o usuário clicar no botão Gerar aut. reemb., que fica no Menu Outras Ações na tela principal do Protocolo de Reembolso.
    OBS: No fonte PLSA001A, a função PLSGERAUT() é a responsável em gerar a Autorização a partir do protocolo. Assim, devemos chamar a função de verificação nesta rotina.
  5. O sistema deverá emitir o alerta de forma clara e concisa, para que o operador possa tomar as atitudes concernentes as ações que serão realizadas, pois trata-se de um trâmite interno da Operadora e o usuário poderá escolher se deseja continuar a gerar a Autorização ou não, via opções do alerta.

     

Guia Mista – Controle do reembolso já pago ao beneficiário, mas recebimento posterior de guia do prestador cobrando o mesmo procedimento/item.

  1. Nos casos onde o reembolso já foi pago ao beneficiário e a Operadora recebe uma guia do prestador cobrando por algum item já pago no reembolso, o sistema deverá glosar o procedimento ou honorário cobrado, pois o prestador já recebeu do beneficiário por este item.
  2. Em Contas Médicas (PLSA498 – Digitação de Contas), o sistema deverá efetuar a validação no momento da Mudança de Fase, ou seja, quando o operador clicar em Outras Ações e depois no Mudança Fase, o sistema deverá realizar a validação.
  3. A validação deverá ser feita na tabela B44 – Cabeçalho do Reembolso, para verificar qual autorização de reembolso já foi paga.
    Para saber qual autorização já foi paga para o beneficiário, é necessário checar se o campo B44_DATPAG está preenchido e se a data atual é maior que este.
  4. Ou seja, quando o operador clicar em Mudança fase, o sistema deve verificar se existe algum reembolso pago – percorrer a B44 e checar se o campo B44_DATPAG está preenchido, verificando também código do prestador, código e data do procedimento e outros campos similares – e caso encontre registro similar, deve alertar (MSGALERT) o operador sobre o procedimento ou honorário que já existe e neste momento, realizar a glosa do item.
  5. A função que realiza a Mudança de Fase nas guias é a PLSA175FAS(), que fica localizada no fonte PLSA175.
    OBS: Durante o desenvolvimento, o analista poderá analisar se a mudança vale ser desenvolvida apenas no fonte PLSA498 ou direto na função PLSA175FAS.
  6. Será necessário criar uma glosa no fonte PLSXAUT, onde será definido a glosa sobre o procedimento ou honorário existir no reembolso.
    1. Essa glosa deve ficar com as outras existentes, no início do fonte, utilizando do comando #define.
    2. A crítica deve ser cadastrada nos arquivos de tradução do Protheus.
      OBS: A crítica pode ter o seguinte texto: “Existe um reembolso já pago ao beneficiário sobre o procedimento/honorário:”
  7. Na função PLSAUTP (fonte PLSXAUT), deverá ser criada a rotina de verificação de procedimentos/honorários no reembolso.
    1. Esta rotina deverá usar a função PLSPOSGLO (função de posicionar glosa), pois é a função responsável por exibir e gravar a glosa no procedimento.
    2. A rotina deverá ficar antes das outras verificações da função PLSAUTP, pois caso o procedimento já exista no reembolso, é necessário glosá-lo imediatamente, não sendo preciso as outras verificações. Isso visa otimizar a rotina.
    3. Após a finalização do processo, será necessário exibir um alerta para o usuário, informando que houve procedimentos ou honorários glosados por já existirem no reembolso.
  8. Após a realização da glosa no procedimento ou honorário, o processo seguirá normal, sem alterações no decorrer do processo.
  9. Esta melhoria visa garantir a diminuição de cobranças irregulares por parte dos prestadores.

 

 

Tabelas Utilizadas

  • BOW – Protocolo de Reembolso
  • B1N – Itens do Reembolso
  • B44 – Cabeçalho Reembolso
  • B45 – Itens Reembolso
  • B7M – SubItens do Protocolo Reembolso
  • BD7 – Part Honorários Prestado Itens

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ótipos de Tela

  

Protótipo 01 - Tela de Protocolo, exibindo a mensagem de que já existe guia com o mesmo procedimento/honorário no Contas Médicas.


 

 

Protótipo 02 - Tela de Digitação de Contas, exibindo que um item da guia já foi pago ao beneficiário e que será glosado, quando o botão de Mudança de Função for chamado.

 

 


Protótipo 03 - Tela de Protocolo de Reembolso, com a guia de Composição de Eventos (imagem retirada da especificação Composicao Item Procedimento Protocolo_Reembolso

 


Fluxo do Processo

 

Fluxograma Básico 1 - Despesa paga pela Operadora ao Prestador e recebimento posterior de reembolso:


 

Fluxograma Básico 2 - Despesa paga pela Operadora ao beneficiário e recebimento posterior de guia:

 



 

 Este documento é material de especificação dos requisitos de inovação, trata-se de conteúdo extremamente técnico.