• Problema
  Quando estamos em uma tela com muitos componentes o ícone do loading fica no fim da tela, dando a entender que o mesmo não está acontecendo ou que ocorreu um bug na tela

• Possível solução
  Colocar o loading com position absolut no centro da tela.

Problema

Atualmente, o dialog de informações cadastrais do paciente encontra-se com muitas informações que poderiam ser separadas por categoria.

Solução

Implementar Tabs de separação por tipo de informação, ex:

• Dados do paciente
• Endereço e Contato
• Plano de saúde
• Observações

Obs: Esse exemplo é ilustrativo.

Descrição

• Atualmente a aplicação só gera relatórios pré-configurados e fixados internamente no projeto. Para que seja possível que o usuário final crie e customize relatórios, faz-se necessário implementar uma funcionalidade de processamento de relatórios.

Solução

• Como solução, adotaremos o JasperReport, primeiro por ser uma ferramenta opensource, segundo por já ser bem consistente no mercado.

Fluxo da solução de processamento

• O front seleciona qual relatório quer gerar.
• O back busca os parâmetros necessários para a geração e devolve para o front
• O front passa os parâmetros necessários
• O back busca o busca o base64 do relatório que está no banco
• O back cria um InputStream do base64
• O back pega os parâmetros enviados pelo front
• O back adiciona o inputstram e os parâmetros no serviço de geração de relatório
• O back pega o relatório gerado, converte em base64 e devolve na resposta
• O front pega o base64 do relatório e adiciona no visualizador de documentos

Contexto adicional (Observações)

• Este recurso só poderá ser feito depois do processador de parâmetros do relatório da atividade #201

Sua solicitação de recurso está relacionada a um problema? Por favor descreva.
Para realizar um agendamento é necessário ter o paciente pré cadastrado. Desta forma o operador perde um certo tempo trocadndo de págias.

Descreva a solução que você deseja
Desenvover uma forma de cadastrar um paciente no momento do agendamento em caso de inexistência do mesmo nas nossas bases.

Problema

Atualmente, o dialog de informações cadastrais do usuário encontra-se com muitas informações que poderiam ser separadas por categoria.

Solução

Implementar Tabs de separação por tipo de informação, ex:

• Dados do usuário
• Endereço e Contato
• Permissões
• Observações

Obs: Esse exemplo é ilustrativo.

Descrição

• Com a tela de agendamento pronta já podemos criar um dashboard baseado no usuário logado. Munindo o mesmo com informações analíticas e de rápido acesso.

Solução

Cards

• Na parte superior da tela, deve conter 4 cards
  -- Pacientes atendidos
  -- Pacientes à atender
  -- Pacientes atrasados
  -- Pacientes cancelados

Tabelas

• Abaixo dos cards, deverá ter dois cards um ao lado do outro
  -- Esquerdo: Pacientes atendidos
  -- Direito: Pacientes aguardando

Gráficos

• Abaixo dos cards, gráficos deveram dividir a tela
  -- Gráfico de atendimentos na semana
  -- Total de desistência na semana

Implementação

• Todos estes recursos serão carregados no load da tela.
• Deve-se criar um botão para atualizar dados na parte superior direita

Descrição

• Para que seja possível criar uma solução de processamento de relatórios dinâmicos, devemos possibilitar o cadastro dos xmls via front, o intuito desta atividade é possibilitar a manutenção cadastral dos relatórios do sistema de forma independente e dinâmica.

Solução

• A solução consiste em 4 partes, são elas:

Fluxo de cadastro de relatório

• O front seleciona Novo Cadastro
• Uma tela abre pedindo as seguintes informações: Nome do relatório, breve descrição do que ele faz e upload do XML do relatório.
• O Front passa todas as informações necessárias e manda um POST
• O back lê o XML e procura por parâmetros
• O back cria metadados dos parâmetros encontrado (Talvez seja interessante ver como o formulário de anamnese é montado)
• O back cria armazena o cabeçalho do relatório (Nome, descrição e xml) em uma tabela. (Obs: O Xml deve ser salvo em base64)
• O back salva os metadados dos parâmetros em outra tabela referenciando o ID do cabeçalho

Fluxo de consulta (Lista)

• O front abre a tela de listagem de relatórios paginada
• O back realiza a busca de relatórios paginados (Obs: não há a necessidade de trafegar o base64 nesta requisição)
• O front exibe a listagem mostrando Id, nome do relatório e nome do criador do relatório.

