The eight questions hospital IT will ask about virtual reality

There is a predictable moment in adopting any technology in a hospital: the service wants it, management is open to it, and the process reaches IT. That is where many projects die, not through rejection, but by waiting for answers nobody prepared.

It pays to anticipate the questions. They are almost always the same eight.

1. "Will this connect to our network?"

The question behind it is: how much new surface does this add for me?

Two things get confused here. One is whether the equipment needs internet during a session: if it does, a Wi-Fi drop interrupts a patient midway, and that is a clinical problem before it is an IT one. The other is whether a management application runs on the local network.

With RVer, content playback runs entirely on the headset and needs no internet during a session. The Companion app opens in the browser on any PC or tablet on the same local network, with nothing to install and nothing going through the cloud.

2. "Does it need integration with our systems?"

This is the question IT dreads most, because integration means a project, and a project means months.

The right answer, when it is true, is no. RVer runs independently and requires no integration with hospital systems. That means no interface to build, no identifier mapping and no dependency on a team already over capacity.

If a supplier tells you it "integrates with everything", ask how long it takes and who pays.

3. "What patient data does it store?"

The question to ask is not "are you GDPR compliant", everyone says yes. It is what specific data leaves the device, to where, and on what basis.

With RVer, no personal or clinical patient data leaves the headset. What is sent is per-device usage statistics (which content played, on which headset, when) which identify nobody. Assigning a patient to a headset happens on the local network and never reaches a server.

This has a practical consequence IT will like: if no personal data leaves, the associated risk is far smaller, and the impact assessment gets simpler.

4. "Who is the data controller?"

The institution. RVer is supplied to healthcare institutions, which are responsible for their patients' data. That is the answer the data protection officer needs to hear, and it should be written into the contract, not into a conversation.

5. "What if the company disappears?"

A legitimate question, rarely asked in time. The answer hinges on one thing: does the system work offline?

If it does, the supplier disappearing switches nothing off: each headset carries on playing the library installed on it. If it does not, you are buying a dependency, and that belongs in the risk assessment.

6. "Who does the updates, and when?"

What matters is whether updates are mandatory, whether they can be deferred, and whether any of them force a service outage window. On equipment that runs offline, an update is a planned operation, not an interruption.

7. "Is this a medical device? Does that change anything for us?"

It changes three things IT should know about:

• There is technical documentation and a risk assessment that can be requested.
• There is an identified, accountable manufacturer.
• There is a formal route for reporting serious incidents: to the manufacturer and to the competent authority.

RVer's base product is registered in EUDAMED and with INFARMED (Portugal) as a Class I medical device, no. CDM 94571546 (Basic UDI-DI 56006195127RVERTZ), and bears the CE mark under MDR 2017/745. The RVer Motion, RVer Neuro and RVer Exposure modules are in development and are not covered by that registration.

8. "Who manages the accounts?"

There are no user accounts for patients. Device settings sit behind a protected menu clients cannot reach, and configuration is done at installation. Fewer accounts is less surface.

A summary to paste into an email

• Offline playback; no internet during a session.
• Management app in the browser, local network, no installation, no cloud.
• No integration with hospital systems.
• No personal or clinical patient data leaves the headset.
• Data controller: the institution.
• Class I medical device registered in EUDAMED (Basic UDI-DI 56006195127RVERTZ) and with INFARMED (Portugal, CDM 94571546), CE-marked (MDR 2017/745); modules not covered.
• No patient accounts; protected settings.

On the security of the platform itself we wrote separately in “The state of security on the RVer platform”, and on data protection in privacy and GDPR.