El Espacio Europeo de Datos Sanitarios, conocido como EHDS por sus siglas en inglés, está transformando el contexto en el que hospitales y organizaciones sanitarias gestionarán e intercambiarán información electrónica.
Las principales fases de aplicación se concentran en 2029 y 2031. Pero los cambios necesarios para preparar una organización sanitaria no empiezan cuando llega una fecha regulatoria. Empiezan mucho antes, cuando el hospital revisa cómo funcionan sus sistemas, qué información puede intercambiar, quién controla los accesos y qué dependencias mantiene con sus proveedores tecnológicos.
El reto no consiste necesariamente en sustituir el HIS/EHR. Consiste en comprender qué capacidades de interoperabilidad, seguridad y gobernanza necesitará la organización y cómo desarrollarlas sin interrumpir los procesos actuales.
Prepararse para EHDS no debería significar reconstruir el hospital digital. Debería significar conocer mejor su arquitectura y reducir las dependencias que dificultan el intercambio seguro de información.
Este artículo continúa nuestra guía sobre interoperabilidad sanitaria entre HIS/EHR, Microsoft y procesos operativos, ahora con foco en la preparación técnica para el EHDS.
Qué cambia realmente con el EHDS
El Reglamento (UE) 2025/327 establece un marco europeo para mejorar el acceso, intercambio y utilización de determinados datos sanitarios electrónicos. Sus objetivos principales incluyen mejorar el acceso de las personas a sus datos de salud, facilitar el intercambio de información para la asistencia sanitaria y establecer condiciones para la reutilización controlada de determinados datos con fines como investigación e innovación. También introduce un marco armonizado para determinados sistemas de historia clínica electrónica.
Sin embargo, estos objetivos no deben confundirse con una obligación inmediata de migrar todos los sistemas hospitalarios a una nueva plataforma. La aplicación del Reglamento es progresiva. Parte de la preparación corresponde a autoridades nacionales, organismos de acceso a datos y fabricantes de sistemas. Otra parte afecta, según las circunstancias, a las organizaciones sanitarias que producen, gestionan o intercambian información electrónica.
La primera tarea de un hospital debería ser identificar qué aspectos del marco son relevantes para su situación. No iniciar automáticamente un proyecto de sustitución tecnológica.
Las fechas que debe conocer un hospital
El Reglamento EHDS entró en vigor el 26 de marzo de 2025. Sin embargo, su aplicación se desarrolla en distintas fases.
26 de marzo de 2027
Comienzan a aplicarse disposiciones generales relevantes del marco y se alcanza un hito importante para la organización institucional y varios actos de ejecución.
26 de marzo de 2029
Comienza una fase fundamental para el intercambio de las primeras categorías prioritarias de información sanitaria electrónica, incluidas historias clínicas resumidas, recetas electrónicas y dispensaciones electrónicas. También comienza la aplicación de numerosas disposiciones relacionadas con el uso secundario de datos.
26 de marzo de 2031
La siguiente fase incorpora categorías como imágenes médicas, resultados de pruebas e informes de alta hospitalaria.
Estas fechas representan hitos regulatorios y operativos diferentes. Las obligaciones concretas dependen de la actividad, del tipo de sistema y de las disposiciones aplicables. No deben interpretarse como una única fecha de cumplimiento idéntica para todas las organizaciones.
Octubre de 2026: la implementación empieza a concretarse
Durante septiembre de 2026, la Comisión Europea adoptó tres reglamentos de ejecución especialmente relevantes para la arquitectura del EHDS.
El primero, Reglamento de Ejecución (UE) 2026/2083, desarrolla aspectos del funcionamiento de MyHealth@EU, la infraestructura europea destinada a facilitar el intercambio transfronterizo de información sanitaria.
El segundo, Reglamento de Ejecución (UE) 2026/2099, aborda mecanismos interoperables de identificación y autenticación de personas, profesionales y prestadores sanitarios.
El tercero, Reglamento de Ejecución (UE) 2026/2098, establece elementos mínimos de metadatos para describir conjuntos de datos destinados al uso secundario.
Los reglamentos entraron en vigor en octubre de 2026, pero sus fechas de aplicación son diferentes. El Reglamento 2026/2083 se aplica desde el 26 de marzo de 2027. El Reglamento 2026/2099 también se aplica, con carácter general, desde esa fecha, aunque sus artículos 3.3 y 5.2 se aplican desde el 26 de marzo de 2029. El Reglamento 2026/2098 se aplica desde el 26 de marzo de 2029.
Esto significa que el marco técnico está adquiriendo mayor definición, aunque no todas sus obligaciones son exigibles inmediatamente a los hospitales. Para una organización sanitaria, la consecuencia práctica es clara: Ya existe suficiente dirección regulatoria para comenzar una evaluación arquitectónica, pero las decisiones de implementación deben considerar las especificaciones y obligaciones efectivamente aplicables.
El primer paso: conocer los sistemas que ya existen
Un hospital puede disponer de varios sistemas clínicos y administrativos que evolucionaron durante años.
- HIS.
- EHR.
- Agenda asistencial.
- Sistemas de laboratorio.
- Plataformas de imagen médica.
- Aplicaciones de comunicación con pacientes.
- Herramientas de analítica.
- Soluciones específicas utilizadas por determinados servicios.
En ocasiones, estos sistemas intercambian información mediante APIs modernas. En otros casos utilizan mecanismos de integración más antiguos, mensajes, servicios especializados o procesos manuales. Antes de planificar nuevas capacidades, conviene construir un inventario técnico y funcional.
- ¿Qué sistema es responsable de cada categoría de información?
- ¿Qué interfaces están disponibles?
- ¿Qué datos pueden consultarse o actualizarse?
- ¿Qué mecanismos de autenticación se utilizan?
- ¿Qué integraciones dependen de un proveedor?
- ¿Qué procesos requieren intervención manual?
Este inventario no necesita convertirse en un proyecto de gran escala. Puede comenzar por los sistemas y procesos más relevantes. Su valor reside en proporcionar una visión compartida entre tecnología, responsables operativos, seguridad y dirección.
Interoperabilidad no significa centralizar todos los datos
Una respuesta habitual a los problemas de integración consiste en proponer una gran plataforma central donde se reúna toda la información. En determinados escenarios pueden ser necesarias plataformas de intercambio o repositorios específicos. Pero no debería asumirse que todos los datos clínicos necesitan duplicarse en una nueva infraestructura. El sistema responsable de la información debe continuar ejerciendo esa función. Una integración puede permitir que otros componentes consulten datos autorizados o ejecuten acciones controladas sin convertirse en una fuente paralela de información.
Por ejemplo, un proceso de gestión de citas puede utilizar información de disponibilidad del sistema hospitalario. Si el paciente confirma una cancelación, la actualización debe gestionarse mediante el sistema autorizado para registrar ese estado. La capa de integración ayuda a coordinar la interacción. No necesita sustituir el sistema de agenda. Este principio también resulta relevante para la futura evolución de la interoperabilidad europea. Una arquitectura preparada para intercambiar información no tiene por qué ser una arquitectura que almacene toda la información en el mismo lugar.
Los estándares ayudan, pero no eliminan las decisiones de integración
HL7 FHIR es uno de los estándares utilizados para representar e intercambiar información sanitaria electrónica. Puede facilitar la integración entre sistemas cuando existen implementaciones compatibles. Sin embargo, utilizar FHIR no garantiza automáticamente que una solución satisfaga todos los requisitos del EHDS. Pueden existir diferencias entre versiones, perfiles, terminologías y capacidades soportadas. Además, el marco europeo contempla especificaciones y formatos de intercambio que deben considerarse según el contexto.
Por eso, antes de incorporar un nuevo componente tecnológico, el hospital debería comprobar qué interfaces ofrece su proveedor HIS/EHR, cuáles están soportadas y cómo se relacionan con los requisitos que correspondan. No es necesario desplegar un servidor FHIR para justificar cualquier proyecto de interoperabilidad. La arquitectura debe responder a un caso de uso real.
Identidad y acceso: un componente central
El intercambio de información sanitaria requiere saber quién solicita una acción y qué información está autorizado a utilizar. Esta cuestión se vuelve especialmente relevante cuando intervienen diferentes organizaciones o países. Un hospital puede gestionar la identidad de sus profesionales mediante sistemas corporativos. Los pacientes pueden acceder utilizando mecanismos diferentes. Y los intercambios transfronterizos pueden requerir mecanismos de identificación y atributos reconocidos entre distintas autoridades. Estos contextos no son equivalentes.
Una solución interna de identidad para empleados no constituye automáticamente un mecanismo de identificación sanitaria transfronteriza. Es necesario distinguir las identidades corporativas, las identidades de pacientes y los mecanismos específicos de confianza utilizados para intercambiar información. En la arquitectura interna, plataformas como Microsoft Entra pueden apoyar determinadas necesidades de autenticación y control de acceso. Pero su incorporación debe responder al uso previsto y no confundirse con el cumplimiento completo de los mecanismos establecidos para MyHealth@EU.
Seguridad y trazabilidad desde el diseño
Cada integración introduce responsabilidades sobre protección de datos. Esto exige determinar qué información necesita cada proceso, cómo se autoriza su utilización y qué actividad debe registrarse. Una aplicación administrativa no debería recibir acceso a información clínica que no necesita. Un sistema de analítica puede trabajar con información agregada cuando el objetivo no requiere identificar a pacientes. Una integración de comunicación debería limitarse a los datos necesarios para ejecutar su función. También es importante registrar las acciones relevantes y poder investigar errores o accesos inadecuados.
La trazabilidad no debe limitarse a disponer de logs técnicos. Debe permitir comprender qué ocurrió dentro del proceso y qué sistemas participaron. La protección de datos, el RGPD y los requisitos de seguridad aplicables continúan siendo relevantes durante la transición hacia EHDS.
Uso primario y secundario: dos necesidades diferentes
El EHDS distingue entre diferentes finalidades de utilización de datos. El uso primario está relacionado con la prestación de asistencia sanitaria. El uso secundario contempla determinados tratamientos posteriores para fines autorizados, como investigación, innovación, salud pública y formulación de políticas. Esta distinción es importante para el diseño tecnológico. Un sistema que ayuda a un profesional sanitario a consultar información durante la atención no tiene necesariamente las mismas necesidades que un proceso destinado a describir conjuntos de datos para investigación.
Los permisos, mecanismos de acceso, finalidades y salvaguardias pueden ser diferentes. El Reglamento de Ejecución (UE) 2026/2098 introduce requisitos de metadatos para determinadas descripciones de conjuntos de datos destinados al uso secundario. Pero describir un conjunto de datos no significa conceder acceso indiscriminado a su contenido. El acceso y la reutilización están sujetos a los mecanismos y condiciones aplicables. Para un hospital, la preparación puede comenzar por conocer qué conjuntos de datos gestiona, qué calidad tienen, quién es responsable y cómo se documentan.
Microsoft puede ayudar sin convertirse en otro sistema clínico
En organizaciones que ya utilizan Microsoft 365 y Azure, parte de la arquitectura de integración y gobierno puede apoyarse en tecnologías existentes.
- Azure puede proporcionar componentes de integración, APIs, procesamiento y servicios de datos.
- Power Platform puede ayudar a coordinar determinados procesos operativos.
- Power BI puede ofrecer visibilidad sobre resultados y calidad de los procesos.
- Microsoft Entra puede participar en la gestión de identidades y permisos dentro de los contextos para los que esté diseñado.
- Microsoft Purview puede apoyar determinadas necesidades de gobierno y protección de información, según las capacidades disponibles.
Sin embargo, ninguna de estas herramientas debería presentarse como una solución universal de cumplimiento EHDS. La elección depende de los sistemas clínicos, las interfaces disponibles, las obligaciones aplicables y la arquitectura del hospital. El enfoque adecuado no consiste en trasladar todos los datos a Microsoft. Consiste en utilizar los componentes necesarios para resolver problemas concretos sin perder control sobre la información y los sistemas existentes.
Empezar con una evaluación de preparación, no con una migración
Una organización sanitaria puede avanzar significativamente sin iniciar inmediatamente un gran programa tecnológico. Una primera evaluación puede centrarse en cuatro áreas.
Arquitectura existente
Identificar sistemas, interfaces, integraciones y dependencias de proveedores.
Datos e interoperabilidad
Revisar formatos, calidad de información, disponibilidad de interfaces y posibles limitaciones de intercambio.
Identidad y seguridad
Comprender los mecanismos actuales de acceso, las responsabilidades sobre datos y las capacidades de trazabilidad.
Gobernanza y operación
Definir responsables, procedimientos de cambio, documentación y prioridades de evolución.
El resultado debería ser un mapa de preparación y un conjunto de acciones priorizadas. Algunas mejoras pueden ser sencillas. Otras pueden requerir conversaciones con proveedores o proyectos de integración más amplios. La prioridad no debería ser implementar todas las capacidades futuras al mismo tiempo. Debería ser reducir las dependencias que podrían dificultar la evolución.
Cómo medir la preparación
La preparación para EHDS también puede evaluarse mediante indicadores.
- Porcentaje de sistemas críticos con interfaces documentadas.
- La cantidad de integraciones cuya responsabilidad está claramente definida.
- La existencia de un inventario de fuentes de datos.
- La disponibilidad de registros de acceso.
- Los procesos que todavía dependen de exportaciones manuales.
- La calidad de los datos necesarios para un intercambio concreto.
Estas métricas no equivalen a una certificación ni garantizan el cumplimiento regulatorio. Pero ayudan a comprender si la organización está reduciendo incertidumbre. También permiten justificar inversiones de modernización que aporten valor antes de las futuras fechas de aplicación.
Un hospital no necesita esperar hasta 2029 para beneficiarse de integraciones más fiables, procesos mejor documentados o mayor control de sus datos.
Cómo lo plantea Cleverina
Cleverina aborda la transformación digital sanitaria desde problemas operativos concretos y la arquitectura existente. Nuestros tres pilares actuales —gestión inteligente de citas, inteligencia de la experiencia del paciente y documentación clínica asistida por IA— pueden requerir diferentes niveles de integración con los sistemas del hospital. La preparación para EHDS proporciona un contexto adicional para evaluar estas integraciones. Nuestro enfoque comienza por comprender los sistemas existentes, identificar dependencias, establecer controles de seguridad y definir qué resultados necesitan medirse.
Cuando es apropiado, utilizamos tecnologías Microsoft para integrar procesos, reforzar controles y ofrecer visibilidad operativa. No proponemos sustituir automáticamente el HIS/EHR ni crear un repositorio paralelo de información clínica. El objetivo es ayudar a las organizaciones sanitarias a evolucionar sus procesos y capacidades de integración con una arquitectura gobernada, sostenible y preparada para adaptarse a requisitos futuros.
El mejor momento para comprender las limitaciones de interoperabilidad de un hospital no es cuando llega una obligación regulatoria. Es cuando todavía existe tiempo para corregirlas de forma controlada.
Fuentes y contexto normativo
- Reglamento (UE) 2025/327: marco del EHDS y calendario de aplicación, artículo 105.
- Comisión Europea: fases de implantación del Espacio Europeo de Datos Sanitarios.
- Reglamento de Ejecución (UE) 2026/2083: MyHealth@EU.
- Reglamento de Ejecución (UE) 2026/2099: identificación y autenticación transfronterizas.
- Reglamento de Ejecución (UE) 2026/2098: metadatos para descripciones de conjuntos de datos.
Información normativa revisada el 24 de octubre de 2026. Este artículo ofrece orientación técnica y no sustituye una evaluación jurídica de las obligaciones aplicables a cada organización.