SaMD vs SiMD: software como dispositivo médico bajo FDA y EU MDR

TL;DR

El software como dispositivo médico (SaMD) es un software que cumple una finalidad médica sin formar parte de un dispositivo médico de hardware. El software en un dispositivo médico (SiMD) es un software que acciona o está integrado en un dispositivo de hardware. La definición internacional proviene del International Medical Device Regulators Forum (IMDRF). Este define el SaMD como "software destinado a ser utilizado para uno o más fines médicos que cumple dichos fines sin formar parte de un dispositivo médico de hardware". ¹

La distinción determina cómo se clasifica y se presenta el software. En la UE, el SaMD se clasifica por derecho propio, principalmente bajo la Regla 11 del MDR. El software que acciona un dispositivo asume la clase de dicho dispositivo. En los EE. UU., FDA autoriza las funciones de software de dispositivos a través de 510(k), De Novo o PMA. La lista de dispositivos habilitados para IA de FDA muestra el patrón. De los 1.614 dispositivos de la lista, el 96,2 % llegó al mercado a través de 510(k). El número autorizado por año aumentó de 18 en 2016 a 335 en 2025. ²

2026 trajo varios cambios. FDA revisó sus guías de soporte para la toma de decisiones clínicas y de bienestar general en enero y su guía de ciberseguridad en febrero. La UE trasladó las obligaciones de alto riesgo de la Ley de IA para dispositivos médicos habilitados para IA al 2 de agosto de 2028. Esta guía explica las definiciones, cómo saber si el software es en absoluto un dispositivo, cómo lo clasifican FDA y la UE, qué incluye una solicitud de registro y cómo lo tratan otros mercados principales.

SaMD, SiMD y MDSW: qué significa cada término

SaMD es un término definido. SiMD es una etiqueta descriptiva sin una definición legal vinculante. La UE utiliza un tercer término, MDSW, que abarca ambos.

El IMDRF es explícito sobre el límite: "El software no cumple la definición de SaMD si su finalidad prevista es accionar un dispositivo médico de hardware". También señala que "las aplicaciones móviles que cumplen la definición anterior se consideran SaMD". La política de 2022 de FDA sobre funciones de software de dispositivos establece que estas "pueden incluir 'Software como Dispositivo Médico (SaMD)' y 'Software en un Dispositivo Médico (SiMD)'". ³

En la UE, la guía MDCG 2019-11 Rev.1 sustituye "software independiente" por MDSW y señala que el término anterior "ya no se utiliza en el contexto de los Reglamentos sobre Dispositivos Médicos". La regla de aplicación 3.3 del MDR establece la consecuencia de clasificación: "El software que accione un dispositivo o influya en la utilización de un dispositivo se clasificará en la misma clase que el dispositivo. Si el software es independiente de cualquier otro dispositivo, se clasificará por derecho propio". ^{4 5}

TGA de Australia describe el SiMD en los términos más prácticos. Dicho software "generalmente se suministra preinstalado con el dispositivo de hardware", y "el SiMD se regula como parte del dispositivo en el que está instalado". ⁶

Primera pregunta: ¿el software es en absoluto un dispositivo médico?

Gran parte del software de salud no es un dispositivo. La finalidad prevista y, en los EE. UU., cinco exclusiones legales lo determinan.

En los EE. UU., la sección 520(o) de la Ley FD&C, añadida por la Ley 21st Century Cures, excluye cinco tipos de funciones de software de la definición de dispositivo:

• soporte administrativo;
• mantener o fomentar un estilo de vida saludable, no relacionado con enfermedades;
• registros electrónicos de pacientes, a menos que la función los interprete o analice;
• transferir, almacenar, convertir o mostrar datos, a menos que interprete o analice dichos datos;
• cierto soporte para la toma de decisiones clínicas (CDS). ⁷

La exclusión de CDS se aplica únicamente cuando el software no analiza imágenes ni señales médicas. Debe mostrar o analizar información médica, respaldar la recomendación de un profesional de la salud y permitir que dicho profesional revise de manera independiente los fundamentos de esta.

FDA revisó dos políticas clave en enero de 2026:

• Soporte para la toma de decisiones clínicas. La guía fue reemitida el 6 de enero de 2026 y corregida el 29 de enero de 2026. El software que proporciona una directiva específica de diagnóstico o tratamiento no cumple con el tercer criterio. En los casos en que solo una opción sea clínicamente adecuada y el software cumpla de otro modo con los criterios, FDA tiene la intención de ejercer discrecionalidad en el cumplimiento. El software que brinda recomendaciones a pacientes o cuidadores, en lugar de a profesionales de la salud, sigue siendo un dispositivo. ⁸
• Bienestar general. La política revisada del 6 de enero de 2026 señala que FDA "puede considerar ciertos productos que utilizan detección no invasiva" para estimar parámetros fisiológicos, como la presión arterial, la saturación de oxígeno o la glucosa, como productos de bienestar general. Esto se aplica solo bajo ciertas condiciones. El producto debe ser no invasivo, no debe sustituir a un dispositivo autorizado por FDA y no debe generar resultados que motiven una acción clínica específica. ⁹

En la UE, la guía MDCG 2019-11 Rev.1 establece una ruta de decisión. El software para "fines generales, incluso cuando se utiliza en un entorno sanitario", o para "fines de estilo de vida y bienestar" no es un dispositivo según el considerando 19 del MDR. El software que crea o modifica información médica para un paciente individual generalmente lo es. La revisión de junio de 2025 añade énfasis en una finalidad prevista redactada con claridad y en el software modular, donde solo algunos módulos califican.

Cómo se clasifica el SaMD según el riesgo

El marco del IMDRF es el lenguaje común. Luego, cada regulador lo convierte en sus propias clases legales.

El marco del IMDRF en N12 clasifica el SaMD según dos factores. El primero es el estado de la situación de salud: crítico, grave o no grave. El segundo es la importancia de la información para la decisión de atención médica: tratar o diagnosticar, guiar el manejo clínico o informar el manejo clínico. ¹⁰

El IMDRF advierte que esta "no es una clasificación regulatoria". En enero de 2025, publicó N81, que complementa a N12 con consideraciones de riesgo específicas para software para todo el software de dispositivos médicos, incluido el software que forma parte del hardware. ¹¹

La Regla 11 del MDR de la UE convierte la misma lógica en ley:

"El software destinado a proporcionar información que se utilice para tomar decisiones con fines diagnósticos o terapéuticos se clasifica en la clase IIa, excepto si tales decisiones tienen un impacto que pueda causar: — la muerte o un deterioro irreversible del estado de salud de una persona, en cuyo caso se clasifica en la clase III; o — un deterioro grave del estado de salud de una persona o una intervención quirúrgica, en cuyo caso se clasifica en la clase IIb. El software destinado a monitorear procesos fisiológicos se clasifica en la clase IIa, excepto si está destinado al monitoreo de parámetros fisiológicos vitales, donde la naturaleza de las variaciones de dichos parámetros sea tal que pueda dar lugar a un peligro inmediato para el paciente, en cuyo caso se clasifica en la clase IIb. Todo el demás software se clasifica en la clase I."

MDCG 2019-11 Rev.1 incluye una tabla ilustrativa que correlaciona las categorías del IMDRF con las clases del MDR. Excluyendo la Clase I, las situaciones críticas corresponden a la Clase III (tratar o diagnosticar), IIb (guiar) y IIa (informar). Las situaciones graves corresponden a IIb, IIa y IIa, y las no graves a IIa en todos los casos. Debido a la Regla 11, la mayoría del SaMD de soporte a la toma de decisiones en la UE requiere un organismo notificado. La propuesta de diciembre de 2025 de la Comisión Europea para revisar el MDR y el IVDR reescribiría la Regla 11 en torno a la matriz del IMDRF. Dicha propuesta sigue pendiente, por lo que se aplica la actual Regla 11. ¹² Para conocer el sistema completo de clases de la UE, consulte nuestra guía de clasificación del MDR de la UE.

En los EE. UU., el software se clasifica como cualquier otro dispositivo: por código de producto y regulación de clasificación. La mayor parte del SaMD se ubica en la Clase II. El software de procesamiento de imágenes radiológicas (código de producto QIH, 21 CFR 892.2050) y el software radiológico de triaje y notificación asistido por computadora (QAS, 21 CFR 892.2080) son casos típicos. Nuestra guía de clasificación de FDA explica cómo encontrar el código adecuado.

Qué muestran los datos del mercado de los EE. UU.

El software habilitado con IA es el segmento de más rápido crecimiento de las autorizaciones de dispositivos de FDA, y casi todo se tramita a través de 510(k).

