Por qué el 60% de las implementaciones de HIS fracasan (y nadie lo admite)

El sector lleva décadas acumulando lecciones sobre proyectos de software hospitalario que no terminan bien. El problema no es la tecnología. Es lo que hay alrededor.

Hay una estadística incómoda que circula entre consultoras del sector sanitario pero que rara vez aparece en los comunicados de prensa: entre el 55% y el 70% de los proyectos de implantación de sistemas de información hospitalaria (HIS) no alcanzan sus objetivos en plazo, presupuesto o adopción real.

McKinsey publicó que los grandes proyectos TI superan su presupuesto en un promedio del 45% y acumulan retrasos de entre seis y doce meses. En hospitales, esos números tienen consecuencias que van más allá del balance contable: personal clínico que trabaja con dos sistemas en paralelo durante meses, datos migrados de forma incompleta que afectan a la continuidad asistencial, y una desconfianza instalada en los equipos que convierte la siguiente iniciativa digital en una batalla cultural antes de arrancar.

Lo que resulta llamativo no es el dato. Lo llamativo es que, conociendo este historial, nadie cambia de forma sustancial cómo se diseña, se contrata y se gestiona un proyecto de estas características.

¿Qué es un HIS y por qué su implementación es diferente a cualquier otro proyecto de software?

Un Hospital Information System (HIS), también llamado sistema de gestión hospitalaria o HMS, es la plataforma central que integra los procesos clínicos, administrativos y de gestión de un centro sanitario: admisión y alta de pacientes, historia clínica electrónica, gestión de consultas y quirófanos, farmacia, laboratorio, facturación e informes de gestión.

A diferencia de un ERP corporativo o un CRM, un HIS interviene directamente en la operativa clínica. No hay modo mantenimiento de seis horas un domingo. No hay margen para “ya lo ajustamos en producción”. Cuando el HIS falla, el hospital siente las consecuencias en tiempo real.

Eso convierte su implementación en uno de los proyectos tecnológicos más complejos que puede abordar cualquier organización, sanitaria o no.

El fracaso no está en el software: el problema real de la gestión del cambio hospitalaria

Cuando un proyecto HIS sale mal, el guión es predecible.

El proveedor culpa al hospital por no haber preparado el cambio organizacional. El hospital culpa al proveedor por haber prometido funcionalidades que no estaban disponibles o una integración que resultó más costosa de lo esperado. Los usuarios finales, médicos, enfermeros, personal de admisión, culpan a todos y desarrollan sus propios workarounds para seguir trabajando.

La narrativa dominante señala al software. Versión desactualizada, módulos mal integrados, interfaz que los clínicos no toleran. Hay algo de verdad en eso, y sería deshonesto negarlo.

Pero el software raramente es la causa primaria del fracaso. Los proyectos HIS no mueren por bugs. Mueren por lo que hay alrededor del software: la organización que lo recibe, los procesos que nadie quiso documentar antes de empezar, y los datos que llevan décadas acumulándose sin ningún criterio de calidad.

Por qué fallan los proyectos de software hospitalario: los tres factores reales

KLAS Research, la consultora de referencia en evaluación de software sanitario a nivel global, identifica de forma consistente tres factores que predicen el fracaso de una implementación HIS. Ninguno tiene que ver con el código.

1. Gobernanza sin autoridad real

Los proyectos HIS cuentan, casi siempre, con un comité de dirección con nombres relevantes y sin capacidad efectiva de tomar decisiones que incomoden a alguien.

Cuando aparecen conflictos, y siempre aparecen, nadie quiere ser quien frene a un servicio médico con veinte años de historia o quien contradiga al director de informática frente al proveedor. El resultado es parálisis por consenso. Los plazos se extienden, los costes se disparan y el proyecto pierde momentum mientras los equipos siguen operando con el sistema antiguo.

La gobernanza que funciona tiene una sola característica estructural: existe una persona o un órgano con autoridad real para tomar decisiones no populares y que se cumplan. Eso raramente está escrito en el pliego de condiciones.

2. Infraestimación sistemática de la migración de datos

Este es el error técnico que más proyectos entierra, y el que menos aparece en los análisis post-mortem porque resulta difícil de explicar a un comité directivo.

Los hospitales acumulan décadas de datos clínicos en sistemas legados, con formatos propietarios, campos sin normalizar, registros duplicados y estructuras que reflejan decisiones de hace veinte años que ya nadie recuerda por qué se tomaron. Migrar eso no es un proceso de importación masiva. Es una auditoría forense de la información clínica del centro, con decisiones de negocio, qué se migra, en qué formato, con qué criterio de calidad, que requieren tiempo, recursos y participación de los clínicos.

Los proveedores saben cuánto cuesta esto. No siempre lo dicen en la fase de venta porque alargaría el proceso comercial. Y los responsables de compra no siempre lo preguntan porque alargaría el proceso de decisión.

3. Formación puntual en lugar de adopción sostenida

La formación en sistemas hospitalarios tiene una ventana de absorción muy limitada. Se forma al personal en el mes previo al arranque, con equipos en tensión anticipando el cambio. Según datos de estudios de adopción de EHR de la Universidad de California, los usuarios olvidan hasta el 70% del contenido formativo en las primeras semanas de uso real si no hay refuerzo continuado.

El resultado es conocido: usuarios que crean workarounds propios para esquivar el sistema, datos que se introducen de forma inconsistente entre servicios, e indicadores de calidad de datos que se degradan de forma silenciosa durante los primeros seis meses de uso. El HIS técnicamente funciona. En la práctica, genera más fricción que el sistema que vino a sustituir.

