Ir para o conteúdo

Anotae

Documento Técnico Consolidado do Projeto

Versão: 1.0
Data: 29 de abril de 2026
Classificação: Público
Documento: Apresentação técnica e institucional para gestores e equipes de desenvolvimento

Autor principal: Carlos E. F. de Ávila, MD, MBA
Organização: Sciereli HDC
Repositório: https://github.com/anotae/anotae
Site: https://anot.ae
Licença: GNU Affero General Public License v3.0 ou posterior (AGPL-3.0-or-later)

Aviso de uso

Este documento descreve o projeto Anotae em sua fase pré-alfa de desenvolvimento. Todas as decisões arquiteturais, cronogramas e estimativas aqui apresentadas são baseadas em pesquisa profunda validada e estão sujeitas a refinamento conforme o projeto evolui pela governança comunitária.

Para informações sempre atualizadas, consulte os documentos vivos no repositório oficial:

  • README.md — visão geral
  • DESIGN.md — arquitetura e decisões técnicas
  • BACKLOG.md — roadmap detalhado
  • THREAT-MODEL.md — modelo de ameaças
  • PRIVACY-IMPACT-ASSESSMENT.md — RIPD/LGPD

Sumário

  1. Sumário Executivo
  2. O Problema que Anotae Resolve
  3. A Proposta de Valor
  4. Princípios Fundacionais
  5. Visão Geral do Produto
  6. Arquitetura Técnica
  7. Modelo de Dados
  8. Modelo de Criptografia
  9. Compliance Regulatório
  10. Modelo de Ameaças e Privacidade
  11. Roadmap e Cronograma
  12. Modelo de Sustentação Financeira
  13. Governança e Comunidade
  14. Identidade Visual e Marca
  15. Stack Tecnológica e Justificativas
  16. Riscos e Mitigações
  17. Casos de Uso e Cenários
  18. Métricas de Sucesso
  19. Conclusões e Próximos Passos
  20. Anexos

1. Sumário Executivo

O que é Anotae

Anotae é uma ferramenta desktop open-source 100% local para profissionais de saúde do Sistema Único de Saúde brasileiro (SUS). Permite ao profissional escrever um atendimento clínico uma única vez em editor estruturado e injetar automaticamente os dados em sistemas oficiais (e-SUS APS PEC, SISREG III) via extensão de navegador, eliminando o retrabalho de digitação repetitiva.

O problema

Profissionais SUS perdem entre 30% e 50% do tempo de consulta com digitação redundante em múltiplos sistemas. Esse retrabalho:

  • Compromete a qualidade do registro clínico (cansaço, copy-paste sem revisão)
  • Aumenta erros de transcrição
  • Eleva o risco de não-conformidade com a Resolução CFM 1.821/2007
  • Contribui significativamente para o burnout profissional documentado em estudos brasileiros recentes
  • Afeta tempo disponível para escuta clínica efetiva

A solução

Anotae resolve esse problema sem comprometer privacidade, soberania de dados, ou autonomia profissional:

  • 100% local: Dados nunca saem do dispositivo do profissional
  • Open source: Código auditável, AGPL-3.0
  • Privacy by design: Cifragem at-rest com algoritmos modernos
  • Comunitário: Governança aberta, sem aprisionamento corporativo
  • Acessível: Hardware modesto, sem dependência de internet
  • Regulatoriamente alinhado: LGPD, CFM 1.821/2007, CFM 2.454/2026, ANVISA

Status atual

  • Fase: Pré-alfa (Q2/2026)
  • Roadmap até v1.0 GA: 6–9 meses (com financiamento)
  • Identidade: Definida (nome, domínio, marca, posicionamento)
  • Arquitetura: Decidida e validada por pesquisa profunda
  • Pendências: Implementação inicial, captação de financiamento, formação de comunidade

Pedido institucional

Este documento serve como base para:

  1. Apresentação a gestores SUS que possam adotar institucionalmente
  2. Captação de financiamento (NLnet, MCTI/Finep, Sovereign Tech Fund, GitHub Sponsors)
  3. Recrutamento de contribuidores (desenvolvedores, designers, profissionais de saúde)
  4. Discussão acadêmica (apresentações em SBIS, AMIA, conferências de informática em saúde)

2. O Problema que Anotae Resolve

2.1 Diagnóstico do problema

A informatização do SUS através do e-SUS APS, SISREG III, e demais sistemas representou avanço inquestionável na capacidade de gestão e registro. Porém, gerou efeito colateral conhecido em informática em saúde: fragmentação de pontos de entrada de dados.

Em uma consulta típica de atenção primária, o profissional pode precisar inserir os mesmos dados clínicos em:

  1. e-SUS APS PEC — registro oficial do atendimento (CFM 1.821/2007)
  2. SISREG III — solicitações de regulação para especialistas/exames
  3. Planilhas estatísticas — produção mensal para gestão
  4. Sistemas estaduais — onde existirem (SES-DF, SES-SP, etc)
  5. Sistemas municipais — quando aplicável
  6. Notas pessoais/registros locais — para acompanhamento próprio

Cada sistema tem interface, fluxo, e estrutura própria. A digitação repetida não é apenas desperdício de tempo — degrada a qualidade do registro à medida que o profissional cansa, encurta ou copia-cola sem revisão.

2.2 Quantificação

Estudos brasileiros e internacionais documentam o problema:

  • Tempo de digitação documentado: 30–50% do tempo de consulta (varia conforme complexidade)
  • Burnout em médicos brasileiros: 25–60% com sintomas significativos (varia por especialidade e contexto)
  • Erros de transcrição: 5–15% em sistemas com múltiplas entradas manuais sem integração
  • Retenção de profissionais SUS: afetada negativamente pelo peso administrativo

2.3 Por que soluções existentes não resolvem

Sistemas comerciais de "scribe AI" (Nuance DAX, Abridge, Suki)

  • ❌ Cloud-only: dados clínicos saem do dispositivo
  • ❌ Inadequação LGPD: transferência internacional de dados sensíveis
  • ❌ Custo proibitivo: modelos SaaS cobram por usuário/mês incompatíveis com orçamento SUS
  • ❌ Integração ausente com SUS: sem mapeamentos para e-SUS APS, SISREG
  • ❌ Aprisionamento (vendor lock-in): dados ficam refém do fornecedor

Soluções de RPA (Robotic Process Automation)

  • ❌ Fragilidade: quebram com qualquer mudança de UI dos sistemas-alvo
  • ❌ Caráter "cinza" regulatório: automação não-autorizada de sistemas oficiais
  • ❌ Custo de manutenção: alto, require especialistas

Macros do navegador (extensões genéricas)

  • ❌ Sem persistência local: não são vault de atendimentos
  • ❌ Sem template estruturado: apenas substituições simples
  • ❌ Sem compliance: desenhados para uso geral, sem LGPD-by-design

Solução de prontuário próprio (PEP local)

  • ❌ Substitui em vez de complementar: profissional ainda precisa duplicar no e-SUS oficial
  • ❌ Custo de homologação: SBIS NGS2 caro
  • ❌ Adoção institucional difícil: UBS já usa e-SUS

2.4 A lacuna que Anotae preenche

Existe uma lacuna não atendida: uma ferramenta auxiliar que não substitui o prontuário oficial, é totalmente local, open source, gratuita, e arquitetada para o SUS brasileiro especificamente.

Anotae é projetado para essa lacuna.

3. A Proposta de Valor

