Tema 5.4 — Economía de la Ingeniería de Software en Salud

Por qué esto importa en economía de la salud

Toda organización sanitaria moderna es, lo admita o no, un operador de software. Los historiales de pacientes, la prescripción, la programación de citas, los resultados de laboratorio, las reclamaciones de pago y la vigilancia poblacional funcionan sobre código, comprado a proveedores, desarrollado internamente, heredado de predecesores o ensamblado a partir de las tres fuentes a la vez. El dinero implicado es cuantioso y recurrente: los programas nacionales de historia clínica electrónica han consumido miles de millones de dólares de fondos públicos, y los costes de funcionamiento del software sanitario —mantenimiento, integración, actualizaciones, seguridad— suelen eclipsar el precio que figuraba en el caso de negocio original. Sin embargo, la mayoría de la formación en economía de la salud no dice nada sobre cómo se comporta el software como activo económico, y la mayoría de la formación en ingeniería de software no dice nada sobre el coste de oportunidad en un sistema que también compra enfermeras y medicamentos.

Esta brecha importa porque el software falla económicamente de formas características que los reflejos habituales de contratación no detectan. Un sistema se compra por su precio de adquisición y sus funcionalidades de demostración; la integración, la migración de datos y la carga de mantenimiento llegan después, contra presupuestos que nunca fueron consultados. Una relación con un proveedor se endurece hasta convertirse en dependencia, de modo que cada renovación se negocia desde una posición de debilidad. Los atajos tomados bajo presión de plazos se acumulan de forma invisible hasta que el sistema que hace funcionar el hospital ya no puede modificarse con seguridad, momento en el que la organización se enfrenta a una factura de modernización que nunca planificó y no puede aplazar, porque el software ya conlleva riesgo clínico. La historia de los grandes programas de tecnología sanitaria, incluido el Programa Nacional de TI del Reino Unido (desmantelado en 2011 tras un coste estimado de unos 10.000 millones de libras), es la historia de estas dinámicas a escala nacional.

Para un directivo, lo que está en juego es triple. Primero, el dinero: el software es un compromiso de por vida, y la opción barata en el momento de la compra suele ser la opción cara a lo largo de una década. Segundo, la seguridad: en un entorno clínico, una interrupción, un error de datos o un sistema inmantenible no son un inconveniente, sino un peligro, con costes que se sitúan en el Tema 3.11 — Economía de la Calidad y la Seguridad. Tercero, la soberanía: las decisiones entre construir y comprar, entre sistemas propietarios y abiertos, y entre interfaces estándar y a medida determinan cuánta libertad tendrá la organización para actuar dentro de cinco años, y la libertad de acción, como sostiene este libro a lo largo de sus páginas, es un activo económico.

Conceptos fundamentales

La ingeniería de software es el diseño, la construcción y el mantenimiento disciplinados del software, y la palabra mantenimiento concentra la mayor parte de la economía. A diferencia de un edificio, el software nunca está terminado: los requisitos cambian, la normativa evoluciona, las dependencias envejecen y las amenazas de seguridad se transforman. El mantenimiento de software —trabajo correctivo, adaptativo y preventivo sobre un sistema en servicio— absorbe habitualmente la mayor parte del coste vital de un sistema. La unidad económica de análisis, por tanto, nunca es la compra; es el coste total de propiedad: adquisición más integración, migración de datos, formación, alojamiento, soporte, actualizaciones, seguridad y baja eventual, a lo largo de la vida realista del sistema.

El segundo concepto es la deuda técnica: el coste futuro implícito de elegir ahora un diseño expeditivo en lugar de uno sólido. La metáfora es lo bastante exacta como para usarla en una reunión financiera. La deuda no es intrínsecamente mala —un atajo deliberado que permite entregar antes una capacidad necesaria puede ser un préstamo racional—, pero genera intereses: cada cambio futuro en el sistema cuesta más por su causa, y la deuda no gestionada se capitaliza hasta que el cambio resulta prohibitivamente caro o peligroso. Una organización sanitaria que no puede ver su deuda técnica está arrastrando un pasivo no contabilizado, exactamente igual que si tuviera un endeudamiento no registrado.

Tercero, el sistema heredado: software que permanece en servicio más allá del punto en que puede mantenerse económicamente, a menudo porque funciona, todo el mundo depende de él y sustituirlo da miedo. El sistema heredado es deuda técnica a escala organizativa, y plantea un auténtico problema de valoración: los costes de mantenerlo (mantenimiento creciente, exposición de seguridad, personal que ya no se puede contratar, mejoras bloqueadas en otras áreas) son difusos y graduales, mientras que el coste de sustituirlo es concentrado, visible y políticamente arriesgado. Los sistemas de salud de todo el mundo hacen funcionar servicios críticos sobre software de décadas de antigüedad precisamente por esta razón.

