Tema 1.0 — Formas de trabajar en la salud y la atención digital

En una frase: Las formas de trabajar son los hábitos deliberados y compartidos —cómo organizas equipos, tomas decisiones, gestionas el riesgo y entregas valor— que permiten a una organización de salud y atención convertir la intención en resultados seguros, equitativos y basados en evidencia para pacientes y ciudadanos.

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

Toda organización tiene formas de trabajar, ya sean elegidas o heredadas. En la salud y la atención digital, las que se heredan suelen ser inadecuadas para la tarea: fueron construidas para proyectos de tipo constructivo con alcance fijo, no para servicios adaptativos que tocan la seguridad clínica, el deber estatutario y el dinero público. Hacerlas bien no es un detalle administrativo; es la diferencia entre una historia clínica compartida en la que los clínicos confían y una que permanece sin usar.

La salud y la atención son distintivas de formas que dan forma a cada práctica de este libro. La seguridad no es negociable —un defecto en un servicio digital puede dañar a un paciente, por lo que la gestión del riesgo clínico (véase el Tema 1.6 — Seguridad clínica y gestión de riesgos) está entretejida en la entrega, no añadida a posteriori. La equidad importa porque un servicio que solo funciona para quienes tienen confianza digital amplía las desigualdades en salud; las poblaciones Core20PLUS5 y las personas con acceso digital limitado deben ser diseñadas para, no diseñadas fuera. Los deberes estatutarios —el compromiso del NHS con la atención integral, la legislación de protección de datos, el deber de confidencialidad— limitan lo que puedes hacer con los datos y cómo debes consultar. El dinero público exige un control de gasto proporcionado y un valor demostrable. Y casi nada se entrega por un solo organismo: la asociación entre sistemas de atención integrada (ICS), autoridades locales, proveedores de atención social y proveedores comerciales es la condición operativa por defecto.

Estas cuatro presiones —seguridad, equidad, deber, dinero— son la razón por la que no puedes simplemente copiar un manual de tecnología de consumo. Necesitas formas de trabajar que sean ágiles y responsables, rápidas y seguras, centradas en el usuario y justas para la población.

Conceptos clave#

Las formas de trabajar operan en tres niveles. A nivel de equipo, son las prácticas diarias: reuniones de pie, investigación de usuarios, entrega iterativa, trabajo en pareja. A nivel organizacional, son el modelo operativo —cómo la estrategia se convierte en flujos de valor, capacidades, financiación y derechos de decisión (véase el Tema 1.1 — El modelo operativo). A nivel de sistema, son la forma en que organizaciones independientes se alinean: estándares compartidos, interoperabilidad y gobernanza común a lo largo de un ICS. Este libro se mueve deliberadamente por los tres niveles.

El diseño centrado en el usuario significa partir de las necesidades de las personas que usan un servicio —pacientes, cuidadores, clínicos, administradores— en lugar de partir de una solución asumida. El Servicio Digital del Gobierno (GDS) del Reino Unido y el NHS codificaron esto en los estándares de servicio: entender a los usuarios y sus necesidades antes de construir, y seguir probando con usuarios reales durante todo el proceso.

La entrega ágil e iterativa significa poner un servicio funcional delante de usuarios reales pronto, aprender y adaptarse —en lugar de especificarlo todo de antemano. El manual de servicio digital del NHS es explícito en que las formas de trabajar ágiles y centradas en el usuario reducen el riesgo de construir lo que no corresponde. Lo ágil aquí es tanto una estrategia de gestión de riesgos como un método de entrega.

Los equipos multidisciplinarios (MDT) reúnen, en un único equipo empoderado, la combinación de habilidades que un servicio necesita: gestión de producto y de entrega, investigación de usuarios y diseño, ingeniería, experiencia clínica y de gobernanza de la información, y conocimiento operativo. El estándar de servicio del NHS exige equipos que incluyan habilidades y perspectivas multidisciplinarias —incluyendo acceso a aportes clínicos, legales o de política especializados. El MDT es el átomo de la entrega digital; la mayoría de los fallos se remontan a una disciplina ausente en la mesa.

