💡 Inspiration

Healthcare in India is unevenly distributed — a family in a rural town or an urban slum may be hours away from a doctor, yet they're the ones most likely to face a medical emergency at 2 AM. When a child develops a high fever or a parent becomes confused and lethargic, caregivers are left searching Google, calling relatives, or simply guessing.

We built HomePulse because we believe that structured clinical reasoning shouldn't be a privilege. The triage protocols used in emergency departments exist for a reason — they save lives by correctly identifying who needs urgent care versus who can safely be monitored at home. HomePulse brings that same logic into the hands of the family, guided, calm, and accessible even without an internet connection.


🩺 What It Does

HomePulse is a clinical triage assistant for home caregivers. Given a patient and their current symptoms, the app:

  1. Walks the caregiver through an adaptive questionnaire — asking only the questions relevant to the reported symptoms (fever, breathing, hydration, consciousness level, rash, etc.).
  2. Runs a deterministic clinical engine that checks for red flags, analyses the symptom trajectory over time, and applies household-resource modifiers (do you have a thermometer? transport to a clinic?).
  3. Returns one of four clearly labelled action states: Monitor at Home → Guided Home Care → Arrange Teleconsultation → Seek Urgent Care Now.
  4. Schedules a recheck reminder via local push notification at the interval specified by the triage result.
  5. Enables caregiver coordination — task checklists can be shared with a second caregiver via a QR code linked to a Supabase-hosted case summary.

Everything above works fully offline. The internet is only needed for the optional sharing and AI explanation features.


🔨 How We Built It

Concern Decision & Rationale
Framework Expo 56 (React Native) — single codebase for iOS, Android & web; managed workflow keeps ops overhead low
Navigation Expo Router (file-based) — screens map directly to the filesystem, making the flow easy to audit
Clinical Engine Pure TypeScript (engine/) with zero React Native imports — independently unit-testable, deterministic, no side-effects
Local DB expo-sqlite with append-only symptom_entries — guarantees no data is ever silently overwritten
State Zustand v5 stores — thin layer between DB and UI; all async errors surface as store fields, never thrown to components
Cloud Sync Supabase (non-critical path) — operations are queued locally first and synced when connectivity is available
Forms React Hook Form + Zod — runtime schema validation for all questionnaire inputs
Design Custom "Guided Reassurance" design system — warm paper palette, 28 px card rounding, Emil-style cascade motion
i18n i18next with full en + hi translation files ready from day one
Linting Biome — single tool for linting and formatting, replacing ESLint + Prettier
Build & Deploy EAS Build for production iOS/Android binaries

🧱 Challenges We Ran Into

  • Making the engine truly offline-safe. Medical apps can't afford to throw an unhandled exception at a critical moment. We spent significant time designing a fail-safe pattern: if the engine encounters any unexpected error, it returns Level 3 (Teleconsult) instead of a false Level 1 reassurance — a deliberate, conservative fallback.

  • Designing the questionnaire as a state machine. Symptoms are correlated; answering "no rash" should skip the rash-severity sub-tree. Building a clean state-driven adaptive flow (without bloated libraries) required careful modelling of question dependency graphs.

  • Balancing clinical accuracy with caregiver anxiety. Too many questions and caregivers give up; too few and the output is unreliable. We iterated heavily on question wording and ordering to feel guided rather than interrogating.

  • Offline-first sync without conflicts. The symptom_entries table is append-only by design — a choice that eliminates write conflicts entirely. Designing the Supabase sync queue to be idempotent (with idempotency_key and bounded retries) without blocking the UI took multiple architecture passes.

  • Security of clinical rule configs. We sign versioned rule JSON files with HMAC-SHA256 so tampered configs are rejected before they influence a triage decision. Getting this right without leaking signing keys in the client bundle required a careful environment variable strategy.


🏆 Accomplishments That We're Proud Of

  • A genuinely useful clinical engine — the evaluator handles red-flag detection, multi-day symptom trajectory analysis, and household-resource modifiers in under 300 lines of pure TypeScript with full unit test coverage.
  • Complete offline functionality — install the app, turn on airplane mode, and every core feature still works perfectly.
  • A design system that feels human — the "Guided Reassurance" aesthetic was deliberately crafted so that caregivers in a stressful moment feel supported, not overwhelmed by clinical jargon or alarming colours.
  • i18n-ready from day one — full Hindi + English translation files mean the app is ready for its primary audience without a future rewrite.
  • Production-grade architecture — module boundaries, sync queue robustness, data retention / purge flows, and at-rest encryption notes are documented and enforced, not deferred.

📖 What We Learned

  • Offline-first is an architecture decision, not a feature. It has to be designed in from the schema up — you can't bolt it on later. The append-only symptom_entries pattern was the single most important structural decision we made.
  • Clinical domain knowledge is non-negotiable. The difference between a useful triage app and a dangerous one is in the details — which red flags to check, what "worsening" means over 24 hours, when to escalate regardless of temperature. We consulted existing triage literature extensively.
  • Fail-safe > fail-loud in healthcare. Every error boundary in the engine returns a more cautious recommendation, not an optimistic one. This principle should be universal for any health-adjacent software.
  • Design drives trust. In usability testing, the calm warm palette and staggered animations made participants describe the app as "reassuring" — the exact adjective we were targeting. Aesthetics are not superficial in high-stress contexts.

🔭 What's Next for HomePulse

  • Wire up i18n across all screens — translations are ready; the useTranslation() hook just needs to replace hardcoded English strings app-wide.
  • Complete caregiver task integration — the useTasksStore and database queries are fully implemented; the Home screen task checklist UI just needs to be connected.
  • Fix sync queue payload — the Supabase sync worker needs the full CaseSummary object (not just { caseId, token }) to successfully retry failed publishes.
  • AI-powered explanations — the Groq integration is scaffolded and feature-flagged; enabling it will give caregivers plain-language reasoning for every triage decision.
  • Multi-language voice input — speak symptoms in Hindi or English rather than tapping through a questionnaire, critical for low-literacy users.
  • Clinician dashboard — a lightweight web view for community health workers to review shared case summaries and send back guidance.
  • Pilot with community health programs — validate the triage engine against real-world cases and iterate on clinical rules with medical advisors.
  • SQLCipher integration — at-rest encryption of the local SQLite database for production deployments handling real patient data.

Built With

Share this project:

Updates