En una era en la que la salud digital, la telemedicina y los diagnósticos impulsados por la IA se están generalizando, el Software como dispositivo médico (SaMD) ya no es un concepto de nicho; se erige como un pilar central de la innovación moderna en la atención médica. Sin embargo, ofrecer un producto SaMD seguro, eficaz y conforme en Europa requiere una navegación cuidadosa por regímenes regulatorios complejos.
Para las empresas y los equipos de asuntos regulatorios, el acceso exitoso al mercado en la Unión Europea significa cumplir con las exigencias del Reglamento de Dispositivos Médicos de la UE ( MDR , Reglamento (UE) 2017/745) y, cada vez más, con la Ley de Inteligencia Artificial de la UE ( Ley de IA , Reglamento (UE) 2024/1689). En conjunto, este régimen combinado da forma a cómo los desarrolladores diseñan, validan, supervisan y mantienen el software con funcionalidad médica.
Esta Guía de cumplimiento de SaMD presenta una descripción general concisa y centrada en Europa. Encontrará:
- Cómo determinar si su software califica como SaMD
- Requisitos clave según el MDR (clasificación, conformidad, evaluación clínica, post-comercialización)
- Mejores prácticas, errores y recomendaciones estratégicas
1. Definición de SaMD: ¿Qué califica?
¿Qué es SaMD?
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”.
En el contexto de la UE, y basado en MDCG 2019-11 , el software califica como dispositivo médico cuando el propósito previsto del fabricante incluye el diagnóstico, la prevención, el seguimiento, la predicción, el pronóstico, el tratamiento o el alivio de la enfermedad.
Determinantes clave
- Función médica prevista (no administrativa, no puramente de bienestar)
- Funcionamiento autónomo; el software no necesita integrarse en hardware médico
- Acción potencialmente autónoma (por ejemplo, análisis basado en la nube)
Ejemplos (y no ejemplos)
Ejemplos típicos de 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
Software no SaMD (o fuera del alcance)
- El software de programación o facturación de un centro de atención médica
- Una aplicación de seguimiento de actividad física para el bienestar general (a menos que se comercialice para el diagnóstico de enfermedades)
- Un visor de imágenes de propósito general utilizado en la clínica pero no destinado al diagnóstico
Debido a que la línea puede ser sutil, los equipos regulatorios deben documentar una breve justificación de si el software es, o no, un dispositivo médico, respaldada por afirmaciones funcionales, etiquetado y arquitectura.
2. El marco MDR de la UE para SaMD
Clasificación: regla 11 para software
El Anexo VIII del MDR incluye la Regla 11, que aborda la clasificación de riesgo del software. Según la Regla 11:
- Si el software informa las decisiones con fines diagnósticos o terapéuticos, a menudo se ubica en la Clase IIa, IIb, o incluso en la Clase III, según el riesgo y las consecuencias del error.
- Si el software monitorea los procesos fisiológicos, puede caer en la Clase IIa o IIb.
- El software destinado a funciones administrativas o no médicas normalmente se ubica en la Clase I.
Debido a que muchas herramientas SaMD avanzadas ahora activan la supervisión del Organismo Notificado, los desarrolladores deben planificar las evaluaciones de conformidad, la evaluación clínica y la documentación en consecuencia.
La hoja de ruta de cumplimiento del MDR
Para obtener el marcado CE según el MDR, siga estos pasos esenciales:
- Propósito previsto y contexto de uso: defina el propósito médico previsto, los grupos de usuarios, el entorno, las contraindicaciones y los escenarios de uso con precisión.
- Gestión de riesgos (ISO 14971): identifique los peligros y mitigue los riesgos, incluidos los errores de software, la deriva del algoritmo, la intrusión de ciberseguridad y los errores de datos. Gestione el riesgo durante todo el ciclo de vida (diseño, validación, implementación, mantenimiento).
- Gestión de calidad (ISO 13485): opere bajo un SGC que aborde el control de diseño, la gestión de la configuración, el control de cambios, el CAPA y la gestión de proveedores.
- Ciclo de vida del software (IEC 62304 / 82304-1): utilice estándares de ciclo de vida reconocidos para estructurar la arquitectura, el diseño a nivel de módulo, la verificación y validación, el mantenimiento y la configuración.
- Evaluación clínica (MDCG 2020-1): demuestre el beneficio clínico y el rendimiento con evidencia adecuada para el propósito.
- Documentación técnica (Anexo II/III): incluya la arquitectura, el análisis de riesgos, la verificación, la usabilidad, el etiquetado y las declaraciones de rendimiento.
- Evaluación de la conformidad: para las clases I(s/m/r), IIa y superiores, un Organismo Notificado revisa su SGC y documentación técnica y realiza auditorías.
- Marcado CE y Declaración de conformidad: una vez que demuestre la conformidad, aplique el marcado CE y firme la DoC para ingresar al mercado de la UE.
- Vigilancia posterior a la comercialización: mantenga el PMS y el PSUR, e integre los datos de rendimiento y los registros de monitoreo de IA.
- Actualizaciones de software y control de cambios: analice cada cambio, funcional, algorítmico o basado en datos, para decidir si representa un cambio significativo que requiere una nueva evaluación.
3. Ciberseguridad y protección del ciclo de vida
La ciberseguridad debe comenzar en el diseño y continuar durante el mantenimiento. Los principales requisitos incluyen:
- Garantizar la confidencialidad, la integridad y la disponibilidad (CIA) durante todo el ciclo de vida
- Definir los requisitos mínimos de TI y las configuraciones seguras
- Implementar la verificación y validación de los controles de seguridad
- Proporcionar instrucciones IFU claras sobre la protección de datos, las actualizaciones y la eliminación segura (GSPR 13.6)
- Mantener un plan de seguridad posterior a la comercialización para rastrear las vulnerabilidades y gestionar los parches
4. Desafíos, riesgos y recomendaciones estratégicas
| 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. |
5. Conclusión
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.
