Plataforma para priorização de atendimentos na Atenção Primária à Saúde. O SinalACS transforma sinais clínicos estruturados em uma fila de trabalho para o Agente Comunitário de Saúde (ACS), priorizada por risco e preparada para operação em conectividade instável.
Estado atual: protótipo funcional da Fase 2 validado localmente em stack Docker. O backend já executa autenticação, criação de alerta vermelho, idempotência por microárea, publicação no broker e confirmação de recebimento pelo ACS. Integrações de produção com MQTT autenticado, identidade e deploy operacional ainda não estão concluídas.
- App do paciente com acesso inicial, triagem estruturada e status da solicitação.
- App ACS com login institucional demonstrativo, painel de priorização, territorialização e registro local de visitas.
- Motor de triagem determinístico, com classificação verde, amarela ou vermelha.
- Fila de visitas offline com sincronização simulada, retry e detecção de conflitos.
- Backend com fluxo real de alerta vermelho, incluindo autenticação, idempotência, publicação em tópico de microárea e ACK do ACS.
- Contrato de alerta MQTT com configuração TLS/WSS e validação local do ciclo de entrega.
- Persistência local preparada para SQLCipher.
Consulte PROGRESS.md para o status detalhado dos milestones e spec/PRD_system.md para requisitos e decisões técnicas.
apps/
acs/ Aplicativo Flutter do Agente Comunitário de Saúde
patient/ Aplicativo Flutter do paciente
admin/ Base do aplicativo administrativo
backend/ Backend Dart (dart:io, sem framework) e regras de domínio
infra/ Configuração local de infraestrutura
spec/ PRD, UX, privacidade e fluxos do produto
tests/ Testes compartilhados
- Flutter SDK compatível com Dart
>=3.3.0 <4.0.0. - Android SDK com API 36 e JDK 17 para gerar ou executar o app ACS no Android.
- Docker Engine com Docker Compose v2 para subir a stack local.
- Um emulador Android ou dispositivo físico, opcional para execução mobile.
As versões usadas pela CI estão definidas em .github/workflows/ci.yml.
Na raiz do repositório, suba PostgreSQL, Mosquitto, backend e Traefik:
docker compose up --buildServiços expostos no ambiente local:
| Serviço | Endereço |
|---|---|
| Traefik | http://localhost |
| Dashboard Traefik (inseguro, somente desenvolvimento) | http://localhost:8081 |
| Backend | http://localhost:8080 |
| PostgreSQL | localhost:5432 |
| Mosquitto MQTT | localhost:1883 |
| Mosquitto WebSocket | localhost:9001 |
Para encerrar a stack:
docker compose downO Compose atual usa credenciais de desenvolvimento declaradas no docker-compose.yml. Não reutilize essas credenciais nem habilite o dashboard inseguro do Traefik em ambientes públicos.
cd apps/acs
flutter pub get
flutter runPara selecionar explicitamente um emulador Android disponível:
flutter devices
flutter run -d <device-id>cd apps/patient
flutter pub get
flutter runO app ACS foi validado com compileSdk e targetSdk 36. Para gerar o APK:
cd apps/acs
flutter clean
flutter pub get
flutter build apk --debugO artefato é criado em:
apps/acs/build/app/outputs/flutter-apk/app-debug.apk
O mesmo procedimento pode ser aplicado ao app do paciente, substituindo
apps/acs por apps/patient.
A configuração Android atual assina builds de release com a chave de debug,
adequada apenas para testes internos. Antes de qualquer distribuição, defina
um applicationId próprio, configure assinatura de release e forneça os
segredos por variáveis de ambiente ou um cofre de segredos.
Execute cada conjunto a partir do respectivo diretório:
cd backend && dart pub get && dart analyze
cd backend/sinalacs_server && dart test
cd apps/acs && flutter pub get && flutter analyze && flutter test
cd apps/patient && flutter pub get && flutter analyze && flutter testO backend é um workspace Dart com dois pacotes: sinalacs_server (servidor
Serverpod) e sinalacs_client (cliente tipado gerado). A suíte tem 25 testes —
16 unitários herméticos, que não precisam de banco, e 9 de integração sobre o
harness do Serverpod, que exigem um Postgres em localhost:9090 conforme
sinalacs_server/config/test.yaml. Para rodar só os herméticos:
dart test test/unit.
A última validação local cobriu o ciclo crítico ponta a ponta em stack Docker —
autenticação, idempotência, publicação no broker e ACK do ACS. A CI
(.github/workflows/ci.yml) roda quatro jobs em pushes para main e pull
requests: serverpod-backend (sobe o Postgres de teste e roda dart analyze
mais a suíte completa), backend-docker-build (valida que a imagem builda),
patient-app e acs-app.
Configuração de servidor e banco vem dos arquivos sinalacs_server/config/*.yaml
e pode ser sobrescrita por variáveis de ambiente: SERVERPOD_DATABASE_HOST e
companhia, SERVERPOD_APPLY_MIGRATIONS (aplica as migrações no boot),
SERVERPOD_REDIS_ENABLED (Redis é opcional e fica desligado) e
SERVERPOD_INSIGHTS_SERVER_PORT. O MQTT não faz parte do Serverpod e mantém as
próprias variáveis, lidas por sinalacs_server/lib/src/config/app_config.dart:
MQTT_BROKER/MQTT_USERNAME/MQTT_PASSWORD/MQTT_USE_TLS, mais JWT_SECRET,
APP_ENV (production exige JWT_SECRET, falhando rápido no boot) e
ENABLE_DEV_LOGIN (por padrão desligado — sem ele, auth.developmentLogin
falha como se o endpoint não existisse). Veja
backend/DEPLOY.md para o runbook completo do piloto de
deploy free-tier.
Não há deploy de produção implementado neste momento. O arquivo docker-compose.yml é destinado ao desenvolvimento local; ele não oferece TLS público, gestão de segredos, persistência operacional, observabilidade, backup ou políticas de acesso compatíveis com produção.
Existe um caminho de piloto/demo em serviços free-tier para o backend, documentado em backend/DEPLOY.md. Esse caminho é propositalmente barato e simplificado para demonstração — ele não substitui nenhum dos requisitos de produção do PRD listados abaixo.
O caminho previsto no PRD para produção inclui:
- Provisionamento imutável com Pulumi.
- PostgreSQL, Mosquitto e Traefik com redes privadas, TLS 1.3 e segredos fora do repositório.
- ACLs MQTT, autenticação institucional e RBAC por microárea.
- Observabilidade com OpenTelemetry, Prometheus e Grafana.
- Revisão de LGPD, auditoria e política de retenção antes de qualquer piloto.
Os critérios completos estão em spec/PRD_system.md e o desenho de privacidade em spec/lgpd_design.md.
O projeto lida com dados de saúde. Não inclua dados reais de pacientes em testes, logs, capturas de tela ou configurações de desenvolvimento. A classificação de risco é determinística e alertas vermelhos não devem ser descartados silenciosamente. As garantias de autenticação, autorização por microárea e entrega MQTT com ACK permanecem pendentes de integração real.
Consulte LICENSE.