Producto sobre proyecto. Un proyecto tiene un inicio, un final y una entrega final; un producto se financia y se gestiona durante toda su vida. El cambio de pensar en proyecto a pensar en producto (véase el Tema 1.1 y el Tema 5.0 — Trabajo liderado por producto) cambia la financiación, los equipos y la responsabilidad, y encaja con los servicios de salud —que son duraderos y evolucionan continuamente— mucho mejor que los proyectos únicos.

Buenas prácticas#

1. Partir de las necesidades del usuario, respaldadas por investigación. Antes de comprometerte a construir, entiende quiénes son los usuarios, qué intentan hacer y dónde el servicio actual les falla. Financia un descubrimiento (véase el Tema 3.4 — Fases de descubrimiento) y trata "asumimos que" como una señal de alerta. Las necesidades del usuario, no las preferencias internas, son el ancla de toda decisión posterior.

2. Construir equipos multidisciplinarios, empoderados y estables. Reúne la combinación completa de habilidades —incluyendo seguridad clínica y gobernanza de la información— y da al equipo autoridad para decidir dentro de límites claros. Mantén los equipos unidos en torno a un servicio en lugar de disolverlos en cada límite de proyecto; los equipos estables acumulan el conocimiento de dominio y de seguridad que exigen los servicios de salud.

3. Trabajar de forma abierta e iterar en pasos pequeños. Entrega porciones delgadas, mide y ajusta. Las publicaciones pequeñas y frecuentes son más seguras que los lanzamientos "big bang", porque los problemas salen a la superficie mientras aún son pequeños, y permiten que la revisión de seguridad clínica y de gobernanza de la información mantenga el ritmo del cambio en lugar de convertirse en un obstáculo al final.

4. Hacer que la seguridad y la equidad sean de primer nivel desde el primer día. Realiza la gestión de riesgo clínico (DCB0129/DCB0160) y el análisis de igualdad/desigualdades en salud junto con la entrega, no como aprobaciones de etapa final. Pregunta desde el principio quién podría quedar excluido o resultar perjudicado, y diseña para los casos más difíciles —rutas de asistencia digital, accesibilidad (WCAG) y alternativas sin conexión.

5. Decidir con evidencia, y registrar la decisión. Distingue la evidencia clínica (¿funciona y es seguro?) de la evidencia de entrega (¿lo estamos construyendo bien y se está usando?), y mantén un registro ligero de decisiones para que el razonamiento sobreviva a la rotación de personal (véase el Tema 1.3 — Decisiones basadas en evidencia). La evidencia vence a la opinión de la persona mejor pagada.

6. Diseñar para la interoperabilidad y la reutilización. Los datos de salud y atención deben fluir de forma segura entre organizaciones; construye sobre estándares abiertos (HL7 FHIR, SNOMED CT) y reutiliza plataformas en lugar de reinventarlas (véase la "plataforma mínima viable" del Tema 1.1 y el Tema 4.3 — Interoperabilidad y estándares de datos). Un servicio que no puede compartir datos es un silo esperando convertirse en un riesgo.

7. Gobernar de forma proporcionada. Ajusta el peso del aseguramiento al nivel de riesgo. Los cambios clínicos de alto riesgo merecen un escrutinio profundo; los cambios de contenido de bajo riesgo no deberían esperar semanas a una junta directiva. La gobernanza proporcionada te mantiene seguro y rápido a la vez.

8. Trabajar de forma abierta. Comparte planes, decisiones, hojas de ruta y —cuando sea seguro— código, para que socios, clínicos y el público puedan ver cómo y por qué se toman las decisiones. La apertura genera confianza, reduce la duplicación en un sistema fragmentado e invita al escrutinio antes de que los errores se consoliden en servicios en vivo. En la salud y la atención, ser transparente sobre lo que un servicio hace con los datos, y por qué, es en sí mismo una práctica de confianza y seguridad.

9. Diseñar para el largo plazo y para el traspaso. Los servicios digitales en salud sobreviven a los equipos y contratos que los construyen, así que registra las decisiones, evita el conocimiento no documentado de "héroe", y diseña pensando en las personas que dirigirán y cambiarán el servicio durante años (véase el Tema 10.3 — Gestión del conocimiento y documentación). Trata la sostenibilidad —del equipo, la tecnología y el modelo de financiación— como una restricción de primer nivel, no como una idea de último momento.

Preguntas para debatir con tu equipo#

1. ¿Dónde son nuestras formas de trabajar actuales heredadas en lugar de elegidas, y qué hábito heredado nos está costando más en seguridad, equidad o gasto desperdiciado? Esta pregunta obliga a una auditoría honesta de las prácticas que nadie decidió pero que todos siguen —financiación de programas de alcance fijo, equipos de proyecto que se disuelven y reconstruyen, gobernanza consultada solo en el momento de la puesta en marcha. Importa porque los hábitos heredados suelen ser invisibles hasta que se nombran, y en la salud y la atención acarrean un coste real: una historia compartida en la que los clínicos no confían, un servicio que excluye a las poblaciones Core20PLUS5, o la reconstrucción de la misma infraestructura de inicio de sesión con dinero público. La tensión a debatir es que las formas heredadas a menudo se sienten seguras precisamente porque son familiares y auditables, por lo que retirarlas parece asumir un riesgo en lugar de eliminarlo. Fundamenta la discusión en artefactos concretos —examina tus últimos tres casos de negocio, la rotación de tu equipo entre proyectos, y cuándo se involucró por primera vez la seguridad clínica— en lugar de intercambiar opiniones. Una buena respuesta nombra uno o dos hábitos específicos con evidencia de su coste, distingue los que vale la pena conservar de los que están dañando activamente los resultados, y se compromete con un cambio del que un líder senior será responsable.

2. ¿Tienen nuestros equipos genuinamente la combinación completa de habilidades multidisciplinarias —incluyendo seguridad clínica y gobernanza de la información— dentro del equipo, o esas disciplinas siguen añadidas como controles de etapa final? El tema sostiene que el MDT es el átomo de la entrega digital y que la mayoría de los fallos se remontan a una disciplina ausente en la mesa, así que esta pregunta pone a prueba si ese principio es real en tu organización o meramente aspiracional. Importa porque un oficial de seguridad clínica o un Guardián Caldicott involucrado solo en la puesta en marcha obliga a rehacer el trabajo o a atajos inseguros, mientras que uno integrado desde la primera semana mantiene un registro de peligros vivo que marca el ritmo de la entrega. La disyuntiva que merece salir a la luz es el coste y la escasez: el tiempo clínico, legal y de gobernanza de la información especializado es genuinamente limitado, así que "integrar a todos en todos los equipos" choca con restricciones reales de recursos, y el equipo debe decidir dónde son aceptables los roles fraccionados o compartidos y dónde no. Examina un servicio actual y traza quién está realmente en el equipo permanente frente a quién se consulta como aprobación externa, y comprueba si el equipo tiene autoridad para decidir dentro de límites o debe escalar constantemente. Una respuesta honesta y buena es específica sobre qué disciplinas faltan o son prestadas, reconoce con franqueza la tensión de recursos, y propone un modelo concreto —a tiempo completo, fraccionado o de guardia— para cerrar la brecha sin fingir que la escasez no existe.

3. ¿Cuándo hemos tratado un servicio digital como un proyecto con una entrega final en lugar de un producto gestionado durante toda su vida, y qué nos costó eso en conocimiento perdido de dominio y de seguridad? Producto sobre proyecto es uno de los cambios estructurales del tema, y esta pregunta hace que el equipo confronte dónde todavía financian y dotan de personal para el cierre en lugar de la continuidad. Importa porque los servicios de salud son duraderos y evolucionan continuamente; un equipo disuelto en el límite del proyecto se lleva consigo exactamente el conocimiento clínico y operativo acumulado que mantiene seguro a un servicio, y el "purgatorio del piloto" es el síntoma recurrente. La tensión real es financiera y estructural: la financiación de producto requiere presupuestos permanentes y desafía el modelo de solicitud anual y plazo fijo en torno al cual están construidos las finanzas y la gobernanza, así que esto es tanto una conversación sobre dinero y responsabilidad como sobre entrega. Considera un servicio concreto que pasó por una entrega final —rastrea qué le sucedió a su registro de peligros, su investigación de usuarios y su equipo— y sopesa eso frente a la disciplina que exige la financiación de producto. Una buena respuesta identifica un caso concreto, cuantifica o al menos caracteriza el conocimiento perdido, y es franca sobre qué barreras organizativas (ciclos de financiación, reglas de dotación de personal, estructuras de gobernanza) tendrían que moverse para que los equipos de producto persistentes se convirtieran en la norma.

4. ¿Quién tiene más probabilidades de quedar excluido o resultar perjudicado por los servicios que construimos, y podemos señalar dónde diseñamos para ellos primero en lugar de al final? El tema insiste en que la equidad no es negociable y que un servicio que solo funciona para quienes tienen confianza digital amplía las desigualdades en salud, así que esta pregunta pone a prueba si "diseñar para los casos más difíciles" es una práctica viva o un eslogan. Importa porque la exclusión en la salud y la atención no es un inconveniente sino un daño de seguridad y acceso: las poblaciones Core20PLUS5, las personas con acceso digital limitado, baja alfabetización en salud, o sin teléfono inteligente son precisamente las personas cuyas necesidades son mayores, y un servicio que las diseña fuera concentra el daño donde es menos asumible. La tensión que merece salir a la luz es que diseñar para los márgenes cuesta tiempo y dinero por adelantado —rutas de asistencia digital, accesibilidad según WCAG, alternativas sin conexión y no digitales, traducción— y esos costes son fáciles de aplazar cuando se acerca una fecha de entrega y la mayoría con confianza ya puede usar la herramienta. Examina un servicio real y pregunta quién está en su muestra de investigación de usuarios, si un análisis de igualdad y desigualdades en salud realmente dio forma a una decisión de diseño, y qué le sucede a alguien que no puede o no quiere conectarse. Una respuesta honesta nombra los grupos específicos en riesgo para este servicio, muestra al menos una decisión de diseño concreta tomada para ellos, y es franca sobre dónde el equipo sacrificó la inclusión bajo presión y cómo lo defendería la próxima vez.

5. ¿Dónde estamos reinventando infraestructura que ya existe, y dónde construir sobre estándares abiertos y reutilizar plataformas compartidas realmente cambiaría lo que entregamos? Diseñar para la interoperabilidad y la reutilización es una de las buenas prácticas del tema, y esta pregunta hace que el equipo confronte el impulso de construir a medida en lugar de reutilizar —el inicio de sesión, las notificaciones, la integración de historias clínicas que otra decena de equipos también ha construido. Importa porque en un sistema fragmentado cada componente reinventado es dinero público gastado dos veces y un nuevo silo que no puede intercambiar datos de forma segura; a la inversa, construir sobre HL7 FHIR y SNOMED CT y reutilizar la plataforma mínima viable es lo que permite que un servicio supere la contratación y comparta datos en todo un ICS. La disyuntiva real es que la reutilización significa dependencia: una plataforma compartida puede ser más lenta, menos personalizada, o gobernada por la hoja de ruta de otro, así que el equipo debe sopesar la fricción de un componente compartido frente al coste y riesgo a largo plazo de un silo a medida. Examina una construcción actual y enumera qué es genuinamente novedoso frente a qué duplica una plataforma, estándar o componente abierto existente, y comprueba si "no podemos reutilizar eso" es una restricción demostrada o un supuesto sin probar. Una buena respuesta distingue las partes que vale la pena construir de las que vale la pena reutilizar, es honesta sobre la madurez y gobernanza de las plataformas disponibles, y se compromete con estándares abiertos para todo lo que deba intercambiar datos.

6. ¿Cómo hacemos coincidir el peso de nuestra gobernanza con el nivel de riesgo, y dónde es el aseguramiento actualmente demasiado pesado para el cambio de bajo riesgo o demasiado ligero para el cambio de alto riesgo? La gobernanza proporcionada es una idea estructural en este tema —los cambios clínicos de alto riesgo merecen un escrutinio profundo mientras que los cambios de contenido de bajo riesgo no deberían esperar semanas a una junta directiva— y esta pregunta pone a prueba si la organización calibra el aseguramiento al riesgo o aplica un único proceso contundente a todo. Importa porque una gobernanza mal calibrada perjudica en ambos sentidos: un control único y pesado para todo hace que los equipos agrupen cambios y ralentiza la misma iteración que mantiene seguros a los servicios, mientras que un trato uniformemente ligero deja pasar un cambio clínico genuinamente de alto riesgo sin el escrutinio de seguridad clínica y gobernanza de la información que necesita. La tensión es que la proporcionalidad requiere juicio, y el juicio resulta incómodo para juntas y auditores que encuentran más fácil defender una única lista de verificación obligatoria que una ruta escalonada por riesgo. Examina cómo se aseguraron tus últimos doce cambios, clasifícalos por riesgo clínico y de datos real, y comprueba si el esfuerzo invertido siguió al riesgo o al calendario. Una respuesta honesta identifica ejemplos concretos de sobre-gobernanza y de infra-gobernanza, propone criterios claros para clasificar el cambio por riesgo, y nombra quién tiene la autoridad para decidir el nivel y ser responsable de ello.

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

Un sistema de atención integrada quiere dar a los clínicos de tres fideicomisos de agudos, servicios comunitarios y atención social de la autoridad local una historia clínica compartida. La vieja manera habría encargado un programa de alcance fijo, especificado cada pantalla de antemano e integrado tarde.

En su lugar, el ICS forma un equipo multidisciplinario: un gestor de producto, un gestor de entrega, un investigador de usuarios, un diseñador de interacción, dos ingenieros, un oficial de seguridad clínica y un responsable de gobernanza de la información, con acceso a un Guardián Caldicott y a un profesional de atención social. Realizan un descubrimiento de ocho semanas, observando cómo una enfermera de distrito, un consultor de urgencias y un trabajador social intentan realmente encontrar información hoy. Descubren que el problema real no es "no hay datos" sino "datos en cuya vigencia no pueden confiar".

El equipo entrega un alfa reducido: acceso de solo lectura a alergias, medicamentos y estado actual del plan de atención para una vía clínica, con una marca visible de "última actualización". La seguridad clínica se ejecuta en paralelo; se mantiene un registro de peligros desde la primera semana. Miden si los clínicos dejan de llamar a otros equipos para confirmar información. Solo una vez que esa porción delgada demuestra ser valiosa y segura, amplían la historia clínica —financiada como un producto continuo, no como un proyecto cerrado.

Perspectivas sectoriales#

Las mismas cuatro presiones —seguridad, equidad, deber, dinero— pesan sobre toda organización, pero las formas de trabajar que las responden cambian con la escala, la financiación y la responsabilidad.

Startup#

Una pequeña empresa de salud digital vive o muere por el enfoque, así que sus formas de trabajar son ágiles por necesidad: un equipo multidisciplinario, toma de decisiones plana y contacto diario con los usuarios. La restricción es el tiempo de financiación disponible, no las normas de plantilla, así que el descubrimiento se mide en semanas y la evidencia se recopila de forma económica —un puñado de entrevistas clínicas, un prototipo navegable, un registro de peligros honesto mantenido por un oficial de seguridad clínica fraccionado. El peligro es saltarse el rigor de seguridad y gobernanza de la información para alcanzar un hito de un inversor; la disciplina que sobrevive al escrutinio es tratar el DCB0129 y una evaluación de impacto en la protección de datos como criterios de entrada para un piloto, no como papeleo aplazado hasta que un fideicomiso lo pida. La interoperabilidad desde el primer día (FHIR, SNOMED CT) es también un activo comercial, porque una startup que no puede intercambiar datos nunca superará la contratación del NHS.

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 agencia de atención domiciliaria, una clínica de un solo emplazamiento, o un modesto proveedor de tecnología de salud que ya superó la etapa previa a los ingresos— carga con las mismas presiones de seguridad, equidad, deber y dinero que un gran fideicomiso, pero con una fracción de la capacidad para afrontarlas. Las formas de trabajar aquí tienen que ser radicalmente proporcionadas: rara vez hay un equipo digital o de gobernanza de la información dedicado, así que el "equipo multidisciplinario" suele ser un puñado de personas que llevan varios sombreros más un recurso compartido o externalizado de seguridad clínica y protección de datos. La trampa es asumir que los deberes estatutarios se reducen a escala con la organización —no lo hacen, así que la seguridad clínica DCB0129/DCB0160, una evaluación de impacto en la protección de datos y la accesibilidad siguen aplicándose en su totalidad incluso cuando un único gestor de consulta es responsable de todas ellas. La disciplina práctica es apoyarse fuertemente en la reutilización en lugar de construir: adoptar sistemas acreditados listos para usar, insistir en que los proveedores cumplan con el DTAC y estándares abiertos (FHIR, SNOMED CT), y usar plataformas nacionales y proporcionadas por el ICS para que la seguridad, la interoperabilidad y la gobernanza de la información se hereden en lugar de reinventarse con recursos mínimos.

Gran organización#

Un fideicomiso del NHS o un ICS tiene el problema opuesto: proceso abundante y propiedad fragmentada. Las formas de trabajar aquí tratan tanto de desaprender —retirar los hábitos de programas de alcance fijo, dar de baja los equipos de proyecto que se disuelven y reconstruyen— como de adoptar nuevas prácticas. La responsabilidad es formal y personal (un propietario senior responsable, un Guardián Caldicott, la aprobación de seguridad clínica a nivel de junta directiva), así que el logro consiste en integrar esos roles dentro del equipo de entrega en lugar de añadirlos como controles. Un gran proveedor de tecnología de salud o farmacéutico enfrenta la imagen especular: fuerte madurez de ingeniería pero distancia de la realidad clínica de primera línea, que los equipos multidisciplinarios con tiempo clínico real existen para cerrar.

Gobierno#

Un organismo público nacional o local —NHS England, DHSC, UKHSA, una autoridad local— establece los estándares según los cuales trabajan todos los demás, así que sus formas de trabajar se propagan hacia afuera. Su responsabilidad es ante el Parlamento y el público, lo que eleva el listón de la transparencia, el control del gasto y la equidad: un estándar de servicio, una vía de aseguramiento publicada y los deberes Core20PLUS5 son instrumentos de esa responsabilidad, no extras opcionales. El riesgo a esta escala es diseñar centralmente para un ciudadano promedio que no existe y ordenar una solución antes de entender la necesidad local. El correctivo es la misma disciplina centrada en el usuario e iterativa que en cualquier otro lugar, aplicada con un sesgo hacia establecer estándares abiertos y plataformas reutilizables sobre las que las organizaciones federadas puedan construir —gobernando el sistema, no solo entregando un servicio.

Modos de fallo comunes#

• Entrega orientada primero a la solución. Comprometerse con un producto nombrado antes de entender la necesidad. Antídoto: financiar el descubrimiento y hacer de las necesidades del usuario el criterio de entrada para la construcción.
• Gobernanza como un control tardío. Seguridad clínica y gobernanza de la información consultadas solo en la puesta en marcha, obligando a rehacer el trabajo o a atajos inseguros. Antídoto: integrar ambas en el equipo desde el primer día.
• Rotación de proyectos. Formar equipos y desmantelarlos, perdiendo el conocimiento de dominio y de seguridad ganado con esfuerzo. Antídoto: financiación de producto y equipos persistentes.
• Purgatorio del piloto. Pilotos interminables que nunca escalan porque la adopción, la formación y el cambio de negocio nunca contaron con recursos (véase el Tema 8.1 — Gestión del cambio). Antídoto: planificar el camino hacia la escala antes del piloto.
• Equidad como idea de último momento. Diseñar para la mayoría con confianza y excluir a las personas que más necesitan atención. Antídoto: diseñar primero para los casos más difíciles.