Fluxo de consulta (Detalhada - Edição)

• O front seleciona um cadastro de relatório já existente (Isso é um getById)
• O back busca o cabeçalho e os itens do cabeçalho e devolve para o front
• O front exibe além os dados do cabeçalho, os parâmetros do relatório, junto com o tipo.

Fluxo de alteração de cadastro de relatório

• O front seleciona um cadastro de relatório já existente (Isso é um getById)
• O back busca o cabeçalho e os itens do cabeçalho e devolve para o front
• O front exibe além os dados do cabeçalho, os parâmetros do relatório, junto com o tipo.
• O Front passa um novo XML via upload e manda um POST
• O back lê o XML e procura por parâmetros
• O back limpa todos os parâmetros cadastrados anteriormente
• O back atualiza o cabeçalho do relatório (Nome, descrição e xml) na tabela de cabeçalhos. (Obs: O Xml deve ser salvo em base64)
• O back salva os metadados dos parâmetros em outra tabela referenciando o ID do cabeçalho

Fluxo de exclusão de relatório

• O front seleciona um cadastro existente de relatório
• O front seleciona a exclusão do mesmo e manda um DELETE passando o ID
• O back deleta da base tanto o cabeçalho quanto os parâmetros
• O front fecha o formulário e volta para a listagem de relatórios

Contexto adicional (Observações)

• É interessante colocar no cabeçalho do relatório quem foi que criou e a data de criação

O Problema

Atualmente adicionamos a logomarca da instituição manualmente via banco de dados. É necessário possibilitar o envio da imagem via requisição no frontend, de preferência na tela de informações da instituição.

Solução

Criar um upload de imagens direto na tela de informações institucionais

O Problema

O layout atual da aplicação possui uma falha de estruturação que deve ser melhorada.

Detalhes

Atualmente, quando adicionamos muitas evoluções ao prontuário ativo do paciente, um "buraco" aparece no layout entre os cards, fazendo com que o layout fique bem uniforme como mostra a imagem abaixo:

Solução

Produzir uma proposta nova para o posicionamento dos cards, lembrando que as alergias precisam estar sempre visíveis, pois é a informação mais sensível em caso de pacientes alérgicos.

Problema

Atualmente o botão de Evento não possui ação nenhuma, o mesmo deve exibir um dialog com as informações necessárias para adicionar um evento.

Criação de uma nova aba na manutenção dos planos de saúde
Para que seja possível realizar a contabilidade dos procedimentos realizados por planos de saúde, faz-se necessário criar uma nova aba na tela de manutenção dos planos.

Solução
Criar uma nova aba na tela de manutenção dos planos de saúde. Esta aba deverá conter uma tabela com todos os procedimentos que a clínica realiza por determinado plano de saúde.

A tela deverá permitir operações como adicionar, remover e editar preços.

Contexto adicional
Esta operação deve ser feita em conjunto com o backend. Repeitando regras lógicas como, cada plano só pode conter um preço por procedimento.

Dependência

#35 Consulta e listagem de convênios

Problema

Temos a tela de listagem e consulta de convênios mas não conseguimos nem cadastrar nem editar os que já existe, faz-se necessário uma tela de manipulação cadastral de convênios.
Ideal utilizar o sistema de abas para separar informações da operadora do convênio e outra aba para os planos fornecidos pela operadora.

Solução

Criar um formulário de criação e edição de cadastro de convênios

Problema

Atualmente, o dialog de informações cadastrais do profissional encontra-se com muitas informações que poderiam ser separadas por categoria.

Solução

Implementar Tabs de separação por tipo de informação, ex:

• Dados do Profissional
• Endereço e Contato
• Especialidades
• Observações

Obs: Esse exemplo é ilustrativo.

Existem espaçamentos desnecessários em algumas tabelas do prontuário, seria interessante retirar estes espaçamentos e dá prioridade as colunas com informações maiores.

Adição de opção de procedimento no menu do prontuário ativo
Atualmente a única forma de adicionar procedimento é pela opção de adicionar evento. O problema é que a tela é muito genérica e leva o operador ao erro.
Seria interessante ter uma opção específica para procedimentos, onde o operador informe o código do procedimento e o sistema retorne com o valor e algumas informações a mais como idade mínima e período.

