Migración de sistemas legacy en hospitales españoles: de HP- - Blog

Introducción

La migración de sistemas legacy en hospitales de España es, posiblemente, el desafío tecnológico más complejo que afronta el Sistema Nacional de Salud (SNS) en esta década. El ecosistema de Sistemas de Información Hospitalaria (HIS) español está dominado por un puñado de proveedores que gestionan la información clínica de millones de ciudadanos: Oracle Health (anteriormente Cerner) con Millennium atiende al 30 % de la población española y opera en varios hospitales reconocidos con nivel HIMSS 6 y 7, CGM Clinical mantiene Selene operativo en 65 hospitales públicos, Dedalus gestiona más de 17 millones de historias clínicas y está presente en el 60 % de los hospitales públicos españoles en el ámbito de anatomía patológica, e InterSystems con HealthShare y TrakCare completa el panorama de los grandes proveedores.

Sin embargo, bajo esta capa de sistemas comerciales consolidados late un sustrato de tecnologías heredadas que acumula décadas de servicio: instalaciones de HP-HIS que se remontan a los años noventa, módulos SAP IS-H implantados en la primera década de los 2000, y decenas de desarrollos propios realizados por los servicios de informática de los hospitales y servicios autonómicos de salud, muchos de ellos escritos en lenguajes y arquitecturas que hoy resultan difíciles de mantener y evolucionar.

El horizonte regulatorio europeo añade urgencia a esta situación. El Espacio Europeo de Datos de Salud (EHDS) exige interoperabilidad basada en FHIR para 2029 (Patient Summaries) y 2031 (imágenes y laboratorio), lo que obliga a replantear no solo los interfaces sino las propias plataformas de persistencia clínica. La migración sistemas legacy hospitales España no es ya una opción deseable sino una necesidad estratégica con calendario definido.

En este artículo analizamos las tres estrategias principales de migración adoptadas en España, las herramientas ETL y de integración que hacen posible la transición, los casos reales más relevantes del panorama nacional, y los retos críticos que todo equipo de informática hospitalaria debe anticipar. Si lideras o participas en proyectos de transformación digital sanitaria, este es el mapa del terreno que vas a recorrer.

El mapa de proveedores HIS en España: quién gestiona qué

Comprender la migración sistemas legacy hospitales España requiere primero cartografiar el ecosistema actual. A diferencia de otros países europeos con sistemas sanitarios más centralizados, el modelo autonómico español ha generado un paisaje de proveedores heterogéneo donde cada comunidad autónoma ha tomado decisiones tecnológicas independientes, muchas veces divergentes.

Oracle Health (Cerner) Millennium

Oracle Health, tras la adquisición de Cerner por Oracle en 2022, opera Millennium como su plataforma HIS insignia en España. El sistema atiende al 30 % de la población española, con implantaciones destacadas en hospitales de comunidades como Baleares, Valencia y Madrid. Varios de estos centros han alcanzado niveles HIMSS EMRAM 6 y 7, el reconocimiento internacional más exigente en adopción de historia clínica electrónica.

Millennium es un sistema monolítico pero maduro, con módulos que cubren desde la gestión de pacientes y órdenes clínicas hasta farmacia, laboratorio y cuidados intensivos. Su migración o sustitución plantea desafíos enormes por la profundidad de la integración y la dependencia funcional que generan los hospitales tras años de uso. Oracle Health ha emprendido su propia transición hacia una arquitectura cloud-native con Oracle Health Clinical Platform, pero los plazos de migración para los clientes existentes se miden en años, no en meses.

CGM Clinical — Selene

CompuGroup Medical (CGM) mantiene Selene como su producto HIS insignia en España, operativo en 65 hospitales públicos. Selene tiene su origen en el desarrollo español (anteriormente NovaLab/Indra) y ha sido el HIS de referencia en comunidades como Andalucía, Canarias y Castilla y León. La transición hacia CGM Clinical, la plataforma unificada de CompuGroup, implica una modernización progresiva de la arquitectura, pero el ritmo de migración varía significativamente entre comunidades.

