Tema 3.4 — Fases de descubrimiento

En una frase: El descubrimiento es el esfuerzo disciplinado y con límite de tiempo para entender a tus usuarios y el problema real antes de comprometer dinero, riesgo clínico, o reputación a construir una solución.

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

En la mayoría de los sectores, construir lo incorrecto desperdicia dinero. En la salud y la atención, también puede desperdiciar tiempo clínico, arraigar desigualdades en salud, y —en el extremo— dañar a los pacientes. Un servicio digital que asume que cada usuario tiene un teléfono inteligente, banda ancha fiable, e inglés confiado excluye silenciosamente a los frágiles, los pobres, y los marginados digitalmente: precisamente las personas a las que existen para servir el NHS y la atención social. El descubrimiento es donde lo averiguas por el precio de unas pocas semanas de investigación, en lugar de después de un despliegue nacional.

El gasto en salud y atención es dinero público mantenido en fideicomiso, y gran parte de él fluye a través de deberes estatutarios: la Constitución del NHS, el deber de igualdad del sector público bajo la Equality Act 2010, y los principios Caldicott para manejar información confidencial del paciente. El descubrimiento es la fase donde pruebas si un servicio propuesto es necesario, legal, seguro, y equitativo —antes de que esas preguntas se vuelvan costosas de responder. Omitirlo no elimina las preguntas; meramente las aplaza a un punto donde la respuesta honesta es políticamente imposible de aceptar.

El Estándar de Servicio Digital del NHS y el Manual de Servicio de GOV.UK ambos hacen del descubrimiento la primera fase obligatoria de cualquier servicio digital orientado al usuario precisamente por esta razón. No es teatro burocrático. Es el seguro más barato que jamás comprarás.

Conceptos clave#

Descubrimiento, definido. El descubrimiento es una fase corta (típicamente de 6 a 10 semanas) cuyo objetivo es entender un espacio de problema: quiénes son los usuarios, qué están intentando hacer, qué se lo impide, qué ya existe, y si hay un problema que valga la pena resolver en absoluto. Su resultado es comprensión y evidencia, no un producto. Un buen descubrimiento puede válidamente concluir "no hacer nada" o "esto es un problema de política, no digital."

El doble diamante. El doble diamante del Design Council (2005) enmarca el diseño como dos diamantes vinculados. El primero —Descubrir luego Definir— diverge para explorar el problema ampliamente, luego converge para enmarcarlo con precisión. El segundo —Desarrollar luego Entregar— diverge para explorar soluciones, luego converge para construir una. El descubrimiento, como fase de entrega, vive casi enteramente en el primer diamante. El fallo recurrente es que los equipos corren hacia el segundo diamante antes de que termine el primero.

Necesidad del usuario frente a deseo del interesado. Una necesidad del usuario es algo que una persona está intentando lograr, expresado desde su punto de vista ("necesito saber que mi cita está confirmada para no tomarme un día libre del trabajo en vano"). Un deseo del interesado es una funcionalidad o solución que alguien ya ha decidido ("necesitamos una aplicación"). La disciplina central del descubrimiento es traducir deseos de vuelta a necesidades, porque las necesidades son estables y las soluciones son baratas e intercambiables una vez que la necesidad es clara.

Enmarcado del problema. Cómo declaras un problema restringe cada solución que considerarás. "Los pacientes se pierden citas" invita a una aplicación de recordatorios. "Los pacientes no pueden reorganizar fácilmente citas que ya no les convienen" invita al autoservicio de reprogramación. Mismo síntoma, problema diferente, servicio radicalmente diferente. El descubrimiento se gana su lugar en gran parte por la calidad de la declaración del problema que produce.

Supuestos, hipótesis y evidencia. Cada proyecto descansa sobre supuestos. El descubrimiento los hace explícitos, los clasifica por riesgo, y prueba los más riesgosos con usuarios reales. El objetivo no es la certeza —eso es inalcanzable— sino la incertidumbre reducida en las cosas que hundirían el proyecto.

Buenas prácticas#

