Tema 1.1 — El modelo operativo

En una frase: Un modelo operativo objetivo (TOM) es el diseño deliberado de cómo la estrategia de tu organización fluye a través de flujos de valor, capacidades, equipos, gobernanza, tecnología, datos y proveedores para entregar resultados de salud y atención digital —y acertar en su forma determina si todo lo que viene después es rápido y seguro o lento y frágil.

Por qué esto importa en la salud y la atención#

La mayoría de las organizaciones de salud digital no fracasan por falta de talento o tecnología; fracasan porque su modelo operativo trabaja en su contra. La financiación está ligada a proyectos de tiempo limitado, los derechos de decisión son ambiguos, y cada equipo reconstruye la misma infraestructura de inicio de sesión, integración y auditoría. El resultado es un coste duplicado con dinero público, seguridad clínica inconsistente, y servicios que no pueden compartir datos en todo un sistema de atención integrada (ICS).

Un modelo operativo es distintivo en este ámbito porque debe conciliar bienes en competencia. Tiene que ser suficientemente federado para respetar la autonomía de organizaciones soberanas —fideicomisos, autoridades locales, consultas de médicos de cabecera— pero suficientemente coherente para dar a un paciente una experiencia segura y única a través de ellas. Debe equilibrar el funcionamiento (mantener los sistemas clínicos disponibles de forma segura) frente al cambio (mejorarlos), cuando el tiempo de inactividad puede afectar la atención. Y debe gastar de forma proporcionada: aseguramiento suficientemente pesado para la responsabilidad pública y la seguridad clínica, suficientemente ligero para no estrangular la iteración. El TOM es donde esas disyuntivas se hacen explícitas en lugar de dejarlas al azar.

Conceptos clave#

Las capas de un modelo operativo. Un TOM útil es una pila, donde cada capa sirve a la que tiene encima:

• Estrategia y resultados — los resultados medibles de población y servicio que existes para mejorar (a menudo expresados como OKR; véase el Tema 1.3 — Decisiones basadas en evidencia).
• Flujos de valor — los flujos de extremo a extremo que entregan valor a un usuario, p. ej. "derivar, clasificar y tratar a un paciente" —organizados en torno al recorrido del ciudadano, no del organigrama.
• Capacidades — las cosas que debes poder hacer (identidad, reserva de citas, documentación clínica, analítica). Las capacidades son estables incluso cuando las soluciones cambian.
• Equipos — las personas organizadas para entregar capacidades y flujos de valor (véase Team Topologies más abajo).
• Gobernanza y derechos de decisión — quién decide qué, y cómo se aplica el aseguramiento.
• Tecnología y datos — las plataformas, estándares y arquitectura de datos sobre los que construyen los equipos.
• Proveedores — el mercado al que compras y cómo lo gestionas.

Diseñar de arriba hacia abajo (estrategia → flujos de valor → capacidades) mantiene a los equipos y la tecnología alineados con los resultados en lugar de con las estructuras heredadas.

Modelos centralizado frente a federado frente a plataforma. Un modelo centralizado concentra la entrega en un equipo u organismo independiente: coherente y barato de estandarizar, pero un cuello de botella y a menudo alejado de la necesidad local. Un modelo federado delega la entrega a fideicomisos y territorios: receptivo y de propiedad local, pero propenso a la duplicación y a la divergencia. Un modelo de plataforma es el patrón conciliador: un equipo central proporciona capacidades compartidas y reutilizables (identidad, interoperabilidad, alojamiento, sistema de diseño) como una plataforma, y los equipos federados construyen encima con rapidez. La mayoría de los sistemas de salud maduros convergen en "plataforma más federación".

Team Topologies. Este marco nombra cuatro tipos de equipo —alineado al flujo (que posee un flujo de valor), plataforma (que proporciona capacidades de autoservicio), habilitador (que capacita a otros en una capacidad) y subsistema complicado (trabajo especializado profundo como un algoritmo)— y enfatiza la interacción de baja fricción entre ellos. Se corresponde limpiamente con el modelo de plataforma: los equipos de plataforma reducen la carga cognitiva de los equipos alineados al flujo para que puedan centrarse en el valor de usuario y clínico.