Cuarto, la dependencia. La dependencia de proveedor es la condición en la que cambiar de proveedor cuesta tanto —en migración de datos, reciclaje del personal, reintegración y perturbación clínica— que el comprador ha perdido poder de negociación efectivo. En salud se agrava por los datos: una década de historiales de pacientes almacenados en un formato propietario es un rehén. La dependencia no es un accidente; es una estrategia de precios, y el momento de ponerle precio es antes de firmar, no en la renovación. Los contrapesos son contractuales (derechos de exportación de datos, depósito en garantía, asistencia para la salida) y arquitectónicos, sobre todo los estándares.

Quinto, la interoperabilidad: la capacidad de los sistemas para intercambiar información y usar lo que se intercambia. Su economía es la del efecto de red —cada sistema que habla un estándar común aumenta el valor de todos los demás sistemas que también lo hacen—, lo que explica por qué el mercado ofrece crónicamente una interoperabilidad insuficiente: los beneficios recaen sobre el sistema en su conjunto, mientras que los costes recaen sobre cada proveedor y comprador por separado, y un proveedor dominante puede beneficiarse precisamente de no interoperar. Estándares como Fast Healthcare Interoperability Resources (FHIR), la familia HL7 a la que pertenece, y openEHR existen para reducir estos costes de intercambio, y los reguladores —por ejemplo, Estados Unidos mediante las normas contra el bloqueo de información de la Ley Cures del Siglo XXI, y la Unión Europea mediante el Espacio Europeo de Datos Sanitarios— han empezado a exigir lo que el mercado no ofrecía.

Sexto, el espectro entre construir y comprar, incluido el software de código abierto: software cuyo código fuente puede usarse y modificarse libremente. El código abierto no es gratuito: el coste de licencia desaparece, pero la implementación, el alojamiento y la gestión permanecen, y alguien debe mantener el código. Su singularidad económica es otra: elimina la prima de la dependencia y convierte el software en un bien común que muchos compradores pueden cofinanciar, razón por la cual plataformas como DHIS2 y OpenMRS soportan gran parte de la carga de información sanitaria en países de renta baja y media. La decisión de construir frente a comprar, del mismo modo, no es una preferencia tecnológica sino una cuestión de cartera: construya donde la capacidad sea diferenciadora y la organización pueda sostener un equipo de ingeniería; compre donde la necesidad sea una mercancía estándar; y nunca construya lo que no pueda mantener.

Finalmente, la fiabilidad como magnitud económica. El software clínico presta servicios en los que el tiempo de inactividad tiene un coste sanitario, de modo que las disciplinas de ingeniería que mantienen los sistemas fiables —incluida la ingeniería de fiabilidad de sitios, que gestiona la fiabilidad frente a objetivos explícitos y presupuestos de fallo aceptable— se entienden mejor como la compra de un seguro cuya prima es el esfuerzo de ingeniería. Una fiabilidad superior a la que necesita el entorno clínico es despilfarro; por debajo, el déficit se paga en incidentes. El aparato de evaluación para todo esto sigue siendo el Tema 2.1 — Evaluación Económica y la disciplina de asequibilidad del Tema 2.5 — Impacto Presupuestario y Asequibilidad; este tema aporta la estructura de costes específica del software con la que deben alimentarse esos métodos. Evaluar una herramienta digital como intervención sanitaria —si la aplicación o el servicio de telesalud mejora los resultados a un coste aceptable— corresponde al Tema 5.2 — Economía de la Salud Digital; la economía de los modelos de IA específicamente, al Tema 5.3 — Economía de la IA en Salud.

Buenas prácticas