1. Comenzar desde un problema, no una solución. Escribe la declaración del problema antes de que alguien nombre una tecnología. Si la solicitud de financiación, el documento de junta, o la propuesta del proveedor ya especifican "una aplicación" o "un portal," trata eso como un supuesto a probar, no una decisión a implementar. Las soluciones a las que se llega antes de entender el problema son casi siempre el hábito de alguien, no la necesidad del usuario.

2. Realizar investigación de usuarios real con usuarios reales. Entrevista y observa a las personas reales que usarán el servicio —pacientes, cuidadores, recepcionistas, enfermeras comunitarias, trabajadores sociales— en su contexto real, no un taller de gestores hablando en su nombre. Apunta a la profundidad sobre el volumen; una docena de entrevistas contextuales bien elegidas revela más que una encuesta de mil respuestas. Recluta deliberadamente para los usuarios más difíciles de alcanzar, porque son a quienes un servicio más a menudo falla.

3. Mapear todo el servicio, no la porción digital. Los usuarios experimentan un servicio de extremo a extremo —una derivación, una evaluación, un tratamiento, un seguimiento— del cual tu componente digital es un paso. Mapea el recorrido actual a través de cada canal y organización, incluyendo las partes en papel, por teléfono, y cara a cara. Los cambios digitales fallan rutinariamente porque optimizan un paso y rompen los dos a cada lado de él.

4. Enmarcar el problema explícitamente y conseguir que se acuerde. Produce una declaración de problema escrita y la evidencia detrás de ella, y asegura el acuerdo explícito de tu patrocinador senior. Este artefacto es tu contrato: define qué significa "terminado" para las siguientes fases y te da la posición para decir no a un alcance que no sirve al problema acordado.

5. Dimensionar la oportunidad y el riesgo honestamente. Estima cuántas personas están afectadas, cuán mal, y qué le cuesta al sistema hoy. Empareja esto con los riesgos que una solución introduciría —clínicos, de gobernanza de la información, de equidad, de entrega. Los líderes financian descubrimientos; deciden sobre la base de una imagen defendible de oportunidad y riesgo, así que dales una.

6. Diseñar para los márgenes desde el primer día. Recluta participantes de investigación a través del espectro de inclusión digital, prueba frente a las expectativas de las Pautas de Accesibilidad para el Contenido Web (WCAG 2.2 AA) temprano, y trata las rutas de asistencia digital y sin conexión como de primer nivel, no como ideas de último momento. En la salud y la atención, el usuario excluido a menudo es el usuario de alta necesidad; un servicio que solo funciona para los confiados y conectados amplía la desigualdad.

7. Mantenerlo multidisciplinario y con límite de tiempo. Dota el descubrimiento de un investigador de usuarios, un diseñador de servicios, una persona de producto, un arquitecto técnico, y —para cualquier cosa que toque la atención— aporte clínico y de gobernanza de la información. Limita el tiempo estrictamente (semanas, no trimestres) para forzar la convergencia. Un descubrimiento sin fin definido es una señal de alerta de que el equipo está evitando una decisión.

8. Escribir qué te haría detenerte. Acuerda, al principio, las condiciones bajo las cuales la recomendación honesta sería "no proceder": ninguna necesidad de usuario genuina, una barrera insuperable de GI o seguridad, una mejor solución no digital, o un problema que posee otro equipo. Un descubrimiento que no puede recomendar detenerse no es un descubrimiento; es una construcción pre-justificada.

Preguntas para debatir con tu equipo#

