A Especificação Reembolso

Especificação Funcional e Técnica

Reembolso Beneficiário x

Digitação Portal

1. Definição do Documento:

Número SAC:	8000024642
Módulo Top Saúde:	REEMBOLSO>>PROTOCOLO MULTIPLO>>INCLUSÃO
Funcionalidade:	Portal Segurado/ Corretor
Requisito:	Vide detalhamento da EF – item 2.
Início EF:	10/02/2015
Término EF:	18/02/2015
Revisão:	10/06/2016 até 05/07/2016
Estimativa h/h:

SAC Nº	PARTICIPANTE	DATA:

Áreas envolvidas e Responsáveis:

Áreas	Responsáveis	Assinaturas
TI	Adriana Toninatto
Contas Médicas	Amauri L. Porfirio

1. Detalhamento da Especificação:

a) DIGITAÇÃO DO REEMBOLSO NO PORTAL:

• O sistema deve permitir o preenchimento do “protocolo de reembolso”, através do login e senha de acesso do Segurado ou Empresa/RH ao Portal Marítima, para antecipação da análise do processo de reembolso.

b) REQUISITOS DA TELA:

 

• A tela deve permitir a inclusão de anexos, para recibos e relatórios (PDF) em geral (quando em outra extensão o sistema deve emitir alerta) e o campo específico para Nota Fiscal Eletrônica quando utilizado este deve obrigar o preenchimento do número da Nota Fiscal.

• O sistema, deve exibir a informação/ orientação abaixo, para cada um destes campos, ao passar mouse sobre eles:

“Verifique os documentos obrigatórios necessários para este tipo de solicitação de reembolso.”

• Basicamente as informações preenchidas via Portal, alimentará a tela Reembolso>>Protocolo Múltiplo>>Inclusão/Alteração e inclusive Delphi, acrescidas das informações do recibo, sendo algumas destas campos obrigatórios.

• Os dados bancários do segurado titular, deverão ser exibidos na tela e confirmados através de pop-up:

Atualizado

Fecha pop-up/ prossegue preenchimento.

Desatualizado

Abrirá novo pop-up com as informações de contato da central de atendimento: POR FAVOR, ENTRE EM CANTATO COM A CENTRAL DE ATENDIMENTO PARA REGULARIZAR SEUS DADOS BANCÁRIOS, EM ATÉ 24 HORAS, CASO CONTRÁRIO SEU REEMBOLSO SERÁ DEVOLVIDO AUTOMATICAMENTE. CENTRAL DE ATENDIMENTO: SP [phone] DEMAIS REGIÕES: 0800-77-19-119 (Observação: O sistema deve permitir atualizar estas informações de contato se necessário). Este pop-up deve ter um botão “ok”, para fechá-lo e prosseguir com a digitação. De forma, que a digitação do protocolo poderá prosseguir, no entanto, na impressão, deve haver a mensagem com a seguinte informação: “ATUALIZE SEUS DADOS BANCÁRIOS EM ATÉ 24 HORAS, ATRAVÉS DA CENTRAL DE ATENDIMENTO: SP [phone] OU DEMAIS REGIÕES: 0800-77-19-119. CASO CONTRÁRIO SEU REEMBOLSO SERÁ DEVOLVIDO AUTOMATICAMENTE.”

c) CADASTRO DOS DOCUMENTOS:

• Para cada tipo de reembolso, haverá uma lista de exigências de documentos para orientação ao segurado.

• Desta forma, tão logo ele selecione o “tratamento”, na tela deve carregar a lista da documentação necessária, em ordem alfabética e indicando quando obrigatório, conforme parametrização.

• Para que esta relação, possa sempre ser revisitada, deverá ser criado um parâmetro para cadastro dos documentos necessários para cada tipo de tratamento.

d) TIPO DE ATENDIMENTO/TRATAMENTO:

• O segurado deve preencher o tipo de atendimento da solicitação de reembolso, exemplo:

“Consulta Eletiva” e ainda neste caso, o sistema, automaticamente deverá carregar no Delphi no momento da análise deste reembolso o código 00010014.

• Para os demais tipos, o analista que será encarregado da digitação do item, no Delphi no momento da análise.

• O tipo de tratamento será listado para opção, de acordo com o cadastro, conforme item acima “C”.

• Provavelmente será agrupado na parametrização os tipos de tratamento, para tanto, a tela, deve trazer a opção de tipos de tratamentos existentes para vínculo na nomenclatura que será criada para apresentação no portal.

• O analista no momento da análise, ficará encarregado de lançar o detalhamento dos honorários.

e) ANEXOS - Web e Delphi:

• Criar campos distintos para anexos em geral e para nota fiscal eletrônica, por tipo de atendimento.

• O sistema, deve exigir a inclusão de um ou outro para geração do protocolo/ finalização da inclusão do protocolo.

• E também deve permitir, uma nova inclusão, desde que a situação do reembolso permita, ou seja: Protocolado/ Devolvido quando estiver em “analise” não deverá permitir alteração via Portal.

• Sempre que inserido novos anexos, o sistema imprimirá novo Protocolo de Reembolso, atualizando os dados, gerando novo prazo para limite de pagamento, no entanto, deve ser preservado o mesmo número de protocolo, atualizando a descrição de todos os documentos.

• No Portal, Web ou Delphi os anexos, devem ficar disponíveis para consulta a qualquer momento.

