A quién obliga

Por papel frente al sistema de historia clínica electrónica y al dato

Cadena de suministro del sistema HCE
Productos que declaran interoperabilidad
Quien presta la asistencia
Uso secundario
Roles que reparte

Notificación
de incidentes

A quién se notifica
Autoridad
CSIRT ·
Afectados ·
Público ·
Cadena ·

Régimen sancionador

Calendario ciber

Calendario ciber

26/03/2027

Aplicación general del Reglamento. Para la ciberseguridad es la fecha que importa, porque con ella entran las obligaciones del fabricante de sistemas HCE del artículo 30, y con ellas la exigencia de conformidad con los requisitos esenciales del anexo II: autenticación fiable de los profesionales sanitarios, registro de cada acceso con las categorías de datos y el origen, y herramientas para revisarlo y analizarlo. Entra también el aviso de incidente grave del artículo 44.7 con su plazo de tres días. En la misma fecha vencen tres plazos que no obligan al mercado pero condicionan lo anterior: la Comisión debe haber adoptado las especificaciones comunes del anexo II (art. 36.1) y los requisitos técnicos y de seguridad del entorno de tratamiento seguro (art. 73.5), y los Estados miembros deben haber comunicado la identidad de su autoridad de salud digital (art. 19.1) y su régimen de sanciones (art. 99).

Art. 105, párr. 2.º · arts. 30, 36.1, 44.7 y 73.5

Calendario ciber

26/03/2029

Empieza a morder el control de acceso al mercado. Los artículos 25, 26, 27, 47, 48 y 49 se aplican a las tres primeras categorías prioritarias de datos (historias clínicas resumidas, recetas electrónicas y dispensaciones electrónicas) y a los sistemas HCE destinados por el fabricante a tratarlas: desde esta fecha un sistema HCE solo puede introducirse en el mercado si cumple el capítulo III, con sus dos componentes armonizados y su marcado CE, y el fabricante de producto sanitario, de producto de diagnóstico in vitro o de sistema de IA de alto riesgo que declare la interoperabilidad tiene que demostrar la conformidad del artículo 27. Es también la fecha de aplicación del capítulo IV entero, y con él del entorno de tratamiento seguro del artículo 73 y del régimen de multas de los artículos 63 y 64.

Art. 105, párr. 3.º, a) y párr. 4.º · arts. 26, 27, 49 y 73

Calendario ciber

26/03/2031

Se cierra el escalonado. Los mismos artículos se aplican a las tres categorías prioritarias restantes (estudios de diagnóstico por imagen e informes correspondientes, resultados de pruebas diagnósticas y de laboratorio, e informes de altas hospitalarias) y a los sistemas HCE destinados a tratarlas. En la misma fecha el capítulo III pasa a aplicarse a los sistemas HCE puestos en servicio conforme al artículo 26.2, es decir a los que un centro sanitario fabrica y usa internamente y a los ofrecidos como servicio, que hasta aquí quedan fuera. Y se suprime el artículo 14 de la Directiva 2011/24/UE, que sostenía la red de sanidad electrónica que este Reglamento sustituye.

Art. 105, párr. 3.º, b) y párr. 3.º in fine · art. 103

Qué implantar

Sistema HCE: requisitos del producto
Sistema HCE: conformidad y mercado
Sistema HCE: incidentes y vigilancia
Productos que declaran interoperabilidad
Uso primario
Uso secundario

Mapa NIST CSF

GOBERNAR NIST CSF 2.0 IDENTIFICAR Identificar · 0 medidas PROTEGER Proteger · 3 medidas DETECTAR Detectar · 2 medidas RESPONDER Responder · 1 medida RECUPERAR Recuperar · 0 medidas
6 medidas sobre NIST CSF 2.0 Elige una función en la rueda o en la lista para ver sus categorías y medidas. Una medida con categorías en varias funciones cuenta en cada una: la suma de la lista supera el total.

Gobernar GV

GV.OC Contexto organizativo

Proteger PR

PR.AA Gestión de identidades, autenticación y control de acceso
PR.DS Seguridad de los datos
PR.PS Seguridad de la plataforma

Detectar DE

DE.CM Monitoreo continuo
DE.AE Análisis de acontecimientos adversos

Responder RS

RS.CO Notificación y comunicación de la respuesta al incidente

Relaciones con otras normas

  • modifica CRA

    Reglamento (UE) 2024/2847 (CRA). El artículo 104 inserta en él un artículo 32.5 bis: el fabricante de un producto con elementos digitales que sea un sistema HCE demuestra la conformidad con los requisitos esenciales del anexo I del CRA por el procedimiento de evaluación de la conformidad del capítulo III de este Reglamento. Ajusta además los artículos 13.4 y 31.3 del CRA para que la evaluación de riesgos y la documentación técnica sean únicas cuando concurren los dos actos. No toca fechas, importes ni el régimen de notificación del artículo 14 del CRA.

    Verificada contra fuente el 13/08/2026

  • modifica CELEX 32011L0024

    Directiva 2011/24/UE, sobre asistencia sanitaria transfronteriza. El artículo 103 suprime su artículo 14, el que creaba la red de sanidad electrónica, con efectos a partir del 26 de marzo de 2031. Hasta esa fecha la red sigue existiendo en paralelo a la infraestructura MiSalud@UE que este Reglamento monta.

    Verificada contra fuente el 13/08/2026

  • desarrollada por CELEX 32026R0771

    Reglamento de Ejecución (UE) 2026/771 de la Comisión, de 7 de abril de 2026, que establece las medidas necesarias para el establecimiento y el funcionamiento del Consejo del EEDS. Regula la composición, la presidencia, los subgrupos y el secreto profesional de sus miembros. No impone ningún deber a fabricantes, prestadores ni usuarios de datos, y no cambia lo exigible en ciberseguridad. Es, a fecha de esta revisión, el único acto adoptado sobre la base del Reglamento.

    Verificada contra fuente el 13/08/2026

  • cita MDR e IVDR

    Reglamento (UE) 2017/745, de productos sanitarios, y su hermano el Reglamento (UE) 2017/746 de diagnóstico in vitro. El artículo 27.1 toma de ellos la definición de producto y les añade un deber propio cuando el fabricante declara la interoperabilidad con los componentes armonizados de los sistemas HCE. El deslinde de competencias es explícito: la vigilancia del mercado de esos productos sigue siendo la de sus reglamentos (art. 43.7), el registro se hace en sus bases de datos con transmisión a la de este Reglamento (art. 49.3), y el artículo 1.5 declara que nada de aquí afecta a la seguridad de los productos sanitarios regulada allí.

    Verificada contra fuente el 13/08/2026

  • cita AI Act

    Reglamento (UE) 2024/1689 (AI Act). El artículo 27.2 impone al proveedor de un sistema de IA de alto riesgo que declare la interoperabilidad con los sistemas HCE el mismo deber de demostrar la conformidad con los requisitos de los componentes armonizados. La vigilancia de esos sistemas corresponde a la autoridad del artículo 70 del AI Act (art. 43.7), y su registro se hace en la base de datos de aquel Reglamento con transmisión a la de este (art. 49.3). La relación es de coordinación, no de sustitución: el artículo 1.5 deja intacto lo que el AI Act exige a esos sistemas.

    Verificada contra fuente el 13/08/2026

  • cita RGPD

    Reglamento (UE) 2016/679 (RGPD). El Reglamento se declara desarrollo y complemento de los derechos que aquel reconoce (art. 1.2.a) y se apoya en él en toda la norma: las autoridades de control del RGPD supervisan el derecho de autoexclusión del uso secundario y pueden multar hasta el máximo de su artículo 83 (art. 65); cuando la autoridad de vigilancia del mercado constata un problema de protección de datos personales debe informarlas sin demora indebida (art. 44.6); y el reparto de papeles de responsable y encargado del tratamiento en el uso secundario se fija expresamente en el artículo 74.

    Verificada contra fuente el 13/08/2026

  • cita NIS2

    Directiva (UE) 2022/2555 (NIS2). El artículo 44.7 declara que el aviso de incidente grave al que obliga se hace sin perjuicio de los requisitos de notificación de incidentes de aquella Directiva. Son dos relojes distintos sobre el mismo hecho: el de aquí lo dispara el vínculo causal con el sistema HCE y tiene tope de tres días, y su destinatario es la autoridad de vigilancia del mercado, no el CSIRT.

    Verificada contra fuente el 13/08/2026

  • cita eIDAS

    Reglamento (UE) n.º 910/2014 (eIDAS). Es la fuente del control de acceso del uso primario: los servicios de acceso para profesionales sanitarios solo son accesibles con medios de identificación electrónica reconocidos conforme a su artículo 6, o con otros que cumplan las especificaciones comunes del artículo 36 (art. 12), y la persona física tiene derecho a identificarse con cualquiera de esos medios reconocidos (art. 16.1).

    Verificada contra fuente el 13/08/2026

  • cita CELEX 32019R1020

    Reglamento (UE) 2019/1020, de vigilancia del mercado. Es la maquinaria de control del capítulo III: se aplica a los sistemas HCE (art. 43.1), da a las autoridades designadas las medidas de su artículo 16, y de él toma este Reglamento las definiciones de fabricante, importador, distribuidor, comercialización, introducción en el mercado, recuperación y retirada (art. 2.1.d).

    Verificada contra fuente el 13/08/2026

  • citada por 5 normas del observatorio

    Índice generado a partir de las relaciones que declaran las demás fichas. Las relaciones con efecto jurídico en este sentido, cuando existen, aparecen arriba como entradas propias.

