Dificuldade ou Problema

Atualmente não possuímos flags de grau de risco dos atendimentos. Quando vamos à um hospital, pulseiras com cores definem o risco do paciente, devemos reproduzir o mesmo comportamento na aplicação.

Solução

Implementar funcionalidade no cadastro de atendimentos, permitindo que o operador informe qual é o grau de risco do paciente.

Problema

• Atualmente qualquer profissional pode realizar qualquer procedimento, por questão de processo e segurança, faz-se necessário que exista um cruzamento de informações entre especialidades e procedimentos que certa especialidade pode realizar.

Dificuldade ou Problema

Frequentemente os pacientes necessitam de algum informativo com data e hora das consultas agendadas, principalmente quando as consultas são em quantidade, como no caso de psicoterapia.

Solução

Desenvolver um relatório de agendamentos no cadastro do paciente para que seja possível baixar e/ou imprimir posteriormente informando todos os agendamentos futuros.

Alternativas

A solução é a única alternativa.

Problema na geração de formulário dinâmico

Problema

Ao preencher um formulário dinâmico na tela de prontuário eletrônico, o mesmo está saíndo totalmente em branco.

Comportamento esperado

É esperado que o sistema gere um documento com cabeçalho e perguntas e respostas do formulário.

Solução possível

Necessário análise do problema.

Passos para reproduzir (Se possível)

1. Inciar um atendimento ou acessar um atendimento existente e ativo.
2. Selecionar o menu hamburguer lateral direito no topo do primeiro card da tela do prontuário.
3. Escolher a opção Formulário
4. Selecionar qualquer formulário existente
5. Responder algumas perguntas
6. Clicar em salvar
7. Na tabela de eventos, encontrar o evento do formulário e clicar em visualizar documento

Contexto (ambiente)

Requer a existência prévia de um cadastro de um formulário dinâmico.

Descrição detalhada

Por algum motivo o serviço de integração entre aplicação e Jasper não está funcionando como o esperado, necessário análise para entender o problema.

Dificuldade ou Problema

Atualmente o objeto de requisição de Upload recebe apenas um multipart/form-data, não é possível adicionar informações detalhadas à imagem.

Solução

Criar uma estrutura composta para qualquer tipo de arquivo, inclusive imagens.

Necessidade

Realizar a criação de um Repositório (Spring Data) para a entidade que mapeia a tabela OPERADORA

Observação

Para realizar esta atividade, faz-se necessário a execução antecipada da atividade #54

Dificuldade ou Problema

Hoje não temos uma relação de paciente com plano, isso dificulta a oferta de serviços entre o estabelecimento e o paciente.

Solução

Criar uma nova coluna na tabela de paciente referenciando o plano de saúde.

• Nova coluna: ID_PLANO
• Tipo................: BIGINT(20)

Dificuldade ou Problema

Não possuímos um repositório de documentos externos por paciente, este repositório ser ordenado por data de criação/upload.

Solução

Criar uma estrutura para documentos.

Dificuldade ou Problema

Atualmente não existe uma forma de visualizar os agendamentos do paciente sem que seja necessário abrir o calendário e checar dia a dia.

Solução

Implementar uma nova aba na tela de cadastro de paciente com a descrição Agendamentos contendo o histórico de todos os agendamentos passados e futuros do paciente.

Alternativas

No serviço de consulta de pacientes, adicionar uma lista de informações de agendamentos do paciente e listar numa tabela dentro da aba de Agendamentos.

Contexto adicional (Observações)

• Esta aba só deve aparecer se o paciente estiver registrado
• Esta aba só deve aparecer se o paciente possuir ao menos um agendamento realizado.

Dificuldade ou Problema

Atualmente não há uma forma do client (GP-UI) realizar a listagem das operadoras de saúde, isto impossibilita a implementação da funcionalidade do lado do client.

Solução

Criar um método de listagem paginada de operadoras, com filtros por Nome Fantasia, Código ANS e CNPJ. Os elementos da lista paginada deve conter todas as informações da operadora, exceto a lista de Planos que a operador fornece.

Dependências

Para que seja possível realizar a implementação desta funcionalidade, é necessário que as issues à baixo estejam implementadas:

