Pular para conteúdo

2. Solução Proposta

2.1 Objetivo Geral do Produto

Digitalizar a gestão assistencial do Lar dos Velhinhos Bezerra de Menezes.

2.2 Objetivos Específicos (OE) do Produto

Para alcançar o objetivo geral, o desenvolvimento do VitalTech baseia-se nos seguintes objetivos específicos:

  • (OE1) Centralizar o registro assistencial dos residentes. (foco: substituição do papel)

  • (OE2) Garantir o controle de acesso e a rastreabilidade das ações da equipe. (foco: segurança / auditoria)

  • (OE3) Apoiar a tomada de decisão clínica. (foco: consulta / decisão)

2.3 Características de Produto

(mapeadas com os Objetivos Específicos do Produto)

ID Característica do Produto (CP) Descrição resumida OE
CP1 Gestão de Residentes Capacidade de cadastrar, editar e inativar o perfil digital dos residentes atendidos pela instituição. OE1
CP2 Registro Assistencial Digital Capacidade de registrar digitalmente, no ponto de cuidado, os dados de sinais vitais, rotinas assistenciais, administração de medicamentos e ocorrências clínicas dos residentes. OE1
CP3 Autenticação de Usuários Capacidade de autenticar e encerrar a sessão de membros da equipe, controlando o acesso ao sistema. OE2
CP4 Gerenciamento de Usuários Capacidade de cadastrar, atualizar, redefinir senha e revogar o acesso dos membros da equipe assistencial. OE2
CP5 Consulta do Histórico Assistencial Capacidade de consultar, filtrar e visualizar o histórico cronológico de registros assistenciais dos residentes, apoiando decisões clínicas da equipe multidisciplinar. OE3

2.4 Tecnologias a Serem Utilizadas

Para atender às restrições de custo, viabilizar o funcionamento em rede local instável (offline-first) e garantir que o código-fonte seja leve e de fácil manutenção futura por parte da equipe do cliente, o projeto Vital Tech adotará a arquitetura de Progressive Web App (PWA) em conjunto com uma API leve, utilizando as seguintes tecnologias:

1. Frontend (Interface Mobile e Web):

  • Tecnologia: PWA (Progressive Web App) utilizando HTML5, CSS3 e JavaScript (com um framework leve como Vue.js).
  • Justificativa: O PWA permite que a aplicação seja acessada pelo navegador do tablet e instalada na tela inicial como um aplicativo nativo, sem a necessidade de publicação em lojas de aplicativos (Play Store) ou de pesados ambientes de compilação mobile (como React Native). O código em padrão web garante uma curva de aprendizado suave para a futura manutenção pelo cliente.
  • Armazenamento Local (Offline): Service Workers e IndexedDB. Essa tecnologia nativa dos navegadores modernos permite que o aplicativo funcione sem internet, armazenando os prontuários localmente no tablet e sincronizando-os em segundo plano assim que a conexão Wi-Fi for restabelecida.

2. Backend (Servidor de Aplicação / API):

  • Tecnologia: Python (utilizando o framework FastAPI).
  • Justificativa: Acatando recomendações arquiteturais para evitar ambientes de execução pesados, o Python apresenta-se como a linguagem ideal. É extremamente legível, possui sintaxe amigável e facilita a transferência de tecnologia para o cliente. O framework servirá como uma API REST ágil, hospedada no servidor local da instituição, responsável por validar e injetar os dados sincronizados pelo tablet no banco de dados.

3. Banco de Dados (SGBD):

  • Tecnologia: MySQL.
  • Justificativa: O MySQL será utilizado como o banco de dados relacional central no servidor físico da instituição. Trata-se de uma solução open-source robusta, capaz de centralizar os prontuários e garantir o controle de integridade referencial, resolvendo definitivamente os gargalos de concorrência e instabilidade do atual legado em Microsoft Access.

A comunicação entre a interface móvel (PWA) e o banco de dados central (MySQL) será orquestrada de forma assíncrona por meio de APIs, viabilizando a sincronização segura dos prontuários médicos sempre que o dispositivo restabelecer a conexão de rede. Para o gerenciamento do código-fonte e o fluxo colaborativo da equipe, adotaremos o sistema de versionamento Git com repositório remoto no GitHub, suportado por rotinas de testes e integração contínua (CI) alinhadas ao ciclo de vida do projeto.

2.5 Pesquisa de Mercado e Análise Competitiva

O mercado atual de software para gestão de Instituições de Longa Permanência para Idosos (ILPIs) possui soluções consolidadas, mas muitas vezes inacessíveis para algumas instituições devido ao alto custo de licenciamento e/ou à dificuldade técnica envolvida. No caso específico do Lar dos Velhinhos Bezerra de Menezes, os cuidadores dependem de processos manuais - papel e planilhas - que geram silos de informação e dificultam o acesso.

Solução Perfil Pontos fortes Gaps
Microsoft Access Solução atual da instituição. Custo zero de licenciamento; customizado pelo diretor. Dados isolados; difícil acesso mobile; risco de perda de dados; não suporta múltiplos acessos simultâneos de forma eficiente.
Sistemas Comerciais (Ex: IW Software) Software de prateleira para ILPIs. Completo; prontuário robusto; atende normas da ANVISA. Custo de assinatura elevado; interface complexa com excesso de digitação; curva de aprendizado alta para cuidadores com rotatividade.
Prontuários em Papel Método tradicional manual. Custo imediato zero; não exige tecnologia. Difícil busca de histórico; rasuras; perda de informações críticas; impossibilidade de gerar alertas automáticos; silos de informação.

2.6 Viabilidade da Proposta

