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

> A maioria das equipas de VR sai quando acha que o produto está bom. Um dispositivo médico de Classe I sai quando um regulador o diz. Eis o gap, e o que nos custou fechá-lo.

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

---

A primeira vez que tentámos [lançar o RVer como dispositivo médico](https://rver.pt/blog/rver-registado-na-eudamed/), fizemos o que toda a equipa de software faz: construímos, testámos, demos por pronto. Depois sentámo-nos a preparar a documentação técnica para o registo no INFARMED e na EUDAMED, e apareceu 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 *declarável*.

### O ficheiro de risco

Um dispositivo de Classe I sob MDR 2017/745 precisa de [um ficheiro de gestão de risco](https://rver.pt/glossario/gestao-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](https://rver.pt/glossario/vigilancia-pos-comercializacao/), 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](https://rver.pt/blog/software-modular-vantagens-saude/) 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 voltar a declarar 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.

---

Publicado por amplified creations, estúdio de tecnologia independente em Leiria e Lisboa, Portugal. Contacto: info@amplifiedcreations.com · Mais: https://amplifiedcreations.com/llms.txt