• O sistema deverá permitir a inclusão de até 30 anexos.

• Estes, serão representados por “clipes”, ao clicar no ícone, deve ser possível visualizar a imagem.

• Enquanto o anexo não for aberto, através do acesso da operadora o ícone deve ficar representado pelo clips vermelho [pic 3]e após leitura verde [pic 4].

• Ao lado do nome do beneficiário em qualquer etapa do processo interno, deve haver um atalho para anexos, no entanto, deve ser diferenciada da seguinte maneira:

➔Quando houver anexos, não “lidos”, o ícone “Clips” deve ficar vermelho e com “animação”, enquanto os já lidos ficarão verde.

f) NOVA TELA – DIGITAÇÃO PORTAL:

• O processo digitado via portal, deverá ficar disponível para distribuição entre as equipes, (processo parecido com o atual em Autorização – Situação do Pedido).

• Esta tela deverá possuir filtros, por período/ tipo de atendimento/ beneficiário/contrato/data da solicitação (de/até)/ Situação do Pedido : Análise/ Deferido/ Indeferido/ Devolvido.

• Deverá permitir a visualização na tela ou extração em TXT.

• Deverá apresentar como resultado: Contagem de Pedidos/ Valor individual de cada pedido/ Valor total de todos os pedidos listados/ N. do Protocolo/ N. Recibo/ N. Nota Fiscal Eletrônica/ Data do Protocolo/ Data da Entrega do documento físico/ Situação/ Tipo de Atendimento/ Nome do Beneficiário/ Usuário/ Data Assumido por este usuário/ Atalho para anexo (clips verde/vermelho), atalho para acesso do pedido de reembolso na tela da Situação Atual.

• Sendo que quando acessado pela Web, permitirá apenas Devolução e Alteração, para análise, será necessário acessar através do Delphi (o sistema deve mencionar esta condição).

g)  PEDIDO BLOQUEIO x USUÁRIO:

• Quando um pedido de reembolso estiver sobre a análise de outro usuário, o sistema, deve abrir pop-up perguntando se realmente deseja assumi-lo, processo parecido com o que temos atualmente no Pedido de Autorização.

➔Deseja Assumir o Pedido de Reembolso? Ok? Cancelar?

Ao clicar em ok, o pedido deve ser assumido pelo usuário logado.

• O pedido ainda não assumido por nenhum usuário, deve assumir automaticamente aquele que o primeiro acessar.

• Inserir em todas as telas do Processo de Reembolso e em qualquer situação (visualização interna), o campo, USUÁRIO, para que seja possível a visualização de qual usuário está com determinado pedido e ou ainda o usuário que finalizou o processo.

• Quando o processo, ainda não estiver sido assumido por ninguém, o campo deverá ficar “sem preenchimento”.

h) REGRA PARA EXCLUSÃO:

• O processo digitado via portal, deverá ser EXCLUÍDO (situação deve ser criada), automaticamente pelo sistema, após 10 dias (criar parâmetro para definição de prazo), da inclusão, quando não houver o preenchimento do campo “Data de Recepção”, utilizado para informar a data de entrega do processo físico.

• Para exclusão automática o sistema não deverá considerar o pedido que possuir anexo de Nota Fiscal Eletrônica, pois estes dispensam o processo original.

• O processo poderá ser enviado para pagamento, somente quando preenchido o campo “data de recepção” – Documento Físico. Quando não preenchido o campo, o sistema deve emitir um pop-up de alerta, no momento da autorização: “O pagamento somente será possível, após o recebimento da documentação física”.

• A regra apenas não se aplica quando se tratar Nota Fiscal Eletrônica.

• E quando o processo for excluído automaticamente ou manualmente por falta da entrega da documentação, deve emitir uma e-mail padrão para o segurado, emitindo tal alerta. (criar parâmetro para texto padrão).

• Deve haver os motivos de exclusão previamente cadastrados para opção quando exclusão manual, no entanto quando exclusão automática o sistema deve adotar sempre a opção indicada pela Marítima na Parametrização.

• O reembolso excluído deve ser listado para consulta em vermelho, no entanto, após o período de tolerância e ou seja, pedido excluído deverá ser digitado novamente, não será possível reabilitar.

• i)  SITUAÇÃO: REEMBOLSO DEVOLVIDO:

• Esta condição, “devolvido”, deve ser definida pelo analista no momento da análise, Web ou Delphi – Funções já existentes.

• Ao devolver um pedido de reembolso, o sistema deve automaticamente abrir um pop-up com caixa para texto (considerando um texto padrão, com possibilidade de edição), e-mail e telefone cadastrado no início do processo.

• O analista deverá definir a forma de contato, através de “radio buttons” quando selecionado o e-mail, que será carregado automaticamente.

• Quando selecionado “Telefone”, o sistema deixará o campo texto, livre para obrigatório registro, do contato.

• Nas duas situações acima (e-mail ou contato telefônico), em todas as fases do processo, o sistema deverá manter o histórico para consulta neste processo quando necessário.

• Portanto, deverá ser criada uma aba de ocorrências, que deve ser visível apenas para a operação da Marítima e não no portal do beneficiário.

Todas as ações deverão ficar registradas nesta aba, inclusive a exclusão automática por falta de documentação física.

➔E-mail: No-Replay – Deve considerar o motivo da devolução ou excluído, pré-cadastrado.