El principal reto con Selene es la heterogeneidad de versiones desplegadas: no todos los hospitales operan la misma versión, las personalizaciones locales son extensas, y la documentación de interfaces no siempre está actualizada. Esto convierte cada migración en un proyecto de ingeniería inversa parcial antes de poder planificar la transición.

Dedalus

Dedalus, el mayor proveedor europeo de software sanitario tras la adquisición de la división de healthcare IT de DXC Technology (ex-HP Enterprise), gestiona más de 17 millones de historias clínicas en España y está presente en el 60 % de los hospitales públicos en el ámbito de anatomía patológica. Su portfolio incluye soluciones para laboratorio (LIMS), anatomía patológica, radiología (RIS/PACS) y HIS.

La presencia de Dedalus en España tiene raíces profundas en el legado de HP-HIS, uno de los sistemas hospitalarios más extendidos en la sanidad pública española durante las décadas de 1990 y 2000. Muchos hospitales que hoy operan soluciones Dedalus están ejecutando versiones evolucionadas de aquella base tecnológica original, con capas de modernización sucesivas pero con una arquitectura subyacente que conserva decisiones de diseño de hace treinta años.

InterSystems — HealthShare / TrakCare

InterSystems tiene una presencia significativa en el sector sanitario español a través de HealthShare (plataforma de integración e interoperabilidad) y TrakCare (HIS). Su tecnología IRIS for Health, con capacidades nativas de FHIR y transformación de datos, la posiciona como un actor clave en los proyectos de interoperabilidad y migración, tanto como proveedor de HIS como de infraestructura de integración.

Tres estrategias de migración: incremental, visor unificado y big bang

La experiencia acumulada en España y a nivel internacional identifica tres estrategias fundamentales para abordar la migración de sistemas legacy hospitalarios. Cada una tiene implicaciones diferentes en coste, riesgo, duración y capacidad de innovación.

Estrategia 1: Migración incremental por fases

La migración incremental es el modelo predominante en España y consiste en sustituir gradualmente los módulos del sistema legacy por componentes modernos, manteniendo el sistema antiguo operativo durante la transición y construyendo capas de integración que permiten la coexistencia.

El ejemplo más paradigmático es la evolución de HC3 hacia HES en Cataluña. El proyecto HC3 (Història Clínica Compartida de Catalunya), operativo desde 2008, proporcionaba una capa de acceso unificado a la información clínica de los diferentes proveedores sanitarios catalanes. La evolución hacia HES (Història Electrònica de Salut), basada en openEHR como modelo de persistencia clínica, representa una migración incremental donde los arquetipos openEHR van sustituyendo progresivamente los modelos de datos propietarios, sin interrumpir el acceso a la información histórica.

El modelo openEHR ofrece una ventaja arquitectónica fundamental para la migración incremental: la separación entre el modelo de conocimiento clínico (arquetipos y plantillas) y el modelo de datos técnico permite evolucionar uno sin afectar al otro. Esto significa que nuevos flujos clínicos pueden modelarse con arquetipos openEHR modernos mientras los datos históricos se mantienen accesibles a través de capas de compatibilidad.

La empresa española Veratech for Health, con más de 20 años de experiencia en openEHR en España, ha sido un actor clave en proyectos de migración incremental, proporcionando la experiencia en modelado clínico y las herramientas de mapeo necesarias para la transición. Su trabajo incluye la implementación de repositorios openEHR y el desarrollo de herramientas de mapeo como FHIRconnect, que permite la interoperabilidad bidireccional entre openEHR y FHIR con 24 arquetipos mapeados a 15 perfiles FHIR.

Estrategia 2: Visor unificado (sin sustitución)

La estrategia de visor unificado consiste en construir una capa de acceso que integra y presenta de forma coherente la información dispersa en múltiples sistemas heterogéneos, sin sustituir ninguno de ellos. Es una estrategia pragmática que prioriza la visibilidad sobre la modernización.

El ejemplo de referencia en España es el modelo HORUS del Servicio Madrileño de Salud (SERMAS). HORUS actúa como la Historia Clínica Electrónica Integrada de la Comunidad de Madrid, proporcionando a los profesionales sanitarios una vista unificada de la información del paciente independientemente del sistema de origen: atención primaria (AP-Madrid), atención hospitalaria (múltiples HIS de diferentes proveedores), urgencias, salud mental y otros ámbitos asistenciales.

