Este documento é material de especificação dos requisitos de inovação, trata-se de conteúdo extremamente técnico. |
---|
Informações Gerais
Especificação | |||
Produto | Microsiga Protheus | Módulo | SIGAPLS |
Segmento Executor | Saúde | ||
Projeto | M_SAU_PLS002 | IRM | PCREQ-3987 |
Requisito | PCREQ-3999 | Subtarefa |
|
Release de Entrega Planejada | 12.1.8 | Réplica | Não |
País | ( X ) Brasil ( ) Argentina ( ) Mexico ( ) Chile ( ) Paraguai ( ) Equador ( ) USA ( ) Colombia ( ) Outro _____________. | ||
Outros | Não Aplicável |
Objetivo
O requisito tem como finalidade permitir que o auditor, durante suas atividades, possa negar determinado procedimento e, caso encontre alguma irregularidade ou queira indicar ou deletar outro procedimento, possa cancelar a guia atual e gerar uma nova, com os procedimentos corretos e o Prestador seja avisado da nova guia, via e-mail.
O sistema permitirá que o auditor possa antes de cancelar a guia, verificar os procedimentos existentes nesta e efetuar tarefas de manutenção – entenda-se como a inclusão e exclusão de procedimentos – para então, o sistema cancelar a guia atual e gerar uma nova, respeitando todos os filtros devidos nesta operação, como se os procedimentos solicitados podem ser realizados pelo beneficiário ou RDA e tantos outros, para garantir total segurança das informações e evitar erros e transtornos para todos os envolvidos. Ao gerar a nova guia, o sistema irá exibir o número da nova guia e o Prestador será avisado via e-mail desta guia, para poder acompanhar de forma transparente e clara que a guia anterior foi cancelada e uma nova foi gerada, com as devidas correções.
Todo esse movimento será realizado via tela de Auditoria (PLSA790V) e a organização deverá indicar quais auditores terão acesso a esta nova funcionalidade (via menu Operadores do Sistema – PLSA980), para evitar uso indiscriminado ou indevido desta funcionalidade por outras pessoas não autorizadas.
Em todas as etapas, o auditor será comunicado com mensagens em tela das ações efetuadas pelo sistema e indagado se deseja realmente continuar estas operações, permitindo total controle destas etapas.
Definição da Regra de Negócio
O processo de auditoria é vital na área de saúde, pois visa garantir a conformidade dos processos e o cumprimento de legislações, contratos e outros acordos, sempre visando o bem-estar do paciente e garantindo a perenidade dos negócios da organização, pois a auditoria tem como metas a melhoria dos processos e por consequência, conseguimos reduzir custos e aumentar a qualidade do atendimento, além de outras melhorias diretas e indiretas neste processo.
No PLS, para facilitar a auditoria referente ao processo de auditoria de guias, temos o módulo de Auditoria, onde o auditor visualizará todas as guias que estão com alguma divergência e necessitam de atenção, para verificar se estão de acordo com as normas regulamentares ou contratuais existentes. Todas essas regras e negociação são cadastradas previamente no sistema, onde cada uma é interpretada durante o processamento das guias e poderá resultar na liberação total/parcial ou até mesmo a negação total da guia.
Todo o processo abaixo será conduzido pelo auditor, que dentro de suas atribuições e conhecimentos, poderá indeferir procedimentos e incluir novos, fazendo com que a guia anterior seja cancelada e uma nova gerada, conforme suas determinações durante o processo. Todas as ações serão manipuladas pelo auditor, que terá total controle de seu trabalho e comunicação do sistema - via mensagens e confirmações. Para isto, o auditor poderá trabalhar das seguintes formas:
- Caso a guia analisada contenha mais de um procedimento para ser analisado, o auditor poderá dar o seu parecer em alguns - mas deverá deixar obrigatoriamente um procedimento sem análise - pois caso o auditor análise todos os procedimentos, o sistema irá encerrar o processo de auditoria e não será possível gerar uma nova guia. Logo, o auditor poderá realizar seus pareceres, mas deverá sempre deixar um procedimento sem análise.
Caso deseje, poderá não efetuar nenhuma análise e gerar uma nova guia, analisando posteriormente os procedimentos incorretos na nova guia gerada pelo sistema. - Caso a guia analisada contenha apenas um procedimento para ser analisado, o auditor deverá obrigatoriamente gerar uma nova guia e auditar este procedimento na nova guia gerada, pelo motivo citado no item acima.
Exemplificando o item 1, caso a guia analisada contenha quatro procedimentos para análise, o auditor poderá dar parecer em 3 procedimentos, mas sempre deverá deixar um procedimento sem análise, para então, gerar uma nova guia e depois auditar este procedimento faltante na guia gerada. Automaticamente, os três pareceres imputados da guia anterior serão migrados para a nova guia.
Caso deseje, o auditor poderá gerar uma nova guia com suas correções e realizar seu processo de análise destes quatro procedimentos na nova guia, maximizando seu tempo.
Se a guia cancelada possuir guias de Anexos Clínicos ou Banco de Conhecimento atrelados, o sistema irá efetuar a migração destas guias de Anexos e banco de conhecimento para a nova guia, mantendo todo o lastro existente.
Regras de Negócio
1. Criar parâmetro (SX6) chamado “MV_MOTTISS”, para a organização indicar o código padrão que será usado para o cancelamento da guia, de acordo com a TISS.
2. Criar campo “BX4_PROAUD” na Tabela BX4 –Operadores x Instituicoes, com as opções: 0=Não e 1=Sim, com inicializador do campo com o valor “0”. Este campo será responsável em sinalizar se o usuário pode ou não efetuar manutenção e gerar novas guias.
2.1. Este campo ficará visível na rotina de Operadores do Sistema (PLSA980).
3. Criar na tela de Análise da auditoria (Model da tela de Análise – PLSANALM / Auditoria – PLSA790V) o botão de Incluir.
4. O botão de Incluir só deverá ser visível aos usuários que possuírem acesso, conforme campo “BX4_PROAUD”. O controle (PLSA790C) deverá ser realizado para verificar estes acessos e a exibição somente para usuários autorizados.
5. Ao clicar no botão de Incluir, o sistema deverá verificar algumas questões (conforme ordem abaixo):
5.1. O parâmetro “MV_MOTTISS” – Caso não esteja preenchido, deverá informar o usuário que o processo será interrompido pela falta de preenchimento (MSGALERT/ALERT). Enquanto o parâmetro não for preenchido, o sistema não irá continuar o processamento.
5.2. Caso o parâmetro “MV_MOTTISS” esteja preenchido, o sistema deverá verificar se o Prestador da guia possui e-mail cadastrado (BAU_EMAIL). Caso não haja e-mail cadastrado, deverá informar sobre a falta do e-mail, indagando o usuário se deseja continuar ou não o processamento (MSGYESNO).
6. Caso o e-mail esteja preenchido ou a resposta do usuário seja “Sim”, deverá ser exibida a janela para manutenção dos procedimentos da guia (usar como base PLGRVDIAG). Esta janela deverá trazer todos os procedimentos constantes da guia selecionada e deverá possibilitar a exclusão e inclusão de novos procedimentos, conforme análise do auditor. Deverá ter o botão de “Cancelar” e “Confirmar”.
7. Ao clicar em “Confirmar”, o sistema deverá questionar o usuário (MSGYESNO) se realmente deseja cancelar a guia atual e gerar uma nova, conforme tela de manutenção.
8. Caso a resposta seja afirmativa, deverá ser usada a função “Processa”, para exibir e informar o usuário sobre o andamento do processo.
9. O sistema deverá realizar as validações dos procedimentos da tela de manutenção, para verificar direitos de execução, carências e outros processos (funções PLSDADUSR, PLSDADRDA, PLSA090PRO e outras de apoio, caso necessárias).
10. Se durante as validações for encontrado algum problema, o sistema deverá emitir alertas para o usuário (as críticas encontradas – MSGALERT/ALERT) e parar todo o processo, devido a essas inconsistências.
11. Se for incluído algum procedimento que tenha como crítica ir para auditoria – por estar sendo incluído por um auditor – este procedimento será validado como aprovado e não entrará no módulo de auditoria.
12. Caso não haja impeditivos, o sistema deverá verificar se existe PEG vigente e alocar a nova guia nesta. Caso não exista, será necessário criar uma nova PEG (ver modelo PLSA974).
13. Iniciar o processo de gerar e gravar a nova guia (verificar recurso de glosa – PLSA498).
14. Gerar o cabeçalho da nova guia (PLSA090)
15. Calcular valores de co-participação dos procedimentos (PLSRETCOP).
16. Gravar dados nas tabelas BD6, BD7 (funções PLS720IBD7, PLSCOMEVE).
17. Iniciar a função de envio de e-mail (PlsWFProc), para comunicar o prestador sobre a nova guia gerada, desde que este tenha e-mail cadastrado.
17.1.A função PlsWFProc possibilita a inclusão de vários sinalizadores e personalização dos modelos de e-mails. Logo, a empresa deverá criar o sinalizador e texto padrão para este caso.
18. Caso a guia cancelada possua algum tipo de parecer já lançado, possua guia de Anexos Clínicos vinculados ou algum tipo de banco de conhecimento, o sistema já efetua a migração destes para a nova guia.
19. Exibir na tela para o usuário (MSGALERT/ALERT) o número da nova guia gerada, indicando o sucesso da ação realizada.
Rotina | Tipo de Operação | Opção de Menu | Regras de Negócio |
PLSA790V - Auditoria | Alteração | Atualizações -> Auditoria-> Auditoria por Guia | 3, 5, 6, 7, 8, 10, 17 |
PLSANALM – Model | Alteração | - | 3 |
PLSA790C – Control | Alteração | - | 4 |
PLSA090 - Atendimento | Envolvida | Atualizações-> Atendimento | 9, 13, 14 |
PLSA498 | Envolvida | - | 12 |
PLSA980 | Envolvida | Atualizações-> Operadora -> Operadores do Sistema | 2.1 |
PLSMFUN | Envolvida | - | 9, |
PLSA974 | Envolvida | - | 11 |
PLSA720 | Envolvida | - | 15 |
PLSVLRPRO | Envolvida | - | 15 |
PLSMPROM | Envolvida | - | 16 |
Funções / Recursos | Descrição |
PLGRVDIAG | Grid genérico |
PLSDADUSR | Validação de Usuário |
PLSDADRDA | Validação da Rede de Atendimento |
PLSA090PRO | Validação de Procedimentos |
PLSRETCOP | Calcula co-participação |
PLS720IBD7 | Grava dados na BD7 |
PLSCOMEVE | Calcula eventos |
PlsWFProc | Função de envio de e-mails |
MSGALERT | Exibir um alerta para o usuário |
Alert | Exibir um alerta para o usuário |
MSGYESNO | Tela de confirmação, onde o usuário pode selecionar sim ou não. |
Tabelas Utilizadas
- BX4 – Operadores x Instituições.
- SX6 – Parâmetros.
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 Operadores do sistema com a nova opção de permitir inclusão de procedimentos.
Protótipo 02 - tela de Auditoria, com o botão de Incluir.
Protótipo 03 - Mensagem do sistema, informando que a RDA da guia não possui e-mail cadastrado e se deseja continuar.
Protótipo 04 - Tela de Manutenção de procedimentos
Fluxo do Processo
Fluxo 1 - Fluxograma Básico sobre a funcionalidade
Caso 1 - Caso de Uso da Funcionalidade
Dicionário de Dados
Parâmetros:
Nome Var. | MV_MOTTISS |
Tipo | Caracter |
Descrição | Indicar o código padrão da TISS utilizado para negar as guias que serão recriadas na auditoria. |
Tabelas:
Tabela BX4 - Operadores x Instituições.
Campo | BX4_PROAUD |
Tipo | Caracter |
Tamanho | 1 |
Decimal | 0 |
Título | Inclui Proc.. |
Descrição | Inclui Procedimento |
Usado | Sim |
Obrigatório | Não |
Browse | Sim |
Contexto | Real |
Propriedade | Alterar |
Help | O auditor pode efetuar manutenção na guia? |
Inicializador do campo | "0" |
Lista de Opções | 0=NAO; 1=SIM |
Este documento é material de especificação dos requisitos de inovação, trata-se de conteúdo extremamente técnico. |
---|