Árvore de páginas

Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.
Comentário: Migration of unmigrated content due to installation of a new plugin

 

 

 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

 Datasul

Módulo 

Gestão de Planos de Saúde

Segmento Executor

 

Projeto1

 

IRM1

 

Requisito1

 

Subtarefa1

 

Saúde

Chamado

TSHMOA

Chamado2

 

País

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

(  ) USA  (  ) Colombia   (  ) Outro _____________.

Objetivo

Disponibilizar uma interface simples para realização de Solicitação de Exames onde possa ter campos TISS obrigatórios parametrizáveis.

Outros

<Caso necessário informe outras referências que sejam pertinentes a esta especificação. Exemplo: links de outros documentos ou subtarefas relacionadas>.

   Legenda: 1 – Inovação 2 – Manutenção (Os demais campos devem ser preenchidos para ambos os processos). 

(Obrigatório)

Objetivo

 

<Nesta etapa informar o objetivo da especificação do requisito, ou seja, o que a funcionalidade deve fazer. Exemplo: Permitir que o usuário defina o percentual mínimo em espécie (dinheiro), a referência mínima para calculo dos débitos do aluno e o período de validade do parâmetro de negociação>.

(Obrigatório)

Definição da Regra de Negócio

 

<Regra de negócio é o que define a forma de fazer o negócio, o processo definido e/ou as regras que devem ser contempladas. Devem ser descritas restrições, validações, condições e exceções do processo. Caso necessário, incluir neste capítulo também regras de integridade que devem ser observadas no momento do desenvolvimento>.

 

<Na tabela abaixo informe quais são as rotinas envolvidas, o tipo de operação, a opção de menu e se necessário uma breve descrição das regras de negócio relacionadas a rotina>.

 

Rotina

Tipo de Operação

Opção de Menu

Regras de Negócio

[ACAA040 – Parâmetros]

[Alteração]

[Atualizações -> Acadêmico-> Tesouraria]

-

[ACAA050 – Negociação Financeira]

[Envolvida]

[Atualizações -> Acadêmico-> Tesouraria]

-

[ACAA060 – Cadastro de Pedidos]

[Criação]

[Atualizações -> Acadêmico-> Cadastros]

-

 

Exemplo de Aplicação:

  • Criar o campo “% Mínimo Espécie” (AAA_PERESP) onde o usuário informará o % que o aluno pagará em dinheiro. Esse % poderá ser alterado durante a negociação.
  • Criar o campo “Referência Mínima para Cálculo” (AAA_REFCAL) onde o usuário informará um dos 4 valores disponíveis para pagamento das mensalidades  como a referência mínima para calcular o débito total do aluno.
  • Criar o parâmetro MV_ACPARNE que definirá se as informações de “% Mínimo Espécie” e “Referência Mínima para Cálculo” serão obrigatórias.
  • O parâmetro MV_ACPARNE deve ter as seguintes opções: 1=Obrigatório e 2=Opcional. Deve ser inicializado como opcional>.

 

Tabelas Utilizadas

  • SE2 – Cadastro de Contas a Pagar
  • FI9 – Controle de Emissão de DARF>.

Opcional

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

 

 

 Image Removed

 

 

 

 

 

 

Opcional

Fluxo do Processo

 

<Nesta etapa incluir representações gráficas que descrevam o problema a ser resolvido e o sistema a ser desenvolvido. Exemplo: Diagrama - Caso de Uso, Diagrama de Atividades, Diagrama de Classes, Diagrama de Entidade e Relacionamento e Diagrama de Sequência>. 

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>

 

(Opcional)

Grupo de Perguntas

 

<Informações utilizadas na linha Protheus>.

 

Nome: FINSRF2

X1_ORDEM

01

X1_PERGUNT

Emissão De

X1_TIPO

D

X1_TAMANHO

8

X1_GSC

G

X1_VAR01

MV_PAR01

X1_DEF01

Comum

X1_CNT01

'01/01/08'

X1_HELP

