Roadmap — recursos em evolução

Visão de produto

Esta página descreve a direção do produto e recursos planejados. Itens marcados como planejado ainda não estão disponíveis na API. Os endpoints documentados nos guias e na Referência da API refletem o que está em produção hoje.

1. Motor clínico confiável (prioridade 1)

Normalização completa de medicamentos

Objetivo: reconhecer o medicamento independentemente de como ele é digitado.

• princípio ativo; nome comercial; combinações de princípios ativos;
• sal e forma farmacêutica; concentração; unidade; via; frequência; duração;
• códigos DCB, ATC e EAN/GTIN quando disponíveis;
• erros de digitação e nomes semelhantes (fuzzy/normalização).

Hoje a API já normaliza nomes PT/EN e marcas comuns, com uma base curada que garante as interações maiores. A meta é cobertura completa de catálogo (RxNorm/ANVISA + códigos).

Contexto clínico estruturado (expansão)

Além de conditions, current_medications, allergies, função renal e gestação, o patient_record/patient_context evoluirá para incluir:

idade, peso, altura, sexo clínico; gestação e lactação; creatinina e clearance; função hepática; alergias e tipo de reação; diagnósticos; resultados laboratoriais; QTc, INR, potássio, pressão arterial; via e frequência; cenário (internação, emergência ou ambulatório); histórico de eventos adversos.

Princípio: a resposta deve declarar explicitamente quando um dado não foi considerado por não ter sido informado (transparência de cobertura, como já existe em source_coverage).

Novas classes de validação

Além de fármaco × fármaco:

✅ Já disponíveis (campo clinical_alerts na resposta do check): Fármaco × doença Duplicidade terapêutica, Dose máxima, Fármaco × alergia (com reação cruzada) Ajuste renal/hepático, Pediatria/Geriatria, Gravidez/Lactação, Fármaco × laboratório, Alimento/álcool e Compatibilidade IV. Resta apenas Farmacogenômica (depende de dado genético).

Validação	Aplicação
Fármaco × doença ✅	medicamento incompatível com a condição
Duplicidade terapêutica ✅	dois medicamentos da mesma classe
Fármaco × alergia ✅	reação conhecida ou reação cruzada
Fármaco × laboratório ✅	risco por potássio, INR ou QTc
Dose máxima ✅	dose diária acima da recomendada
Ajuste renal ✅	dose inadequada à função renal
Ajuste hepático ✅	risco em insuficiência hepática
Pediatria ✅	contraindicações por faixa etária
Geriatria ✅	critérios de risco para idosos (Beers)
Gravidez e lactação ✅	contraindicações na gestação/lactação
Alimento e álcool ✅	advertências por fármaco
Compatibilidade IV ✅	incompatibilidades de administração simultânea
Farmacogenômica	variante genética × medicamento

2. Resposta de alertas mais inteligente (prioridade 2)

Para combater fadiga de alertas, a análise expõe o bloco alert_governance com controles de relevância (configuração por organização/API key):

✅ Já disponível (bloco alert_governance na resposta do check): nível mínimo de gravidade configurável, supressão por tipo, regras por unidade hospitalar (UTI/pediatria/oncologia), supressão de alertas conhecidos com justificativa de override confirmação obrigatória em risco crítico (requires_confirmation) e visões por papel (médico × farmacêutico, via header X-SauBit-Alert-View). A supressão nunca rebaixa o prescription_risk_level. Veja Governança de alertas.

• nível mínimo de gravidade configurável na resposta; ✅
• regras por unidade hospitalar (UTI/pediatria/oncologia); ✅
• supressão de alertas conhecidos e justificativa de override; ✅
• confirmação obrigatória em risco crítico; ✅
• visões diferentes para médico vs farmacêutico; ✅
• métrica de alertas que mudaram a conduta (registro de decisão + endpoint admin). ✅

Indicador-chave: não "quantos alertas foram gerados", mas quantos alertas relevantes mudaram a conduta.

3. Dashboard e ROI (prioridade 3)

✅ Já disponível: endpoint administrativo GET /admin/organizations/{org_id}/dashboard que agrega volume de análises, distribuição de risco, alertas por tipo/gravidade e os sinais de ROI (risco crítico sinalizado + alertas que mudaram a conduta + overrides), com janela since/until. Por ser rota administrativa, está documentada no Swagger Admin (/docs/admin), separada das rotas de hospital.

• agregação de análises, riscos e overrides por organização; ✅
• KPI de alertas que mudaram a conduta integrado ao painel; ✅
• exportações/recortes adicionais e tendência temporal (próximos incrementos).

3. Integração hospitalar (prioridade 4)

✅ Já disponível — FHIR R4 (entrada/saída): POST /api/v1/fhir/$check recebe um Bundle (MedicationRequest/MedicationStatement, Condition, AllergyIntolerance, Observation, Patient) e devolve um Bundle de RiskAssessment + DetectedIssue. Veja FHIR R4.

Implementações documentadas planejadas:

• FHIR R4 ✅ (entrada Bundle + saída RiskAssessment/DetectedIssue); próximos: Encounter, DiagnosticReport, Practitioner e perfis adicionais.
• CDS Hooks ✅ (/cds-services discovery + medication-prescribe/order-select com cards). Veja CDS Hooks.
• HL7 v2 ✅ (POST /api/v1/hl7v2/$check — MSH/PID/AL1/DG1/RXO/RXE/RXR/OBX). Veja HL7 v2.
• importação de prescrição em lote ✅ (POST /api/v1/interactions/batch, até 25 itens — veja Lote); processamento assíncrono por fila planejado.
• idempotency key ✅ (header Idempotency-Key); retry e replay de webhooks ✅ (entrega com até 3 tentativas + log + replay admin); fila de reprocessamento planejada.
• conectores homologados (MV, Tasy, TOTVS) e plataformas de prescrição digital.
• RNDS no roadmap de médio prazo (conforme regras e casos de uso autorizados).

4. SDKs, sandbox e experiência do desenvolvedor (prioridade 5)

✅ Já disponível: SDKs Python e Node/TypeScript + coleção Postman (SDKs e sandbox); sandbox via chaves sm_test_ (não cobradas, billing_status: "not_charged"); changelog + versionamento + política de depreciação (Changelog); portal do desenvolvedor = este Docusaurus + Scalar.

• SDKs: Python ✅ · Node/TypeScript ✅ · Go ✅ · PHP ✅ · C#/.NET ✅ · Java ✅.
• coleção Postman ✅, sandbox/chaves de teste ✅.
• changelog, versionamento e política de depreciação ✅.
• ambiente de homologação dedicado (staging) — sob solicitação/planejado.

Hospitais raramente colocam uma API clínica direto em produção sem homologação.