Estado Clínico: Conceitos

Clinical Corvus mantém um estado explícito por episódio para reduzir inconsistência entre interações e melhorar auditabilidade.

Por que isso importa

• Drift: restrições se perdem em conversas longas.
• Ambiguidade: o mesmo caso vira resumos diferentes.
• Baixa auditabilidade: fica difícil rastrear o que mudou e por quê.

Separação de Estados

O sistema separa estados com papéis epistêmicos diferentes:

Camada	Escopo	Papel	Persistência
Patient Context Manager	Paciente longitudinal	"O que sabemos sobre este paciente?"	Read-mostly das tabelas clínicas
CaseState	Episódio ativo	"O que estamos pensando sobre este caso?"	Patch-based, versionado
Learned User Memory	Usuário/tenant	Preferências e resumos de longo prazo	Com provenance e retenção
Working Memory	Turno/sessão	Contexto da conversa atual	Efêmero
Instruction/Policy Memory	Sistema	Constraints de roteamento e boundaries	Canônico para política

Episode reasoning não persiste como memória learned genérica. Quando CaseState está ativo, artifacts do episódio não são tratados com as mesmas semânticas de persistência que memória learned de usuário.

CaseState (Estado do Episódio)

Representa o raciocínio clínico ativo:

• Representação do problema
• Diagnóstico diferencial
• Plano (ações e monitorização)
• Evidência (quando solicitada)
• Flags de segurança e incerteza
• Estado de clarificação

Mutações Estruturadas

Em vez de "reescrever tudo", o sistema registra atualizações incrementais estruturadas (patches):

Tipos de patch:

• UpdateDifferential: atualiza diagnóstico diferencial
• AddEvidence: adiciona evidência ao ledger
• UpdatePlan: atualiza plano terapêutico
• AddSafetyFlag: adiciona flag de segurança
• UpdateClarificationState: transição de estado de clarificação

Cada patch tem:

• AuthorType: agent, clinician, system
• PatchOperationType: tipo de operação
• Timestamp: quando foi aplicado
• Lineage: referência ao patch anterior

Versionamento

CaseState é versionado. Cada patch cria uma nova versão do estado, permitindo:

• Timeline completa de evolução do raciocínio
• Rollback para versões anteriores
• Auditoria de decisões

Patient Context Manager (PCM)

Agrega contexto longitudinal do paciente:

• Demografia (idade, sexo, etnia)
• Diagnósticos (primário, secundário, comorbidades)
• Medicamentos ativos
• Laboratórios recentes (com tendências)
• Notas clínicas
• Sinais vitais
• Scores calculados (SOFA, NEWS2)
• Localização de cuidado e acuidade

O PCM é read-mostly: é montado das tabelas clínicas e usado como contexto para os agentes.

Working Memory

Memória de trabalho por turno/sessão:

• Contexto da conversa atual
• Notas rolando do agente
• Decisões pendentes
• Clarificações em aberto

Efêmera: não persiste entre sessões.

Learned User Memory

Memória de longo prazo do usuário:

• Preferências de proactivity (low/balanced/high)
• Correções feitas pelo usuário (com PHI scan antes de armazenar)
• Resumos de casos anteriores
• Configurações de notificação
• Preferências de idioma e timezone

Armazenada com provenance e controles de retenção. Escopo por tenant.

Sincronização com Mobile

O sistema expõe API de sincronização (/api/case-state/patches) para clientes mobile:

• Enviar patches do cliente para o servidor
• Receber patches do servidor no cliente
• Verificação de tenant em todas as operações