El Software como Producto Sanitario (SaMD) ocupa una posición única en el panorama regulatorio. A diferencia de los productos sanitarios físicos, el software puede actualizarse continuamente, implementarse instantáneamente a través de fronteras y integrarse en flujos de trabajo clínicos de maneras difíciles de auditar o revertir. Estas características lo convierten en una de las categorías más complejas para introducir en el mercado bajo el Reglamento de Productos Sanitarios de la UE (MDR, Reglamento (UE) 2017/745).
Esta guía cubre lo que los desarrolladores de SaMD, las empresas de salud digital y los equipos regulatorios necesitan comprender para lograr y mantener el marcado CE bajo el MDR de la UE, desde la clasificación inicial hasta la vigilancia post-comercialización.
Para las empresas que desarrollan SaMD impulsado por IA, consulte nuestra guía complementaria: Ley de IA de la UE y Productos Sanitarios: Lo que los desarrolladores de SaMD necesitan saber
1. ¿Su software califica como SaMD?
No todo el software médico es un producto sanitario. El primer y más importante paso es determinar si su software entra dentro del ámbito de aplicación del MDR.
El Foro Internacional de Reguladores de Dispositivos Médicos (IMDRF) define SaMD como:
“Software destinado a ser utilizado para uno o más propósitos médicos que realizan estos propósitos sin ser parte de un dispositivo médico de hardware”.
Según el MDCG 2019-11, el documento de orientación de la UE sobre la cualificación y clasificación de software, el software califica como producto sanitario cuando el uso previsto del fabricante incluye uno o más de los siguientes: diagnóstico, prevención, monitorización, predicción, pronóstico, tratamiento o alivio de enfermedades o lesiones en pacientes individuales.
La palabra clave es previsto. No es la capacidad del software lo que determina su estado regulatorio, sino cómo el fabricante lo posiciona, etiqueta y comercializa.
Software que califica como SaMD:
- Una herramienta de análisis de imágenes basada en IA que ayuda a los radiólogos a detectar tumores
- Una aplicación móvil que predice eventos hipoglucémicos para pacientes diabéticos
- Un algoritmo en la nube que clasifica las señales de ECG para detectar arritmias
- Una herramienta de apoyo a la decisión clínica que recomienda opciones de tratamiento basadas en datos del paciente
Software que no califica como SaMD:
- Software de programación, facturación o administración sanitaria
- Aplicaciones de bienestar general o fitness no comercializadas para el diagnóstico o monitorización de enfermedades
- Visores de imágenes de propósito general utilizados en entornos clínicos pero no destinados al diagnóstico
- Software que impulsa o controla un producto sanitario de hardware (clasificado como software en un producto sanitario, no como un producto sanitario)
Si existe una incertidumbre genuina sobre si su software califica, documente el razonamiento explícitamente. Esta es una de las primeras cosas que buscará un Organismo Notificado.
2. Clasificación según la Regla 11 del MDR
Una vez que se confirma que el software es un producto sanitario, debe clasificarse según el Anexo VIII, Regla 11 del MDR. Esta es la regla específicamente diseñada para software, y determina si necesita un Organismo Notificado y qué ruta de evaluación de la conformidad se aplica.
La clasificación según la Regla 11 depende del uso previsto y de las consecuencias del error:
Clase III — Software destinado a proporcionar información utilizada para tomar decisiones de diagnóstico o terapia de afecciones que ponen en peligro la vida, donde un error podría causar un deterioro inmediato o un daño irreversible. Ejemplos: software que diagnostica infarto agudo de miocardio a partir de ECG, algoritmos de detección de cáncer utilizados en la planificación quirúrgica.
Clase IIb — Software destinado a proporcionar información para el diagnóstico o la terapia de afecciones graves donde un error podría causar un deterioro significativo. Ejemplos: software que clasifica imágenes radiológicas para la planificación del tratamiento, herramientas de IA que apoyan la estadificación oncológica.
Clase IIa — Software destinado a proporcionar información para el diagnóstico o la monitorización, donde es poco probable que los errores causen daños graves. Ejemplos: aplicaciones de monitorización de enfermedades crónicas, software que señala valores de laboratorio anormales para revisión clínica.
Clase I — Software destinado únicamente a fines administrativos, o software que monitoriza procesos fisiológicos en contextos no críticos. La Clase I no requiere la participación de un Organismo Notificado (a menos que sea estéril, con función de medición o quirúrgico reutilizable).
La implicación crítica: la mayoría de los SaMD clínicamente significativos —cualquier herramienta que informe una decisión clínica— se clasificarán como Clase IIa o superior, lo que requiere la revisión de un Organismo Notificado. Planifique esto desde el inicio del desarrollo.
3. La Hoja de Ruta de Cumplimiento del MDR para SaMD
Lograr el marcado CE para SaMD bajo el MDR requiere un proceso estructurado en múltiples dominios técnicos y de calidad. Estos no son elementos secuenciales, sino que deben construirse en paralelo e integrarse a lo largo del ciclo de vida del desarrollo del software.
Propósito Previsto y Contexto de Uso
Defina el propósito médico previsto con precisión: quiénes son los usuarios, en qué entorno se utilizará el software, qué entradas procesa y qué resultados o decisiones apoya. Esta definición impulsa la clasificación, los requisitos de evidencia clínica, el etiquetado y la gestión de riesgos. Los cambios en el propósito previsto en etapas avanzadas del desarrollo son costosos y disruptivos.
Gestión de Riesgos (ISO 14971)
Los peligros específicos del software van más allá de la falla física. Para SaMD, la gestión de riesgos debe abordar la deriva del algoritmo (el rendimiento del modelo que cambia con el tiempo en datos del mundo real), las vulnerabilidades de ciberseguridad, los errores de entrada de datos, las fallas de interoperabilidad y las consecuencias de los falsos positivos y falsos negativos en diferentes escenarios clínicos. La gestión de riesgos es una actividad de ciclo de vida, no termina con la presentación.
Sistema de Gestión de Calidad (ISO 13485)
Un SGC certificado según la ISO 13485 es obligatorio. Para el software, el SGC debe abordar específicamente el control de diseño, la gestión de configuración, el control de versiones, el control de cambios, la validación de software y los procesos CAPA para defectos de software. Muchas organizaciones de software que transitan de procesos de desarrollo comercial (Agile, DevOps) encuentran que adaptar estos a los requisitos de la ISO 13485 es uno de los desafíos operativos más significativos.
Ciclo de Vida del Software (IEC 62304 e IEC 82304-1)
La IEC 62304 es la norma armonizada para los procesos del ciclo de vida del software de productos sanitarios. Requiere la clasificación de seguridad del software (Clase A, B o C según la gravedad del daño si el software falla) y exige actividades específicas de documentación, verificación y validación proporcionales a esa clase. La IEC 82304-1 extiende esto al software sanitario independiente. El cumplimiento de estas normas, evidenciado en la documentación técnica, agiliza significativamente la revisión del Organismo Notificado.
Evaluación Clínica (MDCG 2020-1)
El SaMD debe demostrar un beneficio clínico, no solo un rendimiento técnico. Según el MDCG 2020-1, la evaluación clínica para el software debe incluir una revisión sistemática de la literatura, un análisis de datos clínicos de estudios o evidencia del mundo real, y una demostración clara de que los resultados del software conducen a un beneficio medible en la población de pacientes prevista. «El algoritmo es preciso» no es suficiente. La evaluación debe mostrar que la precisión clínica se traduce en un beneficio clínico.
Ciberseguridad
La ciberseguridad es un requisito de los Requisitos Generales de Seguridad y Rendimiento (RGSP) (Anexo I, sección 13.6) y se evalúa como parte de la conformidad. Los requisitos incluyen: garantizar la confidencialidad, integridad y disponibilidad de los datos durante todo el ciclo de vida; definir los requisitos mínimos de TI y las configuraciones seguras; implementar y validar los controles de seguridad; proporcionar una guía clara en las Instrucciones de Uso (IFU) sobre protección de datos, actualizaciones y desmantelamiento; y mantener un plan de seguridad post-comercialización que rastree las vulnerabilidades y gestione los parches. La guía MDCG 2019-16 y el marco de ciberseguridad IMDRF son las referencias principales.
Documentación Técnica (Anexo II y III)
La documentación técnica de SaMD debe incluir la documentación de la arquitectura del software, el plan de desarrollo del software y los registros del ciclo de vida, el archivo de gestión de riesgos, el archivo de ingeniería de usabilidad (IEC 62366), los registros de verificación y validación, el informe de evaluación clínica y el etiquetado. Para SaMD basado en IA, los Organismos Notificados esperan cada vez más la documentación de los datos de entrenamiento, la metodología de validación del modelo y el rendimiento en subgrupos demográficos.
Evaluación de la Conformidad y Marcado CE
Para la Clase IIa y superiores, un Organismo Notificado debe revisar el SGC y la documentación técnica. Una vez demostrada la conformidad, el fabricante emite una Declaración de Conformidad y aplica la marca CE. Después del marcado CE, la documentación técnica debe mantenerse actualizada y el Organismo Notificado debe realizar auditorías de vigilancia periódicas.
Vigilancia Post-Comercialización y Actualizaciones de Software
La vigilancia post-comercialización para SaMD no es pasiva. Los fabricantes deben monitorizar activamente los datos de rendimiento del mundo real, incluidos los resultados clínicos cuando estén disponibles, las métricas de rendimiento del algoritmo, los comentarios de los usuarios y los informes de incidentes. Críticamente, cada actualización de software debe evaluarse para determinar si constituye un cambio significativo que requiera una nueva evaluación o notificación al Organismo Notificado. Los cambios en el algoritmo, los datos de entrenamiento, el uso previsto o las afirmaciones clínicas son los más propensos a desencadenar este requisito.
4. Errores Comunes y Cómo Evitarlos
Subestimar la clasificación. Muchos desarrolladores clasifican inicialmente su software como Clase I, esperando autocertificarse, solo para descubrir durante la preparación de la documentación técnica que el propósito previsto cae claramente bajo la Regla 11 Clase IIa o superior. La clasificación debe confirmarse con la aportación regulatoria antes de que comience el desarrollo, no después.
Evidencia clínica dejada para el final. La evidencia clínica para SaMD lleva tiempo; los estudios prospectivos, las evaluaciones de rendimiento en el mundo real y las revisiones de la literatura no pueden realizarse en paralelo con la presentación al Organismo Notificado. Incorpore la estrategia de evidencia clínica en el plan de desarrollo desde el principio.
Tratar el SGC como un ejercicio de documentación. Los Organismos Notificados ahora realizan auditorías exhaustivas del SGC que prueban si los procesos están realmente integrados en la organización. Un SGC que existe solo en la documentación no sobrevivirá a una auditoría.
Ignorar las obligaciones post-comercialización. Los requisitos de vigilancia post-comercialización del MDR para el software son activos y continuos. La falta de establecimiento de procesos de vigilancia post-comercialización funcionales antes del lanzamiento es un hallazgo común en las auditorías post-certificación.
5. SaMD bajo el IVDR
Si el software está destinado a procesar datos de pruebas de diagnóstico in vitro —por ejemplo, software que interpreta datos de NGS para la toma de decisiones clínicas, o un algoritmo de diagnóstico complementario— puede estar regulado bajo el IVDR (2017/746) en lugar del MDR. Las reglas de clasificación difieren (el IVDR utiliza las Reglas 1-7 del Anexo VIII), y los requisitos de evidencia clínica bajo el IVDR son en algunos aspectos más estrictos, requiriendo una evaluación de rendimiento bajo la ISO 20916 y, para el software IVD de Clase D, consulta con la EMA.
Si su software se encuentra en el límite entre el MDR y el IVDR, una opinión regulatoria temprana es esencial. Equivocarse en el marco regulatorio al principio puede requerir una reelaboración completa de la documentación técnica.
Desafíos, Riesgos y Recomendaciones Estratégicas para SaMD
| Desafío | Mitigación / Mejor práctica |
|---|---|
| Propósito previsto o clasificación de software poco claros | Defina el propósito médico al inicio del proyecto. Alinee el IFU, el etiquetado, el marketing y los archivos técnicos con el uso previsto y la lógica de la Regla 11. |
| Evidencia clínica/de rendimiento insuficiente | Utilice estudios prospectivos o evaluaciones sólidas del rendimiento en el mundo real alineadas con el Anexo XIV del MDR y, cuando corresponda, las disposiciones de prueba de la Ley de IA. |
| Calidad y representatividad de los datos | Implemente la gobernanza de datos para la adquisición, el preprocesamiento y la validación. Asegúrese de que los conjuntos de datos representen a la población de pacientes prevista y al contexto de uso. |
| Transparencia y comprensión del usuario | Proporcione resultados clínicamente interpretables. Explique la funcionalidad, las limitaciones y las responsabilidades del usuario en el IFU y los materiales de capacitación. |
| Brechas de trazabilidad entre los requisitos, los riesgos y las pruebas | Mantenga una matriz de trazabilidad de requisitos a verificación que vincule los requisitos, los controles de riesgo, los resultados de la verificación y las afirmaciones clínicas. |
| Actualizaciones de software e impacto regulatorio | Establezca la gestión de cambios para evaluar si las actualizaciones son significativas y requieren una nueva evaluación. Integre estos controles en el SGC. |
| Restricciones de capacidad del Organismo Notificado y regulatorio | Involúcrese temprano con un Organismo Notificado calificado. Proporcione documentación clara y armonizada para agilizar las evaluaciones. |
| Evolución de los estándares y la guía regulatoria | Supervise las nuevas guías y estándares de la UE y MDCG (ISO 14971, ISO 13485, IEC 62304, IEC 81001-5-1) y la Ley de IA de la UE. Revise los procedimientos del SGC periódicamente para mantenerse alineado. |
Por dónde empezar: paso a paso para fabricantes de SaMD
La entrega de Software como dispositivo médico (SaMD) seguro y conforme requiere un enfoque estructurado que integre consideraciones regulatorias, técnicas y de calidad en todo el ciclo de vida. El cumplimiento del MDR de la UE garantiza que la seguridad, el rendimiento y el beneficio clínico sigan siendo claros y respaldados de manera consistente.
Las tecnologías avanzadas, incluida la IA, pueden mejorar la funcionalidad de SaMD; sin embargo, no deben eclipsar los principios básicos de seguridad, eficacia y supervisión humana. El mismo rigor regulatorio y las prácticas de gestión del ciclo de vida se aplican a todos los SaMD, independientemente de la tecnología subyacente.
Los fabricantes deben:
- Definir un propósito previsto claro alineado con el beneficio clínico
- Mantener un SGC que aborde las obligaciones del MDR y, cuando corresponda, de la Ley de IA
- Involúcrese temprano con los Organismos Notificados y mantenga la documentación, los riesgos y los controles de ciberseguridad consistentes
- Trate la vigilancia y el mantenimiento posteriores a la comercialización como una mejora continua
Al integrar estos principios, los fabricantes pueden alcanzar el cumplimiento de manera eficiente y ofrecer soluciones SaMD confiables y clínicamente valiosas.