1. ¿Qué tendríamos que ver en el descubrimiento para recomendar honestamente "no proceder", y alguien en esta sala tiene la posición para decirlo? Las condiciones de parada no valen nada si no se pueden ejercer, y en la salud y la atención la presión para no ejercerlas es intensa: un director ha anunciado la aplicación, un contrato de proveedor está medio firmado, o una ventana de financiación se cierra si el equipo duda. Esta pregunta obliga a un equipo a nombrar la evidencia específica —ninguna necesidad de usuario genuina, una barrera insuperable de gobernanza de la información o seguridad clínica, una mejor solución no digital, un problema que posee otro servicio— que voltearía la recomendación hacia detenerse, y a escribirla antes de que comience la investigación para que no se pueda redefinir silenciosamente después. La tensión que vale la pena debatir es entre la confianza del patrocinador y la independencia del investigador: un descubrimiento que estructuralmente no puede decir no es una construcción pre-justificada vestida con la ropa del descubrimiento. Considera quién protege los hallazgos del investigador de la edición, si un externo revisa la evidencia, y cuál fue el último descubrimiento que tu organización realmente detuvo —si no hay uno, eso en sí mismo es un hallazgo. Una respuesta honesta identifica las razones reales por las que "no" es difícil aquí y un mecanismo concreto (criterios de parada acordados, un desafío independiente, un patrocinador que ha bendecido públicamente la posibilidad de detenerse) que lo hace decible.

2. ¿Quiénes son los usuarios que más probablemente excluiremos, y cómo los incorporaremos a la investigación en lugar de aplazarlos hasta la beta? En la salud y la atención, el usuario excluido —el frágil, el marginado digitalmente, la persona con baja confianza en inglés, el cuidador haciendo malabarismos con tres sistemas— es desproporcionadamente el usuario de alta necesidad al que existe para servir el servicio, así que muestrear por conveniencia diseña silenciosamente la desigualdad en la arquitectura. La disyuntiva a debatir es la profundidad e inclusión frente al calendario y el coste de reclutamiento: alcanzar a los más difíciles de alcanzar toma tiempo, socios comunitarios, incentivos, y métodos de investigación asistidos o sin conexión que un descubrimiento apresurado está tentado a omitir "por ahora". Ángulos concretos incluyen mapear explícitamente el espectro de inclusión digital, reclutar a través de guardianes del sector voluntario y clínico en lugar de una lista de correo, y tratar las rutas de asistencia digital y no digitales como hallazgos de primer nivel en lugar de ideas de último momento. Vale la pena nombrar el deber de igualdad del sector público y el contexto Caldicott para que la inclusión se entienda como una obligación legal y ética, no un detalle agradable. Una buena respuesta produce un plan de reclutamiento nombrado que deliberadamente sobremuestrea los márgenes, y una declaración clara de qué usuarios el equipo tratará como el centro de gravedad del diseño.

3. ¿Hemos enmarcado un problema, o hemos colado una solución en la declaración del problema? Cómo se declara un problema restringe silenciosamente cada solución que considerará el equipo —"los pacientes olvidan las citas" invita a una aplicación de recordatorios, mientras que "los pacientes no pueden reorganizar fácilmente citas que ya no les convienen" invita a la reprogramación de autoservicio y una revisión de política de horarios— así que la redacción de la declaración del problema es donde el descubrimiento se gana la mayor parte de su lugar. El debate es si la solicitud de financiación, el documento de junta, o la propuesta del proveedor ya han fijado la respuesta ("una aplicación", "un portal", "una herramienta de triaje de IA") y la han disfrazado de necesidad, y si el equipo tiene la disciplina para traducir ese deseo de vuelta al objetivo subyacente del usuario. Los ángulos útiles incluyen prohibir sustantivos de solución en la declaración del problema, mapear todo el servicio de extremo a extremo a través de cada canal y organización para que la porción digital se vea en contexto, y comprobar que cada necesidad declarada se expresa desde el punto de vista del usuario en lugar del de la organización. La evidencia importa aquí: un enmarcado debería ser rastreable a lo que dijeron e hicieron usuarios reales, no a un hábito o una diapositiva de estrategia. Una respuesta honesta confirma que la declaración nombra una necesidad de usuario estable con evidencia detrás, o admite que se ha asumido una solución y reabre el enmarcado antes de que se delimite cualquier alfa.