3.1 Para o profissional usuário

Antes (sem Anotae) Depois (com Anotae)
Digita o mesmo atendimento em 3-5 sistemas Digita uma vez, sistema injeta nos outros
30-50% do tempo em digitação <10% do tempo em digitação
Risco de erro por fadiga e copy-paste Validação automática + revisão única
Sem registro pessoal estruturado Vault local cifrado, próprio, pesquisável
Dependência da nuvem do empregador Independência: dados são seus
Burnout aumentado Tempo disponível para escuta e cuidado

3.2 Para a instituição (UBS, hospital, secretaria)

Antes Depois
Profissionais sobrecarregados Profissionais com mais tempo clínico
Dados fragmentados em múltiplos sistemas Mesmos dados, mas inseridos consistentemente
Risco LGPD por uso de soluções cloud externas Solução 100% local sob controle institucional
Adoção de soluções comerciais com lock-in Software open source auditável
Custos altos de licença SaaS Zero custo de licença

3.3 Para o SUS como sistema

Antes Depois
Tecnologia clínica dependente de fornecedores estrangeiros Soberania tecnológica nacional
Risco de vazamento de dados em soluções cloud Privacidade by design, dados ficam no Brasil
Inovação cativa de orçamentos institucionais Inovação comunitária financiada por mecanismos diversos
Fork-able apenas em teoria Fork-able na prática via AGPL

3.4 Para a saúde digital brasileira como ecossistema

  • Demonstração de viabilidade de soluções de saúde digital open source de qualidade
  • Modelo replicável para outras necessidades do SUS
  • Capacitação de desenvolvedores brasileiros em saúde digital
  • Caso de estudo internacional sobre soberania de dados em saúde

4. Princípios Fundacionais

Estes são os pilares inegociáveis do projeto. Mudá-los exigiria refundar o projeto com nome diferente.

4.1 Local-first, sempre

Dados clínicos jamais saem do dispositivo do profissional. Sem exceção. Não há "modo cloud", "sync", "backup remoto" oficial. Backups são responsabilidade do usuário, em mídia que ele controla.

Implicação prática: Anotae nunca terá um servidor de produção operado pela equipe do projeto. Não há custo de infraestrutura de servidor recorrente.

4.2 Privacy by design e by default

A configuração padrão é a mais privada possível. Toda feature que reduz privacidade é opt-in com avisos claros. Não existe "anonimização opcional" — o padrão é não-coletar.

4.3 Ferramenta auxiliar, não substituta

Anotae é auxiliar de digitação. O prontuário oficial (e-SUS APS PEC, sistemas próprios) continua sendo o registro autêntico e juridicamente vinculante. Anotae não pretende ser PEP nem dispositivo médico (SaMD).

Implicação regulatória: evita o caro e demorado processo de homologação SBIS NGS2 e registro ANVISA SaMD na v1.0, permitindo lançamento mais rápido. Reavaliação contínua para versões futuras.

4.4 Profissional no controle

Toda automação é revisada pelo humano antes de ter efeito legal/clínico. IA local é opt-in. Templates são personalizáveis. Mapeamentos são auditáveis.

4.5 Open source com governança comunitária

AGPL-3.0-or-later. Forks bem-vindos. Decisões via RFC pública. DCO (não CLA) preservando autonomia de contribuidores.

4.6 Brasileiro de origem, lusófono de coração

Nasceu para o SUS, mas arquitetado para internacionalização (v4.0+). Contextualizado em LGPD/CFM/ANVISA, mas portável conceitualmente para outros países lusófonos (PALOPs).

5. Visão Geral do Produto

5.1 Como funciona — fluxo principal

1. Profissional abre Anotae no laptop
2. Digita o atendimento em editor com template SOAP estruturado
   • Subjetivo: queixa, história, antecedentes
   • Objetivo: exame físico, sinais vitais
   • Avaliação: diagnósticos (CID-10, CIAP-2)
   • Plano: conduta, prescrição, orientações
3. Anotae salva o atendimento em vault local cifrado
4. Profissional abre o navegador no e-SUS APS PEC
5. Clica no ícone da extensão Anotae
6. Seleciona o atendimento que acabou de criar
7. Clica em "Injetar"
8. Anotae preenche automaticamente os campos do e-SUS APS
9. Profissional revisa rapidamente e clica "Salvar" no e-SUS
10. (Opcional) Repete passos 4-9 para SISREG, planilhas, etc

5.2 Componentes principais

App Desktop (Anotae)

  • Interface gráfica em PySide6 (Qt 6)
  • Editor estruturado de atendimentos
  • Vault local SQLite cifrado
  • Templates personalizáveis
  • Mapeamentos para sistemas-alvo
  • Funções de export (XLSX, PDF, JSON)

Extensão de Navegador

  • Manifest V3 (Chrome, Edge, Firefox)
  • Comunicação segura com app desktop (Native Messaging)
  • Engine de mapeamento adaptativo
  • Indicadores visuais de injeção em progresso
  • Permissões mínimas

IA Local Opcional (v2.0+)

  • LLM via llama.cpp para sumarização
  • ASR via whisper.cpp para transcrição (v3.0+)
  • 100% local, opt-in, com disclaimers CFM 2.454

5.3 Limites e não-objetivos

Anotae nunca fará:

  • ❌ Sincronização cloud / SaaS
  • ❌ Telemetria não-anonimizada
  • ❌ Auto-prescrição ou auto-diagnóstico
  • ❌ Substituir o prontuário oficial
  • ❌ Dependência de servidores remotos
  • ❌ Modelos de IA proprietários ou em cloud
  • ❌ Coleta de dados clínicos para treinamento

Estas restrições são fundacionais e protegidas pela governança.

6. Arquitetura Técnica

6.1 Visão geral arquitetural

Anotae é construído sobre arquitetura local-first com componentes claramente desacoplados:

DISPOSITIVO DO PROFISSIONAL
│
├── App Desktop Anotae (Python + PySide6)
│   ├── Camada de UI (Views — PySide6 widgets)
│   ├── Camada de ViewModels (lógica de apresentação, testável)
│   ├── Camada de domínio (Encounter, Template, Mapping)
│   ├── Camada de persistência (SQLite + sqlite3mc)
│   ├── Native Messaging Host (comunicação com extensão)
│   └── Módulos opcionais: LLM (v2.0+), ASR (v3.0+)
│
└── Extensão de Navegador (Manifest V3 + TypeScript)
    ├── Background script (orquestração)
    ├── Content scripts (injeção em formulários)
    ├── Popup UI (controle de ações)
    └── NMH client (comunicação com app desktop)

6.2 Padrões arquiteturais

MVVM (Model-View-ViewModel) na camada de UI permite: - Testes unitários sem GUI - Substituição futura de PySide6 por outro toolkit (Slint, Tauri) - Separação clara de concerns

Repository Pattern na camada de persistência: - Abstração sobre SQLite - Permite mock em testes - Facilita migração futura se necessário

Hexagonal Architecture (ports & adapters) no domínio: - Lógica de negócio independente de frameworks - Adapters específicos para sistemas-alvo (e-SUS, SISREG)

6.3 Comunicação entre componentes

Primário: Native Messaging Host (NMH)

NMH é o método preferencial porque:

  • Comunicação stdio entre app e extensão
  • Não expõe portas de rede
  • Validação de origem pelo navegador
  • Suportado nativamente por Chrome, Edge, Firefox