Data inicial do intervalo de emissões das guias de DARF a serem consideradas na seleção dos dados para o relatório 

 

(Opcional)

Consulta Padrão

<Informações utilizadas na linha Protheus>

 

Consulta: AMB

Descrição

Configurações de Planejamento

Tipo

Consulta Padrão

Tabela

“AMB”

Índice

“Código”

Campo

“Código”; ”Descrição”

Retorno

AMB->AMB_CODIGO

 

Esta interface fará utilização das funcionalidades abaixo:

Cadastro de Favoritos

Mensagem de Procedimento

Manutenção de Apelidos

 

Definição da Regra de Negócio


REQ001

Criar novos parâmetros para indicar a obrigatoriedade de preenchimento dos campos da TISS


REQ002

Criar nova tela de “Guia Eletrônica”, onde os campos que serão exibidos em tela e a obrigatoriedade de preenchimento dos mesmos bem como seu valor default poderá ser definido via arquivo de propriedades. O Campo indicação Clinica seguirá as regras de obrigatoriedade da TISS. Segue abaixo demais componentes e comportamentos da tela:

  • Pesquisa de procedimentos com autocomplete por apelido, nome ou parte do nome e código do procedimento.
  • Possibilidade de adicionar ou remover um procedimento da lista de favoritos
  • Possibilidade de editar o apelido do procedimento na lista de favoritos
  • Componente com a exibição dos procedimentos favoritos para seleção do medico caso necessário, com opção para mostrar/esconder a lista de favoritos. O Botão “mostrar” deve ficar na mesma posição do botão “Esconder”
  • Ao adicionar um serviço na guia, deverá ter a possibilidade de editar a quantidade, adicionar ou remover o procedimento da lista de favoritos ou remover o serviço da guia.
  • Segue abaixo as informações disponíveis para cada serviço:
    • Indicador Sequencial do serviço
    • Código do Procedimento
    • Descrição do Procedimento
    • Quantidade (Esta opção será editável) com valor 1 como default
    • Opção para excluir procedimento da solicitação
    • Opção para incluir o procedimento na lista de favoritos
    • Caso o procedimento seja um Pacote, não exibir seus itens relacionados, exibir apenas o principal
    • Caso o procedimento faça parte de um pacote, tratar a tela da mesma forma que faz no Autorizador, em que o sistema questiona ao usuário qual pacote deseja utilizar, com a opção de escolher “nenhum”, indicando que quer apenas aquele procedimento “avulso”, sem travar a usabilidade da tela
    • Caso o procedimento seja um Agrupador (PAPROINS.LOG-3), carregar todos o seus associados (PACPROCE) com suas quantidades parametrizadas, permitindo edição.
    • Caso o procedimento possua Variações (TSCQIV e TSNEVT), exibir o procedimento com todas as suas variações em uma lista (com fonte menos destacada)
    • Caso o procedimento caia na regra de validade (TRFES0), exibir a data de ultima utilização, a combo-box de justificativas (nenhuma selecionada como default, exigir que o usuário escolha) e opção de justificar com texto (semelhante ao que já faz no Autorizador). Se o usuário não justificar, apontar erro no botão “Solicitar guia”. Enquanto não estiver justificado, destacar o procedimento em Amarelo ou Vermelho, de modo a ficar explícito que há uma pendência para poder finalizar a guia. Usar o mesmo tipo de destaque para Variações enquanto ele não selecionar ao menos uma.

 

  • Botão para Enviar a solicitação
    • O retorno do envio deverá ser disponibilizado para visualização com o numero da guia e glosas caso houver
  • Botão para cancelar a solicitação
    • Deverá voltar para a tela de seleção do Tipo de Atendimento
  • Botão Usos do Beneficiário – voltar para a tela de Usos do beneficiário

 

<REQ001 e  REQ002 >

Tela SADT Simplificada

 

