Histórico da Página

Informações Gerais

Objetivo

Disponibilizar uma interface simples para realização de Solicitação de Exames onde possa ter campos TISS obrigatórios parametrizáveis. 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

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

O objetivo deste documento é descrever onde será aplicada a utilização do componente TSA em diferentes sistemas operacionais e navegadores web disponíveis. Os requisitos necessários para ter a funcionalidade que tem por objetivo principal, eliminar a dependência do plug-in Java no navegador.

“TOTVS Smart Agent HTTP Service” denominado simplesmente como TSA, é um componente desenvolvido pela TOTVS para permitir a comunicação via Web aos dispositivos de hardware instalados na máquina do usuário. A comunicação ocorre via mensagens HTTP, ou seja, o TSA é um serviço Windows que inicia um micro servidor Web para receber as requisições. Este serviço local por sua vez, se comunica diretamente com o hardware através de Api’s de alto nível.

Este documento descreve como deverá ser implementada esta solução no módulo Autorizador WEB

Obs: O TSA para esta versão do Autorizador, esta homologado apenas para o leitor biométrico Nitgen Hamster

Definição da Regra de Negócio 

• Implementação do novo componente de biometria da TOTVS que utiliza a tecnologia javascript/json/rest para comunicação, eliminando a necessidade de utilização de Java Applet.
• Ajuste da tela de Checkin atual para utilização deste novo componente.
• Não deverá haver grande impacto visual para o usuário, pois manterá a interface do Checkin ficando mais simples e ágil.
• Deve ser fácil de instalar e atualizar.
• O Autorizador fará a validação do plug-in HTML antes de ativar o plugin do Java.
• A instalação do componente será feita pela Operadora presencialmente/remotamente ou via comunicado aos prestadores.
• A validação de uso do novo componente se dará da seguinte forma:
  • Se existir -> utiliza o Plug-in HTML TSA.
  • Se não existir -> o Autorizador utiliza JAVA e pode reclamar da ausência ou desatualização do JAVA. Lembrando que apenas o navegador Internet Explorer possui suporte a Applets.

O Autorizador gravará na tabela CHECKIN a versão do TSA disponibilizada pela TOTVS. A Operadora poderá fazer o acompanhamento deste log e os plug-ins utilizados. Caso seja utilizado o Applet para captura, não será gravada nenhuma informação no registro do Checkin e, caso for realizada a captura com o TSA, será gravada a versão atual disponibilizada pela TOTVS.

Casos de Teste

Obs: O plugin java atualmente só funciona com o Internet Explorer. Outros navegadores atualizados não estão mais dando suporte ao plugin Java. Portanto o TSA será a unica alternativa.

Especificação Técnica

Na entidade CheckinData deverá ser criado um atributo denominado biometryVersion (String), onde irá armazenar a versão do TSA disponibilizada pela TOTVS. Caso este atributo seja nulo, indica que o Applet Java foi utilizado.

Alteração na página de propriedades do Sistema

Image Added

Deverá ser disponibilizado um link no TDN para instalação do novo componente, assim como um manual de instruções para o usuário.

Outros arquivos a serem alterados:

/WAC2Web/WebContent/js/functions.js

/WAC2Web/WebContent/pages/biometry/authenticateFingers.xhtml

/WAC2Web/WebContent/pages/biometry/capture.xhtml

/WAC2Web/WebContent/pages/biometry/totvsTecBiometry.xhtml

/WAC2Web/WebContent/pages/biometry/verify.xhtml

/WAC2Web/WebContent/pages/checkin/checkin.xhtml

/WAC2Web/WebContent/js/ajax.js

D:\Desenv\workspace_wac_11\WAC2Web\WebContent\js\nitgen.js

/WAC2Web/WebContent/js/json2.js

/WAC2Web/WebContent/js/websockets.js

/WAC2Web/WebContent/WEB-INF/totvssmart (Diretorio contendo o instalador e manual de utilização)

Abaixo os diretórios de fontes que sofrerão impacto de alteração:

•    /WAC2Web/WebContent/pages/biometry/
•    /WAC2Web/WebContent/pages/checkin/checkin.xhtml
•    /WAC2Web/src/com/totvs/saude/wac/action/fingerprint/
•    /WAC2Web/src/com/totvs/saude/wac/action/checkin/
•    /WAC2Web/src/com/totvs/saude/wac/bean/checkin/
•    /WAC2Web/src/com/totvs/saude/wac/bean/fingerprint/

Tecnologias envolvidas nesta demanda:
•    Javascript
•    Json
•    Java

Implementação do novo Componente de Biometria TSA

O novo componente de biometria TOTVS não utiliza a tecnologia Java Applet. Ele utiliza a tecnologia JSON com requisições via REST para um servidor web instalado na maquina cliente. Este servidor web fica responsável pela comunicação com o driver do dispositivo e de devolver a camada web requisitante as respostas de autenticação da biometria.

Para esta implementação foi disponibilizado um projeto de exemplo contendo as funções de comunicação com o novo componente, bem como uma página de teste onde é possível fazer o teste da biometria.



Registrar em uma tabela cada utilização de biometria, identificando qual componente foi utilizado e qual prestador/clinica utilizou.

Por fim, será implementado a gravação do log de utilização da biometria, onde deverá ser identificado qual componente foi utilizado e qual prestador/clínica utilizou. Esta tabela será monitorada pelo cliente para saber como estará a utilização do novo plugin e, posteriormente, decretar o fim da utilização do componente atual em Java. Utilizar a tabela existente CHECKIN.

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
  • Data da ultima realização do procedimento (caso caia na regra do chamado TRFES0)
  • Quantidade Solicitada (possibilitar inserir a quantidade)
    • Não possibilitar alterar caso o procedimento for uma variação
  • 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

Obs.: Lembrando que campos como por exemplo “Data de solicitação Futura” Ficará desabilitada da tela por default, porém pode ser habilitada através da tela de Manutenção de Campos

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 Removed

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 Removed

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.

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

Especificação Técnica

Artefatos envolvidos

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;

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)

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
  • Data da ultima realização do procedimento (Parametrizavel)
  • 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 Removed