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/Serverpod 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 && dart test
cd apps/acs && flutter pub get && flutter analyze && flutter test
cd apps/patient && flutter pub get && flutter analyze && flutter testA última validação local aprovou a suíte do backend e testes específicos de integração HTTP do alerta vermelho, cobrindo autenticação, idempotência, publicação no broker e ACK do ACS. A CI executa análise e testes para backend, paciente e ACS em pushes para main e pull requests.
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.