Funcionamiento frente a cambio. Funcionamiento es mantener los servicios en vivo seguros y disponibles; cambio es mejorarlos o construirlos. Los equipos de producto que tanto construyen como operan un servicio ("tú lo construyes, tú lo operas") cierran el bucle de retroalimentación y mejoran la seguridad, pero el equilibrio debe financiarse honestamente —privar de recursos al funcionamiento para financiar el cambio es la forma en que los sistemas clínicos se degradan.

La plataforma mínima viable (TVP). De Team Topologies: una plataforma debería ser el conjunto más pequeño de servicios compartidos que genuinamente reduce la fricción para los equipos de flujo —nada más. Una plataforma sobreconstruida se convierte en su propio cuello de botella y en su propio legado. Comienza con las pocas capacidades que cada equipo realmente necesita (autenticación, una capa de interoperabilidad, alojamiento, un sistema de diseño) y crece solo según demanda demostrada.

Buenas prácticas#

1. Diseñar el modelo desde los resultados hacia abajo, no desde el organigrama hacia arriba. Comienza con los resultados de población y servicio que debes mover, deriva los flujos de valor que los entregan, y solo entonces diseña equipos y tecnología. Un TOM anclado en la jerarquía existente simplemente automatiza los silos actuales.

2. Adoptar una forma de plataforma más federación. Proporciona capacidades compartidas de forma centralizada como una plataforma de autoservicio, y deja que los equipos alineados al flujo en fideicomisos y territorios construyan encima. Esto te da consistencia nacional en seguridad e interoperabilidad con velocidad y propiedad local —la conciliación que exige el ámbito.

3. Financiar productos, no proyectos. Traslada el dinero de proyectos con plazo fijo a equipos de producto financiados de forma persistente y alineados con flujos de valor. La financiación de proyectos obliga a los equipos a disolverse exactamente en el punto en que han aprendido el dominio; la financiación de producto sostiene el conocimiento de seguridad y la iteración que necesitan los servicios de salud (véase el Tema 5.0 — Trabajo liderado por producto).

4. Hacer que el control del gasto sea proporcionado y escalonado. Usa financiación escalonada ligada a la evidencia —libera dinero en las etapas de descubrimiento, alfa, beta y en vivo en lugar de aprobar un programa completo de antemano. Los controles de gasto al estilo GDS y la vía de aseguramiento del NHS existen para evitar grandes costes hundidos en ideas no probadas; aplícalos como umbrales escalados al riesgo y al valor, no como burocracia general.

5. Hacer explícitos los derechos de decisión con un mapa RACI o RAPID. La autoridad ambigua es la causa más común de entrega estancada. Nombra, para cada tipo significativo de decisión, quién es Responsable/Aprobador/Consultado/Informado (RACI) o quién Recomienda, Acuerda, Ejecuta, aporta Input y Decide (RAPID). Publícalo para que los equipos dejen de escalar decisiones que están empoderados para tomar.

6. Mantener la plataforma delgada y guiada por la demanda. Construye capacidades compartidas solo cuando dos o más equipos demuestren necesitar la misma cosa, y trata la plataforma como un producto con sus propios usuarios (los equipos internos). Resiste el impulso de preconstruir una gran plataforma; la plataforma mínima viable gana su alcance a través de la adopción.

7. Gestionar a los proveedores como parte del modelo, no fuera de él. Decide deliberadamente qué capacidades son estratégicas (construir/poseer) y cuáles son básicas (comprar), evita el bloqueo a un solo proveedor en los datos clínicos centrales, y exige estándares abiertos y derechos de salida en los contratos. Tus proveedores son una capa de tu modelo operativo, y sus formas de trabajar deben ser compatibles con las tuyas.

8. Hacer explícitos los derechos de decisión. Un modelo operativo solo funciona si las personas saben quién decide qué —qué elecciones corresponden a un equipo de producto, cuáles a una autoridad de seguridad clínica, y cuáles deben llegar a una junta directiva. Mapea los derechos de decisión y empuja cada decisión al nivel más bajo que pueda sostenerla de forma segura, para que la entrega no se estrangule por una escalada innecesaria. La autoridad ambigua es una de las causas más comunes de entrega lenta y defensiva.