Criar novos parâmetros exibir/ocultar e indicar a obrigatoriedade de preenchimento dos campos da TISS. Segue abaixo os campos que deverão ser validado sua obrigatoriedade de acordo com a parametrização:

21 – Caráter de atendimento

33 – Tipo de de Acidente

34 – Tipo de Consulta

58 – Observações / justificativa – Caso o usuário informar uma justificativa em tela, não solicitar novamente caso a guia fique pendente

 

SP/SADT Simplificada

  • Ao selecionar a opção “Solicitar” no momento do atendimento do Beneficiário, o sistema deverá ser redirecionado para a tela de Solicitação de Guias. Para prosseguir com a solicitação, o médico deverá selecionar o tipo de atendimento.
    • Internação: Amarrado ao grupo 7 - Internação na tabela TISS-TIP-ATENDIM
    • Terapias: Amarrado ao grupo 3 - Terapias na tabela TISS-TIP-ATENDIM
    • SP/SADT: Amarrado aos demais grupos na tabela TISS-TIP-ATENDIM
    • A ordem dos tipos de atendimento deverá seguir assim: SP / SADT, Terapias e Internação

Após selecionar o tipo de atendimento, o sistema abrira a Guia de Solicitação de acordo com o tipo de atendimento.

Os subtipos podem ser parametrizados com uma classe de nota / transação. Para maior entendimento visualizar chamado “TQYFYV

Nesta primeira release do Perfil Médico não esta contemplada a solicitação de internação bem como os atendimentos vinculados (Usos do beneficiário).

A pesquisa dos procedimentos utilizará o componente de pesquisa inteligente, onde após inserir o segundo digito o sistema buscará os serviços(Procedimento, Insumo, OPME e Pacotes) disponíveis que contenham os dígitos em alguma parte do nome / código nas tabelas de procedimentos, insumos, pacotes ou até mesmo nos apelidos definidos pelo médico. Demais Informações sobre o componente se encontram disponíveis na especificação do chamado TSEUER

  • Esta Pesquisa sofrerá alteração para trazer apenas os serviços vinculados ao tipo de atendimento. Os serviços serão pesquisados de acordo com a Transação x Módulo x Procedimento
  • Ao buscar os procedimentos no componente de pesquisa rápida, caso o mesmo estiver incluído em algum pacote, será exibido uma tabela com a lista dos pacotes, podendo selecionar um pacote para adicionar na lista de Serviços ou adicionar somente o procedimento em questão na guia
  • Alerta validade de Solicitação / Execução: Ao adicionar um procedimento na lista de serviços da guia, deverá buscar a data de validade da última realização do mesmo e se o procedimento já consta Autorizada em outra guia. Caso ainda esteja no prazo de validade ou Autorizada, o médico será obrigado a informar uma justificativa para o procedimento. Caso a justificativa já tenha sido informada em tela, o sistema não solicitará nova justificativa. Não será necessário informar justificativa novamente, pois no momento que o médico adicionar o procedimento na guia, já será possível saber se o mesmo precisa de uma justificativa vinculado, não permitindo enviar a guia para o GP sem a seleção da mesma. A justificativa é por procedimento.
  • TSCQIV – Variações de Procedimento: Ao pesquisar um procedimento caso o mesmo já esteja contido no cadastro de variações, a pesquisa retornará apenas as variações para que o médico selecione. Será possível selecionar as variações desejadas. Cada variação selecionada será tratada como um novo procedimento para envio ao Gestão de Planos

Será possível navegar entre os procedimentos cadastrados como favoritos pelo médico, podendo adiciona-los na lista de procedimentos para solicitação na guia.  

    • Os serviços que não são vinculados ao tipo de atendimento selecionado na tela anterior, não deverão ser listados
    • Opção para remover o serviço da lista de favoritos
    • Exibir o apelido do serviço caso o mesmo estiver cadastrado Ex.: HEM - HEMODIALISE (POR SESSÃO)
    • Opção para esconder / exibir a tabela dos serviços favoritos bem como inserir/editar um apelido

