PRANA

Inspiration

37% of Empty Nose Syndrome patients report suicidal thoughts — not from a terminal diagnosis, but from a routine nasal surgery that destroyed the nerve sensors telling their brain air is flowing. Their nose is wide open, but their brain thinks they're suffocating. 77% develop depression. 77% develop anxiety. And most are told by their doctors: "Your nose looks fine."

ENS doesn't even have an ICD-10 code. These patients are medically invisible.

But what struck us most wasn't just the suffering — it was the unique failure of care. In most diseases, the doctor finds something and treats it. In ENS, every scan comes back normal. The doctor literally has nothing to give. Traditional doctor-driven care breaks down completely.

So we asked: what if the patient decides what "getting better" looks like?

That question became PRANA.

What it does

PRANA (meaning "breath" in Sanskrit) is a patient companion app that puts the patient in the driver's seat of their own care. Instead of the doctor telling the patient what to work on, the patient sets their own life goals — like "sleep through the night without breathing distress" or "work a full day without my nose controlling my thoughts."

PRANA then:

Tracks daily symptoms using the ENS6Q — a clinically validated 6-item questionnaire (0–5 severity across 6 domains: suffocation, burning, openness, crusting, dryness, impaired air sensation)
Links each goal to specific symptom domains as measurable proxies (e.g., "sleep" maps to suffocation + dryness scores)
Translates patient language into clinical terminology using NLP — "my nose feels like a desert" becomes "Nasal mucosal dryness" in SNOMED CT, with confidence scoring
Computes goal progress — "You are 46% closer to sleeping through the night. Your barrier is crusting, which correlates with air conditioning exposure."
Generates a single-page clinician report** where GOALS come first — not symptoms, not scores — with what helped, what's blocking, and discussion points framed as questions

The result: instead of walking into a doctor's office saying "nobody believes me," the patient hands over a structured report and says: "Here are my goals. Here is my progress. I've done the work. Let's talk."

How we built it

Frontend: Single-page vanilla HTML/CSS/JavaScript application — no frameworks, no build step. All screens (splash, onboarding, profile, subtype selection, baseline ENS6Q, goal setting, daily check-in, home dashboard, clinician report) in one file
**Database & Auth: Firebase Firestore for patient profiles, daily check-ins, and generated reports. Firebase Authentication for email/password login
NLP Engine: Groq API (LLaMA) with a carefully constrained clinical prompt that maps free-text patient descriptions to SNOMED CT clinical descriptors and ENS6Q domains, with confidence scores. Anything below 70% confidence is flagged as "uncertain — discuss with clinician"
Goal Engine: Custom JavaScript engine that links each patient goal to specific ENS6Q domains, computes progress percentage using the formula progress% = (baseline - current) / (baseline - target) × 100, identifies trend direction (improving/stable/worsening), and pinpoints the specific symptom domain acting as a barrier
Trigger Correlation: Simple delta method comparing average symptom scores on days with vs. without each trigger (air conditioning, low humidity, stress, poor sleep, etc.) across 14+ days of data
Report Generation: html2pdf.js for client-side PDF generation of the goal-framed clinician report
Baseline Calibration: 2-phase system — provisional baseline from initial ENS6Q self-assessment, then automatic calibration prompt after 5 check-ins comparing estimates to actual data

Challenges we ran into

Designing the goal-domain mapping was harder than expected. We needed each life goal (like "sleep through the night") to map to specific ENS6Q symptom domains that could serve as measurable proxies. Getting this mapping clinically meaningful — not just technically correct — required deep research into ENS literature and the ENS6Q validation studies
NLP confidence thresholds — we debated extensively about what confidence level justified presenting a clinical term to a patient or doctor. We landed on 70% as the threshold, with anything below flagged explicitly as uncertain. The safety principle was: it's better to show ambiguity than to make a false-confident clinical assertion
Keeping it simple under time pressure — the temptation to add features (flare prediction, treatment effectiveness tracking, mental health screening) was constant. We had to discipline ourselves to focus on the core loop: goals → track → translate → report. Everything else was a future feature, not an MVP feature
Making the clinician report actually useful — early versions were data dumps. The breakthrough was restructuring the entire report around patient goals instead of symptom scores. Once we put "Goals & Progress" as Section 1 (above ENS6Q scores, above trigger insights), the report transformed from a chart into a conversation guide

Accomplishments that we're proud of

The goal-framed report — when we showed the report to peers and they said "oh, the goals come FIRST" — that was the moment we knew we'd nailed the core insight. No existing rare disease app structures its output around patient life goals
NLP translation with safety guardrails — "my nose feels like a desert" → "Nasal mucosal dryness" (95% confidence) and "I cannot stop thinking about breathing" → "Aprosexia nasalis" (85% confidence). Clinically meaningful translations with honest uncertainty flagging
The patient empowerment model — we didn't build a symptom tracker. We built a system where the patient defines what "better" means, and the entire app — every calculation, every visualization, every line of the report — serves that patient-defined goal
A working app with real data flow — from onboarding to daily check-in to NLP translation to goal progress computation to a downloadable PDF clinician report. End-to-end, built in 29.5 hours
The MCID integration — the report automatically notes when a patient's ENS6Q improvement exceeds the Minimal Clinically Important Difference of 7 points, giving the doctor a validated benchmark

What we learned

Patient-centered design is not a buzzword — it's an architecture decision. When we restructured the report to put goals first, it changed everything downstream: how we computed progress, what we highlighted, what we flagged as a barrier. The information hierarchy IS the philosophy
Rare disease patients need bridges, not dashboards. The problem was never "not enough data." It was that patient experience and clinical language are two different worlds. Building the NLP translation bridge between them was more valuable than any chart we could have made
Validated instruments matter. Using the ENS6Q (a published, peer-reviewed 6-item questionnaire with established scoring thresholds and a defined MCID) gave our project clinical credibility that a custom symptom scale never could have. We learned to lean on existing clinical science rather than inventing our own
Safety-by-design is non-negotiable in health apps. Every NLP output carries a confidence score. Every report carries a disclaimer. Every suggestion is framed as a question. We learned that what you DON'T claim is as important as what you do

What's next for PRANA

Baseline calibration refinement — after 5 days of data, prompt the patient to review whether their initial baseline estimates match their actual tracked patterns, and offer adjustment
Expanded trigger correlation — integrate with weather APIs for outdoor humidity/temperature data, and allow patients to add custom triggers beyond the preset list
Multi-disease support — the architecture is disease-agnostic. Any rare disease with a validated symptom scale can be configured: swap the ENS6Q for another instrument, create new goal templates mapped to that scale, and adapt the NLP prompt for that disease's terminology
Caregiver portal — a read-only view for caregivers and family members to see goal progress and receive the clinician report, supporting care coordination across multiple specialists
HPO interoperability — add optional Human Phenotype Ontology term suggestions as metadata on NLP outputs, enabling future integration with research databases like the Undiagnosed Diseases Network
Longitudinal insights — visit-over-visit comparison reports showing what changed since the last doctor's appointment, enabling true shared decision-making conversations over time