9. Tratar el modelo operativo como un producto que evolucionas. Un modelo operativo objetivo no se fija una vez y se enmarca en la pared; inspécciónalo a medida que cambian la demanda, la tecnología y las asociaciones, y adáptalo según la evidencia. Observa unas pocas señales —flujo de trabajo, tiempo hasta la decisión, retrabajo y salud del equipo— y cambia las estructuras cuando demostrablemente estén estorbando, no en respuesta a la moda de la reorganización.

Preguntas para debatir con tu equipo#

1. ¿Está nuestro modelo operativo diseñado desde los resultados y los flujos de valor hacia abajo, o simplemente ha automatizado nuestro organigrama existente y sus silos? Esta pregunta apunta a la advertencia central del tema de que un TOM anclado en la jerarquía actual simplemente atrinchera los silos que ya tienes, así que vale la pena ponerla sobre la mesa antes de cualquier reorganización. Importa en un entorno de salud y atención porque los flujos de valor siguen el recorrido del ciudadano —derivar, clasificar, tratar— a través de organizaciones soberanas, mientras que los organigramas siguen los límites institucionales, y un modelo construido sobre estos últimos seguirá produciendo servicios fragmentados y no interoperables con dinero público. La tensión a debatir con honestidad es que diseñar de arriba hacia abajo desde los resultados es genuinamente disruptivo: corta a través de la propiedad departamental, los presupuestos y las líneas de reporte sobre las que personas senior han construido carreras, así que hacerlo correctamente tiene un coste político real. Pónganse a prueba de forma concreta nombrando sus tres principales resultados y rastreando si los límites reales de sus equipos y sus líneas de financiación siguen esos flujos de valor o los departamentos; si los equipos se corresponden limpiamente con departamentos, esa es su respuesta. Una respuesta buena y honesta admite dónde el modelo tiene forma de organigrama, identifica al menos un flujo de valor que actualmente está dividido entre silos en su detrimento, y es realista sobre qué límites estructurales la organización está dispuesta a redibujar.

2. ¿Qué pertenece a nuestra plataforma mínima viable, y cómo evitaremos que se sobreconstruya hasta convertirse en un cuello de botella o que se infraconstruya de modo que cada equipo reconstruya la misma infraestructura? La forma de plataforma más federación solo funciona si la plataforma se mantiene delgada y guiada por la demanda, y esta pregunta hace que el equipo confronte ambos modos de fallo que nombra el tema —la gran plataforma que se convierte en su propio cuello de botella heredado, y la ausencia que obliga a cada equipo a reconstruir el inicio de sesión, la integración y la auditoría. Importa porque en un ICS la plataforma es efectivamente infraestructura compartida (identidad, una capa de interoperabilidad FHIR, alojamiento con líneas base de seguridad, un sistema de diseño) y equivocarse en su alcance multiplica el coste o la fricción en cada equipo de flujo. La disyuntiva a debatir es el momento y la evidencia: construir demasiado pronto y adivinas mal y creas un cuello de botella; construir demasiado tarde y la duplicación ya se ha solidificado —así que la prueba de "dos o más equipos demuestran necesitar la misma cosa" es el quid de la cuestión, y el equipo debería poner a prueba si realmente la aplica o simplemente construye lo que parece obviamente central. Examina qué tratas actualmente como plataforma frente a lo que los equipos reconstruyen, y pregunta si la plataforma se gestiona como un producto con sus propios usuarios internos y SLA o como una cola tras la que todos esperan. Una respuesta honesta nombra las capacidades específicas que hoy superan la prueba de dos equipos, resiste la tentación de preconstruir el resto, y se compromete a tratar a los usuarios internos del equipo de plataforma como clientes reales con niveles de servicio reales.