Ao inserir um serviço na guia, possuirá os componentes abaixo:

    • Exibir a sequencia do serviço
    • Código e descrição do serviço
    • Quantidade Solicitada (possibilitar inserir a quantidade)
    • Opção para remover o serviço da guia
    • Opção para adicionar/remover o serviço da lista de favoritos

 

Obrigatoriedade do campo indicação clinica de acordo com a opção selecionada no campo “Tipo de Atendimento”.

Deverá ter um checkBox para indicar se o atendimento se trata de um recém nascido (Campo 12 da TISS)

Deverá ter opção de data de solicitação futura conforme Autorizador WEB

Será adicionado em tela 3 botões, “Solicitar Guia”para enviar a solicitação da guia integrar com o Gestão de Planos, um botão para cancelar a solicitação e outro “Usos do Beneficiário” para retornar". Caso retorne para o “Usos do Beneficiário”, a digitação será descartada.

  • Ao Finalizar o atendimento, o sistema devera retornar para a tela de Solicitação exibindo uma tabela contendo as guias Solicitadas durante o mesmo atendimento. Exibir as colunas abaixo:
    • Número da Guia
    • Tipo de Atendimento
    • Status

 

Esta lista de procedimentos Solicitados deverá ter a opção de impressão da Guia no padrão TISS. Cada registro possuirá um botão imprimir, sendo impresso apenas individualmente.

  • Imprimir apenas a guia selecionada

 

Ao clicar sobre uma guia, exibir os procedimentos de forma agrupada, semelhante a tela de Usos do beneficiário. Ao selecionar um registro de agrupado expandir os procedimentos exibindo as informações abaixo:

    • Código do Procedimento
    • Descrição do Procedimento
    • Quantidade Solicitada
    • Quantidade Autorizada
    • O processo de solicitação de guias fará as mesmas validações já existentes Autorizador
    • Será exibido em tela o retorno da Solicitação com o status da guia. Caso tenha ocorrido com êxito será exibido o número da guia criada e redirecionado para a tela de histórico de atendimento do beneficiário. Se ocorrer algum erro de validação ou glosa será exibido para o médico

 

Campos que serão habilitados por default:

 Guia :

  •  Tipo de Consulta (Obrigatório)
  • Carater de Atendimento
  • Tipo de Acidente (Obrigatório)
  • Atendimento RN
  • Indicação Clinica
  • Observação / Justificativa

 Serviços:

  •  Quantidade

 

Ao selecionar a opção “Solicitar” na tela de atendimento, o sistema redirecionará para a tela de seleção do tipo de atendimento conforme cadastro no GP. Cadastro de tipo de atendimento desenvolvido através do chamado TQYFYV.

Image Added

 

Ao selecionar o tipo de atendimento, o sistema redirecionará o médico para a tela de Solicitação. Segue abaixo protótipo de tela:

Image Added

 

 

 

Casos de teste

Obs.: Todas as regras envolvendo Propriedades, funcionarão da mesma forma que o Autorizador, pois ambos vão utilizar a mesma camada de negócio no EJB. Portanto os testes abaixo não serão a nível de parametrizações das propriedades.

 

Caso de Testes

CT001

 
 

Pré-condições

 

 

Procedimentos

Resultados Esperados

 

Acessar Arquivo de propriedades JBOSS_HOME\server\default\conf\ sadt_fields.properties

  • Alterar o Valor default e obrigatoriedade e se ficará disponível em tela
  • Iniciar o Jboss
  • Acessar tela de Solicitação de guia

 

Ao entrar na tela de solicitação de SADT os campos Tipo de consulta, tipo de Atendimento e tipo de Acidente deverão estar preenchidos de acordo com o que foi cadastrado.

Verificar observações acima sobre os campos necessários para a solicitação SADT TISS 3.02. – Apenas esses campos poderam ser modificados além de Atendimento RN, os demais são dados vinculados ao médico/clinica que serão atribuídos pelo sistema