Manifesto NMH instalado em: - Chrome/Chromium: ~/.config/google-chrome/NativeMessagingHosts/ae.anot.anotae.json - Edge: ~/.config/microsoft-edge/NativeMessagingHosts/ae.anot.anotae.json - Firefox: ~/.mozilla/native-messaging-hosts/ae.anot.anotae.json - Windows: registro em HKCU\Software\...\NativeMessagingHosts

Fallback: HTTP loopback com token efêmero

Quando NMH não está disponível (cenários edge: instalação corporate restritiva):

  • App escuta em 127.0.0.1:porta_aleatoria
  • Token efêmero gerado por sessão (32 bytes random)
  • Cada request da extensão inclui Bearer token
  • App valida token + origin header

Restrições do fallback: - Bind apenas em 127.0.0.1 (nunca 0.0.0.0) - Porta randomizada por sessão - Token rotaciona a cada N minutos

6.4 Schema de mensagens versionado

// extension/shared/protocol.ts

export type Message =
  | { v: 1; type: "ping" }
  | { v: 1; type: "request_encounters"; filter?: EncounterFilter }
  | { v: 1; type: "encounter_payload"; encounter_id: string; mapping_id: string }
  | { v: 1; type: "injection_complete"; encounter_id: string; success: boolean }
  | { v: 1; type: "error"; code: string; message: string };

Validação rigorosa com Pydantic (Python) e Zod (TypeScript) nos boundaries.

7. Modelo de Dados

7.1 Entidades principais

Encounter (atendimento)

{
  "id": "ulid",                     # ULID (ordenável por tempo)
  "created_at": "datetime",
  "updated_at": "datetime",
  "professional_cns": "string",     # CNS do profissional
  "professional_cpf": "encrypted",  # CPF cifrado em campo separado
  "professional_role": "enum",      # MFC, GO, PED, ENF, etc
  "patient_id_local": "string",     # ID interno
  "encounter_date": "date",
  "encounter_type": "enum",         # primeira, retorno, urgência
  "soap": {
    "subjective": "text",
    "objective": "text",
    "assessment": "text",
    "plan": "text"
  },
  "ciap2_codes": ["A01", ...],
  "cid10_codes": ["E11.9", ...],
  "procedures": ["..."],            # Códigos SIGTAP
  "medications": ["..."],
  "metadata": {
    "ai_assisted": false,           # CFM 2.454
    "ai_model_used": null,
    "audio_captured": false,
    "template_used": "mfc-padrao"
  }
}

Template

{
  "id": "ulid",
  "name": "MFC - Atendimento padrão",
  "specialty": "mfc",
  "version": "1.0.0",
  "schema": { /* JSON schema */ },
  "fields": [ /* lista ordenada */ ],
  "default_values": { /* valores default */ }
}

Mapping (mapeamento para sistema-alvo)

{
  "id": "ulid",
  "name": "e-SUS APS PEC - Atendimento Individual",
  "target_system": "esus-aps-pec",
  "target_version": "5.x",
  "version": "1.2.0",
  "fields": [
    {
      "source": "soap.subjective",
      "target_selectors": [
        {"type": "id", "value": "subjetivo"},
        {"type": "label", "value": "Subjetivo"},
        {"type": "aria-label", "value": "Subjetivo"}
      ],
      "transform": null,
      "validation": "required"
    }
  ]
}

7.2 Schema SQL principal

CREATE TABLE encounters (
  id TEXT PRIMARY KEY,                    -- ULID
  created_at TEXT NOT NULL,
  updated_at TEXT NOT NULL,
  professional_cns TEXT NOT NULL,
  professional_cpf_encrypted BLOB,
  professional_role TEXT NOT NULL,
  patient_id_local TEXT NOT NULL,
  encounter_date TEXT NOT NULL,
  encounter_type TEXT NOT NULL,
  soap_subjective TEXT,
  soap_objective TEXT,
  soap_assessment TEXT,
  soap_plan TEXT,
  ciap2_codes TEXT,                       -- JSON array
  cid10_codes TEXT,                       -- JSON array
  procedures TEXT,                        -- JSON array
  medications TEXT,                       -- JSON array
  metadata TEXT NOT NULL,                 -- JSON object
  audit_log TEXT DEFAULT '[]',
  hash_sha256 TEXT NOT NULL               -- detecção de tampering
);

CREATE INDEX idx_encounters_date ON encounters(encounter_date);
CREATE INDEX idx_encounters_patient ON encounters(patient_id_local);

7.3 Vocabulários integrados

Vocabulário Origem Atualização
CIAP-2 WICC/WONCA Estável (versão 2 atual)
CID-10 OMS Estável (transição CID-11 em curso)
SIGTAP DATASUS Mensal
RENAME Ministério da Saúde Bienal
RENASES Ministério da Saúde Bienal

Atualizações de vocabulários são distribuídas via canal seguro (assinatura PGP) e podem ser aplicadas pelo usuário sem reinstalar o app.

7.4 Modelagem FHIR-shaped

Embora Anotae não seja servidor FHIR, o modelo de dados interno é FHIR-shaped com convenções BR-Core:

  • Encounter ≈ FHIR Encounter resource
  • Patient ID ≈ FHIR Patient identifier (local)
  • Practitioner CNS ≈ FHIR Practitioner identifier
  • Observation/Procedure ≈ FHIR resources correspondentes

Isso facilita futura integração com RNDS (Rede Nacional de Dados em Saúde) se feature for desejada pela comunidade.

8. Modelo de Criptografia

8.1 Camadas de proteção

Anotae implementa defesa em profundidade com múltiplas camadas de proteção:

Camada 1 — Sistema de arquivos do OS (responsabilidade do usuário) - BitLocker (Windows), FileVault (macOS), dm-crypt (Linux)

Camada 2 — Vault SQLite criptografado (sqlite3mc) - Cifra: ChaCha20-Poly1305 AEAD - Page-level encryption - Chave derivada de senha-mestra via Argon2id

Camada 3 — Campos sensíveis criptografados (PII) - CPF, CNS de pacientes em campos BLOB cifrados - Cifra adicional com chave derivada distinta

Camada 4 — Hash de integridade - SHA-256 do conteúdo do Encounter - Detecta tampering pós-fato - Audit log assinado (futuro: HMAC)

8.2 Derivação de chave

Senha-mestra (input usuário)
      ↓
Argon2id (m=64MiB, t=3, p=1, salt=32 bytes random)
      ↓
Master Key (32 bytes)
      ↓
HKDF-SHA256
      ├─→ Vault Encryption Key (chave do sqlite3mc)
      ├─→ Field Encryption Key (PII em campos)
      └─→ Audit MAC Key

Parâmetros adaptativos: - Default em hardware moderno (8GB+ RAM): m=64MiB t=3 p=1 (RFC 9106) - Fallback em hardware modesto detectado: m=19MiB t=2 p=1 - Salt único por instalação, gerado por secrets.token_bytes(32)

8.3 Por que sqlite3mc (e não SQLCipher)

Critério sqlite3mc SQLCipher
Licença MIT (totalmente open) BSD-3-Clause + commercial
Cifra moderna ChaCha20-Poly1305 (AEAD) AES-256-CBC (não AEAD)
Build Wheel Python simples Mais complexo
Manutenção Ativa (utelle) Ativa (Zetetic)
Performance Comparável Comparável

A escolha por sqlite3mc se justifica pela autenticação criptográfica nativa (AEAD) e licença permissiva sem dependência de empresa única.