Sanción

Uso secundario indebido · techo del Reglamento

Conducta
Incumplimiento por el usuario de datos de salud de los fines del permiso, extracción de datos personales del entorno de tratamiento seguro, reidentificación o intento de reidentificación, o incumplimiento de las medidas de garantía del cumplimiento del organismo de acceso
Importe
20 000 000 EUR como máximo o, en el caso de una empresa, una cuantía equivalente al 4 % como máximo de su volumen de negocios anual total a escala mundial del ejercicio financiero anterior si esta última cifra fuera superior

Art. 64.5

Sanción

Obligaciones de tenedor y usuario · techo del Reglamento

Conducta
Incumplimiento de las obligaciones del tenedor de datos de salud del artículo 60 y de las del usuario de datos de salud del artículo 61, apartados 1, 5 y 6
Importe
10 000 000 EUR como máximo o, en el caso de una empresa, una cuantía equivalente al 2 % como máximo de su volumen de negocios anual total a escala mundial del ejercicio financiero anterior si esta última cifra fuera superior

Art. 64.4

Sanción

Obstrucción · multa por día de retraso

Conducta
Obstrucción del tenedor de datos de salud: no poner los datos a disposición con la intención manifiesta de obstruir su uso, o incumplir el plazo de tres meses del artículo 60.2
Importe
Multas coercitivas por cada día de retraso, transparentes y proporcionadas, de importe fijado con arreglo al Derecho nacional

Art. 63.4

Régimen sancionador · todo el detalle

Escalones

Uso secundario indebido · techo del Reglamento

Incumplimiento por el usuario de datos de salud de los fines del permiso, extracción de datos personales del entorno de tratamiento seguro, reidentificación o intento de reidentificación, o incumplimiento de las medidas de garantía del cumplimiento del organismo de acceso

20 000 000 EUR como máximo o, en el caso de una empresa, una cuantía equivalente al 4 % como máximo de su volumen de negocios anual total a escala mundial del ejercicio financiero anterior si esta última cifra fuera superior

Art. 64.5
Obligaciones de tenedor y usuario · techo del Reglamento

Incumplimiento de las obligaciones del tenedor de datos de salud del artículo 60 y de las del usuario de datos de salud del artículo 61, apartados 1, 5 y 6

10 000 000 EUR como máximo o, en el caso de una empresa, una cuantía equivalente al 2 % como máximo de su volumen de negocios anual total a escala mundial del ejercicio financiero anterior si esta última cifra fuera superior

Art. 64.4
Obstrucción · multa por día de retraso

Obstrucción del tenedor de datos de salud: no poner los datos a disposición con la intención manifiesta de obstruir su uso, o incumplir el plazo de tres meses del artículo 60.2

Multas coercitivas por cada día de retraso, transparentes y proporcionadas, de importe fijado con arreglo al Derecho nacional

Art. 63.4

Matices

  • Las multas de los artículos 63 y 64 solo alcanzan al uso secundario. El incumplimiento del capítulo III (los requisitos esenciales del anexo II, el marcado CE, la documentación técnica o el registro) no se sanciona por esta vía, sino con las medidas de la autoridad de vigilancia del mercado (prohibir o restringir la comercialización, recuperar o retirar el sistema) y con el régimen que cada Estado miembro establezca por el artículo 99.
  • Quien impone las multas administrativas no es un tribunal ni la autoridad de protección de datos, sino el organismo de acceso a datos de salud, que es a la vez quien expide el permiso.
  • Cada Estado miembro puede decidir si impone multas administrativas a sus autoridades y organismos del sector público, y en qué medida (art. 64.6). Donde el ordenamiento no contemple multas administrativas, el artículo 64.8 admite medidas jurídicas de efecto equivalente.
  • El derecho de autoexclusión del uso secundario del artículo 71 lo supervisan las autoridades de control del Reglamento (UE) 2016/679, que pueden imponer multas hasta el máximo de su artículo 83 (art. 65).

En España

El régimen general de sanciones lo establece cada Estado miembro, que debe comunicarlo a la Comisión a más tardar el 26 de marzo de 2027. España no lo ha establecido, así que no puede afirmarse todavía qué autoridad sancionaría el incumplimiento del capítulo III ni con qué procedimiento.

Aviso

El reloj tiene dos disparadores encadenados y el segundo no espera al primero: se notifica inmediatamente al establecer el vínculo causal, o la posibilidad razonable de que exista, y en todo caso a más tardar tres días desde que se tiene conocimiento del incidente. Un procedimiento que arranque solo con la causalidad confirmada llega tarde. La notificación no sustituye a la de la Directiva (UE) 2022/2555 cuando también proceda: el propio artículo lo dice. Y si lo que se constata toca a la protección de datos personales, es la autoridad de vigilancia del mercado la que informa a la autoridad de control del Reglamento (UE) 2016/679, lo que no releva al responsable del tratamiento de su propia notificación.

Notificación de incidentes

Incidente grave que afecta a un sistema HCE introducido en el mercado o puesto en servicio

Plazo
3 días
Desde cuándo corre
Inmediatamente después de establecer el vínculo causal entre el sistema HCE y el incidente grave, o la posibilidad razonable de que exista; y en todo caso a más tardar tres días desde que el fabricante tiene conocimiento del incidente

Art. 44.7

A quién se notifica

Autoridades de vigilancia del mercado de los Estados miembros donde se produjo el incidente y donde se introdujo o puso en servicio el sistema

Cuándo
Régimen general del sistema HCE. La notificación incluye la medida correctiva adoptada o prevista por el fabricante
En España
España no ha designado todavía la autoridad de vigilancia del mercado de los sistemas HCE ni la autoridad de salud digital. El Reglamento da de plazo hasta el 26 de marzo de 2027 para comunicar a la Comisión la identidad de la autoridad de salud digital, y admite que sea la misma que la de vigilancia del mercado si se evita el conflicto de intereses. Hasta entonces no se puede afirmar cuál es la ventanilla española. El Ministerio de Sanidad figura aquí como departamento competente en la materia y punto donde seguir la designación, no como destinatario confirmado de la notificación.

Art. 44.7

A quién se notifica

Autoridades de vigilancia del mercado de los Reglamentos de productos sanitarios y del Reglamento de IA

Cuándo
Productos sanitarios, productos de diagnóstico in vitro y sistemas de IA de alto riesgo que hayan declarado la interoperabilidad
En España
Para productos sanitarios y de diagnóstico in vitro la autoridad competente es la AEMPS. Para los sistemas de IA de alto riesgo, la vigilancia corresponde a la autoridad designada bajo el Reglamento (UE) 2024/1689, papel que en España está previsto para la AESIA sin que la designación formal esté cerrada.

Art. 43.7

Notificación de incidentes · todo el detalle

Qué es notificable

El incidente grave que afecte a un sistema HCE ya introducido en el mercado o puesto en servicio. La definición no exige daño consumado: basta que el fallo pueda dar lugar a la muerte o al daño grave para la salud, al perjuicio grave para los derechos de una persona, o a la perturbación grave de la gestión y explotación de infraestructuras críticas del sector sanitario. Obliga al fabricante del sistema HCE.

Literal de la norma «incidente grave»: todo funcionamiento defectuoso o deterioro de las características o del funcionamiento de un sistema HCE comercializado que, directa o indirectamente, dé lugar, pueda haber dado lugar o pueda dar lugar, a alguna de las siguientes consecuencias: i) la muerte de una persona física o el daño grave para su salud, ii) el perjuicio grave para los derechos de una persona física, iii) la perturbación grave de la gestión y la explotación de infraestructuras críticas en el sector sanitario

El reloj tiene dos disparadores encadenados y el segundo no espera al primero: se notifica inmediatamente al establecer el vínculo causal, o la posibilidad razonable de que exista, y en todo caso a más tardar tres días desde que se tiene conocimiento del incidente. Un procedimiento que arranque solo con la causalidad confirmada llega tarde. La notificación no sustituye a la de la Directiva (UE) 2022/2555 cuando también proceda: el propio artículo lo dice. Y si lo que se constata toca a la protección de datos personales, es la autoridad de vigilancia del mercado la que informa a la autoridad de control del Reglamento (UE) 2016/679, lo que no releva al responsable del tratamiento de su propia notificación.

Supuestos y plazos

Incidente grave que afecta a un sistema HCE introducido en el mercado o puesto en servicio

3 días

Inmediatamente después de establecer el vínculo causal entre el sistema HCE y el incidente grave, o la posibilidad razonable de que exista; y en todo caso a más tardar tres días desde que el fabricante tiene conocimiento del incidente

Art. 44.7

A quién se notifica

Autoridades de vigilancia del mercado de los Estados miembros donde se produjo el incidente y donde se introdujo o puso en servicio el sistema

Régimen general del sistema HCE. La notificación incluye la medida correctiva adoptada o prevista por el fabricante

Art. 44.7
Autoridades de vigilancia del mercado de los Reglamentos de productos sanitarios y del Reglamento de IA

Productos sanitarios, productos de diagnóstico in vitro y sistemas de IA de alto riesgo que hayan declarado la interoperabilidad

Art. 43.7
A quién obliga