• #53 Estrutura de banco
• #54 Mapeamento de modelo relacional
• #55 Criação de repositório

Contexto adicional (Observações)

Seguir o padrão de funcionalidades já existentes como listagem de pacientes, listagem de usuários e listagem de profissionais.

Necessidade

Criar as entidades de modelo relacional JPA com as novas tabelas da issue #53

Observação

Deve haver relacionamento entre as entidades

Dificuldade ou Problema

Atualmente não há uma forma do client (GP-UI) realizar uma busca de todas as informações de uma operadora de saúde, isto impossibilita a implementação da funcionalidade de exibição detalhada das informações da operadora.

Solução

Criar um método de busca por identificador único na base de operadoras. O elemento encontrado deve conter todas as informações da operadora, até a lista de Planos que a operador fornece.

Alternativas

Para que seja possível realizar a implementação desta funcionalidade, é necessário que as issues à baixo estejam implementadas:
#53 Estrutura de banco
#54 Mapeamento de modelo relacional
#55 Criação de repositório

Contexto adicional (Observações)

Seguir o padrão de funcionalidades já existentes como busca de informações detalhadas do paciente.

Problema

• Atualmente, alumas entidades não possuem descrições de propriedades intuitivas. Faz-se necessário uma melhor documentação em todas as entidades faltantes.

Solução

• Adicionar anotações de documentação da OpenAPI utilizada no projeto (Swagger)

Entidades faltantes

• ProfessionalIdentityDTO
• RoleDTO
• SectorDTO
• SectorInfoDTO
• ServerStatusDTO
• SpecialityDTO
• SpecialityInfoDTO

Dificuldade ou Problema

Atualmente existem diversas opções de eventos que confundem o operador e na grande maioria não são utilizados.

Solução

Criar uma padronização de eventos para evitar uso indevido.

Alternativas

• Remover eventos com menus existentes:
• • Entrada
• • Saída
• • Evolução
• Remover eventos que são procedimentos:
• • Primeira consulta
• • Consulta médica
• • Consulta médica remota
• • Urgência médica
• • Pós operatório
• • Retorno
• • Sessão

Contexto adicional (Observações)

Estas remoções servirão para evitar utilização equivocada dos tipos de eventos.

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

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

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

• É papel da API devolver para o front as seguintes informações:

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

Solicitação

