ImpulsoGov · Teste Técnico · Designer de Serviços Sênior
REGISTRO
ASSISTIDO

Redesenhando o registro de acolhimentos em saúde mental na Atenção Primária à Saúde — do diagnóstico sistêmico à proposta fundamentada.

Case Study · Abril 2026
Teste Técnico · Solo Project · ImpulsoGov
REGISTROASSISTIDO
Redesign do registro de acolhimentos em APS

O desafio era propor caminhos para melhorar o registro de acolhimentos em saúde mental na Atenção Primária à Saúde — o recorte operacional de um programa que a ImpulsoGov já conduz.

Este trabalho não entrega apenas uma solução. Entrega o processo: diagnóstico do ecossistema, análise de falhas, princípios de design, caminhos explorados e descartados, e uma proposta fundamentada em evidências reais.

Modalidade Solo Project
Contexto Atenção Primária à Saúde (APS)
Usuário-foco ACS capacitados em SM em campo
Entregável Diagnóstico + Proposta de serviço
Duração Teste técnico — Abril 2026
IMPULSOGOV · DESIGNER DE SERVIÇOS SÊNIOR · 2026
WHY DO THIS?
O Desafio e o Contexto

A ImpulsoGov conduz um programa para qualificar acolhimentos em saúde mental na APS. O registro — a etapa que garante rastreabilidade, continuidade e dados para o sistema — é o ponto crítico: muitos profissionais não registram, ou registram de forma inconsistente e tardia.

Não se trata de falta de ferramentas. Existem três: o PEC (prontuário oficial), um bot WhatsApp da ImpulsoGov e o caderno físico comprado pelos próprios profissionais. Nenhuma delas foi desenhada para o momento e contexto real em que o registro precisa acontecer.

Este trabalho parte do pressuposto de que o problema não é de motivação nem de conhecimento — capacitações já foram realizadas sem impacto na adesão. O problema é estrutural e de timing.

REGISTRO NÃO OCORRE PEC (e-SUS APS) Oficial · PC + internet · SOAP Bot WhatsApp CSAT 38% · Isolado Caderno Físico Comprado · Não rastreável INTEGRAÇÃO POSSÍVEL PEC ↔ ImpulsoGov via LEDI APS (Thrift/XML)
Ecossistema de ferramentas Análise de contexto Falha de integração
ECOSYSTEM ANALYSIS
Por que as soluções atuais falham
Critério PEC Caderno Bot
Acesso em campo ✕ PC ◑ Net
Dados ao governo
PHQ-9 / GAD-7
Funciona offline
Satisfação Baixa Precário 38%
Por que o bot falhou

O bot transferiu a fricção de meio, mas manteve a mesma lógica: parar, lembrar, digitar. A carga cognitiva permanece idêntica. Além disso, o WhatsApp compete com mensagens pessoais, gerando distração e abandono no meio do fluxo de registro.

Nenhuma das três soluções foi desenhada para o contexto real do campo: sem internet estável, sem PC disponível, com alta carga cognitiva acumulada e múltiplas interrupções ao longo do dia.

Análise comparativa Falha de timing 38% CSAT
PRIMARY RESEARCH
O Usuário — Perfil e Contexto de Campo

Denilson é ACS em Jacarezinho. Foi capacitado para conduzir acolhimentos em saúde mental e atua inteiramente em campo — sem mesa fixa, sem PC próprio, em rotas que atravessam múltiplas residências ao longo do dia.

Seu contexto impõe restrições reais: conectividade instável, PC compartilhado com fila de espera, alta carga cognitiva acumulada e interrupções constantes. O momento entre terminar um acolhimento e ter acesso a uma ferramenta de registro pode durar horas.

📋
Roteiro de visitas
Múltiplas linhas por dia
🏠
Domicílio do paciente
Sem equipamento disponível
📵
Sem sinal de internet
Conectividade instável
🖥
PC compartilhado
Fila na UBS ao retornar

Gap de horas
Entre atender e registrar
😓
Carga cognitiva alta
Fim do dia — exaustão
Observação de campo Pesquisa contextual Análise de restrições
EVIDENCE ANALYSIS
Por que o registro não acontece — dados
61% aponta falta de tempo como barreira
54% sem horário definido para registrar
38% CSAT do bot WhatsApp
Dado mais revelador

Capacitações foram realizadas sem qualquer impacto na adesão ao registro. Isso elimina a hipótese de falta de conhecimento ou motivação — o problema é estrutural, não comportamental.

Apenas 27% registram logo após o atendimento — o único momento em que os dados ainda estão íntegros na memória de trabalho. Os 73% restantes registram horas depois, ou não registram.

Modelo BJ Fogg — onde a cadeia quebra

Comportamento = Motivação × Habilidade × Gatilho.

Motivação existe — profissionais entendem a importância.
Habilidade está restringida — o campo impede uso das ferramentas.
Gatilho está ausente — nada aciona o comportamento no momento certo.

