Clinical VR session companion · iPadOS

VR4GOOD Clinician

An iPad control interface designed to help clinicians prepare patients, configure personalised immersive environments and supervise structured VR sessions.

StatusWorking SwiftUI prototype · clinical validation pending
VR4GOOD Clinician
01Patient profile
02Sanctuary setup
03Sensor check
04Session control
05Clinician review

The problem

Why this product needed to exist.

A supervised clinical VR session involves more than launching an experience. The clinician needs a clear operational view of the patient, the selected environment, sensory preferences, session controls and safety indicators without being overloaded by the headset interface itself.

The product response

Architecture led by the workflow.

VR4GOOD Clinician separates the professional control layer from the immersive patient experience. The working iPad prototype provides bilingual entry, patient profiles, personalised “sanctuary” configuration, sensor preparation and session controls. A separate Unity blueprint defines the proposed Quest 2 runtime, modular scenes, sensor-provider interface and clinician-supervised return-to-safety logic.

Proposed end-to-end architecture: clinician console, VR runtime, physiological input and a supervised return-to-sanctuary safety loop. This diagram is a product and technical blueprint, not evidence of a deployed clinical system.
Proposed end-to-end architecture: clinician console, VR runtime, physiological input and a supervised return-to-sanctuary safety loop. This diagram is a product and technical blueprint, not evidence of a deployed clinical system.

Our team’s role

Responsibility from strategy to execution.

Clinical workflow modelling
iPad experience and interface direction
SwiftUI prototype development
Patient and session data flow
Safety-state interaction design
Bilingual product experience

Important decisions

The choices that make the system coherent.

  1. Keep the clinician in control of session start, pause and stop actions.
  2. Separate patient preparation, environment configuration and live monitoring into clear stages.
  3. Treat sensor readings and safety states as supervised indicators, not automated clinical decisions.
  4. Present the product as a prototype requiring clinical, privacy and regulatory validation before care use.

Technology & disciplines

SwiftUIiPadOSUnity / OpenXR blueprintAdditive scene architectureSensor-provider abstractionClinician-supervised safety states

Honest outcome

What this project proves today.

The prototype demonstrates a coherent clinician-side workflow for personalised and supervised VR sessions on iPad. It is product-development evidence, not evidence of therapeutic effectiveness, and it is not presented as a certified medical device or a replacement for clinical judgement.

Related problem

Your project does not need to be identical to benefit from the same discipline.