Fabricante de sistema HCE

Quien introduce en el mercado o pone en servicio un sistema de historia clínica electrónica con su nombre o marca

Ejemplo La empresa que vende a hospitales su historia clínica electrónica es fabricante. Lo es también el hospital que desarrolla la suya y la pone en servicio, por la vía de la puesta en servicio del artículo 26.2, aunque para ese supuesto el capítulo III no se aplica hasta 2031.
Roles que emanan
A quién obliga

Representante, importador y distribuidor

Quien representa en la Unión al fabricante de fuera, quien lo importa y quien lo comercializa

Ejemplo El distribuidor que revende el sistema con su propia marca deja de ser distribuidor: el artículo 34 lo convierte en fabricante y le traslada el artículo 30 entero.
Roles que emanan
A quién obliga

Producto sanitario y diagnóstico in vitro

El fabricante que declara la interoperabilidad de su producto con los componentes armonizados de los sistemas HCE

Ejemplo Un monitor de constantes que vuelca sus lecturas en la historia clínica del hospital y lo anuncia como característica del producto queda dentro del artículo 27.
Roles que emanan
A quién obliga

Sistema de IA de alto riesgo

El proveedor de un sistema de IA de alto riesgo fuera del ámbito de los Reglamentos de productos sanitarios que declare esa interoperabilidad

Ejemplo Un sistema de apoyo a la decisión clínica clasificado de alto riesgo que se anuncia integrado con la historia clínica electrónica.
Roles que emanan
A quién obliga

Aplicación de bienestar

El fabricante de una aplicación de bienestar que declare la interoperabilidad, que debe expedir además la etiqueta del artículo 47

Ejemplo Una aplicación de seguimiento de actividad física que ofrece volcar sus datos a la historia clínica del usuario.
Roles que emanan
A quién obliga

Prestador y profesional sanitario

Quien registra los datos de las categorías prioritarias en un sistema HCE y quien accede a ellos para tratar a una persona

Ejemplo El centro de salud registra en formato electrónico la historia clínica resumida y la receta; el médico accede con un medio de identificación electrónica reconocido.
Roles que emanan
A quién obliga

Tenedor y usuario de datos de salud

Quien tiene el dato y debe ponerlo a disposición, y quien lo explota al amparo de un permiso de datos

Ejemplo Un servicio autonómico de salud cede el conjunto de datos al organismo de acceso; un grupo de investigación lo trata dentro del entorno seguro sin poder descargarlo.
Roles que emanan
A quién obliga

Organismo de acceso a datos de salud

El organismo público designado que expide los permisos y opera el entorno de tratamiento seguro

Roles que emanan
A quién obliga

Exclusiones

Los programas informáticos de propósito general utilizados en un entorno de asistencia sanitaria, que quedan fuera del capítulo III

Art. 25.2

Las personas físicas, incluidos los investigadores individuales, y las microempresas, que quedan exentas de las obligaciones del tenedor de datos de salud salvo que el Derecho nacional disponga otra cosa

Art. 50.1

El tratamiento realizado en el ejercicio de una actividad no comprendida en el ámbito de aplicación del Derecho de la Unión

Art. 1.9.a)

El tratamiento por las autoridades competentes con fines de prevención, investigación, detección o enjuiciamiento de infracciones penales o de ejecución de sanciones penales

Art. 1.9.b)
A quién obliga · todo el detalle

Tres poblaciones distintas con poco en común. La primera es la cadena de suministro del sistema de historia clínica electrónica, que responde de los requisitos esenciales del anexo II como responde cualquier fabricante de un producto con marcado CE. La segunda son los productos que deciden declarar interoperabilidad con esos sistemas, un deber que nadie contrae sin quererlo. La tercera es el uso secundario, donde obligan el tenedor del dato, el usuario que lo explota y el organismo público que opera el entorno seguro.

Cadena de suministro del sistema HCE

Fabricante de sistema HCE

Quien introduce en el mercado o pone en servicio un sistema de historia clínica electrónica con su nombre o marca

Representante, importador y distribuidor

Quien representa en la Unión al fabricante de fuera, quien lo importa y quien lo comercializa

Productos que declaran interoperabilidad

Producto sanitario y diagnóstico in vitro

El fabricante que declara la interoperabilidad de su producto con los componentes armonizados de los sistemas HCE

Sistema de IA de alto riesgo

El proveedor de un sistema de IA de alto riesgo fuera del ámbito de los Reglamentos de productos sanitarios que declare esa interoperabilidad

Aplicación de bienestar

El fabricante de una aplicación de bienestar que declare la interoperabilidad, que debe expedir además la etiqueta del artículo 47

Quien presta la asistencia

Prestador y profesional sanitario

Quien registra los datos de las categorías prioritarias en un sistema HCE y quien accede a ellos para tratar a una persona

Uso secundario

Tenedor y usuario de datos de salud

Quien tiene el dato y debe ponerlo a disposición, y quien lo explota al amparo de un permiso de datos

Organismo de acceso a datos de salud

El organismo público designado que expide los permisos y opera el entorno de tratamiento seguro

Exclusiones

Los programas informáticos de propósito general utilizados en un entorno de asistencia sanitaria, que quedan fuera del capítulo III

Art. 25.2

Las personas físicas, incluidos los investigadores individuales, y las microempresas, que quedan exentas de las obligaciones del tenedor de datos de salud salvo que el Derecho nacional disponga otra cosa

Art. 50.1

El tratamiento realizado en el ejercicio de una actividad no comprendida en el ámbito de aplicación del Derecho de la Unión

Art. 1.9.a)

El tratamiento por las autoridades competentes con fines de prevención, investigación, detección o enjuiciamiento de infracciones penales o de ejecución de sanciones penales

Art. 1.9.b)
Unión Europea · Reglamento UE

Reglamento (UE) 2025/327 del Parlamento Europeo y del Consejo, de 11 de febrero de 2025, relativo al Espacio Europeo de Datos de Salud, y por el que se modifican la Directiva 2011/24/UE y el Reglamento (UE) 2024/2847

Identificador
CELEX 32025R0327
Fuente
EUR-Lex · Diario Oficial de la Unión Europea · Oficina de Publicaciones de la Unión Europea
Ficha técnica

Ciberseguridad

De los nueve capítulos del Reglamento, la seguridad tiene uno propio y bien delimitado. El anexo II reserva su sección 3 a requisitos de seguridad y de registro que el fabricante del sistema de historia clínica electrónica debe cumplir para poner el producto en el mercado: autenticación fiable de los profesionales sanitarios, un componente de registro que grabe quién accede, a qué categorías de datos, cuándo y desde qué origen, y herramientas para revisar y analizar esos registros. Alrededor hay marcado CE, documentación técnica, declaración de conformidad y un aviso de incidente grave con plazo de tres días. En el uso secundario, el artículo 73 impone al entorno de tratamiento seguro una lista tasada de medidas con auditoría periódica. Lo que impide subir de nivel es la proporción: el resto de la norma son derechos del paciente, formato de intercambio, gobernanza e infraestructura transfronteriza, y ni siquiera la sección de seguridad del anexo II llega a un programa de gestión de la seguridad: es una lista corta de capacidades exigidas al producto.

Valoración del curador · nivel 3 de 5

Qué implantar · Sistema HCE: requisitos del producto

Los dos componentes armonizados obligatorios Ciber parcial

Todo sistema de historia clínica electrónica tiene que incluir dos piezas separadas y obligatorias: el componente europeo de interoperabilidad, que entrega y recibe los datos en el formato europeo de intercambio, y el componente europeo de registro, que deja constancia de los accesos. El Reglamento exige expresamente que cada uno sea independiente del otro.

Literal de la norma Los sistemas HCE incluirán un componente de programa informático europeo de interoperabilidad para sistemas HCE y un componente de programa informático europeo de registro para sistemas HCE (en lo sucesivo, «componentes armonizados de programa informático de sistemas HCE»), de conformidad con las disposiciones establecidas en el presente capítulo.
Dónde está la ciber De los dos componentes que el Reglamento hace obligatorios, uno es de interoperabilidad y el otro es el componente europeo de registro, cuyo contenido es la traza de acceso al dato clínico. La obligación no es de seguridad en su enunciado, pero sin ella no hay sujeto al que exigir el registro del punto 3.2 del anexo II.
Recae sobre

Art. 25.1

Qué implantar · Sistema HCE: requisitos del producto

Autenticación de los profesionales sanitarios Ciber

El requisito esencial más directo de toda la norma, y el que convierte al fabricante en responsable de una función de seguridad: si el sistema está diseñado para que lo usen profesionales sanitarios, tiene que traer mecanismos fiables de identificación y autenticación. El texto no fija factores ni niveles de garantía; eso lo concretarán las especificaciones comunes del artículo 36, que la Comisión debe adoptar antes del 26 de marzo de 2027 y que pueden incluir requisitos sobre la gestión de la identificación y el uso de la identidad electrónica.

Literal de la norma Todo sistema HCE diseñado para ser utilizado por profesionales sanitarios incluirá mecanismos fiables para la identificación y autenticación de los profesionales sanitarios.
Recae sobre
Alimenta estas medidas

Anexo II, punto 3.1

Qué implantar · Sistema HCE: requisitos del producto

Registro de cada acceso y herramientas para analizarlo Ciber

