Caracterização dos riscos do software médico: o que devemos aprender com o guia IMDRF N81 (2025)?

MD, AI and Cybersecurity

29 January 2025

1. Um novo guia para compreender melhor os riscos do software

O rápido crescimento do software médico, quer seja autónomo (SaMD) ou incorporado num dispositivo, exige uma nova abordagem à avaliação dos riscos. Já não é apenas o dispositivo que presta cuidados, mas também a informação que gera, filtra ou recomenda. E esta informação pode, por sua vez, tornar-se uma fonte de risco.

Para ajudar os fabricantes a lidar com esta complexidade crescente, o IMDRF publicou um novo guia em janeiro de 2025: IMDRF/SaMD WG/N81 FINAL:2025, sobriamente intitulado Characterisation Considerations for Medical Device Software and Software-Specific Risk.

Este guia faz mais do que simplesmente reafirmar o óbvio. Fornece uma estrutura para melhor descrever o software médico, identificar factores de risco específicos do software e apoiar processos regulamentares para classificação e gestão de riscos.

2. O que a Orientação IMDRF N81 cobre (e o que não cobre)

O guia N81 é posicionado como um complemento ao guia IMDRF N12 de 2014, que propôs um quadro para a categorização de SaMD de acordo com o seu impacto clínico. Mas aqui, o âmbito é alargado: já não estamos a falar apenas de SaMD, mas de qualquer software que se enquadre na definição de dispositivo médico, incluindo os que estão incorporados em hardware.

O que oferece:

Um método para descrever com exatidão o software médico (utilização prevista + descrição funcional).
Uma lista de controlo para identificar riscos específicos relacionados com o software, em particular riscos informativos.
Uma linguagem comum para discutir a classificação dos riscos do software entre os organismos reguladores.

O que não é:

Uma ferramenta de classificação.
Uma norma de gestão de riscos.
Uma lista de requisitos.

Lembrete

O guia N81 é uma ferramenta de caraterização e não uma referência normativa. Ajuda a estruturar o seu pensamento, não a validar a sua conformidade.

3. Caracterização do software médico: dimensões a ter em conta

3.1) Utilização prevista: os 7 elementos-chave

O guia propõe uma estruturação clara da utilização pretendida/objetivo pretendido, articulada em torno de 7 elementos:

1. objetivo médico (diagnóstico, tratamento, acompanhamento, etc.)

2. doença ou patologia-alvo (gravidade, estádio, etc.)

3. população-alvo (idade, vulnerabilidade...)

4. utilizador-alvo (médico, doente, prestador de cuidados...)

5. local de utilização (domicílio, consultório, hospital...)

6. contra-indicações (se aplicável)

7. funções do software: entradas, saídas e o seu papel no percurso de cuidados

O Apêndice A do guia propõe um modelo de redação, útil para estruturar as secções 1 e 3 da documentação técnica.

3.2) Descrição do software: os 4 eixos propostos

Além disso, a descrição do programa informático deve abranger 4 eixos fundamentais:

Problema médico abordado (objetivo do software, nível de gravidade, população afetada).
Contexto de utilização (tipo de utilizador, ambiente, tempo de utilização no processo de cuidados).
Função e utilização do software (tipo de resultado, fonte de dados, nível de autonomia, explicabilidade, destinatário).
Gestão da mudança (aprendizagem, atualização, infraestrutura, implantação).

Pasted Graphic 1.png

4. Caracterização do risco de software: conceitos úteis

O guia N81 faz uma observação fundamental: os riscos de software nem sempre são físicos. Eles podem ser:

Informativos (dados erróneos, em falta ou mal interpretados).
Indirectos (decisão médica errada baseada nos resultados do software).
Relacionados com a redução da eficácia (enviesamento, perda de interpretabilidade, falta de fiabilidade).

Exemplo: um software que interpreta excessivamente os dados dos sensores pode levar a exames desnecessários ou mesmo a tratamentos inadequados.

O guia também sublinha a ligação com a norma ISO 14971: a metodologia de análise de risco continua a ser válida, mas as especificidades do software devem ser integradas.

5. Estudos de casos: quando a caraterização altera o nível de risco

5.1. Exemplo 1: Diagnóstico da pré-diabetes através de um algoritmo

Um programa informático analisa o historial dos doentes para detetar uma provável pré-diabetes. A orientação mostra que:

O risco é moderado, uma vez que o erro não implica qualquer perigo imediato.
Mas a exclusão de certos doentes (não assinalados pelo algoritmo) é um ponto de vigilância.
A autonomia da ferramenta e o facto de certos limiares não serem visíveis influenciam a perceção do risco.

Um bom exemplo de risco de informação indireto mas real.

5.2. Exemplo 2: terapia digital da dor

São comparados dois cenários:

Cenário 1: o software é utilizado como complemento dos analgésicos.
Cenário 2: o software é a única terapia possível (doentes intolerantes aos medicamentos)

A mesma função, o mesmo objetivo, mas níveis de risco muito diferentes. Em caso de falha, o segundo cenário apresenta um risco muito maior para o doente.

6. Na prática: como utilizar esta diretriz como fabricante

O guia N81 pode ajudá-lo a:

Estruturar o seu dossier técnico desde as primeiras fases de desenvolvimento.
Enriquecer as suas análises de risco ISO 14971, em particular para funções algorítmicas.
Clarificar a sua posição regulamentar face às autoridades competentes ou aos organismos notificados.

Lista de controlo

Definir claramente a utilização prevista (utilizando os 7 elementos).
Completar os 4 eixos da descrição do software.
Identificar os perigos específicos da informação e o contexto de utilização.
Avaliar o impacto da autonomia e da explicabilidade.
Documentar a gestão das alterações do software (actualizações, IA, personalizações).

7. Mini FAQ

Este guia substitui a norma ISO 14971?

Não, complementa-a. Fornece elementos específicos do software.

É obrigatório seguir as tabelas e listas de verificação do guia?

Não, o guia não tem valor normativo vinculativo. Trata-se de uma ferramenta de estruturação.

Pode ser utilizado para software incorporado em hardware?

Sim, o âmbito abrange todo o software que se enquadre na definição de dispositivo médico (DM).

O que acontece se o meu software estiver em constante evolução?

O guia inclui uma secção sobre gestão da mudança. Convida-o a caraterizar o grau de autonomia e o âmbito das actualizações.

O guia aborda os algoritmos de IA?

Indiretamente, sim, principalmente através das noções de explicabilidade, autonomia e desempenho escalável.

8. Conclusão

O guia IMDRF N81 não é nem uma norma nem um regulamento. É uma ferramenta estruturante de valor inestimável, que ajuda a pensar e a documentar os riscos do software de uma forma pormenorizada e contextualizada.

Na CSDmed, ajudamos os fabricantes a integrar estas boas práticas desde as primeiras linhas de código, para proteger o produto e facilitar o intercâmbio com as autoridades.

Precisa de ajuda para caraterizar ou documentar o seu software médico?

Entre em contacto connosco. Discutiremos a utilização clínica, a arquitetura do software e a estratégia regulamentar.