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.
What the published record does not tell you
Healthcare case studies name the clinical setting and are close to silent on everything a procuring team needs next.
None of the healthcare work in this register carries a date, and only one names a target device. Neither absence is unique to healthcare, but both cost more here, because a clinical deployment depends on the device passing local infection control and IT review, and because a project delivered several years ago sits under a different regulatory posture than one delivered today.
The more significant gap is regulatory. Almost no published case study states whether the software was assessed as a medical device, which pathway it followed or who held the registration. A studio describing a clinical training build has usually not needed one. A studio describing anything that touches a live decision should be able to say, and the silence is the thing to ask about rather than to assume either way.
United States regulators publish the framework directly. The Food and Drug Administration sets out what qualifies as software as a medical device, defining it as software intended for a medical purpose that performs that purpose without being part of a hardware device. Reading that definition against a proposed scope is a cheaper first step than commissioning advice, though it does not replace it.
Further published work in this category
Healthcare work in the register divides into clinical training, patient-facing preparation and clinical visualization, and the middle group is growing fastest.
4Experience publishes training built for Doctors Without Borders, which is commissioned by a non-governmental organization rather than a provider and is aimed at field staff rather than clinicians. Draw and Code publishes SHELTA, a mental health support application built with the University of Liverpool, which sits in the patient-facing group and carries a named academic partner.
Device and procedure visualization is the third group. Next/Now publishes a showcase for VELYS Digital Surgery covering a robotic surgical platform, and Treeview publishes a cardiovascular patient onboarding experience. Both explain a procedure or a device to someone who is not the operating clinician, which is a communication problem rather than a clinical one and is regulated accordingly.
How deep the field actually is
Healthcare is one of the better covered sectors in this register, and it is still a small field.
Roughly half the studios on record publish at least one healthcare project, which is a higher share than most sectors reach. The depth behind that share is thin. Most of those studios publish a single healthcare project rather than a body of clinical work, so a shortlist drawn on sector experience alone will mix a studio with sustained clinical delivery and a studio with one adjacent project, and the published record presents them identically.
That is the argument for reading the individual record rather than the sector tag. A studio with one patient education build and a studio with several clinical training deployments both qualify as having healthcare experience, and they are not interchangeable for a procuring team. The register publishes the case studies behind each qualification for exactly this reason.
A ranked list for this sector will only be published where the evidence supports at least five studios with documented work in scope. That threshold is the same one that governs every route on this site, and where it is not met the register publishes nothing rather than a short list padded to look complete.
One further practical constraint sits outside both the clinical and the regulatory question. Hardware entering a clinical environment passes infection control and information security review, and both can refuse a device the project has already specified. Headsets shared between patients need a cleaning protocol that the manufacturer supports rather than one invented locally, and any device joining the network is assessed like any other endpoint. Those reviews are routine, they are run by teams who were not in the procurement conversation, and they are a common reason a funded project stalls between signature and first use.
A related point is worth stating plainly. Clinical governance is a capability a studio either has access to or does not, and it is usually borrowed rather than held, through a named clinical adviser or a partner organization. Asking who filled that role on a previous project, and whether they are available for this one, tells a procuring team more than any claim about sector experience.
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. Healthcare draws on the same supplier pool as the technology pillars rather than a specialist one, which is the single most important thing a procuring team should know before shortlisting. Most studios with published clinical work also appear under Augmented Reality development and under Virtual Reality development, so clinical experience has to be checked against the individual record rather than assumed from the sector.
By use case, the published healthcare record is concentrated in training and simulation, which covers clinical rehearsal and procedural instruction, and in product visualization, which covers anatomical teaching and surgical planning.
