Respuesta corta: cuando un software tiene un propósito previsto médico (diagnóstico, prevención, monitorización, predicción, pronóstico, tratamiento), se considera un dispositivo médico según el Reglamento de Dispositivos Médicos de la UE (MDR, 2017/745) y se le asigna una clase de riesgo: I, IIa, IIb o III, principalmente según la Regla 11 del Anexo VIII. La clase determina si puede autocertificarse (solo clase I) o si necesita un organismo notificado, la profundidad de la evaluación clínica requerida y cómo se realiza la vigilancia posterior a la comercialización. Por separado, el estándar de ingeniería IEC 62304 asigna al software una clase de seguridad: A (no es posible ninguna lesión), B (es posible una lesión no grave) o C (es posible la muerte o una lesión grave), que determina la cantidad de documentación, diseño y pruebas que requiere el ciclo de vida. Las dos clasificaciones están relacionadas pero son independientes, y ambas se establecen en función del daño que el software podría causar, no de su complejidad.
Paso 1: ¿Es un dispositivo en absoluto?
El software se considera un producto sanitario según el Reglamento de Productos Sanitarios de la UE (MDR) cuando su finalidad prevista es médica: diagnóstico, prevención, monitorización, predicción, pronóstico o tratamiento (Artículo 2(1)). El software que solo almacena, archiva, comunica, muestra o busca datos no es un producto sanitario; el software que crea o modifica información médica para apoyar una decisión de diagnóstico o tratamiento sí lo es, según la MDCG 2019-11.
La definición del MDR (Artículo 2(1)) se basa en el propósito previsto. El software que almacena, archiva, comunica, muestra o realiza búsquedas simples en datos no es un dispositivo (MDCG 2019-11 lo especifica). El software que crea o modifica información médica para apoyar una decisión de diagnóstico o tratamiento sí lo es. Un registro que muestra un valor de laboratorio con el rango de referencia del laboratorio no lo es; el software que indica al usuario que el valor indica una condición, o recomienda una dosis, sí lo es. Consulte ¿Es una aplicación de salud un dispositivo médico? para obtener detalles sobre el paso de calificación.
Paso 2: La clase de riesgo del MDR, Regla 11
La Regla 11 del MDR clasifica el software de productos sanitarios según el daño que una decisión errónea podría causar. El software que proporciona información para decisiones diagnósticas o terapéuticas es de clase IIa por defecto, clase IIb si dichas decisiones pueden causar un deterioro grave o requerir cirugía, y clase III si pueden causar la muerte o un deterioro irreversible. El software de monitorización es de clase IIa, o IIb para parámetros vitales.
| Software destinado a… | Clase MDR |
|---|---|
| proporcionar información utilizada para tomar decisiones con fines diagnósticos o terapéuticos (el valor predeterminado) | IIa |
| …donde tales decisiones puedan causar la muerte o un deterioro irreversible de la salud | III |
| …donde tales decisiones puedan causar un grave deterioro de la salud o una intervención quirúrgica | IIb |
| monitorizar procesos fisiológicos (el valor predeterminado) | IIa |
| …monitorizar parámetros fisiológicos vitales donde las variaciones podrían resultar en peligro inmediato para el paciente | IIb |
| cualquier otra cosa (software que es un dispositivo pero ninguno de los anteriores) | I |
La Regla 11 ha llevado la mayoría del software previamente de clase I a IIa o superior, que es la razón principal por la que el MDR se sintió como un cambio significativo para la salud digital. MDCG 2019-11 y el marco de riesgo de la IMDRF (significancia de la información × estado de la situación sanitaria) ayudan a ubicar casos límite. El software que controla o influye en un dispositivo de hardware toma la clase de ese dispositivo (Regla 3.3 de las reglas de implementación).
Consecuencias por clase: la clase I se autodeclara con un expediente técnico y registro, sin organismo notificado (excepto Im, Is, Ir); la IIa necesita una evaluación por parte de un organismo notificado del sistema de calidad y una muestra de la documentación técnica; la IIb lo mismo con un escrutinio de documentación más exhaustivo; la III una revisión completa de la documentación técnica y, cuando sea pertinente, la consulta de un panel de expertos. Todas las clases necesitan un sistema de gestión de calidad, una evaluación clínica proporcional a la clase, una persona responsable del cumplimiento normativo, UDI, registro en EUDAMED, vigilancia posterior a la comercialización y vigilancia.
Paso 3: La clase de seguridad del software IEC 62304
La clase de seguridad del software IEC 62304 evalúa el software de productos sanitarios según el peor daño al que podría contribuir, después de los controles de riesgo externos: clase A cuando no es posible ninguna lesión, clase B cuando es posible una lesión no grave, clase C cuando es posible la muerte o una lesión grave. La clase determina la cantidad de diseño, verificación y documentación que requiere el ciclo de vida del software.
IEC 62304 (2006, enmendado en 2015) es el estándar armonizado para los procesos del ciclo de vida del software de dispositivos médicos. Su clase de seguridad proviene de la peor situación peligrosa a la que el software puede contribuir, después de considerar las medidas de control de riesgos externas al software:
| Clase | Situación peligrosa podría conducir a… | Lo que requiere el ciclo de vida |
|---|---|---|
| A | ninguna lesión o daño a la salud | Plan de desarrollo de software, requisitos, lanzamiento; resolución de problemas; gestión de configuración |
| B | lesión no grave | A: más diseño arquitectónico, verificación de integración y pruebas de sistema, verificación de unidades documentada |
| C | muerte o lesión grave | B: más diseño detallado para cada unidad, segregación arquitectónica adicional, verificación más rigurosa |
Las clases se asignan por sistema de software y se pueden asignar por elemento de software después de la descomposición, de modo que solo las partes de riesgo lleven el rigor de la clase C; el estándar explica el argumento de segregación que esto requiere. ISO 14971 (gestión de riesgos) alimenta la clasificación; IEC 82304-1 añade requisitos a nivel de producto para software de salud que se ejecuta en plataformas de propósito general (teléfonos, nube).
Cómo interactúan los dos
La clase de riesgo del MDR y la clase de seguridad IEC 62304 son independientes: la clase del MDR (I a III) decide la vía regulatoria y la participación de organismos notificados, mientras que la clase IEC 62304 (A a C) decide el rigor del proceso de ingeniería. Una aplicación de clase IIa puede ser de clase 62304 B o C, dependiendo del daño que una salida errónea pudiera causar.
La clase MDR se refiere a la ruta regulatoria; la clase IEC 62304 se refiere al proceso de ingeniería. Una aplicación de clase IIa según la Regla 11 podría ser de clase B según IEC 62304 (información incorrecta podría llevar a un retraso no grave en la atención) o de clase C (si una sugerencia de dosis incorrecta pudiera ser mortal). Un dispositivo de clase I suele ser de clase A según IEC 62304, pero no necesariamente. Los organismos notificados esperan que el expediente técnico muestre la clase IEC 62304 con su justificación, los documentos del ciclo de vida a ese nivel y el enlace al expediente de gestión de riesgos. La ciberseguridad (MDCG 2019-16, IEC 81001-5-1) se evalúa junto con esto.
Ejemplo práctico
Un ejemplo práctico de SaMD: una aplicación de seguimiento de síntomas que registra, muestra y comparte síntomas no es un producto sanitario. Añadir una función que puntúa los síntomas según una escala validada y le indica al usuario cuándo buscar atención médica la convierte en un producto sanitario, de clase IIa del MDR por defecto, con clase IEC 62304 B, o clase C para un caso de uso cardíaco.
Una aplicación de seguimiento de síntomas que permite a los usuarios registrar síntomas, ver tendencias y compartirlas con su médico: no es un dispositivo (almacenamiento, visualización, comunicación). La misma aplicación añade una función que puntúa los síntomas registrados según una escala validada y le dice al usuario cuándo la puntuación sugiere que debe buscar atención: ahora es un dispositivo, clase IIa por defecto según la Regla 11 (información para una decisión diagnóstica; un "no es necesario buscar atención" incorrecto podría retrasar el tratamiento, grave pero no típicamente irreversible, por lo que no es IIb o III a menos que la condición objetivo lo haga así). IEC 62304: una falsa tranquilidad podría llevar a un retraso en la atención, de no grave a grave dependiendo de la condición, por lo que clase B, posiblemente C para un caso de uso cardíaco. Ruta: ISO 13485 SGC, organismo notificado, evaluación clínica de la escala, ingeniería de usabilidad (IEC 62366-1), vigilancia posterior a la comercialización.
Estados Unidos, brevemente
En Estados Unidos, la FDA regula el software como producto sanitario según su uso previsto, con clases I, II y III y las vías de aprobación 510(k), De Novo y PMA. La Ley "21st Century Cures Act" excluye el software administrativo, los productos de bienestar general, los registros de salud electrónicos y cierto soporte de decisiones clínicas del estatus de producto sanitario. La FDA reconoce la norma IEC 62304 como una norma de consenso.
La FDA regula el software como dispositivo médico bajo la misma lógica de propósito previsto, con clases I, II y III y vías 510(k), De Novo y PMA. La Ley 21st Century Cures (sección 3060) eliminó varias categorías del estado de dispositivo: software administrativo, bienestar general, registros de salud electrónicos y soporte de decisiones clínicas que permite al médico revisar de forma independiente la base de la recomendación (la guía de la FDA de 2022 sobre CDS la interpreta de forma restrictiva). La FDA reconoce IEC 62304 como un estándar de consenso y, desde 2023, requiere documentación de ciberseguridad para "dispositivos cibernéticos". ISO 13485 se convirtió en la base de la regulación del sistema de calidad de EE. UU. (QMSR) en 2026.
En Anpheros
Anpheros Daily almacena, muestra y comparte; no puntúa, interpreta ni recomienda, y su propósito previsto así lo indica. Por lo tanto, no es un dispositivo médico según la Regla 11 o las exclusiones de la Ley Cures, y el equipo aplica seguridad estilo ISO 27001 y prácticas de software documentadas sin la ruta de dispositivo. Si alguna vez se añadiera una función con propósito médico, se clasificaría según la Regla 11 y se desarrollaría bajo IEC 62304 antes de su lanzamiento. Consulte Transparencia de salud.
Esta página explica la regulación para equipos de producto e ingeniería. No constituye asesoramiento legal; los textos enlazados en Fuentes son la autoridad, y su oficial de protección de datos, organismo notificado o asesor decide para su caso. Última revisión: Octubre de 2026.
Páginas relacionadas
- ¿Es una aplicación de salud un dispositivo médico? Regla 11 del MDR de la UE
- MDR vs IVDR
- Explicación de CDS Hooks
- Mapa de regulación de datos de salud
- La Ley de IA de la UE y la IA en salud
Fuentes
- Reglamento (UE) 2017/745 (MDR), Anexo VIII, EUR-Lex
- MDCG 2019-11: Calificación y clasificación de software
- IEC 62304:2006+AMD1:2015, Procesos del ciclo de vida del software de dispositivos médicos
- IEC 82304-1:2016, Seguridad de productos de software de salud
- FDA: Guía sobre software de soporte de decisiones clínicas (2022)
- FDA: Software como dispositivo médico
Preguntas frecuentes
¿Puede el software ser de clase I según el MDR?
Sí, pero raramente: solo software con propósito médico que ni informa decisiones diagnósticas o terapéuticas ni monitoriza procesos fisiológicos. La mayoría de las aplicaciones que califican como dispositivos se ubican en IIa.
¿Necesita un dispositivo de clase IIa ensayos clínicos?
Necesita una evaluación clínica, que puede basarse en literatura, equivalencia y datos de rendimiento; se requiere una investigación clínica cuando la evidencia existente es insuficiente. El software que reclama un rendimiento diagnóstico generalmente necesita su propio estudio de rendimiento.
¿Es obligatorio IEC 62304?
Es un estándar armonizado, por lo que seguirlo es la presunción de conformidad con los requisitos de software del MDR (Anexo I, 17). Puede utilizar otro enfoque, pero luego debe demostrar la equivalencia, lo que nadie hace en la práctica.
¿Qué pasa con las funciones de IA?
Se aplican las mismas reglas, además de la Ley de IA de la UE: un dispositivo con evaluación de organismo notificado es un sistema de IA de alto riesgo según el Anexo I, con requisitos sobre datos, registro, transparencia y supervisión humana evaluados junto con el MDR.
Pruébalo gratis en el sandbox
Tu primera llamada FHIR en 5 minutos. Una API HL7 FHIR R4 con el consentimiento del paciente integrado: pruébala en el sandbox y luego conecta tu propia app o sistema de clínica.
Gratis · 30 pacientes sintéticos · sin tarjeta
Anpheros crea un historial médico que el paciente controla y puede compartir con cualquier clínica, en una plataforma HL7 FHIR R4, con sede en la UE. Estas guías te ayudan a entender y organizar tu salud; no reemplazan a tu médico.
Sobre Anpheros →