Caracterización de los riesgos del software médico: ¿qué debemos aprender de la guía N81 (2025) del IMDRF?

MD, AI and Cybersecurity

29 Enero 2025

1. Una nueva guía para comprender mejor los riesgos del software

El rápido crecimiento del software médico, ya sea autónomo (SaMD) o integrado en un dispositivo, exige un nuevo enfoque de la evaluación de riesgos. Ya no es sólo el dispositivo el que presta asistencia, sino la información que genera, filtra o recomienda. Y esta información puede convertirse a su vez en una fuente de riesgo.

Para ayudar a los fabricantes a hacer frente a esta creciente complejidad, la IMDRF publicó una nueva guía en enero de 2025: IMDRF/SaMD WG/N81 FINAL:2025, sobriamente titulada Consideraciones de caracterización para software de dispositivos médicos y riesgo específico del software.

Esta guía hace más que simplemente reafirmar lo obvio. Proporciona un marco para describir mejor el software médico, identificar los factores de riesgo específicos del software y apoyar los procesos reglamentarios de clasificación y gestión de riesgos.

2. Qué cubre (y qué no cubre) la guía N81 de la IMDRF

La guía N81 se posiciona como un complemento de la guía IMDRF N12 de 2014, que propuso un marco para categorizar el SaMD según su impacto clínico. Pero aquí, el alcance se amplía: ya no estamos hablando solo de SaMD, sino de cualquier software que entre en la definición de dispositivo médico, incluidos los integrados en hardware.

Qué aporta:

Un método para describir con precisión el software médico (uso previsto + descripción funcional).
Una lista de comprobación para identificar los riesgos específicos relacionados con el software, en particular los riesgos informativos.
Un lenguaje común para debatir la clasificación de los riesgos del software entre los organismos reguladores.

Lo que no es:

Una herramienta de clasificación.
Una norma de gestión de riesgos.
Una lista de requisitos.

Recordatorio

La guía N81 es una herramienta de caracterización, no una referencia normativa. Ayuda a estructurar su pensamiento, no a validar su cumplimiento.

3. Caracterización del software médico: dimensiones a tener en cuenta

3.1. Uso previsto: los 7 elementos clave

La guía propone una estructuración clara del uso previsto/ finalidad prevista, articulada en torno a 7 elementos:

1. Finalidad médica (diagnóstico, tratamiento, seguimiento, etc.)

2. Enfermedad o afección objetivo (gravedad, estadio, etc.)

3. Población destinataria (edad, vulnerabilidad...)

4. Usuario destinatario (médico, paciente, cuidador...)

5. Entorno de uso (hogar, consulta, hospital...)

6. Contraindicaciones (si procede)

7. Funciones del software: entradas, salidas y su papel en la vía asistencial

En el apéndice A de la guía se propone un modelo de redacción, útil para estructurar las secciones 1 y 3 de su documentación técnica.

3.2. Descripción del software: los 4 ejes propuestos

Además, la descripción del software debe cubrir 4 áreas clave:

Problema médico abordado (propósito del software, nivel de gravedad, población afectada).
Contexto de uso (tipo de usuario, entorno, momento de uso en el proceso asistencial).
Función y uso del programa informático (tipo de resultado, fuente de datos, nivel de autonomía, explicabilidad, destinatario).
Gestión del cambio (aprendizaje, actualización, infraestructura, despliegue).

Pasted Graphic 1.png

4. Caracterización de los riesgos del software: conceptos útiles

La guía N81 hace una observación fundamental: los riesgos de software no siempre son físicos. Pueden ser:

Informativos (datos erróneos, ausentes o malinterpretados).
Indirectos (decisión médica errónea basada en los resultados del software).
Relacionados con la reducción de la eficacia (sesgo, pérdida de interpretabilidad, falta de fiabilidad).

Ejemplo: un software que sobreinterpreta los datos de los sensores puede dar lugar a exámenes innecesarios o incluso a tratamientos inadecuados.

La guía también subraya el vínculo con la norma ISO 14971: la metodología de análisis de riesgos sigue siendo válida, pero hay que integrar las especificidades del software.

5. Casos prácticos: cuando la caracterización cambia el nivel de riesgo

5.1. Ejemplo 1: diagnóstico de prediabetes mediante un algoritmo

Un programa informático analiza los historiales de los pacientes para detectar una probable prediabetes. La guía muestra que:

El riesgo es moderado, ya que el error no entraña ningún peligro inmediato.
Pero la exclusión de ciertos pacientes (no marcados por el algoritmo) es un punto de vigilancia.
La autonomía de la herramienta y el hecho de que ciertos umbrales no sean visibles influyen en la percepción del riesgo.

Un buen ejemplo de riesgo informativo indirecto pero real.

5.2. Ejemplo 2: terapia digital del dolor

Se comparan dos escenarios:

Escenario 1: el software se utiliza como complemento de los analgésicos.
Escenario 2: el software es la única terapia posible (pacientes intolerantes a los fármacos)

Misma función, mismo objetivo, pero niveles de riesgo muy diferentes. En caso de fallo, el segundo escenario presenta un riesgo mucho mayor para el paciente.

6. En la práctica: cómo utilizar esta guía como fabricante

La guía N81 puede ayudarle a:

Estructurar su expediente técnico desde las primeras fases de desarrollo.
Enriquecer sus análisis de riesgos ISO 14971, en particular para las funciones algorítmicas.
Aclarar su posición reglamentaria ante las autoridades competentes o los organismos notificados.

Lista de comprobación

Defina claramente su uso previsto (utilizando los 7 elementos).
Complete los 4 ejes de la descripción del software.
Identifique los peligros específicos de la información y el contexto de uso.
Evalúe el impacto de la autonomía y la explicabilidad.
Documente la gestión de cambios del software (actualizaciones, IA, personalizaciones).

7. Mini FAQ

¿Sustituye esta guía a la norma ISO 14971?

No, la complementa. Aporta elementos específicos del software.

¿Es obligatorio seguir las tablas y listas de comprobación de la guía?

No, la guía no tiene valor normativo vinculante. Es una herramienta de estructuración.

¿Puede utilizarse para software integrado en hardware?

Sí, el ámbito de aplicación abarca todo el software que entre dentro de la definición de DM.

¿Qué ocurre si mi software evoluciona constantemente?

La guía incluye una sección sobre la gestión del cambio. Le invita a caracterizar el grado de autonomía y el alcance de las actualizaciones.

¿Se ocupa la guía de los algoritmos de IA?

Indirectamente, sí. Sobre todo a través de las nociones de explicabilidad, autonomía y rendimiento escalable.

8. Conclusión

La guía IMDRF N81 no es una norma ni un reglamento. Es una herramienta de estructuración inestimable, que ayuda a pensar y documentar los riesgos del software de forma detallada y contextualizada.

En CSDmed, ayudamos a los fabricantes a integrar estas buenas prácticas desde las primeras líneas de código, para asegurar el producto y facilitar los intercambios con las autoridades.

¿Necesita ayuda para caracterizar o documentar su software médico?

Póngase en contacto con nosotros. Hablaremos del uso clínico, la arquitectura del software y la estrategia normativa.