Dados quantitativos Modelo Fogg Capacitação sem efeito
Os insights que ancoraram o diagnóstico:
01
"Não é falta de ferramenta. Existem três. Nenhuma foi desenhada para o momento real do registro."
Diagnóstico de ecossistema — análise das soluções existentes
02
"O gap entre atender e registrar é onde a informação se perde. Quanto maior, pior a qualidade."
Análise do fluxo de campo — falha de timing
03
"Capacitação sem impacto na adesão. Informação não muda comportamento quando a fricção é estrutural."
Dado crítico — análise de evidências
PROBLEM REFRAME
A pergunta que guiou a proposta
Como integrar o registro à rotina do ACS, reduzindo esforço cognitivo e eliminando a dependência de memória e disciplina, de forma que os dados cheguem ao sistema oficial no momento certo?
● comportamento alvo ● design de produto ● barreira a eliminar ● contexto operacional
Três diagnósticos que a pergunta encapsula
01
Não é falta de ferramenta
Existem 3. O problema é que nenhuma serve ao contexto real de campo.
02
Não é falta de motivação
Capacitações sem impacto. A fricção é estrutural, não atitudinal.
03
É uma falha de timing
O gap entre atender e registrar é onde a informação se perde definitivamente.
STORYBOARDING
Jornada do Denilson — Um dia de campo

ACS em Jacarezinho. Capacitado para acolhimento em saúde mental. A jornada mostra onde a informação se perde.

01
07:30
Chega à UBS. Organiza o dia.
02
08:00
Visitas domiciliares. Múltiplas linhas.
03
10:30
Acolhimento SM. ~60 minutos.
REGISTRAR OU PERDER
04 ⚠
11:30
Momento crítico. Dados evaporam.
14:00
05
14:00
Retorno à UBS. PC com fila.
! z z 27% incompleto
06 ✕
16:30
Registro abandonado. Dados perdidos.
07:30 → 16:30 Gap crítico: 5+ horas Alta carga cognitiva
PATHS EXPLORED
Caminhos explorados e descartados

Antes de chegar à proposta final, três caminhos foram avaliados com rigor. Dois foram descartados por razões estruturais — não de implementação, mas de inadequação ao contexto real.

A. Melhorar o bot WhatsApp Descartado
Redesenhar o fluxo de conversa, reduzir etapas, simplificar linguagem.
✕ Internet obrigatória. CSAT 38% indica falha estrutural, não de UX. A lógica permanece.
B. Modo rápido no PEC (e-SUS) Descartado
Criar tela simplificada dentro do próprio PEC para registros de saúde mental.
✕ Impossível adicionar variáveis. Governança federal impede alterações no sistema.
C. Voz + IA → Registro Assistido Selecionado
Captura por áudio ao final do acolhimento. Transcrição offline, estruturação por LLM, validação pelo profissional, sync duplo (ImpulsoGov + PEC).
✓ Offline. Imediato. Mínimo esforço cognitivo. Integra com sistema oficial.
Design decision Voz + IA Offline-first
PROPOSED SOLUTION
Registro Assistido — O serviço proposto

O registro como extensão natural do atendimento. Em vez de exigir que o profissional se adapte ao sistema, o sistema se adapta à realidade do cuidado.

1
Fim do acolhimento
Gatilho automático
2
Nudge contextual
Geoloc ou timer
3
Grava áudio
30–60s · offline
4
STT local
Transcrição no device
5
IA estrutura
Campos + escalas
6
Valida
1 toque · ~2 min
7
Queue offline
Armazena local
8
Sync duplo
IG + PEC via LEDI
Fundamentos técnicos

Whisper rodando localmente para transcrição offline. LLM com prompt de domínio clínico extrai: tipo de acolhimento, queixa principal, PHQ-9, GAD-7, desfecho e encaminhamentos. Gollwitzer (1999): vincular a ação a um momento e lugar específico eleva a execução em até 3×.

Antes
Atende → horas → lembrar → PEC ou bot → campo a campo → desiste
⏱ 15–20 min · Alta fricção · Dados incompletos
Depois
Atende → lembrete → áudio → IA → valida → sync automático
⏱ ~2 min · Baixa fricção · Dados completos
Whisper STT LLM domain-specific Offline-first LEDI APS
DESIGN PRINCIPLES
Princípios que qualquer solução válida precisa honrar

Estes princípios foram derivados do diagnóstico de campo. Funcionam como filtros de decisão — qualquer escolha de design que viole um deles gera o mesmo problema que as soluções anteriores.