Evalúe el coste total de propiedad a lo largo de la vida realista del sistema, nunca el precio de compra. Exija que todo caso de negocio de software costee la adquisición, la integración, la migración de datos, la formación, el alojamiento, el soporte, la seguridad, las actualizaciones y la baja a lo largo de un horizonte declarado —normalmente una década o más— y que indique qué presupuesto asume cada partida recurrente. Un precio de licencia comparado con nada no es un caso de negocio; es la punta visible de un compromiso.
Registre la deuda técnica en los libros. Haga que los líderes de ingeniería mantengan un registro de los atajos significativos y los componentes envejecidos del parque tecnológico, con una estimación honesta del interés que cada uno cobra —cambios más lentos, mayor riesgo de incidentes, mejoras bloqueadas—. Revíselo con la misma seriedad que un pasivo financiero, y presupueste una cuota permanente de la capacidad de ingeniería (habitualmente entre un quinto y un tercio) para amortizarla, porque el servicio de la deuda aplazado es deuda capitalizada.
Financie el mantenimiento como coste operativo desde el primer día. El software que está "terminado" es software que se está degradando: las dependencias envejecen, las amenazas evolucionan, la normativa cambia. Incorpore el flujo de mantenimiento a la evaluación original y al presupuesto recurrente, y trate una propuesta sin partida de mantenimiento como incompleta: el dinero se gastará de todos modos, y la única cuestión es si se planificó o se extrajo por una crisis.
Ponga precio a la dependencia antes de firmar, no en la renovación. Para cada compra importante, calcule el coste de la salida mientras todavía dispone de alternativas: quién es propietario de los datos, en qué formato pueden exportarse, qué asistencia de salida debe proporcionar el proveedor y cuánto costaría plausiblemente una migración. Negocie derechos de exportación de datos e interfaces abiertas en el contrato, y trate la resistencia de un proveedor a aceptarlos como información sobre la próxima negociación de renovación.
Compre interoperabilidad de forma deliberada, porque el mercado la ofrece de manera insuficiente. Exija compatibilidad con estándares abiertos —FHIR y afines— como condición de compra, verifique el cumplimiento declarado frente a sus flujos de datos reales y no frente a un folleto, y rechace las interfaces a medida cuando exista una estándar. Cada interfaz propietaria que acepte es un coste de cambio que regala al proveedor y un impuesto sobre toda integración futura.
Decida entre construir y comprar como una cartera, ajustada a su capacidad de ingeniería. Construya solo donde la capacidad diferencie su servicio y pueda contratar, retener y financiar de forma realista un equipo que mantenga lo que construya —un sistema desarrollado internamente sin un equipo sostenido es un sistema heredado con pasos adicionales—. Compre las necesidades estándar; considere plataformas de código abierto cuando una comunidad o un consorcio público las sostenga; y por escrito el plan de sostenimiento en la decisión, sea cual sea el resultado.
Trate el código abierto como una opción de contratación con su propia estructura de costes, no como algo gratuito. Compárelo por coste total de propiedad: sin coste de licencia, pero con costes reales de implementación, alojamiento, soporte y gestión, ya se asuman internamente o mediante un proveedor de soporte. Sopese sus beneficios distintivos —sin prima de dependencia, código inspeccionable, la posibilidad de cofinanciar un bien común con otros organismos sanitarios— y su obligación distintiva: si depende de él, contribuya a sostenerlo.
Fije los objetivos de fiabilidad a partir de la consecuencia clínica, y gaste hasta el objetivo. Decida, servicio por servicio, cuánto cuesta realmente una hora de inactividad —en atención retrasada, soluciones improvisadas inseguras y confianza perdida— y establezca objetivos de disponibilidad y recuperación en consecuencia. Después mantenga el gasto de ingeniería fiel al objetivo desde ambos lados: pagar por menos fiabilidad de la que necesita la clínica compra incidentes, y pagar por más de la que necesita compra sobreingeniería innecesaria.
Planifique la sustitución del sistema heredado antes de que se vuelva forzosa. Revise periódicamente la antigüedad y la mantenibilidad de los sistemas críticos, y empiece la sustitución mientras el sistema vigente aún funciona: una migración ejecutada bajo fallo es la más cara de todas. Prefiera la migración incremental (estrangulando el sistema antiguo interfaz por interfaz) frente a las transiciones de tipo big-bang, cuyo modo de fallo en salud se mide en clínicas canceladas y registros perdidos.
Convierta la migración de datos en una partida de primer nivel en toda evaluación. Los datos de los pacientes sobreviven a todos los sistemas que los contienen, y trasladarlos —de forma limpia, completa y con la seguridad clínica garantizada— está habitualmente entre los costes mayores y más infravalorados de cualquier transición. Cuantifíquela explícitamente, pruébela pronto con registros reales, y mantenga la custodia de sus datos en formato exportable durante toda la vida de un sistema, de modo que la migración nunca quede rehén del proveedor saliente.
Mantenga la ingeniería de seguridad clínica dentro de la economía. El software sanitario es software relevante para la seguridad: los cambios necesitan pruebas, las versiones necesitan vías de reversión, los incidentes necesitan investigación, y las jurisdicciones imponen cada vez más normas formales de riesgo clínico a la tecnología sanitaria. Estas disciplinas cuestan tiempo de ingeniería y deben figurar en el caso de negocio: una entrega "más barata" que las omite está transfiriendo el coste a los pacientes en forma de riesgo (el coste del daño se trata en el Tema 3.11 — Economía de la Calidad y la Seguridad).
Someta las decisiones de software al mismo escrutinio de valor que cualquier otra inversión sanitaria. Un programa de software compite por el mismo presupuesto restringido que los medicamentos y el personal, así que debe la misma disciplina: un beneficio declarado, un comparador real (incluido "mejorar lo que ya tenemos"), un perfil de asequibilidad a lo largo del tiempo y una revisión posterior a la implementación frente a las promesas realizadas (el aparato es el Tema 2.1 — Evaluación Económica y el Tema 2.5 — Impacto Presupuestario y Asequibilidad, y el oficio de compra es el Tema 3.10 — Compra Estratégica y Contratación de Servicios).

