What it takes to ship a Class I medical VR app
Most VR teams ship when the team thinks it's good. A Class I medical device ships when a regulator says so. Here's the gap, and what it cost us to close it.
The first time we tried to ship RVer as a medical device, we did what every software team does: built it, tested it, called it ready. Then we sent the technical file to Infarmed and got a list of seventy-three things we'd never thought about.
Most of them weren't bugs. They were absences — documents we hadn't written, processes we hadn't formalised, decisions we hadn't recorded. The product worked. The product wasn't certifiable.
The risk file
A Class I device under MDR 2017/745 needs a risk management file before it ships. Not as a final-step audit. As a living document that traces every code commit back to a documented hazard analysis.
This was the biggest pivot. We stopped writing code top-down ("build the menu") and started writing it requirement-up ("the user must be able to abort a session in under 2 seconds; the abort path must not depend on the headset's controller; the abort UI must be visible in peripheral vision"). Every implementation decision now traces to a requirement that traces to a hazard.
The post-market plan
You can't ship and walk away. Regulators want a documented plan for what happens after launch: how you monitor adverse events, how you communicate updates to hospitals, how you handle a recall.
For RVer we built a lightweight telemetry pipeline that flags clinical session anomalies (sudden disconnects, abandoned sessions, calibration failures) into a triage queue. Anything novel goes to the medical advisor inside 24 hours.
The decision we got right
Splitting clinical logic from content was the single best architectural call. The clinical core (session timing, intensity ramp, abort behaviour) is versioned, signed, and locked. The content (which beach, which forest, which soundscape) lives in a separate runtime — swappable without re-certifying the device.
That decision is the difference between needing a regulatory re-submission every time we add a new environment, and never needing one for content updates. It bought us months, possibly years, of velocity.
The honest part
This was hard. Slower than we wanted. More expensive than we budgeted. And the engineering work we're proudest of isn't in the gameplay — it's in the compliance harness that makes the gameplay legally sellable.
If you're a software team thinking about regulated VR, the work isn't the VR. The work is the regulatory shape you build around it. Plan for that first.