Tema 4.1 — Plataformas y servicios compartidos

En la salud y la atención, una plataforma compartida no es una conveniencia de ahorro de costes sino una forma de hacer que la seguridad, la equidad, y la confianza sean repetibles —para que cada equipo las herede en lugar de reinventarlas, a menudo mal.

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

Cuando operas la entrega digital a través de un sistema de salud y atención, rápidamente notas las mismas capacidades siendo reconstruidas una y otra vez. Cada servicio quiere autenticar a un paciente, buscar un registro demográfico, enviar una notificación, registrar un rastro de auditoría, o verificar el rol de un clínico. Dejado solo, cada equipo construye su propia versión. Terminas con una docena de pantallas de inicio de sesión, una docena de formas de manejar la identidad de un paciente, una docena de registros de auditoría de calidad variable —y una docena de lugares donde puede esconderse un defecto de seguridad.

Esta duplicación es costosa, pero el problema más profundo es que es peligrosa e inequitativa. En la salud y la atención, la fontanería lleva riesgo clínico. Si la lógica de coincidencia de pacientes de un equipo es más débil que la de otro, a un paciente se le puede dar el registro equivocado. Si la accesibilidad de un servicio es más pobre, algunas personas quedan silenciosamente excluidas. Si los rastros de auditoría difieren, una investigación de gobernanza de la información se estanca. Una plataforma compartida te permite construir una capacidad una vez, a un alto estándar, con el trabajo de seguridad clínica y accesibilidad hecho apropiadamente, y luego dejar que muchos equipos hereden ese estándar en lugar de que cada uno apueste por acertar solo.

Las plataformas también dan forma al ritmo de todo el sistema. Una buena plataforma significa que un nuevo servicio puede alcanzar a los pacientes en semanas en lugar de años, porque las partes difíciles y genéricas ya existen. Una plataforma mala o ausente significa que cada equipo carga con todo el peso de la infraestructura, y la entrega se ralentiza a la velocidad del equipo con menos recursos. En un sector bajo presión financiera y de fuerza laboral sostenida, donde cientos de organizaciones necesitan las mismas capacidades nacionales y locales, acertar con las plataformas es una de las decisiones de mayor apalancamiento que tomarás. Este tema trata sobre cómo construirlas y operarlas bien —como productos con usuarios reales, no como infraestructura obligatoria que nadie ama.

Conceptos clave#

Una plataforma, en este contexto, es un conjunto de capacidades sobre las que otros equipos construyen en lugar de construirlas ellos mismos. El encuadre moderno más útil es que una plataforma es un producto con usuarios internos. Sus clientes son tus propios desarrolladores, equipos de entrega, y organizaciones asociadas, y su éxito se mide de la forma en que se mide el de cualquier producto: por adopción, por la experiencia de las personas que lo usan, y por los resultados que habilita.

Varias ideas relacionadas se sitúan debajo de esto. Los servicios compartidos son el patrón organizacional más antiguo de proporcionar una capacidad una vez para muchas partes de una organización en lugar de duplicarla en cada una. La infraestructura pública digital extiende esto al nivel de toda una sociedad —los bloques de construcción compartidos, reutilizables, interoperables (identidad, pagos, intercambio de datos) sobre los que se construyen los servicios públicos y privados. "El gobierno como plataforma", una frase acuñada por Tim O'Reilly y adoptada por equipos de gobierno digital en todo el mundo, aplica la misma lógica al estado: el gobierno proporciona componentes comunes, y los departamentos componen servicios a partir de ellos en lugar de que cada uno construya toda la pila.

Técnicamente, las plataformas a menudo exponen sus capacidades a través de una interfaz de programación de aplicaciones (API) —un contrato definido que permite que un sistema use la capacidad de otro sin conocer sus mecanismos internos. Frecuentemente se basan en modelos de plataforma como servicio (PaaS) en la nube, y las plataformas nacionales compartidas típicamente dependen de la multiarrendamiento, donde una única instancia sirve a muchas organizaciones mientras mantiene separados sus datos y configuración.