El componente europeo de registro debe grabar, sobre cada evento o grupo de eventos de acceso, cinco datos tasados: quién es el prestador o la organización que accedió, qué persona física concreta lo hizo, a qué categorías de datos, cuándo y de qué origen vienen los datos. El origen es el elemento que más distingue a esta traza de un log de aplicación corriente. Y el punto 3.3 cierra el círculo con lo que casi nunca se exige por norma: el sistema tiene que incluir herramientas para revisar y analizar esos registros, o al menos permitir que se conecte software externo que lo haga. Un registro que no se puede consultar no cumple.

Literal de la norma El componente de programa informático europeo de registro de un sistema HCE diseñado para posibilitar el acceso de los prestadores de asistencia sanitaria u otras personas a datos de salud electrónicos personales incluirá mecanismos de registro suficientes que graben, como mínimo, la siguiente información sobre cada evento o grupo de eventos de acceso: a) la identificación del prestador de asistencia sanitaria o de otras personas que hayan accedido a los datos de salud electrónicos personales; b) la identificación de la persona o personas físicas concretas que hayan accedido a los datos de salud electrónicos personales; c) las categorías de datos a los que se haya accedido; d) la hora y fecha de acceso; e) el origen u orígenes de los datos.
Recae sobre
Alimenta estas medidas

Anexo II, puntos 3.2 y 3.3

Qué implantar · Sistema HCE: requisitos del producto

Períodos de conservación y derechos de acceso diferenciados Ciber

El sistema que almacene datos de salud electrónicos personales tiene que permitir aplicar períodos de conservación distintos y derechos de acceso distintos según el origen y la categoría del dato. Es una exigencia de granularidad: un modelo de permisos de todo o nada sobre la historia completa no la satisface.

Literal de la norma Los componentes armonizados de programa informático de un sistema HCE que almacene datos de salud electrónicos personales permitirán diferentes períodos de conservación y derechos de acceso que tengan en cuenta el origen y las categorías de tales datos.
Recae sobre
Alimenta estas medidas

Anexo II, punto 3.4

Qué implantar · Sistema HCE: requisitos del producto

Requisitos generales del producto Ciber parcial

El sistema debe alcanzar el funcionamiento previsto por su fabricante, no poner en peligro la seguridad de los pacientes en condiciones normales de uso, poder suministrarse e instalarse sin que sus características se degraden, y diseñarse para que sus propiedades de interoperabilidad y seguridad respeten los derechos de las personas físicas.

Dónde está la ciber La sección general no habla de amenazas, pero dos de sus cuatro puntos nombran la seguridad como propiedad de diseño: el sistema se diseña para que sus características de interoperabilidad, seguridad y protección respeten los derechos de las personas, y el que se destina a funcionar en combinación con otros productos se diseña para que esa interacción sea fiable y segura.
Recae sobre

Anexo II, sección 1

Qué implantar · Sistema HCE: requisitos del producto

Requisitos de interoperabilidad

El sistema que almacene o intermedie datos debe ofrecer una interfaz que permita acceder a ellos en el formato europeo de intercambio a través del componente europeo de interoperabilidad, y poder recibirlos en ese mismo formato. Además hay dos prohibiciones que se leen como cláusulas antibloqueo: el sistema no puede incluir características que impidan o limiten el acceso autorizado y el intercambio de datos, ni que impidan la exportación autorizada de los datos para sustituir el sistema por otro producto.

Recae sobre

Anexo II, sección 2

Qué implantar · Sistema HCE: conformidad y mercado

Documentación técnica Ciber parcial

Se elabora antes de introducir el sistema en el mercado y se mantiene actualizada. El anexo III fija el contenido mínimo: descripción del sistema y su finalidad, categorías de datos para las que está diseñado, arquitectura, especificaciones técnicas con el detalle de las estructuras de datos, cambios a lo largo del ciclo de vida, resultados de las pruebas y copia de la ficha informativa y de la declaración de conformidad. Si la autoridad la pide, hay treinta días para entregarla, menos si un riesgo grave e inmediato lo justifica; no entregarla puede acabar en una prueba encargada a un organismo independiente a costa del fabricante.

Dónde está la ciber Es el expediente donde se demuestra el cumplimiento de los requisitos esenciales, incluidos los de seguridad y registro: el anexo III exige los resultados y el análisis crítico de todas las verificaciones y pruebas realizadas para demostrarlo. Y el artículo 30.3 obliga a poner a disposición de la autoridad, previa solicitud motivada, el código fuente o la lógica de programación si hace falta para comprobar esa conformidad.
Recae sobre
Alimenta estas medidas

Art. 37 y anexo III

Qué implantar · Sistema HCE: conformidad y mercado

Declaración UE de conformidad Ciber parcial

No hay organismo notificado: la conformidad se autoevalúa. El fabricante elabora la declaración UE de conformidad con el contenido del anexo IV, que se emite bajo su responsabilidad exclusiva y se complementa con los resultados obtenidos en el entorno digital de pruebas. Si el sistema cae además bajo otros actos de la Unión que exijan declaración, se elabora una sola. En formato digital debe seguir accesible en línea durante la vida útil prevista y al menos diez años.

Dónde está la ciber Lo que la declaración afirma es el cumplimiento de los requisitos esenciales del anexo II en bloque, y ahí dentro está la sección de seguridad y registro. Al firmarla el fabricante asume la responsabilidad de esa conformidad en el momento de introducir el sistema en el mercado.
Recae sobre
Alimenta estas medidas

Art. 39 y anexo IV

Qué implantar · Sistema HCE: conformidad y mercado

Marcado CE Ciber parcial

El marcado se coloca de manera visible, legible e indeleble en los documentos que acompañan al sistema y, cuando proceda, en su embalaje, siempre antes de introducirlo en el mercado. Le son de aplicación los principios generales del Reglamento (CE) n.º 765/2008. La obligación de colocarlo es exigible desde la aplicación general, en 2027; lo que llega después, en 2029 y 2031, es la prohibición del artículo 26 de introducir en el mercado sistemas que no cumplan el capítulo III.

Dónde está la ciber Es la señal externa de que se han cumplido los requisitos esenciales del anexo II, la sección de seguridad y registro incluida. Colocarlo indebidamente es una de las causas tasadas de incumplimiento del artículo 45.1.
Recae sobre
Alimenta estas medidas

Art. 41

Qué implantar · Sistema HCE: conformidad y mercado

Evaluación en el entorno digital de pruebas Ciber parcial

Antes de introducir el sistema en el mercado, el fabricante tiene que usar el entorno digital de pruebas europeo, o el que opere su Estado miembro conforme a las especificaciones comunes, para evaluar los componentes armonizados. Los resultados van a la documentación técnica y los elementos evaluados con resultado positivo se presumen conformes con el Reglamento.

Dónde está la ciber Lo que se evalúa en el entorno de pruebas son los componentes armonizados, y uno de los dos es el componente europeo de registro. Los elementos con resultado positivo se presumen conformes, así que es la vía por la que el cumplimiento de la sección de seguridad y registro del anexo II se acredita antes de vender.
Recae sobre
Alimenta estas medidas

Art. 40

Qué implantar · Sistema HCE: conformidad y mercado

Procedimientos que sostienen la conformidad Ciber parcial

El fabricante mantiene procedimientos para que el diseño, el desarrollo y la implantación de los componentes armonizados sigan cumpliendo los requisitos esenciales y las especificaciones comunes, y conserva la documentación técnica y la declaración de conformidad durante diez años desde la introducción en el mercado.

Dónde está la ciber La conformidad con el anexo II, seguridad incluida, no se acredita una vez: el fabricante debe tener procedimientos que garanticen que el diseño, el desarrollo y la implantación de los componentes armonizados la siguen cumpliendo, y todo cambio de diseño o de características debe reflejarse en la documentación técnica.
Recae sobre
Alimenta estas medidas

Art. 30.2 y 30.3

Qué implantar · Sistema HCE: conformidad y mercado

Ficha informativa e instrucciones de uso

El sistema va acompañado, gratis para el usuario, de una ficha con la identidad y contacto del fabricante, el nombre y versión del sistema, su finalidad prevista, las categorías de datos para las que está diseñado y las normas, formatos y especificaciones con los que funciona, con sus versiones. En vez de entregarla, el fabricante puede volcar esa información en la base de datos de la UE. El artículo 28 prohíbe además que la ficha, las instrucciones o la publicidad induzcan a error sobre la interoperabilidad o la seguridad del sistema.

Recae sobre

Art. 38

Qué implantar · Sistema HCE: conformidad y mercado

Registro en la base de datos de la UE

Antes de introducir en el mercado o poner en servicio el sistema HCE, o de comercializar la aplicación de bienestar con etiqueta, el fabricante o su representante autorizado introduce los datos exigidos en la base de datos pública de la UE, incluidos, para los sistemas HCE, los resultados de la evaluación en el entorno de pruebas. Los productos sanitarios, los de diagnóstico in vitro y los sistemas de IA de alto riesgo del artículo 27 se registran en sus propias bases de datos y los datos se transmiten además a esta.

Recae sobre

Art. 49

Qué implantar · Sistema HCE: conformidad y mercado

Deberes del representante, el importador y el distribuidor Ciber parcial