HORUS no sustituye los sistemas departamentales: Oracle/Cerner Millennium, Selene, los sistemas de laboratorio, los RIS/PACS y los desarrollos propios siguen operando de forma autónoma. Lo que HORUS proporciona es una capa de integración que recoge datos de todos estos sistemas mediante mensajería HL7v2 y documentos CDA, los indexa y los presenta al clínico en una interfaz única. Esta estrategia tiene ventajas claras en entornos con alta heterogeneidad tecnológica: no requiere migrar datos, no interrumpe los sistemas existentes y puede desplegarse de forma incremental.

La limitación principal del modelo visor es que no resuelve los problemas estructurales del legacy: los datos siguen almacenados en formatos propietarios, la calidad de los datos depende de cada sistema de origen, y la capacidad analítica está limitada por la capa de integración. A largo plazo, el visor unificado suele ser un paso intermedio hacia una migración más profunda.

Estrategia 3: Big bang (greenfield)

La migración big bang consiste en implantar un nuevo sistema HIS completo, sustituyendo de una sola vez toda la infraestructura legacy. Es la estrategia de mayor riesgo pero también la que ofrece mayor capacidad de innovación, ya que permite diseñar la arquitectura desde cero sin las restricciones del legacy.

El caso de referencia en España es Marina Salud en Denia (Alicante), que implementó Oracle/Cerner Millennium como sistema integral en un modelo greenfield, alcanzando el nivel HIMSS EMRAM 7, el máximo reconocimiento posible en adopción de historia clínica electrónica. La clave del éxito en Denia fue la convergencia de varios factores favorables: un modelo de concesión administrativa que otorgaba autonomía de gestión, un hospital de tamaño manejable, y la posibilidad de diseñar los flujos de trabajo clínicos desde cero sin la inercia de sistemas preexistentes.

La migración big bang es raramente viable en hospitales grandes con sistemas legacy profundamente integrados. El riesgo de interrupción asistencial durante la transición, la curva de aprendizaje masiva para los profesionales y la complejidad de migrar décadas de datos históricos hacen que esta estrategia se reserve para implantaciones nuevas o para centros donde la obsolescencia del sistema legacy no deja otra opción.

Herramientas ETL y de integración: el kit del ingeniero de migración

Mirth Connect: el estándar de facto

Mirth Connect (ahora parte de NextGen Healthcare) es el motor de integración más extendido en los hospitales españoles para la gestión de mensajería HL7v2, y se ha convertido en una pieza fundamental de los proyectos de migración. Su arquitectura basada en canales permite definir flujos de transformación de datos entre sistemas heterogéneos, soportando de forma nativa HL7v2, FHIR R4, DICOM, XML, CSV y bases de datos relacionales.

En el contexto de migración, Mirth Connect actúa como puente bidireccional: recibe mensajes HL7v2 del sistema legacy, los transforma en recursos FHIR y los enruta al nuevo sistema, y viceversa. Esta capacidad de traducción simultánea es esencial durante la fase de coexistencia, cuando ambos sistemas (legacy y nuevo) deben operar en paralelo.

InterSystems Health Connect / IRIS for Health

InterSystems ofrece Health Connect e IRIS for Health como plataformas de integración de grado empresarial, con capacidades superiores a Mirth Connect en rendimiento, escalabilidad y gestión transaccional. Su presencia establecida en hospitales españoles y su soporte nativo para FHIR, HL7v2 y transformaciones complejas la convierten en una opción natural para proyectos de migración a gran escala.

HAPI FHIR Server

HAPI FHIR (Java) es el servidor FHIR open source de referencia y se utiliza frecuentemente como destino en las migraciones: los datos transformados desde el legacy se persisten en un repositorio FHIR basado en HAPI, que actúa como la nueva fuente de verdad para los sistemas modernos. Su soporte para FHIR R4 y R5, validación de perfiles y operaciones bulk lo hacen idóneo para proyectos institucionales.

