Un programa informático puede ser un producto sanitario igual que un bisturí: depende de para qué lo destine su fabricante, no de su tecnología. Si ayuda a diagnosticar o a decidir un tratamiento, el MDR lo clasifica por la regla 11 y exige su evaluación antes de usarlo. Por otro lado, el Espacio Europeo de Datos de Salud fija, desde 2027 y por fases hasta 2031, cómo accede cada persona a sus datos, cómo deben ser los sistemas de historia clínica y cómo se reutilizan los datos para investigar.

Cuándo un programa es producto sanitario

El Reglamento (UE) 2017/745, conocido como MDR, define el producto sanitario como «todo instrumento, dispositivo, equipo, programa informático, implante, reactivo, material u otro artículo» destinado por el fabricante a usarse en personas con fines médicos específicos (art. 2.1) ¹. Esos fines son, entre otros, el diagnóstico, la prevención, el seguimiento, la predicción, el pronóstico, el tratamiento o el alivio de una enfermedad ¹. El MDR es aplicable desde el 26 de mayo de 2021, como recuerda la norma española que lo complementa, el Real Decreto 192/2023 ².

La clave está en la finalidad que declara el fabricante. Un sistema que gestiona citas, camas o facturación no tiene fin médico y no es producto sanitario. Uno que calcula una dosis, interpreta un electrocardiograma o estima el riesgo de deterioro de un paciente, sí puede serlo.

Fuente de la definición: MDR, art. 2.1 ¹. La calificación de cada caso concreto depende de su finalidad declarada; la tabla solo orienta.

La regla 11: cómo se clasifica el software

Los productos se clasifican en clases I, IIa, IIb y III según su riesgo, con las reglas del anexo VIII ¹. Para el software rigen dos ideas. Si el programa maneja un producto o influye en su uso, toma la clase de ese producto; si es independiente, se clasifica por sí mismo (anexo VIII, 3.3) ¹. Y para el software independiente existe una regla específica, la 11 ¹:

La consecuencia práctica es que casi todo software con fin médico queda en clase IIa o superior. Eso importa porque la clase decide el procedimiento: los fabricantes de clase I emiten ellos mismos la declaración UE de conformidad tras elaborar la documentación técnica (art. 52.7), mientras que las clases IIa, IIb y III pasan por las evaluaciones de conformidad de los anexos IX a XI (art. 52.3, 52.4 y 52.6) ¹. La vía habitual es la del anexo IX: auditoría del sistema de gestión de la calidad del fabricante y evaluación de su documentación técnica ¹. Los productos conformes llevan el marcado CE (art. 20) ¹.

Lo que un hospital puede fabricar

Muchos hospitales desarrollan sus propias herramientas: una escala de riesgo integrada en la historia o un algoritmo de alerta. El MDR prevé una excepción para los productos «fabricados y utilizados exclusivamente en centros sanitarios» de la UE: no se les aplica el reglamento, salvo los requisitos generales de seguridad y funcionamiento del anexo I, si se cumplen todas estas condiciones (art. 5.5) ¹:

• no se ceden a otras personas jurídicas;
• se fabrican y usan con un sistema de gestión de calidad apropiado;
• el centro justifica que ningún producto equivalente del mercado cubre las necesidades de ese grupo de pacientes;
• el centro publica una declaración con sus datos, los de los productos y su cumplimiento de los requisitos generales;
• mantiene documentación técnica suficiente para que la autoridad lo evalúe, y revisa la experiencia clínica y corrige lo necesario.

España lo restringe en el artículo 9 del Real Decreto 192/2023 ²:

Vigilancia: cuando un producto falla

Los fabricantes notifican los incidentes según el MDR. Además, los profesionales sanitarios y las autoridades que, en su actividad, conozcan un incidente grave deben notificarlo a la AEMPS por su sede electrónica, y la Agencia lo traslada al fabricante (Real Decreto 192/2023, art. 35.2) ². Los pacientes y usuarios también pueden notificarlo ². Un error de cálculo en un programa de dosificación que provoca una sobredosis es, por tanto, un caso de vigilancia de productos sanitarios, no solo una incidencia informática.

El Espacio Europeo de Datos de Salud