Ok, devem estar de acordo com o padrão TISS da ANS.

 

Caso de Testes

CT002

 
 

Pré-condições

REQ002 Concluido

 

 

Procedimentos

Resultados Esperados

 

Preencher todos os campos da Guia Exceto

Teste 1 - Tipo de Consulta

Teste 2 - Tipo de Atendimento

Teste 3 – Tipo de Acidente

 

 e clicar em enviar

 

 

 

 

 

Ao clicar em enviar uma mensagem deverá ser exibida informando a obrigatoriedade do Campo que não foi preenchido

 

Caso de Testes

CT003

 
 

Pré-condições

REQ002 Concluido

 

 

Procedimentos

Resultados Esperados

 

Preencher todos os campos obrigatórios porém não adicionar nenhum procedimento na guia

 

 

 

 

Uma mensagem deverá ser exibida informando que não é possível incluir uma guia sem procedimentos

 

Caso de Testes

CT004

 
 

Pré-condições

REQ002 Concluido

 

 

Procedimentos

Resultados Esperados

 
  • Preencher todos os campos obrigatórios.
  • Adicionar um procedimento que o prestador possa solicitar (Hemograma)
  • Clicar em Salvar

 

Ao salvar deverá retornar para a tela de histórico de atendimento com uma mensagem informando que a guia foi criada com sucesso e disponibilizando o número de autorização

 

Caso de Testes

CT005

 
 

Pré-condições

REQ002 Concluido

 

 

Procedimentos

Resultados Esperados

 
  • Logar com como administrador
  • Cadastrar propriedade com.totvs.saude.guide.sadt.divide com valor “false”
  • Acessar perfil medico
  • Selecionar Beneficiario
  • Solicitar SADT
  • Preencher todos os campos obrigatórios.
  • Adicionar um procedimento que necessite de auditoria e um que não necessite
  • Salvar guia

Ao salvar a guia deverá retornar mensagem que a guia esta pendente Analise e exibir o número da guia.

 

Caso de Testes

CT006

 
 

Pré-condições

REQ002 Concluido

 

 

Procedimentos

Resultados Esperados

 
  • Logar com como administrador
  • Cadastrar propriedade "com.totvs.saude.guide.sadt.divide" com valor “true”
  • Acessar perfil medico
  • Selecionar Beneficiário
  • Solicitar SADT
  • Preencher todos os campos obrigatórios.
  • Adicionar um procedimento que necessite de auditoria e um que não necessite
  • Salvar guia

Ao salvar a guia, uma guia ficará pendente de Analise e outra deverá ficar como Autorizada, exibindo o número das guias criadas

 

 

Caso de Testes

CT007

 
 

Pré-condições

REQ002 Concluido

 

 

Procedimentos

Resultados Esperados

 
  • Acessar perfil medico
  • Selecionar Beneficiario
  • Solicitar SADT
  • Preencher todos os campos obrigatórios.
  • Adicionar um procedimento com glosa restritiva
  • Salvar Guia

 

Ao tentar salvar a guia o sistema identificará uma glosa restritiva para mesmo e não permitira a criação da guia.

 

 

Caso de Testes

CT008

 
 

Pré-condições

REQ002 Concluido

 

 

Procedimentos

Resultados Esperados

 
  • Acessar perfil medico
  • Selecionar Beneficiario
  • Solicitar SADT
  • Preencher todos os campos obrigatórios.
  • Adicionar um procedimento com glosa administrativa (Quantidade excedida por exemplo)

 

O sistema informarára o número da guia e que a mesma ficou em Analise

 

 

 

Observação: No momento de salvar as guias no GP, caso seja identificado alguma glosa de Cadastro, parametrização ou estrutura de produto, o sistema exibira uma mensagem com a glosa e não permitira salvar a guia, até que o problema seja corrigido.

Caso de Testes

CT009

 
 

Pré-condições

REQ002 Concluído

 

 

Procedimentos