3. ¿Dónde son nuestros derechos de decisión genuinamente ambiguos, y qué están escalando hoy los equipos que deberían estar empoderados para decidir por sí mismos? La autoridad ambigua se señala como la causa más común de entrega estancada, así que esta pregunta saca a la luz la fricción cotidiana que un mapa RACI o RAPID publicado pretende eliminar. Importa de forma aguda en un sistema de salud federado donde los equipos territoriales, una junta digital del ICS, la seguridad clínica y la gobernanza de la información tienen todos reclamos legítimos sobre una decisión, y los límites poco claros significan que o todo se escala o, peor, nadie asume una decisión hasta que sale mal. La tensión que merece explorarse es que delegar decisiones requiere confiar en los equipos dentro de límites, algo a lo que los líderes senior y las juntas a menudo se resisten precisamente donde está implicada la seguridad clínica o el dinero público —sin embargo, negar esa confianza es lo que crea el atasco de escalada en primer lugar. Hazlo concreto enumerando las últimas cinco decisiones que se escalaron y preguntando, para cada una, quién debería haber decidido y qué límite se lo habría permitido; el patrón suele revelar un pequeño número de tipos de decisión ambiguos recurrentes. Una buena respuesta produce una declaración específica y publicable de quién decide qué —distinguiendo estándares de plataforma, diseño de servicio y aprobación de seguridad clínica— y es honesta sobre qué decisiones la organización está genuinamente dispuesta a delegar frente a cuáles mantendrá centralizadas y por qué.

4. ¿Estamos financiando el funcionamiento y el cambio honestamente, o estamos privando silenciosamente de recursos a las operaciones de servicio en vivo para pagar nuevas funcionalidades? El tema es contundente en que privar de recursos al funcionamiento para financiar el cambio es la forma en que los sistemas clínicos se degradan, y esta pregunta obliga a sacar el equilibrio a la luz antes de que un corte de servicio o un incidente de seguridad lo haga por ti. Importa en la salud y la atención porque el "funcionamiento" no es una carga administrativa —es la disponibilidad de los sistemas de los que dependen los clínicos en el punto de atención, así que un presupuesto de funcionamiento degradado se manifiesta como tiempo de inactividad que puede afectar a los pacientes, no meramente incomodar a los usuarios. La disyuntiva es incómoda porque el cambio es visible y celebrado mientras que el funcionamiento es invisible hasta que falla, así que las juntas y las hojas de ruta naturalmente se inclinan hacia lo nuevo; un modelo "tú lo construyes, tú lo operas" ayuda al mantener cerrado el bucle de retroalimentación, pero solo si el tiempo de funcionamiento del equipo está genuinamente protegido en lugar de asignado nominalmente y luego saqueado. Hazlo concreto examinando qué proporción de la capacidad de cada equipo de producto se dedicó realmente a mantener los servicios seguros y disponibles el último trimestre frente a lo planificado, y si el trabajo de funcionamiento se rastrea y valora o se trata como una interrupción. Una respuesta honesta nombra dónde el funcionamiento está infrafinanciado hoy, protege una asignación realista de funcionamiento como primer cargo en lugar de residual, y es franca sobre qué servicios en vivo cargan con riesgo operativo acumulado.

5. ¿Qué capacidades estamos eligiendo deliberadamente construir y poseer frente a comprar, y estamos aceptando el bloqueo en nuestros datos clínicos centrales sin querer hacerlo? La buena práctica aquí es decidir deliberadamente entre construir y comprar, evitar el bloqueo a un solo proveedor en los datos clínicos centrales, y tratar a los proveedores como una capa del modelo operativo en lugar de algo externo a él —esta pregunta pone a prueba si esas elecciones se están tomando realmente o si están sucediendo por defecto. Importa porque en la salud digital el bloqueo más consecuente gira en torno a la historia clínica y sus datos, donde un almacén propietario sin salida realista puede atrapar a todo un sistema durante una década y dictar lo que cada servicio posterior puede hacer. La tensión es velocidad frente a opcionalidad: comprar es más rápido y a menudo más barato hoy, especialmente para un equipo con recursos limitados, pero cada compra conveniente sin estándares abiertos ni derechos de salida estrecha silenciosamente las opciones de mañana, y el coste solo se hace visible cuando intentas marcharte. Hazlo concreto enumerando tus capacidades centrales, marcando cada una como estratégica (construir/poseer) o básica (comprar), y comprobando si los contratos detrás de las básicas realmente exigen estándares abiertos (HL7 FHIR, SNOMED CT) y derechos de salida exigibles. Una buena respuesta distingue las pocas capacidades genuinamente estratégicas de las muchas que se compran de forma segura, es honesta sobre dónde la organización ya está bloqueada en los datos clínicos, y se compromete con estándares abiertos y derechos de salida en los contratos que más importan.

