# 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.

- **Source:** https://amplifiedcreations.com/journal/ship-class-i-medical-vr
- **Publisher:** amplified creations (https://amplifiedcreations.com/)
- **Author:** Pedro Thomaz
- **Published:** 2026-04-22
- **Updated:** 2026-10-18
- **Language:** en
- **Topics:** VR, Medical Device, Engineering, MDR 2017/745, Compliance

---

The first time we tried to [ship RVer as a medical device](https://rver.pt/blog/rver-registado-na-eudamed/en/), we did what every software team does: built it, tested it, called it ready. Then we sat down to prepare the technical documentation for registration in EUDAMED and with INFARMED (Portugal), and a list of *seventy-three* things we'd never thought about appeared.

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 *declarable*.

### The risk file

A Class I device under MDR 2017/745 needs [a risk management file](https://rver.pt/en/glossario/gestao-de-risco/) 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](https://rver.pt/en/glossario/vigilancia-pos-comercializacao/), 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](https://rver.pt/blog/software-modular-vantagens-saude/en/) 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-declaring 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.

---

Published by amplified creations, an independent technology studio in Leiria & Lisboa, Portugal. Contact: info@amplifiedcreations.com · More: https://amplifiedcreations.com/llms.txt