AIIA Clinical Trials Dashboard - a real-time, cloud-based, GCP-compliant Clinical Trial Management System (CTMS) for Ayurveda research, with CDISC/FHIR-interoperable data, role-based KPIs, and integrated ethics, regulatory (CTRI / NDCT Rules 2019) and pharmacovigilance tracking.
Ministry of Ayush
Reasonable choice. The scoreboard liked it. The scoreboard is not the one asking questions on the day.
Worth considering. The sponsor has removed the data barrier and told you exactly what to build and in what order, but this is enterprise regulatory software with almost no visible surface, so take the staging advice and make the adverse event reporting clock your demo rather than the portfolio view. Roughly 95–220 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
CDISC SDTM mapping is a specialist skill with a genuine learning curve, and a submission claiming submission-ready datasets that would not actually pass a validator is the exact claim a regulatory-literate judge will test
It gets worse
The scope taken whole is an enterprise CTMS plus a pharmacovigilance system plus a standards conformance layer — take the statement's own staging advice or you will ship nine shallow modules
Still reading?
There is no visible product moment here beyond the adverse event clock, so the demo needs deliberate staging or it becomes a tour of dashboards
And the finisher
MedDRA is a licensed dictionary with access restrictions, so plan how you will demonstrate coding without it rather than discovering the licensing question during your presentation
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 statement removes the one thing that would otherwise block this by explicitly directing you to synthetic and de-identified data, and everything you must conform to is public — CTRI records are open, the CDISC standards and controlled terminology are published, and the FHIR R4 specification is freely available.
Innovation scope
2/5Nothing here is new. Your only edge is execution — and execution is also everyone else's only edge.
The lifecycle stages, the KPIs, the alert triggers, the data standards, the coding dictionaries, the seven roles and the export formats are all specified, so this is a conformance exercise where the correct answer is defined externally by regulation and standard.
Clarity
5/5The ask is unambiguous, which quietly removes your favourite excuse.
Exceptionally precise — it names every governing framework from GCP-ASU and the NDCT Rules to the DPDP Act and its 2025 Rules, every data standard including Define-XML, both coding dictionaries, all seven access roles, and even the four criteria the solution will be evaluated on.
Acceptance potential
3/5Middle of the pack. This statement will not win the room for you — you will have to.
Zero data risk, an unambiguous specification and a very thin field are all real advantages, but the scope is enterprise-scale and the parts that actually distinguish a serious submission — correct SDTM mapping and MedDRA coding — require specialist regulatory knowledge that most student teams do not have and will therefore fake.
Effort
MassiveA semester of work wearing a hackathon costume. Something is getting cut; decide what now, not in week five.
A study lifecycle tracker, a KPI and alerting engine, a full pharmacovigilance module with dictionary coding and regulatory timers, CDISC-conformant data models with submission export, FHIR and ABDM interoperability, consent management and an immutable audit trail is enterprise clinical software that vendors build over years.
Demo-ability
MediumDemoable, if you rehearse it. Nobody rehearses it.
The adverse event routing against a regulatory clock is a genuinely good moment and the audit trail is tangible, but the bulk of the product is a portfolio dashboard, and enterprise compliance software rarely produces anything a judge feels rather than merely follows.
The demo they will have already seen
Somewhere around 95–220 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.
- The statement tells you to use synthetic and de-identified data, which removes the ethics and access barrier that normally makes clinical software statements impossible for students
- It also tells you the build can be staged and names the order, so a core study-tracking and KPI MVP done properly is explicitly a valid submission rather than a partial one
- Correctness is defined by published standards and regulations rather than by your judgement, so requirement ambiguity is essentially zero
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.