6. ¿Cómo sabremos cuándo nuestro modelo operativo necesita cambiar, y qué señales nos lo dirían —en lugar de reorganizar por moda o por la llegada de un nuevo líder? El tema enmarca el modelo operativo como un producto que evolucionas según la evidencia, no un diagrama enmarcado en la pared, así que esta pregunta pide al equipo que defina de antemano qué evidencia justificaría remodelarlo. Importa en la salud y la atención porque la reorganización es disruptiva y costosa —disuelve el conocimiento de dominio y de seguridad clínica ganado con esfuerzo— sin embargo el sector es propenso a la agitación estructural impulsada por ciclos políticos y nuevos nombramientos en lugar de por si el modelo actual realmente está estorbando. La tensión es entre estabilidad y adaptación: cambia el modelo con demasiada facilidad y nunca dejas que los equipos se asienten o acumulen experiencia en seguridad; cámbialo con demasiada poca frecuencia y las estructuras solidificadas estrangulan el flujo mucho después de que dejaron de encajar con el trabajo. Hazlo concreto eligiendo un pequeño conjunto de señales a observar —flujo de trabajo, tiempo hasta la decisión, retrabajo y salud del equipo— y acordando qué movimiento en ellas desencadenaría un rediseño deliberado frente a un ajuste menor. Una respuesta honesta se compromete con unos pocos indicadores adelantados, distingue el cambio guiado por evidencia del teatro de la reorganización, y es clara sobre quién es responsable de inspeccionar el modelo y actuar cuando las señales dicen que está impidiendo la entrega.

En la práctica: un ejemplo de salud y atención#

Un ICS que cubre cinco territorios tiene a cada fideicomiso construyendo sus propias herramientas de citas de cara al paciente. Los costes se duplican, las experiencias divergen, y ninguno comparte datos de forma limpia. El ICS rediseña su modelo operativo.

Define tres resultados (reducir los "no asistió", reducir los ingresos evitables, mejorar la equidad de acceso) y los flujos de valor detrás de ellos. Establece un pequeño equipo de plataforma que posee cuatro capacidades mínimas viables: una identidad/inicio de sesión compartido, una capa de interoperabilidad basada en FHIR, alojamiento común con líneas base de seguridad y seguridad clínica, y un sistema de diseño. Cada territorio mantiene un equipo alineado al flujo pero ahora construye sobre la plataforma en lugar de desde cero.

La financiación pasa de solicitudes anuales de proyecto a presupuestos permanentes de producto para cada flujo, liberados a través de compuertas de descubrimiento/alfa/beta. Un mapa RAPID publicado deja claro que los equipos territoriales deciden su propio diseño de servicio dentro de los límites de la plataforma y la seguridad clínica, mientras que la junta digital del ICS decide los estándares de la plataforma. En el plazo de un año, tres territorios comparten una capacidad de reserva, el diseño y la línea base de seguridad son consistentes, y las nuevas funcionalidades que antes tomaban un ciclo de proyecto se entregan en semanas —porque la plataforma absorbió el trabajo pesado indiferenciado.

Perspectivas sectoriales#

Un modelo operativo se dimensiona según la organización a la que sirve; las mismas capas —flujos de valor, capacidades, equipos, gobernanza, plataforma, proveedores— se trazan de forma muy diferente en una startup, una gran organización y un organismo gubernamental.

Startup#

En una pequeña empresa de salud digital, el modelo operativo es mayormente implícito y eso está bien: uno o dos equipos alineados al flujo, un fundador que posee la mayoría de los derechos de decisión, y ningún equipo de plataforma porque todavía no hay nada que plataformizar. La disciplina consiste en hacer explícitas pronto las pocas decisiones reales —construir frente a comprar para el almacén de datos clínicos, a qué estándares abiertos comprometerse— para que el atajo de hoy no se convierta en el bloqueo de mañana. El funcionamiento y el cambio están en las mismas manos, así que el riesgo es que mantener las luces encendidas para los primeros clientes prive de recursos a la hoja de ruta; una división simple y honesta del tiempo de ingeniería es el equivalente ligero de un presupuesto de funcionamiento protegido. Los proveedores se eligen por velocidad, pero una startup debería aun así rechazar el bloqueo de datos clínicos centrales, porque sus futuros compradores del NHS exigirán derechos de salida.