4. ¿Tenemos las disciplinas correctas en la sala, y están la seguridad clínica y la gobernanza de la información dando forma al trabajo en lugar de aprobarlo al final? Un descubrimiento dotado solo de un gestor de producto y un líder de entrega encontrará problemas de producto y entrega; los usuarios, clínicos, y deberes legales que nunca invita a la sala se convierten en los riesgos que salen a la superficie costosamente en alfa o, peor, después de la puesta en marcha. La tensión es que un equipo genuinamente multidisciplinario —investigador de usuarios, diseñador de servicios, arquitecto técnico, oficial de seguridad clínica, experiencia en gobernanza de la información y Caldicott— es escaso, disputado, y lento de convocar, así que los equipos están tentados a "pedir prestado" a un clínico por una hora o añadir GI como un control final. Esa secuenciación es la trampa: la seguridad clínica y la GI son baratas de diseñar durante el enmarcado y ruinosamente costosas de adaptar retroactivamente una vez que una arquitectura asume que los datos fluirán a través de límites organizacionales. Ángulos concretos incluyen nombrar a un oficial de seguridad clínica desde la primera semana para cualquier cosa que toque la atención, tratar una evaluación de impacto en la protección de datos como un artefacto de descubrimiento vivo en lugar de una formalidad posterior, y comprobar si las personas que entienden el flujo de trabajo de primera línea son contribuyentes o meramente consultadas. Una respuesta honesta nombra quién está realmente en el equipo, qué deberes están representados por una persona frente a una casilla, y dónde el descubrimiento sería ciego porque falta una disciplina.

5. ¿Cómo sabremos que el descubrimiento ha terminado, y qué evita que se prolongue durante meses o se corte después de una quincena? El descubrimiento tiene dos modos de fallo opuestos y ambos tratan sobre el tiempo: el estudio ilimitado que mapea todo y no decide nada, y la quincena truncada que se apresura hacia una conclusión predeterminada porque se fijó una fecha de entrega antes de que comenzara la investigación. La disciplina que exige el doble diamante es la convergencia —saber cuándo el problema se entiende lo suficientemente bien como para tomar una decisión defendible, no cuándo se ha respondido cada pregunta, porque la certeza es inalcanzable y el objetivo es la incertidumbre reducida en las cosas que hundirían el proyecto. La disyuntiva que vale la pena debatir es la profundidad frente al impulso: un límite de tiempo estricto de semanas obliga al equipo a priorizar los supuestos más riesgosos, pero un límite fijado demasiado ajustado priva de recursos a la investigación inclusiva y difícil de alcanzar que más necesita este dominio. Los ángulos útiles incluyen acordar la decisión que debe informar el descubrimiento y los artefactos que necesita un patrocinador para tomarla, clasificar los supuestos para que el límite se gaste en lo que importa, y nombrar un punto de decisión en lugar de dejar que la fase se desvanezca en una alfa no reconocida. Una respuesta honesta declara cuánto dura el límite, cómo se ve "entendido lo suficiente" para este problema, y quién declara el final.

6. Cuando termine el descubrimiento, ¿podemos entregar a una junta de financiación una imagen defendible de la oportunidad y el riesgo —o solo una historia? Los líderes no financian la comprensión; financian decisiones, y un descubrimiento que produce una idea rica pero ninguna cuenta legible para la junta de cuántas personas están afectadas, cuán mal, qué le cuesta al sistema hoy, y qué pondría en riesgo una solución deja la decisión a quien cuente la historia más confiada. La tensión es entre los hallazgos matizados y con salvedades del investigador y la necesidad de la junta de un caso dimensionado, comparable, defendible —comprime demasiado y pierdes las sutilezas de equidad y seguridad que eran el punto; niégate a comprimir y la evidencia nunca llega a las personas que asignan el dinero. En la salud y la atención, la imagen debe emparejar la oportunidad con los riesgos que introduciría una solución —clínicos, de gobernanza de la información, de equidad, de entrega— porque una junta que solo ve el lado positivo está siendo preparada para hacer una mala apuesta. Ángulos concretos incluyen dimensionar la población afectada a partir de datos reales en lugar de una estimación esperanzadora, hacer que los hallazgos sean rastreables para que un escéptico pueda seguirlos de vuelta a lo que dijeron los usuarios, y enmarcar la recomendación (incluyendo "no proceder" o "hacer alfa de esta cosa más estrecha") en términos sobre los que la siguiente fase pueda actuar. Una respuesta honesta muestra que el equipo puede pasar de la evidencia a una recomendación que una junta de financiación podría examinar abiertamente sin que se desmorone.

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