Preguntas para debatir con su equipo

¿Cuánto cuesta realmente nuestro parque de software al año, y qué parte de ello planificamos? La mayoría de las organizaciones puede nombrar sus cuotas de licencia, pero no sus costes de integración, mantenimiento, seguridad y soluciones improvisadas, que se ocultan en los presupuestos operativos y el tiempo del personal en toda la organización. Pida al equipo que reúna la cifra anual real de los principales sistemas y la compare con lo que prometían los casos de negocio originales. La tensión reside en que los costes difusos no tienen un único propietario, así que nadie es responsable de su crecimiento, y las personas que aprobaron la compra rara vez son las que pagan el mantenimiento. Una respuesta honesta produce una cifra de coste vital completo, indica qué presupuestos la asumen y admite dónde el gasto no está planificado, porque un coste que se descubre anualmente con retraso es un coste que no se puede gestionar.
¿Dónde está nuestra deuda técnica, y qué interés estamos pagando por ella? Los equipos de ingeniería suelen saber exactamente dónde está la deuda —el módulo que nadie se atreve a tocar, la interfaz sostenida con pasos manuales, la plataforma dos versiones por detrás en soporte de seguridad—, pero ese conocimiento rara vez llega a la dirección en lenguaje económico. Pida el registro: las deudas significativas, qué ralentiza o pone en peligro cada una, y cuánto costaría amortizarlas. La tensión reside en que la amortización de deuda compite con nuevas funcionalidades visibles y siempre pierde en imagen, que es precisamente cómo se capitaliza la deuda. Una respuesta honesta cuantifica el interés (entrega más lenta, exposición a incidentes, proyectos bloqueados), compromete una cuota permanente de capacidad para su reducción, y acepta que cierta deuda es racional mantener, siempre que se mantenga con conocimiento de causa.
Si tuviéramos que dejar a nuestro proveedor principal de sistemas dentro de tres años, ¿podríamos hacerlo, y cuánto costaría? Esta pregunta saca a la luz la dependencia mientras todavía hay tiempo para reducirla. Indague quién es propietario de los datos y en qué formato pueden salir, qué dice el contrato sobre la asistencia de salida, cuántas interfaces a medida habría que reconstruir, y qué reciclaje del personal y qué perturbación clínica impondría una migración. La tensión reside en que todos esperan no tener que ejercer nunca la salida, así que nadie quiere pagar por mantenerla abierta; sin embargo, una salida imposible es una negociación de renovación ya perdida. Una respuesta honesta pone precio a la salida, identifica las dos o tres acciones que la abaratarían (derechos de exportación de datos, interfaces estándar, documentación), y trata ese precio como una posición negociadora que la organización mantiene activamente.
¿Qué sistemas deberíamos construir, cuáles deberíamos comprar, y nuestra capacidad de ingeniería está a la altura de esa respuesta? La división entre construir y comprar es una decisión de cartera que muchas organizaciones toman por acumulación en lugar de por elección, y acaban construyendo mercancías estándar y comprando lo que las diferencia. Pregunte cuáles de sus sistemas encarnan genuinamente algo distintivo de su servicio y cuáles son necesidades estándar que ya atiende un mercado o una comunidad de código abierto. Después ponga a prueba la afirmación sobre la capacidad: para todo lo construido internamente, ¿existe un equipo financiado y contratable comprometido a mantenerlo durante toda su vida, no solo el proyecto que lo creó? La tensión reside en que construir halaga la ambición y comprar halaga la prudencia, y ninguno de los dos instintos es un análisis. Una respuesta honesta nombra los diferenciadores, admite dónde deberían retirarse o sustituirse por productos estándar construcciones pasadas, y se niega a iniciar cualquier construcción cuyo mantenimiento no esté financiado.
¿Cuánto cuesta realmente una hora de inactividad en nuestro sistema más crítico, y nuestro gasto en fiabilidad está a la altura? Las decisiones de fiabilidad a menudo las toman ingenieros sin información sobre el coste clínico, o direcciones sin información sobre el coste de ingeniería, así que el gasto se ajusta al hábito en lugar de a la consecuencia. Trabaje un escenario concreto: la historia clínica electrónica cae durante una jornada de mucha actividad; ¿qué se retrasa, qué soluciones improvisadas inseguras aparecen, qué daño se produce plausiblemente, cuánto cuesta la recuperación? Compárelo después con lo que gasta en resiliencia, copias de seguridad, conmutación por error y respuesta a incidentes. La tensión funciona en ambos sentidos: gastar de menos compra incidentes, pero sobreproteger un sistema de bajo riesgo desperdicia dinero que otro servicio necesita. Una respuesta honesta fija un objetivo explícito de disponibilidad y recuperación por servicio crítico, derivado de la consecuencia clínica, y puede mostrar el gasto de ingeniería que lo cumple, ni más ni menos.
¿Cuál es nuestro plan para los sistemas heredados que todo el mundo teme tocar? Toda organización sanitaria madura los tiene: sistemas que han superado su mantenibilidad económica, mantenidos con vida porque funcionan y la sustitución da miedo. Nombre los suyos. Pregunte qué bloquea cada uno —integraciones no construidas, mejoras no realizadas, exposición de seguridad asumida— y cuál es la vía de sustitución: migración incremental, sustitución total, o retención deliberada y planificada con riesgo contenido. La tensión es temporal: los costes de mantener lo heredado son difusos y anuales, mientras que el coste de sustituirlo es concentrado y visible en la carrera profesional, así que el aplazamiento aparentemente racional es la opción por defecto hasta que el fallo fuerza la cuestión al peor precio posible. Una respuesta honesta programa la sustitución mientras el sistema vigente aún funciona, prefiere la migración incremental de tipo estrangulador frente a la transición de golpe, y trata "decidiremos el año que viene" como la decisión que en realidad es.

