Histórico da Página
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
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:
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.
Ao selecionar o tipo de atendimento, o sistema redirecionará o médico para a tela de Solicitação. Segue abaixo protótipo de tela:
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
| 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. |
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_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
- 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
(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
Este documento é material de especificação dos requisitos de inovação, trata-se de conteúdo extremamente técnico. |
|---|


