Performance optimization of an R Shiny-based digital health dashboard for monitoring small and sick newborn care in low-resource hospital settings

Este estudo descreve e avalia as estratégias de otimização aplicadas ao painel digital NEST-IT, desenvolvido em R Shiny para monitoramento de recém-nascidos em hospitais de baixa renda, demonstrando melhorias significativas no tempo de processamento, renderização e disponibilidade do sistema que garantem acesso mais rápido e confiável a informações críticas de saúde.

O essencial

🚑 O "Trânsito" Digital nos Hospitais: Como Aceleramos um Mapa Vital para Bebês

Imagine que você é um médico em um hospital na África, cuidando de bebês recém-nascidos que estão doentes. Você precisa de informações rápidas: "Quantos bebês estão recebendo o tratamento certo?", "Onde estamos com falta de oxigênio?". Para ajudar, existe um painel digital (um site interativo) chamado NEST-IT. Ele funciona como um "GPS" ou um "painel de controle" que mostra todos os dados dos hospitais em tempo real.

Mas, infelizmente, esse GPS estava travando.

🐢 O Problema: Um Carro de Fórmula 1 em uma Estrada de Terra

O painel foi construído com uma ferramenta chamada R Shiny. Pense no R Shiny como um carro de corrida muito potente, mas que foi projetado para rodar em pistas de asfalto perfeitas (computadores rápidos e internet de fibra óptica).

O problema é que os hospitais onde esse painel é usado são como estradas de terra batida:

• Computadores antigos e lentos.
• Internet fraca e instável.
• Muitos médicos tentando usar o sistema ao mesmo tempo.

Quando o sistema cresceu (deixou de ter dados de 68 hospitais para mais de 100, com meio milhão de registros), o "carro" começou a engasgar.

• Antes: Para ver um gráfico simples, o médico tinha que esperar 10 segundos (ou até mais). Era como pedir um café e esperar 10 minutos para ele chegar.
• O Resultado: Médicos ficavam frustrados, o sistema travava e, o pior, decisões importantes sobre a vida dos bebês eram atrasadas.

🛠️ A Solução: A "Reforma" do Motor

Os autores do estudo (uma equipe de engenheiros e médicos) decidiram fazer uma "reforma completa" no sistema para que ele funcionasse nessas estradas de terra. Eles não trocaram o carro, mas otimizaram o motor de várias formas criativas:

1. Cozinhar antes de servir (Pré-processamento de Dados):

   • Antes: O sistema tentava cozinhar a comida (processar dados) na hora que o cliente pedia.
   • Depois: Eles começaram a cozinhar tudo antes e deixar pronto na geladeira. Quando o médico pedia, o prato já estava servido. Isso reduziu o tempo de espera drasticamente.

2. Não carregar o que não precisa (Carregamento Preguiçoso):

   • Antes: O sistema tentava carregar todas as fotos e mapas do mundo inteiro assim que você abria o site.
   • Depois: O sistema agora só carrega o que você está olhando naquele momento. É como entrar em uma biblioteca gigante: em vez de pegar todos os livros da estante, você pega apenas o livro que está lendo.

3. Ter um "Segundo Chef" na Cozinha (Processamento Assíncrono):

   • Antes: O cozinheiro principal (o computador) tinha que parar tudo para fazer uma tarefa longa, deixando o cliente esperando.
   • Depois: Eles contrataram um ajudante (processamento em segundo plano) para fazer as tarefas pesadas enquanto o cozinheiro principal continua atendendo os clientes. O site não trava mais enquanto calcula números complexos.

4. Guardar Respostas Antigas (Memória Cache):

   • Antes: Se você perguntasse a mesma coisa duas vezes, o sistema calculava tudo de novo.
   • Depois: O sistema aprendeu a anotar a resposta. Se você perguntar de novo, ele apenas mostra o papel com a resposta escrita, sem precisar calcular nada.

🚀 Os Resultados: De "Lento" para "Rápido"

Depois dessa reforma, a diferença foi impressionante:

• Velocidade: O tempo para carregar um gráfico complexo caiu de 10 segundos para apenas 2,7 segundos. É como ir de um carro de tração lenta para um trem-bala.
• Confiança: O sistema ficou disponível 99% do tempo (antes era 92%). Isso significa que o "GPS" raramente sai do ar.
• Acesso: Agora, mesmo em celulares antigos e com internet ruim, o painel funciona bem.

💡 Por que isso importa?

Imagine que você está dirigindo em uma estrada escura e precisa de um farol. Se o farol demorar 10 segundos para acender, você pode bater no muro. No caso dos bebês, cada segundo conta.

Ao consertar a velocidade desse painel digital, os médicos conseguem ver os problemas e agir na hora. Eles podem identificar onde um hospital precisa de mais oxigênio ou onde a técnica de "Kanguru" (um método de cuidar de bebês prematuros) não está sendo usada, e corrigir isso imediatamente.

Em resumo: O estudo mostra que, mesmo com tecnologia simples e recursos limitados, é possível criar ferramentas digitais super-rápidas e confiáveis se você souber "otimizar o motor". Isso salva vidas, porque transforma dados lentos em decisões rápidas.

Resumo técnico

Título: Otimização de Desempenho de um Painel de Saúde Digital Baseado em R Shiny para Monitoramento de Cuidados a Recém-Nascidos Pequenos e Doentes em Hospitais de Recursos Limitados

1. Problema

