Cómo Evitar el Vendor Lock-in en Salud: Guía para la Alta Dirección sobre la Propiedad de los Datos

Resumen Ejecutivo

El vendor lock-in ocurre cuando los costos técnicos, financieros y operacionales de cambiar de proveedor se vuelven tan elevados que una organización siente que no puede cambiar de rumbo aunque la relación ya no sirva a sus intereses. En salud, esto no es simplemente un inconveniente de TI — es un riesgo estratégico y clínico. El lock-in erosiona la capacidad de una organización para adoptar mejores herramientas clínicas, responder rápidamente a cambios regulatorios y negociar precios justos en las renovaciones de contrato. Las apuestas financieras son sustanciales: un análisis revisado por pares concluye que para los grandes sistemas de salud, el costo de migrar fuera de un sistema de historia clínica electrónica (HCE) dominante oscila entre cientos de millones y más de $1.000 millones, incluyendo licencias, consultoría, rediseño de flujos de trabajo y conversión de datos — un caso documentado, Partners HealthCare (ahora Mass General Brigham), presupuestó $600 millones para su implementación pero terminó gastando $1.200 millones.[1]

Este informe está escrito para la alta dirección de hospitales y sistemas de salud que operan en EE.UU., la UE y el Reino Unido. Enmarca el vendor lock-in como un problema de gobernanza y gestión de riesgos universal, no técnico ni regional, y plantea un único argumento central: la protección más efectiva contra el lock-in es exigir estándares abiertos en el momento de la adquisición — no después de que surja un problema. Los reguladores a ambos lados del Atlántico están convergiendo en el mismo principio. Los compromisos contractuales con la exportación de datos basada en estándares, las APIs de interoperabilidad publicadas y la plena propiedad de los datos son mucho más fáciles y económicos de negociar antes de firmar que después. Cerramos con la perspectiva de CaboLabs sobre cómo los estándares abiertos como openEHR — y nuestra plataforma nativa de openEHR, Atomik — ayudan a los hospitales a ser propietarios de sus propios datos y conocimiento clínico, en lugar de depender de un único proveedor.

Por Qué el Lock-in Es un Riesgo a Nivel Directivo en Salud

La concentración del mercado hace que el riesgo sea concreto. En los Estados Unidos, el mercado de HCE hospitalarios se ha vuelto altamente consolidado: según datos de participación de mercado de KLAS Research citados en un análisis revisado por pares, un solo proveedor, Epic Systems, provee la historia clínica electrónica al 42,3% de los hospitales de atención aguda y controla el 54,9% de todas las camas hospitalarias de atención aguda, y captó casi el 70% de los nuevos contratos hospitalarios en 2024.[1] Ese mismo análisis atribuye este dominio no a una clara superioridad tecnológica, sino a fuerzas estructurales como programas de incentivos federales, requisitos débiles de interoperabilidad, altos costos de cambio y efectos de red que refuerzan el vendor lock-in.[1]

La dinámica subyacente no es un fenómeno exclusivo de EE.UU.; es un fenómeno del sector salud que los reguladores en Europa y el Reino Unido están abordando directamente. El Reglamento del Espacio Europeo de Datos de Salud (EHDS) de la Unión Europea, que entró en vigor en marzo de 2025, exige que todos los sistemas de HCE comercializados en la UE cumplan con un formato europeo común de intercambio de HCE para ser interoperables a nivel europeo, y otorga a los individuos un derecho reforzado de acceso y portabilidad de sus datos de salud electrónicos.[6] En el Reino Unido, NHS England ha adoptado FHIR UK Core, un perfil nacional del estándar internacional HL7 FHIR, como su enfoque mandatorio para la interoperabilidad basada en APIs en Inglaterra, Escocia, Gales e Irlanda del Norte, con orientación del NHS que establece explícitamente que "lo importante es el estándar al que se ajusta la API, no la API en sí misma" — un principio que se aplica con igual fuerza al lock-in que a la interoperabilidad.[7]