openEHR + FHIRconnect

Para las organizaciones que han adoptado openEHR como modelo de persistencia clínica, FHIRconnect proporciona mapeos bidireccionales entre arquetipos openEHR y perfiles FHIR. Actualmente dispone de 24 arquetipos mapeados a 15 perfiles FHIR, cubriendo los casos de uso más frecuentes: signos vitales, diagnósticos, medicación, alergias y resultados de laboratorio. Esta herramienta permite exponer datos almacenados en repositorios openEHR como recursos FHIR estándar, facilitando la interoperabilidad con sistemas que consumen FHIR sin necesidad de modificar el modelo de persistencia.

Pipelines ETL hacia OMOP CDM: uso secundario de datos

Un componente cada vez más relevante de los proyectos de migración es la construcción de pipelines ETL hacia OMOP CDM (Observational Medical Outcomes Partnership Common Data Model) para habilitar el uso secundario de datos clínicos: investigación observacional, farmacovigilancia, estudios de efectividad comparada y analítica de salud poblacional.

En España, dos proyectos destacan especialmente:

Hospital La Fe de Valencia: Ha implementado un repositorio OMOP CDM alimentado mediante pipelines ETL desde sus sistemas clínicos, participando activamente en la red OHDSI (Observational Health Data Sciences and Informatics) y utilizando herramientas como ATLAS (para definición de cohortes y estudios) y Achilles (para caracterización y calidad de datos).
Hospital 12 de Octubre de Madrid: El proyecto INFOBANCO ha construido una plataforma unificada que integra openEHR, FHIR y OMOP CDM, creando un ecosistema donde los datos clínicos se persisten en openEHR, se exponen vía FHIR para interoperabilidad y se transforman a OMOP para investigación. Este modelo de triple estándar es posiblemente la arquitectura de referencia más avanzada en España para la gestión integral de datos clínicos.

Las herramientas ETL utilizadas en estos proyectos incluyen Apache Kafka para streaming de datos en tiempo real, Talend e Informatica para transformaciones batch, y los vocabularios estandarizados de OHDSI para la normalización semántica. El despliegue de los servicios de integración se realiza típicamente sobre Docker/Kubernetes, facilitando la escalabilidad y la reproducibilidad del entorno.

Normalización semántica: la clave invisible

Ninguna migración tiene éxito sin abordar la normalización semántica de los datos. Los sistemas legacy españoles utilizan una mezcla de codificaciones: CIE-9-MC (aún presente en datos históricos), CIE-10-ES (obligatorio desde 2016), SNOMED CT (con despliegue desigual entre CCAA), LOINC (para laboratorio, con adopción creciente) y numerosos catálogos locales sin estandarizar.

El mapeo entre estas codificaciones y los vocabularios estándar (SNOMED CT, LOINC, CIE-10-ES) es un trabajo intensivo que requiere conocimiento clínico profundo y herramientas especializadas. Las herramientas de OHDSI, particularmente Usagi para el mapeo semiautomático de vocabularios, aceleran este proceso pero no lo automatizan completamente: la validación clínica humana sigue siendo imprescindible.

Retos críticos de la migración en el contexto español

Heterogeneidad extrema entre comunidades autónomas

El modelo autonómico español genera un ecosistema donde 17 comunidades autónomas (más Ceuta y Melilla) han tomado decisiones tecnológicas independientes durante décadas. No existe un HIS nacional ni una arquitectura de referencia común. Cada servicio de salud autonómico opera con su propia combinación de proveedores, versiones, personalizaciones y modelos de datos. Esta heterogeneidad multiplica la complejidad de cualquier proyecto de migración que aspire a tener impacto a escala nacional.

Datos no estructurados: el gran volumen oculto

Una proporción significativa de la información clínica en los hospitales españoles existe en formato no estructurado: informes de alta en texto libre, notas de evolución, informes de radiología dictados, documentos escaneados y PDFs de resultados externos. La migración de estos datos requiere tecnologías de NLP (Natural Language Processing) para extraer entidades clínicas y convertirlas en datos estructurados, un proceso que añade complejidad y costes significativos.

Codificación inconsistente

