What is deployed today
Published XR work in healthcare concentrates on training clinicians and on preparing patients, not on assisting live clinical procedures.
That distinction runs through everything below, because the two sit on opposite sides of a regulatory line. Training a surgeon on a simulated procedure and guiding a surgeon during a real one are different products with different obligations, and the published record is heavily weighted toward the first.
Clinical and procedural training leads. WE/AR Studio publishes VR training for pathologists. Program-Ace documents a medical VR simulation platform. The logic matches training everywhere: rehearse something that is costly, risky or rare to practise on a real patient.
Visualization of medical imaging forms a second group. HQSoftware publishes a VR application for viewing CT and MRI scans, which addresses a genuine problem: volumetric data flattened onto a screen loses spatial relationships that matter for planning.
Patient-facing work is a third and growing group, covering education, preparation before a procedure and rehabilitation. It tends to be commissioned by a manufacturer or a provider rather than by a clinical department, and it is measured on comprehension and adherence rather than on clinical outcome.
What is largely absent from the published record is XR embedded in live clinical decision-making. Very little of it appears relative to how often it features in category marketing, and the reason is regulatory rather than technical.
What regulation constrains
The question that changes a healthcare XR project is whether the software influences a clinical decision, because that is what can make it a regulated medical device.
Software that informs diagnosis, treatment or monitoring falls under medical device regulation in most jurisdictions, including the European Union and the United States. Training a clinician on a simulated case generally does not. Guiding one during a real procedure generally does. The boundary is not always obvious in advance, and it is set by regulators rather than negotiated with a studio, so a project that drifts across it mid-build faces a compliance obligation nobody scoped.
Two consequences follow, and both belong in a first conversation rather than a late one.
Classification determines the process, not just the paperwork. A regulated device carries requirements for design controls, risk management, clinical evaluation and post-market surveillance. Those obligations shape how the software is built and documented from the start, and they cannot be applied retrospectively to a project that was developed as a training application.
Patient data carries its own regime regardless of device status. An application that touches identifiable health information is subject to health privacy law wherever it operates, and the applicable rules differ by jurisdiction. Where the data lives, who processes it and how it is retained are architecture decisions with legal consequences.
This page does not offer regulatory advice and no register page should. The practical instruction is narrower: establish device classification with a qualified regulatory adviser before scoping, because the answer determines the budget, the timeline and which studios can credibly do the work.
What evidence of return exists
The published evidence for healthcare XR is thinner than the category's marketing implies, and it is strongest for training rather than for outcomes.
Case studies describe what was delivered and for whom. Very few publish a result measured against a control group, and almost none published by a studio are peer-reviewed. That is not an accusation, since a studio's case study is a commercial document rather than a clinical one, but it does mean a studio case study cannot support a claim about clinical effectiveness.
Treat the two categories of claim separately. Claims about training, such as whether learners complete procedures more accurately after simulated practice, have a genuine research literature behind them and can be checked. Claims about patient outcomes, such as reduced pain, faster recovery or improved adherence, require clinical evidence, and any figure offered without a named study should be treated as marketing.
The register records what a source states and does not assess clinical validity. That limit is deliberate and is stated in the methodology. A studio being on the register means its published work has been read and its claims traced to sources, not that its software is clinically safe or effective. No directory can tell a buyer that, and one implying otherwise is overreaching.
What a studio must prove
Ask for delivered healthcare work, then ask which regulatory pathway it went through and who owned that pathway.
The second question is the one that separates studios. A studio that has delivered regulated software will answer specifically, will name the standard it worked to and will be clear about which obligations sat with the client. A studio that has only built training applications will not, and that is acceptable provided the project genuinely does not cross the line. The failure mode is a studio that has never met the question and does not recognize why it matters.
Three further checks are worth the time in this sector specifically.
Ask how clinical accuracy was established and by whom. Procedural content requires a clinician to validate it, and that person's time is a real line in the plan. A studio that cannot describe its clinical review process built its content from documentation alone.
Ask where patient data goes, if any is collected. The answer should be architectural and specific rather than reassuring, and a studio that has worked in the sector will have a ready answer about residency, retention and processing.
Ask about infection control and device handling. A headset shared between patients or clinicians in a clinical setting is subject to cleaning protocols that affect device selection, and it is a routine question in real deployments that never appears in a demonstration.
Where projects fail in this sector
Healthcare XR projects fail on clinical validation capacity and on procurement, far more often than on technology.
Clinical validation is the recurring bottleneck. Content must be checked by practising clinicians whose time is scarce and whose availability is controlled by a department rather than by the project. A plan that assumes prompt review cycles from busy clinical staff is optimistic, and the correction is to secure named reviewers with allocated time before development starts.
Procurement is the second. Healthcare organizations buy slowly, through information governance, clinical safety and IT security reviews that each take time and can require documentation the studio has to produce. A pilot funded from a departmental budget frequently cannot convert into a deployment without clearing those reviews, so the questions they will ask should shape the build rather than surprise it.
The third failure is quieter. Training content that is not maintained falls out of step with the protocol it teaches, and in a clinical setting teaching a superseded procedure is worse than teaching nothing. Maintenance ownership belongs in the original agreement.
Where to go next
Every studio named here is on the public record with its sources and its verification date, and the full list sits on the register.
Rankings are scoped rather than global, and healthcare is the clearest case for why. A studio with strong retail work has demonstrated nothing about its ability to operate under clinical governance, and the two capabilities do not transfer.
