Una API de dispositivo médico de Clase IIb es la interfaz de un software que cuenta con el marcado CE como dispositivo médico de Clase IIb según el Reglamento de Dispositivos Médicos de la UE (MDR 2017/745). Estar certificado como Clase IIb significa que un organismo notificado ha evaluado el software para la monitorización de pacientes cuya condición puede deteriorarse rápidamente: una persona con insuficiencia cardíaca que aumenta dos kilos en tres días, un paciente con EPOC cuya saturación de oxígeno cae durante la noche o alguien que se recupera en casa tras recibir el alta hospitalaria.

La mayoría de las API de datos de salud no son dispositivos médicos. Recopilan y transportan datos de dispositivos wearables y aplicaciones, como los pasos, el sueño o la frecuencia cardíaca de un reloj inteligente, pero no están certificadas para convertir esos datos en alertas clínicas. Esta guía explica dónde se encuentra el límite, qué cubre la certificación cuando se desarrolla sobre una API de Clase IIb y qué preguntar a un proveedor antes de realizar la integración.

API de datos de salud frente a API de dispositivo médico

Lo que separa a ambas es la finalidad prevista declarada por el fabricante. La tecnología parece la misma: ambas exponen endpoints y webhooks. Una API de datos de salud puede decirle a su aplicación que un usuario durmió seis horas. Solo una API de dispositivo médico está certificada para decirle a un enfermero que la presión arterial de un paciente requiere atención hoy mismo.

Vitalera se sitúa en el segundo lado de esa línea. Nuestro software de monitorización remota de pacientes cuenta con el marcado CE como dispositivo médico de Clase IIb según el MDR, está certificado por un organismo notificado y figura en EUDAMED, la base de datos pública de la Comisión Europea. Nosotros mismos pasamos por ese proceso, por lo que sabemos lo que exige tanto del software como de los equipos que lo desarrollan.

La mayoría de las API de datos de salud no son dispositivos médicos en absoluto. Mueven datos; no tienen permitido convertirlos en alertas clínicas. Esta guía explica la diferencia, qué cubre la certificación cuando se desarrolla sobre una de ellas y qué preguntar a un proveedor antes de realizar la integración.

Si su producto solo muestra pasos y sueño, una API de datos de salud es suficiente. Si un enfermero va a actuar basándose en una alerta generada por el sistema, necesita la columna de la derecha.

Por qué el software de monitorización remota de pacientes es de Clase IIb

La Regla 11 del MDR clasifica el software según lo que sucede si comete un error. La regla tiene dos ramas que son relevantes para la monitorización remota:

• El software que monitoriza procesos fisiológicos es de Clase IIa. Pasa a ser de Clase IIb cuando monitoriza parámetros vitales cuya variación podría poner al paciente en peligro inmediato.
• El software que informa sobre decisiones diagnósticas o terapéuticas comienza en la Clase IIa. Pasa a ser de Clase IIb cuando una decisión errónea podría causar un deterioro grave o una intervención quirúrgica, y de Clase III cuando podría causar la muerte o daños irreversibles.

El documento de orientación MDCG 2019-11, revisado en junio de 2025, añade que cada módulo de software se evalúa según su propia finalidad médica. Por lo tanto, una plataforma puede tener módulos certificados y no certificados conviviendo, razón por la cual el alcance del certificado es más importante que el logotipo.

Qué cubre la certificación cuando realizas una integración y qué no

Un certificado cubre el software del fabricante, utilizado dentro de su finalidad prevista declarada. No se transfiere al producto que construyes sobre él. Este es el punto que la mayoría de las páginas de proveedores omiten.

1) Qué obtienes al desarrollar sobre una API certificada

• Lógica de monitorización, umbrales y alertas que han sido evaluados por un organismo notificado.
• Un ciclo de vida de software ejecutado bajo la norma IEC 62304, con gestión de riesgos conforme a la norma ISO 14971.
• Evaluación clínica y vigilancia poscomercialización ya implementadas para esas funciones.
• Lanzamientos controlados: se te informa cuando un cambio afecta a la seguridad o al rendimiento.

2) Qué sigue siendo responsabilidad tuya

• Si tu producto añade su propia lógica médica (tu propia puntuación de riesgo, tus propias reglas de alerta), esa lógica puede constituir un producto sanitario por sí misma.
• Si comercializas el software bajo tu propio nombre, cambias su finalidad prevista o lo modificas, el Artículo 16 del MDR te impone las obligaciones del fabricante.
• Si lo utilizas fuera de la finalidad prevista declarada (un grupo de pacientes diferente, un entorno agudo), el certificado ya no cubre ese uso.

3) Qué no cambia la certificación

Un reloj inteligente de consumo sigue siendo un dispositivo de consumo. Pasar sus datos a través de un software certificado no convierte la lectura en grado médico. El software certificado puede procesar esos datos, pero el peso clínico de cada señal depende del dispositivo que la produjo. Un proveedor serio te indicará qué fuentes son productos sanitarios y cuáles no.

Desarrollar sobre una API de producto sanitario de Clase IIb

Si tu producto solo muestra datos de bienestar, una API de datos de salud es suficiente. Si un médico va a tomar decisiones basadas en lo que muestra, necesitas un software certificado para ese uso. La plataforma de monitorización remota de pacientes de Vitalera cuenta con el marcado CE como producto sanitario de Clase IIb según el MDR y está registrada en EUDAMED. A través de la API de Vitalera puedes conectar más de 500 dispositivos wearables y médicos, recopilar PROMs y PREMs, y enviar datos de monitorización a la historia clínica en formato FHIR o HL7. Cuéntanos qué estás construyendo y lo verificaremos con nuestra finalidad prevista antes de que escribas una sola línea de código. Habla con el equipo o lee la documentación de la API.

‍