8.4 Memória

  • Senha-mestra é mantida em memória apenas durante derivação
  • Master Key é mantida durante a sessão (necessário para escrever no vault)
  • Após bloqueio (timeout ou logout): secure_zero na chave (best-effort em Python)

8.5 Backup

  • Backup automático diário (configurável)
  • Arquivos de backup são vault completos cifrados (não decrypted)
  • Restauração requer senha-mestra original
  • Versioning de backups: últimos N (default 7)

8.6 Assinatura digital ICP-Brasil (v2.0+)

A partir da v2.0, Anotae suportará assinatura digital de atendimentos exportados via:

  • Padrão: PAdES (PDF Advanced Electronic Signatures)
  • Biblioteca: pyHanko (open source, MIT)
  • Suporte a tokens A3 (smartcard) e certificados A1 (arquivo)
  • Validação de cadeia ICP-Brasil
  • Timestamps RFC 3161 opcionais

Isso permite uso pleno em ambiente CFM-NGS2 quando institucionalmente requerido.

9. Compliance Regulatório

9.1 LGPD (Lei 13.709/2018)

Anotae aplica todos os princípios da LGPD na arquitetura:

Princípio Aplicação
Finalidade Cada dado tem propósito explícito documentado
Adequação Dados compatíveis com finalidades clínicas
Necessidade Apenas dados necessários (sem coleta automática)
Livre acesso Profissional tem acesso total no próprio vault
Qualidade Profissional controla acurácia, audit log permite correção
Transparência Código aberto, RIPD público, sem telemetria escondida
Segurança Cifragem AEAD, KDF Argon2id, threat modeling
Prevenção Disclosure responsável, atualizações automáticas
Não-discriminação Software não toma decisões automatizadas
Responsabilização Audit log local, RIPD versionado, transparência

Importante para LGPD: Anotae como ferramenta = operador técnico potencial, mas como roda 100% local no dispositivo do controlador, o desenvolvedor não tem acesso aos dados. O controlador é o profissional/instituição que usa o software.

9.2 CFM 1.821/2007 — Prontuário eletrônico

Anotae é auxiliar de digitação, não prontuário oficial. Arquitetura é compatível com NGS1 desde dia 1, e NGS2-ready a partir da v2.0 (assinatura ICP-Brasil).

9.3 CFM 2.454/2026 — IA em medicina

Compliance day-zero na v3.0+:

  • Registro de uso de IA em metadata do encounter (ai_assisted: true, ai_model_used: "...")
  • Disclaimer obrigatório ao paciente quando IA for usada
  • Profissional retém responsabilidade — IA nunca decide autonomamente
  • Consentimento informado documentado em audit log

9.4 ANVISA RDC 657/2022 — SaMD

Anotae NÃO é Software as a Medical Device. Análise jurídica:

  • Não fornece informações para decisão diagnóstica/terapêutica
  • É auxiliar de digitação (equivalente a editor de texto especializado)
  • Não interpreta dados clínicos para gerar recomendações
  • Profissional sempre revisa antes de qualquer ação

Reavaliação contínua: se feature futura cruzar a linha de SaMD, re-classifica.

9.5 Marco regulatório consolidado

Norma Aplicação ao Anotae Status
LGPD (Lei 13.709/2018) Privacy by design ✅ Aplicado desde v0.1
CFM 1.821/2007 Auxiliar de prontuário ✅ Compatível NGS1
CFM 2.454/2026 IA em medicina ✅ Day-zero v3.0+
ANVISA RDC 657/2022 SaMD ❌ Não aplicável
Lei 12.527/2011 (LAI) Software open source ✅ Total transparência
Marco Civil da Internet (Lei 12.965/2014) Não aplicável (offline) N/A
ECA (Lei 8.069/1990) Adolescentes em populações vulneráveis ✅ Considerações especiais v3.0+

10. Modelo de Ameaças e Privacidade

10.1 Análise STRIDE resumida

Categoria Ameaça principal Mitigação Anotae
Spoofing Extensão maliciosa se passa pelo NMH legítimo Native Messaging Host com manifesto restrito por extension ID; fallback HTTP loopback com token efêmero rotacionado por sessão
Tampering Adulteração silenciosa de registro clínico Audit log append-only com hash chain + HMAC por linha (prev_hash + entry_mac, Migration 007, verificável via verify_chain); hash SHA-256 de encounter verificado na leitura (IntegrityError em divergência); field-level AEAD em colunas clínicas (Migration 010)
Repudiation Profissional nega ter feito determinado registro Audit log timestamped (TSA opcional v2.0); assinatura ICP-Brasil PAdES opt-in
Information Disclosure Vazamento de dados clínicos Cifragem em repouso ChaCha20-Poly1305 + KDF Argon2id; sem rede externa em hipótese alguma; redação de logs
Denial of Service App travado impede atendimento Modo degradado offline + recovery automático; encounter draft persistido a cada keystroke
Elevation of Privilege Extensão obtém capacidades além do escopo Manifest V3 com permissões mínimas; CSP estrito; sem eval(); revisão de cada permissão nova em RFC

10.2 Análise LINDDUN (privacidade)

Categoria Ameaça Mitigação
Linkability Dados de paciente conectáveis entre encounters Apenas pseudo-ID local (UUID interno), sem cross-correlation externa
Identifiability Re-identificação de dados "anonimizados" Modo Forte usa supressão + generalização; profissional consciente de risco residual
Non-repudiation Profissional não pode negar autoria (Aceita como feature, não bug — registro clínico exige autoria)
Detectability Adversário detecta presença de dado sensível Cifragem AEAD oculta tanto conteúdo quanto comprimento aproximado
Disclosure of information Vazamento ativo Sem servidor; sem telemetria; sem cloud sync
Unawareness Usuário não sabe o que foi coletado Audit log local sempre visível ao usuário; RIPD público
Non-compliance Software viola LGPD RIPD versionado; auditoria via código aberto; DPO de referência

10.3 Adversários considerados

Em escopo:

  • Adversário com acesso físico temporário ao laptop (roubo, descuido em mesa de UBS)
  • Malware no SO do usuário (info-stealer, ransomware comum)
  • Adversário de rede (extensão maliciosa, MITM em update)
  • Insider malicioso na cadeia de suprimentos (PyPI, npm)
  • Adversário curioso (familiar, colega)

Fora de escopo (assumimos como limitação aceita):

  • Estado-nação com capacidade de comprometer firmware/TPM
  • Adversário com acesso permanente físico irrestrito
  • Coerção física do usuário para revelar senha

10.4 RIPD — Relatório de Impacto à Proteção de Dados

Documento completo em docs/PRIVACY-IMPACT-ASSESSMENT.md. Resumo:

  • Controlador: profissional/instituição que usa Anotae
  • Operador técnico potencial: Sciereli HDC (sem acesso aos dados)
  • Bases legais (Art. 7 e 11 LGPD): consentimento + execução de políticas públicas + tutela da saúde + cumprimento de obrigação legal
  • Categorias de dados: dados pessoais sensíveis (saúde — Art. 5, II)
  • Finalidade: apoio à digitação clínica para reduzir retrabalho e erros
  • Retenção: controlada pelo usuário (sem retenção automática pelo desenvolvedor)
  • Compartilhamento: zero externo (apenas com sistemas SUS pré-autorizados via injeção)
  • Direitos do titular: garantidos via funcionalidade do controlador (export, exclusão)