Solução
Criar uma opção no menu do prontuário para adicionar procedimento clínico.

Detalhes da tela

• Um campo com o código do procedimento. O código a ser informado deve estar previamente cadastrado no módulo de procedimentos.
• Um campo com a descrição do procedimento. Este campo deve ficar desabilitado, impedindo a alteração do mesmo.
• Um campo com o preço padrão do procedimento.
• Uma lista de alertas para problemas de checagens como periodicidade e idade mínima e máxima do paciente.

Comportamento:

• A aplicação deve mostrar um feedback ao operador caso alguma validação de checagem seja acionada.

Contexto adicional
Remover a opção de adição de procedimento do menu "Criar Evento".

Como não há nenhuma funcionalidade nos cards do dashboard, não há sentido em manter os mesmos visíveis.

Problema

Atualmente o botão de evento não possui nenhuma ação.

Solução

Para que seja possível adicionar procedimentos e eventos customizados, faz-se necessário a implementação de um novo componente no qual novos eventos serão inseridos.

Obeservações

1 - Os novos eventos deverão ter uma forma de adicionar múltiplos documentos via upload de arquivos.
2 - Os documentos só podem ser PDFs
3 - A acomodação deve ser pré-carregada com a última acomodação utilizada no atendimento. Este processo agilizará a atividade do operador.

Documentação do endpoint

A documentação do endpoint encontra-se em: https://gestao-prontuario.herokuapp.com/swagger-ui.html#/attendance-event-controller

Descrição

• Hoje, todos os cadastros de especialidades do sistema estão fixos numa tabela da aplicação, entretanto, para realização inserção e atualização é necessário uma intervenção manual direto no banco, o que não parece muito interessante. Pensando neste problema, surgiu a idéia de permitir que o usuário cadastre a especialidade direto no sistema.

Solução

• Criar um CRUD básico para cadastro de especialidade. Toda a estrutura está pronta, falta apenas criar os controladores para a exposição da funcionalidade.
• Criar o POST, PUT e DELETE
• Não permitir deletar se houver profissional marcado para uso

Contexto adicional (Observações)

• Talvez seja interessante trazer os profissionais que possuem certa especialidade na consulta detalhada da especialidade

O problema está ocorrendo sempre que tento criar uma nova acomodação sem fechar o dialog, apenas limpando o formulário.

Comportamento esperado

Limpar o formulário e possibilitar um novo cadastro no mesmo setor.

Comportamento atual

Ao clicar em "Nova acomodação", o formulário limpa o identificador do setor, gerando um erro de chave estrangeira nula

Solução possível

Limpar todo o formulário exceto o código do setor

Passos para reproduzir

1. Entrar no cadastro de setores
2. Clicar em um setor já cadastrado
3. Clicar na aba de leitos e salas
4. Clicar em editar qualquer leito
5. Clicar em Nova acomodação
6. Verificar o erro

Contexto (ambiente)

O problema ocorreu em ambiente de Homologação

Descrição

• Hoje, todos os cadastros de anamnese do sistema estão fixos numa tabela da aplicação, entretanto, para realização inserção e atualização é necessário uma intervenção manual direto no banco, o que não parece muito interessante. Pensando neste problema, surgiu a idéia de permitir que o usuário cadastre a anamnese direto no sistema.

Solução

• Para a criação do CRUD da anamnese, alguns processos devem existir, são eles:

Criação do formulário

• Front clica em novo formulário
• Front informa Nome e descrição breve sobre o que é o formulário
• Front manda salvar
• Back adiciona à base e devolve a requisição com ID criado (Cabeçalho)
• Front exibe aba de criação de questões
• Front seleciona a criação de questõe
• Front clica em Criar Questão
• Dialog abre pedindo O texto da pergunta e o tipo da resposta.
• Front salva (POST)
• Back salva (Itens do cabeçalho)
• Front fecha o Dialog
• Front exibe na aba de Questões um item na tabela de questões cadastras

Consulta de formulário

• Front seleciona formulário criado (getById)
• Back busca tanto o cabeçalho quanto os itens
• Front exibe cabeçalho na aba de informações gerais
• Front exibe itens do cabeçalho na aba de questões

Edição de formulário

• Front seleciona formulário criado (getById)
• Front realiza a consulta do passo anterior
• Front recebe novos valores no cabeçalho
• Front manda PUT
• Back atualiza cabeçalho com novas informações

