A Regra 11 do Anexo VIII do MDR é a regra de classificação que mais abalou a saúde digital. Sob a diretiva 93/42/CEE, a maioria dos softwares médicos se enquadrava na classe I, em autocertificação, sem organismo notificado. Sob o MDR, a maioria dos softwares de apoio à decisão se enquadra no mínimo na classe IIa. A mudança de classe não é um ajuste documental: ela faz entrar um organismo notificado na vida do desenvolvedor.
O que diz exatamente a Regra 11
O texto estabelece uma lógica em três tempos, que deve ser lida na ordem.
Primeiro tempo: a classe IIa por padrão. Os softwares destinados a fornecer informações usadas para tomar decisões com fins terapêuticos ou de diagnóstico enquadram-se na classe IIa. Esse é o ponto de partida, não a exceção. Todo software de apoio à decisão clínica entra no escopo por essa porta.
Segundo tempo: duas exceções para cima. Se as decisões que o software fundamenta tiverem um impacto suscetível de causar a morte ou uma deterioração irreversível do estado de saúde, o software enquadra-se na classe III. Se puderem causar uma grave deterioração do estado de saúde ou uma intervenção cirúrgica, ele enquadra-se na classe IIb. A intervenção cirúrgica é um critério por si só: um software cujo erro pode levar a operar, ou a operar mal, é IIb mesmo sem ameaça vital direta. Essas mesmas consequências graves que elevam a classe são também as que, uma vez o software no mercado, desencadeiam as obrigações de vigilância e prazos de notificação.
Terceiro tempo: a monitorização. Os softwares destinados a monitorizar processos fisiológicos enquadram-se na classe IIa. Passam à classe IIb unicamente se monitorizarem parâmetros fisiológicos vitais cujas variações possam representar um perigo imediato para a vida do paciente. As duas condições são cumulativas: parâmetro vital, e perigo imediato em caso de variação. Um software que acompanha a frequência cardíaca em terapia intensiva marca as duas caixas. Um aplicativo que registra a mesma frequência cardíaca em acompanhamento de bem-estar não marca nenhuma, e provavelmente nem sequer é um dispositivo médico.
Todos os demais softwares enquadram-se na classe I. Na prática, essa categoria tornou-se estreita: a revisão de 2025 da guidance dá um exemplo dela, sob condições estritas.
Uma regra de aplicação complementa o dispositivo: o software que comanda um dispositivo ou age sobre a sua utilização enquadra-se na mesma classe que esse dispositivo (Anexo VIII, regra 3.3). A Regra 11 aplica-se ao software classificado como tal.
Por que a reclassificação foi tão ampla
Sob a diretiva, o critério central era o lugar do software dentro de um dispositivo físico. O MDR desloca o critério para o impacto clínico de um erro do próprio software. Um software que sugere um diagnóstico diferencial parte de IIa, sobe para IIb ou III conforme as consequências de uma sugestão errada. Um software de planejamento de radioterapia acaba em IIb ou III: um erro de dosimetria pode causar uma deterioração irreversível. Um software de interpretação automática de ECG sobe para IIb assim que suas saídas orientam uma decisão de consequências graves.
A passagem de classe I para IIa ou IIb muda a natureza do processo: dossiê técnico completo, avaliação clínica substancial, ciclo de vida do software segundo a IEC 62304, plano de PMS e PMCF, e avaliação por um organismo notificado. O desenvolvedor que sobe de classe descobre ao mesmo tempo a ISO 13485 e deve auditar seu SGQ ISO 13485. Seus softwares, agora classificados como dispositivos médicos, ficam além disso sujeitos à identificação única e registro no EUDAMED, inclusive em distribuição desmaterializada. O desenvolvedor não preenche mais formulários. Ele muda de profissão regulatória.
MDCG 2019-11 Rev.1: a revisão de junho de 2025 embaralha as cartas
A guidance de referência sobre a qualificação e classificação dos softwares, MDCG 2019-11, foi revisada em 17 de junho de 2025. Não se trata de um retoque. Quatro contribuições dizem respeito diretamente aos desenvolvedores.
O fim do “standalone software”. A revisão abandona a noção de software autônomo em favor de uma abordagem por função: o que conta é a finalidade de cada funcionalidade, não o suporte que a hospeda. O termo europeu é MDSW (Medical Device Software). SaMD continua sendo o vocabulário IMDRF usado do outro lado do Atlântico, mas um dossiê europeu que raciocina em MDSW fala a língua de seu avaliador.
A abordagem modular. Um software pode ser dividido em módulos, alguns com finalidade médica, outros não. Cada módulo médico deve ter uma finalidade definida e documentada, e o desenvolvedor deve demonstrar que os módulos não médicos não comprometem nem a segurança nem o desempenho dos módulos médicos. A fronteira traça-se por escrito, na documentação técnica.
O surgimento do termo MDAI. A revisão nomeia pela primeira vez os softwares médicos com inteligência artificial (Medical Device AI), subconjunto dos MDSW submetidos em paralelo ao regulamento de IA. Os desenvolvedores de algoritmos de aprendizado têm agora dois textos a cruzar, não um.
A finalidade como pedra angular. A revisão martela a exigência de uma finalidade precisa, não ambígua, alinhada com os dados de validação e as alegações públicas do desenvolvedor, incluindo site e fichas de lojas de aplicativos. Uma classificação constrói-se sobre essa finalidade escrita. Uma finalidade vaga produz uma classificação indefensável.
A guidance distingue ainda os softwares que criam ou modificam informações médicas daqueles que se limitam a exibi-las ou armazená-las. Um algoritmo que trata dados para deles deduzir um resultado clínico está na primeira categoria. Um portal que exibe resultados de laboratório sem tratamento está na segunda, e a pergunta a lhe fazer é primeiro a da qualificação, antes da classe.
O que isso implica para um desenvolvedor em 2026
Um desenvolvedor que classificou seu software antes de junho de 2025 construiu seu raciocínio sobre a versão de 2019 da guidance. Essa versão foi substituída. As hipóteses de qualificação dos módulos, os casos-limite, os softwares de prevenção: são todos pontos que a Rev.1 decide de forma diferente ou mais fina. Uma classificação em classe I decidida em 2022 merece uma releitura com o texto de 2025 sobre a mesa, em particular se o software incorpora funções de apoio à decisão adicionadas ao longo das versões.
O cenário que custa caro é sempre o mesmo: um software classificado como I em seu lançamento, enriquecido funcionalidade por funcionalidade, cuja finalidade real deslizou para o apoio à decisão sem que a classificação acompanhasse. No dia em que um organismo notificado ou uma autoridade competente fizer a pergunta, a resposta constrói-se na urgência, com um histórico de versões contra si.
Reler sua classificação com a Rev.1 custa meio dia estruturado. Descobri-la obsoleta em auditoria custa uma reformulação sob pressão. O bom momento para revisar a classificação do seu software é aquele que você escolhe, não aquele que um auditor lhe impõe.
Fontes regulatórias: