Errores Comunes en la Adquisición de Tecnología de Salud: Guía de Gobernanza y Riesgos para Ejecutivos

Cuando una inversión en tecnología de salud fracasa, el análisis post-mortem casi nunca culpa al software en sí. Culpa al proceso que lo seleccionó. Los fallos de adquisición más dañinos en hospitales y sistemas de salud son fallos de gobernanza — decisiones tomadas en el orden incorrecto, por las personas incorrectas, sobre la base de números incorrectos. Estos errores son predecibles y, precisamente por ello, son evitables. Este artículo expone los errores de adquisición que con mayor frecuencia convierten un sistema prometedor en una crisis presupuestaria o una responsabilidad clínica, y las salvaguardas de gobernanza que los previenen. Está escrito para directorios y equipos ejecutivos en los Estados Unidos, la Unión Europea y el Reino Unido, donde el contexto regulatorio difiere pero la disciplina subyacente de una buena adquisición no.

Error 1: Evaluar proveedores antes de definir requisitos

El error de adquisición más común ocurre antes de que nadie firme nada: la organización comienza a evaluar proveedores antes de haber acordado qué necesita realmente. Los ejecutivos asisten a demostraciones impecables, se enamoran de un flujo de trabajo en su mejor versión y luego trabajan hacia atrás para justificar un sistema que nunca fue medido contra un conjunto definido de requisitos. El resultado es una decisión anclada a una narrativa de ventas en lugar de a la realidad operacional.

La evidencia de que esto importa es de larga data. En el análisis CHAOS del Standish Group sobre los resultados de proyectos de TI, las tres principales causas de fracaso de proyectos citadas por los ejecutivos de TI fueron la falta de participación del usuario (12,8%), los requisitos y especificaciones incompletos (12,3%) y los requisitos y especificaciones cambiantes (11,8%) [4] — en conjunto, las razones dominantes por las que los proyectos no logran sus objetivos. En la práctica, la definición de requisitos y la evaluación de necesidades que preceden a una solicitud de propuesta no son papeleo; son el instrumento con el que se evalúa y responsabiliza posteriormente a los proveedores. Sin ellos, una evaluación carece de criterio objetivo y termina favoreciendo a quien mejor demuestra.

La salvaguarda de gobernanza es simple de enunciar y más difícil de hacer cumplir: definir los requisitos primero, por escrito, clasificados en "imprescindibles" y "deseables", y solo entonces invitar a los proveedores a responderlos. En nuestra experiencia, las organizaciones que preseleccionan solo tres o cuatro finalistas contra criterios ponderados previamente acordados toman decisiones notablemente mejores que las que dejan que el mercado moldee su pensamiento.

Error 2: Dejar que TI conduzca una decisión que requiere propiedad clínica

La tecnología de salud no es una compra administrativa de oficina. Un sistema clínico modifica la forma en que trabajan médicos, enfermeras y farmacéuticos, y una decisión tomada sin su respaldo encontrará resistencia en el punto de atención sin importar cuán sólida sea la tecnología. Demasiadas organizaciones tratan la selección de sistemas como un proyecto de TI con "participación" clínica, cuando debería ser una decisión de propiedad clínica con validación de TI.

Las consecuencias de equivocarse en esto están bien documentadas. En su análisis EHR Implementations 2025, KLAS Research encontró que solo el 38% de las organizaciones reportaron que sus implementaciones postpandemia "dieron en el blanco", mientras que el 62% dijo que sus implementaciones fallaron significativamente o tenían áreas que necesitaban mejora [1]. Las organizaciones que tienen éxito comparten consistentemente un rasgo: una estructura de gobernanza formal con derechos de decisión definidos, patrocinio ejecutivo y liderazgo médico y de enfermería integrado desde el inicio, no consultado al final.

La salvaguarda es un estatuto de gobernanza documentado que nombre quién es propietario de la decisión. Los clínicos son propietarios de los requisitos, la revisión de demostraciones y el diseño del piloto; TI valida la viabilidad técnica y la seguridad; finanzas pone a prueba el modelo de costos. Un patrocinador nombrado a nivel de dirección lleva el proyecto durante toda su duración. Cuando esos derechos de decisión son ambiguos, los proyectos se desvían y la responsabilidad desaparece en el momento en que surgen problemas.

Error 3: Dejar que un proveedor preferido o titular defina los criterios de evaluación

Un fallo de gobernanza más sutil es permitir que un proveedor favorecido — frecuentemente el titular — influya en los criterios con los que se juzga a todos los proveedores. Esto puede ocurrir de manera inocente: el proveedor titular conoce su entorno, ayuda a "delimitar" el requisito y, al hacerlo, escribe silenciosamente las especificaciones en torno a las fortalezas de su propio producto y las debilidades de sus competidores. La evaluación parece rigurosa cuando en realidad está sesgada.

La salvaguarda es aislar el proceso de definición de criterios de cualquier parte comercial. Los requisitos y la ponderación deben ser finalizados y aprobados por el comité de gobernanza interno antes de que se involucren los proveedores, y la ayuda material para la redacción de especificaciones debe provenir de asesores independientes, no de los licitantes. Un proceso de evaluación transparente y auditable es también cada vez más una expectativa de cumplimiento en la contratación pública — por ejemplo, las organizaciones del NHS en el Reino Unido están dirigidas a comprar productos digitales a través de acuerdos marco estructurados con procesos de selección estandarizados y publicados, precisamente para reducir este riesgo.

Error 4: Subestimar el costo total de propiedad

Subestimar el costo total de propiedad (CTP) es uno de los errores de adquisición más dañinos y más comunes. Las organizaciones se obsesionan con la tarifa inicial de licencia o suscripción mientras subestiman los costos que realmente dominan un despliegue grande: servicios de implementación y configuración, desarrollo de interfaces e integración, capacitación del personal y gestión del cambio, soporte y mantenimiento continuos y — la partida que se omite con mayor frecuencia — la pérdida de productividad durante el período de transición. En nuestra experiencia, los servicios de implementación por sí solos frecuentemente representan varias veces la tarifa anual de software en proyectos complejos, y la licencia es solo una minoría del costo real a varios años.

Los casos reales son sobrios y públicos. NYC Health + Hospitals firmó su contrato de HCE Epic en enero de 2013 y reportó una inversión de $764 millones durante seis años para implementarlo y mantenerlo — una cifra muchas veces mayor que el contrato de software subyacente [3]. La University of Vermont Health Network dijo que su implementación de Epic por $151,7 millones fue parcialmente responsable de una pérdida operativa de $10 millones en el primer trimestre de 2020, a medida que los costos superaron las expectativas y la productividad de los médicos cayó mientras los clínicos se adaptaban al nuevo sistema [2]. Otros sistemas han atribuido públicamente pérdidas operativas de varios millones de dólares a las puestas en marcha de HCE, incluyendo Ector County Health District (que culpó parcialmente a su implementación de Cerner por $55 millones por pérdidas financieras y una rebaja de calificación de Fitch) y Centra Health (un proyecto de Cerner por $65 millones) [2]. En todos los casos, la tecnología era capaz; el dolor financiero provino de costos que eran previsibles pero no presupuestados.

La salvaguarda es un caso de negocio que modele costos a cinco años, no al primer año, y que trate la pérdida de productividad y el tiempo interno del personal como partidas reales. CaboLabs aconseja a sus clientes mantener un presupuesto de contingencia de al menos quince a veinte por ciento del costo de implementación para los cambios de alcance que inevitablemente emergen una vez que comienza la implementación; esta cifra refleja nuestra experiencia en compromisos reales y no un único referente publicado, pero el principio — presupuestar para las sorpresas que sabe que vienen — es universal.

Error 5: Descuidar el contrato

Muchas organizaciones invierten meses en seleccionar un sistema y luego firman el acuerdo estándar del proveedor con revisión legal mínima — aceptando términos redactados para favorecer al proveedor en cada escenario de disputa. El contrato es donde el poder de negociación se captura o se cede, y ese poder nunca es mayor que en el momento previo a la firma.