A diferencia de la mayoría de las industrias, donde cambiar de proveedor es un inconveniente temporal, el lock-in en salud toca directamente la seguridad del paciente, la continuidad de la atención y el cumplimiento regulatorio. Cuando los costos de cambio son efectivamente prohibitivos, el proveedor titular obtiene un enorme poder de negociación en cada negociación posterior — sobre precios, prioridades de la hoja de ruta y qué innovaciones de terceros se permite conectar a un hospital. Ya sea que la presión provenga de un mercado concentrado (como en EE.UU.), un mandato supranacional de interoperabilidad (como en la UE) o un organismo nacional de estándares (como en el Reino Unido), el resultado es el mismo: las decisiones clínicas y financieras quedan silenciosamente restringidas por un sistema del que la organización ya no puede salir de manera realista.

Puntos a Considerar: Los Detalles que Deciden su Destino

El lock-in rara vez es el resultado de una sola mala decisión. Se acumula a través de detalles que son fáciles de pasar por alto en el momento de la adquisición y costosos de deshacer después, independientemente de la jurisdicción en la que opere. Los siguientes puntos merecen atención explícita de la alta dirección y del área de adquisiciones.

• Modelos de datos propietarios detrás de APIs "abiertas". Un proveedor puede ofrecer una API basada en estándares mientras almacena internamente sus datos en un esquema propietario y no documentado. Cuando se va, la API exporta una porción estandarizada superficial mientras el detalle clínico estructurado en profundidad queda atrapado en un formato que solo el proveedor comprende. Una API no equivale a la propiedad de los datos.
• APIs "abiertas" que son de solo lectura. Muchas APIs publicadas permiten que las aplicaciones aprobadas lean datos pero no los escriban de vuelta en el registro. El acceso de solo lectura significa que las herramientas de terceros pueden observar pero no participar en el flujo de trabajo, lo que silenciosamente obliga a que cada función clínica significativa pase por el proveedor titular. Los contratos deben especificar conformidad tanto de lectura como de escritura.
• Cargos contractuales por extracción de datos. El mecanismo más directo de lock-in es cobrar al cliente para obtener sus propios datos. Los reguladores de EE.UU. han identificado explícitamente cobrar una tarifa para exportar información de salud electrónica de modo que un proveedor pueda cambiar de plataforma como una posible práctica de bloqueo de información,[2] y el marco EHDS de la UE se basa en el principio opuesto — que los individuos y, por extensión, las organizaciones que actúan en su nombre deben poder acceder y portar datos de salud electrónicos sin obstáculos indebidos.[6] Sin embargo, las estructuras de tarifas vinculadas al volumen de datos o a herramientas de exportación propietarias siguen siendo comunes en la práctica. Negocie los términos de salida y extracción antes de firmar, dondequiera que opere.
• Contenido clínico y mapeos terminológicos atrapados en formatos propietarios. Años de inversión en conjuntos de órdenes, conjuntos de valores y mapeos terminológicos (por ejemplo a SNOMED CT) se encuentran entre los activos más valiosos y menos portables que posee un hospital. Migrar terminologías "de interfaz" propietarias a un estándar de referencia es un problema documentado e intensivo en trabajo: en un estudio de mapeo, el 71% de los conceptos se vieron afectados por una sola revisión de la terminología de destino.[4] Si este conocimiento vive solo dentro de la configuración del proveedor, no sale con usted.
• Estrategias de "suite integrada" de un solo proveedor. Una suite de un solo proveedor simplifica la integración interna pero concentra el riesgo. Las organizaciones que dependen de una suite integrada única para cada función están estructuralmente más expuestas que las que utilizan componentes best-of-breed conectados a través de capas de integración abiertas. El balance es consistencia de plataforma versus flexibilidad de ecosistema — y la flexibilidad es lo que preserva su poder de negociación futuro.
• Costos de motor de integración e interfaces. Cada interfaz punto a punto personalizada es un pequeño rehén. Cuando las integraciones se construyen según las convenciones propietarias de un proveedor en lugar de estándares publicados, cada una se convierte en una traducción que se rompe cuando cualquiera de los lados cambia — y un costo que deberá reconstruir si migra.
• Costos de reentrenamiento del personal. Los costos de cambio no son solo técnicos. El reentrenamiento de los clínicos, la reoptimización de los flujos de trabajo y la pérdida temporal de productividad durante la transición son frecuentemente los componentes reales más grandes de una migración, y los proveedores lo saben.
• Analítica y soporte a decisiones clínicas integrados en el HCE que no son portables. Los paneles de control, los modelos predictivos, la documentación ambiental y el soporte a decisiones clínicas cada vez más integrados directamente en la plataforma titular generalmente solo funcionan dentro de ese ecosistema. A medida que estas funcionalidades habilitadas por IA se profundizan, el costo de cambio puede pasar de astronómico a prácticamente imposible. Trate la analítica integrada como un vector de lock-in, no solo como una funcionalidad.

