O que custa lançar uma app de VR médica de Classe I

A primeira vez que tentámos lançar o RVer como dispositivo médico, fizemos o que toda a equipa de software faz: construímos, testámos, demos por pronto. Depois mandámos o ficheiro técnico para o Infarmed e recebemos uma lista de setenta e três coisas em que nunca tínhamos pensado.

A maioria não eram bugs. Eram ausências — documentos que não tínhamos escrito, processos que não tínhamos formalizado, decisões que não tínhamos registado. O produto funcionava. O produto não era certificável.

O ficheiro de risco

Um dispositivo de Classe I sob MDR 2017/745 precisa de um ficheiro de gestão de risco antes de sair. Não como auditoria final. Como documento vivo que rastreia cada commit de código até uma análise de perigo documentada.

Foi a maior viragem. Deixámos de escrever código top-down ("construir o menu") e começámos a escrever requirement-up ("o utilizador tem de conseguir abortar uma sessão em menos de 2 segundos; a via de aborto não pode depender do comando; a UI de aborto tem de ser visível na visão periférica"). Cada decisão de implementação rastreia hoje até a um requisito que rastreia a um perigo.

O plano pós-mercado

Não se pode lançar e desaparecer. Os reguladores querem um plano documentado para o que acontece depois do lançamento: como monitorizamos eventos adversos, como comunicamos updates aos hospitais, como lidamos com um recall.

Para o RVer construímos uma pipeline leve de telemetria que sinaliza anomalias de sessão clínica (desconexões súbitas, sessões abandonadas, falhas de calibração) para uma fila de triagem. Tudo o que seja inédito vai para o consultor médico em menos de 24 horas.

A decisão que acertámos

Separar lógica clínica de conteúdo foi a melhor decisão arquitectónica que tomámos. O core clínico (timing de sessão, ramp de intensidade, comportamento de aborto) é versionado, assinado e bloqueado. O conteúdo (que praia, que floresta, que soundscape) vive num runtime separado — substituível sem re-certificar o dispositivo.

Essa decisão é a diferença entre precisar de uma re-submissão regulatória por cada novo ambiente, e nunca precisar de uma por updates de conteúdo. Comprou-nos meses, possivelmente anos, de velocidade.

A parte honesta

Foi difícil. Mais lento do que queríamos. Mais caro do que orçamentámos. E o trabalho de engenharia de que mais nos orgulhamos não está no gameplay — está no arnês regulatório que torna o gameplay legalmente vendável.

Se és uma equipa de software a pensar em VR regulada, o trabalho não é a VR. O trabalho é a forma regulatória que constróis à volta dela. Planeia para isso primeiro.