El fabricante de fuera de la Unión designa por mandato escrito un representante autorizado establecido aquí. El importador solo introduce sistemas conformes y responde de que no se alteren mientras están bajo su responsabilidad; el distribuidor verifica el marcado y la documentación antes de comercializar. Quien comercialice el sistema con su propia marca, lo modifique de forma que pueda verse afectada su conformidad o cambie su finalidad prevista pasa a ser fabricante a todos los efectos. Todos ellos deben poder identificar durante diez años a quien les suministró el sistema y a quien se lo suministraron.

Dónde está la ciber Lo que estos operadores verifican y no pueden comprometer son los requisitos esenciales del anexo II, que incluyen la sección de seguridad y registro: el importador solo puede introducir sistemas conformes con ellos y ni él ni el distribuidor pueden alterar el sistema de forma que esa conformidad se vea comprometida.
Recae sobre

Arts. 31 a 35

Qué implantar · Sistema HCE: incidentes y vigilancia

Aviso de incidente grave Ciber

El fabricante notifica todo incidente grave que afecte a un sistema HCE a las autoridades de vigilancia del mercado de los Estados miembros donde se produjo y donde el sistema se introdujo o se puso en servicio, incluyendo en la notificación la medida correctiva adoptada o prevista. El plazo tiene dos disparadores: inmediatamente al establecer el vínculo causal o la posibilidad razonable de que exista, y en todo caso tres días desde que se tiene conocimiento del incidente. La notificación se hace sin perjuicio de la que corresponda por la Directiva (UE) 2022/2555. Los Estados miembros pueden habilitar además a los usuarios del sistema para notificar.

Literal de la norma La notificación que se exige con arreglo al párrafo primero del presente apartado se efectuará, sin perjuicio de los requisitos de notificación de incidentes en virtud de la Directiva (UE) 2022/2555, inmediatamente después de que el fabricante haya establecido un vínculo causal entre el sistema HCE y el incidente grave, o la posibilidad razonable de que exista dicho vínculo, y, en cualquier caso, a más tardar tres días después de que el fabricante tenga conocimiento del incidente grave que afecta al sistema HCE.
Recae sobre
Alimenta estas medidas

Art. 44.7

Qué implantar · Sistema HCE: incidentes y vigilancia

Medidas correctivas y cooperación con la vigilancia del mercado Ciber parcial

En cuanto el fabricante estima o tiene motivos para creer que su sistema no es conforme con los requisitos esenciales, adopta sin demora indebida las medidas correctivas necesarias o lo recupera o retira, e informa a las autoridades nacionales de los Estados donde lo comercializó con el calendario de aplicación y la fecha de puesta en conformidad. Informa también a distribuidores, importadores y usuarios de la no conformidad y del mantenimiento preventivo obligatorio, mantiene canales de reclamación y lleva registro de las reclamaciones y de los sistemas no conformes. Si no coopera con la autoridad de vigilancia del mercado o entrega información incompleta o incorrecta, esta puede prohibir o restringir la comercialización hasta que lo haga.

Dónde está la ciber El disparador de estas obligaciones es la no conformidad con los requisitos esenciales del anexo II, y una de las causas tasadas de incumplimiento del artículo 45.1 es precisamente esa. Cuando lo que falla es la sección de seguridad y registro, este es el procedimiento que se activa.
Recae sobre
Alimenta estas medidas

Arts. 30.1.i) a o), 44.1 y 45

Qué implantar · Productos que declaran interoperabilidad

Conformidad del producto sanitario que declara interoperabilidad Ciber parcial

El fabricante de un producto sanitario o de un producto sanitario para diagnóstico in vitro que declare la interoperabilidad de su producto con los componentes armonizados de los sistemas HCE tiene que demostrar la conformidad con los requisitos esenciales aplicables a esos dos componentes. Le es aplicable además el artículo 36, así que las especificaciones comunes que adopte la Comisión (que deben tener en cuenta las especificidades de estos productos) le dan también a él la presunción de conformidad. Nadie contrae este deber por accidente: se contrae al declarar la interoperabilidad.

Literal de la norma Los fabricantes de productos sanitarios o de productos sanitarios para diagnóstico in vitro, tal como se definen en el artículo 2, punto 1, del Reglamento (UE) 2017/745 y el artículo 2, punto 2, del Reglamento (UE) 2017/746, respectivamente, que declaren la interoperabilidad de dichos productos sanitarios o productos sanitarios para diagnóstico en vitro con los componentes armonizados de programa informático de los sistemas HCE deberán demostrar la conformidad con los requisitos esenciales aplicables al componente de programa informático europeo de interoperabilidad para sistemas HCE y al componente de programa informático europeo de registro para sistemas HCE establecidos en el anexo II, sección 2, del presente Reglamento. […]
Dónde está la ciber El artículo nombra los dos componentes armonizados, y uno de ellos es el componente europeo de registro, cuyo formato el propio Reglamento sitúa en el punto 3.2 del anexo II, dentro de la sección de seguridad y registro. La remisión literal del artículo, en cambio, es a la sección 2 del anexo, la de interoperabilidad. Quien cierra el desajuste es la entrada del propio anexo II, que declara sus requisitos esenciales aplicables mutatis mutandis a los productos que declaren la interoperabilidad: por esa vía la traza de acceso viaja dentro del deber, aunque la remisión del artículo apunte a otra sección.
Recae sobre

Art. 27.1

Qué implantar · Productos que declaran interoperabilidad

Conformidad del sistema de IA de alto riesgo que declara interoperabilidad Ciber parcial

El proveedor de un sistema de IA clasificado de alto riesgo por el artículo 6 del Reglamento (UE) 2024/1689 que no entre en el ámbito de los Reglamentos de productos sanitarios y que declare la interoperabilidad con los componentes armonizados de los sistemas HCE debe demostrar la conformidad con los requisitos esenciales aplicables a esos componentes, y le es aplicable el artículo 36. La vigilancia del mercado de estos sistemas no la ejerce la autoridad del Reglamento del dato sanitario, sino la designada bajo el Reglamento de IA.

Dónde está la ciber Vale aquí lo mismo que en el apartado anterior: el deber se enuncia sobre los dos componentes armonizados, el de registro incluido, y la entrada del anexo II extiende sus requisitos esenciales mutatis mutandis a los sistemas de IA que declaren la interoperabilidad.
Recae sobre

Art. 27.2

Qué implantar · Productos que declaran interoperabilidad

Etiqueta de la aplicación de bienestar Ciber parcial

Si el fabricante de una aplicación de bienestar declara la interoperabilidad con un sistema HCE, la aplicación debe llevar una etiqueta, expedida por él mismo, que indique con claridad su conformidad con las especificaciones comunes y los requisitos esenciales. La etiqueta dice para qué categorías de datos se ha confirmado el cumplimiento, con qué especificaciones comunes se demuestra y hasta cuándo vale, y su validez no puede pasar de tres años. Cuando la aplicación es solo software, la etiqueta es digital y va en la propia aplicación.

Dónde está la ciber Lo que la etiqueta declara es el cumplimiento de los requisitos esenciales del anexo II, cuya sección 3 es la de seguridad y registro, extendida a estas aplicaciones por la entrada del propio anexo. Y la autoridad de vigilancia del mercado comprueba esa conformidad, así que la declaración no queda sin control.
Recae sobre

Art. 47

Qué implantar · Productos que declaran interoperabilidad

Límites de la interoperabilidad de la aplicación de bienestar

Declarar la interoperabilidad no habilita a volcar datos. El intercambio o la transmisión solo son posibles con el consentimiento previo de la persona y por la vía del artículo 5, y la interoperabilidad se limita a esos fines. El fabricante tiene que garantizar que la persona pueda elegir qué categorías de datos pasan al sistema HCE y en qué circunstancias, e informar a los usuarios de qué implica esa interoperabilidad.

Recae sobre

Art. 48

Qué implantar · Uso primario

Registro de los datos en el sistema HCE

Cuando el prestador de asistencia sanitaria trate datos en formato electrónico, debe registrar en un sistema HCE los datos de las categorías prioritarias y mantenerlos actualizados con la información de la asistencia prestada. Al registrar o actualizar, la historia debe indicar qué profesional y qué prestador lo hicieron y cuándo; el Derecho nacional puede exigir que se registre algo más.

Recae sobre

Art. 13

Qué implantar · Uso primario

Acceso de los profesionales con identidad electrónica reconocida Ciber parcial

Los profesionales sanitarios acceden a los datos pertinentes y necesarios de la persona a la que tratan, con independencia del Estado miembro de afiliación, a través de los servicios de acceso para profesionales y con medios de identificación electrónica reconocidos. Los Estados miembros establecen qué categorías de datos puede ver cada categoría de profesional o cada tarea asistencial. Si la persona ha limitado el acceso, no se informa al profesional del contenido limitado, salvo que sea necesario para proteger sus intereses vitales, y ese acceso excepcional queda registrado de forma clara y accesible para ella.

Dónde está la ciber El control de acceso está en el enunciado, no en un desarrollo posterior: el servicio solo es accesible con medios de identificación electrónica reconocidos conforme al artículo 6 del Reglamento (UE) n.º 910/2014 o que cumplan las especificaciones comunes, y el acceso se limita a los datos pertinentes y necesarios de la persona a la que se está tratando.
Recae sobre

Arts. 11 y 12

Qué implantar · Uso primario

Información a la persona sobre quién accedió a sus datos Ciber parcial