En la práctica: un ejemplo de economía de la salud

El Ministerio de Salud de un país ficticio de África Oriental se enfrenta a una decisión de renovación. Durante nueve años, sus hospitales regionales han funcionado con un sistema propietario de información hospitalaria suministrado por un proveedor extranjero. El sistema funciona, pero el presupuesto de renovación ha subido bruscamente, cada interfaz nueva —con el sistema nacional de seguro y con la red de laboratorios— es un proyecto a medida y con precio del proveedor, y el contrato guarda silencio sobre la exportación de datos. Mientras tanto, las oficinas distritales de salud del ministerio ya utilizan DHIS2, la plataforma de código abierto empleada para las estadísticas sanitarias nacionales, y un país vecino ha implantado una plataforma de historia clínica de código abierto con un consorcio regional de soporte.

La unidad de economía de la salud del ministerio replantea la decisión, que pasa de "renovar o no" a una comparación de coste vital completo entre tres opciones a diez años: renovar con el proveedor actual, renovar a corto plazo mientras se construyen derechos de salida, o migrar de forma incremental a la plataforma de código abierto. Cuantificar las opciones revela la economía real. La licencia del proveedor actual representa solo un tercio de su coste anual real una vez que se cuentan las interfaces a medida, los proyectos de actualización obligatorios y los desplazamientos de soporte desde el extranjero. La opción de código abierto no conlleva licencia, pero exige al ministerio financiar un equipo nacional de soporte, alojamiento regional y una contribución a la comunidad de la plataforma: dinero real y recurrente que la retórica del "software gratuito" había ocultado. La partida decisiva, sin embargo, no es ninguna de estas: es la migración de datos. Nueve años de historiales de pacientes residen en un esquema propietario, y el precio del proveedor por la asistencia de extracción es, en efecto, el precio de marcharse.