Após a criação da nova coluna na tabela de paciente (#59), deve-se mapear a mesma na entidade relacional utilizando Referência de objeto (@OnetoOne em Patient), invés de utilizar o ID puro.

Dificuldade ou Problema

Hoje o módulo de agendamento é muito aberto, não existem controles como marcações conflitantes, marcações em dias sem expediente, marcações com profissionas sem agenda, entre vários outros problemas.

Solução

Implementar um serviço de configuração de agenda da Clínica e do Profissional.

Alternativas

• Configurações da clínica:
• • Dias de funcionamento
• • Horários de funcioonamento
• • Regras de exclusão de datas (Feriados, eventos e imprevistos)
• • Regras de encaixe
• Configurações do profissional
• • Dias de atendimento
• • Horários de atendimento
• • Regras de exclusão de datas

Problema

• Atualmente o GP não possui nenhum endpoint para acessar as consultas do GTISS.

Solução

• Criar Service e Controller para disponibilizar o endpoint para acesso as consultas do GTISS.

Observações

• N/A

Dificuldade ou Problema

A agenda atual possue dois status não muito bem definidos. São eles: Remarcado e Ausente.

Solução

Ajustar status para manter a coesão.

Alternativas

• Trocar Remarcado para Presente (Exibir o mesmo na lista de atendimentos).
• Trocar Ausente para Atrasado (checar o horário do agendamento e o status do paciente = Presente).

Contexto adicional (Observações)

A alternativa de Atrasado requer consulta em tempo real das agendas.

Informações

Atualmente a API encontra-se na versão 2.3.1.RELEASE, devemos realizar uma evolução de versão e realizar testes de conexão com o MariaDB devido à um upgrade no driver de acesso ao mesmo.

Dificuldade ou Problema

Atualmente o cadastro do convênio no cadastro do paciente é um pouco incômoda, tendo em vista que é necessário passar o código do convênio. Raramente o operador conhece o código, sendo necessário ir até o cadastro do mesmo para verificar.

Solução

Implementar um combobox listando todos os convêncios cadastrados no sistema para uso.

Alternativas

1 - Para resolver isso pode-se implementar um serviço apenas para listar os convênios cadastrados, retorando código e descrição apenas para o uso.
2 - Utilizar o serviço de listagem paginada existente para carregar o combobox.

Contexto adicional (Observações)

• É necessário ao menos um convênio cadastrado no sistema.
• Se não houver nenhum convênio cadastrado não deve exibir a aba de convênios.

Solicitação

Após a criação da propriedade de Plano no Paciente (#60),deve-se criar uma propriedade semelhante no DTO de informações detalhadas do paciente, possibilitando a externalização do mesmo. Para possibilitar o preenchimento, deve-se adicionar estas informações na camada de busca do service de paciente.

Necessidade

Realizar a criação de um Repositório (Spring Data) para a entidade que mapeia a tabela PLANO

Observação

Para realizar esta atividade, faz-se necessário a execução antecipada da atividade #54

Dificuldade ou Problema

Com a criação das configurações da agenda, bloqueios para evitar conflitos de agendas passarão a travar outros agendamentos. Para possibilitar encaixes seria interessante haver uma lista de espera, diferente da lista de atendimentos ativos.

Solução

Implementar uma lista de espera para encaixe.

Alternativas

Estudar possibilidade.

Dificuldade ou Problema

Hoje o sistema carece de ferramentas de marketing e fidelização de cliente.

Solução

Pensando na carência de ferramentas para marketing, pensamos em criar algo simples mas útil que as clínicas sempre pedem. Um painel de aniversariantes na tela inicial.

Alternativas

1 - Adicionar um card com uma lista de pacientes aniversariantes do dia e um botão com ação de redirecionamento para o WhatsApp..

Contexto adicional (Observações)

O paciente precisa ter o celular cadastrado previamente.

Dificuldade ou Problema

Atualmente armazenamos em banco, valores enumerados simples. O problema é que quando chega no client, o mesmo precisa realizar a conversão, o que não é interessante, o backend já deveria retornar este valor alterado.

Solução

Evoluir o Enum para Enum composto com valor value, exemplo:
atualmente:

public enum DigitalDocumentType {
    PDF, JPEG, PNG, XML, JSON
}

Novo:

public enum DigitalDocumentType {
    PDF("application/pdf"),
    JPEG("image/jpeg"),
    PNG("image/png"),
    XML("application/xml"),
    JSON("application/json");
    
    private String description;
    
    private DigitalDocumentType(String description) {
        this.description = description;
    }
    /** Métodos de encapsulamento e toEnum para conversão **/
}

Contexto adicional (Observações)

Com esta alteração o documento fica muito mais dinâmico e já recebe direto do client sem tratamentos.

Problema

A aplicação não possui um cadastro de Operadoras e planos, isso impossibilita o registro desta informação no cadastro dos pacientes e nos procedimentos cobertos de cada plano.

Solução

Para este cenário, aplica-se apenas a criação de uma nova tabela de registro de Operadoras e outra para registro de planos x operadoras

Detalhes

• Tabela de Operadoras
  -- Nome: OPERADORA
  ---- Colunas:
  ------ ID
  ------ RAZAO_SOCIAL
  ------ COD_ANS
  ------ CNPJ
  ------ NOME_FANTASIA
  ------ MODALIDADE

• Tabela de Planos
  -- Nome: PLAO
  ---- Colunas:
  ------ ID
  ------ COD_PLAN
  ------ NOME_COMERCIAL
  ------ SEGMENTACAO
  ------ TIPO_CONTRATO
  ------ ABRANGENCIA
  ------ TIPO_PLANO

Detalhes

Há um certo tempo que o README não é atualizado com informações de arquitetura e modelagem de dados, esta atualização deve ser realziada

Itens

• Deploy em Container
• Script de build e run
• MariaDB em Container

Descrição

• Seria interessante ter um sistema de notificações no GP, onde o sistema notifique ao usuário com algumas informações relevantes como avisos do sistema, agendamentos, movimentações, financeiro, entre outras.

Possível solução

• Criar um sistema isolado semelhante à um sistema de logs, sem relacionamentos com tabelas internas.
• A entidade da solução deve armazenar status (READ, UNREAD)
• O status da entidade deve ser alterada para READ se já estiver sido lida.
• A entidade deve armazenar a data/hora da leitura se estiver com status READ
• A entidade deve conter a seguinte estrutura:

1. ID
2. TITULO
3. DESCRICAO (HTML)
4. STATUS
5. DH_LEITURA
6. DATA_CRIACAO

Observações

Estudar uma estratégia que permita adicionar HTML na descrição da notificação...

Problema

• Atualmente o GP não possui nenhum endpoint para upload de logotipo, faz-se necessário a implementação do mesmo para que seja possível substituir sem a necessidade de acessar diretamente o banco de dados.

Solução

• Criar um recurso rest em que seja possível realizar o upload de imagens PNG para recebimento do logotipo da instituição

Como fazer?

• Criar uma nova coluna na tabela de informações institucionais. A nova coluna deve ser do tipo LONGBLOB.
• A entidade a ser mexida é a Institute, mapear tipos LOB com o @lob, como mostra a imagem abaixo:
  

Observações

• Existe processos de envio de imagens no front, entretanto, este envio é feito via base64. No cenário do upload, não se aplica.

Dificuldade ou Problema

Para que o sistema fique completamente dinâmico, precisamos realizar o controle dos formulário apensa do lado co cliente, isso porque cada clínica possui o seu padrão de informações.

Solução

Retirar todos os nullsafes do banco e realizar validações nos formulários se baseando nos parâmetros do formulário.

Contexto adicional (Observações)

Esta discussão deverá levar em conta a questão dos parâmetros dos formulários, separação de atividades e opinião dos demais.

Problema

A listagem de materiais e medicamentos é muito extensa e não faz parte do core domain do Gestão de Prontuário, por este motivo o mesmo não possui um cadastro ou manutenção de materiais.

Solução

Criar uma integração entre o GP e o GTISS via Rest Client para que possa ser possível consultar medicamentos e materiais veia GP.

Observação

Criar um parâmetro para que seja possível apontar o endereço do GTISS no GP.

Problema

• Atualmente, a aplicação não possui controle por tipo de profissional, possibilitando que qualquer pessoa com privilégio de escrita em eventos do atendimento dê alta médica. Este recurso deve ser controlador por função do profissional, exemplo: apenas médicos podem dá alta médica, o sistema deve saber diferenciar um médico de um enfermeiro.

Solução

• Na entidade Responsible deve-se adicionar um novo relacionamento com EventType se baseando em um relacionamento de NxN (ManyToMany) com uma nova tabela -> TPEVENTO_RESPONSAVEL.

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

Problema

Atualmente, para que seja realizado um encerramento de um atendimento, deve-se adicionar um evento manualmente, informando acomodação, profissional, atendimento e algumas outras informações que podem ficar abstraídas em um outro endpoint rest.

Solução

Criar um endpoint específico para "Alta médica", onde seja necessário informar apenas o tipo de alta médica e data/hora. As outras informações devem ser tratadas internamente na API, assim como acomodação, profissional e privilégios.

Descrição

• Hoje, todos os privilégios estão separados por recurso rest, esta estratégia não é interessante quando se trata de fluxos compartilhados. A questão da granularidade dos privilégios dificulta a manutenção de acesso ao sistema.

Solução

• Criar ROLES bem definidas de acordo com processos inteiros

Contexto adicional (Observações)

• Esta atividade requer um certo tempo de estudo para definir o comportamento da funcionalidade.

Dificuldade ou Problema

Hoje, todos os atendimentos da aplicação são comuns, não há diferenciação entre atendimento normal e preferencial.

Solução

Criar uma flag para informar atendimentos preferenciais.

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

Dificuldade ou Problema

• Foi percebido que apesar das consultas paginadas devolverem DTOs reduzidos das entidades principais, a aplicação realiza o select na entidade completa.

Solução

• Substituir as consultas por entidades completas por projeções de entidades baseadas no DTO.