CognitiVR
A virtual reality platform for exploring and treating chronic pain.
CognitiVR was already treating patients when I became involved. I helped make the system more robust, portable and repeatable — and came to understand that the harder problem was getting it to people.
- Role
- CTO / Product & Technology
- Company
- Neurotechnology
- Product
- CognitiVR
- Domain
- VR · Digital Health · Human-computer interaction
- My work
- Technical leadership · Product architecture · Swift / iPad body tracking · Sensor abstraction · Platform development
Making pain visible
Chronic pain is deeply personal and difficult to communicate. CognitiVR explored whether immersive technology could give patients a different way to experience, describe and interact with pain.
The system combined a virtual representation of the body with immersive environments and tools that allowed pain attributes and locations to be represented spatially.
The core experience already worked when I arrived.
When I joined 42 Interactive, CognitiVR was already running in the Edgecliff clinic. The Unity experience existed. Body tracking worked. Clinicians could guide patients through the treatment.
I didn't need to invent the core idea. My role was CTO and technical leadership: architecture, technical guidance and helping make the system more robust and portable.
The companion application allowed the experience to be configured and observed outside VR. The person inside the headset interacted with a tracked representation of their own body.
The question I became increasingly interested in was what had to happen around that experience if it was ever going to reach more people.
- Immersive VR experience
- Anatomical 3D body model
- Body / movement tracking
- Pain location and attribute representation
- Clinician-facing controls
- Multiple virtual environments
The product in motion
The interaction makes much more sense when you see it running.
Built with real people, not just prototypes
VR products are difficult to design from a monitor. Much of the work happened through repeated testing — putting people into the experience, observing what worked, changing the interaction model and trying again.
The treatment shouldn't depend on one sensor.
The existing system used Kinect-style body tracking to drive the patient's avatar. Sourcing and depending on that hardware became increasingly problematic.
I personally developed a Swift implementation using an iPad's LiDAR / body-tracking capabilities as an alternative pose source. It captured body pose on the Apple device, mapped it into the skeleton representation Unity expected and transmitted the tracking data into the existing experience.
Different coordinate systems and skeleton conventions made that translation difficult. I also helped create an abstraction around tracking providers, so the avatar could receive a common pose representation rather than be hard-wired to one sensor.
- Kinect or iPad / LiDAR
- Tracking provider
- Unity
- Patient avatar
The treatment should survive the hardware changing underneath it. This was an alternative tracking implementation, not a wholesale replacement of Kinect across every installation.
The VR experience wasn't the whole product.
A clinic experience could work technically and still be difficult to replicate. We started building out the software around the treatment and thinking about what a repeatable service would need.
That meant patient profiles, clinician notes, treatment history and loading the right patient context. It also meant digitising previously paper-based measurements, tracking pain over time and collecting evidence of treatment progression.
The headset was where the treatment happened. Everything needed to remember the patient, measure progress and reproduce the service somewhere else had to exist outside it.
The aim was a platform that could support additional clinics, rather than a single installation that only worked in one room.
What if the clinic could come to the patient?
The treatment was centred on one Sydney clinic. People interested in it weren't necessarily in Sydney. Physical reach kept coming back as a constraint.
We explored untethered Quest-class hardware, lighter tracking requirements, iPad/mobile support, remote clinician involvement and a reduced home experience. Later, as AI capabilities emerged, we also considered whether some aspects of clinician interaction could be supported differently.
These were product explorations. They weren't a launched home product, clinically validated remote treatment or a replacement for the clinician.
The question was: how could the treatment reach someone who couldn't get to the clinic?
The technology wasn't the bottleneck.
I spent a lot of my career assuming difficult technical problems were the thing standing between an idea and success. CognitiVR complicated that assumption.
We improved robustness, explored alternative tracking, added platform capability and considered portability. But another technical feature didn't create another patient.
People had to discover the treatment and be able to access it. Referral pathways, geography and the operating model mattered. Distribution mattered.
The question that remained was: how do we get the treatment into the hands of the people who need it?
We made the technology more capable.
The harder problem was getting it to people.
What kept me believing in it was watching people use it.
I saw people arrive after living with pain for years and watched them engage with the treatment in ways that were difficult to forget.
From what I witnessed, I believed there were people who could potentially benefit from the approach. Those were personal observations, not a clinical evaluation.
Those experiences made the distribution problem frustrating. The challenge was reaching enough of them.
Looking back, I would have spent more time on reach.
I'm proud of the technical work we did on CognitiVR. The body tracking was difficult. The interaction design was unusual. Making the platform more robust and portable mattered.
But I don't think another technical feature was what the product needed most. The core experience was already good enough to test the bigger question: could we get it to enough of the people who needed it?
That's the problem I would have focused on earlier.
After several years working with Wilfred on Neurotechnology, 42 Interactive recently exited the joint venture. I left with a much stronger appreciation for a lesson that now influences how I think about products: technical feasibility and product distribution are different problems.
The technology worked.
The harder problem was reach.