Pular para o conteúdo principal
Docs vAtual•API —
Versão: Atual

Changelog, versionamento e depreciação

Versionamento​

  • A API é versionada no caminho: /api/v1/.... Mudanças incompatíveis entram numa nova versão (/api/v2), nunca quebrando a v1 em produção.
  • O contrato é aditivo: novos campos podem ser adicionados à resposta a qualquer momento — trate campos desconhecidos de forma tolerante. As versões internas do motor/regra vêm em analysis_metadata.source_versions.
  • schema_version identifica o contrato da resposta (v2).

Política de depreciação​

  • Recursos a serem removidos são anunciados aqui com antecedência mínima de 90 dias e passam a responder o header Deprecation (RFC 8594) com a data de término.
  • Endpoints administrativos seguem documentados no Swagger Admin (/docs/admin), separados das rotas de cliente.

Changelog​

2026-09 — Auto-alimentação por organização (v1.32.20)​

  • Decisões informativas passam a alimentar automaticamente a base de conhecimento da própria organização (RAG do tenant, sem dados do paciente) e um perfil de conduta agregado entra no contexto de todo chat da organização.
  • Snapshots de treinamento versionados por organização (JSONL anonimizado + SHA-256), gerados sob demanda ou semanalmente, mediante flag e consentimento. Nada alcança o motor determinístico. Ver Governança de alertas.

2026-09 — Memória de decisões e evidência mais rápida (v1.32.19)​

  • decision_history em cada clinical_alert: memória por organização das decisões já registradas sobre o mesmo alerta (contagens, taxa de sobreposição, última justificativa). Apresentação/contexto — não altera severidade nem risco. Também entra no contexto do chat/MCP.
  • Sugestões de governança (admin): candidatos a supressão por assinatura derivados das decisões, sempre com aprovação humana; CONTRAINDICADO nunca é candidato.
  • Exportação anonimizada de decisões (admin, desativada por padrão + consentimento por organização) para ajuste offline dos modelos de texto.
  • Velocidade da evidência: RAG por par em paralelo e com cache (9,5 s → 12 ms em pares já vistos); openFDA e DailyMed com cache de 6 h e consultas por par em paralelo.

2026-09 — Revisão de código end-to-end (v1.32.18): robustez e segurança​

  • Correção crítica: POST /pharmacy/check respondia 409 para qualquer chamada (chave de idempotência interna constante). Corrigido; Idempotency-Key funciona como em /interactions/check.
  • Webhooks: a entrega não bloqueia mais o servidor durante tentativas a endpoints lentos; chat.message agora usa o mesmo caminho de analysis.completed (retentativas, log e replay).
  • IP de origem real: a API passa a enxergar o IP do cliente atrás do proxy. A whitelist allowed_ips funciona e GET /health devolve client_ip para você conferir o IP visto.
  • Limites de payload: campos de texto livre (notes ≤ 8.000 chars; itens de conditions/ allergies ≤ 300 chars; listas ≤ 100 itens; labs ≤ 100 chaves) e corpo JSON ≤ 2 MB (413).
  • Paginação validada: limit (1–200 nas rotas de cliente) e offset (≥ 0) → 422 em vez de 500.
  • Lote (/interactions/batch): itens processados em paralelo com prazo global (100 s); itens não concluídos voltam como error explícito em vez de o proxy cortar a conexão.
  • Cota mensal: requisições rejeitadas pelo limite por minuto não consomem mais a cota do mês (429 distinto: Cota mensal excedida).
  • Direito ao esquecimento (LGPD): DELETE .../patients/{ref}?purge=true agora apaga o perfil e pseudonimiza a referência/remove dados clínicos nas análises, logs de uso e snapshots (snapshots em legal_hold são preservados e reportados). A resposta traz erased com contagens.
  • Headers: novos X-SauBit-Cache, X-SauBit-Agent-Run, X-SauBit-Processing-Time-Ms (os X-SafeMed-* continuam por uma versão). Security headers (HSTS, nosniff, frame-options) em todas as respostas.
  • MCP: JSON malformado → -32700 Parse error (400) em vez de 500; erros internos não expõem detalhes (apenas request_id).

2026-06 — Integração hospitalar, contrato estruturado e dev experience​

  • FHIR R4 (POST /fhir/$check): Bundle → RiskAssessment + DetectedIssue; perfis MedicationRequest/Statement, Condition, AllergyIntolerance, Observation, Patient, Encounter, DiagnosticReport, Practitioner.
  • CDS Hooks (/cds-services): medication-prescribe e order-select com cards.
  • HL7 v2 (POST /hl7v2/$check): MSH/PID/AL1/DG1/RXO/RXE/RXR/OBX.
  • Lote (POST /interactions/batch, até 25 itens).
  • Idempotência (Idempotency-Key) em check/batch/fhir/hl7v2/cds.
  • Webhooks: entrega com até 3 tentativas + log + replay (admin).
  • Contrato clínico estruturado (UCUM): dose+dose_unit (incl. mg/kg, mg/m2), forma/concentração/duração/indicação e códigos DCB/ATC/RxNorm/GTIN; bloco clinical_context_assessment (completude + risco residual).
  • Semântica transacional: resposta com request_id, replayed_request, billing_status; replay idempotente não é cobrado; GET /analyses/{id}/status.
  • Sandbox: chaves sm_test_ não são cobradas (billing_status: "not_charged").
  • Dev: SDKs Python e Node, coleção Postman, página de Fluxos do sistema.

Anterior​

  • Governança de alertas (P2): bloco alert_governance, visões médico × farmacêutico, confirmação em crítico, métrica "alertas que mudaram a conduta", dashboard/ROI (admin).
  • Motor clínico (P1): clinical_alerts (12 validações determinísticas) + safety net offline.