Si tu software diagnostica, predice, monitoriza o ayuda a decidir un tratamiento, puede ser un producto sanitario. Te ayudamos a calificarlo y clasificarlo, a definir la ruta de marcado CE, la licencia de fabricante y los registros, y llevamos la dirección regulatoria del proyecto, incluido su encaje con el Reglamento de IA.
¿Tu software es producto sanitario? Diagnóstico gratuito
Cuéntanos qué hace tu software y para quién, y te decimos si entra en el MDR y qué ruta regulatoria le corresponde.
Trabajamos con startups de salud y equipos de producto para que la regulación acompañe al desarrollo en lugar de frenarlo al final.
Analizamos la finalidad prevista y las funciones del software frente a la definición del MDR y la guía MDCG 2019-11 para saber si es producto sanitario, accesorio o queda fuera.
Determinamos la clase (I, IIa, IIb o III) aplicando la regla 11 del anexo VIII y el resto de reglas pertinentes, y dejamos justificado el razonamiento.
Definimos si basta la declaración del fabricante o hace falta un organismo notificado, y ordenamos la documentación técnica, la evaluación clínica y el sistema de calidad.
Si fabricas desde España, preparamos la licencia previa de funcionamiento de la AEMPS, que la Instrucción PS 1/2025 extiende a los fabricantes de software.
Articulamos la persona responsable del cumplimiento normativo (PRRC), el registro del agente y del producto en EUDAMED y el sistema UDI.
Si el software usa IA y, como producto sanitario, necesita organismo notificado, es de alto riesgo: coordinamos ambas normas en una sola documentación.
No lo decide la tecnología, sino la finalidad médica que el fabricante atribuye al software.
Un software que analiza imágenes o datos del paciente para detectar o diagnosticar una enfermedad tiene finalidad médica y suele ser producto sanitario.
Si proporciona información que se usa para tomar decisiones diagnósticas o terapéuticas, la regla 11 lo clasifica, como mínimo, en la clase IIa.
El software que monitoriza procesos fisiológicos es de clase IIa, y de clase IIb si vigila parámetros vitales cuya variación puede suponer un peligro inmediato.
Un software de citas, facturación o archivo que solo almacena o transmite datos, sin finalidad médica propia, en principio no es producto sanitario.
Datos del Reglamento (UE) 2017/745 (MDR), de la guía MDCG 2019-11 y del Reglamento (UE) 2024/1689 de inteligencia artificial.
La definición de producto sanitario incluye expresamente el software con finalidad médica, solo o combinado con otros productos.
El software que informa decisiones diagnósticas o terapéuticas es, como mínimo, de clase IIa; IIb o III según la gravedad del posible daño.
Por regla general, en la clase I el fabricante declara la conformidad por sí mismo; desde la clase IIa interviene un organismo notificado.
El fabricante debe disponer de una persona responsable del cumplimiento normativo; las micro y pequeñas empresas pueden tenerla externa, disponible de forma permanente y continua.
Desde esa fecha son obligatorios cuatro módulos: agentes, UDI y productos, organismos notificados y certificados, y vigilancia del mercado.
Fecha desde la que se aplican las obligaciones de alto riesgo a la IA de productos regulados, como los sanitarios, tras el Reglamento (UE) 2026/1744.
Calificamos y clasificamos tu producto, diseñamos la ruta regulatoria y la dirigimos contigo hasta la comercialización.
Cuando el fabricante le atribuye una finalidad médica: diagnosticar, prevenir, monitorizar, predecir, pronosticar, tratar o aliviar una enfermedad, entre otras recogidas en el artículo 2 del Reglamento (UE) 2017/745. La guía MDCG 2019-11 explica cómo hacer esa calificación paso a paso.
Es la regla del anexo VIII del MDR que clasifica el software. El que proporciona información para decisiones diagnósticas o terapéuticas es de clase IIa; de IIb si esas decisiones pueden causar un deterioro grave o una intervención quirúrgica, y de III si pueden causar la muerte o un deterioro irreversible. El resto del software sanitario es de clase I.
No, si su finalidad es el bienestar general o el estilo de vida y no una finalidad médica. La frontera está en lo que declara el fabricante en el etiquetado, las instrucciones y la publicidad: prometer detectar o tratar una enfermedad cambia la calificación.
Si fabricas desde España software que es producto sanitario, sí. La Instrucción PS 1/2025 de la AEMPS incluye a los fabricantes de software en la licencia previa de funcionamiento, con especial atención a los procedimientos de diseño, desarrollo, etiquetado y validación.
Es la persona responsable del cumplimiento normativo del artículo 15 del MDR. Todo fabricante debe tenerla. Las micro y pequeñas empresas no están obligadas a tenerla en plantilla, siempre que dispongan de ella de forma permanente y continua.
Si tu software es un sistema de IA y, como producto sanitario, necesita un organismo notificado, se considera de alto riesgo. Esas obligaciones se aplicarán desde el 2 de agosto de 2028, según el calendario fijado por el Reglamento (UE) 2026/1744. La guía MDCG 2025-6 explica cómo coordinar ambas normas.
Es la base de datos europea de productos sanitarios. Desde el 28 de mayo de 2026 son obligatorios sus módulos de registro de agentes, de UDI y productos, de organismos notificados y certificados, y de vigilancia del mercado.
Llevar el hilo regulatorio de principio a fin: calificación y clasificación, plan de marcado CE, interlocución con el organismo notificado y con la AEMPS, licencia, PRRC, registros y actualización de la documentación cuando cambia el software.
La regulación del software sanitario se decide en las primeras semanas del proyecto: una finalidad mal escrita o una clase mal elegida se pagan después en tiempo y en rediseño.
Todo parte de una frase: qué hace el software, para quién y con qué fin médico. De ella dependen la calificación, la clase y el esfuerzo regulatorio.
Desde la clase IIa necesitas un organismo notificado. Plantear pronto esa relación evita que la certificación se convierta en el cuello de botella del lanzamiento.
Ciclo de vida del software, gestión de riesgos, evaluación clínica y seguridad de la información: la documentación técnica debe reflejar cómo se desarrolla de verdad el producto.
Fuentes: Reglamento (UE) 2017/745, guías MDCG 2019-11 y MDCG 2025-6, Instrucción PS 1/2025 de la AEMPS y Reglamento (UE) 2024/1689, modificado por el Reglamento (UE) 2026/1744.
Si desarrollas software médico o IA clínica, estos términos aparecen en la documentación técnica, en la relación con el organismo notificado y ante la AEMPS.
Software que por sí mismo tiene una finalidad médica, sin formar parte de un equipo físico.
Norma europea de productos sanitarios, que incluye el software con finalidad médica.
Regla del anexo VIII del MDR que asigna la clase del software según el riesgo de las decisiones que informa.
Uso al que el fabricante destina el producto según el etiquetado, las instrucciones y la publicidad.
Entidad designada que evalúa la conformidad de los productos de clase IIa, IIb y III.
Figura del artículo 15 del MDR que vela por la conformidad, la documentación y la vigilancia.
Sistema de identificación que permite rastrear cada producto, también el software, a lo largo de su vida.
Registro europeo de agentes, productos, certificados y vigilancia del mercado.
Norma europea de inteligencia artificial. Considera de alto riesgo la IA de productos sanitarios que requieren organismo notificado.
Clase I: software sanitario que no informa decisiones diagnósticas o terapéuticas ni monitoriza procesos fisiológicos.
Clase IIa o superior: software que informa decisiones clínicas o monitoriza procesos fisiológicos.
Clase I: declaración del fabricante, por regla general sin organismo notificado.
Clase IIa o superior: con organismo notificado, que revisa el sistema de calidad y la documentación técnica.
Clase I: si usa IA, en principio no es de alto riesgo por la vía del producto sanitario.
Clase IIa o superior: si usa IA, es un sistema de alto riesgo, con obligaciones desde el 2 de agosto de 2028.
Clase I: menor: no depende de la agenda de un tercero.
Clase IIa o superior: mayor: depende de la evaluación del organismo notificado.
Clase I: necesarias igualmente si el fabricante está en España.
Clase IIa o superior: necesarias igualmente si el fabricante está en España.
Son los que obligan a rehacer documentación, a reclasificar el producto o a retrasar el lanzamiento.
El Reglamento (UE) 2017/745 sobre productos sanitarios (MDR) incluye expresamente el software en la definición de producto sanitario. Por eso una aplicación, un algoritmo o un sistema de IA clínica pueden necesitar marcado CE, licencia de fabricante y registro en EUDAMED antes de comercializarse en la Unión Europea.
Lo decide la finalidad prevista que el fabricante atribuye al software: diagnosticar, prevenir, monitorizar, predecir, pronosticar o tratar una enfermedad, entre otras. La guía MDCG 2019-11, revisada en 2025, ofrece los criterios para hacer esta calificación y distinguir el software sanitario del que solo almacena, archiva o transmite datos.
La regla 11 del anexo VIII del MDR sitúa en la clase IIa, como mínimo, al software que proporciona información para tomar decisiones diagnósticas o terapéuticas, y en las clases IIb o III cuando esas decisiones pueden causar un deterioro grave o irreversible, o la muerte. El software que monitoriza procesos fisiológicos es de clase IIa, o IIb si vigila parámetros vitales críticos. El resto es de clase I.
Salvo en la clase I, la evaluación de la conformidad exige un organismo notificado. El fabricante debe designar una PRRC (artículo 15 del MDR), registrarse junto con sus productos en EUDAMED y asignarles un UDI. Si fabrica desde España, necesita además la licencia previa de funcionamiento de la AEMPS, que la Instrucción PS 1/2025 extiende a los fabricantes de software.
El Reglamento (UE) 2024/1689 de IA considera de alto riesgo los sistemas de IA que son productos sanitarios, o componentes de seguridad de ellos, cuando necesitan un organismo notificado. Tras el Reglamento (UE) 2026/1744, esas obligaciones se aplican desde el 2 de agosto de 2028. La guía MDCG 2025-6 explica cómo coordinar los requisitos de ambas normas en una sola documentación.