11. Roadmap e Cronograma

11.1 Visão geral das fases

Versão Foco principal Janela estimada Estado
v0.1 MVP core: editor + extensão + injeção e-SUS APS PEC 4-6 meses pós-início 🟦 Planejamento
v0.5 Extensão SISREG III + audit log polido +3 meses 🟦 Planejamento
v1.0 Estável: vault encryption, multi-OS, packaging robusto +3 meses 🟦 Planejamento
v1.5 Vocabulários (CIAP-2, CID-10, SIGTAP, RENAME) integrados +2 meses 🟦 Planejamento
v2.0 LLM local opt-in (sumarização, expansão de tópicos) +6 meses 🟦 Planejamento
v2.5 Assinatura ICP-Brasil PAdES + NGS2-ready +3 meses 🟦 Planejamento
v3.0 ASR local opt-in (whisper.cpp), modo pós-consulta +6 meses 🟦 Planejamento
v3.5 ASR streaming (modo durante consulta) +3 meses 🟦 Planejamento
v4.0 Interoperabilidade RNDS/FHIR R4 BR-Core +6 meses 🟦 Planejamento
v5.0 Federação SUS (multi-estabelecimento, bioma colaborativo) TBD 🔮 Visão

11.2 v0.1 — MVP detalhado (primeiros 4-6 meses)

Sprint 1-2 (mês 1): Setup - Repositório, CI/CD, brand assets, documentação base - Esqueleto PySide6 com janela principal e roteamento - SQLite com sqlite3mc + Argon2id KDF + testes - Native Messaging Host esqueleto (Chrome + Firefox)

Sprint 3-4 (mês 2): Editor - Editor de encounter com template SOAP estruturado - Persistência criptografada de drafts auto-save - UI de cadastro/auth com senha-mestra

Sprint 5-6 (mês 3): Mapeamento - DSL declarativa de mapeamento (YAML) - Engine de injeção (CSS selectors + ARIA + fallback XPath) - Extensão MV3 com background worker e content script

Sprint 7-8 (mês 4): e-SUS APS PEC - Mapeamentos para os 12 campos principais do PEC - Testes de integração com instância de homologação - Refinamento UX baseado em testes piloto

Sprint 9-12 (meses 5-6): Polimento + alpha release - Audit log básico - Documentação Diátaxis (tutorials + how-to + reference) - Build reproduzível Windows + macOS + Linux - Sigstore attestations + SBOM CycloneDX - Release alpha v0.1.0

11.3 Critérios de release

Versão Critérios obrigatórios
v0.1 alpha Funciona em Windows 10+/macOS 12+/Ubuntu 22.04+; injeção e-SUS APS PEC funcional em homologação; doc tutorial básico; ≥10 testers piloto
v1.0 stable Cobertura testes ≥75%; auditoria externa segurança; documentação completa Diátaxis; ≥100 usuários ativos; bus factor ≥2
v2.0 LLM LLM local validado em hardware modesto (8GB RAM); humano-no-loop obrigatório; documentação ética; opt-in explícito
v3.0 ASR ASR validado em ambiente clínico ruidoso; modo pós-consulta como default; aviso e consentimento em fluxo
v4.0 RNDS Conformidade FHIR BR-Core validada; certificação RNDS (se aplicável e desejável)

12. Modelo de Sustentação Financeira

12.1 Filosofia

Anotae é bem público digital — software de saúde para o SUS. O modelo de sustentação espelha essa natureza: não há propriedade comercial, não há cobrança por uso, não há freemium. O projeto se sustenta por:

  • Contribuição voluntária da comunidade (código, documentação, tradução, design)
  • Financiamento via grants e ladder de patrocínio (sem investidor de risco)
  • Serviços profissionais opcionais prestados por Sciereli HDC (suporte enterprise, consultoria de implantação)

12.2 Funding ladder

Nível 1: Bootstrap (presente)
   └── Tempo voluntário do mantenedor (Carlos)
   └── Sciereli HDC absorve custos infra básica (~R$ 200/mês)

Nível 2: GitHub Sponsors + Open Collective (3-6 meses)
   └── Meta: R$ 2.000-5.000/mês
   └── Permite ~25% do tempo do mantenedor dedicado

Nível 3: NLnet/NGI Zero (6-12 meses) ⭐ TARGET PRINCIPAL
   └── Faixa: €5.000-50.000 por grant
   └── Foco: privacy, data sovereignty (encaixe perfeito)
   └── Leva 4-6 meses do submit ao primeiro pagamento

Nível 4: Sovereign Tech Fund (12-18 meses)
   └── Foco: infra crítica open source
   └── Faixas significativas (€50.000+)

Nível 5: MCTI/Finep + parcerias institucionais (18-24 meses)
   └── Brasil: editais MCTI, Finep, BNDES
   └── Parcerias UnB, UFRGS, USP via convênios

Nível 6: Consórcio multi-estado SUS (24+ meses)
   └── Estados/municípios cofinanciam mantendo open source
   └── Modelo similar SAGES (Itália)

12.3 Custos estimados por fase

Fase Custo mensal estimado Justificativa
Bootstrap (v0.1-v0.5) R$ 200-500 Domínio, infra básica, ferramentas
Crescimento (v1.0-v2.0) R$ 5.000-10.000 1 dev part-time + infra + brand
Consolidação (v3.0+) R$ 15.000-30.000 2 devs + designer part-time + suporte comunidade

12.4 Fontes de receita opcionais (Sciereli HDC)

Sciereli HDC pode oferecer serviços profissionais que NÃO comprometem o caráter open source do Anotae:

  • Suporte enterprise para hospitais/secretarias com SLA
  • Consultoria de implantação (treinamento, customização de mapeamentos)
  • Auditoria de segurança e compliance específica
  • Desenvolvimento de extensões customizadas mantidas internamente pela instituição
  • Workshops e capacitação para equipes IT do setor

Compromisso anti-rent-seeking: funcionalidades core nunca atrás de paywall. Serviços = expertise humano, não software gated.

13. Governança e Comunidade

13.1 Estrutura inicial (BDFL benevolente)

Nas fases iniciais (v0.1 a v1.0), Carlos E. F. de Ávila atua como Benevolent Dictator for Life (BDFL) com decisão final em:

  • Direção arquitetural e roadmap
  • Aceitação de PRs em módulos críticos (criptografia, persistência)
  • Aplicação do Code of Conduct
  • Brand assets e identidade

13.2 Transição planejada

A partir de v2.0 (estimado 18-24 meses), a governança transiciona para modelo comunitário:

  • Steering Committee com 3-5 mantenedores eleitos
  • Working Groups específicos (segurança, design, vocabulários, documentação)
  • RFC process público com período de comentários
  • Decisões por consenso (lazy consensus + votação se necessário)

13.3 Papéis

Papel Responsabilidades Como se torna
Contribuidor Código, doc, testes, design Abrir PR aceito
Triager Triagem de issues, labels, primeira resposta Convite após contribuições consistentes
Mantenedor Review e merge de PRs em sua área Convite por consenso de mantenedores
Steering Committee Decisões estratégicas, roadmap Eleição (pós v2.0)
Security Advisor Resposta a vulnerabilidades, RFCs de segurança Convite por mantenedores

13.4 Diversidade e inclusão

Reconhecemos que comunidades de saúde + tech historicamente sub-representam:

  • Mulheres em posições técnicas
  • Profissionais não-brancos
  • Pessoas com deficiência
  • Usuários de tecnologia assistiva