La persona tiene derecho a saber, incluso mediante notificaciones automáticas, quién ha accedido a sus datos de salud a través del servicio de acceso de los profesionales. La información se da gratis y sin demora, y debe estar disponible durante al menos tres años desde el acceso, con el prestador o la persona que accedió, la fecha y hora y los datos a los que se accedió. Los Estados miembros pueden limitar este derecho en circunstancias excepcionales.

Dónde está la ciber Es la cara visible de la traza que el anexo II obliga a grabar: la información sobre quién accedió, cuándo y a qué datos debe estar disponible para la persona durante al menos tres años. Ese plazo es, en la práctica, un plazo de retención del registro de accesos.
Recae sobre
Alimenta estas medidas

Art. 9

Qué implantar · Uso secundario

Entorno de tratamiento seguro Ciber

Los datos para uso secundario solo se entregan dentro de un entorno de tratamiento seguro que opera el organismo de acceso, con seis medidas tasadas: acceso limitado a las personas autorizadas que enumera el permiso de datos; minimización del riesgo de lectura, copia, modificación o supresión no autorizadas con las medidas técnicas y organizativas más avanzadas; limitación de quién puede introducir, inspeccionar, modificar o suprimir datos; identidades de usuario individuales y únicas con modos de acceso confidenciales; registros identificables de acceso y actividad conservados al menos un año; y seguimiento continuo de esas medidas. Encima, auditorías periódicas del entorno, también por terceros, con medidas correctivas sobre lo que detecten. Del entorno solo puede descargarse dato no personal, y el organismo revisa cada petición de descarga para asegurarlo.

Literal de la norma Los organismos de acceso a datos de salud proporcionarán acceso a los datos de salud electrónicos en virtud de un permiso de datos únicamente a través de un entorno de tratamiento seguro sometido a medidas técnicas y organizativas y requisitos de seguridad e interoperabilidad. […]
Recae sobre
Alimenta estas medidas

Art. 73

Qué implantar · Uso secundario

Deberes del usuario de datos de salud Ciber parcial

El usuario solo puede tratar los datos al amparo del permiso, la petición aprobada o la aprobación de acceso. Dentro del entorno seguro no puede dar acceso a terceros no incluidos en el permiso, y en ningún caso puede reidentificar ni intentar reidentificar a las personas. Debe publicar los resultados en el plazo de dieciocho meses desde que termina el tratamiento, solo con datos anonimizados, citando la fuente y el hecho de haberlos obtenido en el marco del espacio europeo. Y tiene un deber que se olvida: informar al organismo de acceso de cualquier hallazgo significativo relacionado con la salud de la persona cuyos datos están en el conjunto.

Dónde está la ciber Dos de los deberes son controles de seguridad del dato en manos de quien lo explota: no dar acceso a terceros que no figuren en el permiso ni ponerlo a su disposición, y no reidentificar ni intentar reidentificar a las personas. Son además las dos conductas que el artículo 64.5 castiga con el escalón alto de multa.
Recae sobre
Alimenta estas medidas

Art. 61

Qué implantar · Uso secundario

Usos secundarios prohibidos

Aunque haya permiso, hay finalidades vedadas: tomar decisiones perjudiciales con efectos jurídicos, económicos o sociales sobre una persona o un grupo; decidir sobre ofertas de empleo, condiciones de bienes y servicios, seguros o crédito de forma discriminatoria; publicidad y mercadotecnia; desarrollar productos que puedan perjudicar a las personas o a la salud pública, con ejemplos tasados que llegan al tabaco, el alcohol y el armamento; y actividades que choquen con el Derecho nacional en materia de ética.

Recae sobre

Art. 54

Qué implantar · Uso secundario

Puesta a disposición de los datos por el tenedor

El tenedor pone los datos a disposición del organismo de acceso en un plazo razonable y, como máximo, tres meses desde la petición, prorrogables por otros tres en casos justificados. Comunica además la descripción de sus conjuntos de datos y comprueba al menos una vez al año que esa descripción sigue siendo exacta y actualizada.

Recae sobre

Art. 60

Medida

Gestión de identidades y accesos (IAM) Compartida

Un sistema de gestión de identidades y accesos: cada identidad, humana o de máquina, es conocida, se autentica por un punto controlado y pierde el acceso cuando corresponde.

Cómo se despliega Un directorio o IdP centralizado con SSO como fuente única de identidad, con altas, cambios de puesto y bajas ligados al proceso de recursos humanos. Las identidades de máquina (cuentas de servicio, tokens, claves de API) con dueño, caducidad y custodia en un gestor de secretos, porque habitualmente quedan fuera de los procesos de baja.
Qué exige esta norma
  • Políticas de control de acceso
  • Mínimo privilegio y segregación de funciones
Matiz de esta norma La autenticación no es una decisión del cliente que despliega el sistema, es un requisito del producto: el fabricante tiene que llevarla dentro. El texto pide mecanismos fiables sin concretar factores ni nivel de garantía, y esa concreción llega por las especificaciones comunes del artículo 36, que pueden incluir requisitos de gestión de la identificación y de uso de la identidad electrónica. El mínimo privilegio entra por una vía poco habitual: el punto 3.4 del anexo II exige que el sistema permita derechos de acceso diferenciados según el origen y la categoría del dato, así que un modelo de permisos de todo o nada sobre la historia completa no cumple el requisito esencial.
Categoría CSF 2.0 PR.AA · Gestión de identidades, autenticación y control de acceso
Emana de

Anexo II, puntos 3.1 y 3.4 · categorización del curador, no de la norma

Medida

Monitorización y detección Compartida

Capacidad de observar de forma continua lo que ocurre en sistemas, redes y servicios, sostenida como un servicio con responsable y no como una herramienta desatendida.

Cómo se despliega La vigilancia contratada o desplegada según la madurez de la organización (propia, gestionada o híbrida), con la cobertura decidida desde el riesgo y documentada (qué entra, qué queda fuera y por qué), de forma que los puntos ciegos sean decisiones registradas y no descubrimientos del análisis posterior de un incidente.
Qué exige esta norma
  • Registro de la actividad con retención suficiente, protegido frente a alteración y con los relojes sincronizados
  • Detección y análisis de anomalías e indicios de incidente
Matiz de esta norma Los cinco campos del registro están tasados y uno de ellos no es habitual: además de quién, cuándo y qué categorías de datos, hay que grabar el origen u orígenes de los datos a los que se accedió. Y el punto 3.3 convierte la capacidad de análisis en requisito de producto: el sistema incluye herramientas para revisar y analizar los registros, o permite conectar software externo que lo haga. El plazo de retención no está en el anexo sino en el derecho de la persona a saber quién accedió, que debe poder ejercerse durante al menos tres años.
Categoría CSF 2.0 DE.CM · Monitoreo continuoDE.AE · Análisis de acontecimientos adversos

La observación continua es DE.CM; el triaje de lo que salta (correlacionar fuentes, estimar alcance, decidir si esto es algo) es DE.AE. La declaración formal del incidente contra criterios vive en la clasificación de respuesta a incidentes, y la frontera es deliberada: aquí se decide que hay algo, allí qué es y qué reloj arranca.

Emana de

Anexo II, puntos 3.2 y 3.3 · art. 9.2 · categorización del curador, no de la norma

Medida

Conformidad y certificación Compartida

Poder demostrar a un tercero lo que se ha hecho, en sus dos versiones: la conformidad de la organización, que se audita y se certifica, y la del producto, que se evalúa, se documenta y se marca antes de venderlo. Es el expediente que convierte el cumplimiento en algo oponible a un cliente, a un pliego o a un supervisor.

Cómo se despliega Un repositorio de evidencias al día, una relación estable con quien evalúa desde fuera y el calendario de la acreditación gestionado como un compromiso más del negocio. El dueño lo fija cada norma: el sistema de gestión de la organización, o quien responde del producto.
Qué exige esta norma
  • Vía de evaluación de la conformidad elegida y documentada según la clase de riesgo
  • Documentación técnica y declaración de conformidad conservadas y a disposición de la autoridad
  • Marcado o declaración pública de conformidad antes de comercializar
Matiz de esta norma No hay organismo notificado ni certificado de tercero: la vía es la autoevaluación, con declaración UE de conformidad emitida bajo responsabilidad exclusiva del fabricante y marcado CE. El tercero aparece de dos maneras indirectas: el entorno digital de pruebas, que da presunción de conformidad a los elementos con resultado positivo, y la facultad de la autoridad de vigilancia del mercado de exigir una prueba por un organismo independiente a costa del fabricante si este no entrega la documentación técnica. La documentación y la declaración se conservan diez años.
Categoría CSF 2.0 GV.OC · Contexto organizativo

GV.OC recoge los requisitos legales y reglamentarios comprendidos y gestionados; la acreditación externa es su prueba oponible. La mejora que sale de esa auditoría no se queda aquí: va a evaluación de la eficacia (ID.IM). Aquí se demuestra; allí se corrige.

Emana de

Arts. 37, 39, 40 y 41 · categorización del curador, no de la norma

Medida

Adquisición y desarrollo seguros Compartida

La seguridad como requisito de compra y de construcción: exigencias al adquirir, prácticas de desarrollo seguro al construir y mantenimiento con la seguridad dentro durante todo el ciclo de vida.

Cómo se despliega La seguridad integrada en el flujo de construir y de comprar, con un criterio de aceptación explícito y un responsable de sostenerlo: su incumplimiento impide el paso a producción o la firma del contrato.
Qué exige esta norma
  • Seguridad en la adquisición, el desarrollo y el mantenimiento de sistemas
