MDCG 2019-11 rev.1: O que a nova versão muda para o software médico e IVD

Desde 2019, as orientações do MDCG 2019-11 têm sido uma referência para os fabricantes de software para dispositivos médicos (MDSW) e de software para diagnóstico in vitro (IVD MDSW). Mas, na prática, a primeira versão deixou muitas áreas cinzentas: casos-limite não resolvidos, falta de clareza em relação aos módulos de software e interpretações variadas da Regra 11

A versão revista, publicada em 17 de junho de 2025, vai muito além das actualizações cosméticas. Traz clarificações conceptuais e operacionais substanciais, com um forte enfoque no conceito de finalidade pretendida, estruturas modulares de software e interações com outros regulamentos, como a EHDS

Este artigo analisa as principais alterações, descreve as implicações concretas para os fabricantes e oferece cenários práticos para o ajudar a adaptar os seus produtos e documentação técnica

1. Lembrete: O que é que o MDCG 2019-11 abrange?

A orientação se concentra em dois conceitos principais

• Qualificação: determinar se um produto de software se enquadra no MDR ou IVDR e se qualifica como um dispositivo médico ou um acessório
• Classificação: atribuir a classe de risco adequada ao software com base na sua finalidade (particularmente ao abrigo da Regra 11 do RDM)

Também aborda casos especiais

• Software que acciona ou influencia um dispositivo médico,
• Diferenciação entre MDSW e módulos não médicos,
• Software implementado na nuvem, em dispositivos móveis ou incorporado em hardware

A finalidade pretendida é central: determina a qualificação, a classificação e os requisitos regulamentares aplicáveis

2. O que muda com a Revisão 1 (junho de 2025)

2.1 Esclarecimentos introduzidos

• Âmbito alargado para incluir software ao abrigo do Anexo XVI (produtos sem finalidade médica, por exemplo, dispositivos estéticos).
• Finalidade prevista: As orientações salientam a necessidade de uma declaração de finalidade clara, precisa e inequívoca - cada função com um objetivo médico deve ser clinicamente justificada.
• Abordagem modular: O documento reconhece que o software pode ser dividido em módulos. Alguns módulos podem ser MDSW, outros não. O fabricante deve:
• Definir claramente os limites funcionais,
• Documentar as interações,
• Provar que os módulos não médicos não comprometem a segurança ou o desempenho dos módulos médicos.
• Interoperabilidade com sistemas EHR: As orientações incorporam os novos requisitos do Espaço Europeu de Dados de Saúde (EHDS). A reivindicação de interoperabilidade acarreta obrigações adicionais

2.2 Novos exemplos

• Casos de software destinado a tratamento (nomeadamente nos domínios da saúde mental, da reabilitação e das perturbações alimentares)
• Software terapêutico que utiliza a realidade virtual ou jogos interactivos
• Exemplos em que os módulos não médicos são essenciais para o funcionamento mas não são abrangidos pelos RDM/ RDIV - desde que os limites estejam bem documentados
• Um exemplo raro de um software de Classe I (aplicação de comunicação assistida para doentes com autismo ou paralisia cerebral)

2.3 Classificação e Regra 11

O documento clarifica as três sub-regras

• 11a: Software que fornece informações utilizadas para decisões de diagnóstico ou terapêuticas
• 11b: Software para monitorizar processos fisiológicos
• 11c: Todos os outros programas informáticos

Inclui também uma matriz útil baseada na gravidade da situação clínica e no impacto do software nas decisões médicas, em conformidade com o quadro do IMDRF

3. Cenários práticos: O que isto significa para si

Caso 1 - Software de Reabilitação Modular

Um programador constrói uma plataforma de reabilitação que inclui

• Um módulo terapêutico de realidade virtual (MDSW),
• Um módulo de controlo administrativo (não MDSW),
• Um módulo para acompanhar o envolvimento do paciente

O que diz a Revisão 1

• Cada módulo deve ser avaliado separadamente
• O módulo terapêutico é classificado na Regra 11
• Os módulos não médicos devem ser documentados e a sua interação analisada no processo técnico

Caso 2 - Software ligado a um sistema de gestão de recursos humanos

Uma ferramenta de apoio à decisão é integrada num sistema de registo de dados eletrónico certificado

O que diz a Revisão 1

• Se o fabricante alegar interoperabilidade, a conformidade com a EHDS também é necessária (especificações de interoperabilidade, documentação, cibersegurança)
• A qualificação MDR por si só já não é suficiente: o quadro regulamentar torna-se duplo

4. Perguntas mais frequentes (FAQ)

1. O meu software continua a ser de classe IIa se eu não tiver alterado o algoritmo?

Não necessariamente. O que importa é o impacto nas decisões médicas. Mesmo sem alterações técnicas, a sua posição regulamentar pode evoluir ao abrigo das novas orientações

2. Posso declarar módulos não médicos como "fora do âmbito"?

Sim, mas apenas se puder justificar que não têm qualquer impacto na segurança ou no desempenho da MDSW

3. O alojamento em nuvem afecta a classificação do meu software?

Não. A classificação depende do objetivo pretendido e não da implementação técnica. No entanto, podem aplicar-se requisitos adicionais (cibersegurança, rastreabilidade, disponibilidade). Veja também: Nova orientação MDCG 2025-4: Requisitos para aplicações de software para dispositivos médicos em plataformas online

4. E se eu quiser ligar o meu software a um EHR?

Terá de cumprir tanto o EHDS como o MDR/IVDR. É necessário um dossier de interoperabilidade específico

5. O meu software foi anteriormente considerado não-MDSW. Devo requalificá-lo?

É possível. Os casos limite são agora abordados de forma mais clara e podem agora ser considerados MDSW

5. O que os fabricantes devem fazer agora

• Reavaliar o objetivo pretendido com o alinhamento clínico
• Mapear a arquitetura do seu software: módulos, fluxos de dados, interfaces
• Requalificar os módulos limítrofes à luz dos novos exemplos
• Atualizar a documentação técnica: justificação da classificação, análise da interface, conformidade com a EHDS, se aplicável
• Reavaliar as estratégias de avaliação clínica/desempenho para cada módulo

6. Conclusão

Esta é mais do que uma simples atualização: consolida o quadro interpretativo, resolve finalmente algumas ambiguidades de longa data (reivindicações de tratamento, lógica modular, interoperabilidade), reforçando simultaneamente a exigência de uma justificação sólida

Isto exigirá trabalho por parte dos fabricantes, mas também oferece uma oportunidade: construir arquitecturas de software e ficheiros técnicos mais robustos, claros e defensáveis

Precisa de apoio estratégico?

Na CSDmed, ajudamos os fabricantes

• Estruturar o objetivo pretendido e a arquitetura de software,
• Classificar o software de acordo com a lógica MDR/IVDR,
• Alinhar-se com os requisitos MDR, IVDR, AIA e EHDS sem complicar demais o desenvolvimento

Está a desenvolver um produto de software de saúde? Comece com a base correta. Vamos conversar.