RadFlow
Built at the Harvard Health Systems Innovation Lab Hackathon 2026 by a four-person team, RadFlow targets a specific gap: district and rural hospitals that own an X-ray machine but have no radiologist on site. It runs two complete AI pipelines end to end — detection, localization, guideline retrieval, and report drafting — entirely offline, and auto-adapts to whatever hardware the hospital actually has.
The Problem
A district hospital can own imaging hardware without owning imaging expertise — the read is the bottleneck, not the scan. Cloud-based triage tools assume reliable connectivity and a specific GPU, neither of which holds in a resource-constrained facility, and a missed abnormality on a chest film has a direct clinical cost.
The Solution
Every radiograph moves through a 4-stage pipeline — DenseNet121 screens for 18 pathologies, GradCAM localizes and crops the abnormal region, a ChromaDB-backed RAG step retrieves the matching clinical guideline, and CheXagent-8b drafts the final report grounded in that guideline rather than free-associating. A second pipeline, the Foveal Engine, trades some of that depth for speed: an OpenCV contrast pass crops a high-resolution region of interest in milliseconds and a token router (D-RoVA) drops irrelevant visual tokens before the VLM ever sees them, cutting token count by roughly 80% while keeping the crop diagnostic.
System Architecture
A FastAPI backend fronts both pipelines behind one API and owns the parts that make it operable rather than a demo: an InferenceJob queue processed by a background worker thread with retries, per-job cancellation, and status polling, so a slow VLM call never blocks the request path. Every completed inference is written to an append-only InferenceLedger, which powers an admin drift report comparing the last 7 days of case mix and calibrated confidence against the 7 days before — the kind of check a clinical tool needs and a hackathon demo usually skips. A hardware router picks CUDA + bitsandbytes 4-bit quantization, Apple MLX, or Intel IPEX at startup, so the same code path runs on whatever machine is actually in the building.
Key Features
Innovative solutions developed to solve complex technical challenges.
RadFlow-Edge: 4-stage clinical pipeline
DenseNet121 detection over 18 pathologies, GradCAM localization and cropping, ChromaDB-backed guideline retrieval, and a CheXagent-8b VLM analyzer that drafts the final report grounded in the retrieved guideline.
Foveal Engine: sub-second triage path
An OpenCV 'Vision Hack' crops a 512x512 region of interest by contrast alone, and a D-RoVA token router drops irrelevant visual tokens before the VLM call — roughly an 80% token reduction with the crop still diagnostic.
Async inference queue with retry and cancel
Analysis requests enqueue as an InferenceJob worked by a background thread with up to 2 retries and a live status/progress endpoint, so a slow or failed VLM call degrades gracefully instead of timing out the request.
Observability and drift panels
Per-endpoint call count, average and p95 latency, and error rate are tracked in-process; a separate drift report compares the last 7 days of pathology mix and calibrated confidence against the prior 7-day baseline.
Hardware-agile inference
Auto-detects NVIDIA CUDA (with 4-bit bitsandbytes quantization), Apple Silicon (MLX/MPS), or Intel ARC (IPEX) at startup so the identical pipeline runs on a hospital's existing hardware without a rebuild.
Dynamic clinical worklist
A full case worklist with escalation events and an EHR-style timeline per patient, backed by SQLAlchemy models (Case, Finding, Escalation) rather than being bolted onto the inference response.
Challenges & Breakthroughs
Challenge: A VLM call (CheXagent-8b) can legitimately take long enough to make a synchronous request path feel broken, and a hackathon demo can't afford a hung request.
Growth: Moved inference behind a queue: a POST returns a job ID immediately, a worker thread processes it with retries, and the frontend polls status. Cancellation and a hard retry cap made the failure modes explicit instead of a request that just never returns.
Challenge: Reducing visual tokens by 80% (the Foveal Engine's core bet) is only useful if the crop that remains is still the diagnostically relevant one.
Growth: Kept the contrast-based crop (Vision Hack) as a distinct, inspectable stage before any token-dropping, so the tradeoff between speed and detail is a visible pipeline boundary rather than a black box the VLM has to compensate for.
Challenge: A model that quietly degrades — starts favoring different pathologies, or grows less confident — is worse than one that fails loudly, and nothing in a single-request API surfaces that.
Growth: Added the drift endpoint specifically to compare rolling windows against each other from data already being logged, so the question 'has this gotten worse' has an answer without exporting the database somewhere else first.
Results & Impact
Next Project
AI Orchestrator (OrchestratorCLI)