Tema 3.5 — Ciclos de vida de entrega

En una frase: Un ciclo de vida de entrega es la secuencia de fases y puertas de decisión —Descubrimiento, Alfa, Beta, En vivo, y eventual retiro— a través de las cuales se mueve un servicio digital, con la seguridad clínica, la gobernanza de la información, y el aseguramiento entretejidos en cada fase en lugar de añadidos al final.

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

Un ciclo de vida es cómo una organización convierte una idea en un servicio seguro y en vivo y, eventualmente, lo retira responsablemente. En la salud y la atención, cada transición conlleva peso estatutario y clínico: no puedes desplegar un sistema que toque la atención del paciente sin un caso de seguridad clínica, y no puedes procesar datos confidenciales del paciente sin una base legal y una evaluación de impacto en la protección de datos (DPIA) completada. Un ciclo de vida que trata estos como papeleo de fin de proyecto produce servicios que están tarde, son inseguros, o ambos.

Las consecuencias son asimétricas. Una aplicación de consumo que lanza un error molesta a los usuarios; un registro de atención compartido que lanza un error puede mostrar a un clínico las alergias del paciente equivocado. Por eso el NHS incorpora el modelo de fases de GOV.UK y los estándares de gestión de riesgo clínico DCB0129 y DCB0160 en el mismo ciclo de vida. Acertar con el ciclo de vida no es un detalle de gobernanza —es el mecanismo mediante el cual la seguridad, la equidad, y el valor por el dinero público realmente se entregan en lugar de meramente prometerse.

Los líderes también necesitan el ciclo de vida porque hace el progreso legible. Las fases y puertas nombradas permiten a una junta directiva ver dónde está un servicio, qué evidencia existe, y qué decisión vence —reemplazando la niebla de "está casi terminado" con un compromiso escalonado y defendible de dinero público.

Conceptos clave#

El modelo de fases: Descubrimiento → Alfa → Beta → En vivo. Los estándares de servicio del NHS y GOV.UK definen cuatro fases. El Descubrimiento (véase el Tema 3.4 — Fases de descubrimiento) entiende el problema. El Alfa construye prototipos desechables para probar si una solución podría funcionar y para reducir los supuestos más riesgosos. La Beta construye el servicio real, primero privado y luego público, sobre infraestructura de producción, iterando con usuarios reales a escala creciente. El En vivo opera el servicio en funcionamiento continuo, todavía iterando, hasta que se retira. Las fases son una rampa de reducción de riesgo: cada una compromete más dinero y expone a más usuarios, justificado por evidencia de la anterior.

Iteración continua, no una cinta transportadora. Las fases no son una cascada de una sola dirección. Un servicio en beta puede volver al alfa para una funcionalidad difícil; un servicio en vivo itera continuamente. El valor del modelo está en sus puertas, no en una promesa de que el trabajo fluye en una dirección.

Ágil, cascada, e híbrido. La cascada fija el alcance de antemano y procede en secuencia —adecuada solo donde los requisitos son genuinamente estables y conocibles (una migración de centro de datos, un cambio regulatorio obligatorio). El ágil entrega en incrementos pequeños, inspeccionando y adaptando —adecuado para la incertidumbre de los servicios orientados al usuario. El híbrido es la realidad honesta de la mayoría de los grandes programas de salud: equipos de producto ágiles operando dentro de un envoltorio de hitos y financiación que exigen la organización y sus reguladores. Ajusta el método a la incertidumbre, no a la moda.

Evaluaciones de servicio y puertas de estándares. En las transiciones entre fases —especialmente alfa-a-beta y antes del lanzamiento público— los servicios del NHS y GOV.UK enfrentan una evaluación de servicio: un panel independiente que pone a prueba el trabajo frente a los puntos del Estándar de Servicio (necesidad del usuario, accesibilidad, seguridad, fiabilidad, equipo, elecciones tecnológicas). Aprobar es la puerta para gastar más y exponer a más usuarios. La evaluación es una revisión por pares basada en evidencia, no un sello de goma.

