Características especiais do software
O software difere dos dispositivos médicos tradicionais em um aspecto fundamental: sua rápida evolução. Versões, atualizações, ambientes em nuvem, interfaces, funções de IA e riscos de cibersegurança são partes naturais de seu ciclo de vida. O MDR leva isso em consideração. Para softwares, o Anexo I exige, entre outras coisas, uma abordagem de ponta para o ciclo de desenvolvimento, gestão de riscos, verificação e validação, bem como requisitos mínimos para hardware, redes de TI e proteção contra acesso não autorizado. A cibersegurança, portanto, não é uma questão secundária de TI, mas sim parte integrante da segurança e do desempenho do produto.
Principalmente no caso de software, não é o código que importa, mas sim a finalidade médica. Um aplicativo de bem-estar não se qualifica como software médico simplesmente por ser tecnicamente complexo. Por outro lado, um aplicativo aparentemente simples pode muito bem se enquadrar no Regulamento de Dispositivos Médicos (MDR) se as informações nele contidas forem usadas para decisões diagnósticas ou terapêuticas. Diretrizes atuais do MDCG O documento sobre a qualificação e classificação de software esclarece precisamente essa distinção.
Requisitos do MDR – onde posso encontrá-los?
Qualquer pessoa que deseje colocar software no mercado em conformidade com o MDR Deve-se ler atentamente as seções relevantes do regulamento. As seções mais importantes são:
Anexo I , que estabelece os requisitos gerais de segurança e desempenho. Para software, os requisitos relativos ao processo de desenvolvimento, gestão de riscos, segurança da informação, validação e ambiente de TI são particularmente relevantes neste contexto.
Anexos II e III regem a documentação técnica, bem como os requisitos para a vigilância pós-comercialização. No caso de software, isso também inclui evidências de verificação e validação do software como parte da documentação do produto.
Anexo VIII , em particular Regra 11 A classificação de softwares médicos é fundamental. O MDCG 2019-11, revisado em 2025, explica os três princípios básicos da Regra 11: softwares que fornecem informações para decisões diagnósticas ou terapêuticas; softwares que monitoram processos fisiológicos; e “todos os outros softwares”. Dependendo da relevância clínica, a classificação pode variar da Classe I à Classe III.
Artigo 52 e Anexos IX a XI Descreva a avaliação da conformidade. Para dispositivos de Classe I, a declaração de conformidade é geralmente emitida pelo próprio fabricante; para dispositivos de Classe IIa e superiores, é necessária a participação de um Organismo Notificado.
Anexo XIV Por fim, é a referência central para avaliação clínica e acompanhamento clínico pós-comercialização (PMCF). Especialmente no caso de softwares, essa é uma área que muitas vezes é estabelecida sistematicamente tarde demais.
Os padrões mais importantes para software médico
O MDR especifica os requisitos regulamentares. Na implementação prática, porém, algumas normas são particularmente importantes porque definem o "estado da arte".
IEC 62304 É o padrão fundamental para o ciclo de vida de software médico. Ele descreve os processos de desenvolvimento e manutenção de software quando o próprio software é um dispositivo médico ou parte integrante de um dispositivo médico.
ISO 14971 é a norma de referência para a gestão de riscos de dispositivos médicos, incluindo explicitamente o Software como Dispositivo Médico.
ISO 13485 É a norma central de gestão da qualidade para dispositivos médicos em todo o ciclo de vida do produto. Para os fabricantes que buscam estabelecer uma organização robusta em conformidade com o MDR, ela serve como base operacional prática.
IEC 62366-1 Abrange a engenharia de usabilidade. Isso é particularmente relevante para software, pois operações incorretas, orientações enganosas para o usuário ou alarmes pouco claros podem ter consequências imediatas para a segurança.
IEC 82304-1 É particularmente relevante para softwares de saúde em plataformas de TI gerais, ou seja, para produtos sem hardware dedicado. A norma aborda a segurança em nível de produto e, portanto, é de grande importância para muitos softwares independentes ou Software como Dispositivo Médico (SaMD). É especialmente importante destacar que a IEC 82304-1 define requisitos específicos para a validação de SaMD e é referenciada simultaneamente na IEC 62304, que está harmonizada no escopo do MDR.
Classificação: O primeiro passo crucial
A pergunta inicial mais comum e importante é: em qual classe meu software se enquadra? É justamente aqui que muitos projetos falham — não por causa da tecnologia, mas devido a uma finalidade pouco clara. De acordo com o MDCG 2019-11 Rev.1, a Regra 11 é aplicada essencialmente com base em se o software fornece informações para decisões diagnósticas ou terapêuticas, monitora processos fisiológicos ou se enquadra na categoria residual. Os exemplos no guia mostram que softwares de diagnóstico ou de apoio à terapia podem ser rapidamente classificados como Classe IIa, IIb ou III, enquanto “todo o resto do software” é Classe I.
Do ponto de vista de um Organismo de Certificação, fica claro: a classificação não é uma etapa administrativa final, mas sim a base de toda a estratégia de autorização de comercialização. Ela influencia o escopo das evidências clínicas, a profundidade da documentação técnica, os requisitos do PMS/PMCF e, naturalmente, a questão de se e em que medida um Organismo de Certificação deve estar envolvido.
Dados clínicos: Não funcionará sem evidências clínicas.
Para softwares médicos, evidências clínicas não são um mero "desejável". A norma MDCG 2020-1 afirma explicitamente que softwares médicos com finalidade específica e benefício clínico declarado exigem evidências clínicas como parte de sua avaliação de conformidade. O objetivo é demonstrar que o software é seguro, atinge o desempenho esperado e proporciona o benefício clínico declarado.
Na prática, isso significa que, para o software, não basta simplesmente demonstrar que o algoritmo funciona tecnicamente. É preciso também avaliar se o software fornece as informações corretas em um contexto clínico, como essas informações são utilizadas e se, de fato, resultam em um benefício demonstrável. A avaliação clínica não é um documento pontual, mas um processo contínuo.
Acompanhamento Clínico Pós-Comercialização (PMCF)
O PMCF (Processamento de Manutenção Pós-Fabricação) é frequentemente subestimado no contexto de software. O MDR (Regulamento de Dispositivos Médicos) define PMCF como um processo contínuo que atualiza a avaliação clínica e deve estar ancorado no plano de PMS (Sistema de Gestão de Pós-Fabricação) do fabricante. É precisamente isso que o Modelo MDCG PMCF descreve explicitamente.
A PMCF (Public Product Safety Framework - Estrutura de Dados de Segurança do Produto) é particularmente importante para softwares, pois os contextos de uso, sistemas operacionais, interfaces, ameaças cibernéticas e padrões de uso clínico estão em constante mudança. Portanto, os fabricantes precisam não apenas de uma estratégia sólida de autorização de comercialização, mas também de um sistema robusto para coletar e avaliar dados de desempenho e segurança no mundo real após o lançamento no mercado e para incorporar essas informações em melhorias de produto.
Como funciona o processo de certificação na perspectiva de um Organismo de certificação?
O caminho para a certificação pode ser resumido em seis etapas principais.
Primeiro: O uso pretendido deve ser definido com precisão. Esta é a única maneira de determinar com clareza se o software se enquadra no MDR.
Segundo: O software deve ser classificado corretamente — normalmente com base no Anexo VIII e na Regra 11.
Terceiro: A empresa precisa de um sistema de gestão da qualidade adequado e de um processo de desenvolvimento verificável e de última geração, normalmente baseado em ISO 13485 , IEC 62304, ISO 14971 e outras normas, dependendo do produto.
Quarto: A documentação técnica deve ser completa, estruturada e rastreável, incluindo a verificação e validação do software.
Quinto: A avaliação clínica, o PMS (Pré-venda) e o PMCF (Pré-venda com Base na Capacidade de Adaptação) devem ser estruturados adequadamente para o produto.
Sexto: Se a classificação exigir a participação de um Organismo de Certificação, a avaliação formal da conformidade segue os procedimentos estabelecidos no MDR.
