Inspiration
In low-resource health settings, NGOs and community health workers often lack real-time population data. We saw that teams were forced to respond reactively to emergencies rather than proactively to early warning signals, allowing patients to slip through the cracks between sparse clinic visits. We wanted to bridge that gap by turning daily self-reported wellness data into structured, actionable clinical intelligence with zero infrastructure cost.
What it does
SwasthyaSetu (Sanskrit for "health bridge") is a clinical-grade preventive triage and NGO intervention planning system. It ingests daily patient wellness check-ins—covering mood, sleep, hydration, activity, stress, and resting HR—and runs them through a deterministic risk scoring engine. The system surfaces actionable population-level intelligence on a live 5-tab Command Center dashboard, allowing NGO field teams to monitor risk distributions, track 14-day high-risk alerts, and project necessary interventions over a 12-week period so they can intervene before a crisis occurs.
How we built it
We wanted a system that was lightning-fast, memory-safe, and capable of handling high-concurrency event streams. We built the backend entirely in Rust, utilizing the Tokio async runtime and the Axum web framework.
The core of the backend is our deterministic risk engine, which evaluates patient check-ins on the fly. The overall wellness score $W$, bounded to $[0, 100]$, is calculated using a weighted clinical model:
$$W = \left(\frac{M}{5} \times 28\right) + \left(\min\left(\frac{S}{8}, 1\right) \times 24\right) + \left(\min\left(\frac{H}{8}, 1\right) \times 18\right) + \left(\min\left(\frac{A}{30}, 1\right) \times 18\right) - \left(\frac{Str - 1}{4} \times 12\right)$$
(Where $M$ is Mood, $S$ is Sleep in hours, $H$ is Hydration in glasses, $A$ is Activity in minutes, and $Str$ is Stress level).
Simultaneously, the engine calculates a cumulative risk score, which includes complex triggers like a compounded psychosocial risk penalty ($R_{psych}$):
$$R_{psych} = \begin{cases} 8 & \text{if } M \leq 2 \text{ and } Str \geq 4 \ 0 & \text{otherwise} \end{cases}$$
We store this evaluated data in a thread-safe, bounded in-memory structure using Arc<RwLock<VecDeque<CheckIn>>>. For the frontend, we kept it lightweight and dependency-free using Vanilla ES6 JavaScript, HTML, and CSS, utilizing Chart.js for the live telemetry and analytics visualizations. The dashboard polls the API every 5 seconds to keep the telemetry stream and UI entirely real-time.
Challenges we ran into
Building a real-time system from scratch came with some deep technical hurdles. We ran into critical panics during the Axum server initialization due to duplicate HTTP method routing on the same API path. We also had to untangle static file serving paths between the Rust backend and the frontend directory structure to prevent 404 errors. On the frontend, managing the live telemetry stream required writing custom deduplication logic using a seenTelemetryIds Set to ensure historical check-ins didn't infinitely reload and flood the UI during our 5-second background polling cycles.
Accomplishments that we're proud of
We are incredibly proud of the clinical risk engine we developed. It isn't just a black box; it provides deterministic, explainable, and auditable risk scoring, ensuring that NGO workers know exactly why a patient was flagged. We are also proud of achieving a fully real-time, responsive 5-tab dashboard without relying on heavy frontend frameworks, proving that Vanilla JS and a highly optimized Rust backend can deliver a premium, high-performance experience.
What we learned
We deepened our understanding of low-level systems architecture and safe concurrency in Rust. Managing shared state across multiple async threads using RwLock taught us a lot about preventing data races while maintaining high throughput. We also learned how to effectively handle and visualize time-series aggregation, specifically dealing with timezone offsets and bucketing daily check-in volume for the frontend analytics charts.
What's next for SwasthyaSetu
To take SwasthyaSetu from a hackathon prototype to a field-ready tool, our first step is replacing the bounded in-memory VecDeque store with a persistent database like PostgreSQL. From there, we plan to integrate SMS or WhatsApp API capabilities so community health workers can submit patient check-ins via basic text messages, truly achieving the "zero-infrastructure" goal for the last mile of healthcare.
Log in or sign up for Devpost to join the conversation.