A execução do projeto Vital Tech foi analisada sob quatro dimensões (Técnica, Financeira, Operacional e Legal), comprovando o alinhamento entre as exigências acadêmicas da disciplina e as severas restrições de recursos do Lar dos Velhinhos Bezerra de Menezes.

A escolha da stack tecnológica (PWA, Python/FastAPI e MySQL) apresenta uma curva de aprendizado factível para a equipe de desenvolvimento dentro do cronograma do semestre. Para garantir a viabilidade acadêmica (que exige acesso remoto contínuo para avaliação do professor e da monitoria), o sistema operará em um ambiente de staging (homologação) na nuvem, utilizando infraestruturas gratuitas como Vercel (para o frontend PWA) e Fly.io (para a API).

Visando a entrega de um produto real e sustentável no longo prazo para o cliente uma ONG com orçamento restrito, o deploy em ambiente de produção será On-Premise (Servidor Local). A API Python e o banco de dados MySQL serão hospedados em uma máquina física já existente na própria instituição. Essa arquitetura garante custo zero de licenciamento de software e elimina qualquer dependência de mensalidades de servidores em nuvem (Cloud), inviáveis para o asilo.

O risco de interrupção do sistema por falhas no provedor de internet do asilo é mitigado pela arquitetura offline-first do PWA (via Service Workers), que garante o registro nos tablets e sincronização assíncrona via rede Wi-Fi local (Intranet). Além disso, visando reduzir o atrito na adoção da nova tecnologia e preservar a autonomia gerencial do cliente, o sistema implementa uma arquitetura de transição inteligente: os dados legados serão migrados para o MySQL, mas a interface atual do Microsoft Access será reconfigurada via conexão ODBC (Tabelas Vinculadas). Dessa forma, o Access passa a atuar exclusivamente como uma ferramenta de visualização local (Frontend) do MySQL. Isso garante a estabilidade do banco para inserções via dispositivos móveis, ao mesmo tempo em que mantém a familiaridade do cliente para a geração de relatórios administrativos já consolidados.

Ao adotar o deploy On-Premise, a solução isola o tráfego de informações na Intranet da instituição. Como os prontuários contêm dados sensíveis de saúde, mantê-los armazenados fisicamente no servidor interno da ONG sem exposição a bancos de dados públicos em nuvem de terceiros facilita a conformidade com a Lei Geral de Proteção de Dados (LGPD) e atende aos critérios de segurança da informação. A estratégia de segregar o ambiente acadêmico (Cloud) do ambiente de produção (On-Premise), aliada à coexistência pacífica com o legado via ODBC, torna o projeto altamente executável pela equipe universitária e garante uma adoção operacional livre de custos extras e barreiras técnicas para o cliente bem como a manutenibilidade por parte do gestor do produto.

2.7 Benefícios Esperados

Para o Cliente (Diretoria e Equipe Multidisciplinar de Saúde): * Fim do Retrabalho Operacional: Mudança no processo de dupla digitação (transcrição do papel para o computador), otimizando o tempo da equipe e centralizando a informação em uma base de dados estruturada (MySQL). * Monitoramento Clínico em Tempo Real: Capacidade de acompanhar o status de saúde e as rotinas dos 74 idosos de forma instantânea, permitindo intervenções médicas preventivas em vez de apenas reativas. * Conformidade e Rastreabilidade (LGPD): Facilidade na geração de relatórios precisos para órgãos fiscalizadores, garantindo a autoria de cada registro e a segurança dos dados sensíveis mantidos na rede local. * Transição Tecnológica sem Atrito: Adoção de um novo sistema sem custos de mensalidade em nuvem (deploy On-Premise) e sem perda do legado gerencial, mantendo o Microsoft Access do cliente conectado como ferramenta de visualização.

Para os Usuários (Cuidadores na Beira do Leito): * Agilidade no cuidado dos idosos: Substituição das pranchetas e formulários físicos por um aplicativo de interface ágil (click-based), reduzindo drasticamente o tempo gasto escrevendo e permitindo maior foco no cuidado com o idoso. * Resiliência de Infraestrutura: Segurança de que nenhum dado inserido será perdido devido a quedas de energia ou falhas no Wi-Fi do asilo, graças ao funcionamento offline-first do aplicativo. * Mitigação de Erros de Preenchimento: Redução da carga cognitiva e de falhas humanas na passagem de plantão mitigando os impactos da alta rotatividade da equipe por meio de validações automáticas no momento da inserção do dado. * Acesso Imediato ao Histórico: Disponibilidade do resumo cronológico das últimas aferições do idoso diretamente na tela do tablet, eliminando viagens desnecessárias até os arquivos físicos ou postos de enfermagem.


Histórico de Revisão

Data Versão Descrição Autor
03/04/2026 1.0 Criação do documento (Seções 1 a 2.3) para submissão da proposta. Alberto Côrtes, João Pedro Sampaio, Ana Caroline, Enzo Menali e Gustavo Xavier
10/04/2026 1.1 Finalização e correção do documento para primeira entrega (Seções 1 a 6) para submissão. Alberto Côrtes, Ana Caroline, Enzo Menali e Gustavo Xavier
13/04/2026 1.2 Lançamento dessa seção no GitPages Gustavo Xavier
05/05/2026 1.3 Reformulação da seção 2.3 (Características de Produto): adequação ao feedback do professor, remoção de RNFs disfarçados de CPs (antigas CP4 e CP7), substituição por capacidades funcionais derivadas dos OEs revisados. Gustavo Xavier
17/05/2026 1.4 Reestruturação completa das seções 2.1, 2.2 e 2.3: reformulação do OG, redução de 5 para 3 OEs e de 6 para 5 CPs com mapeamento 1:1 entre CP e OE. Adição das Regras de Negócio (RN-01 a RN-04). Gustavo Xavier