Histórico da Página
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:
- 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 ER_PCREQ6253_Composicao_Item_Procedimento_Protocolo_Reembolso - Na tela de Protocolo de Reembolso (PLSA001A), será necessário criar um campo que já existe na Autorização de reembolso, que é o campo Número da Liberação (B44_NUMLIB - campo que deve ser utilizado apenas quando as liberações possuam alguma participação negada). Este campo Número da Liberação na tela de Autorização é um campo de pesquisa do tipo F3, que é alimentado pela consulta B98PLS.
- Será necessário criar um campo idêntico na tabela BOW – Protocolo de Reembolso, que será chamado de BOW_NUMLIB, com as mesmas características e pode-se aproveitar a mesma pesquisa B98PLS, para filtrar as guias.
OBS: O campo B44_NUMLIB possui funções de validação do sistema (X3_VALID) e controle de edição (X3_When). O desenvolvedor deverá analisar estes valores e adaptar para a rotina de Protocolo.
Guia Mista – Controle de guia paga ao prestador e recebimento posterior de reembolso em mesmo procedimento
- 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. - 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.
- 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).
- 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.
- 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. - 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. - 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.
- 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.
- Em Contas Médicas (PLSA498). Toda vez que uma PEG for inserida, será necessário vas
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
Protótipo de Tela
<Caso necessário inclua protótipos de telas com o objetivo de facilitar o entendimento do requisito, apresentar conceitos e funcionalidades do software>.
Protótipo 01
Fluxo do Processo
Fluxograma Básico 1 - Despesa paga pela Operadora ao Prestador e recebimento posterior de reembolso:
Fluxograma Básico 2 - Despesa paga pelo Operadora ao beneficiário e recebimento posterior de guia:
Opcional
Dicionário de Dados
Arquivo ou Código do Script: AAA – Negociação Financeira / *Versao=CP.2014.12_03*/
Índice | Chave |
01 | <FI9_FILIAL+FI9_IDDARF+FI9_STATUS> |
02 | <FI9_FILIAL+FI9_FORNEC+ FI9_LOJA+FI9_EMISS+FI9_IDDARF> |
03 | <FI9_FILIAL+FI9_FORNEC+ FI9_LOJA+FI9_PREFIX+FI9_NUM+FI9_PARCEL+FI9_TIPO> |
Campo | <AAA_PERESP> |
Tipo | <N> |
Tamanho | <6> |
Valor Inicial | <Varia de acordo com o tipo informado. Por exemplo, quando o campo “tipo” for date, neste campo pode ser informado uma data>. |
Mandatório | Sim ( ) Não ( ) |
Descrição | <Referência Mínima para Cálculo> |
Título | <Ref.Calc.> |
Picture | <@E999.99> |
Help de Campo | <Informar o % que o aluno pagará em dinheiro. Esse % poderá ser alterado durante a negociação> |
Este documento é material de especificação dos requisitos de inovação, trata-se de conteúdo extremamente técnico. |
---|