Resultados Esperados

 
  • Acessar perfil medico
  • Selecionar Beneficiário
  • Solicitar SADT
  • Preencher todos os campos obrigatórios.
  • Adicionar um procedimento valido
  • Salvar Guia
  • Voltar para tela de solicitação
  • Voltar para tela de Usos do Beneficiário

A guia deverá ser salva com Sucesso.

Ao voltar para a tela de Solicitação essa guia deverá estar na lista das guias criadas durante o atendimento

Ao voltar para tela de Usos do beneficiário a guia deverá estar listada

A guia deve ficar com Status “digitada” no AT do GP

O Autorizador / Perfil não possui o conceito de guia digitada. A guia poderá ficar pendente de auditoria, Autorizado ou negado no momento da solicitação.

Para as guias com status “digitada” possui o conceito de guia rascunho existente apenas no Autorizador.

 



Especificação Técnica

 

Artefatos envolvidos


Artefato

Projeto

Descrição

SadtAction.java

WAC2WEB

Action da tela SADT do Autorizador

ProcedureSolicitationService

WAC2EJB

Implementação do EJB de solicitação

ProcedureSolicitationLocal

WAC2EJB

Interface com a definição dos métodos do EJB

solicitexam.detail.html

PerfilMedico

Tela de solicitação SADT

solicitexam.js

PerfilMedico

Define as rotas e controllers

 de tela

solicitexam-services.js

PerfilMedico

Define as rotas e controllers

 de tela

SolicitExamResouce.java

PerfilMedico

Define os métodos que serão executados pela camada WEB e chama a camada EJB

 

 

 


<REQ001>

Campos TISS Obrigatórios. Parametrizar Valores Campos TISS


A parametrização dos campos TISS será através do arquivo de propriedades denominado "sadt_fields.properties" que ficará armazenado com diretorio conf da instancia do Jboss

Abaixo um exemplo da estrutura deste arquivo

#### ESTRUTURA DE PROPRIEDADE #######

#nome_propriedade = Nome de como será lido a propriedade no java
#nome_campo = Nome do campo da Tiss
#valor_default = valor default do campo
#propriedades_do_campo = 1 - Visivel, 2 - Visivel e Obrigatório, 3 - invisivel

#nome_propriedade=nome_campo;valor_default;propriedades_do_campo;


#Indicação de Acidente
indicacao_acidente=acidentType;0;2
#tipo de consulta
tipo_consulta=consultType;1;1
#Atendimento a Rescem Nascido
atendimento_rn=attendanceRN;false;1
#Caráter de Atendimento
carater_atendimento=attendanceCharacter;E;2
#Indicação clinica
indicacao_clinica=clinicIndicator; ;1
#Observação / Justificativa
observacao_justificativa=observation; ;1
#Observação para o Auditor
observacao_auditor=descriptionAuditor; ;1

A verificação destas regras devera ser construída na classe /PerfilMedico/src/com/totvs/html/framework/perfilmedico/resource/SolicitExamResource.java

no momento de envio para a criação da guia, também deverá ser verificado estas propriedades

com.totvs.saude.business.proceduresolicitation.implementation.ProcedureSolicitationService.validate(ProcedureSolicitationData, ProviderConfigurationProgressVo, List<ProcedureSolicitationDetailData>, boolean)

 

<REQ002>

Guia SADT Simplificada

 