Compromissos ativos:

  • Code of Conduct (Contributor Covenant 2.1) aplicado consistentemente
  • Documentação acessível (WCAG 2.1 AA mínimo)
  • Comunicação em português brasileiro acessível (não apenas inglês)
  • Mentoria explícita para novos contribuidores
  • Eventos online com gravação e legendas

13.5 Canais comunitários

  • GitHub Discussions — discussões assíncronas, RFCs
  • Codeberg Forum (espelho) — para pessoas que preferem evitar GitHub
  • Matrix room #anotae:matrix.org — chat em tempo real
  • Mailing list anotae@anot.ae — anúncios e discussões longas
  • Eventos: sprints virtuais trimestrais, encontro anual presencial (quando viável)

14. Identidade Visual e Marca

14.1 Conceito da marca

A identidade Anotae é construída em torno de três elementos visuais:

1. Brackets [ ] — referência tripla: - Estrutura clínica padronizada (SOAP: Subjetivo, Objetivo, Avaliação, Plano) - Notação de código (estrutura de dados, programação) - Metáfora visual de "captura" (envolvendo o conteúdo)

O bracket esquerdo é completo (estrutura estabelecida); o direito tem o topo aberto (registro em andamento, capturando).

2. Letra "a" minúscula bold — base do nome "anotae", lowercase deliberado para tom cotidiano (não corporativo nem governamental).

3. Ponto laranja-âmbar — substitui visualmente o topo ausente do bracket direito. Significa "registro feito" — comparable a um commit, save, timestamp.

14.2 Tipografia oficial

IBM Plex Sans Bold é a face tipográfica oficial:

  • Designer: IBM (Mike Abbink + Bold Monday)
  • Licença: SIL Open Font License 1.1 (OFL) — embedding livre
  • Caráter: neogrotesca contemporânea com inflexões humanistas
  • Por que: equilibra peso institucional com leveza técnica; suporta latim estendido completo (todos caracteres pt-BR); IBM (institucional respeitado) sem ser corporativo demais

Variantes utilizadas: Bold (wordmark, headlines), Semibold (subheadings), Medium (body com ênfase), Regular (body padrão), Light (captions). IBM Plex Mono Regular para código.

14.3 Paleta de cores

Cor HEX Uso
Azul Anotae #0F4C81 Wordmark, brackets, primário
Laranja-âmbar #F4A12B Acento (ponto), CTAs de destaque
Azul claro #3A7CA5 Suporte, hover states
Teal alternativo #2A9D8F Sucesso, confirmações
Anotae Dark #1A2433 Texto principal
Anotae Light #FAFBFC Fundo principal

Documentação completa em brand/BRAND-GUIDELINES.md com valores em RGB, HSL, CMYK, Pantone e validação WCAG.

14.4 Aplicações

Os ativos visuais já produzidos cobrem:

  • Logos: símbolo, símbolo monocromático, wordmark, lockup horizontal, lockup vertical, favicon
  • Social: OG image 1200×630 para GitHub e meta tags
  • Desktop: splash screen 800×600 (com versão @2x para HiDPI)
  • Installer: ícone master SVG + PNGs de 16 a 1024px + .ico Windows multi-tamanho
  • Favicons: SVG moderno + PNGs (16, 32, 180, 192, 512) para web e PWA

14.5 Trademark Policy

Anotae é marca comunitária do projeto. Forks são bem-vindos sob AGPL-3.0, mas devem usar nome distinto e logo distinto para evitar confusão. Política completa em TRADEMARK-POLICY.md.

15. Stack Tecnológica

15.1 Visão geral

Camada Tecnologia Licença Justificativa
Linguagem core Python 3.12+ PSF Ecossistema científico/saúde, mypy estrito, dev velocity
UI desktop PySide6 (Qt 6.x) LGPL-3.0 Maturo, multi-OS, A11y nativo, Qt Models reusáveis
Persistência SQLite stdlib + sqlite3mc MIT Embarcado, portátil, AEAD ChaCha20-Poly1305
KDF Argon2id (argon2-cffi) Apache-2.0 Padrão atual recomendado, resistente GPU/ASIC
LLM local llama.cpp + llama-cpp-python MIT CPU-only viável, GGUF padronizado, opt-in
ASR local whisper.cpp MIT CPU-only viável, preciso para PT-BR, opt-in
Empacotamento PyInstaller --onedir GPL com exceção Maturo, multi-OS, build reproduzível
Extensão browser Manifest V3 + TypeScript + Vite MIT/Apache Padrão atual Chrome/Edge, compatível Firefox
CI/CD GitHub Actions + Codeberg Woodpecker MIT Free para open source, espelho independente
SBOM CycloneDX Apache-2.0 Padrão OWASP, integração CI fácil
Attestations Sigstore PEP 740 Apache-2.0 Keyless signing, padrão emergente

15.2 Justificativas-chave

Por que Python e não Rust? - Velocidade de desenvolvimento crucial em projeto bootstrap - Ecossistema saúde (FHIR libs, OCR, LLM bindings) maduro em Python - mypy --strict + bandit + ruff entregam segurança comparable em domínio não-crítico para perf - Componentes de performance (LLM, ASR) são bindings Python para C++ otimizado - Migração futura para Rust possível módulo a módulo se necessário

Por que PySide6 e não Tauri/Electron? - Tauri exigiria stack Rust + JS = curva mais íngreme; ainda imaturo em A11y - Electron = bundle gigante, RAM elevada, problemas A11y conhecidos - PySide6 = 30-50MB instalado, A11y Qt nativo, multi-OS estável

Por que sqlite3mc e não SQLCipher? - Validação por pesquisa profunda: SQLCipher tem AEAD frágil em alguns modos - sqlite3mc com ChaCha20-Poly1305 = AEAD moderno, MIT, manutenção ativa - Integração com sqlite3 stdlib via ctypes — sem dependência runtime extra

Por que AGPL-3.0? - Garante que forks SaaS comerciais devolvam código à comunidade - Compatível com a natureza "bem público digital" - Modelo similar OpenMRS, GNU Health funciona em saúde - Trademark Policy adicional protege identidade

16. Riscos e Mitigações

16.1 Matriz de riscos

Risco Probabilidade Impacto Mitigação
Mudança de DOM em e-SUS PEC quebra mapeamentos Alta Médio DSL declarativa atualizável sem novo release; testes E2E em homologação
Bus factor 1 — mantenedor único Alta no início Alto Documentação extensiva; busca ativa de cofundadores via NLnet/UnB; transição BDFL→community
CFM/ANVISA muda regulação SaMD Média Alto Análise jurídica continuada; revisão semestral de compliance; relacionamento ativo com CFM/SBIS
LLM local consome muito RAM em hardware modesto Média Médio Modelos quantizados (GGUF q4_K_M); detection runtime; opt-in com aviso de hardware
Performance ASR insuficiente em consultório Média Médio whisper.cpp small-pt validado; modo pós-consulta default; opcional streaming v3.5+
Adoption baixa por inércia institucional Alta Alto Foco em valor para profissional individual primeiro; doc tutorial excelente; eventos comunidade
Captura de receita por terceiros (rent-seeking sobre o open core) Média Médio AGPL-3.0 + Trademark Policy; serviços Sciereli HDC explícitos vs core comunitário
Vulnerabilidade crítica não detectada Baixa Crítico Auditoria externa pre-v1.0; bug bounty quando viável; SBOM + Sigstore para supply chain
Funding insuficiente para escalar Média Alto Funding ladder gradual; Sciereli HDC sustenta bootstrap; consultoria opcional
Conflito INPI marca Anotae Baixa Médio Busca INPI já realizada (livre classes 9 e 42); registro pós-MVP

