Patient Case-Taking Software
Ministry of Ayush
Good pick. Genuinely. Now sit down, because the judges are going to try anyway — and this is what they will try.
Strong pick. The best-argued statement on the portal hiding behind a three-word title, with a demo the judge participates in — build the conversational history module properly and be upfront that the handwritten prescription OCR is partial, because pretending otherwise is the one thing that will sink you. Roughly 120–270 teams are expected to go here.
The receipts
Every red flag on this statement, in full. These are the four places it bites.
Exhibit A
Handwritten Indian prescriptions are among the hardest OCR targets in existence, and the statement treats reliable extraction from them as a solved enabling technology when it is not — scope this module honestly or it will collapse in front of a clinician
It gets worse
A conversational medical system must never appear to diagnose, and an unconstrained language model asking follow-up questions will drift there naturally — the ontology constraint and the physician-edits-before-saving design are safety requirements, not features
Still reading?
Hospital OPDs are loud and crowded, and speech recognition tested in a quiet lab behaves very differently at a registration counter with five hundred people in the hall
And the finisher
Four modules with multilingual speech, document AI, summarisation and ABDM integration is far more than one team finishes — decide which module is your demo and let the others be honest stubs
The damage report
Every score this statement earned, and what each one actually costs you.
Feasibility
4/5Actually buildable, which on this slate is rarer than it sounds. Do not squander it on scope.
The enabling pieces the statement identifies genuinely exist and are free — Indian-language speech recognition through national language infrastructure, an LLM constrained by a dialogue ontology, and an openly documented ABDM sandbox for the identity and FHIR side — so the conversational core is buildable now, with only the handwritten prescription OCR sitting well below what the statement assumes.
Innovation scope
3/5Mildly interesting. The novelty will not carry the room; the build has to.
Four modules, the clinical frameworks, the patient journey and even the failure modes of alternatives are all laid out, but the genuinely open question — how you constrain a language model to elicit history without ever drifting into diagnosis — is not answered anywhere in the statement and is the design problem that matters.
Clarity
5/5The ask is unambiguous, which quietly removes your favourite excuse.
At close to twelve thousand characters this is the most thoroughly specified statement on the portal, working through the problem quantitatively, explaining precisely why each existing alternative fails, naming the clinical frameworks for both allopathic and Ayurvedic history, and walking the entire patient journey step by step.
Acceptance potential
4/5Strong footing before you have written a line. Try not to waste it.
A strong hidden gem — the title is three words and the specification behind it is enormous, so teams browsing titles will skim past it, the demo is participatory, the two-minute consultation problem needs no justification, and the AYUSH Dashavidha Pariksha mode is a differentiator essentially no competing team will build.
Effort
MassiveA semester of work wearing a hackathon costume. Something is getting cut; decide what now, not in week five.
Multilingual speech in and out, an adaptive clinical dialogue manager, handwritten multilingual document OCR with entity extraction, timeline construction, clinical summarisation, ABHA authentication and FHIR push, and an accessible kiosk interface for low-literacy users is four large products in one statement.
Demo-ability
EasyEasy to demo — and so is everyone else's. Working is the floor here, not the achievement.
The judge talks to it and it interviews them back, which puts them inside the product rather than watching it, and the structured history appearing on the doctor's screen closes the loop in a way anyone in the room immediately understands.
Data
None suppliedNo dataset comes with this one, so every accuracy figure you quote is a number about labels you invented.
Nothing is provided with the statement. You are sourcing, cleaning and labelling it yourself, and that work is invisible in the demo but very visible in the questions.
The demo they will have already seen
Somewhere around 120–270 teams are heading here, and the description is doing the choosing for most of them. They will read the same brief, reach the same architecture, and build a version of the same demo you are planning. Being correct is the floor. If your five minutes could be swapped with the team before you and nobody in the room would notice, you have not picked badly — you have built predictably, which costs exactly the same and hurts more.
What survives
The ground worth standing on when the questions start.
- A three-word title over a twelve-thousand-character specification is a genuine competitive advantage — many teams filter statements by how substantial the title sounds and will never open this one
- The problem is quantified for you with consultation-time figures and OPD volumes, so the motivation is evidence-backed rather than asserted
- The dual-mode requirement that every question be answerable by speaking or tapping is both an accessibility win and a demo safety net — if speech recognition struggles on stage you fall back to touch without breaking the flow
Nothing here is fatal. It is just the list of places this statement pushes back, and you now get to push there first.
The framing is a joke. The findings are not — they are the same analysis on the statement page, and every line above is attached to a score or a fact in the record. It is one opinion with its reasoning attached, so argue with it before you trust it.