A portable mobile app and sensor system that helps rural healthcare workers screen patients for osteoarthritis risk using joint, gait, and pain assessments offline.
Ministry of Development of North Eastern Region (MDoNER) · Hardware
Signing in saves it for your whole team, so everyone on your invite link sees the same two entries. Anything you shortlisted while signed out comes with you.
Decomposed from what the description asks for. Nothing added.
Symptom & Pain Screener
A digital questionnaire interface for healthcare workers to record patient pain levels, mobility limits, and medical history.
Gait & Movement Analyzer
A video or sensor processing module that analyzes joint movement, posture, and gait to detect early physical signs of osteoarthritis.
AI OA Risk Classifier
An AI engine that processes clinical inputs and physical movement metrics to generate a preliminary risk and severity score.
Offline Data Sync
A local storage system that captures screening data without internet connection and synchronizes with the server when online.
Multilingual Worker Dashboard
A localized interface that displays diagnostic reports, analytics, and preventive lifestyle guidance for healthcare workers.
Both columns are read off the brief's own wording. Nothing here is inferred from the ministry's name.
The jury will evaluate offline functionality and low-connectivity synchronization for remote field deployments. They will also look for multilingual support tailored to the North Eastern Region and a functional portable or camera-based gait assessment mechanism.
A jury can still ask about these. Decide them deliberately rather than by accident.
Generated from the brief's own wording and the competition's published rules, never from a guess about what this ministry prefers.
Which specific North Eastern languages must be supported?
The brief never answers this, so a panel will. Whatever you decide, say it the same way twice.
What accuracy or sensitivity metric is required for the AI model?
The brief never answers this, so a panel will. Whatever you decide, say it the same way twice.
Which specific sensors or hardware attachments are preferred?
The brief never answers this, so a panel will. Whatever you decide, say it the same way twice.
Where teams should source medical imaging or gait datasets for training?
The brief never answers this, so a panel will. Whatever you decide, say it the same way twice.
Has any part of this been shown at a previous event, hackathon or college project?
The guidelines are explicit: your solution must not have appeared in any previous event or programme, of any sort. A recycled project is what a team under time pressure reaches for.
The brief asks for symptom & pain screener. How would you build that?
Decoded from SIH26004 itself: A digital questionnaire interface for healthcare workers to record patient pain levels, mobility limits, and medical history. The brief asks for it by name.
The brief asks for gait & movement analyzer. How would you build that?
Decoded from SIH26004 itself: A video or sensor processing module that analyzes joint movement, posture, and gait to detect early physical signs of osteoarthritis. The brief asks for it by name.
The brief asks for ai oa risk classifier. How would you build that?
Decoded from SIH26004 itself: An AI engine that processes clinical inputs and physical movement metrics to generate a preliminary risk and severity score. The brief asks for it by name.
The brief asks for offline data sync. How would you build that?
Decoded from SIH26004 itself: A local storage system that captures screening data without internet connection and synchronizes with the server when online. The brief asks for it by name.
The brief asks for multilingual worker dashboard. How would you build that?
Decoded from SIH26004 itself: A localized interface that displays diagnostic reports, analytics, and preventive lifestyle guidance for healthcare workers. The brief asks for it by name.
Where does your data come from: a published source, one you collect, or one you generate?
No dataset is attached to this problem statement, so sourcing it is part of the work and nobody told you that.
Why not use what already exists? Name the closest thing to this that is already running.
A team that has not named the alternative themselves is answering this for the first time in the room.
Which single thing will you demonstrate end to end, start to finish, with nothing skipped?
Ours, not a rule: a narrow thing that fully works survives questioning better than a broad thing that half works. If nobody on the team can name it, that is the finding.
Show me this working: the jury will evaluate offline functionality and low-connectivity synchronization for remote field deployments.
This is the evaluator read for your problem statement, decoded from the brief's own wording.
Each one is quoted from a gap in the brief, not a guess about your team.
Needs physical hardware
Listed as a hardware problem statement, so a working demo needs physical components you have to source yourself.
No measurable target
The description asks for AI risk analysis and severity indication but provides no measurable target for accuracy or diagnostic performance.
What the organisers attached, and what the brief assumes you can get.
Same organisation, same year. Reading two of theirs tells you more about what they care about than reading one.