Estudo de caso · Selecionado no 13º Campus Mobile
UniFlui: da fila no hospital à gestão das unidades de saúde
Uma ideia de aula que virou projeto de disciplina, foi selecionada num programa nacional, ganhou pesquisa com usuários, mudou de direção e hoje é um MVP de plataforma para unidades básicas de saúde. É o meu projeto mais longo, e o que mais me ensinou sobre mudar de rumo com evidência.
A linha do tempo
- 2024 · A ideia Nasce numa aula de administração sobre inovação, num grupo de cinco estudantes. Escrevemos o Documento de Visão: um app que mostra ao paciente onde há atendimento e o tamanho da fila.
- Em seguida · Projeto de disciplina Duas pessoas do grupo levaram a ideia para a disciplina de Engenharia de Software, e passaram a estudá-la e aprimorá-la.
- jan–fev/2025 · 13º Campus Mobile A proposta "Gestão de Filas Inteligentes em Unidades de Saúde" foi selecionada na categoria Saúde do programa nacional do Instituto Claro. Fizemos entrevistas, requisitos, histórias de usuário, modelo de negócio e pitch.
- 2025 · Pesquisa e prototipação A equipe passou a ter 4 pessoas. Na disciplina de Engenharia de Software Aplicada: entrevistas com usuários, protopersonas, backlog com cenários BDD, protótipo no Figma e protótipo navegável no Adalo. Escrevemos também um artigo sobre o projeto para o SBSI 2025.
- mai–jun/2026 · Pivô para um MVP de gestão O produto deixa de ser só um app de informação para o paciente e vira uma plataforma de saúde pública, com agendamento, métricas, escala de profissionais e IA para os gestores das UBSs.
O problema
A superlotação em unidades de saúde afeta quem espera e quem trabalha. Para o paciente, fila longa, risco de desistir do atendimento e de recorrer à automedicação, que pode piorar quadros simples. Para o profissional, ambientes lotados significam desgaste físico e mental e risco de burnout, o que reduz a qualidade do acolhimento.
Uma das causas que escolhi atacar é a desinformação: muita gente não sabe qual unidade atende a sua queixa e acaba indo ao lugar errado, o que gera aglomeração desnecessária. Na literatura que consultamos, a fila é descrita como a porta de entrada do sistema de saúde e molda a visão do usuário sobre ele.
Descoberta: o que as entrevistas mostraram
Entrevistamos 8 pessoas, uma a uma, com roteiro estruturado e gravação em áudio com consentimento. Transcrevemos e analisamos as respostas com apoio de uma ferramenta de IA e organizamos os dados em gráficos para enxergar padrões. Também ouvimos profissionais de saúde: 6 de 8 enfrentam superlotação diariamente ou semanalmente, principalmente em atendimento especializado, pronto-socorro, recepção e ambulatórios.
| O que encontramos | O que isso mudou |
|---|---|
| Todos queriam saber o quão ocupados os hospitais da região estão, e a maioria preferia um lugar com pouca fila a um mais próximo. | A informação de fila virou o centro da proposta de valor, acima da localização. |
| A maioria tinha dificuldade em achar especialistas e em saber onde e quando atendem, o que levava a adiar a busca e a desistir. | Busca por especialidade entrou como requisito. |
| O perfil real não era o que tínhamos planejado. Esperávamos pessoas do interior de 20 a 45 anos. Os entrevistados eram majoritariamente urbanos, mais velhos (até 60) e com escolaridade alta. | Em vez de forçar o perfil original, separamos duas protopersonas por faixa etária e passamos a considerar públicos urbano e rural. |
O terceiro ponto é o mais importante. A amostra era pequena e diferente da esperada, e em vez de esconder isso o relatório compara o perfil proposto com o real e diz o que a diferença significa.
Primeira solução e modelo de negócio
- Para o paciente (grátis): mapa com as unidades próximas, filtros por especialidade, horários, rota e tamanho da fila.
- Para a unidade (assinatura): relatórios de fluxo por setor e destaque no aplicativo. O modelo é B2C2B: o paciente atrai, a unidade paga.
- Sem depender de contrato: para a rede pública, a ideia era usar bases abertas de unidades (CNES e DataSUS). Com contrato, a rede privada ganharia a fila em tempo real e os relatórios.
- Mapeamos a concorrência (sistemas de senha e gerenciadores de fila) e vimos que ofereciam painéis e totens, mas não ajudavam o paciente a escolher onde ir.
- Na primeira versão, o tamanho da fila viria de uma câmera com reconhecimento de imagem na sala de espera.
Depois, o fluxo evoluiu: o paciente escaneia um QR code na recepção, preenche um pré-prontuário, entra na fila da unidade e sai dela ao ser atendido. A recepcionista vê os dados e o tempo médio de espera.
Requisitos e backlog
Escrevemos 17 requisitos funcionais e 4 não funcionais, entre eles LGPD e acessibilidade, e um backlog priorizado em três ondas: primeiro o núcleo (mapa, unidades próximas, fila), depois o que dá confiança (cadastro, rota, horários) e por último o conforto (favoritos).
Cada funcionalidade tem história de usuário e cenários BDD, incluindo os de falha: se o logout falha por erro de rede, o usuário continua logado e é avisado; se a exclusão da conta falha, a conta não é apagada. Pensar no erro é parte da especificação.
Validamos com um protótipo navegável no Adalo e com telas no Figma, antes de qualquer código.
O pivô
O MVP de 2026 muda o ponto de partida. Em vez de mostrar a fila em tempo real captada por câmera, a plataforma organiza a demanda na origem, e serve a quem gerencia a unidade:
| Primeira versão | MVP de 2026 | |
|---|---|---|
| Foco | Informar o paciente | Gerir a unidade e a rede |
| Fila | Contada por câmera | Agendamento, lembretes e fila de atendimento |
| Para o gestor | Relatório de fluxo | Métricas, escala de profissionais otimizada e dashboard com IA |
| Perfis | Paciente e administrador | Paciente, profissional, gestor da UBS e secretaria de saúde |
| Produto | Aplicativo de informação | Plataforma white label de saúde pública |
O MVP de 2026
Defini quatro módulos: agendamento, registro pós-consulta, notificações e métricas. UBSs, especialidades e horários entram como dados fictícios, preparados para importar de fontes oficiais (CNES). Preferi não esperar uma integração para validar o fluxo.
Regras de produto que protegem as pessoas
- Cancelar com pelo menos 24 horas de antecedência, e o horário volta a ficar livre para outro paciente. Quando é o profissional que cancela, a justificativa é obrigatória e o paciente é notificado.
- Registro pós-consulta imutável, só criado se a consulta foi realizada.
- Métricas nunca expõem dados que identifiquem um paciente. O gestor só vê a própria unidade (relação 1 para 1), e a secretaria vê o agregado.
- O isolamento entre unidades vem do token de login e nunca de um dado enviado pela tela.
- Login com identificador diferente por perfil: paciente entra com CPF e profissional com matrícula, e o sistema recusa o identificador trocado com uma mensagem que explica o motivo.
Escala de profissionais por otimização matemática
Em vez de o gestor montar a escala na mão, o sistema calcula uma escala que cobre o mínimo de médicos e enfermeiros em cada turno sem passar da carga contratada de cada profissional (programação linear inteira). Começou semanal e, na sprint 11, virou mensal. Ao final, a IA escreve um resumo em português para o gestor.
Dashboard que explica os números
Os indicadores (absenteísmo, ocupação, demanda por especialidade) ganharam uma narrativa gerada por IA, com recomendações como "considere enviar lembretes 48 horas antes". A regra de segurança do projeto é que a IA nunca escreve nem executa SQL: ela deve só acionar funções que já existem no sistema, com parâmetros controlados. As respostas ficam em cache, e se o cache cair o sistema continua funcionando.
O provedor de IA mudou no meio do caminho, do Gemini para a Groq, por bloqueios de cota e autenticação. A troca exigiu mexer na dependência, na configuração e no formato da resposta, e foi o motivo de uma sprint de estabilização.
Hipóteses e o que já sei sobre elas
| Hipótese | Como testei ou testaria | Situação |
|---|---|---|
| O paciente prefere um lugar com pouca fila a um mais próximo. | Entrevistas com 8 pessoas. | Indício. Amostra pequena e mais urbana do que o previsto. |
| Saber a ocupação e a especialidade antes de sair de casa reduz deslocamentos desnecessários. | Protótipo navegável e artigo. Falta medir com uma unidade real. | Aberta. |
| Lembrete 24 horas antes e cancelamento fácil reduzem o absenteísmo. | Lembretes automáticos, cancelamento que libera o horário e a taxa de absenteísmo como indicador. | Aberta. Funcionando com dados fictícios. |
| O gestor age mais com uma explicação em linguagem natural do que com o número bruto. | Dashboard com narrativa e recomendações geradas por IA. | Aberta. Não testada com gestores. |
| Uma escala otimizada poupa o tempo do gestor e cobre os turnos. | Módulo de escala mensal com restrições de cobertura e carga. | Aberta. Falta comparar com a escala manual de uma UBS real. |
Métricas
- Principal (definida): taxa de absenteísmo, ou seja, ausentes sobre agendados.
- De apoio (definidas): taxa de ocupação dos horários, demanda por especialidade e atendimentos realizados por dia, semana e mês.
- Resultados: o MVP roda com dados fictícios, então não há resultado de uso para mostrar. O que existe de evidência são as entrevistas (8 pessoas e profissionais de saúde), que sustentam o problema, e não a solução.
Artigo
Escrevemos o artigo "O Protagonismo dos Pacientes na Jornada de Atendimento em Unidades de Saúde", para o Simpósio Brasileiro de Sistemas de Informação (SBSI 2025). Ele reúne o problema, as entrevistas, o fluxo com QR code e a ligação com a estratégia de saúde digital do Brasil.
O que aprendi
- Uma ideia premiada ainda não é um produto. Transformá-la em requisitos, regras e sprints mostrou o que a apresentação não precisava responder.
- Pesquisa com usuários vale mais quando você compara o que esperava com o que encontrou. O público real era diferente do planejado, e isso mudou as personas.
- Mudar de direção é parte do produto. O que permaneceu do início ao fim foi o problema (a desinformação e a lotação), não a solução.
- Regras de privacidade e de acesso entram no desenho desde o primeiro requisito, e não como ajuste final.
- Sem unidade real, as hipóteses de impacto seguem abertas. A maior prioridade seria validar com uma UBS.
O código do MVP está em repositório privado.