La unidad pone precio a la salida de todos modos, y esa cifra cambia la negociación. Armado con una alternativa cuantificada, el ministerio negocia una renovación de dos años a un precio más bajo que incluye exportación contractual de datos en un formato documentado e interfaces FHIR estándar con el sistema de seguro y la red de laboratorios, comprada, en términos económicos, como una opción sobre una salida futura más barata, valorada del modo en que el Tema 3.12 — Economía de la Preparación ante Pandemias y Emergencias valora cualquier opción sobre libertad de acción futura. Durante esos dos años, un proyecto piloto migra tres hospitales distritales a la plataforma de código abierto, poniendo a prueba el consorcio de soporte, las herramientas de migración de datos y —de forma crítica— si el ministerio puede contratar y retener a los ingenieros que la plataforma necesita, apoyándose en la economía de la fuerza laboral del Tema 3.6 — Fuerza Laboral Sanitaria y Mercados de Trabajo.

El piloto tiene éxito en dos hospitales y encuentra dificultades en el tercero, donde las carencias de personal convierten cada incidente en una crisis, una advertencia sobre capacidad, no sobre software. El ministerio procede con una migración nacional escalonada a lo largo de cinco años, hospital por hospital, manteniendo el sistema vigente en paralelo hasta verificar los datos de cada centro. La evaluación final hace explícita la lección: la jugada ganadora no fue elegir el código abierto frente al propietario, sino cuantificar el coste vital completo de cada opción, comprar derechos de salida antes de que la dependencia se endureciera aún más, y ajustar el compromiso de ingeniería a lo que el ministerio podía sostener realmente.

Cuatro perspectivas sectoriales

Startup

Una startup de software sanitario vive la economía de este tema desde el lado de la venta: su valoración premia la velocidad de entrega, que es precisamente la forma en que se acumula la deuda técnica, y su modelo de ingresos puede depender silenciosamente de la misma dependencia que sus clientes deberían resistir. La disciplina consiste en asumir deuda de forma deliberada —un atajo que gana a un cliente decisivo puede ser racional— manteniendo a la vez un registro y un plan de amortización, porque una base de código que no puede modificarse es una empresa que no puede pivotar. La interoperabilidad es estrategia, no cumplimiento normativo: las interfaces estándar (sobre todo FHIR) son la forma en que un producto pequeño se gana un lugar dentro de parques dominados por operadores establecidos. Y la ingeniería de seguridad clínica no es burocracia que aplazar hasta alcanzar escala; un solo incidente de integridad de datos en un entorno clínico puede acabar con una empresa joven.

Pequeña empresa

Un proveedor pequeño pero consolidado —un grupo de clínicas, una cadena de farmacias, un laboratorio de diagnóstico— compra casi todo su software y no cuenta con personal de ingeniería que compense una mala compra, de modo que su economía es la economía de la dependencia. El coste total de propiedad y los derechos de salida importan aquí más que en ningún otro sitio, porque un sistema mal valorado supone proporcionalmente una parte mayor del presupuesto, y una migración fallida puede paralizar el negocio. La postura sensata es la estandarización: productos convencionales, interfaces de estándar abierto, servicios alojados en lugar de servidores gestionados internamente, y contratos leídos por sus cláusulas de exportación de datos antes que por el precio. Su riesgo distintivo es el sistema heredado silencioso —el sistema de gestión de consulta que envejece sin cambios hasta que su proveedor desaparece—, así que incluso un comprador pequeño debería saber, cada año, cuánto le costaría dejar cada sistema del que depende.

Gran empresa

Un gran grupo hospitalario o una aseguradora gestiona cientos de sistemas, así que su problema es la cartera: productos solapados comprados por distintos departamentos, una red de integración que nadie mapea por completo, y deuda técnica distribuida por un parque demasiado grande para que ningún equipo lo abarque. La gran empresa madura gestiona el parque como gestiona una cartera de inversiones —un inventario de sistemas con propietarios, costes vitales completos, calificaciones de deuda y riesgo, y horizontes de sustitución planificados— y financia una capacidad de ingeniería permanente para la integración, la fiabilidad y la amortización, en lugar de tratar cada mejora como un proyecto que hay que licitar. La escala también le otorga un poder de compra del que carece el comprador más pequeño: puede exigir interfaces estándar, derechos de exportación de datos y depósito en garantía como condiciones de entrada, y sus decisiones arquitectónicas disciplinan a sus proveedores en lugar de al revés.

Gobierno

Un ministerio o un pagador nacional modela esta economía para todos los demás. Establece las reglas de interoperabilidad que determinan si el mercado premia o castiga la apertura —como hizo Estados Unidos con las disposiciones contra el bloqueo de información de la Ley Cures del Siglo XXI, y la Unión Europea con el Espacio Europeo de Datos Sanitarios—, y su propia contratación enseña a los proveedores lo que los compradores van a tolerar. Su modo de fallo distintivo es el megaprograma nacional: entrega de software centralizada, de tipo big-bang, con calendario político, cuyo colapso se mide en miles de millones, como demostró el Programa Nacional de TI del Reino Unido. La disciplina es la postura inversa: estándares y plataformas de forma centralizada, entrega de forma incremental, con opciones de código abierto y de mantenimiento local sopesadas seriamente allí donde los mercados comerciales son escasos (el aparato de política se trata en el Tema 3.2 — Política de Salud, y el oficio de compra en el Tema 3.10 — Compra Estratégica y Contratación de Servicios).

Modos de fallo habituales

Comprar la licencia, no la vida útil. Aprobar software por el precio de compra mientras la integración, la migración, el mantenimiento y la salida quedan sin cuantificar. Solución: exigir el coste total de propiedad a lo largo de toda la vida, con presupuestos nombrados para cada partida recurrente, en todo caso de negocio.
Deuda invisible hasta que se capitaliza. Dejar que la deuda técnica se acumule sin registrar hasta que el parque ya no pueda modificarse con seguridad. Solución: mantener un registro de deuda, comunicarlo en términos económicos, y comprometer capacidad permanente para su amortización.
Deslizarse hacia la dependencia sin darse cuenta. Aceptar formatos propietarios e interfaces a medida hasta que la salida es inasequible y las renovaciones vienen dictadas. Solución: negociar derechos de exportación de datos e interfaces estándar en el momento de la compra, y poner precio a la salida anualmente.
Construir lo que no se puede mantener. Encargar sistemas internos sin un equipo financiado para toda su vida. Solución: ninguna construcción sin un plan de sostenimiento; comprar o adoptar plataformas de código abierto donde la capacidad sea escasa.
Tratar el código abierto como gratuito. Adoptar plataformas comunitarias sin financiar el alojamiento, el soporte y la gestión. Solución: evaluar el código abierto por coste total de propiedad y presupuestar el sostenimiento que necesita.
Fiabilidad por esperanza. Dejar sin fijar los objetivos de disponibilidad hasta que una interrupción revela el coste clínico del tiempo de inactividad. Solución: fijar objetivos de disponibilidad y recuperación por servicio crítico a partir de la consecuencia clínica, y gastar hasta el objetivo.
Sustitución del sistema heredado de golpe y bajo presión. Aplazar la modernización hasta que el fallo fuerza una transición apresurada y total. Solución: planificar la sustitución mientras el sistema vigente funciona, y migrar de forma incremental con funcionamiento paralelo y datos verificados.
Software fuera de la disciplina de valor. Dejar que los programas de tecnología eludan el escrutinio aplicado a los medicamentos y los servicios. Solución: mismas reglas: beneficio declarado, comparador real, perfil de asequibilidad, revisión posterior a la implementación.

Modelo de madurez

Dimensión	Iniciar	Desarrollar	Estandarizar	Gestionar	Orquestar
Coste vital completo	Software comprado por precio de licencia; costes de funcionamiento descubiertos con retraso	Compras importantes cuantificadas a varios años; partidas recurrentes parcialmente identificadas	Coste total de propiedad a lo largo de la vida del sistema exigido en todo caso de negocio, con presupuestos nombrados	Costes de todo el parque seguidos frente a la previsión, desviaciones investigadas, previsiones recalibradas	La economía del coste vital completo dirige la cartera: inversiones, renovaciones y retiradas reequilibradas de forma continua
Deuda técnica	Invisible; descubierta mediante incidentes	Conocida de manera informal por los ingenieros; sin registro compartido	Registro de deuda mantenido y comunicado en términos económicos; capacidad de amortización permanente	Tendencias de deuda gestionadas con límites y prioridades; interés medido en velocidad de entrega y exposición a incidentes	Deuda asumida y amortizada de forma deliberada como estrategia, cuantificada en cada decisión de entrega
Proveedor y salida	Condiciones aceptadas tal como se ofrecen; salida sin cuantificar	Dependencia reconocida; se buscan algunas cláusulas de exportación	Derechos de exportación de datos e interfaces estándar contractuales por norma; salidas cuantificadas en la compra	Posiciones de salida mantenidas y ensayadas; renovaciones negociadas frente a una alternativa viva	Cartera de proveedores modelada a lo largo del tiempo; la dependencia es una posición elegida y cuantificada, nunca un accidente
Interoperabilidad	Interfaces a medida se acumulan caso por caso	Estándares abiertos preferidos cuando resulta conveniente	Cumplimiento de estándares (p. ej., FHIR) verificado como condición de compra	Parque de integración mapeado y gestionado; interfaces propietarias retiradas según plan	La organización modela la adopción de estándares en sus socios y su mercado
Fiabilidad y seguridad	Coste del tiempo de inactividad desconocido; recuperación improvisada	Copias de seguridad y respuesta a incidentes existen; objetivos implícitos	Objetivos de disponibilidad y recuperación fijados por servicio crítico a partir de la consecuencia clínica	Fiabilidad diseñada y medida frente a objetivos; incidentes investigados económicamente	Resiliencia orquestada en todo el parque y los proveedores, ensayada y mejorada de forma continua