🌱
Registro como subproduto
Deve emergir naturalmente do ato de cuidar, não como tarefa separada e consciente adicionada ao final do dia.
📶
Offline-first obrigatório
Sem internet é a condição padrão em campo. Sincronização apenas quando houver conexão — sem penalidade por ausência de sinal.
🧠
Carga cognitiva mínima
O profissional narra, não preenche. A estruturação é responsabilidade do sistema, não do usuário.
🔗
Integração real com PEC
Dados precisam chegar ao sistema oficial. Solução isolada reproduz exatamente o fracasso do bot.
Validação, não criação
O usuário revisa e confirma o que o sistema gerou. Jamais redige do zero sob carga cognitiva alta.
SERVICE BLUEPRINT
Mapa do Serviço — Registro Assistido

O blueprint mapeia cada camada do serviço em seis estágios: do acolhimento ao dado registrado no PEC. A linha de visibilidade separa o que o ACS experimenta do que acontece nos sistemas por trás.

Camada Acolhimento Nudge Captura Validação Sync Integração
— LINHA DE VISIBILIDADE —
Frontstage SM ~60min Notificação no celular Áudio 30–60s Revisa · confirma Automático Automático
Backstage App em standby Geoloc / timer Queue offline STT + LLM Sync manager LEDI → PEC
Suporte Capacitação ACS Configuração Modelo clínico APS Prompt engineering Cloud IG Acordo municipal
Falhas Privacidade Ignorada Ruído / sotaque Erro de IA Perda de dados PEC rejeita
Nota sobre falhas

Cada ponto de falha identificado no blueprint tem um mecanismo de mitigação correspondente na proposta: validação humana obrigatória para erros de IA, criptografia e2e para privacidade, descarte do áudio após transcrição para LGPD, e queue local para perdas de sync.

Service Blueprint Linha de visibilidade 4 camadas mapeadas
SYSTEM MAP
Mapa de integração sistêmica

O serviço proposto não existe em isolamento. Ele articula três sistemas distintos — o app do ACS, a plataforma ImpulsoGov e o PEC federal — em um fluxo coerente de dados clínicos. O acordo municipal com a gestão local é o enabler crítico para a integração via LEDI APS.

APP DO ACS offline-first REGISTRO ASSISTIDO STT + LLM + Queue IMPULSO GOV PHQ-9 · GAD-7 PEC e-SUS APS LEDI APS voz granular LEDI ACORDO MUNICIPAL — ENABLER CRÍTICO
3 sistemas integrados Sync duplo
DESIGN DECISIONS
Processo de design — caminhos e escolhas

A proposta final emergiu de um processo deliberado de eliminação. Três caminhos foram avaliados. Dois foram descartados não por preferência, mas por inadequação estrutural ao contexto.

🎙
Entrada por voz
Narra em vez de preencher. Elimina a dependência de teclado e digitação em contexto de campo com carga cognitiva alta.
Captura imediata
O registro acontece em 2 minutos após o atendimento — antes do gap de memória. Gollwitzer: intenção + contexto = execução.
🤖
IA como secretária
O modelo estrutura a narração em campos clínicos. O ACS valida, não cria. Inversão do ônus cognitivo.
🔄
Queue + sync assíncrono
Dados ficam localmente seguros até haver conexão. O profissional não precisa se preocupar com internet para registrar.
🔒
LGPD by design
Criptografia e2e no áudio. Descarte automático após transcrição. Dados de saúde tratados como categoria sensível.
🌱
Piloto antes de escalar
5–10 ACS em contexto controlado. Iterar sobre a experiência real antes de qualquer expansão. Mudança de comportamento leva tempo.
IMPACT & METRICS
Como mediremos o sucesso
North Star Metric
% de acolhimentos registrados no PEC em até 24 horas
Tempo de registro
↓ <3min
vs. 15–20 min atuais ou abandono
Satisfação
↑ NPS
baseline: CSAT 38% no bot atual
Limitações reais — sem ilusões
Dependência de acordo municipal
LEDI APS requer formalização com a gestão local. Sem acordo, o sync com o PEC não é possível.
Transcrição imprecisa
Sotaques regionais, vocabulário clínico e ruído de campo degradam a qualidade. A validação humana é essencial e não opcional.
LGPD — dados de saúde sensíveis
Exige criptografia e2e, descarte do áudio após transcrição e política clara de retenção de dados.
CLOSING STATEMENT
"Ao invés de exigir que o profissional se adapte ao sistema, redesenhamos o sistema para se adaptar à realidade do cuidado."

O registro não falha por negligência. Falha porque o sistema foi desenhado para um contexto que não existe na ponta. Quando eliminamos a fricção estrutural e entregamos o gatilho certo no momento certo, o comportamento emerge naturalmente — sem disciplina adicional, sem sobrecarga.

Romenig Cintra
Psicólogo · Designer de Produto · Abril 2026
Sobre o autor
Serviço que serve às pessoas, não ao sistema.

Psicólogo e designer de produto. Trabalho na intersecção entre psicologia comportamental, design de serviços e tecnologia — acreditando que o design mais eficaz é o que torna o comportamento certo mais fácil que o errado.

Registro Assistido
Case Study — Teste Técnico
ImpulsoGov · Designer de Serviços Sênior
Abril 2026