CONTEÚDO

  1. Visão Geral
  2. Rotina Atual
  3. Nova tela de cadastro de Corpo Clínico e premissas
  4. Alterações e Protótipos
  5. Tabelas utilizadas


01. VISÃO GERAL 

      A presente especificação visa detalhar as regras iniciais da nova funcionalidade no módulo SIGAPLS, referente a DPS - Declaração do Plano de Saúde, obrigação acessória, inerente as Operadoras de Saúde, situadas na cidade de São Paulo, que são referidas na Lei 13.701, de 24/12/03, nos subitens 4.22 e 4.23 da lista do “caput” do artigo 1º, que são:

     Assim, a especificação terá como base essas legislações Municipais, bem como as regras e demais informações contidas no manual do DPS - disponível no endereço http://notadomilhao.prefeitura.sp.gov.br/cidadao/informacoes-gerais/manuais-arquivos/manual_dps.pdf/view (acessado em 08/02/2021,às 11:000 - e no manual de Repasse, que contêm e descreve de forma técnica o layout do arquivo txt a ser enviado para o sistema de NF-e, disponível em http://notadomilhao.prefeitura.sp.gov.br/cidadao/informacoes-gerais/manuais-arquivos/manual_dps_repasses.pdf/view (acessado em 08/02/2021, às 11:15). 

     Por se tratar de tema técnica e fiscal, a presente especificação poderá e deve passar por atualizações em seu conteúdo, visto que deverá passar por crivos técnicos (de desenvolvimento e legal), bem como por análise pelo(s) cliente(s)/usuário(s), que poderá(ão) trazer outros visos à presente especificação.



02. Rotina atual 

Para acessar o cadastro de Corpo Clínico do Prestador, é necessário acessar o seguinte caminho: Atualizações / Rede de Atendimento / Rede de Atendimento - RDA. O sistema irá abrir todos os cadastro de prestadores no sistema (tabela BAU). Selecionar o prestador desejado no browse a na sequência, clicar no botão Outras Ações / Complemento

O sistema irá abrir o cadastro completo da RDA, com várias abas e informações. No nosso caso, será necessário acessar a aba Especialidades. O sistema irá exibir as especialidades cadastradas para o prestador e na parte inferior, temos diversas abas, sendo que a aba que será desmembrada desse cadastro será a de Corpo Clínico. Ao clicar nessa aba, temos mais abas pertinentes a esse cadastro, que é de RDA e Procedimentos.

 
Figura 1

Note que ao mudar a especialidade no grid acima, os itens exibidos no Corpo Clínico mudam, pois o Corpo Clínico e suas sub-abas são associadas a especialidade.

Contudo, note a quantidade de abas e informações que não são necessárias para atualizar o cadastro de Corpo Clínico, que são exibidas na tela. Além disso, essa tela utiliza a classe TPLSBrw (fonte PLSBRW.PRW)para todos os grids, que é uma classe criada pelo time do PLS, não possuindo suporte oficial pelo setor de tecnologia da empresa, além de carregar todos os dados em memória, ocasionando extrema lentidão na abertura e navegação na telas, caso esses grids contenham vários registros. 

Por isso, para utilizar as tecnologias oficiais da empresa e melhorar a usabilidade e velocidade, essa tela de Corpo Clínico será desmembrada e refeita em MVC, conforme detalhes nos próximos itens dessa especificação.


03. Nova tela de cadastro de Corpo Clínico e premissas 

Conforme visto nos outros tópicos, o acesso ao cadastro de Corpo Clínico passa por vários menus e submenus, além de apresentar lentidão na tela, devido ao uso da classe própria. Desta forma, no desmembramento da aba de Corpo Clínico, será necessário observar as seguintes premissas abaixo, para o desenvolvimento da nova rotina:

É de suma importância que a tela seja feita em MVC, garantindo o suporte oficial pelo time de tecnologia, além de garantir que todas as validações existentes sejam revistas e feitas na nova tela, para garantir a gravação correta e funcionamento das demais rotinas envolvidas, que utilizam desses cadastros, visando garantir uma melhor usabilidade e maior performance no uso da rotina.

No tópico de alterações, será descrito o que deve ser feito, bem como demais observações importantes no processo.

Mesmo se tratando de especificação, no decorrer do desenvolvimento, poderá ser encontrado outros pontos não mencionados aqui, visto que se trata de um rotina antiga, que pode possuir diversas implicações em várias partes do sistema. 


04. Alterações e Protótipos 

Abaixo, iremos definir os passos básicos, que devem ser seguidos para realizar as alterações e a criação da nova tela:

  1. O acesso a nova rotina será pelo caminho existente hoje, ou seja: Atualizações / Rede de Atendimento / Rede de Atendimento - RDA.
  2. Ao abrir o browser com o cadastro dos prestadores, incluir uma nova opção no botão Outras Ações da tela, que será chamado Especialidades x Cadastros relacionados. Esse item deve chamar a nova tela.

    Figura 2

  3. A nova tela deverá exibir, de forma obrigatória, um form com o cabeçalho básico da RDA, exibindo o código, CPF/CNPJ e nome da RDA, um grid com os locais de atendimento da RDA selecionada, e de acordo com o local selecionado, deve atualizar o grid especialidades atreladas ao local. E ao clicar na especialidade, deve exibir as informações pertinentes, que são a de corpo clínico e suas sub-abas (RDA's e Procedimentos).
    1. Ou seja, a tela será dinâmica, pois de acordo com o local selecionado, deve filtrar as especialidades vinculadas, e ao selecionar a especialidade, deve filtrar as informações da aba de Corpo Clinico. E de acordo com o item posicionado na aba de Corpo Clínico, deve filtrar os procedimentos relacionados ao profissional.
    2. Na prática, o funcionamento é igual ao que ocorre hoje, sendo a diferença que está em um menu a parte e a tela se beneficiará da tecnologia MVC, tornando a performance mais rápida.




  4. Abaixo, um exemplo de como a tela deve ficar no final do desenvolvimento, além de colocar o alias de cada tabela envolvida, de acordo com a tabela acima:

    Figura 3 

  5. No exemplo acima, o form com os dados básicos da RDA e os grid de locais de atendimento e especialidades já estão em MVC. A parte inferior é apenas uma projeção do visual atual, que deverá ser convertido para o MVC.
  6. Importante colocar em cada grid MVC o título do grid e os componentes GRIDFILTER e GRIDSEEK, para facilitar a busca dos dados nos grids para o usuário. Abaixo, os componentes citados:

    Note que no exemplo da figura 3, nos grids de local e especialidade, temos o uso desses componentes. Deverá ser replicado para os grids das tabelas BC1 e BE6, conforme exemplo abaixo:


  7. Após o desenvolvimento da tela e confirmação que os dados estão sendo gravados corretamente, realizar a limpeza no fonte PLSA360 e PLSA365, realizando a limpeza desses fontes, retirando qualquer menção dos grids antigos e funções que não são mais necessárias, devido a criação do novo fonte.
  8. Após as etapas acima, a automação da nova rotina, bem como realizar testes diversos na rotina de Cadastro de Prestadores, devido a limpeza efetuada.


05. TABELAS UTILIZADAS 


<!-- esconder o menu --> 


<style>
div.theme-default .ia-splitter #main {
    margin-left: 0px;
}
.ia-fixed-sidebar, .ia-splitter-left {
    display: none;
}
#main {
    padding-left: 10px;
    padding-right: 10px;
    overflow-x: hidden;
}

.aui-header-primary .aui-nav,  .aui-page-panel {
    margin-left: 0px !important;
}
.aui-header-primary .aui-nav {
    margin-left: 0px !important;
}
</style>