Local Clinical Engine
LAB-02 · Pilot · MVP demo · Last reviewed 29 August 2026.
A clinical decision support motor designed to run locally first, placing deterministic crisis handling, deidentification and output guardrails around model reasoning.
The question
How can a clinical assistant support intake and navigation while keeping emergency handling deterministic and preventing the model from becoming the source of clinical authority?
AXIO’s approach
The clinical motor is designed as a guarded workflow, not an autonomous diagnostician. Safety critical classification happens before generation, and production readiness depends on clinical governance, consent and validation from intake through operation.
Highlights
- An eight step orchestration path from identity and input guardrail through delivery and memory.
- Deterministic N0–N3 crisis classification before any LLM response.
- Deidentification aligned with Safe Harbor and adapted to the Costa Rica context.
- Local inference for workflows containing PHI, with cloud use restricted to content with identifiers removed and approved contracts.
How it works
- Identity — Resolve a pseudonymous subject and conversation boundary before retrieval or reasoning. Control: Production identity and consent records must be auditable; demo identity is not treated as production proof.
- Crisis gate — Deterministic rules classify urgent signals before the model and produce a controlled escalation path. Control: The model cannot downgrade a deterministic crisis classification.
- Remove identifiers — Configured identifiers and known clinical terms are transformed before an eligible cloud call. Control: Names and geography entered as free text still require maintained vocabularies and adversarial testing.
- Retrieve — Approved operational and clinical knowledge is selected for the current interaction. Control: Unavailable schedules, coverage or pricing must remain unknown rather than being generated.
- Reason locally — Qwen models hosted on Ollama provide the default reasoning path on local GPU infrastructure. Control: The system distinguishes degraded local inference from a successful response.
- Output guardrail — Deterministic checks block diagnosis, dosing and unsupported operational claims. Control: Clinical and operational lexicons require ongoing domain review.
- Human review — Risk and review queues surface cases for authorized staff rather than executing clinical action. Control: A real notification receipt and escalation SLA remain deployment evidence, not design assumptions.
- Audit — Events are structured for traceability across the motor, console and connected channels. Control: A true append only/WORM production audit store remains a production gate until verified live.
What AXIO delivers
AXIO helps healthcare teams evaluate a decision support workflow designed to run locally first before committing to a production clinical deployment.
- Workflow and risk classification for one bounded clinical use case.
- Local inference, deidentification and output guardrail prototype.
- Production readiness gap analysis covering governance, consent, audit and human escalation.
Evidence & maturity
- Implemented — Crisis and output guardrails: The motor includes deterministic crisis rules and explicit checks against diagnosis, dosing and unsupported output.
- Implemented with limits — Deidentification: The identifier coverage and adversarial tests exist, with documented limits for names and locations entered as free text.
- Pilot evidence — Local inference: Local Ollama smoke testing exists. Production concurrency, uptime and all target hardware paths still require current measurement.
- Pending production gate — Clinical operation from intake to audit: Consent, live channels, clinical governance, WORM audit storage and integrated deployment are not presented as complete.
Safeguards
- Decision support only: no diagnosis, prescription, dosing or autonomous medical action.
- Deterministic crisis classification precedes LLM reasoning.
- PHI is routed locally unless an approved cloud path for content with identifiers removed exists.
- Human review for risk and operational exceptions.
- Public notes exclude identifiers, network details, credentials, prompts and patient data.
Frequently asked questions
How can a clinical assistant support intake and navigation while keeping emergency handling deterministic and preventing the model from becoming the source of clinical authority?
The clinical motor is designed as a guarded workflow, not an autonomous diagnostician. Safety critical classification happens before generation, and production readiness depends on clinical governance, consent and validation from intake through operation.
What does AXIO deliver in this engagement?
AXIO helps healthcare teams evaluate a decision support workflow designed to run locally first before committing to a production clinical deployment. Typical deliverables: Workflow and risk classification for one bounded clinical use case; Local inference, deidentification and output guardrail prototype; Production readiness gap analysis covering governance, consent, audit and human escalation.
What is the current maturity of this work?
Pilot · MVP demo. Implemented: The motor includes deterministic crisis rules and explicit checks against diagnosis, dosing and unsupported output.
Contact & resources
Founder & CEO: Michael Vega. Email: [email protected]. Phone: +506 6300 5688. LinkedIn: linkedin.com/company/axiostaging. GitHub: github.com/VegaBuildsAI. Machine-readable resources for agents and developers: llms.txt, OpenAPI specification, MCP manifest, and agent instructions.