Matiz de esta norma La conformidad con los requisitos esenciales tiene que sostenerse en el diseño, el desarrollo y la implantación, no acreditarse una sola vez, y todo cambio de diseño o de características de los componentes armonizados debe reflejarse en la documentación técnica. El Reglamento no define una puerta de modificación sustancial como otras normas de producto: lo que exige es el procedimiento que mantiene la conformidad viva.
Categoría CSF 2.0 PR.PS · Seguridad de la plataforma
Emana de

Art. 30.2 · categorización del curador, no de la norma

Medida

Proceso de notificación regulatoria Compartida

Saber a quién, qué y en cuánto tiempo hay que notificar un incidente, y poder hacerlo bajo presión y con los relojes en contra.

Cómo se despliega Un procedimiento con responsables designados y suplentes, el asesor jurídico y comunicación dentro del circuito, y ensayos que comprueben si el procedimiento funciona bajo presión. Cada reloj arranca en un hecho distinto (conocer el incidente, clasificarlo o que ocurra), así que alguien declara ese momento y queda anotado; y un mismo incidente suele exigir varias notificaciones simultáneas, que deben ser coherentes entre sí.
Qué exige esta norma
  • Notificación de incidentes a la autoridad o al CSIRT en los plazos de la norma
  • Aviso a los destinatarios o afectados cuando el incidente pueda tocarles
Matiz de esta norma El destinatario no es un CSIRT sino la autoridad de vigilancia del mercado, y son varias a la vez: la del Estado donde se produjo el incidente y las de aquellos donde el sistema se introdujo o se puso en servicio. El plazo tiene dos disparadores encadenados y el de tres días corre desde el conocimiento, no desde la confirmación de la causa. El aviso a afectados no es automático: nace cuando la autoridad de vigilancia del mercado considera que el sistema ha causado perjuicio a la salud, la seguridad o el interés público, y entonces el fabricante debe informar de inmediato a la persona o usuario perjudicado y, en su caso, a otros terceros.
Categoría CSF 2.0 RS.CO · Notificación y comunicación de la respuesta al incidente
Emana de

Arts. 44.7 y 44.3 · categorización del curador, no de la norma

Medida

Entorno de tratamiento seguro para el uso secundario

Una plataforma cerrada donde el dato se explota sin salir de ella. El acceso se limita a las personas físicas autorizadas que enumera el permiso de datos, cada una con identidad de usuario individual y única y modo de acceso confidencial; el riesgo de lectura, copia, modificación o supresión no autorizadas se minimiza con las medidas técnicas y organizativas más avanzadas; los registros de acceso y de actividad se conservan al menos un año para poder verificar y auditar todas las operaciones; y las medidas se someten a seguimiento continuo y a auditorías periódicas, también por terceros, con corrección de lo que detecten. La salida está controlada por diseño: solo puede descargarse dato no personal, y cada petición de descarga se revisa antes de autorizarla.

Qué exige esta norma
  • Acceso limitado a las personas autorizadas enumeradas en el permiso, con identidades individuales y únicas y modos de acceso confidenciales
  • Medidas técnicas y organizativas más avanzadas contra la lectura, copia, modificación o supresión no autorizadas
  • Registros identificables de acceso y de actividad conservados al menos un año, suficientes para auditar todas las operaciones
  • Auditorías periódicas del entorno, también por terceros, con medidas correctivas sobre las deficiencias detectadas
  • Revisión de cada petición de descarga para que solo salgan datos no personales o anonimizados
Categoría CSF 2.0 PR.AA · Gestión de identidades, autenticación y control de accesoPR.DS · Seguridad de los datosDE.CM · Monitoreo continuoGV.OC · Contexto organizativo
Emana de

Art. 73.1 a 73.3 · categorización del curador, no de la norma

Mapa NIST CSF · todo el detalle

Las obligaciones ciber de la norma, traducidas a medidas y organizadas por las funciones y categorías de NIST CSF 2.0 (traducción oficial al español, NIST CSWP 29). La asignación de categoría es juicio del curador; cada medida cita las obligaciones de las que emana.

Gobernar · GV

Conformidad y certificación ◆

No hay organismo notificado ni certificado de tercero: la vía es la autoevaluación, con declaración UE de conformidad emitida bajo responsabilidad exclusiva del fabricante y marcado CE. El tercero aparece de dos maneras indirectas: el entorno digital de pruebas, que da presunción de conformidad a los elementos con resultado positivo, y la facultad de la autoridad de vigilancia del mercado de exigir una prueba por un organismo independiente a costa del fabricante si este no entrega la documentación técnica. La documentación y la declaración se conservan diez años.

GV.OC · Arts. 37, 39, 40 y 41
Entorno de tratamiento seguro para el uso secundario

Una plataforma cerrada donde el dato se explota sin salir de ella. El acceso se limita a las personas físicas autorizadas que enumera el permiso de datos, cada una con identidad de usuario individual y única y modo de acceso confidencial; el riesgo de lectura, copia, modificación o supresión no autorizadas se minimiza con las medidas técnicas y organizativas más avanzadas; los registros de acceso y de actividad se conservan al menos un año para poder verificar y auditar todas las operaciones; y las medidas se someten a seguimiento continuo y a auditorías periódicas, también por terceros, con corrección de lo que detecten. La salida está controlada por diseño: solo puede descargarse dato no personal, y cada petición de descarga se revisa antes de autorizarla.

GV.OC · Art. 73.1 a 73.3

Proteger · PR

Gestión de identidades y accesos (IAM) ◆

La autenticación no es una decisión del cliente que despliega el sistema, es un requisito del producto: el fabricante tiene que llevarla dentro. El texto pide mecanismos fiables sin concretar factores ni nivel de garantía, y esa concreción llega por las especificaciones comunes del artículo 36, que pueden incluir requisitos de gestión de la identificación y de uso de la identidad electrónica. El mínimo privilegio entra por una vía poco habitual: el punto 3.4 del anexo II exige que el sistema permita derechos de acceso diferenciados según el origen y la categoría del dato, así que un modelo de permisos de todo o nada sobre la historia completa no cumple el requisito esencial.

PR.AA · Anexo II, puntos 3.1 y 3.4
Entorno de tratamiento seguro para el uso secundario

Una plataforma cerrada donde el dato se explota sin salir de ella. El acceso se limita a las personas físicas autorizadas que enumera el permiso de datos, cada una con identidad de usuario individual y única y modo de acceso confidencial; el riesgo de lectura, copia, modificación o supresión no autorizadas se minimiza con las medidas técnicas y organizativas más avanzadas; los registros de acceso y de actividad se conservan al menos un año para poder verificar y auditar todas las operaciones; y las medidas se someten a seguimiento continuo y a auditorías periódicas, también por terceros, con corrección de lo que detecten. La salida está controlada por diseño: solo puede descargarse dato no personal, y cada petición de descarga se revisa antes de autorizarla.

PR.AA · Art. 73.1 a 73.3
Entorno de tratamiento seguro para el uso secundario

Una plataforma cerrada donde el dato se explota sin salir de ella. El acceso se limita a las personas físicas autorizadas que enumera el permiso de datos, cada una con identidad de usuario individual y única y modo de acceso confidencial; el riesgo de lectura, copia, modificación o supresión no autorizadas se minimiza con las medidas técnicas y organizativas más avanzadas; los registros de acceso y de actividad se conservan al menos un año para poder verificar y auditar todas las operaciones; y las medidas se someten a seguimiento continuo y a auditorías periódicas, también por terceros, con corrección de lo que detecten. La salida está controlada por diseño: solo puede descargarse dato no personal, y cada petición de descarga se revisa antes de autorizarla.

PR.DS · Art. 73.1 a 73.3
Adquisición y desarrollo seguros ◆

La conformidad con los requisitos esenciales tiene que sostenerse en el diseño, el desarrollo y la implantación, no acreditarse una sola vez, y todo cambio de diseño o de características de los componentes armonizados debe reflejarse en la documentación técnica. El Reglamento no define una puerta de modificación sustancial como otras normas de producto: lo que exige es el procedimiento que mantiene la conformidad viva.

PR.PS · Art. 30.2

Detectar · DE

Monitorización y detección ◆

Los cinco campos del registro están tasados y uno de ellos no es habitual: además de quién, cuándo y qué categorías de datos, hay que grabar el origen u orígenes de los datos a los que se accedió. Y el punto 3.3 convierte la capacidad de análisis en requisito de producto: el sistema incluye herramientas para revisar y analizar los registros, o permite conectar software externo que lo haga. El plazo de retención no está en el anexo sino en el derecho de la persona a saber quién accedió, que debe poder ejercerse durante al menos tres años.

DE.CM · Anexo II, puntos 3.2 y 3.3 · art. 9.2
Entorno de tratamiento seguro para el uso secundario

Una plataforma cerrada donde el dato se explota sin salir de ella. El acceso se limita a las personas físicas autorizadas que enumera el permiso de datos, cada una con identidad de usuario individual y única y modo de acceso confidencial; el riesgo de lectura, copia, modificación o supresión no autorizadas se minimiza con las medidas técnicas y organizativas más avanzadas; los registros de acceso y de actividad se conservan al menos un año para poder verificar y auditar todas las operaciones; y las medidas se someten a seguimiento continuo y a auditorías periódicas, también por terceros, con corrección de lo que detecten. La salida está controlada por diseño: solo puede descargarse dato no personal, y cada petición de descarga se revisa antes de autorizarla.