Exclusão de formulário

• Front seleciona formulário criado (getById)
• Front clica em excluir formulário
• Front manda DELETE com ID
• Back deleta itens do cabeçalho
• Back deleta cabeçalho

Contexto adicional (Observações)

• A estrutura de banco já está pronta e vai até a camada de serviço
• A Tela de formulários de anamnese será muito semelhante à tela de Cadastro de Setores
• A edição das questões devem segui o mesmo padrão da edição de Salas e Leitos do cadastro de Setores

Sua solicitação de recurso está relacionada a um problema? Por favor descreva.
Ao logar com um usuário de profissional e abrir a agenta, por padrão é exebida a agenda de todos os pacientes da clínica. É mais interessante filtrar direto pelo profissional logado.

Descreva a solução que você deseja
Desenvolver uma forma de ao abrir a agenda, o profissional atrelado ao usuário já seja selecionado no filtro da agenda.

Descreva as alternativas que você considerou
Criar um método no load da agenda checando o usuário logado e setando no estado

Problema

O problema foi identificado quando a tabela de eventos ficou muito grande, gostaria ordenar em forma decrescente.

Tela

Solução

Criar a possibilidade de ordenar os campos de todas as tabelas, principalmente a de eventos.

Problema

Ao realizar uma alteração no cadastro de um profissional, apertei para salvar e nada aconteceu, apertei novamente e apareceu que salvou duas vezes seguidas.

O que deveria acontecer?

• Um loading deveria aparecer no momento em que apertei em salvar, para que o usuário receba um feedback de ação e não fique apertando insistentemente em salvar.

Descrição

• Com a tela de agendamento versão 1 pronta, seria interessante poder visualizar todos os agendamentos de um paciente à partir do cadastro do mesmo.

Solução

• Criar uma nova aba no dialog de edição de paciente, na qual serão listados todos os agendamentos do paciente.
• A tela deverá ser semelhante à tela do histórico do paciente e também deverá ter uma forma de redirecionar para a tela de agendamento com o paciente já selecionado em caso de novo agendamento e em caso de seleção de agendamento já existente, a tela deve ser redirecionada para a tela de edição de agendamento com o agendamento carregado.

A ordenação não está funcionando na tabela de eventos

Problema

Atualmente a tela de prontuário possui apenas o esqueleto para a criação de Evoluções, entretanto, não há integração com a API.

Solução

Cria a camada de serviço de integração com a API e ligar no Controller da Evolução.

Observação

Adicionar um componente de loading para que a tela seja bloqueada no momento do envio da evolução para o servidor de aplicação.

Documentação -> https://gestao-prontuario.herokuapp.com/swagger-ui.html#/evolution-controller/evolution-post

Outras observações: Apenas o código do atendimento e a descrição da evolução são obrigatórios, as outras propriedades são para fins de consulta.

Problema

Atualmente não existe uma tela de listagem de convênios cadastrados na aplicação

Solução

A solução consiste em criar uma tela que realize apenas a consulta (com filtros) e listagem de convênios cadastrados no sistema, nada mais do que isso.

Filtros

• Identificador interno
• Código do convênio
• Nome do convênio

Problema

Com a nova propriedade obrigatória na criação da anamnese, o fluxo foi quebrado, faz-se necessário alimentar a nova propriedade na criação da anamnese.

Solução

• Adicionar um select "autocompletável" dentro do componente de questionário de anamnese.

Problema

A tela do prontuário só espera um documento por evento de atendimento, com a nova estrutura, faz-se necessário a evolução do processo.

Soluções

• Até o momento existem duas possíveis soluções:

Solução 1

• Abrir um dialog solicitando a escolha do usuário

Solução 2

• Utilizar o componente de visualização de documento existente. Criar um processo em que seja possível selecionar os documentos simultaneamente.

• Motivação
  Atualmente a aplicação só possui um ponto de entrada de imagens de cadastro (Paciente, Responsáveis, Usuários, Perfil), que é a integração com a câmera.
  Para que seja possível o envio de imagens à partir do computador ou celular utilizando o upload de imagens, faz-se necessário a implementação de um botão de upload. Também será interessante se houver um botão para remoção de imagem.

• Solução proposta
  Imaginei numa solução semelhante a esta: