MyHospital

Where you live shouldn't decide how well you're cared for, MyHospital gives every village the triage intelligence and specialist access of a city hospital, in the patient's own language.

Comment

Inspiration

Millions of people live hours from the nearest specialist, but the NGOs that already work in those communities aren't short on trust or field presence, they're short on the software layer that lets a volunteer health worker, a patient, and a metropolitan doctor collaborate in real time. We kept coming back to the same gap: telehealth products exist, but almost none of them are built around low-bandwidth geography, multiple Indian languages, and a health worker's actual workflow, a triage queue, not a generic appointment list. We wanted to build the version of telehealth that assumes the patient has a basic phone, not a hospital's IT budget.

What it does

MyHospital is a two-sided telehealth platform, a patient portal and a clinician portal, built around one flagship idea: the sickest patient should never be buried in a first-come-first-served queue.

A patient describes symptoms by voice, in one of 9 Indian languages; a floating multilingual assistant (Sarvam AI for chat/TTS, Groq Whisper for STT, with a browser Web-Speech fallback when the backend isn't running) handles the conversation and grounds its answers in our own docs via a local RAG pipeline, so it doesn't hallucinate about the product. Behind the scenes, an XGBoost model trained on 560K+ real ED visits turns vitals + chief complaint + history into an inverted-ESI risk score, and a zero-shot DistilBERT/MNLI classifier routes the complaint to a specialty, together producing a critical → urgent → moderate → stable bracket. That result auto-assigns the patient to the best-matched, least-loaded doctor in-specialty and live-reorders the doctor's priority panel, no one manually triages the queue. Every AI decision is explainable: the patient-facing XAI Help page renders real per-prediction SHAP contributions as a reasoning graph with a plain-language summary, not a black-box confidence number. Doctor and patient talk over real-time, end-to-end access-controlled Secure Chat (Supabase Realtime Postgres Changes + Broadcast + Presence, AES-256-GCM client-side encryption, Postgres row-level security) and WebRTC video calls with a live captioned transcript that gets AI-summarized into the patient's permanent record when the call ends. If a patient has no smartphone or app literacy, the system can mirror every notification to SMS and nudge them daily to log vitals, shipped disabled by default since SMS is billable, but wired end-to-end.

How we built it

We treated this as a real product, not a static demo: React 19 + Vite 6 + TypeScript + Tailwind v4 on the frontend talking straight to Supabase (Auth, Postgres, Realtime) under row-level security — there's no custom app server standing between the UI and the database for core features. The database does real work: a triage_shift_patient trigger resolves the owning doctor and upserts the priority panel automatically, notify_user() is the single write path for a real notifications feed, and pg_cron jobs fire appointment reminders and daily vitals nudges.

Everything AI-related lives in its own optional service so the platform degrades gracefully if a service is down: a standalone FastAPI/XGBoost triage-risk service we trained ourselves and containerized for Railway, an Express voice backend holding the Sarvam/Groq keys server-side, and a local-embeddings + Pinecone RAG service (Xenova/multilingual-e5-small, no embedding API cost) that (re)indexes the README, source, and product docs whenever the app changes.

We built this in nine days end-to-end, auth and the login flow first, then the frontend shells for both roles, real-time secure chat, the ML risk model, WebRTC calling, the RAG assistant, and finally the notification/SMS layer, working in feature branches (frontend, dagrefeature, develop, hotfix) merged through PRs rather than pushing straight to main.

Challenges we ran into

Training a model that's actually trustworthy, not just accurate. Getting a triage score is easy; getting one a clinician would act on meant treating missing vitals the way the training data treated them, choosing the ESI inversion so "higher = more urgent" read naturally in the UI, and then building real SHAP explanations instead of a fabricated confidence number, because a black-box health score is worse than no score at all. Doctor-facing RLS without assignment. Doctors need to see patients matched to their specialty, not just patients explicitly assigned to them, but naive row-level security on triage_assessments can't express "same specialty" cleanly without leaking data. We ended up writing a security definer RPC (doctor_patient_panel()) specifically to keep the live priority queue both correct and properly scoped. WebRTC without a media server. Getting a P2P video call signaling entirely over Supabase Realtime broadcast (no dedicated media server, Google STUN only) took real debugging, we broke and fixed the call flow more than once before it was reliable. Making the voice assistant honest. An assistant that hallucinates about a healthcare product's own features is actively dangerous, so we built the RAG grounding layer specifically to keep its chat answers tied to real docs, and made sure it degrades to an ungrounded answer, not a broken one, if that service is offline. Being honest about our own encryption's limits. Client-side AES-256-GCM keeps plaintext out of the database, backups, and logs, but because Vite inlines VITE_* vars, the key ships in the client bundle. We chose to document that threat model explicitly in the README rather than overstate what we built as "end-to-end encryption."

Accomplishments that we're proud of

A real, trained ML pipeline, not a prompt wrapped in a chat UI; with genuine SHAP explainability driving a patient-facing reasoning graph. Zero plaintext chat messages at rest, enforced by both client-side encryption and database-level RLS, with idempotent writes so a flaky network retry never double-posts a message. A doctor queue that reorders itself: no admin, no manual triage, the trigger chain from ML prediction to panel ranking is fully automatic. Shipping a multilingual voice assistant across 9 Indian languages with a graceful offline-capable fallback, so the experience still works without any backend running. Building four genuinely optional services (voice, ML, RAG, SMS) that each degrade cleanly when unavailable, instead of one monolith that breaks if any dependency is missing.

What we learned

That the hardest part of "AI in healthcare" isn't the model — it's the honesty layer around it: knowing when to show a confidence score versus a full reasoning graph, when to let a feature fail silently versus loudly, and when to admit a security limitation in the README instead of marketing around it. We also relearned that Postgres, used properly (RLS, triggers, security definer RPCs, pg_cron), can replace an entire application server's worth of custom backend logic, most of this platform's "business logic" lives in the database, not in React state.

What's next for MyHospital

As an entity. We want MyHospital to exist the way a lot of health infrastructure that matters actually exists, as a small, mission-driven team rather than a growth-at-all-costs startup. Concretely: register as a not-for-profit or a low-profit/L3C-style entity so NGO partners never have to weigh "helping patients" against "paying a vendor," fund development through grants (health-tech innovation funds, public health foundations, CSR budgets under India's mandatory 2% corporate social responsibility spend) rather than patient- or NGO-facing fees, and keep the core platform open-source so any NGO with a technical volunteer can self-host it if they'd rather not depend on us at all. Revenue, if any, comes from optional paid infrastructure hosting/support for larger networks, never from patient data, never from a paywall on care.

How we'll help NGOs. Our first move isn't more features, it's one real pilot: partner with a single NGO already running mobile or rural clinics, deploy MyHospital alongside their existing workflow (not instead of it), and spend a full season just watching where it breaks against real patients, real network conditions, and real health workers who didn't design the software. From there:

A "bring your own doctor network" model, NGOs already have relationships with volunteer specialists; we make it trivial to onboard them as verified doctor accounts rather than requiring NGOs to recruit clinicians through us. Field-worker-first onboarding, training materials and an intake flow designed for a community health worker on a shared device, not an assumption that every patient self-registers on their own phone. Data ownership stays with the NGO, each NGO's care network is RLS-isolated by design already; going forward, that isolation extends to letting an NGO export or delete all of its data on request, no questions asked. Tiered connectivity support, the SMS bridge and offline-tolerant patterns exist specifically so a clinic with patchy 2G coverage isn't a second-class user of the same platform a city hospital gets. How we can make a difference. The honest measure of this project isn't lines of code or model accuracy, it's whether a patient who would have waited three days for a bus to see a doctor instead gets triaged and seen the same afternoon by someone who genuinely needed to see them first. If the pilot works, the plan is to publish real, anonymized before/after numbers (average time-to-care, correct-urgency triage rate, patients reached who'd never used telehealth before) instead of marketing copy, and to make the case, with evidence, that this specific combination of triage AI, native-language voice access, and zero-cost-to-deploy architecture is a repeatable model other NGOs can adopt, not a one-off pilot.

A major future scope: doctor-led diagnostic workshops. Beyond one-to-one telehealth, we want doctors and NGOs to be able to schedule in-person diagnostic workshops, a specialist holding a free check-up camp in a village or town for a day, directly inside MyHospital, with a location and radius attached. The platform would then automatically send an SMS and WhatsApp broadcast to everyone registered within a configurable radius (e.g. 5km) of the workshop, inviting them to walk in and get assessed. This turns the same triage and outreach infrastructure we've already built for one-to-one care into a tool for proactive, area-wide screening, reaching people who might never open the app on their own but will absolutely read a text saying a doctor is nearby today.

Built With

Share this project:

Updates

Submission history