16.2 Risco existencial: dados de paciente vazam

Cenário: Atacante explora vulnerabilidade no Anotae que vaza vault de paciente em produção.

Impacto potencial: - Quebra do princípio fundacional do projeto - Dano irreversível à reputação - Possível investigação ANPD/MPF

Mitigações em camadas:

  1. Prevenção arquitetural — sem rede externa significa que vazamento online via Anotae é impossível por design
  2. Cifragem em repouso — mesmo com acesso ao disco, conteúdo cifrado AEAD
  3. Auditoria contínua — SAST + SCA + dependabot + revisão humana
  4. Auditoria externa — pre-v1.0 financiar pentest profissional
  5. Disclosure responsável — SECURITY.md detalhado, hall of fame
  6. Comunicação preparada — playbook de resposta a incidente documentado pre-v1.0

17. Casos de Uso e Cenários

17.1 Persona principal: Dra. Ana, médica de família UBS Brasília

  • 35 anos, especialista em medicina de família e comunidade
  • Atende 30 pacientes/dia em UBS do GDF
  • Usa e-SUS APS PEC obrigatoriamente, faz regulação no SISREG quando necessário
  • Tempo médio digitação atual: 8-12 minutos por consulta de 15 minutos

Cenário típico (pós-Anotae):

  1. Paciente entra. Dra. Ana abre Anotae, novo encounter, template "Consulta de retorno HAS".
  2. Durante a consulta, anota no Anotae em tempo real (campos estruturados):
  3. Subjetivo: queixa, evolução
  4. Objetivo: PA, peso, exame físico
  5. Avaliação: CIAP-2 K86 + CID-10 I10
  6. Plano: ajuste medicação, exames, retorno
  7. Ao final, clica "Injetar no e-SUS". Anotae abre janela do PEC já aberta no Chrome, extensão preenche os 12 campos automaticamente.
  8. Dra. Ana revisa em 30 segundos, faz pequeno ajuste, salva no PEC.
  9. Tempo total digitação: 2-3 minutos (de 8-12).

Ganho: ~7 minutos por consulta × 30 consultas = 3.5 horas/dia recuperadas.

17.2 Cenário 2: Regulação SISREG

Dr. Bruno, médico regulador. Recebe solicitação de cardiologia. - Abre encounter no Anotae com template "Regulação cardiologia". - Preenche justificativa, prioridade, dados do paciente. - Injeta no SISREG — campos preenchidos, ele apenas confirma. - Audit log local registra a regulação para auditoria interna.

17.3 Cenário 3: Pesquisa epidemiológica

Carlos, médico-pesquisador. Coordena estudo de prevalência de HAS na sua UBS. - Usa Anotae para registros estruturados durante 6 meses. - Exporta dados anonimizados (modo Forte) em CSV/FHIR. - Análise estatística externa em R/Python. - Dados nunca saíram cifrados de seu controle direto.

17.4 Cenário não-suportado (out of scope)

  • ❌ Telemedicina via Anotae (não é vídeo conferência)
  • ❌ Prescrição digital (é prontuário oficial, fica no e-SUS)
  • ❌ Faturamento TISS (sistema separado, integração futura via FHIR)
  • ❌ Atendimento sem profissional de saúde (autodiagnóstico)

18. Métricas de Sucesso

18.1 Métricas de produto

Métrica Baseline Meta v1.0 Meta v3.0
Redução tempo digitação 8-12 min/consulta -50% -70%
Taxa de campos preenchidos automaticamente 0% 80% e-SUS PEC 95% e-SUS + SISREG
Erros transcrição (auto-detectados) N/A -60% vs manual -80% vs manual
Satisfação NPS profissional N/A ≥40 ≥60
Tempo médio adoção (do download ao primeiro uso real) N/A ≤30 min ≤15 min

18.2 Métricas de adoção

Métrica Meta v0.5 Meta v1.0 Meta v3.0
Downloads únicos 100 1.000 10.000
Usuários ativos mensais (MAU) 30 300 3.000
Estabelecimentos com ≥1 usuário 10 100 1.000
Estados representados 3 10 27
Contribuidores GitHub 3 15 50
Stars GitHub 50 500 5.000

18.3 Métricas de comunidade e governança

Métrica Meta v1.0 Meta v3.0
Bus factor ≥2 ≥5
Mantenedores ativos 3-5 8-12
Tempo médio resposta a issue ≤7 dias ≤48h
PRs externos merged/mês 5 30
Cobertura testes ≥75% ≥85%

18.4 Métricas de segurança

Métrica Meta
Tempo médio de patch security crítico ≤7 dias
Vulnerabilidades graves não corrigidas 0 (zero)
Releases com SBOM + Sigstore 100%
Auditoria externa formal 1× por ano (pós-funding)

18.5 Como NÃO medimos sucesso

❌ DAU (Daily Active Users) — pressiona engagement em vez de utilidade
❌ Tempo dentro do app — uso ideal = curto e eficiente
❌ Receita — não é o ponto
❌ Comparação direta com SaaS proprietários (modelos diferentes)

19. Conclusões e Próximos Passos

19.1 O que Anotae representa

Anotae é mais do que ferramenta de produtividade. É:

  • Demonstração de que software de saúde brasileiro pode ser feito com privacy-by-design e sem extração rentista
  • Bem público digital auditável, replicável, evoluível pela comunidade
  • Resposta concreta ao problema documentado de burnout e retrabalho no SUS
  • Caso de uso para advocacy de soberania de dados em saúde
  • Plataforma educacional para formar nova geração de devs em healthtech ética no Brasil

19.2 Próximos passos imediatos

Próximas 2 semanas: - [ ] Setup do repositório GitHub público + espelho Codeberg - [ ] Aplicação dos brand assets nos canais (avatar, OG image, perfil) - [ ] Publicação da proposta v0.3 e desta documentação consolidada - [ ] Anúncio inicial em Twitter/X, LinkedIn, comunidades AMIA/SBIS, listas SUS - [ ] Issue #1: "RFC: governança inicial e processo de contribuição"

Próximo mês: - [ ] Esqueleto de código rodando: PySide6 main window + SQLite + Argon2id KDF - [ ] Setup CI/CD (GitHub Actions com mypy + ruff + pytest + bandit) - [ ] Primeira release v0.0.1-dev (não funcional, apenas confirmando build pipeline) - [ ] Submissão preliminar a NLnet (formulário de interesse) - [ ] Convite a 5-10 profissionais SUS para grupo de feedback inicial

Próximos 3-6 meses (rumo v0.1 alpha): - [ ] MVP editor + extensão + injeção e-SUS APS PEC - [ ] Documentação Diátaxis básica - [ ] Build reproduzível Windows + macOS + Linux - [ ] 10-20 testers piloto ativos - [ ] Submissão formal a NLnet - [ ] Relacionamento institucional UnB (coautoria de paper)

19.3 Compromisso público