Tres conceptos gobiernan si una plataforma ayuda o daña. El primero es la carga cognitiva: una buena plataforma reduce la cantidad que un equipo de entrega debe mantener en su cabeza, para que el equipo pueda concentrarse en el problema clínico o de atención que existe para resolver. El segundo es el "camino pavimentado" o "camino dorado" —una forma predeterminada, bien soportada y con opinión de hacer una tarea común que es más fácil de seguir que de evitar, ofrecida a través de autoservicio en lugar de guardianía. El tercero es evitar el bloqueo de proveedor, que es por eso que las plataformas deberían construirse sobre estándares abiertos para que las organizaciones puedan moverse entre proveedores sin costes de cambio prohibitivos.

En la salud específicamente, los servicios compartidos nacionales ya son parte del panorama. Programas históricos como NHS Connecting for Health establecieron el NHS Spine, un conjunto de servicios nacionales que llevan datos centrales como el Personal Demographics Service. Los equivalentes modernos incluyen API nacionales, NHS login para autenticación de ciudadanos, y NHS Notify para mensajería —capacidades ofrecidas para que los servicios individuales no necesiten reconstruirlas. Donde una plataforma proporciona una forma común de probar quién es alguien, a menudo expone el inicio de sesión único para que un clínico se autentique una vez en lugar de repetidamente. Este tema trata sobre cómo construir y operar tales plataformas; los detalles de quién eres y qué puedes hacer pertenecen al Tema 4.2 — Gestión de identidad y accesos, y los estándares que permiten a los sistemas intercambiar datos pertenecen al Tema 4.3 — Interoperabilidad y estándares de datos.

Buenas prácticas#

1. Tratar la plataforma como un producto, no un proyecto. Una plataforma tiene una hoja de ruta, un gestor de producto, financiación continua, y usuarios cuya satisfacción mides —no una fecha de finalización y un traspaso. Los proyectos terminan y se degradan; las plataformas deben operarse indefinidamente porque los equipos llegan a depender de ellas. Financia y dota de personal en consecuencia, y consulta el Tema 5.0 — Trabajo liderado por producto para la disciplina operativa que esto implica.

2. Comenzar con la plataforma mínima viable. Construye el conjunto más pequeño de capacidades compartidas que genuinamente alivian a los equipos, y añade más solo cuando la demanda real y el dolor real lo justifiquen. Esta idea de "plataforma mínima viable", introducida en el Tema 1.1 — El modelo operativo, protege contra el fallo más común: una plataforma central ambiciosa que intenta hacer todo, llega tarde, y no se ajusta a nadie. Deja que la plataforma crezca a partir de evidencia de uso, no de aspiración arquitectónica.

3. Hacer del camino pavimentado el camino fácil. Una plataforma se gana la adopción haciendo que el camino soportado sea más rápido y simple que construir el propio —a través de incorporación de autoservicio, documentación clara, entornos de prueba, y valores predeterminados sensatos con seguridad clínica y accesibilidad incorporadas. Si usar la plataforma es más lento o más doloroso que evitarla, los equipos la evitarán, y habrás gastado dinero para crear un cuello de botella. Diseña para la primera hora del desarrollador y su peor día.

4. Medir el éxito por adopción y experiencia del usuario, no por existencia. Las métricas correctas son cuántos equipos usan la plataforma voluntariamente, cuánto tiempo toma la incorporación, con qué frecuencia está disponible la plataforma, y cómo califican sus usuarios la experiencia. Las métricas vanidosas como el número de servicios desplegados no te dicen nada sobre si los equipos están siendo ayudados. Instrumenta la plataforma, realiza investigación regular con los equipos que construyen sobre ella, y trata una curva de adopción cayendo o estancada como un problema de producto a arreglar, no un problema de cumplimiento a hacer cumplir.

5. Construir sobre estándares abiertos y mantener barata la salida. Prefiere estándares e interfaces abiertos y ampliamente adoptados para que ni tú ni los equipos en tu plataforma queden atrapados. Documenta cómo un equipo se iría, y asegúrate de que pudiera hacerlo. Paradójicamente, facilitar la salida es lo que hace que los equipos se sientan cómodos llegando, y mantiene honesta la plataforma porque debe ganarse su lugar en lugar de depender de la cautividad. Esto reduce directamente el bloqueo de proveedor en el patrimonio más amplio discutido en el Tema 4.0 — Arquitectura técnica, nube y sistemas heredados.

6. Ser explícito sobre quién paga y quién decide. Una plataforma compartida necesita un modelo de financiación y un modelo de gobernanza acordados de antemano: si se financia centralmente, se cobra de vuelta a los usuarios, o es un híbrido, y cómo se prioriza su hoja de ruta entre inquilinos en competencia. La ambigüedad aquí es lo que convierte a las plataformas en campos de batalla políticos. Publica el modelo, da a los usuarios una voz real en la hoja de ruta, y revísalo a medida que crece la plataforma.

7. Operar el equipo de plataforma con responsabilidades y límites claros. Organízate en torno a un equipo de plataforma dedicado cuyo trabajo es habilitar a los equipos de entrega alineados al flujo a través del autoservicio, como se describe en los patrones de Team Topologies en el Tema 7.0 — Estructuras de equipo, roles y responsabilidades. Mantén explícita la interfaz entre la plataforma y los consumidores —qué promete la plataforma, qué no, y cómo obtener soporte— para que la plataforma habilite en lugar de hacer de guardián.

8. Diseñar para el multiarrendamiento, el aislamiento, y la seguridad desde el principio. Si muchas organizaciones compartirán una plataforma, la separación de sus datos, configuración, y dominios de fallo es un requisito fundacional, no una funcionalidad posterior. En la salud y la atención esto también es un requisito de gobernanza de la información y seguridad clínica: el incidente de un inquilino no debe exponer o poner en peligro a los pacientes de otro. Incorpora aislamiento, observabilidad por inquilino, y un caso de seguridad clínica para la plataforma misma bajo DCB0129.

Preguntas para debatir con tu equipo#

1. ¿Cuál es la plataforma más delgada que genuinamente aliviaría a nuestros equipos, y qué estamos tentados a construir que no deberíamos? Es fácil diseñar una plataforma expansiva en una pizarra y difícil enviar una que los equipos amen. Comienza desde el dolor real y repetido que sienten hoy tus equipos de entrega —la capacidad que tres o más equipos están cada uno reconstruyendo— y resiste añadir cualquier cosa que solo un equipo necesite o que nadie haya pedido todavía. Pregunta qué capacidades son genuinamente comunes frente a cuáles meramente parecen similares desde lejos pero difieren en los detalles que importan clínicamente. Considera el coste de equivocarse: una capacidad compartida prematura que los equipos deben evadir es peor que ninguna plataforma en absoluto. Acuerda una línea explícita entre lo que la plataforma poseerá ahora y lo que deliberadamente aplazará. Revisita esa línea según un calendario, moviendo elementos a través solo cuando se demuestren la demanda y el dolor. La disciplina es decir no a buenas ideas que todavía no se han ganado su lugar.

2. ¿Cómo financiaremos la plataforma y decidiremos su hoja de ruta cuando los inquilinos no estén de acuerdo? Una plataforma sirve a muchos equipos con prioridades en competencia, y en el momento en que dos inquilinos importantes quieren cosas incompatibles, se pone a prueba tu gobernanza. Decide ahora si la plataforma se financia centralmente, se cobra de vuelta a los usuarios, o es híbrida, y sé honesto sobre los incentivos que crea cada modelo: el cobro de vuelta puede suprimir la adopción, mientras que la financiación central puede desconectar la plataforma de la necesidad del usuario. Decide quién sostiene la hoja de ruta, cómo la influyen los inquilinos, y cómo arbitras entre la necesidad urgente de una gran organización y la necesidad básica de una pequeña. Considera la equidad explícitamente, porque un modelo de cobro de vuelta puede excluir a organizaciones más pequeñas o más pobres de las mismas capacidades de seguridad compartidas que más necesitan. Acuerda cómo manejarás a un inquilino que quiere financiar una funcionalidad que los demás no quieren. Escribe el modelo y publícalo, para que las decisiones se sientan como gobernanza en lugar de favoritismo. Luego comprométete a revisitarlo a medida que crecen la plataforma y su base de usuarios.

3. ¿Cómo sabremos que la plataforma es amada en lugar de meramente obligatoria, y qué haremos si no lo es? Una plataforma puede ser técnicamente sólida, oficialmente requerida, y silenciosamente odiada —y una plataforma obligatoria pero no amada acumula soluciones alternativas, sistemas en la sombra, y resentimiento. Decide de antemano qué señales te dicen la verdad: adopción voluntaria donde los equipos tienen elección, tiempo hasta el primer éxito para un nuevo equipo, disponibilidad e historial de incidentes, y retroalimentación directa de los desarrolladores que la usan. Habla sobre cómo recopilarás retroalimentación honesta cuando también tienes poder sobre tus usuarios, ya que las personas son reacias a criticar una plataforma que están obligadas a usar. Acuerda cómo se ve una curva de adopción saludable y qué umbral desencadenaría una reconsideración seria. Decide si alguna vez estarías dispuesto a retirar o reemplazar la plataforma si la evidencia lo exigiera. Estar dispuesto a escuchar que tu plataforma no está funcionando es lo que la mantiene funcionando. La alternativa es descubrir la verdad solo cuando un servicio importante te evade.

4. ¿Cómo mantendremos barata la salida, y un equipo en nuestra plataforma realmente podría irse si lo necesitara? Es fácil afirmar que estás construido sobre estándares abiertos y bastante diferente probar que un equipo podría alejarse sin una reescritura prohibitiva. Habla honestamente sobre dónde se está infiltrando el bloqueo —una interfaz propietaria, un formato de datos no documentado, una dependencia nacional sin alternativa— y si el coste de irse está aumentando silenciosamente con el tiempo. Decide quién es responsable de documentar y probar periódicamente una vía de salida, en lugar de asumir que existe una. Considera que en la salud y la atención el riesgo de bloqueo se compone: una plataforma nacional construida sobre la cautividad puede atrapar a todo un sistema durante una generación, y los equipos menos capaces de absorber costes de cambio suelen ser los proveedores más pequeños. Una respuesta honesta nombra las dependencias específicas que tendrías dificultad para deshacer, describe una salida concreta para al menos un inquilino real, y trata la portabilidad como una funcionalidad que mantienes en lugar de un eslogan que repites. Recuerda que facilitar la salida a menudo es lo que hace que los equipos se sientan cómodos llegando.

5. ¿Tiene la plataforma su propio caso de seguridad clínica, y cómo evitamos que el fallo de un inquilino dañe a los pacientes de otro? Cuando muchas organizaciones comparten una plataforma, su fontanería lleva riesgo clínico en nombre de cada servicio construido sobre ella, así que un defecto en la coincidencia de pacientes o una fuga entre inquilinos no es el problema de un equipo sino de todos. Decide si la plataforma tiene su propio caso de seguridad DCB0129 en el que los equipos consumidores puedan genuinamente confiar, o si cada servicio está silenciosamente reevaluando el mismo riesgo compartido. Discute cómo aíslas los datos, la configuración, y los dominios de fallo de los inquilinos, y cómo sabrías si ese aislamiento se violara —la observabilidad por inquilino es la diferencia entre contener un incidente y descubrirlo tarde. Considera también las consecuencias de gobernanza de la información: una investigación sobre un inquilino no debe requerir exponer los registros de otro. Una respuesta honesta puede señalar un caso de seguridad mantenido, un límite de aislamiento probado, y una cuenta clara de qué promete la plataforma sobre la seguridad frente a qué sigue siendo responsabilidad de cada servicio. Tratar la seguridad y el aislamiento como fundacionales, no como funcionalidades posteriores, es lo que permite a los equipos heredar aseguramiento en lugar de apostar por él.

6. ¿Dónde está la línea entre el equipo de plataforma y los equipos a los que sirve, y cómo evitamos que la plataforma se convierta en un cuello de botella? Una plataforma compartida puede acelerar a cada equipo o ralentizarlos a todos a la velocidad de una cola central, y la diferencia radica en cuán nítidamente has trazado la interfaz entre la plataforma y los consumidores. Decide qué posee y promete la plataforma, qué explícitamente no, y cómo un equipo obtiene soporte sin esperar un ticket para trabajo rutinario. Habla sobre el autoservicio como el valor predeterminado: si la incorporación, el aprovisionamiento, o un cambio común todos requieren que el equipo de plataforma actúe manualmente, has construido una puerta en lugar de un camino pavimentado. Considera el trato de carga cognitiva en el corazón de una buena plataforma —debería reducir lo que un equipo de entrega debe mantener en su cabeza para que puedan concentrarse en el problema clínico, no añadir una nueva capa que negociar. Una respuesta honesta nombra las tareas que todavía se canalizan a través del equipo de plataforma como un cuello de botella, establece una dirección para hacerlas de autoservicio, y es franca sobre dónde la plataforma está habilitando frente a dónde está haciendo de guardián.

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

Un Sistema de Atención Integrada (ICS) que cubre varios fideicomisos del NHS, proveedores comunitarios, y el servicio de atención social para adultos de un consejo del condado sigue chocando contra el mismo muro. Cada nuevo servicio digital —una sala virtual, un formulario de autoderivación para fisioterapia comunitaria, una herramienta de supervisión de residencias de cuidados— pasa sus primeros tres meses reconstruyendo los mismos fundamentos: probar quién es el paciente, verificar el rol del profesional, enviar recordatorios por SMS, y escribir un rastro de auditoría. La coincidencia de pacientes del equipo de sala virtual resulta ser más débil que la del equipo de fisioterapia, y ocurre un cuasi-incidente cuando se envía un recordatorio a la persona equivocada. El liderazgo digital del ICS reconoce el patrón: están pagando muchas veces por capacidades que deberían existir una vez, y la variación es un riesgo de seguridad.

En lugar de encargar una gran plataforma de ICS, comienzan delgados. Establecen un único servicio compartido que hace una cosa bien: envuelve NHS login y el Personal Demographics Service nacional detrás de una API limpia y documentada con un entorno de prueba, para que cualquier equipo pueda verificar la identidad de un ciudadano y recuperar un registro demográfico confirmado a través de un camino soportado único. Un pequeño equipo de plataforma de cinco lo trata como un producto. Publican una guía de camino pavimentado, ofrecen incorporación de autoservicio, y establecen un objetivo de que un nuevo equipo debería hacer su primera llamada exitosa dentro de un día. Fundamentalmente, no lo hacen obligatorio. Lo hacen la opción más fácil y dejan que el equipo de sala virtual sea el primer adoptante voluntario.

El modelo de financiación se acuerda abiertamente: el ICS financia centralmente el núcleo de la plataforma durante sus primeros dos años para que la adopción no se suprima por el cobro de vuelta, con una revisión a los dieciocho meses. Un grupo de múltiples proveedores, incluyendo el consejo, sostiene la hoja de ruta y se reúne mensualmente. Cuando el equipo de fisioterapia pide a continuación una capacidad de notificaciones, el equipo de plataforma añade un envoltorio delgado alrededor de NHS Notify en lugar de construir mensajería desde cero —construir una vez, usar muchas. En un año, seis equipos han adoptado el servicio de identidad voluntariamente, la incorporación ha caído de meses a días, y el equipo de plataforma publica abiertamente sus cifras de disponibilidad y adopción. Cuando el sistema a medida de un fideicomiso evade la plataforma, el equipo lo trata como investigación en lugar de desafío, aprende la fricción que impulsó la decisión, y la arregla. La plataforma crece porque los equipos la eligen, y el ICS hereda una única forma bien probada y accesible de hacer las cosas comunes y riesgosas.

Perspectivas sectoriales#

Startup#

Una startup de tecnología de salud rara vez construye plataformas para otros; construye sobre ellas. Tu influencia viene de consumir plataformas nacionales y de nube —NHS login, API nacionales, los servicios gestionados de un proveedor de nube— para que tu pequeño equipo gaste su energía en el problema clínico, no en reinventar la identidad o la mensajería. Aun así vigila el bloqueo: elige estándares abiertos y mantén tus datos portátiles, porque la capacidad que alquilas barata hoy puede convertirse en la dependencia que te limita mañana. Internamente, mantén tu propia "plataforma" delgada hasta el punto de casi-invisibilidad; un equipo de dos personas no necesita una abstracción de camino dorado, necesita entregar. La disciplina es saber cuándo has crecido lo suficiente como para que valga la pena extraer una capacidad interna compartida.