Los datos históricos presentan inconsistencias de codificación acumuladas durante años: diagnósticos codificados con diferentes versiones de CIE, procedimientos con nomenclaturas locales, medicamentos con nombres comerciales en lugar de principios activos, y laboratorio con unidades y rangos de referencia variables. Limpiar y normalizar estos datos es un prerequisito para cualquier migración que aspire a mantener la calidad clínica.

Continuidad asistencial durante la migración

El requisito más crítico de toda migración hospitalaria es garantizar la continuidad asistencial: en ningún momento del proceso puede perderse el acceso a la información clínica del paciente ni interrumpirse los flujos de trabajo asistenciales. Esto exige períodos de convivencia entre sistemas (dual running) con sincronización bidireccional, planes de contingencia detallados, y formación intensiva para los profesionales sanitarios que deben operar ambos sistemas simultáneamente.

Resistencia al cambio y formación

La dimensión humana de la migración es tan crítica como la técnica. Los profesionales sanitarios desarrollan flujos de trabajo profundamente arraigados en los sistemas que utilizan a diario, y el cambio genera resistencia, especialmente cuando se percibe como una imposición tecnológica sin beneficio clínico inmediato. Los planes de formación y gestión del cambio deben integrarse en el proyecto de migración desde la fase de planificación, no como un añadido posterior.

Conclusión

La migración sistemas legacy hospitales España es un proceso largo, complejo y costoso, pero ineludible. El horizonte regulatorio del EHDS (2029-2031), la obsolescencia progresiva de las plataformas legacy, la necesidad de habilitar el uso secundario de datos clínicos y la demanda de interoperabilidad real entre niveles asistenciales y comunidades autónomas convergen para hacer de la modernización de los HIS una prioridad estratégica del SNS.

Las tres estrategias analizadas (migración incremental, visor unificado y big bang) no son mutuamente excluyentes: muchas organizaciones combinan elementos de las tres en función de sus circunstancias. Lo que sí es común a todas es la necesidad de un stack de integración robusto (Mirth Connect, HAPI FHIR, openEHR, Kafka), una estrategia de normalización semántica rigurosa (SNOMED CT, CIE-10-ES, LOINC) y una gobernanza del proyecto que integre las dimensiones técnica, clínica, regulatoria y humana.

Los casos del Hospital La Fe, el Hospital 12 de Octubre con INFOBANCO, la evolución HC3-HES en Cataluña y el modelo HORUS en Madrid demuestran que la migración es viable y que España cuenta con equipos y experiencia para abordarla. El reto es escalar estas experiencias al conjunto del SNS en los plazos que marca Europa.

En Informática Médica acompañamos a hospitales y servicios de salud autonómicos en la planificación y ejecución de proyectos de migración desde sistemas legacy hacia plataformas FHIR-native y openEHR, con experiencia directa en el ecosistema de proveedores español y las herramientas de integración que hacen posible la transición sin comprometer la continuidad asistencial.

Referencias

HIMSS Analytics: EMRAM (Electronic Medical Record Adoption Model) Europe — himss.org/emram.
Oracle Health (Cerner): casos de éxito y soluciones en España — oracle.com/es/health.
Dedalus Spain: presencia y soluciones en el mercado español — dedalus.com/spain.
CGM Clinical: transición de Selene y portfolio de productos — cgm.com/es.
Veratech for Health: experiencia openEHR en España, más de 20 años — veratech.es.
OHDSI: OMOP CDM, ATLAS, Achilles y herramientas de analítica — ohdsi.org.
Proyecto INFOBANCO, Hospital 12 de Octubre (Madrid): plataforma unificada openEHR/FHIR/OMOP.
Fundació TIC Salut Social: proyectos de interoperabilidad en Cataluña — ticsalutsocial.cat.
SERMAS: plataforma HORUS — comunidad.madrid/servicios/salud.
NextGen Healthcare: Mirth Connect — nextgen.com/products-and-services/integration-engine.
InterSystems: IRIS for Health y Health Connect — intersystems.com.
FHIRconnect: mapeo bidireccional openEHR-FHIR — documentación técnica disponible en repositorios del proyecto.