Las cláusulas que más recompensan la negociación son consistentes entre jurisdicciones: propiedad y derechos de exportación de datos (usted debe ser propietario de sus datos y poder extraerlos en un formato utilizable en cualquier momento); disposiciones de rescisión y asistencia en la transición; definiciones de nivel de servicio con remedios significativos en lugar de créditos simbólicos; límites de escalada de precios en renovaciones y complementos; y una definición precisa de lo que constituye el producto licenciado versus la personalización facturable. Contratar asesoría legal especializada en tecnología de salud antes de firmar es una inversión que casi siempre se amortiza, especialmente a medida que la regulación eleva las apuestas: el Espacio Europeo de Datos de Salud de la UE requerirá atención contractual a la interoperabilidad, el registro, la calidad de los datos y las responsabilidades de actualización de estándares en los acuerdos con proveedores, convirtiendo la alineación legal y de adquisiciones temprana en una necesidad práctica y no en un lujo.

Error 6: Ignorar la realidad de la implementación — clínicos, plazos y migración de datos

Tres errores relacionados se agrupan en el punto donde la adquisición se encuentra con la implementación. El primero es la participación insuficiente de clínicos y usuarios finales en la recopilación de requisitos, lo que produce sistemas técnicamente correctos pero clínicamente inutilizables. El segundo es aceptar un cronograma de implementación poco realista — a menudo impulsado por ciclos presupuestarios o presión política en lugar de la preparación operacional. El tercero es no planificar la migración de datos y la interoperabilidad desde el inicio, tratando el movimiento de registros heredados y la construcción de interfaces como elementos secundarios en lugar de flujos de trabajo centrales y costificados.

La salvaguarda para los tres es la debida diligencia antes del compromiso. Las verificaciones de referencias y las visitas a sitios con organizaciones comparables — coincidentes en tamaño, especialidad y geografía — revelan los riesgos de implementación que ninguna demostración mostrará; emparejar a sus clínicos y gerentes con sus contrapartes en un sitio en funcionamiento es una de las cosas más valiosas que puede hacer un equipo de selección. El alcance y los requisitos de la migración de datos y las interfaces deben definirse y costificarse durante la adquisición, no descubrirse durante la puesta en marcha, y el cronograma de implementación debe probarse contra la preparación de la organización en lugar de las ambiciones del patrocinador.

Interoperabilidad y estándares abiertos como criterio de adquisición — y cómo ayuda CaboLabs

Un requisito merece tratamiento explícito en cualquier adquisición moderna de tecnología de salud: la capacidad de intercambiar y reutilizar datos sobre estándares abiertos. Esto ya no es una preferencia técnica; es un requisito comercial y de cumplimiento, y difiere por región. En los Estados Unidos, la regla final HTI-1 de la ONC (ASTP) avanza la tecnología de salud certificada hacia una interoperabilidad estandarizada basada en FHIR y la transparencia algorítmica [5]. En la Unión Europea, el Reglamento del Espacio Europeo de Datos de Salud (Reglamento (UE) 2025/327) establece requisitos obligatorios de interoperabilidad y registro para los sistemas de HCE, con el primer intercambio transfronterizo de uso primario de datos prioritarios — resúmenes de pacientes, ePrescripciones y eDispensaciones vía MyHealth@EU — volviéndose obligatorio en todos los Estados Miembros a partir del 26 de marzo de 2029 [6]. En el Reino Unido, NHS England exige un enfoque consistente de interoperabilidad a través del estándar FHIR UK Core, publicado bajo la sección 250 de la Ley de Salud y Atención Social de 2012 [7].

Para los ejecutivos, el punto de gobernanza es directo: los criterios de adquisición deben exigir que los datos de un sistema puedan salir de él tan fácilmente como entran, sobre estándares abiertos reconocidos como HL7 FHIR y openEHR. Esto protege la posición negociadora de la organización, reduce los costos futuros de cambio y mantiene a la institución del lado correcto de un panorama regulatorio que se endurece. CaboLabs asesora a clientes en EE.UU., la UE y el Reino Unido en la incorporación de estos requisitos basados en estándares en la adquisición — desde los criterios de solicitud de propuesta hasta las cláusulas contractuales — y construye Atomik, un repositorio de datos clínicos nativo de openEHR, precisamente para que los datos de salud permanezcan como propiedad y activo del proveedor en lugar de cualquier proveedor de software único. La buena gobernanza de adquisición y los estándares abiertos son dos expresiones del mismo principio: mantenga el control de sus datos, sus costos y sus opciones.