Pequeña empresa#

Un proveedor pequeño y establecido —una consulta de médico de cabecera, una farmacia comunitaria, una residencia de cuidados, o una clínica de un solo emplazamiento— casi siempre es un consumidor de plataforma con poca o ninguna capacidad digital propia, así que las plataformas de las que depende efectivamente establecen su piso de seguridad y equidad. Tu tarea práctica es elegir servicios compartidos soportados sobre construcciones a medida que no puedes dotar de personal ni mantener, favoreciendo capacidades nacionales como NHS login, la búsqueda demográfica, y NHS Notify que ya llevan trabajo de accesibilidad y seguridad clínica que nunca podrías financiar solo. Insiste en una incorporación de autoservicio genuina y documentación clara, porque no tienes un equipo de plataforma al que escalar y no puedes permitirte un largo proyecto de integración. Vigila de cerca el modelo de financiación: una plataforma de cobro de vuelta puede excluir a un proveedor pequeño de las mismas capacidades de seguridad que más necesita, así que presiona por un acceso equitativo y plantéalo en cualquier gobernanza de hoja de ruta que puedas alcanzar. También vigila la salida, ya que un bloqueo de proveedor propietario es más difícil de escapar cuando no tienes personal técnico interno para migrarte. La ganancia es que una buena plataforma compartida te permite heredar estándares que no podrías construir, cumpliendo los mismos deberes que las grandes organizaciones sin sus recursos.

Gran organización#

Un gran fideicomiso u organismo nacional tiene la escala para justificar plataformas reales y la burocracia para arruinarlas. El riesgo es un equipo de plataforma central que se convierte en una torre de marfil —arquitectónicamente elegante, lento para responder, y desconectado de los equipos de entrega a los que se supone que sirve. Contrarresta esto financiando las plataformas como productos de larga duración con sus propias hojas de ruta e investigación de usuarios, y midiéndolas por adopción y experiencia del desarrollador en lugar de por cumplimiento del mandato. El multiarrendamiento, el aislamiento, y un caso de seguridad clínica para la plataforma misma se vuelven esenciales a esta escala. El premio es enorme: una capacidad construida una vez a un alto estándar y heredada por docenas de servicios, elevando el piso para toda la organización.

Gobierno#

A nivel nacional y de sistema, el encuadre es infraestructura pública digital y gobierno como plataforma: construir componentes comunes —identidad, notificaciones, búsqueda demográfica, intercambio de datos— que cientos de organizaciones componen en servicios. Las consecuencias de la apertura son más altas aquí, porque una plataforma nacional construida sobre el bloqueo propietario puede atrapar a todo un sistema de salud durante una generación. La gobernanza y la financiación deben trabajarse abiertamente, con influencia real para las organizaciones más pequeñas y pobres que las plataformas compartidas existen en parte para proteger. La tentación de exigir es más fuerte y más peligrosa a este nivel; una plataforma nacional que es requerida pero no amada engendra sistemas en la sombra en todo el país. Gánate la adopción a través de la calidad y el soporte, y trata cada solución alternativa como una señal para mejorar.

Modos de fallo comunes#

• El cuello de botella. Cada equipo debe esperar al equipo de plataforma central para hacer cualquier cosa, así que la plataforma ralentiza la entrega en lugar de acelerarla. La cura es el autoservicio: los equipos deberían poder incorporarse y actuar sin un ticket.
• La torre de marfil. La plataforma es diseñada por personas alejadas de la entrega, es técnicamente admirable, y no se ajusta a las necesidades de ningún equipo real. La cura es operar la plataforma como un producto con investigación de usuarios continua.
• Obligatoria pero no amada. La plataforma es requerida por política pero evadida en la práctica, acumulando sistemas en la sombra y resentimiento. La cura es ganarse la adopción a través de la calidad y escuchar cuando los equipos te evaden.
• La plataforma de todo. Un alcance excesivamente ambicioso significa que la plataforma llega tarde, hace demasiado, y no hace bien ninguna de esas cosas. La cura es la plataforma mínima viable, cultivada a partir de evidencia de demanda.
• Bloqueo sigiloso. La plataforma silenciosamente ata a los equipos a un proveedor o interfaz propietario, y el coste de irse se vuelve prohibitivo. La cura son estándares abiertos y una vía de salida documentada y probada.
• Ambigüedad de financiación. Nadie acordó quién paga o quién decide, así que la plataforma se muere de hambre o se convierte en un campo de batalla político. La cura es un modelo explícito y publicado de financiación y gobernanza.
• Seguridad como idea de último momento. La plataforma no tiene su propio caso de seguridad clínica, así que cada servicio consumidor hereda riesgo no evaluado. La cura es tratar el caso de seguridad DCB0129 de la plataforma como fundacional.