Un sistema de atención integrada (ICS) está bajo presión para reducir las tasas de "no asistió" (DNA) en clínicas ambulatorias. Un proveedor ha propuesto una aplicación de recordatorio impulsada por IA, y un director está ansioso por financiarla. En lugar de comprar, el ICS realiza un descubrimiento de ocho semanas.

El investigador de usuarios entrevista a dieciocho pacientes que recientemente perdieron citas, más recepcionistas y dos gestores de clínica. Emerge un patrón que la teoría de los recordatorios pasó por alto: muchos "no se presentaron" habían intentado reorganizar pero se toparon con una línea telefónica ocupada durante días, o se les había dado una cita durante horario laboral que no podían tomar sin perder salario. Un subconjunto había muerto o había sido ingresado en otro lugar y seguía en la lista. Los recordatorios no tocarían ninguna de estas causas.

El equipo mapea el recorrido de reserva de extremo a extremo y encuentra tres organizaciones, dos sistemas de administración de pacientes, y una máquina de fax en el bucle. Replantean el problema de "los pacientes olvidan las citas" a "los pacientes no pueden alcanzarnos fácilmente para reorganizar citas que ya no les funcionan." Lo cuantifican: aproximadamente el 40% de las DNA en las clínicas muestreadas involucraron un intento fallido de contacto previo. Marcan una cuestión de gobernanza de la información (una herramienta de reprogramación compartida cruzaría límites organizacionales) y un hallazgo de equidad (las tasas más altas de DNA estaban entre pacientes en los códigos postales más desfavorecidos, para quienes el horario laboral era la barrera).

El descubrimiento recomienda en contra de la aplicación, y a favor de un alfa explorando la reprogramación de autoservicio más una revisión de la política de programación de horarios. El problema replanteado es acordado por el patrocinador, se nombra un oficial de seguridad clínica para el alfa, y se encarga una evaluación de impacto en la protección de datos. El ICS ha gastado ocho semanas y evitado financiar una solución que habría fallado mensurablemente en público.

Perspectivas sectoriales#

Startup#

Una startup de salud digital realiza el descubrimiento con recursos escasos y contra el reloj —a menudo el "descubrimiento" es la propia experiencia vivida de los fundadores más una quincena de entrevistas de usuario comprimidas entre reuniones con inversores. La presión de financiación es mostrar tracción, lo que tienta a los fundadores a saltar directamente a una demostración; la disciplina que más importa es nombrar el supuesto más riesgoso y matar la idea económicamente si falla, porque una startup no puede permitirse construir lo incorrecto ni siquiera una vez. La responsabilidad recae en inversores y primeros adoptantes en lugar de una junta estatutaria, así que las condiciones de parada son tanto comerciales (sin disposición a pagar, sin mercado alcanzable) como clínicas. La ventaja es la velocidad y la libertad de girar; el riesgo es confundir una narrativa convincente del fundador con evidencia de una necesidad real del usuario.

Pequeña empresa#

Un proveedor pequeño y establecido —una consulta de médico de cabecera, una farmacia comunitaria, una residencia de cuidados, una agencia 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 en marcha, pero rara vez un investigador de usuarios o diseñador de servicios de sobra para dotar un descubrimiento formal. Aquí el descubrimiento es ligero y oportunista: la "investigación" es la recepcionista que ya sabe por qué los pacientes no pueden comunicarse por teléfono, los trabajadores de atención que ven la duplicación de papeleo diariamente, y un puñado de conversaciones deliberadas con los usuarios a los que afectaría un cambio. La trampa es que los mismos deberes estatutarios —Caldicott, UK GDPR, el deber de igualdad, la seguridad clínica— aplican en su totalidad independientemente de si hay alguien internamente que los posea, así que la disciplina que más importa es enmarcar el problema honestamente y probar el supuesto más riesgoso antes de comprometer efectivo escaso al producto de un proveedor. Porque las operaciones continuas no pueden pausarse, un proveedor pequeño a menudo ejecuta su descubrimiento alrededor de un único punto de dolor concreto en lugar de un espacio de problema amplio, y su condición de parada más valiosa es reconocer cuando la solución es un cambio de proceso o una plataforma regional compartida en lugar de un sistema a comprar.