La lista de dispositivos médicos habilitados con IA de FDA contenía 1.614 entradas en su actualización de septiembre de 2026, con decisiones finales hasta el 29 de junio de 2026. 1.553 (96,2 %) fueron autorizaciones 510(k), 40 fueron concesiones De Novo y 21 fueron aprobaciones PMA. Radiología fue el panel de revisión principal para 1.230 de ellos (76,2 %), seguido por cardiovascular (154) y neurología (73). FDA señala que la lista "no es un recurso exhaustivo de dispositivos médicos habilitados con IA".

Una segunda medición proviene del análisis de Pure Global de la exportación de 510(k) de openFDA. Las autorizaciones bajo códigos de producto cuyo nombre de dispositivo en FDA incluye "software" aumentaron de 7 en 2016 a 187 en 2025, pasando del 0,2 % al 5,8 % de todas las autorizaciones 510(k). En 2025, 94 de esas 187 correspondieron a software de procesamiento automatizado de imágenes radiológicas (QIH). ¹³ Esto subestima el SaMD, ya que muchos dispositivos de software se ubican bajo códigos de producto que no incluyen "software" en su nombre. Aun así, sigue siendo una línea de tendencia consistente.

Qué espera FDA en una solicitud de SaMD

La vía es la misma que para el hardware. La documentación es específica para el software y cuatro guías le dan forma.

1. Nivel de documentación del software. La guía de junio de 2023 de FDA reemplazó el antiguo "nivel de preocupación" por dos niveles de documentación. La Documentación Mejorada aplica "cuando un fallo o defecto de cualquiera de las funciones de software del dispositivo pudiera presentar una situación peligrosa con un riesgo probable de muerte o lesión grave". La evaluación se realiza antes de que se apliquen los controles de riesgo. De lo contrario, aplica la Documentación Básica. ¹⁴
2. Ciberseguridad. La Sección 524B de la Ley FD&C, en vigor desde el 29 de marzo de 2023, se aplica a los "ciberdispositivos". Estos son dispositivos que incluyen software, pueden conectarse a internet y podrían ser vulnerables a amenazas de ciberseguridad. Las solicitudes deben incluir un plan de monitoreo de vulnerabilidades, procesos de actualización y parches, y una lista de materiales de software. ¹⁵ La guía de ciberseguridad de FDA se revisó por última vez el 3 de febrero de 2026 para alinearse con el QMSR. ¹⁶
3. Planes de control de cambios predeterminados (PCCP). La Sección 515C permite a FDA autorizar modificaciones futuras planificadas por adelantado, de modo que los cambios realizados dentro del plan no requieran una nueva solicitud. La guía sobre PCCP de FDA para funciones de software de dispositivos habilitados con IA se finalizó el 4 de diciembre de 2024 y se revisó el 18 de agosto de 2025. Cubre 510(k), De Novo y PMA. ¹⁷ Una guía general sobre PCCP para todos los dispositivos sigue siendo un borrador de agosto de 2024. ¹⁸
4. Ciclo de vida de la IA. El borrador de guía del 7 de enero de 2025 de FDA sobre funciones de software de dispositivos habilitados con IA establece recomendaciones sobre el ciclo de vida y las solicitudes de comercialización. Estas abarcan la gestión de datos, la descripción del modelo, la validación del desempeño, el sesgo, la transparencia y el monitoreo poscomercialización. Aún era un borrador en octubre de 2026. ¹⁹ FDA también solicitó comentarios para el 19 de octubre de 2026 sobre un documento de discusión sobre IA generativa. ²⁰

Bajo el QMSR, el diseño y desarrollo (cláusula 7.3 de ISO 13485) se aplica a todos los dispositivos de Clase II y III y a los dispositivos de Clase I automatizados con software. Por lo tanto, la validación del software forma parte tanto del sistema de calidad como de la solicitud. Consulte nuestra tabla de correspondencias de 21 CFR 820 a ISO 13485.

Requisitos de la UE más allá de la Regla 11

