ContextRx

Inspiration

Our discussions with intensive care physicians, pharmacists, and nursing staff revealed a critical vulnerability in modern patient care: alert fatigue caused by legacy clinical decision support systems (CDSS). Clinicians characterised current tools as rigid and disconnected from the physiological reality of the patient in front of them. In the ICU, where patients frequently require 13–20 concurrent medications and organ function fluctuates hourly, practitioners do not need more pop-ups; they need intelligent context. The prevailing frustration is clear: when over 90% of alerts are overridden, even life-threatening warnings are dismissed as system noise. ContextRx was developed to address a fundamental question: how can we design a system that remains silent until a theoretical drug interaction evolves into an acute, patient-specific danger?

What It Does

ContextRx is a context-aware clinical decision support engine that integrates real-time laboratory trends with pharmacokinetic drug interaction modelling to determine when a theoretical interaction represents a definitive physiological risk. Rather than generating static alerts upon medication order entry, the system actively monitors organ function parameters such as serum creatinine, liver enzymes, and electrolyte panels. It only triggers a high-priority alert when a specific metabolic or renal clearance pathway is demonstrably failing, thereby increasing the risk of drug accumulation. Upon activation, the system generates an actionable intervention card detailing the pharmacological mechanism, the projected clinical risk, and precise recommendations for dose adjustment or alternative therapies. This methodology results in fewer workflow interruptions, enhanced clinical relevance, and improved medication safety within the ICU.

How We Built It

We built a four-layer architecture entirely within a single Next.js application:

1. Data Layer

An in-memory store seeding 3 ICU patients with realistic medication regimens (12 drugs for the primary patient), baseline labs, and scenario timelines. This replaces what would be FHIR/EHR adapters in production.

2. Risk Engine

A TypeScript computation engine that scores drug interaction danger in real time using the following formula:

$$ \text{riskScore} = \left(1 - S_{\text{organ}}\right) \times M_{\text{toxicity}} \times F_{\text{trend}} $$

Where:

$$S_{\text{organ}}$$ is the current organ function score (e.g., derived from GFR/creatinine)
$$M_{\text{toxicity}}$$ is the toxicity multiplier for the specific drug pair
$$F_{\text{trend}}$$ is a trend factor reflecting the slope of recent lab value changes

The engine cross-references 5 nephrotoxic drug pairs against live creatinine/GFR values and their trend slopes. Alert triage classifies scores into four tiers:

Tier	Score Range	Behavior
Critical	> 0.7	Immediate intervention alert
Warning	0.4 - 0.7	Elevated monitoring prompt
Informational	0.2 - 0.4	Logged, no interruption
Silent	< 0.2	Suppressed entirely

The silent tier is what eliminates alert fatigue.

3. Simulation Engine

A time-stepper that advances through a scripted ICU scenario (t = 0 \rightarrow 40 hours), inserting deteriorating lab values at each step, recomputing risk scores, and generating/superseding alerts. This lets us demo the full clinical arc, from "all quiet" to "critical intervention needed," in 60 seconds.

4. Clinician Interface

Five screens (Dashboard, Patient Detail, Comparison View, Audit Trail, About) designed for clinical light-mode glanceability. The comparison view, the demo centerpiece, shows a wall of 12 ignored static alerts on the left versus 1 precise, acted-upon context-aware alert on the right.

Architectural Philosophy

The key decision was keeping everything in one Next.js app with no external dependencies. API routes serve as the backend, the risk engine runs server-side as plain functions, and the in-memory store eliminates database setup. This let us go from zero to a working, deployable demo rapidly.

Challenges We Ran Into

Database to In-Memory Migration. We started with SQLite and Drizzle ORM for a proper relational data layer. When we tried deploying to Vercel, SQLite's native binaries wouldn't run in serverless. Rather than spinning up a hosted database mid-hackathon, we replaced the entire DB with plain TypeScript arrays in memory: simpler, zero-config, instantly deployable.

Cross-Worker Data Desync. The in-memory approach created a nasty bug: Next.js Turbopack runs API routes in separate workers, so /api/patients and /api/alerts each got their own copy of the data. The patient list would show alert badges while the alert feed right next to it said "All clear." We fixed it by eliminating the dual-fetch. The dashboard now pulls everything from a single API call, so there's one source of truth.

Risk Gauge vs Intervention Cards. The patient detail page showed "No interventions needed" directly above a "72\% Critical Risk Score" gauge. The risk gauge used live computation but intervention cards depended on stored alerts, which could lag behind. We rewired intervention cards to use live risk engine output instead of stored records.

Light Mode Pivot. We initially built a dark theme, but clinical environments are bright: fluorescent-lit wards, shared workstations, EHR systems like Epic are all light mode. We redesigned the full UI to a clinical light-mode aesthetic with restrained color use, where critical alerts earn attention against a calm baseline.

Realistic Data. Early demos had only 4 medications per patient. A real ICU patient is on 10 to 15 drugs. We expanded to realistic regimens, which made the demo more credible and better illustrated why static alert systems create so much noise.

Accomplishments We're Proud Of

We successfully translated complex pharmacological principles into a functional, demonstrative prototype that offers immediate clinical utility. By modelling the intersection of drug clearance pathways and real-time organ dysfunction, we achieved a critical shift from static rule-based logic to dynamic and physiology-driven decision support. We also developed an intervention interface that emphasises the pharmacokinetics reasoning behind each alert, thereby reinforcing clinician trust and supporting autonomous decision-making. Most notably, our side-by-side demonstration effectively highlights how legacy CDSS generates immediate noise, whereas ContextRx selectively identifies true clinical risk, making the platform's value proposition unequivocally clear.

What We Learned

We learned that alert fatigue is fundamentally an architectural flaw, not merely a user interface deficiency. Static lookup tables are not sufficient for managing the dynamic physiology of critically ill patients. We also learned that clinicians do not simply desire fewer alerts; they require highly specific notifications. We learned that explainability is critical to clinical adoption, as providing the pharmacological rationale behind a recommendation fosters significantly more trust than a standard severity label. Finally, meaningful healthcare innovation shouldn't try to replace clinicians, but rather act as a smart assistant that supports their clinical decision-making."

What's Next for ContextRx

Our next objective is to expand the platform beyond its initial nephrotoxicity focus into a comprehensive pharmacokinetic knowledge graph encompassing hepatic metabolism (CYP450 pathways), cardiac QT prolongation risk, and synergistic toxicity patterns. We intend to establish FHIR API integration for live EHR environments, enabling pilot testing in ICU settings to empirically validate the system's impact on alert override rates. We will also implement clinician feedback loops to iteratively refine our risk thresholds. Our overarching goal is to transition this prototype into a clinically validated, regulatory-compliant platform that eliminates alert fatigue and optimises patient safety.