Roadmap — features in evolution

Product vision

This page describes the product direction and planned features. Items marked as planned are not yet available in the API. The endpoints documented in the guides and in the API Reference reflect what is in production today.

1. Reliable clinical engine (priority 1)

Complete medication normalization

Goal: recognize the medication regardless of how it is typed.

• active ingredient; brand name; active-ingredient combinations;
• salt and pharmaceutical form; concentration; unit; route; frequency; duration;
• DCB, ATC and EAN/GTIN codes when available;
• typos and similar names (fuzzy/normalization).

Today the API already normalizes PT/EN names and common brands, with a curated base that guarantees the major interactions. The goal is full catalog coverage (RxNorm/ANVISA + codes).

Structured clinical context (expansion)

Beyond conditions, current_medications, allergies, renal function and pregnancy, the patient_record/patient_context will grow to include:

age, weight, height, clinical sex; pregnancy and lactation; creatinine and clearance; hepatic function; allergies and reaction type; diagnoses; lab results; QTc, INR, potassium, blood pressure; route and frequency; setting (inpatient, emergency or outpatient); adverse-event history.

Principle: the response must explicitly state when a data point was not considered because it was not provided (coverage transparency, as already exists in source_coverage).

New validation classes

Beyond drug × drug:

✅ Already available (the clinical_alerts field in the check response): drug × disease, therapeutic duplication, maximum dose, drug × allergy (with cross-reactivity), renal/hepatic adjustment, pediatrics/geriatrics, pregnancy/lactation, drug × lab, food/alcohol and IV compatibility. Only pharmacogenomics remains (needs genetic data).

Validation	Application
Drug × disease ✅	medication incompatible with the condition
Therapeutic duplication ✅	two medications of the same class
Drug × allergy ✅	known reaction or cross-reaction
Drug × lab ✅	risk from potassium, INR or QTc
Maximum dose ✅	daily dose above recommended
Renal adjustment	dose inadequate for renal function
Hepatic adjustment ✅	risk in hepatic impairment
Pediatrics ✅	age-based contraindications
Geriatrics ✅	risk criteria for the elderly (Beers)
Pregnancy & lactation ✅	contraindications in pregnancy/lactation
Food & alcohol ✅	per-drug advisories
IV compatibility ✅	simultaneous-administration incompatibilities
Pharmacogenomics	genetic variant × medication

2. Smarter alerting (priority 2)

To fight alert fatigue, the analysis exposes the alert_governance block with relevance controls (configured per organization/API key):

✅ Available now (alert_governance block in the check response): configurable minimum severity, per-type suppression, per-hospital-unit rules (ICU/pediatrics/ oncology), known-alert suppression with override justification, mandatory confirmation on critical risk (requires_confirmation) and role views (physician × pharmacist, via the X-SauBit-Alert-View header). Suppression never lowers the prescription_risk_level. See Alert governance.

• configurable minimum severity in the response; ✅
• per-hospital-unit rules (ICU/pediatrics/oncology); ✅
• suppression of known alerts and override justification; ✅
• mandatory confirmation on critical risk; ✅
• different views for physician vs pharmacist; ✅
• metric of alerts that changed the clinical decision (decision recording + admin endpoint). ✅

Key metric: not "how many alerts were generated", but how many relevant alerts changed the clinical decision.

3. Dashboard and ROI (priority 3)

✅ Available now: admin endpoint GET /admin/organizations/{org_id}/dashboard that aggregates analysis volume, risk distribution, alerts by type/severity and the ROI signals (critical risk flagged + alerts that changed conduct + overrides), with a since/until window. As an admin route it is documented in the Admin Swagger (/docs/admin), kept separate from the hospital routes.

• aggregation of analyses, risks and overrides per organization; ✅
• the alerts that changed conduct KPI wired into the dashboard; ✅
• additional breakdowns/exports and time-series trends (next increments).

3. Hospital integration (priority 4)

✅ Available now — FHIR R4 (input/output): POST /api/v1/fhir/$check accepts a Bundle (MedicationRequest/MedicationStatement, Condition, AllergyIntolerance, Observation, Patient) and returns a Bundle of RiskAssessment + DetectedIssue. See FHIR R4.

Planned documented implementations:

• FHIR R4 ✅ (Bundle input + RiskAssessment/DetectedIssue output); next: Encounter, DiagnosticReport, Practitioner and additional profiles.
• CDS Hooks ✅ (/cds-services discovery + medication-prescribe/order-select with cards). See CDS Hooks.
• HL7 v2 ✅ (POST /api/v1/hl7v2/$check — MSH/PID/AL1/DG1/RXO/RXE/RXR/OBX). See HL7 v2.
• batch prescription import ✅ (POST /api/v1/interactions/batch, up to 25 items — see Batch); async queue processing planned.
• idempotency key ✅ (Idempotency-Key header); webhook retry and replay ✅ (delivery with up to 3 attempts + log + admin replay); reprocessing queue planned.
• certified connectors (MV, Tasy, TOTVS) and digital prescribing platforms.
• RNDS (Brazil's national health data network) on the mid-term roadmap.

4. SDKs, sandbox and developer experience (priority 5)

✅ Available now: Python and Node/TypeScript SDKs + Postman collection (SDKs and sandbox); sandbox via sm_test_ keys (not billed, billing_status: "not_charged"); changelog + versioning + deprecation policy (Changelog); developer portal = this Docusaurus + Scalar.

• SDKs: Python ✅ · Node/TypeScript ✅ · Go ✅ · PHP ✅ · C#/.NET ✅ · Java ✅.
• Postman collection ✅, sandbox/test keys ✅.
• changelog, versioning and deprecation policy ✅.
• dedicated staging environment — on request/planned.

Hospitals rarely put a clinical API straight into production without a staging environment.