La Protección Más Efectiva: Exija Estándares Abiertos en el Momento de la Adquisición

Cada punto anterior es mucho más económico de prevenir que de corregir. Antes de firmar, un hospital tiene poder de negociación; después de firmar, lo tiene el proveedor titular. Los siguientes compromisos pertenecen al contrato en sí, no a una lista de deseos posimplementación — y cada uno está ahora respaldado por regulación en alguna jurisdicción donde su organización probablemente opera.

• Exportación de datos basada en estándares. Exija que todos los datos clínicos y operacionales sean exportables en formatos estándar publicados como HL7 FHIR, en cualquier momento y sin tarifas punitivas. En EE.UU., la regla final de la Ley de Curas del Siglo XXI de la ONC estableció un criterio de certificación que requiere que la tecnología de salud certificada exporte toda la información de salud electrónica que un producto puede almacenar, específicamente para apoyar a los proveedores que cambian de sistema.[2] En la UE, el Reglamento EHDS va más allá al exigir un formato europeo común de intercambio de HCE en todo el mercado.[6]
• APIs publicadas y conformes. Exija que las APIs se ajusten a especificaciones de interoperabilidad publicadas y soporten tanto operaciones de lectura como de escritura. En EE.UU., las regulaciones federales exigen que los pagadores regulados expongan datos de pacientes y clínicos a través de APIs basadas en HL7 FHIR, estableciendo FHIR Versión 4.0.1 como expectativa nacional base.[3] En el Reino Unido, NHS England exige FHIR UK Core para las APIs nuevas y en migración en todo el sistema de salud y atención social.[7] Cualquiera sea la jurisdicción aplicable, insista en el perfil FHIR nacional o supranacional, no en la variante propietaria del proveedor.
• Propiedad y portabilidad explícita de los datos. El contrato debe establecer sin ambigüedad que la organización es propietaria y retiene la plena portabilidad de sus datos clínicos y operacionales, incluidos los mapeos terminológicos, la configuración y los metadatos de auditoría — independientemente de lo que cualquier regulación exija en un momento determinado.
• Una estrategia de salida de datos documentada. Para cada sistema crítico, documente exactamente cómo migraría fuera de él: qué datos existen, en qué formato, cómo se extraerían y cuál sería el costo. Esto es valioso tanto como disciplina de gobernanza interna como señal negociadora — un proveedor titular que sabe que usted tiene un plan de salida creíble negocia de manera diferente.

Diversificación: Best-of-Breed sobre una Capa de Integración Abierta

Reducir el lock-in es en parte una elección arquitectónica. Una suite integrada única hace que cada función dependa de la hoja de ruta y los precios de un solo proveedor. Un enfoque best-of-breed — componentes especializados conectados a través de una capa de integración y persistencia abierta y basada en estándares — distribuye esa dependencia y preserva la capacidad de reemplazar cualquier componente sin reemplazar todo.