Implementaciones HIS en España y LATAM: el contexto que agrava el problema

En España, la complejidad tiene una capa estructural adicional que los análisis globales no capturan: la fragmentación autonómica.

Cada comunidad autónoma ha desarrollado sus propios sistemas de información, sus propios estándares técnicos y, en muchos casos, sus propios procesos de integración con la atención primaria. El proyecto HCDSNS, Historia Clínica Digital del Sistema Nacional de Salud, lleva años intentando construir una capa de interoperabilidad funcional sin terminar de consolidarla. La Estrategia de Salud Digital 2022–2026 reconoce explícitamente el problema, lo que es positivo; que llevar décadas reconociéndolo sin resolverlo sea lo normal, es otra conversación.

Un hospital que implanta un HIS nuevo no solo debe integrarlo con su laboratorio, su servicio de farmacia y sus sistemas de imagen médica. Debe integrarlo con el sistema autonómico correspondiente, alinearlo con el ENS (Esquema Nacional de Seguridad) y garantizar el cumplimiento del RGPD en su dimensión más exigente: los datos de salud son datos de categoría especial bajo el artículo 9, con obligaciones de seguridad que van mucho más allá del consentimiento informado.

En México, la NOM-024 establece los requisitos técnicos del expediente electrónico, pero su cumplimiento real en las implementaciones de software privado es heterogéneo. La coexistencia de los ecosistemas del IMSS, el ISSSTE y los hospitales privados crea entornos de integración que ningún proveedor resuelve de forma estándar.

En Colombia, la Resolución 3374 y el sistema REPS generan obligaciones de reporte que deben estar contempladas en el HIS desde el diseño, no añadidas como módulo posterior.

Lo que comparten España y todos los mercados de LATAM con mayor madurez digital: el presupuesto para gestión del cambio organizacional es invariablemente el primero en recortarse cuando el proyecto se desvía en costes. Es también el que tiene mayor impacto en el éxito final. La matemática de esa decisión habla por sí sola.

Qué exigir a tu proveedor de software de gestión hospitalaria antes de firmar

Si eres director gerente, CIO o responsable de una implantación HIS, estas preguntas deben tener respuesta documentada antes de que el contrato lleve tu firma.

Sobre los datos: ¿El contrato incluye una fase de auditoría previa del estado de los datos del sistema actual? ¿Cuántas horas de consultoría de migración están presupuestadas? Si la respuesta es ambigua, “os ayudaremos en lo que necesitéis”, pide un número. La ambigüedad en migración de datos es siempre cara.

Sobre la gobernanza: ¿Está identificada por escrito la persona o el órgano con autoridad para tomar decisiones ejecutivas en el proyecto? ¿Hay un protocolo de escalado acordado con tiempos de respuesta? Si no existe, el primer conflicto real lo gestionará el consenso informal, que es otra forma de decir que nadie lo gestionará a tiempo.

Sobre la formación: ¿El contrato incluye formación de refuerzo a los tres y seis meses del arranque? ¿Se han definido métricas de adopción, porcentaje de registros completados correctamente, tiempo de uso por perfil de usuario, como parte de los criterios de éxito del proyecto? Si la formación es un evento puntual pre-arranque, ya sabes qué ocurrirá.

Sobre las referencias: Pide hablar con el director de operaciones de un hospital que tenga el sistema en producción desde hace más de dos años, no con el que lo implantó hace seis meses. Las implementaciones recientes generan euforia de arranque. Los dos años revelan la realidad del uso sostenido y los problemas que no aparecen en los primeros meses.

El sector necesita una conversación diferente sobre los proyectos de software hospitalario

Los primeros proyectos de historia clínica electrónica en España y LATAM acumulan más de veinte años de lecciones aprendidas. Hay literatura académica, informes de consultoras y post-mortems publicados con franqueza infrecuente en el sector.

El problema no es que esas lecciones no estén escritas. Es que la siguiente licitación se redacta igual que la anterior: con criterios técnicos exhaustivos sobre funcionalidades del software, y sin ningún requerimiento serio sobre gestión del cambio organizacional, calidad de los datos de origen o gobernanza ejecutiva del proyecto.

Hasta que los contratos no exijan resultados medibles de adopción y calidad de datos, las implementaciones seguirán vendiéndose como proyectos tecnológicos en lugar de lo que realmente son: proyectos de transformación organizacional con un componente tecnológico.

La próxima vez que tu hospital evalúe un HIS, la pregunta más importante no es “¿qué módulos incluye?” ni “¿cuánto cuesta la licencia?”. Es esta: “¿Qué pasará cuando el proyecto entre en crisis, y quién tiene autoridad real para tomar decisiones en ese momento?”

Los proyectos que salen bien no tienen menos problemas que los que fracasan. Tienen mejor gobernanza. Y eso se negocia antes de firmar, no después de empezar.

¿Has vivido una implementación HIS que salió bien, o una que salió mal? Las lecciones reales de este sector vienen de quienes se atreven a contar la versión sin editar. Comparte tu experiencia en los comentarios.

Sobre la autora

Sara Nievas es Marketing Communications Manager en NaturalSoft Solutions, empresa especializada en software de gestión hospitalaria y clínicas de reproducción asistida con presencia en 28 países.

Escribe sobre transformación digital en sanidad en esta publicación y en LinkedIn.

→ Conecta en LinkedIn: linkedin.com/in/tirandodardos

→ Software hospitalario NS-Hospital: naturalsoft.es/soluciones/ns-hospital

→ Software para clínicas de fertilidad VRepro: naturalsoft.es/soluciones/vrepro