Cuándo un software es producto sanitario: la regla 11 del MDR

La pregunta no es qué hace, sino para qué dices que sirve

La cualificación de un software como producto sanitario depende de su finalidad prevista, que es lo que el fabricante declara. Si el software se destina a diagnóstico, prevención, seguimiento, predicción, pronóstico o tratamiento de una enfermedad, es producto sanitario. Si solo almacena, archiva, comunica o realiza una búsqueda simple, no lo es.

De ahí salen dos casos que conviene tener claros:

No es producto sanitario un sistema que muestra la historia clínica, un cuadro de mando de actividad asistencial, un catálogo documental o una herramienta que ordena citas por criterios administrativos.

Sí lo es un algoritmo que estima el riesgo de un paciente para orientar una decisión clínica, un sistema que detecta hallazgos en una imagen o una herramienta que sugiere un ajuste de dosis, aunque siempre haya un profesional revisando.

La revisión humana no saca al software de la categoría. Lo que importa es si su resultado se destina a informar una decisión clínica sobre un paciente concreto.

La regla 11, y por qué sorprende

La regla 11 del anexo VIII clasifica el software destinado a aportar información para decisiones diagnósticas o terapéuticas como clase IIa, y sube a clase III cuando esas decisiones pueden causar la muerte o un deterioro irreversible de la salud, y a IIb cuando pueden causar un deterioro grave o una intervención quirúrgica.

El efecto práctico es que casi nada queda en clase I. Y ese salto importa mucho: la clase I se autocertifica, mientras que a partir de IIa hace falta un organismo notificado, con lo que eso supone en tiempo, coste y sistema de gestión de calidad bajo ISO 13485.

Para el software de seguimiento que vigila parámetros fisiológicos, la regla prevé clase IIa, elevándose a IIb cuando la variación vigilada puede suponer peligro inmediato.

Dónde se cruza con el Reglamento de IA

Un software sanitario con IA queda en el anexo I del Reglamento de IA, es decir, alto riesgo por ser producto ya regulado con evaluación por tercero. Sus obligaciones son exigibles desde agosto de 2027, y la idea del legislador es que se integren en la evaluación de conformidad que ya se hace bajo el MDR, no que se dupliquen procedimientos.

En la práctica esto significa preparar una sola documentación técnica que responda a ambas normas: gestión de riesgos, datos de entrenamiento y validación, registro de eventos, supervisión humana, robustez y ciberseguridad.

La excepción del desarrollo interno

El MDR contempla un régimen específico para productos fabricados y utilizados dentro de la misma institución sanitaria: el artículo 5.5 exime del marcado CE si se cumplen condiciones estrictas, entre ellas que no exista en el mercado un producto equivalente disponible, que la fabricación se haga bajo un sistema de gestión de calidad apropiado y que la institución justifique documentalmente la necesidad y revise la experiencia de uso.

Es una vía real para desarrollos propios, pero no es una puerta trasera: exige documentación, justificación y revisión continua. Y desaparece en cuanto el software se cede a otro centro.

Cómo decidirlo sin bloquear el proyecto

La conversación productiva no es “¿esto es producto sanitario?” sino “¿qué queremos declarar que hace?”. Muchas herramientas útiles pueden formularse como apoyo a la gestión y quedar fuera del MDR, o formularse como apoyo a la decisión clínica y entrar. La diferencia está en el uso previsto que se documente, y en si el resultado se presenta al clínico como información para decidir sobre un paciente.

Conviene resolverlo al principio del proyecto, cuando aún se puede elegir. Al final ya no se elige: se hereda.