El Reglamento (UE) 2025/327 crea el Espacio Europeo de Datos de Salud ³. Se publicó en el Diario Oficial de la UE el 5 de marzo de 2025 y entró en vigor el 25 de marzo de 2025 ⁴. Según el Ministerio de Sanidad, persigue mejorar el acceso de las personas a sus datos de salud y su control sobre ellos, permitir su reutilización para investigación e innovación y facilitar que los profesionales accedan a la historia interoperable de sus pacientes en la UE ⁴.

Uso primario: los derechos de las personas

Para la asistencia, el reglamento fija seis categorías prioritarias de datos: historias clínicas resumidas, recetas electrónicas, dispensaciones electrónicas, estudios de imagen con sus informes, resultados de pruebas diagnósticas con sus informes, e informes de alta hospitalaria (art. 14.1) ³. Sobre ellas, cada persona tendrá derecho a ³:

• acceder a sus datos de forma inmediata tras su registro en un sistema de historia clínica electrónica, gratis y en formato legible (art. 3.1), y descargar una copia en el formato europeo de intercambio (art. 3.2);
• limitar el acceso de los profesionales a todo o parte de sus datos, sabiendo que eso puede afectar a su asistencia; la limitación no será visible para quien la atiende (art. 8);
• autoexcluirse del acceso a través de los servicios del reglamento, si el Derecho nacional lo prevé (art. 10).

Los sistemas de historia clínica electrónica

Los sistemas HCE deberán incluir dos componentes armonizados: uno europeo de interoperabilidad y otro europeo de registro (art. 25) ³. Solo podrán comercializarse o ponerse en servicio si cumplen esas reglas, y los que un centro fabrica y usa internamente se consideran puestos en servicio (art. 26) ³. Los programas de propósito general usados en un entorno sanitario quedan fuera (art. 25.2) ³.

Uso secundario: reutilizar para investigar

Cada Estado designará uno o varios organismos de acceso a datos de salud que decidirán las solicitudes, expedirán permisos y darán acceso en un entorno de tratamiento seguro (art. 57) ³. Las personas tendrán derecho de autoexclusión del uso secundario, en cualquier momento, sin dar motivos y de forma revocable (art. 71) ³. Qué organismos designará España no consta todavía en la web del Ministerio: [PENDIENTE: autoridad de salud digital y organismo de acceso a datos de salud designados por España].

Calendario

Fuente: Reglamento (UE) 2025/327, art. 105 ³.

Caso práctico

El servicio de cuidados intensivos de un hospital y su departamento de sistemas desarrollan un modelo que predice qué pacientes se deteriorarán en las próximas horas y lanza una alerta en la historia clínica. Su finalidad es el pronóstico, de modo que es un programa con fin médico ¹. Informa decisiones terapéuticas sobre pacientes críticos, cuyo deterioro puede ser grave o irreversible: por la regla 11, sería de clase IIb o III ¹. En España, un hospital no puede fabricar para sí productos de clase IIb ni III ². Para usarlo en pacientes, el proyecto tiene que buscar otra vía, como su evaluación de conformidad por la vía ordinaria, o rediseñar su finalidad.

El mismo hospital prepara su sistema de historia clínica para el EEDS. Antes de marzo de 2029 deberá poder ofrecer a los pacientes su historia resumida y sus recetas en el formato europeo, y respetar su decisión de limitar quién ve qué ³.

Qué implica para los sistemas

Elemento	Dato o requisito que nace	Con quién se relaciona
Inventario de software clínico	Por cada programa: finalidad declarada, si es producto sanitario, clase y marcado CE	Fabricantes, ingeniería clínica y el comité que aprueba herramientas
Desarrollo interno	Justificación, documentación técnica, sistema de calidad y declaración pública	AEMPS (comunicación previa) y autoridad sanitaria
Integración con equipos y otros sistemas	Si el software controla un producto, hereda su clase: integrarlo puede alterar su conformidad	LIS, PACS, monitores y bombas de infusión
Incidentes con software clínico	Registro del fallo, daño causado y notificación	AEMPS y fabricante; gestión de incidentes de seguridad
EEDS: limitaciones del paciente	Qué datos ha restringido y a quién, sin mostrar que existe la restricción	Portal del paciente, HIS y servicios nacionales de intercambio
EEDS: autoexclusión del uso secundario	Marca por persona que filtra las extracciones	Almacenes de datos y organismo de acceso