Designing VR clinical training with AIIMS Patna and BNRC: a co-design methodology

The most common failure mode of healthcare VR built in Indian technology ecosystems is that it is built by engineers, not clinicians. The engineer has reference images, procedural manuals, and good intentions. The clinician has the one thing the engineer doesn't: an internal mental model of what is true about the procedure and what is convenient for the demo.

NursingVR's development process was built around the observation that clinical accuracy is not the default output of a games studio. It is an output that has to be designed in from day one, with the clinicians whose names will be on the module.

Phase one — scope a module with the clinician, not for them

Every module in NursingVR starts with a scoping session between a content lead from AIIMS Patna and a VR engineer from Aonix. The question is not 'what would look good in VR'. The question is: 'What is the procedure your final-year nursing students get wrong most often in clinical posting, and what exactly do they get wrong?'

The answer drives the scope. A procedure that students get wrong in sequencing becomes a step-by-step module with branching feedback. A procedure they get wrong in instrument identification becomes an environment-navigation module. A procedure they have never seen becomes a virtual hospital tour. The clinician is not being consulted on the artwork; they are setting the learning objective.

Phase two — script the module against the logbook

Each module is scripted against the specific INC Practical Logbook competency it fulfils. This is how BNRC validation becomes possible. When a B.Sc Nursing student at a Bihar state college completes the NursingVR module on urinary catheterisation, the module output maps directly onto the logbook entry their clinical supervisor will sign.

Scripting against the logbook is tedious work. It requires reading the competency line by line, identifying which motor actions are testable in VR and which require physical hands-on, and partitioning the module accordingly. The payoff is that the module is not something the college has to fit into its curriculum — it is something the curriculum already defines.

The clinician is not being consulted on the artwork; they are setting the learning objective.

Phase three — build it wrong on purpose

The best-designed modules in NursingVR all went through a version that an AIIMS clinician rejected. That rejection is the most valuable step in the pipeline. It surfaces the things the engineer does not know they do not know: the orientation of the foley catheter tray relative to the patient, the order of glove donning before sterile-field preparation, the subtle positioning of the neonate during screening for retinopathy of prematurity. None of these are in any procedural manual in the depth required to ship. They live in the clinician's head.

We ship broken builds to clinicians early and often. The clinician plays through the module and tells us what's wrong. We fix it. We ship it again. The cycle ends when the clinician cannot find anything to correct. On a typical module, that is three to five cycles over two months.

Phase four — test it with students, not faculty

Clinician sign-off is necessary but not sufficient. A module that is clinically correct can still be pedagogically useless — too fast, too slow, too dense, or visually confusing in ways the clinician doesn't notice because the clinician already knows the procedure. Every NursingVR module is piloted with final-year GNM and B.Sc Nursing students at the deployed institutions before it is locked for release.

Student feedback has surfaced issues that the clinical pipeline alone would have missed: narrator pace being too quick for comprehension in Hindi-medium cohorts, assessment time pressure creating artificial mistakes, visual cues that made sense to a clinician but not to a student still building spatial orientation. These are not bugs. They are the content's interface, and they have to be designed with the same rigour as the clinical accuracy.

Phase five — validate against outcomes

The final phase of the co-design loop is outcome measurement. Every cohort that completes a module has their pre-training and post-training scores recorded. The interim impact study covering the first 212 students across the pilot institutions surfaced a measurable improvement in knowledge retention and clinical confidence. These numbers are not marketing — they are inputs back into the scoping session for the next module.

• Scope sessions with AIIMS clinical leads, framed around specific competency gaps observed in practice.
• Logbook-aligned scripting so the module serves the existing curriculum rather than creating parallel work.
• Iterative build-reject-rebuild with the clinician. Three to five cycles per module is standard.
• Student piloting at deployed institutions to test pedagogy, not just clinical correctness.
• Pre/post outcome measurement that feeds back into the next scope session.

Why this matters to a procurement committee

A nursing-college principal or state procurement lead evaluating VR platforms should ask one question before any other: how is the content made? If the answer does not involve practising clinicians at every stage of the build, the content is not reliable for clinical education. Medical VR is a domain where the production process is the product.

NursingVR is designed so that the answer is verifiable. The AIIMS Patna faculty who co-designed the modules are named. The BNRC validation is documented. The deployment data is open to review by partner institutions. That transparency is not a feature. It is a prerequisite for the institutional trust that makes clinical education work.