A pesquisa dos procedimentos utilizará o componente de pesquisa inteligente, onde após inserir o segundo digito o sistema buscará os serviços(Procedimento, Insumo, OPME e Pacotes) disponíveis que contenham os dígitos em alguma parte do nome / código nas tabelas de procedimentos, insumos, pacotes ou até mesmo nos apelidos definidos pelo médico

  • Deverá ser possível navegar entre os procedimentos cadastrados como favoritos pelo médico, podendo adiciona-los na lista de procedimentos para solicitação na guia.
  • A obrigatoriedade e visibilidade dos campos da TISS será tratada de acordo com o que foi cadastrado no arquivo de propriedades.
  • Ao inserir um serviço na guia, possuirá os componentes abaixo:
    • Sequencia do serviço
    • Código e descrição do serviço
    • Quantidade Solicitada (possibilitar alterar a quantidade)
    • Opção para remover o serviço da guia
    • Opção para adicionar/remover o serviço da lista de favoritos
    • Valor de Participação (A busca desse valor esta sendo tratada no chamado TRULEL)
  • Obrigatoriedade do campo indicação clinica de acordo com a opção selecionada no campo “Tipo de Atendimento”. Parametrizado no cadastro de Tipo de Atendimento do GP

 

  • Serão adicionados em tela 3 botões, uma para enviar a solicitação do exame e integrar com o Gestão de Planos, um botão para cancelar a digitação e retornar para a seleção do Tipo de Atendimento e outro para retornar para o Usos do Beneficiário.
    • Será exido em tela o retorno da Solicitação. Caso tenha ocorrido com êxito será exibido o número da guia criada e redirecionado para a tela de histórico de atendimento do beneficiário. Se ocorrer algum erro de validação ou glosa será exibido para o médico.


Guia SP/SADT Simplificada:

Para este desenvolvimento será necessário alterar alguns métodos da classe SadtAction do projeto WAC2Web. Esta alteração se faz necessário devido a maioria das regras de negócio e regras de validação do sistema estarem contidas nessa classe. Com essa alteração será possível reutilizar as validações para o Perfil Médico.

 

Métodos que deverão ter a regra de negócio migradas para a Camada EJB:

 

  • saveSadt
    • Verifificar todos os objetos utilizados do Bean e criar como parâmetros de entrada
  • requestAuthorizationGuide2
    • Verifificar todos os objetos utilizados do Bean e criar como parâmetros de entrada

 

Os método poderão continuar na camada WEB porém as regras de negocio deverão ser migradas para a camada EJB, deixando apenas encarregado de chamar o EJB e exibir as informações do FacesContext

 

Métodos que sofrerão impacto com essa alteração:

authorizeGuide

saveDraft

registerGuide

registerGuideTISS3

requestAuthorizationGuide2

 

Resource

 

Ao salvar a solicitação deverá cair no resource. O Resource será responsável por efetuar as buscas no Gestão de Planos e preencher as informações obrigatórias na guia e chamar os métodos da camada EJB.

  •  Neste momento será necessário efetuar a busca na tabela “ParameterFields” para definir os campos que serão necessário trazer o registro para exibir em tela.

 Segue abaixo as informações que deverão ser preenchidas:

Obs: Os itens em negrito são obrigatório o preenchimento para TISS 3, os campos que não possuir em tela deverão ser buscados no banco e populados no objeto ProcedureSolicitationData

 

Guia :

 

solicitationType = Tipo de solicitação /*  Valor fixo “SO”   */

clinicCode = Código da clinica

codeUnitProviderPrincipal = Código Unidade do Prestador Principal

codeProviderPrincipal = Código do Prestador Principal

providerCode = Código do Prestador solicitante (unidade + código do prestador)

registrationId = Carteira do beneficiário

attendanceType = Tipo de Atendimento

consultType = Tipo de Consulta

accidentType = Tipo de Acidente

solicitationDate = Data da solicitação

InternmentCharacter = Carater do Atendimento /* E ou U*/ será passado sempre com valor E

CouncilCode = Conselho do profisisonal Solicitante

CouncilType = Código do tipo do conselho

CouncilState = Estado do Conselho

Cbos = CBO do profissional Solicitante

AttendanceRN = Atendimento a rescem nato /*false, true*/

clinicIndicator = Indicação Clinica

observation = Observações da Guia

 

Serviços :

AnnexType = tipo do anexo (A principio será passado valor 0, pois não há guias anexo)

quantitySolicitation = Quantidade Solicitada

InternmentCharacter = Carater de atendimento

serviceType = tipo do serviço

serviceId = Codigo do Procedimento / insumo

 