Gran organización#

Un fideicomiso del NHS o un gran proveedor de tecnología de salud puede dotar un descubrimiento multidisciplinario apropiado —investigadores de usuarios, diseñadores de servicios, seguridad clínica, gobernanza de la información— pero debe luchar contra la gravedad organizacional: un contrato de proveedor establecido, una junta que ya ha anunciado "la aplicación", o un caso de negocio que predecidió la solución. Aquí el trabajo más difícil del descubrimiento es político —replantear una solución sancionada de vuelta a una necesidad de usuario sin perder el apoyo del patrocinador. La financiación es anual y vinculada a comités, así que los descubrimientos compiten por espacios y deben producir artefactos legibles para la junta. El apetito de riesgo es bajo y la responsabilidad amplia (reguladores, auditores, el público), lo que hace que un "no proceder" honesto sea tanto más valioso como más difícil de decir en voz alta.

Gobierno#

Un organismo público nacional o local —NHS England, DHSC, un gobierno descentralizado, una autoridad local— realiza el descubrimiento bajo todo el peso del Estándar de Servicio, las puertas de control de gasto, y el escrutinio público, donde el informe de descubrimiento mismo puede publicarse y cuestionarse. La base de usuarios es enorme y el deber de incluir a los marginados es una preocupación legal, no opcional, así que el reclutamiento inclusivo y las rutas de asistencia digital son obligatorias desde la primera semana. La responsabilidad recae en ministros, el Parlamento, y el electorado, así que un descubrimiento debe ser defendible abiertamente y puede ser detenido por controles de gasto cuando la evidencia es débil. La disyuntiva es rigor frente a ritmo: el descubrimiento gubernamental es más lento y más asegurado, lo que protege el dinero público pero puede frustrar a equipos acostumbrados a moverse rápido.

Modos de fallo comunes#

• Solucionar demasiado pronto. El equipo entra al descubrimiento con la respuesta ya elegida y pasa las semanas construyendo un caso de negocio para ella. Antídoto: prohibir sustantivos de solución en la declaración del problema; hacer del supuesto más riesgoso una pregunta de investigación.
• Teatro de investigación. Se consulta a unos pocos interesados amigables, se omiten los usuarios difíciles de alcanzar "por tiempo", y los hallazgos convenientemente confirman el plan. Antídoto: reclutar para los márgenes; hacer que los hallazgos de investigación sean cuestionados por alguien fuera del equipo.
• El descubrimiento que no puede decir no. La financiación, la política, o un contrato firmado hacen que "no proceder" sea indecible, así que el descubrimiento se convierte en ritual. Antídoto: acordar las condiciones de parada de antemano y proteger la independencia del investigador.
• Hervir el océano. Un descubrimiento ilimitado se prolonga durante meses, mapeando todo y decidiendo nada. Antídoto: un límite de tiempo estricto y una decisión nombrada al final.
• Ignorar el servicio no digital. El equipo estudia la pantalla y pasa por alto la línea telefónica, la carta, y la recepcionista que realmente llevan el recorrido. Antídoto: mapear todos los canales y organizaciones de extremo a extremo.
• Tratar la accesibilidad y la inclusión como algo posterior. Los usuarios marginales se aplazan a la beta, momento en el cual la arquitectura ya los excluye. Antídoto: reclutar de forma inclusiva y probar frente a WCAG desde el primer prototipo.

Modelo de madurez#

Lista de verificación#

• Hay una declaración de problema escrita que nombra una necesidad de usuario, no una solución.
• Se ha entrevistado u observado en contexto a usuarios reales —incluyendo a los más difíciles de alcanzar.
• El servicio de extremo a extremo está mapeado a través de todos los canales y organizaciones.
• Los supuestos más riesgosos están listados, clasificados, y los principales probados.
• Se identifican los riesgos de seguridad clínica, gobernanza de la información (Caldicott, UK GDPR/DPIA), y desigualdad en salud.
• La accesibilidad (WCAG 2.2 AA) y la inclusión digital se consideran desde el primer prototipo.
• Las condiciones de parada se acordaron al principio, y "no proceder" es un resultado genuinamente posible.
• La oportunidad está dimensionada y la recomendación es defendible ante una junta de financiación.
• Un equipo multidisciplinario (incluyendo aporte clínico/GI) realizó la fase dentro de un límite de tiempo fijo.
• El patrocinador ha acordado la declaración del problema antes de que comience cualquier alfa.

Fuentes clave#

• NHS England — Manual de Servicio Digital del NHS y Estándar de Servicio del NHS (service.nhs.uk).
• Manual de Servicio de GOV.UK — "Cómo funciona la fase de descubrimiento" y el Estándar de Servicio del Gobierno (Government Digital Service).
• Design Council — el marco de proceso de diseño The Double Diamond.
• NHS England — Criterios de Evaluación de Tecnología Digital (DTAC): seguridad clínica, protección de datos, aseguramiento técnico, interoperabilidad, usabilidad y accesibilidad.
• NICE — Marco de Estándares de Evidencia para Tecnologías de Salud Digital.
• Web Content Accessibility Guidelines (WCAG) 2.2, W3C; y orientación de GOV.UK sobre accesibilidad y digital asistido.
• Principios Caldicott del Reino Unido y la Data Protection Act 2018 / UK GDPR (evaluaciones de impacto en la protección de datos).
• Equality Act 2010 — el deber de igualdad del sector público (relevante para la evaluación de desigualdad en salud en el descubrimiento).

Referencias#

1. Double Diamond (design process model) — Wikipedia — https://en.wikipedia.org/wiki/Double_Diamond_(design_process_model)
2. Design Council — Wikipedia — https://en.wikipedia.org/wiki/Design_Council
3. User research — Wikipedia — https://en.wikipedia.org/wiki/User_research
4. Contextual inquiry — Wikipedia — https://en.wikipedia.org/wiki/Contextual_inquiry
5. Problem statement — Wikipedia — https://en.wikipedia.org/wiki/Problem_statement
6. Web Content Accessibility Guidelines — Wikipedia — https://en.wikipedia.org/wiki/Web_Content_Accessibility_Guidelines
7. Equality Act 2010 — Wikipedia — https://en.wikipedia.org/wiki/Equality_Act_2010
8. NHS Constitution for England — Wikipedia — https://en.wikipedia.org/wiki/NHS_Constitution_for_England
9. Digital divide — Wikipedia — https://en.wikipedia.org/wiki/Digital_divide
10. Privacy impact assessment (data protection impact assessment) — Wikipedia — https://en.wikipedia.org/wiki/Privacy_impact_assessment
11. How the discovery phase works — Government Digital Service, GOV.UK Service Manual — https://www.gov.uk/service-manual/agile-delivery/how-the-discovery-phase-works
12. NHS service standard and NHS digital service manual — NHS England — https://service-manual.nhs.uk/
13. The Double Diamond — Design Council — https://www.designcouncil.org.uk/our-resources/the-double-diamond/
14. Web Content Accessibility Guidelines (WCAG) 2.2 — W3C — https://www.w3.org/TR/WCAG22/
15. Equality Act 2010 — UK legislation (legislation.gov.uk) — https://www.legislation.gov.uk/ukpga/2010/15/contents
16. 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/
17. The Caldicott Principles — National Data Guardian, GOV.UK — https://www.gov.uk/government/publications/the-caldicott-principles
18. Evidence standards framework for digital health technologies — NICE — https://www.nice.org.uk/about/what-we-do/digital-health