Este documento é material de especificação dos requisitos de inovação, trata-se de conteúdo extremamente técnico. |
|---|
Especificação | |||
Produto | Datasul | Módulo | Gestão de Planos de Saúde |
Segmento Executor | Saúde | ||
Chamado | TTKGL1 | ||
País | (X) Brasil ( ) Argentina ( ) Mexico ( ) Chile ( ) Paraguai ( ) Equador ( ) USA ( ) Colombia ( ) Outro _____________. | ||
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:
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:
<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
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
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.
Ao inserir um serviço na guia, possuirá os componentes abaixo:
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.
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.
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:
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 :
Serviços:
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.

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

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
| 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 | |
| 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 | |
| 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 | |
| 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 | |
| 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 | |
| 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 | |
| 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. |
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_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)
<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
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:
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.
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.

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