Carlos E. F. de Ávila, em nome próprio e da Sciereli HDC, compromete-se publicamente a:

  1. Manter Anotae sempre 100% open source (AGPL-3.0-or-later)
  2. Nunca implementar funcionalidades que comprometam privacidade do paciente ou autonomia do profissional
  3. Não estabelecer modelo de cobrança por uso ou freemium sobre o software
  4. Transicionar para governança comunitária real assim que houver bus factor para suportá-la
  5. Documentar e responder publicamente a quaisquer conflitos de interesse entre Sciereli HDC e o projeto

19.4 Convite

Anotae não é projeto solo. É convite à comunidade brasileira de:

  • Profissionais de saúde dispostos a testar e dar feedback
  • Desenvolvedores que querem contribuir com código, documentação, design
  • Pesquisadores que veem aqui plataforma para estudos
  • Gestores que querem implantar e cofinanciar evolução
  • Entidades (CFM, COREN, SBIS, AMIA, ABRASCO) interessadas em parcerias

Contato: contato@anot.ae (ou via GitHub Issues/Discussions)

20. Anexos

Anexo A — Glossário

Termo Definição
AEAD Authenticated Encryption with Associated Data — cifragem que detecta adulteração
APS Atenção Primária à Saúde
Argon2id Função de derivação de chave (KDF) padrão atual recomendada
BDFL Benevolent Dictator for Life — modelo de governança comum em projetos open source iniciais
CIAP-2 Classificação Internacional de Atenção Primária, segunda edição
CID-10 Classificação Internacional de Doenças, décima revisão
CFM Conselho Federal de Medicina
DCO Developer Certificate of Origin — alternativa leve a CLA
DSL Domain-Specific Language
e-SUS APS PEC Sistema oficial DATASUS para atenção primária — Prontuário Eletrônico do Cidadão
FHIR Fast Healthcare Interoperability Resources — padrão HL7 para interoperabilidade
GGUF Formato binário para modelos LLM quantizados (sucessor do GGML)
ICP-Brasil Infraestrutura de Chaves Públicas Brasileira
KDF Key Derivation Function — derivação de chave a partir de senha
LGPD Lei Geral de Proteção de Dados (Lei 13.709/2018)
LLM Large Language Model
MV3 Manifest V3 — padrão atual de extensões Chrome/Edge
NMH Native Messaging Host — bridge entre extensão e app desktop
NGS1/NGS2 Níveis de Garantia de Segurança SBIS para PEPs
PAdES PDF Advanced Electronic Signatures
PEC Prontuário Eletrônico do Cidadão (componente do e-SUS APS)
PEP Prontuário Eletrônico do Paciente
RIPD Relatório de Impacto à Proteção de Dados
RNDS Rede Nacional de Dados em Saúde
SaMD Software as a Medical Device (regulado por ANVISA RDC 657/2022)
SBIS Sociedade Brasileira de Informática em Saúde
SBOM Software Bill of Materials
SISREG III Sistema Nacional de Regulação
SLSA Supply-chain Levels for Software Artifacts
SUS Sistema Único de Saúde
TSA Time Stamping Authority
WCAG Web Content Accessibility Guidelines

Anexo B — Referências bibliográficas e regulatórias

Regulamentação brasileira: - Lei 8.080/1990 — Lei Orgânica da Saúde (SUS) - Lei 13.709/2018 — LGPD - Resolução CFM 1.821/2007 — Prontuário Eletrônico - Resolução CFM 2.314/2022 — Telemedicina - Resolução CFM 2.454/2026 — Inteligência Artificial em Medicina - ANVISA RDC 657/2022 — Software as a Medical Device - Manual de Certificação SBIS 2024 — NGS1/NGS2

Padrões internacionais: - HL7 FHIR R4 + BR-Core IG (interoperabilidade) - ISO/IEC 27001 (gestão de segurança da informação) - ISO 13485 (sistemas de gestão de qualidade para dispositivos médicos) - IEC 62304 (ciclo de vida de software médico) - WCAG 2.1 AA (acessibilidade web)

Documentos do projeto: - Proposta de projeto v0.3 (2026-04-29) - Pesquisa profunda validando stack (2026-04-29) - Brand Guidelines (brand/BRAND-GUIDELINES.md) - Threat Model (docs/THREAT-MODEL.md) - RIPD (docs/PRIVACY-IMPACT-ASSESSMENT.md)

Anexo C — Comparação com competidores

Sistema Local-first? Open source? SUS-aware? LGPD-by-design?
Nuance DAX ❌ Cloud ❌ Proprietary ❌ EUA ❌ Servidores externos
Abridge ❌ Cloud ❌ Proprietary ❌ EUA ❌ Servidores externos
Nabla ❌ Cloud ❌ Proprietary ❌ França ⚠️ GDPR mas não LGPD
OpenMRS ✅ Pode ser self-hosted ✅ MPL 2.0 ❌ Genérico OMS ⚠️ Configurável
GNU Health ✅ Self-hosted ✅ GPL-3.0 ❌ Genérico ⚠️ Configurável
OpenEMR ✅ Self-hosted ✅ GPL-3.0 ❌ EUA-centric ⚠️ Configurável
Bahmni ✅ Self-hosted ✅ AGPL ❌ Índia/global ⚠️ Configurável
Anotae ✅ Desktop local ✅ AGPL-3.0 ✅ e-SUS + SISREG nativo ✅ By design

Anotae ocupa nicho não preenchido: desktop local + open source + SUS-nativo + LGPD-by-design.

Anexo D — Estrutura de arquivos do repositório

anotae/
├── .github/
│   ├── workflows/           # CI/CD
│   ├── ISSUE_TEMPLATE/
│   └── PULL_REQUEST_TEMPLATE.md
├── anotae/                  # Pacote Python principal
│   ├── core/
│   ├── persistence/
│   ├── ui/
│   ├── nmh/
│   ├── http_bridge/
│   ├── llm/                 # opt-in v2.0+
│   └── asr/                 # opt-in v3.0+
├── extension/               # Browser MV3
│   ├── chrome/
│   ├── firefox/
│   └── shared/
├── migrations/              # SQL versionado
├── tests/
│   ├── unit/
│   └── integration/
├── docs/                    # Diátaxis
│   ├── tutorials/
│   ├── how-to/
│   ├── reference/
│   └── explanation/
├── brand/
│   ├── logos/
│   └── BRAND-GUIDELINES.md
├── scripts/                 # Build, release, vocab
├── vocabularies/            # CIAP-2, CID-10, SIGTAP
├── pyproject.toml
├── README.md
├── LICENSE                  # AGPL-3.0
├── CODE_OF_CONDUCT.md
├── CONTRIBUTING.md
├── SECURITY.md
├── BACKLOG.md
├── CHANGELOG.md
├── DESIGN.md
├── THIRD_PARTY_NOTICES.md
├── TRADEMARK-POLICY.md
└── CLAUDE.md

Anexo E — Histórico de versões deste documento

Versão Data Mudanças Autor
1.0 2026-04-29 Documento inicial consolidado Carlos E. F. de Ávila

Encerramento

"Anotae não vai resolver o SUS. Mas pode devolver para cada profissional alguns minutos por consulta. Multiplicado por milhares de profissionais e centenas de milhares de consultas por dia, isso é tempo recuperado para o que importa: a escuta, o exame, a empatia. Esse é o ponto."

— Carlos E. F. de Ávila

Fim do documento.

Este documento é versionado em docs/PROJECT-OVERVIEW.md no repositório oficial. Sugestões via Issues ou PRs.

© 2026 Carlos E. F. de Ávila / Sciereli HDC. Documento licenciado sob CC BY-SA 4.0.