• Evidencia clínica. MDCG 2020-1 pide tres componentes para todo MDSW: asociación clínica válida (validez científica), desempeño técnico o analítico, y desempeño clínico. Estos siguen a IMDRF N41. ²¹
• Requisito general de seguridad y funcionamiento 17. El Anexo I exige que el software se desarrolle "de conformidad con el estado del arte teniendo en cuenta los principios del ciclo de vida del desarrollo, la gestión de riesgos, incluida la seguridad de la información, la verificación y la validación".
• La Ley de IA. El Reglamento (UE) 2024/1689 considera de alto riesgo los sistemas de IA en dispositivos médicos que requieren una evaluación de la conformidad por parte de un organismo notificado. El Ómnibus Digital, Reglamento (UE) 2026/1744, publicado en el Diario Oficial el 24 de julio de 2026, trasladó dichas obligaciones al 2 de agosto de 2028. ²² MDCG 2025-6 explica cómo interactúan el MDR y la Ley de IA. Establece que la Ley de IA "no afecta la clasificación de riesgo de los dispositivos médicos". Su referencia a una fecha de agosto de 2027 es anterior al Ómnibus. ²³

Cómo tratan otros mercados principales el SaMD

Fuentes: ²⁴, ²⁵ y ²⁶. Para el acceso al mercado específico de IA en más de 30 países, consulte nuestro informe de investigación sobre IA como dispositivo médico.

Las normas detrás de un expediente de SaMD

• IEC 62304:2006+A1:2015 establece los procesos del ciclo de vida del software y las clases de seguridad del software A, B y C. La edición 2 todavía es un borrador de comité y la IEC prevé su publicación en octubre de 2028. Planifique con base en la versión consolidada de 2015. ²⁷
• IEC 82304-1:2016 cubre los productos de software para la salud que se ejecutan en plataformas informáticas generales sin hardware dedicado, lo cual es típico del SaMD. ²⁸
• IEC 81001-5-1:2021 establece las actividades de seguridad a lo largo del ciclo de vida del software para la salud. ²⁹
• La gestión de riesgos de ISO 14971 y la ingeniería de usabilidad de IEC 62366-1 se aplican al SaMD al igual que a cualquier dispositivo. Nuestra guía sobre ISO 14971 cubre el expediente de riesgos.

SaMD frente a SiMD: qué cambia en su expediente

Errores comunes

• Redactar la finalidad prevista al final. La clasificación, la evidencia clínica y la condición de bienestar o CDS se derivan de ella. Redáctela primero y mantenga las afirmaciones comerciales dentro de ella.
• Asumir que "soporte para la toma de decisiones" significa "no es un dispositivo". En EE. UU., deben cumplirse los cuatro criterios de CDS. En la UE, la Regla 11 sitúa a la mayoría del software de soporte para la toma de decisiones en la Clase IIa o superior.
• Tratar una aplicación móvil como de una categoría inferior. Una aplicación que cumple con la definición de SaMD es SaMD.
• Citar el antiguo "nivel de preocupación". FDA lo reemplazó por Documentación Básica y Mejorada en junio de 2023.
• Planificar para la fecha de la Ley de IA de 2027. Las obligaciones de alto riesgo para dispositivos médicos habilitados para IA ahora se aplican a partir del 2 de agosto de 2028.
• Lanzar actualizaciones de algoritmos sin un plan. Sin un PCCP, un cambio significativo por lo general requiere una nueva presentación.

Cómo ayuda Pure Global

Determinamos si el software es un dispositivo y redactamos la finalidad prevista. Clasificamos el software según FDA, la Regla 11 del EU MDR y otros sistemas, y preparamos expedientes de 510(k) y De Novo con documentación Básica o Mejorada, ciberseguridad y contenido de PCCP. Nuestro equipo también brinda soporte en las presentaciones ante organismos notificados de la UE y registros en más de 30 mercados. Consulte nuestra página sobre regulación de SaMD o póngase en contacto con nuestro equipo.

Cómo elaboramos las cifras

• Dispositivos habilitados para IA: nuestro recuento de la lista de dispositivos médicos habilitados para IA de FDA (CSV), actualizada en septiembre de 2026. Las decisiones abarcan hasta el 29 de junio de 2026, y 2026 es un año parcial. La participación de cada vía proviene del prefijo del número de presentación (K, DEN o P).
• Códigos de producto denominados como software: códigos de producto en el archivo de códigos de producto de FDA con fecha del 12 de octubre de 2026 cuyo nombre de dispositivo contiene "software", cotejados con la exportación de openFDA 510(k) con fecha del 12 de octubre de 2026. Pure Global conserva ambos en su lago de datos. Los recuentos corresponden al año calendario de la decisión.