Pequeña empresa#

Un proveedor pequeño y establecido —una consulta de médico de cabecera, una farmacia comunitaria, una residencia de cuidados o un proveedor de atención domiciliaria, una clínica de un solo emplazamiento, o un pequeño proveedor de tecnología de salud que ya superó la etapa previa a los ingresos— tiene pacientes reales y operaciones continuas pero ningún equipo de plataforma, ninguna capacidad digital o de TI dedicada, y poco margen en efectivo o personal. Aquí el modelo operativo es en gran medida un conjunto de capacidades compradas cosidas entre sí, así que las decisiones determinantes son las de proveedor: insistir en estándares abiertos y derechos de salida en los sistemas clínicos que adquieres, porque cargas con los mismos deberes de interoperabilidad y seguridad clínica que un gran fideicomiso sin su poder de compra ni su experiencia interna. El funcionamiento y el cambio recaen sobre el mismo puñado de personas que también prestan atención, así que la disciplina honesta es proteger un poco de tiempo para mantener los sistemas seguros y actualizados en lugar de solo apagar incendios. Los derechos de decisión son simples —normalmente un socio o gestor-propietario decide— pero eso hace fácil aplazar las decisiones digitales indefinidamente, así que el valor está en nombrar las pocas que importan (qué historia clínica, a qué plataforma regional compartida unirse) y tomarlas deliberadamente. Cuando un ICS u organismo nacional ofrece una identidad compartida, interoperabilidad o plataforma de diseño, el mejor movimiento de la pequeña empresa suele ser construir sobre ella en lugar de reinventarla, tomando prestada la capacidad que no puede dotar de personal por sí misma.

Gran organización#

Un fideicomiso del NHS o un ICS es donde la forma de plataforma más federación demuestra su valor: organizaciones soberanas que deben sentirse como un solo servicio para un paciente. Los problemas difíciles son tan políticos como técnicos —mover el dinero de solicitudes de proyecto de tiempo limitado a presupuestos permanentes de producto, y publicar un mapa RACI/RAPID para que los equipos territoriales dejen de escalar decisiones que les pertenecen. Una gran empresa de tecnología de salud o farmacéutica tiene la fuerza de ingeniería de plataforma pero corre el riesgo de sobreconstruir una gran plataforma interna que se convierte en su propio cuello de botella; la prueba de la plataforma mínima viable —dos o más equipos demuestran necesitar la misma cosa— es el freno. A esta escala, los derechos de decisión y el flujo de financiación son el modelo operativo; la tecnología normalmente no es la restricción.

Gobierno#

Un organismo público nacional o local diseña modelos operativos que otras organizaciones deben habitar, así que sus elecciones sobre estándares y plataformas son efectivamente infraestructura nacional. Que NHS England o DHSC proporcionen una capa de identidad compartida, una espina dorsal de interoperabilidad o un sistema de diseño es el patrón de plataforma aplicado a escala de población, y sus controles de gasto y compuertas de aseguramiento escalonadas son la forma en que el dinero público rinde cuentas. El modo de fallo es un modelo centralizado que se convierte en un cuello de botella remoto, imponiendo una única solución para cada contexto local; el correctivo es plataformizar las capacidades verdaderamente comunes y federar el resto a fideicomisos y autoridades locales. La responsabilidad ante el Parlamento también significa que construir/comprar y la gestión de proveedores son asuntos de registro público, así que los estándares abiertos y los derechos de salida no son meramente prudentes sino esperados.

Modos de fallo comunes#