Lista de comprobación

Evaluar toda decisión de software por el coste total de propiedad a lo largo de su vida realista, con presupuestos nombrados para cada partida recurrente.
Mantener un registro de deuda técnica, comunicarlo en términos económicos, y comprometer capacidad de ingeniería permanente para su amortización.
Financiar el mantenimiento como coste operativo planificado desde el caso de negocio original en adelante.
Negociar derechos de exportación de datos, interfaces estándar y asistencia de salida en los contratos en el momento de la compra.
Poner precio a la salida de cada sistema importante anualmente, y mantener viva una alternativa cuantificada antes de las renovaciones.
Exigir el cumplimiento verificado de estándares abiertos (p. ej., FHIR) como condición de compra.
Decidir entre construir y comprar como una cartera, y no iniciar ninguna construcción sin un plan de sostenimiento vital financiado.
Evaluar las opciones de código abierto por coste total de propiedad, presupuestando alojamiento, soporte y gestión.
Fijar objetivos de disponibilidad y recuperación por servicio crítico a partir de la consecuencia clínica, y ajustar el gasto a ellos.
Programar la sustitución del sistema heredado mientras los sistemas vigentes aún funcionan, prefiriendo la migración incremental frente a la transición de golpe.
Cuantificar y probar la migración de datos con antelación, y mantener los datos de los pacientes exportables durante toda la vida de cada sistema.
Someter los programas de software al mismo escrutinio de valor que cualquier otra inversión sanitaria, con revisión posterior a la implementación.

Key sources

WHO, Global Strategy on Digital Health 2020–2025 — the World Health Organization's frame for digital health investment, including sustainability and interoperability principles.
HL7 International — the FHIR (Fast Healthcare Interoperability Resources) standard, the dominant open standard for health-data exchange.
openEHR, DHIS2, and OpenMRS — open-source health-information platforms and specifications widely deployed worldwide, exemplars of community-sustained health software.
U.S. Office of the National Coordinator for Health IT (now ASTP) — 21st Century Cures Act information-blocking and interoperability rules, a regulatory response to under-supplied interoperability.
DORA, Accelerate State of DevOps reports — long-running research linking software delivery and reliability practices to organizational performance.
UK National Audit Office — reports on the National Programme for IT in the NHS, the canonical case study of large-scale health-IT programme failure.

References

Software engineering — Wikipedia — https://en.wikipedia.org/wiki/Software_engineering
Software maintenance — Wikipedia — https://en.wikipedia.org/wiki/Software_maintenance
Total cost of ownership — Wikipedia — https://en.wikipedia.org/wiki/Total_cost_of_ownership
Technical debt — Wikipedia — https://en.wikipedia.org/wiki/Technical_debt
Legacy system — Wikipedia — https://en.wikipedia.org/wiki/Legacy_system
Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
Interoperability — Wikipedia — https://en.wikipedia.org/wiki/Interoperability
Network effect — Wikipedia — https://en.wikipedia.org/wiki/Network_effect
Fast Healthcare Interoperability Resources — Wikipedia — https://en.wikipedia.org/wiki/Fast_Healthcare_Interoperability_Resources
Health Level 7 — Wikipedia — https://en.wikipedia.org/wiki/Health_Level_7
Open-source software — Wikipedia — https://en.wikipedia.org/wiki/Open-source_software
Site reliability engineering — Wikipedia — https://en.wikipedia.org/wiki/Site_reliability_engineering
World Health Organization — Global Strategy on Digital Health 2020–2025 — https://www.who.int/publications/i/item/9789240020924
HL7 International — FHIR specification — https://hl7.org/fhir/
National Audit Office — The National Programme for IT in the NHS: an update on the delivery of detailed care records systems — https://www.nao.org.uk/reports/the-national-programme-for-it-in-the-nhs-an-update-on-the-delivery-of-detailed-care-records-systems/
National Programme for IT — Wikipedia — https://en.wikipedia.org/wiki/National_Programme_for_IT