Lo que cuesta lanzar una app de VR médica de Clase I
La mayoría de equipos de VR salen cuando creen que está bien. Un dispositivo médico de Clase I sale cuando un regulador lo dice. Aquí está la brecha, y lo que nos costó cerrarla.
La primera vez que intentamos lanzar RVer como dispositivo médico, hicimos lo que todo equipo de software hace: lo construimos, lo probamos, lo dimos por listo. Luego enviamos el expediente técnico a Infarmed y recibimos una lista de setenta y tres cosas en las que nunca habíamos pensado.
La mayoría no eran bugs. Eran ausencias — documentos que no habíamos escrito, procesos que no habíamos formalizado, decisiones que no habíamos registrado. El producto funcionaba. El producto no era certificable.
El expediente de riesgo
Un dispositivo Clase I bajo MDR 2017/745 necesita un expediente de gestión de riesgo antes de salir. No como auditoría final. Como documento vivo que rastrea cada commit de código hasta un análisis de peligro documentado.
Fue el mayor cambio. Dejamos de escribir código top-down ("construir el menú") y empezamos a escribir requirement-up ("el usuario debe poder abortar una sesión en menos de 2 segundos; la vía de aborto no puede depender del mando; la UI de aborto debe ser visible en la visión periférica"). Cada decisión de implementación se rastrea hoy hasta un requisito que se rastrea hasta un peligro.
El plan poscomercialización
No puedes lanzar y desaparecer. Los reguladores quieren un plan documentado para lo que pasa después del lanzamiento: cómo monitorizamos eventos adversos, cómo comunicamos updates a los hospitales, cómo gestionamos un recall.
Para RVer construimos una pipeline ligera de telemetría que señala anomalías de sesión clínica (desconexiones súbitas, sesiones abandonadas, fallos de calibración) hacia una cola de triaje. Todo lo novedoso va al asesor médico en menos de 24 horas.
La decisión que acertamos
Separar lógica clínica de contenido fue la mejor llamada arquitectónica que hicimos. El core clínico (timing de sesión, ramp de intensidad, comportamiento de aborto) está versionado, firmado y bloqueado. El contenido (qué playa, qué bosque, qué soundscape) vive en un runtime separado — intercambiable sin re-certificar el dispositivo.
Esa decisión es la diferencia entre necesitar una re-submisión regulatoria cada vez que añadimos un entorno, y nunca necesitar una por updates de contenido. Nos compró meses, posiblemente años, de velocidad.
La parte honesta
Fue difícil. Más lento de lo que queríamos. Más caro de lo que presupuestamos. Y el trabajo de ingeniería del que más orgullosos estamos no está en el gameplay — está en el arnés regulatorio que hace el gameplay legalmente vendible.
Si eres un equipo de software pensando en VR regulada, el trabajo no es la VR. El trabajo es la forma regulatoria que construyes a su alrededor. Planifícalo primero.