• Automatizar el organigrama. Diseñar equipos en torno a departamentos existentes en lugar de flujos de valor, de modo que el TOM atrinchera los silos. Antídoto: diseñar desde los resultados y los flujos de valor hacia abajo.
• La plataforma que se convierte en un cuello de botella. Un equipo de plataforma central con un alcance excesivo tras el que debe hacer cola cada solicitud. Antídoto: plataforma mínima viable, tratada como un producto con SLA.
• Financiación de proyecto para trabajo de producto. El dinero que caduca fuerza una agitación de disolver y reconstruir. Antídoto: financiación de producto persistente con compuertas escalonadas.
• Funcionamiento privado de recursos para alimentar el cambio. Infrafinanciar las operaciones de servicio en vivo hasta que los sistemas clínicos se degradan. Antídoto: financiar el funcionamiento y el cambio explícitamente y proteger el presupuesto de funcionamiento.
• Decisiones sin propietario. Nadie sabe quién decide, así que todo se escala. Antídoto: un RACI/RAPID publicado.
• Bloqueo por defecto. Datos clínicos centrales atrapados en un sistema propietario de proveedor sin salida. Antídoto: estándares abiertos y derechos de salida en cada contrato estratégico.

Modelo de madurez#

Lista de verificación#

• El modelo operativo está diseñado desde los resultados y los flujos de valor, no desde la jerarquía existente.
• Las capacidades compartidas se proporcionan como una plataforma mínima viable, con equipos de flujo construyendo encima.
• Los equipos de producto están financiados de forma persistente y alineados con flujos de valor.
• El control del gasto está escalonado (compuertas de descubrimiento/alfa/beta/en vivo) y es proporcionado al riesgo y al valor.
• Los derechos de decisión están documentados (RACI o RAPID) y publicados.
• El funcionamiento y el cambio están financiados explícitamente, con el presupuesto de funcionamiento protegido.
• Los tipos de equipo (alineado al flujo, plataforma, habilitador, subsistema complicado) se comprenden y se usan.
• Construir/comprar es una elección deliberada por capacidad; los datos clínicos centrales evitan el bloqueo.
• Los contratos exigen estándares abiertos (p. ej. HL7 FHIR, SNOMED CT) y derechos de salida.

Fuentes clave#

• Matthew Skelton y Manuel Pais — Team Topologies (equipos alineados al flujo, de plataforma, habilitadores, de subsistema complicado; plataforma mínima viable).
• Manual de Servicio de GOV.UK — controles de gasto y aseguramiento escalonado (descubrimiento/alfa/beta/en vivo); Government Digital Service.
• Manual de servicio digital del NHS — Estándar de servicio del NHS (service-manual.nhs.uk).
• AXELOS — Management of Portfolios (MoP) y Managing Successful Programmes (MSP) para gobernanza de carteras y programas.
• Bain & Company — marco de derechos de decisión RAPID; y el modelo de asignación de responsabilidad RACI.
• John Doerr — Measure What Matters (OKR) para la definición de resultados.

Referencias#

1. Operating model — Wikipedia — https://en.wikipedia.org/wiki/Operating_model
2. Value stream — Wikipedia — https://en.wikipedia.org/wiki/Value_stream
3. Objectives and key results (OKRs) — Wikipedia — https://en.wikipedia.org/wiki/Objectives_and_key_results
4. Responsibility assignment matrix (RACI) — Wikipedia — https://en.wikipedia.org/wiki/Responsibility_assignment_matrix
5. Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
6. Government Digital Service — Wikipedia — https://en.wikipedia.org/wiki/Government_Digital_Service
7. Fast Healthcare Interoperability Resources (HL7 FHIR) — Wikipedia — https://en.wikipedia.org/wiki/Fast_Healthcare_Interoperability_Resources
8. SNOMED CT — Wikipedia — https://en.wikipedia.org/wiki/SNOMED_CT
9. Team Topologies: Organizing Business and Technology Teams for Fast Flow — Matthew Skelton & Manuel Pais, IT Revolution — https://teamtopologies.com/book
10. Spend controls and staged assurance (discovery/alpha/beta/live) — GOV.UK Service Manual, Government Digital Service — https://www.gov.uk/service-manual/agile-delivery
11. NHS service standard — NHS digital service manual, NHS England — https://service-manual.nhs.uk/standards-and-technology/service-standard
12. Managing Successful Programmes (MSP) and Management of Portfolios (MoP) — AXELOS/PeopleCert — https://www.axelos.com/
13. Measure What Matters (OKRs) — John Doerr — https://www.whatmatters.com/the-book