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 | TSHMOA | ||
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:
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. |
|---|