Modelo de madurez#

Lista de verificación#

• Cada servicio tiene un equipo multidisciplinario nombrado y estable con habilidades de seguridad clínica y gobernanza de la información.
• Ninguna construcción comienza sin necesidades de usuario respaldadas por el descubrimiento.
• La gestión de riesgo clínico (DCB0129/DCB0160) funciona desde el primer día, con un registro de peligros vivo.
• Se ha realizado un análisis de equidad/desigualdades en salud, y existen rutas de asistencia digital.
• La entrega procede en porciones pequeñas, frecuentes y medibles.
• Las decisiones se registran, distinguiendo la evidencia clínica de la de entrega.
• Los servicios se construyen sobre estándares abiertos de interoperabilidad y reutilizan plataformas compartidas.
• El peso de la gobernanza coincide con el riesgo, y el equipo lo conoce.
• Hay un camino financiado desde el piloto hasta la escala, incluyendo formación y cambio.

Fuentes clave#

• Manual de servicio digital del NHS — Estándar de servicio del NHS y sus puntos, incluyendo "Usar formas ágiles de trabajar" y "Crear un equipo que incluya habilidades y perspectivas multidisciplinarias" (service-manual.nhs.uk).
• Manual de Servicio de GOV.UK y el Estándar de Servicio del Gobierno — Government Digital Service (gov.uk/service-manual).
• NHS England / NHSX — Criterios de Evaluación de Tecnología Digital (DTAC).
• Estándares de seguridad clínica DCB0129 y DCB0160 (NHS England / antiguo NHS Digital).
• NICE — Marco de Estándares de Evidencia para tecnologías de salud digital (nice.org.uk).
• NHS England — Enfoque Core20PLUS5 para reducir las desigualdades en salud.

Referencias#

1. User-centered design — Wikipedia — https://en.wikipedia.org/wiki/User-centered_design
2. Government Digital Service — Wikipedia — https://en.wikipedia.org/wiki/Government_Digital_Service
3. Agile software development — Wikipedia — https://en.wikipedia.org/wiki/Agile_software_development
4. Iterative and incremental development — Wikipedia — https://en.wikipedia.org/wiki/Iterative_and_incremental_development
5. Interdisciplinarity — Wikipedia — https://en.wikipedia.org/wiki/Interdisciplinarity
6. Product management — Wikipedia — https://en.wikipedia.org/wiki/Product_management
7. Health equity — Wikipedia — https://en.wikipedia.org/wiki/Health_equity
8. Web Content Accessibility Guidelines — Wikipedia — https://en.wikipedia.org/wiki/Web_Content_Accessibility_Guidelines
9. Fast Healthcare Interoperability Resources (HL7 FHIR) — Wikipedia — https://en.wikipedia.org/wiki/Fast_Healthcare_Interoperability_Resources
10. SNOMED CT — Wikipedia — https://en.wikipedia.org/wiki/SNOMED_CT
11. NHS service standard — NHS digital service manual, NHS England — https://service-manual.nhs.uk/standards-and-technology/service-standard
12. Government Service Standard — Government Digital Service, GOV.UK — https://www.gov.uk/service-manual/service-standard
13. Digital Technology Assessment Criteria (DTAC) — NHS England — https://www.nhs.uk/digital-technology-assessment-criteria-dtac/
14. Clinical Risk Management: DCB0129 and DCB0160 — NHS England — https://digital.nhs.uk/services/clinical-safety
15. Evidence Standards Framework for digital health technologies — NICE — https://www.nice.org.uk/about/what-we-do/digital-health
16. Core20PLUS5 — NHS England — https://www.england.nhs.uk/about/equality/equality-hub/national-healthcare-inequalities-improvement-programme/core20plus5/