La seguridad clínica y la gobernanza de la información como hilos del ciclo de vida. El DCB0129 (para el fabricante/proveedor) y el DCB0160 (para la organización de salud o atención que despliega) exigen un sistema de gestión de riesgo clínico, un registro de peligros, y un informe de caso de seguridad clínica aprobado por un Oficial de Seguridad Clínica (CSO) nombrado y formado. La gobernanza de la información exige una base legal, una DPIA, y adherencia a los principios Caldicott. Ambos son hilos que atraviesan el descubrimiento, el alfa, la beta, y el en vivo —no puertas al final.

Baja de servicio. Un ciclo de vida tiene un final. Retirar un servicio de forma segura —migrar o archivar datos bajo la ley de retención, redirigir usuarios, notificar a los clínicos, y preservar registros— es una fase por derecho propio, y una de las más descuidadas.

Buenas prácticas#

1. Usar las fases como puertas de reducción de riesgo, no hitos de calendario. Deja que la decisión de cada fase sea "¿hay suficiente evidencia para justificar comprometer el siguiente tramo de dinero y usuarios?" Una fase que termina porque llegó la fecha, en lugar de porque llegó la evidencia, se ha saltado el punto de la puerta.

2. Entretejer la seguridad clínica desde el alfa, no antes del En vivo. Nombra a un Oficial de Seguridad Clínica y abre el registro de peligros tan pronto como exista una forma de solución. Los peligros identificados en el alfa son baratos de diseñar fuera; los peligros encontrados en la puesta en marcha son una crisis que bloquea el lanzamiento. El caso de seguridad madura junto con el servicio, así que la aprobación de DCB0129/0160 es un resumen de trabajo ya hecho, no una carrera de última hora.

3. Comenzar el trabajo de DPIA y GI en el descubrimiento y mantenerlo vivo. Los flujos de datos, la base legal, y las consideraciones Caldicott dan forma a la arquitectura, así que sácalos a la luz mientras la arquitectura todavía es blanda. Una DPIA escrita después de construir es un ejercicio de documentación; una escrita junto con el diseño realmente reduce el riesgo y previene el retrabajo.

4. Automatizar el camino hacia producción con CI/CD y DevOps. La integración continua y la entrega continua —pipelines automatizados de construcción, prueba, y despliegue— permiten a un equipo enviar cambios pequeños y reversibles de forma segura y frecuente. En un dominio crítico para la seguridad, la capacidad de desplegar una corrección en minutos y revertir limpiamente es en sí misma un control de seguridad. Empareja esto con monitoreo, alertas, e infraestructura como código para que el servicio en vivo sea observable y reproducible.

5. Ajustar el método a la incertidumbre. Usa ágil donde las necesidades del usuario son inciertas y el descubrimiento todavía te está enseñando cosas; acepta una secuenciación tipo cascada solo donde los requisitos son genuinamente fijos y el riesgo de cambio es bajo. Sé explícito sobre operar un híbrido —equipos ágiles dentro de un envoltorio de programa— en lugar de fingir que un método gobierna todo, lo cual no engaña a nadie y frustra a todos.

6. Tratar la evaluación de servicio como una herramienta de diseño, no un examen. Trae revisores de aseguramiento, seguridad clínica, seguridad, y accesibilidad temprano y a menudo, para que la evaluación formal confirme un servicio ya construido según el estándar. Los equipos que primero cumplen el estándar la semana antes de la evaluación fallan lenta y costosamente; los equipos que lo interiorizan aprueban como un subproducto.

7. Seguir iterando en En vivo —y dotarlo de recursos. Un servicio no deja de necesitar un equipo cuando se pone en vivo. En vivo es donde el uso real expone las últimas inequidades, los casos límite clínicos raros pero graves, y las brechas de accesibilidad. Financia un equipo de producto permanente para la vida operativa del servicio (véase el Tema 5.0 — Trabajo liderado por producto); un servicio en vivo sin equipo es deuda técnica acumulando riesgo clínico.

8. Planificar la baja de servicio antes de necesitarla. Decide, mientras construyes, cómo se retirará eventualmente el servicio: retención y migración de datos bajo la ley de gestión de registros, redirección de usuarios, notificación a clínicos, y archivado del caso de seguridad clínica y el rastro de auditoría. Un retiro no planificado deja varados datos y usuarios; uno planificado es una fase controlada y auditable.

Preguntas para debatir con tu equipo#

