La respuesta corta
Lo que convierte una app en producto sanitario no es la tecnología ni el sector: es la finalidad prevista. Si el software está destinado a un propósito de los que define la normativa de producto sanitario, es producto sanitario, sea una app, un módulo o parte de otro sistema.
Y el corte que salva a la mayoría de las apps: el software que persigue exclusivamente fines administrativos, de estilo de vida o de bienestar no se considera software sanitario.
El documento que hay que leer antes de discutirlo con nadie es la guía MDCG 2019-11, del Grupo de Coordinación de Productos Sanitarios, que explica cuándo y cómo se cualifica y clasifica el software. La clasificación se decide en el anexo VIII del MDR, y para software manda la regla 11.
La tabla que decide la clase
Esta es la orientación de clasificación que publica la propia guía para la regla 11. Se cruzan dos ejes: cuánto pesa la información que da el software, y en qué situación está el paciente.
| Alta — tratar o diagnosticar | Media — dirige la actuación clínica | Baja — informa la actuación clínica | |
|---|---|---|---|
| Situación crítica | Clase III | Clase IIb | Clase IIa |
| Situación seria | Clase IIb | Clase IIa | Clase IIa |
| Situación no seria | Clase IIa | Clase IIa | Clase IIa |
Lo que salta a la vista: casi todo cae en IIa como mínimo. Bajo la regla 11, en cuanto tu software aporta información usada para tomar decisiones con finalidad diagnóstica o terapéutica, la clase I deja de ser el caso normal y pasa a ser la excepción.
Y eso cambia el proyecto entero: clase IIa o superior implica organismo notificado, sistema de gestión de calidad, documentación técnica, evaluación clínica y vigilancia poscomercialización. No es una casilla más en el backlog.
Los ejemplos oficiales, que valen más que la teoría
La guía incluye ejemplos concretos. Estos son los que más se parecen a lo que suele llegar a una agencia:
- Una app móvil que analiza el latido del usuario, detecta anomalías e informa al médico: clase IIb por regla 11(a), si la información está destinada a guiar al médico en el diagnóstico.
- Vigilancia continua de procesos fisiológicos vitales en anestesia, cuidados intensivos o urgencias: clase IIb por regla 11(b).
- Monitorización de procesos fisiológicos no vitales, y lecturas de señales vitales en revisiones rutinarias incluida la monitorización en casa: clase IIa por regla 11(b).
- Software que puntúa depresión a partir de síntomas introducidos por el paciente: clase IIb por regla 11(a).
- App de fertilidad que calcula el estado fértil a partir de temperatura basal y días de menstruación, mostrando tres luces —fértil, infértil, fase de aprendizaje—: clase I por regla 11c.
- Diagnóstico por análisis de imagen para decidir el tratamiento en ictus agudo: clase III por regla 11(a).
Fíjate en el contraste entre el segundo y el tercero: la misma medición cambia de clase según el contexto de uso. Un sensor de constantes en la UCI y el mismo sensor en una revisión en casa no son el mismo producto a efectos regulatorios.
Y en el primero: una app de latido es IIb —no IIa— si su información guía al médico en el diagnóstico. Es exactamente el tipo de producto que se plantea como «una app de bienestar con un extra» y aterriza en el tramo alto.
Lo que no es producto sanitario
También está acotado, y sirve para diseñar dentro de los límites si esa es la decisión:
- Software exclusivamente administrativo, de estilo de vida o de bienestar.
- Sistemas de información de laboratorio y gestores de área de trabajo por sí mismos — aunque los módulos adicionales que se les añadan sí pueden cualificar por separado.
- Sistemas de gestión de imagen usados solo para visualizar, archivar y transmitir. Si incorporan postprocesado con fines diagnósticos, sí cualifican.
- Software que solo modifica la representación de resultados: operaciones aritméticas básicas, conversión de unidades, representación en el tiempo o comparación con límites fijados por el usuario, cuando los resultados son legibles y comprensibles sin la intervención del software.
Ese último es el más útil como criterio de diseño: si tu app solo enseña lo que ya era legible, estás fuera. En cuanto interpreta, entras.
La trampa del «wellness»
El patrón de riesgo se repite: un producto se lanza como bienestar, funciona, y el equipo comercial empieza a describirlo por lo que de verdad hace —«detecta», «alerta», «recomienda»—. La finalidad prevista no la fija el código: la fijan también las afirmaciones de marketing.
Es decir: puedes convertir tu app en producto sanitario reescribiendo la página de la web. Sin tocar una línea. Por eso la revisión de los textos comerciales debería pasar por quien lleva el asunto regulatorio, y no es una formalidad.
Antes de escribir la primera línea
- Escribe la finalidad prevista en una frase. Si no se puede, el producto no está definido.
- ¿La información se usa para decisiones diagnósticas o terapéuticas? Si sí, mira la tabla.
- ¿En qué situación está el paciente cuando se usa? Crítica, seria o no seria.
- ¿Interpreta, o solo muestra?
- Si sale IIa o más: ¿hay plan regulatorio, presupuesto y organismo notificado? Eso condiciona el calendario mucho más que el desarrollo.
Y una recomendación práctica: esta conversación se tiene antes del diseño, con el responsable regulatorio del cliente en la sala. Descubrir en el mes ocho que el producto es IIb no retrasa el lanzamiento unas semanas — lo cambia de año.
Es parte del trabajo previo en apps para el sector salud: saber en qué régimen estás antes de decidir cómo se construye.
Fuente primaria, consultada el 14 de agosto de 2026: MDCG 2019-11 — Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 – MDR and Regulation (EU) 2017/746 – IVDR, anexos III y IV. La guía tuvo una revisión publicada en junio de 2025 con aclaraciones sobre software con IA y arquitecturas modulares: conviene trabajar siempre contra la versión vigente.