O painel NEST-IT (NEST360 Implementation Tracker), desenvolvido em R Shiny, é utilizado para monitorar intervenções de cuidados neonatais em mais de 100 hospitais na África Subsaariana. À medida que a plataforma escalou para suportar mais de 500.000 registros e mais de 250 usuários simultâneos, surgiram graves limitações de desempenho devido à arquitetura de thread única do R Shiny e às restrições de infraestrutura nos locais de baixa renda (hardware desatualizado, conectividade de internet limitada e dispositivos móveis de baixo poder de processamento).

As principais consequências incluíam:

• Tempos de carregamento de visualizações superiores a 10 segundos.
• Respostas lentas do servidor e "congelamento" da interface do usuário (UI).
• Inacessibilidade em dispositivos móveis e tablets, comprometendo a tomada de decisão clínica em tempo real e a eficiência operacional.

2. Metodologia

O estudo utilizou um desenho quase-experimental pré-pós (dezembro de 2023 a agosto de 2024) seguindo um framework estruturado de cinco fases:

1. Perfilamento de Desempenho (Profiling): Avaliação da linha de base usando três métricas principais:
   • Tempo de Renderização de Visualização (VRT).
   • Tempo de Processamento de Solicitação do Servidor.
   • Tempo até o Primeiro Byte (TTFB).
   • Limiares definidos: VRT > 4s, Processamento > 2s, TTFB > 1s.
2. Identificação de Gargalos: Detecção de quatro categorias principais de problemas: renderização lenta, respostas atrasadas do servidor, ineficiência no manuseio de dados e inconsistência no desempenho entre dispositivos.
3. Seleção e Implementação de Estratégias: Foram aplicadas seis estratégias técnicas de otimização específicas para R Shiny:
   • Manuseio Eficiente de Dados: Pré-processamento offline, lazy loading (carregamento sob demanda) e carregamento paralelo de dados em massa.
   • Programação Reativa: Uso de reactive() com memoise() para evitar recálculos redundantes e atualizações em tempo real apenas quando os inputs mudam.
   • Cache (Memorização): Armazenamento de resultados de computações complexas para recuperação instantânea.
   • Processamento Assíncrono: Uso de future() e promises para executar tarefas pesadas em processos separados, mantendo a UI responsiva.
   • Layout Adaptável (JavaScript): Otimização de layouts para dispositivos móveis de baixo poder.
   • Programação Vetorizada: Substituição de loops por operações vetorizadas usando dplyr e data.table.
4. Avaliação Pós-Otimização: Reavaliação das mesmas métricas de desempenho e testes estatísticos (teste t pareado e teste de Wilcoxon) para comparar os resultados antes e depois.

3. Principais Contribuições Técnicas

O artigo oferece um framework prático e baseado em evidências para otimizar aplicações R Shiny em ambientes de recursos limitados. As contribuições técnicas específicas incluem:

• Arquitetura Híbrida: Demonstração de como combinar processamento assíncrono no servidor com carregamento diferido no cliente para mitigar a arquitetura de thread única do Shiny.
• Otimização de Dados: Validação de que o pré-processamento offline e a agregação de dados antes do carregamento no painel reduzem drasticamente o tempo de inicialização.
• Adaptação a Dispositivos Limitados: Prova de que a otimização do JavaScript e o layout responsivo são críticos para a usabilidade em smartphones e tablets de baixo custo, comuns em hospitais de baixa renda.
• Reprodutibilidade: Fornecimento de snippets de código e estratégias detalhadas que podem ser replicadas por outros desenvolvedores de saúde digital.

4. Resultados

As otimizações resultaram em melhorias estatisticamente significativas (p < 0,001) em todas as métricas de desempenho:

• Tempo de Carregamento de Visualizações Interativas: Redução de 10,1s para 2,7s (melhoria de 73,3%).
• Tempo de Renderização de Visualização (VRT): Redução de 3,61s para 1,62s.
• Tempo de Processamento do Servidor: Redução de 2,3s para 0,8s.
• Tempo até o Primeiro Byte (TTFB): Redução de 1,9s para 0,6s.
• Uptime do Sistema: Aumentou de 92,5% para 99,2%, indicando maior estabilidade sob carga pesada.
• Melhorias Específicas em Gráficos Complexos: Gráficos multi-país que antes levavam ~18 segundos foram reduzidos para ~3,3 segundos (redução de ~82%).

Todos os componentes do painel passaram a atender ao limiar de usabilidade de < 4 segundos, permitindo interatividade em tempo real.

5. Significância

Este estudo demonstra que é possível transformar ferramentas de análise de dados lentas e frágeis em plataformas escaláveis e responsivas, mesmo em infraestruturas de TI precárias.

• Impacto Clínico: Ao reduzir a latência, o painel permite que profissionais de saúde e gestores tomem decisões baseadas em dados de forma oportuna, o que é crucial para a redução da mortalidade neonatal.
• Escalabilidade Global: As estratégias apresentadas servem como um modelo para a implementação de sistemas de saúde digital em outros países de baixa e média renda (LMICs), onde a confiabilidade e a velocidade são tão importantes quanto a relevância dos indicadores.
• Viabilidade Técnica: Confirma que o R Shiny, quando adequadamente otimizado, pode suportar grandes volumes de dados e múltiplos usuários simultâneos em ambientes de recursos limitados, superando a percepção de que é inadequado para produção em larga escala nesses contextos.