El habilitador clave es la capa de integración. El best-of-breed solo reduce el lock-in si los componentes se comunican a través de estándares abiertos en lugar de interfaces propietarias frágiles; de lo contrario, el hospital simplemente intercambia un lock-in por muchos. Aquí es donde la capa de persistencia — donde realmente viven los datos — se convierte en la pregunta de gobernanza decisiva.

La Visión de CaboLabs: Sea Propietario de sus Datos y su Conocimiento Clínico

La posición de CaboLabs es directa: los hospitales deben ser propietarios de sus datos y su conocimiento clínico, y ninguno de los dos debe depender de un único proveedor — ni del ciclo regulatorio de una única jurisdicción. El camino para lograrlo no es solo una cláusula contractual mejor — es una arquitectura en la que la capa de datos está diseñada para sobrevivir a cualquier aplicación individual. Los estándares abiertos hacen esto posible, ya sea que su organización opere bajo las regulaciones federales de EE.UU., el EHDS de la UE o el mandato FHIR UK Core de NHS England.

El estándar abierto diseñado específicamente para esto es openEHR, una especificación abierta sobre cómo deben estructurarse, almacenarse y preservarse las historias clínicas centradas en el paciente a lo largo de su vida.[5] Su idea central es una arquitectura de doble modelo, o de dos niveles, que separa el conocimiento clínico del software. Los clínicos e informaticistas definen el significado de los datos a través de "arquetipos" y "plantillas" formales; los desarrolladores de software se centran únicamente en cómo se almacenan y muestran los datos.[5] Como solo la base técnica estable se implementa en software, el significado clínico de los datos no depende de ninguna aplicación, proveedor ni región en particular.

Esto ataca directamente la causa raíz del lock-in. La vida útil típica del software empresarial es de 7 a 12 años, mientras que la historia clínica de un paciente debe mantenerse significativa durante toda su vida.[5] Cuando la capa de persistencia es neutral al proveedor y está basada en estándares, las aplicaciones pueden reemplazarse sin perder ni transformar los datos clínicos subyacentes, y múltiples aplicaciones pueden compartir el mismo repositorio estructurado — reduciendo la dependencia de cualquier proveedor de aplicaciones. Los beneficios que importan a la dirección son beneficios de gobernanza: persistencia neutral al proveedor, interoperabilidad semántica y portabilidad genuina de los datos.

Atomik, el repositorio de datos clínicos (CDR) y repositorio de datos demográficos (DDR) nativo de openEHR de CaboLabs, está construido exactamente sobre este principio. Provee una capa de datos persistente y basada en estándares a la que se conectan las aplicaciones, almacenando información clínica y demográfica según plantillas openEHR para que la estructura y la semántica estén definidas separadamente del software. Cambiar qué datos se recopilan no requiere migraciones de base de datos ni cambios de código, y Atomik expone APIs basadas en estándares — incluyendo interfaces conformes a openEHR y compatibles con FHIR, alineadas con perfiles regionales como FHIR UK Core donde corresponda — de modo que los datos permanecen accesibles para las aplicaciones que el hospital elija usar, ahora y en el futuro. En la experiencia de CaboLabs en proyectos de consultoría e implementación en EE.UU., la UE y el Reino Unido, construimos deliberadamente sobre especificaciones publicadas y evitamos los modelos de datos propietarios donde sea posible, precisamente porque eso es lo que mantiene los datos y el conocimiento clínico del cliente en manos del cliente, independientemente del régimen regulatorio que los rija hoy.

Para la dirección de un hospital, la implicación estratégica es que la persistencia neutral al proveedor convierte los datos clínicos de un pasivo retenido como rehén por un proveedor en un activo institucional duradero y portable — la base sobre la que mejores herramientas, negociaciones más justas y respuestas más rápidas a la regulación, en cualquier jurisdicción, se vuelven posibles.