1. ¿Están nuestras puertas de fase genuinamente gobernadas por evidencia, o se han convertido silenciosamente en fechas en un plan? Todo el valor del modelo Descubrimiento–Alfa–Beta–En vivo es que cada transición compromete más dinero y expone a más usuarios solo cuando la evidencia de la fase anterior lo justifica; en el momento en que una puerta se activa porque terminó el trimestre en lugar de porque llegó la evidencia, la rampa deja de reducir el riesgo y se convierte en "cascada disfrazada de ágil". Esta pregunta pide a un equipo que mire honestamente sus últimas transiciones y pregunte qué habría pasado si la evidencia hubiera dicho "todavía no" —¿había espacio para esperar, hacer que una beta volviera al alfa para una funcionalidad difícil, o la fecha de puesta en marcha era políticamente inamovible? La tensión a debatir es entre la necesidad de la organización de hitos legibles y programados por la junta y la realidad de que los servicios seguros se mueven al ritmo de la evidencia, y la entrega híbrida vive precisamente en esa fricción. Ángulos concretos incluyen nombrar la decisión y evidencia específica que vence en la siguiente puerta, comprobar si los "sprints" realmente cambian el alcance o meramente rastrean un plan fijo, y preguntar quién está empoderado para retrasar una puerta sin riesgo profesional. Una buena respuesta puede señalar una instancia real donde la evidencia cambió el plan, y puede articular qué evidencia justificaría —o bloquearía— el siguiente compromiso de dinero público y usuarios.

2. ¿Son la seguridad clínica y la gobernanza de la información hilos vivos a través de cada fase, o papeleo que pretendemos terminar antes de En vivo? En la salud y la atención, la DPIA y el trabajo de riesgo clínico DCB0129/0160 no son aprobaciones de fin de proyecto sino hilos que deben dar forma a la arquitectura y el diseño desde el alfa en adelante, porque un peligro diseñado fuera temprano es barato mientras que uno descubierto en la puesta en marcha es una crisis que bloquea el lanzamiento —o peor, una presión para dejar pasar el caso de seguridad. Esta pregunta saca a la luz si existe un Oficial de Seguridad Clínica nombrado y formado y un registro de peligros abierto tan pronto como aparece una forma de solución, y si el análisis de DPIA y base legal comenzó en el descubrimiento mientras los flujos de datos todavía eran lo suficientemente blandos para cambiar. La disyuntiva que vale la pena debatir es el arrastre sentido de hacer esto continuamente frente al coste mucho mayor y el riesgo clínico de una adaptación retroactiva, especialmente para equipos más pequeños o startups donde ningún regulador todavía está observando pero la obligación DCB0129 se adhiere al fabricante independientemente. Considera evidencia concreta: ¿muestra el registro de peligros peligros encontrados y mitigados en alfa, se lee el caso de seguridad como un resumen de trabajo ya hecho, y la DPIA se rastrea hasta decisiones de diseño reales? Una respuesta honesta distingue un equipo que madura su caso de seguridad junto con el servicio de uno que se dirige hacia una carrera de documentación el mes antes del lanzamiento.

3. ¿Cómo se operará este servicio en En vivo y eventualmente se retirará —y quién está financiado para hacerlo? Los ciclos de vida tienen una cola larga que las organizaciones rutinariamente infrafinancian: En vivo es donde el uso real expone las últimas inequidades, casos límite clínicos raros pero graves, y brechas de accesibilidad, y necesita un equipo de producto permanente, monitoreo, y despliegue rápido y reversible en lugar de un equipo que se disuelve en la puesta en marcha dejando que el servicio se pudra y acumule riesgo clínico silenciosamente. Igualmente descuidada es la baja de servicio —retirar un servicio bajo la ley de retención de registros, migrar o archivar datos, redirigir usuarios, notificar a clínicos, y preservar el registro de peligros y el rastro de auditoría— que para un sistema nacional es un programa mayor por derecho propio, no una idea de último momento cuando llega el reemplazo. La tensión a debatir es los ciclos de financiación anuales y la presión de declarar un proyecto "terminado" en el lanzamiento frente a la propiedad de toda la vida que un servicio seguro realmente requiere. Ángulos útiles incluyen si un pipeline de CI/CD con monitoreo y reversión rápida se trata como un control de seguridad en vivo, si un presupuesto de guardia e iteración sobrevive a la celebración de la puesta en marcha, y si se escribió un plan de salida mientras se construía en lugar de improvisarlo en pánico. Una buena respuesta nombra quién posee el servicio durante su vida operativa y describe un retiro controlado y auditable en lugar de la esperanza de que alguien lo maneje después.

4. ¿Cuándo fue la última vez que dejamos que el fallo de un prototipo nos detuviera —y todavía construimos cosas para desechar? El alfa existe para reducir los supuestos más riesgosos económicamente, lo que significa que un prototipo desechable que falla ha hecho su trabajo: ha comprado una lección costosa antes de que se comprometiera el dinero de producción y pacientes reales. Esta pregunta sondea si un equipo genuinamente trata el alfa como aprendizaje desechable o si silenciosamente ha derivado hacia pulir su primer prototipo hasta convertirlo en el producto eventual porque descartar código se siente como un desperdicio —la trampa del coste hundido que convierte una fase de reducción de riesgo en un compromiso costoso hecho a ciegas. La tensión que vale la pena sacar a la luz es la presión de "tener algo que mostrar" y reutilizar cada línea escrita frente a la disciplina de probar que una solución podría funcionar antes de construir la real sobre infraestructura de producción. Ángulos concretos incluyen preguntar qué supuestos realmente probó el último alfa, si algún prototipo alguna vez se abandonó según la evidencia, y si la construcción de beta privada reutilizó código desechable que debería haberse reescrito según el estándar de producción. Una respuesta honesta puede señalar un supuesto específico que un prototipo mató o confirmó, y puede distinguir los artefactos de aprendizaje que el equipo estaba dispuesto a descartar del código asegurado que ahora ejecuta en En vivo.

5. ¿Ejecutamos un híbrido honesto, o varios métodos disfrazados que silenciosamente se contradicen entre sí? La mayoría de los grandes programas de salud son genuinamente híbridos —equipos de producto ágiles operando dentro de un envoltorio de hitos y financiación que exigen la organización y sus reguladores— y el fallo no es el híbrido en sí sino fingir que es ágil puro o cascada pura, para que las dos lógicas choquen sin gestionar en cada puerta. Esta pregunta pide a un equipo que nombre dónde se sitúan realmente los compromisos fijos y secuenciados (tramos de financiación, hitos regulatorios, congelaciones de integración) y dónde sucede la iteración genuina, en lugar de dejar que "ágil" y "el plan" cada uno reclame todo el programa y frustre a todos. La disyuntiva a debatir es la necesidad legítima de la organización de hitos predecibles y gasto auditable frente a la necesidad del equipo de entrega de cambiar el alcance según la evidencia, y el movimiento honesto es hacer las costuras explícitas para que ambas puedan planificarse en torno a ellas. Ángulos útiles incluyen si la repriorización del backlog alguna vez sobrevive al contacto con el plan del programa, si los proveedores están contratados para un alcance fijo mientras se les pide trabajar iterativamente, y si el reporte que ve una junta coincide con cómo realmente se hace el trabajo. Una buena respuesta describe un híbrido deliberadamente diseñado con puntos fijos nombrados y espacios flexibles nombrados, no un lío en el que se reclama un método por apariencias.

6. ¿Qué tan bien sabemos qué le está haciendo realmente un servicio en vivo a sus usuarios ahora mismo —y notaríamos el daño antes de que lo reportaran? Un servicio de salud en vivo es solo tan seguro como su observabilidad: el monitoreo, las alertas, y los instintos de seguridad clínica que convierten una métrica en un peligro marcan la diferencia entre detectar un defecto de datos obsoletos en minutos y enterarse de él a través de un informe de incidente semanas después. Esta pregunta examina si el equipo puede ver el servicio en producción —tasas de error, fallos de integración, abandono de accesibilidad, las brechas de equidad que solo revela el uso real— y si alguien está observando los paneles con el riesgo clínico en mente, no solo el tiempo de actividad de la infraestructura. La tensión es el coste y la disciplina de una observabilidad y guardia apropiadas frente al supuesto silencioso de que "sin noticias son buenas noticias" una vez que un servicio está en vivo, que en un dominio crítico para la seguridad es cómo se acumula el daño silencioso. Ángulos concretos incluyen si el registro de peligros se actualiza desde incidentes en vivo, si las alertas se mapean al impacto clínico en lugar de solo a la salud del servidor, y si una mala versión se puede detectar y revertir antes de que llegue a muchos pacientes. Una respuesta honesta describe señales específicas que observa el equipo, un incidente real que el monitoreo captó (o pasó por alto), y cómo la evidencia en vivo retroalimenta la siguiente iteración.

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

Un fideicomiso comunitario del NHS está reemplazando un sistema heredado de papel y hoja de cálculo para la programación de visitas de enfermeras de distrito. Saliendo del descubrimiento (Tema 3.4), el equipo entra al alfa y construye dos prototipos desechables para probar los supuestos más riesgosos: que las enfermeras usarán un teléfono en los hogares de los pacientes, y que el horario puede integrarse con la historia clínica electrónica. Se nombra a un Oficial de Seguridad Clínica el primer día del alfa y abre un registro de peligros; un peligro temprano —un horario obsoleto que muestra una visita ya completada por un colega— impulsa una decisión de diseño para mostrar el estado de sincronización en tiempo real. La DPIA, comenzada en el descubrimiento, señala que los datos de ubicación de trabajadores solitarios necesitan una base legal y un límite de retención definidos.

En la evaluación de servicio alfa-a-beta, un panel independiente sondea la accesibilidad (enfermeras con deficiencias visuales), la seguridad, y el razonamiento del equipo. El servicio aprueba con acciones. En la beta privada, diez enfermeras usan el sistema real en infraestructura de producción; un pipeline de CI/CD permite al equipo enviar diariamente y revertir una mala versión en menos de diez minutos. El uso revela un problema de equidad —personal de agencia sin dispositivos del fideicomiso— lo que lleva a una alternativa basada en navegador. La beta pública escala a tres localidades; el informe del caso de seguridad clínica se completa y aprueba bajo DCB0160 antes de un despliegue más amplio.

El servicio se pone En vivo con un equipo de producto permanente, paneles de monitoreo, y un turno de guardia. Dieciocho meses después, cuando el fideicomiso adopta una plataforma regional, el horario se retira según el plan: los datos migrados bajo el calendario de retención, las enfermeras reentrenadas y redirigidas, y el registro de peligros y el caso de seguridad archivados para auditoría. Cada transición fue una decisión respaldada por evidencia, no una fecha en un diagrama de Gantt.

Perspectivas sectoriales#

Startup#

El ciclo de vida de una startup está comprimido y en gran parte autogobernado: no hay un panel de evaluación de servicio independiente, así que la disciplina de las puertas Alfa–Beta–En vivo debe autoimponerse o colapsa en "enviar continuamente y esperar". La ventaja es que un equipo pequeño puede ejecutar CI/CD genuino desde el primer día e iterar más rápido que cualquier organismo grande. El peligro es abandonar silenciosamente los hilos de seguridad clínica y DPIA porque ningún regulador todavía está observando —un error fatal en la salud, donde las obligaciones DCB0129 se adhieren al fabricante independientemente del tamaño de la empresa, y un peligro no gestionado puede terminar tanto con el producto como con la empresa. Las startups deberían adoptar la intención del modelo de fases —evidencia antes de exposición— incluso sin la ceremonia, nombrando a un Oficial de Seguridad Clínica (a menudo fraccionado) tan pronto como exista una forma de solución.

Pequeña empresa#

Un proveedor pequeño y establecido —una consulta de médico de cabecera, farmacia comunitaria, residencia de cuidados, o clínica de un solo emplazamiento— generalmente encuentra el ciclo de vida como un desplegador en lugar de un constructor: está adquiriendo o configurando el sistema de un proveedor, así que la aprobación de despliegue DCB0160 y una DPIA local recaen sobre él incluso sin un equipo digital interno. Las fases aún aplican, pero comprimidas y externalizadas: el "alfa" es un piloto supervisado en unos pocos pacientes reales, la "beta" es un despliegue escalonado a través de la consulta, y En vivo es el negocio habitual con las actualizaciones del proveedor llegando continuamente y en gran parte fuera del control de la consulta. La organización debe nombrar a un Oficial de Seguridad Clínica (a menudo un socio clínico asumiendo el rol además de un trabajo diario) y mantener un registro de peligros de cómo se usa el sistema localmente, porque el trabajo DCB0129 del fabricante no cubre los riesgos específicos del despliegue. Con efectivo ajustado y sin TI dedicada, la disciplina realista es apoyarse en el aseguramiento del proveedor mientras posee las pocas decisiones que solo el conocimiento local puede tomar —quién está formado, cuál es la alternativa cuando el sistema está caído, y cómo fluyen los datos del paciente en este entorno específico.

Gran organización#

Un fideicomiso del NHS o un gran proveedor ejecuta el ciclo de vida en su forma más completa y asegurada: evaluaciones de servicio formales, un Oficial de Seguridad Clínica nombrado, aprobación de despliegue DCB0160, juntas de asesoramiento de cambios, y un ciclo de financiación anual en el que debe encajar el trabajo ágil. El desafío característico es el híbrido —equipos de entrega ágiles operando dentro de un envoltorio de programa e hitos que exigen la organización y sus auditores— y el fallo clásico es "cascada disfrazada de ágil", donde las puertas silenciosamente se convierten en fechas de calendario. Las grandes organizaciones tienen los recursos para hacer CI/CD, observabilidad, y equipos de producto permanentes apropiadamente, sin embargo la inercia organizacional y la integración heredada a menudo ralentizan el despliegue a paso de tortuga. La responsabilidad es amplia y el radio de impacto grande, así que la rampa escalonada de beta privada a en vivo no es prudencia opcional sino control de riesgo esencial.

Gobierno#

Un organismo nacional entrega bajo el Estándar de Servicio completo, evaluaciones de servicio publicadas, controles de gasto, y escrutinio parlamentario, así que cada puerta de fase también es un punto de responsabilidad pública. Los ciclos de vida aquí son largos y la exposición vasta —un servicio en vivo a nivel del NHS puede tocar millones— lo que eleva las consecuencias de la rampa escalonada, el aseguramiento de seguridad clínica, y la baja de servicio de los sistemas heredados que se reemplazan. Las reglas de contratación y los acuerdos de financiación plurianuales dan forma a lo que puede significar "ágil" en la práctica, y retirar un sistema nacional (con sus décadas de registros y deberes estatutarios de retención) es un programa mayor por derecho propio. La disyuntiva es aseguramiento frente a velocidad: la entrega gubernamental está fuertemente controlada por puertas, lo que protege la seguridad y el dinero público pero exige un esfuerzo deliberado para mantener a los equipos iterando en lugar de revertir a un diseño grande de antemano.

Modos de fallo comunes#

• Cascada disfrazada de ágil. El equipo ejecuta "sprints" pero el alcance, las fechas, y el diseño estaban todos fijados de antemano; la iteración es teatro. Antídoto: dejar que la evidencia en cada puerta realmente cambie el plan.
• Seguridad y GI añadidas al final. El caso de seguridad clínica y la DPIA se escriben el mes antes de la puesta en marcha, bloqueando el lanzamiento o, peor, dejándose pasar bajo presión. Antídoto: abrir el registro de peligros y la DPIA en alfa y madurarlos continuamente.
• El lanzamiento big bang. El servicio omite la beta privada/pública y va directamente al despliegue completo, exponiendo a cada usuario a software no probado. Antídoto: usar la rampa escalonada; crecer la exposición con evidencia.
• El servicio En vivo abandonado. El equipo de entrega se disuelve en la puesta en marcha; el servicio se pudre, y el riesgo clínico se acumula silenciosamente. Antídoto: financiar un equipo de producto permanente para la vida operativa.
• Preparación de última hora para la evaluación. Los estándares se ignoran hasta que se acerca la evaluación, luego se cumplen superficialmente. Antídoto: involucrar continuamente a revisores de aseguramiento y clínicos.
• Sin plan de salida. El servicio se retira en pánico cuando llega su reemplazo, dejando varados datos y usuarios. Antídoto: planificar la baja de servicio como una fase de primer nivel.

Modelo de madurez#

Lista de verificación#

• El servicio tiene una fase actual explícita (Descubrimiento / Alfa / Beta / En vivo) y una siguiente decisión nombrada.
• Las transiciones de fase se activan según evidencia, no fechas.
• Un Oficial de Seguridad Clínica está nombrado y un registro de peligros está abierto (DCB0129/0160) desde el alfa en adelante.
• Una DPIA y evaluación de base legal (Caldicott, UK GDPR) comenzaron en el descubrimiento y se mantienen actualizadas.
• El método de entrega se ajusta al nivel de incertidumbre, y cualquier acuerdo híbrido es explícito.
• Las evaluaciones de servicio están planificadas, y los revisores de aseguramiento/seguridad/accesibilidad se involucran temprano.
• Un pipeline de CI/CD con monitoreo y reversión rápida está en marcha antes de la beta pública.
• El servicio se expone a los usuarios en una rampa escalonada (beta privada → beta pública → en vivo), no big bang.
• Un equipo de producto permanente está financiado para la vida operativa del servicio (véase el Tema 5.0).
• Un plan de baja de servicio cubre la retención/migración de datos, la redirección de usuarios, y el archivado de registros de seguridad y auditoría.

Fuentes clave#

• Manual de Servicio de GOV.UK — las fases de un proyecto ágil (Descubrimiento, Alfa, Beta, En vivo) y el Estándar de Servicio del Gobierno.
• NHS England — Estándar de Servicio del NHS y Manual de Servicio Digital del NHS; evaluaciones de servicio del NHS.
• NHS England Digital — DCB0129 (Clinical Risk Management: its Application in the Manufacture of Health IT Systems) y DCB0160 (its Application in the Deployment and Use of Health IT Systems).
• NHS England — Aseguramiento de seguridad clínica digital; el rol de Oficial de Seguridad Clínica, el registro de peligros, y el informe de caso de seguridad clínica.
• NHS England — Criterios de Evaluación de Tecnología Digital (DTAC).
• Principios Caldicott del Reino Unido; Data Protection Act 2018 / UK GDPR y evaluaciones de impacto en la protección de datos.
• NICE — Marco de Estándares de Evidencia para Tecnologías de Salud Digital.
• Práctica de DevOps y entrega continua (p. ej. las capacidades DORA: integración continua, automatización de despliegue, monitoreo); orientación del Manual de Servicio de GOV.UK sobre entrega continua y operación de un servicio.

Referencias#

1. Systems development life cycle — Wikipedia — https://en.wikipedia.org/wiki/Systems_development_life_cycle
2. Waterfall model — Wikipedia — https://en.wikipedia.org/wiki/Waterfall_model
3. Agile software development — Wikipedia — https://en.wikipedia.org/wiki/Agile_software_development
4. Software prototyping — Wikipedia — https://en.wikipedia.org/wiki/Software_prototyping
5. CI/CD — Wikipedia — https://en.wikipedia.org/wiki/CI/CD
6. Continuous integration — Wikipedia — https://en.wikipedia.org/wiki/Continuous_integration
7. Continuous delivery — Wikipedia — https://en.wikipedia.org/wiki/Continuous_delivery
8. DevOps — Wikipedia — https://en.wikipedia.org/wiki/DevOps
9. Infrastructure as Code — Wikipedia — https://en.wikipedia.org/wiki/Infrastructure_as_code
10. Observability (software) — Wikipedia — https://en.wikipedia.org/wiki/Observability_(software)
11. Privacy impact assessment (data protection impact assessment) — Wikipedia — https://en.wikipedia.org/wiki/Privacy_impact_assessment
12. Agile delivery: the phases of an agile project — Government Digital Service, GOV.UK Service Manual — https://www.gov.uk/service-manual/agile-delivery
13. NHS service standard and NHS digital service manual — NHS England — https://service-manual.nhs.uk/
14. Clinical risk management standards DCB0129 and DCB0160 — NHS England (Clinical Safety) — https://digital.nhs.uk/services/clinical-safety
15. DevOps Research and Assessment (DORA) capabilities — Google Cloud / DORA — https://dora.dev/
16. Continuous delivery — Jez Humble and David Farley — https://continuousdelivery.com/
17. Data protection impact assessments (DPIAs) — Information Commissioner's Office (ICO) — https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/data-protection-impact-assessments-dpias/
18. Evidence standards framework for digital health technologies — NICE — https://www.nice.org.uk/about/what-we-do/digital-health