Si desarrollas una app de salud o un sistema que gestiona historiales clínicos en Europa, el Espacio Europeo de Datos de Salud (EHDS) deja de ser una discusión regulatoria abstracta: es una especificación técnica con fechas. El Reglamento (UE) 2025/327 entró en vigor el 26 de marzo de 2025, empieza a aplicarse de forma general el 26 de marzo de 2027 y obliga, entre otras cosas, a que cualquier sistema que almacene o dé acceso a datos clínicos hable un formato común (el EEHRxF, basado en HL7 FHIR) y, en el caso de los sistemas de historia clínica electrónica (EHR), lleve marcado CE. Este artículo explica qué cambia, cuándo, y qué decisiones de arquitectura conviene tomar ahora — y también cuándo el EHDS todavía no es tu prioridad.
Qué es el EHDS en una frase
El EHDS es el marco europeo que estandariza cómo se comparten los datos de salud, con dos usos bien diferenciados:
- Uso primario: que un paciente (y los profesionales que le atienden) puedan acceder, controlar y compartir su historial clínico entre países, a través de la infraestructura MyHealth@EU.
- Uso secundario: reutilizar datos de salud de forma segura para investigación, innovación y políticas públicas, a través de HealthData@EU y los organismos de acceso a datos de salud, que conceden permisos para fines concretos.
La distinción importa para el diseño: el uso primario condiciona tu interoperabilidad y tu UX de consentimiento; el uso secundario introduce derechos de opt-out del paciente y un circuito de permisos que no controlas tú, sino un organismo nacional.
El corazón técnico: EEHRxF sobre FHIR
La pieza que afecta directamente a quien escribe código es el European Electronic Health Record Exchange Format (EEHRxF): un formato estandarizado y legible por máquina para intercambiar datos clínicos entre sistemas, dispositivos y proveedores. Se apoya en HL7 FHIR y en perfiles europeos ya conocidos por quien haya trabajado con interoperabilidad sanitaria.
La obligación es contundente: cualquier sistema diseñado para almacenar, intermediar o dar acceso a datos personales de salud debe permitir recibir y exponer esos datos en EEHRxF. En la práctica, si tu backend guarda datos clínicos en un modelo propio, vas a necesitar una capa de mapeo hacia recursos FHIR (Patient, MedicationRequest, Observation, DiagnosticReport, ImagingStudy…) y las validaciones asociadas.
Categorías prioritarias y calendario
El despliegue es por fases y por categorías de datos. Estas son las fechas de referencia:
| Hito | Fecha | Qué implica |
|---|---|---|
| Entrada en vigor | 26 mar 2025 | Arranca el reloj de los plazos |
| Aplicación general | 26 mar 2027 | Se publican especificaciones técnicas y arranca el grueso del reglamento |
| Grupo 1 operativo | ~mar 2029 | Resumen del paciente, receta y dispensación electrónicas; marcado CE de sistemas EHR |
| Grupo 2 operativo | ~mar 2031 | Imágenes médicas e informes, resultados de laboratorio, informes de alta |
La lectura estratégica: 2026 no es el año del cumplimiento, es el año de la preparación. Las categorías de mayor esfuerzo de datos (imagen, laboratorio) tienen margen hasta 2031, pero el resumen del paciente y la e-prescripción llegan en 2029, y el marcado CE de los sistemas EHR no es algo que se improvise en el último trimestre.
¿A quién le aplica? (y a quién no de la misma forma)
No todo el software de salud entra en el mismo cajón. Conviene clasificarse antes de asumir obligaciones que no te tocan:
- Sistemas EHR (historia clínica electrónica): son el objetivo central. Deben cumplir requisitos esenciales de dos componentes armonizados — interoperabilidad y registro (logging) — pasar tests automatizados, preparar documentación técnica, emitir una declaración UE de conformidad, afijar el marcado CE y registrarse en la base de datos designada. Es un marco de conformidad pre y post-mercado, más cercano al mundo del producto sanitario que al de una app de consumo.
- Aplicaciones de bienestar (wellness apps) que declaran interoperar con sistemas EHR: se enfrentan a un esquema de etiquetado voluntario. No es obligatorio, pero si afirmas que interoperas, esa afirmación pasa a tener consecuencias legales. Es decir: puedes elegir no jugar, pero no puedes prometer interoperabilidad y no cumplirla.
- Dispositivos y apps ya reguladas como producto sanitario (MDR): el EHDS se suma a lo que ya tienes; no lo sustituye.
Qué hacer en 2026 (checklist técnico, sin humo)
Si el EHDS te afecta, estas son las decisiones que rinden ahora y no dentro de dos años:
- Clasifícate primero. ¿Eres un sistema EHR, una wellness app que interopera, o ninguno de los dos? La respuesta cambia radicalmente el esfuerzo. Mucha ansiedad regulatoria se disuelve con esta pregunta.
- Aísla el modelo de datos clínicos. Si hoy tienes entidades de salud mezcladas con lógica de negocio, sepáralas. Una capa de dominio limpia hace que mapear a FHIR sea un adaptador, no una reescritura.
- Diseña la interoperabilidad como una API, no como un export. El EEHRxF es intercambio bidireccional. Piensa en endpoints FHIR bien perfilados desde el principio (aquí aplican los mismos principios de diseño de APIs que en cualquier backend serio).
- Trata el logging como requisito, no como nice to have. El componente de registro es obligatorio y auditable. La observabilidad deja de ser opcional cuando un regulador puede pedirte la traza de quién accedió a qué.
- Modela el consentimiento y el opt-out desde el dominio. El derecho del paciente a restringir accesos y a salir del uso secundario no es una casilla de UI: es estado que atraviesa tu backend.
Cuándo el EHDS NO es tu prioridad (todavía)
Seamos honestos: no todo equipo debe parar su roadmap por esto en 2026.
- Si construyes una app de bienestar sin ninguna intención de interoperar con sistemas clínicos, el etiquetado es voluntario y probablemente no es tu batalla de este año.
- Si operas exclusivamente fuera de la UE, el reglamento no te obliga (aunque MyHealth@EU y los estándares FHIR marcarán tendencia global de todos modos).
- Si eres una startup pre-producto validando encaje, invertir en conformidad EHDS antes de tener tracción es optimización prematura. Primero valida; la arquitectura correcta te permitirá cumplir después sin reescribir.
La regla práctica: prepara el terreno (dominio limpio, FHIR como adaptador) pero no sobre-inviertas en certificación hasta que tu categoría y tu mercado lo exijan.
Conclusión
El EHDS convierte la interoperabilidad sanitaria en Europa de aspiración a obligación con fechas: aplicación general en 2027, primeras categorías y marcado CE de sistemas EHR hacia 2029, resto hacia 2031. Para la mayoría de equipos, la jugada de 2026 no es certificarse, sino diseñar para poder certificarse: un modelo de datos clínicos aislado, FHIR como capa de intercambio y logging auditable. Quien lo trate como un problema de arquitectura ahora se ahorrará tratarlo como una crisis de última hora en 2028.
Es exactamente el mismo patrón que vimos con la regulación fintech (DORA, PSD3, AI Act): el cumplimiento bien diseñado es una decisión técnica, no un parche legal.
En Dribba llevamos desde 2011 construyendo apps con equipo senior in-house (Flutter y backend en Go), y trabajamos el cumplimiento como parte del diseño, no como un añadido. Si estás evaluando qué implica el EHDS para tu producto de salud, hablemos.