Regras que deverão ser verificadas:

 Chamado TRFES0  Unimed Nordeste - Alerta Validade de Exame

 Ao salvar a guia e enviar para o GP, o sistema deverá exibir o retorno em tela, listando o número da guia criada (caso a mesma fique dividida em varias guias mostrar de todas) e as glosas retornadas do Gestão de Planos.

  • Criar registro na tabela CheckinGuide, o numero do registro de checkin esta armazenado na tabela da fila de atenidmento

 

Diagrama de Classes

 

Image Added

 

(Opcional)

Estrutura de Menu

 

<Informações utilizadas na linha Datasul>.

 

Procedimentos

 

Procedimento

 

 

 

Descrição

(Max 40 posições)

(Max 40 posições)

(Max 40 posições)

Módulo

 

 

 

Programa base

 

 

 

Nome Menu

(Max 32 posições)

(Max 32 posições)

(Max 32 posições)

Interface

GUI/WEB/ChUI/Flex

GUI/WEB/ChUI/Flex

GUI/WEB/ChUI/Flex

Registro padrão

Sim

Sim

Sim

Visualiza Menu

Sim/Não

Sim/Não

Sim/Não

Release de Liberação

 

 

 

 

 

 

Programas

 

Programa

 

 

 

Descrição

(Max 40 posições)

(Max 40 posições)

(Max 40 posições)

Nome Externo

 

 

 

Nome Menu/Programa

(Max 32 posições)

(Max 32 posições)

(Max 32 posições)

Nome Verbalizado[1]

(Max 254 posições)

(Max 254 posições)

(Max 254 posições)

Procedimento

 

 

 

Template

(Verificar lista de opções no man01211)

(Verificar lista de opções no man01211)

(Verificar lista de opções no man01211)

Tipo[2]

Consulta/Manutenção/ Relatório/Tarefas

Consulta/Manutenção/ Relatório/Tarefas

Consulta/Manutenção/ Relatório/Tarefas

Interface

GUI/WEB/ChUI/Flex

GUI/WEB/ChUI/Flex

GUI/WEB/ChUI/Flex

Categoria[3]

 

 

 

Executa via RPC

Sim/Não

Sim/Não

Sim/Não

Registro padrão

Sim

Sim

Sim

Outro Produto

Não

Não

Não

Visualiza Menu

Sim/Não

Sim/Não

Sim/Não

Query on-line

Sim/Não

Sim/Não

Sim/Não

Log Exec.

Sim/Não

Sim/Não

Sim/Não

Rotina (EMS)

 

 

 

Sub-Rotina (EMS)

 

 

 

Localização dentro da Sub Rotina (EMS)

 

 

 

Compact[4]

Sim/Não

Sim/Não

Sim/Não

Home[5]

Sim/Não

Sim/Não

Sim/Não

Posição do Portlet[6]

0 – Top Left

1 – Top Right

2 – Bottom Left

3 – Bottom Right

0 – Top Left

1 – Top Right

2 – Bottom Left

3 – Bottom Right

0 – Top Left

1 – Top Right

2 – Bottom Left

3 – Bottom Right

Informar os papeis com os quais o programa deve ser vinculado

 

 

 

 

Cadastro de Papéis

<O cadastro de papéis é obrigatório para os projetos de desenvolvimento FLEX a partir do Datasul 10>.

<Lembrete: o nome dos papeis em inglês descrito neste ponto do documento, devem ser homologados pela equipe de tradução>.

 

Código Papel

(máx 3 posições)

Descrição em Português*

 

Descrição em Inglês*

 

[1] Nome Verbalizado é obrigatório para desenvolvimentos no Datasul 10 em diante.

[2] Tipo é obrigatório para desenvolvimento no Datasul 10 em diante

[3] Categorias são obrigatórias para os programas FLEX.

[4] Obrigatório quando o projeto for FLEX

[5] Obrigatório quando o projeto for FLEX

[6] Obrigatório quando o projeto for FLEX

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