Modelo de madurez#

Lista de verificación#

• La plataforma tiene un gestor de producto nombrado, una hoja de ruta, y financiación continua (no de proyecto).
• Comenzaste desde la plataforma mínima viable y puedes nombrar qué aplazaste deliberadamente.
• El camino soportado es genuinamente más rápido y fácil que los equipos construyendo el suyo propio.
• Los nuevos equipos pueden incorporarse a través de autoservicio, con un entorno de prueba y documentación clara.
• Mides la adopción, el tiempo hasta el primer éxito, la disponibilidad, y la experiencia del desarrollador.
• El modelo de financiación (central, cobro de vuelta, o híbrido) está acordado y publicado.
• La gobernanza de la hoja de ruta da a los inquilinos, incluyendo organizaciones más pequeñas, una voz real.
• La plataforma está construida sobre estándares abiertos y existe una vía de salida documentada.
• El aislamiento de datos y fallos multiarrendatario está diseñado, no añadido.
• La plataforma tiene su propio caso de seguridad clínica (DCB0129) en el que pueden confiar los equipos consumidores.
• Tratas a los equipos que evaden la plataforma como investigación, no desafío.

Fuentes clave#

• Manual de Servicio de GOV.UK y los escritos del Government Digital Service sobre el gobierno como plataforma y componentes comunes.
• Matthew Skelton y Manuel Pais, Team Topologies — equipos de plataforma, plataforma mínima viable, y carga cognitiva.
• Orientación de desarrollador y API de NHS England (NHS login, NHS Notify, API nacionales, y los servicios Spine).
• Estándares de gestión de riesgo clínico DCB0129 y DCB0160 para sistemas de TI de salud.
• Los escritos del Banco Mundial y las Naciones Unidas sobre infraestructura pública digital y bloques de construcción públicos reutilizables.
• Tim O'Reilly, "Government as a Platform", en Open Government (O'Reilly Media).

Referencias#

1. Digital public infrastructure — Wikipedia — https://en.wikipedia.org/wiki/Digital_public_infrastructure
2. Shared services — Wikipedia — https://en.wikipedia.org/wiki/Shared_services
3. API (application programming interface) — Wikipedia — https://en.wikipedia.org/wiki/API
4. Platform as a service — Wikipedia — https://en.wikipedia.org/wiki/Platform_as_a_service
5. Multitenancy — Wikipedia — https://en.wikipedia.org/wiki/Multitenancy
6. Cognitive load — Wikipedia — https://en.wikipedia.org/wiki/Cognitive_load
7. Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
8. Open standard — Wikipedia — https://en.wikipedia.org/wiki/Open_standard
9. NHS Connecting for Health (including the NHS Spine and Personal Demographics Service) — Wikipedia — https://en.wikipedia.org/wiki/NHS_Connecting_for_Health
10. Single sign-on — Wikipedia — https://en.wikipedia.org/wiki/Single_sign-on
11. Team Topologies: Organizing Business and Technology Teams for Fast Flow — Matthew Skelton and Manuel Pais (IT Revolution Press) — https://teamtopologies.com/book
12. Government as a Platform — Tim O'Reilly, in Open Government (O'Reilly Media) — https://www.oreilly.com/library/view/open-government/9781449381936/ch02.html
13. GOV.UK Service Manual — Government Digital Service — https://www.gov.uk/service-manual
14. NHS login and NHS England developer/API guidance — NHS England — https://digital.nhs.uk/services/nhs-login
15. Clinical risk management: its application in the manufacture of health IT systems (DCB0129) — NHS England — https://digital.nhs.uk/services/clinical-safety/documentation