DE.CM · Art. 73.1 a 73.3
Monitorización y detección ◆

Los cinco campos del registro están tasados y uno de ellos no es habitual: además de quién, cuándo y qué categorías de datos, hay que grabar el origen u orígenes de los datos a los que se accedió. Y el punto 3.3 convierte la capacidad de análisis en requisito de producto: el sistema incluye herramientas para revisar y analizar los registros, o permite conectar software externo que lo haga. El plazo de retención no está en el anexo sino en el derecho de la persona a saber quién accedió, que debe poder ejercerse durante al menos tres años.

DE.AE · Anexo II, puntos 3.2 y 3.3 · art. 9.2

Responder · RS

Proceso de notificación regulatoria ◆

El destinatario no es un CSIRT sino la autoridad de vigilancia del mercado, y son varias a la vez: la del Estado donde se produjo el incidente y las de aquellos donde el sistema se introdujo o se puso en servicio. El plazo tiene dos disparadores encadenados y el de tres días corre desde el conocimiento, no desde la confirmación de la causa. El aviso a afectados no es automático: nace cuando la autoridad de vigilancia del mercado considera que el sistema ha causado perjuicio a la salud, la seguridad o el interés público, y entonces el fabricante debe informar de inmediato a la persona o usuario perjudicado y, en su caso, a otros terceros.

RS.CO · Arts. 44.7 y 44.3
Roles que reparte
Rol

Fabricante de sistema HCE

Quien introduce en el mercado o pone en servicio un sistema de historia clínica electrónica con su nombre o marca. El Reglamento no define «fabricante» por su cuenta: toma la definición del Reglamento (UE) 2019/1020 de vigilancia del mercado. El papel se contagia: el importador, el distribuidor o el usuario que comercialice el sistema con su propia marca, que lo modifique de forma que pueda verse afectada su conformidad, o que cambie la finalidad prevista declarada, pasan a ser fabricantes y asumen el artículo 30 entero.

Art. 2.1.d) · arts. 30 y 34

Rol

Representante autorizado

Quien, establecido en la Unión, recibe mandato escrito de un fabricante de fuera de la Unión antes de que este comercialice aquí su sistema HCE. El mandato tiene un contenido mínimo tasado, y el representante debe disponer de la documentación necesaria para cumplirlo.

Art. 31 · art. 30.4

Rol

Importador

Quien introduce en el mercado de la Unión un sistema HCE procedente de un tercer país. Solo puede introducir sistemas conformes con el anexo II y con las especificaciones comunes, y responde de que el sistema no se altere mientras está bajo su responsabilidad.

Art. 32

Rol

Distribuidor

Quien comercializa un sistema HCE sin ser su fabricante ni el importador. Debe verificar el marcado CE y la documentación antes de comercializarlo, y no puede alterar el sistema de forma que comprometa su conformidad.

Art. 33

Rol

Fabricante de producto sanitario

Fabricante de un producto sanitario o de un producto sanitario para diagnóstico in vitro, en el sentido de los Reglamentos (UE) 2017/745 y (UE) 2017/746, que declara la interoperabilidad de su producto con los componentes armonizados de programa informático de los sistemas HCE. La declaración es voluntaria; hacerla es lo que activa el deber.

Art. 27.1

Rol

Proveedor de IA de alto riesgo

Proveedor de un sistema de IA considerado de alto riesgo por el artículo 6 del Reglamento (UE) 2024/1689 que no entra en el ámbito de los Reglamentos de productos sanitarios y que declara la interoperabilidad de ese sistema con los componentes armonizados de los sistemas HCE. Tiene el mismo deber que el fabricante de producto sanitario y por la misma vía.

Art. 27.2

Rol

Fabricante de aplicación de bienestar

Quien fabrica un programa informático destinado a que una persona física trate sus datos de salud con una finalidad distinta de la prestación de asistencia sanitaria. Solo queda alcanzado si declara la interoperabilidad con un sistema HCE, y entonces debe expedir la etiqueta que acredita el cumplimiento del anexo II.

Art. 2.2, letra ab) · arts. 47 y 48

Rol

Prestador de asistencia sanitaria

Quien presta asistencia sanitaria en el sentido de la Directiva 2011/24/UE. Es el usuario del sistema HCE: registra en formato electrónico los datos de las categorías prioritarias y mantiene actualizada la historia de la persona a la que trata.

Art. 2.1.b) · art. 13

Rol

Profesional sanitario

Quien accede a los datos de salud electrónicos personales de la persona a la que está tratando, a través de los servicios de acceso para profesionales. Solo puede hacerlo con medios de identificación electrónica reconocidos conforme al Reglamento (UE) n.º 910/2014 o que cumplan las especificaciones comunes.

Art. 2.1.b) · arts. 11 y 12

Rol

Tenedor de datos de salud

Quien tiene el derecho o la obligación de tratar datos de salud electrónicos personales, o la capacidad de poner a disposición datos no personales controlando el diseño técnico de un producto. Es una categoría ancha: alcanza a centros sanitarios, a quien desarrolla productos o servicios para el sector, a quien crea aplicaciones de bienestar y a quien investiga.

Literal de la norma toda persona física o jurídica, autoridad pública, agencia u otro organismo del sector de la asistencia sanitaria o el asistencial, incluidos los servicios de reembolso cuando sea necesario, así como cualquier persona física o jurídica que desarrolle productos o servicios destinados al sector de la salud, el de la asistencia sanitaria o el asistencial, que desarrolle o cree aplicaciones de bienestar, que efectúe investigaciones científicas relacionadas con el sector de la asistencia sanitaria o el asistencial o que actúe como registro de mortalidad, así como las instituciones, órganos u organismos de la Unión, que tengan bien: […]

Art. 2.2, letra t)

Rol

Usuario de datos de salud

Quien ha obtenido acceso lícito a datos de salud electrónicos para uso secundario mediante un permiso de datos, una petición aprobada o una aprobación de acceso. Trabaja dentro del entorno de tratamiento seguro y no puede sacar de él datos personales.

Literal de la norma una persona física o jurídica, incluidas las instituciones, órganos u organismos de la Unión, a la que se ha concedido acceso lícito a datos de salud electrónicos para uso secundario en virtud de un permiso de datos, una petición de datos de salud o una aprobación de acceso por parte de un participante autorizado en DatosSalud@UE

Art. 2.2, letra u)

Rol

Organismo de acceso a datos de salud

Organismo del sector público que cada Estado miembro designa para tramitar las solicitudes de acceso a datos para uso secundario, expedir los permisos y operar el entorno de tratamiento seguro. No es solo una ventanilla: es quien responde de las medidas de seguridad del artículo 73 y quien impone las multas administrativas del artículo 64.

Arts. 55 y 57

Qué implantar

Obligaciones por rol

Fabricante de sistema HCERepresentante autorizadoImportadorDistribuidorFabricante de producto sanitarioProveedor de IA de alto riesgoFabricante de aplicación de bienestarPrestador de asistencia sanitariaProfesional sanitarioTenedor de datos de saludUsuario de datos de saludOrganismo de acceso a datos de salud
Art. 25.1 Ciber parcial Los dos componentes armonizados obligatorios
Anexo II, punto 3.1 Ciber Autenticación de los profesionales sanitarios
Anexo II, puntos 3.2 y 3.3 Ciber Registro de cada acceso y herramientas para analizarlo
Anexo II, punto 3.4 Ciber Períodos de conservación y derechos de acceso diferenciados
Anexo II, sección 1 Ciber parcial Requisitos generales del producto
Anexo II, sección 2 Requisitos de interoperabilidad
Art. 37 y anexo III Ciber parcial Documentación técnica
Art. 39 y anexo IV Ciber parcial Declaración UE de conformidad
Art. 41 Ciber parcial Marcado CE
Art. 40 Ciber parcial Evaluación en el entorno digital de pruebas
Art. 30.2 y 30.3 Ciber parcial Procedimientos que sostienen la conformidad
Art. 38 Ficha informativa e instrucciones de uso
Art. 49 Registro en la base de datos de la UE
Arts. 31 a 35 Ciber parcial Deberes del representante, el importador y el distribuidor
Art. 44.7 Ciber Aviso de incidente grave
Arts. 30.1.i) a o), 44.1 y 45 Ciber parcial Medidas correctivas y cooperación con la vigilancia del mercado
Art. 27.1 Ciber parcial Conformidad del producto sanitario que declara interoperabilidad
Art. 27.2 Ciber parcial Conformidad del sistema de IA de alto riesgo que declara interoperabilidad
Art. 47 Ciber parcial Etiqueta de la aplicación de bienestar
Art. 48 Límites de la interoperabilidad de la aplicación de bienestar
Art. 13 Registro de los datos en el sistema HCE
Arts. 11 y 12 Ciber parcial Acceso de los profesionales con identidad electrónica reconocida
Art. 9 Ciber parcial Información a la persona sobre quién accedió a sus datos
Art. 73 Ciber Entorno de tratamiento seguro
Art. 61 Ciber parcial Deberes del usuario de datos de salud
Art. 54 Usos secundarios prohibidos
Art. 60 Puesta a disposición de los datos por el tenedor