Tema 3.3 — Servicios digitales orientados a pacientes y ciudadanos

Un servicio digital orientado al paciente es una intervención de salud pública por derecho propio: puede ampliar el acceso y la confianza para millones, o excluir silenciosamente a las mismas personas que más necesitan atención, y cómo lo construyes decide cuál.

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

Cuando pones un servicio directamente en las manos del público, cambias la relación entre una persona y el sistema que la cuida. Un sistema orientado al personal lo usan personas capacitadas dentro de un entorno controlado; un servicio orientado al paciente lo usa un padre asustado a las 2 de la madrugada, una persona de 84 años que comparte un teléfono con un vecino, alguien sin dirección fija, alguien que lee poco inglés, alguien en crisis. No eliges a tus usuarios, no los capacitas, ni te paras a su lado. El servicio tiene que funcionar —de forma segura, clara y justa— para todos a quienes el sistema de salud está obligado a servir, no meramente para los confiados y conectados.

Esa obligación es lo que hace esto diferente de la tecnología de consumo. En el comercio minorista, un pago confuso pierde una venta. En la salud y la atención, un formulario de triaje en línea confuso, una instrucción de medicación poco clara, o un flujo de "reservar una cita" que falla silenciosamente puede llevar a un diagnóstico perdido, una dosis incorrecta, o una persona que se rinde y se presenta más tarde y más enferma. Las consecuencias son clínicas (véase el Tema 1.6 — Seguridad clínica y gestión de riesgos), legales (los deberes de igualdad y accesibilidad vinculan a los organismos públicos), y financieras, porque el dinero público se gasta tanto si el servicio realmente ayuda a alguien como si no.

También hay una dimensión de confianza que los productos de consumo rara vez llevan. Las personas traen sus datos de salud, sus miedos, y toda una vida de experiencia con el NHS a cada pantalla que les muestras. Si el servicio se siente extractivo, opaco, o inseguro, no simplemente lo abandonarán —perderán la confianza en la institución detrás de él (véase el Tema 1.8 — Ética de datos, consentimiento y confianza pública). Y porque las personas menos capaces de navegar un servicio digital pobre son desproporcionadamente mayores, más pobres, discapacitadas, o digitalmente excluidas, los servicios orientados al paciente mal diseñados amplían activamente las desigualdades en salud. Hacer esto bien no es una cuestión de pulido. Es una cuestión de equidad, seguridad, y confianza pública.

Conceptos clave#

Un servicio orientado al paciente es la "puerta de entrada digital": el punto de entrada en línea a través del cual una persona encuentra información, prueba quién es, y comienza una tarea. En Inglaterra las dos plataformas nacionales que más personas encuentran son la aplicación del NHS y NHS login. La aplicación del NHS, desarrollada por NHS England, permite a las personas en Inglaterra reservar y gestionar citas con el médico de cabecera, pedir recetas repetidas, ver su registro mantenido por el médico de cabecera, acceder a NHS 111 en línea, y establecer preferencias de intercambio de datos y donación de órganos. NHS login es el servicio separado de identidad y autenticación que verifica quién es una persona (a un nivel proporcionado de aseguramiento) para que pueda alcanzar de forma segura su propio registro a través de muchos servicios diferentes del NHS y asociados —de forma muy similar a como GOV.UK Verify una vez pretendió hacer para el gobierno central. Es importante describirlos con precisión: la aplicación del NHS es una puerta de entrada y una aplicación, mientras que NHS login es la capa de identidad que muchas aplicaciones y sitios web, no solo la aplicación del NHS, pueden usar.

Detrás de la puerta de entrada se sitúan registros y herramientas. Una historia clínica electrónica (EHR) es el registro mantenido por el clínico y sostenido por un proveedor. Un registro de salud personal (PHR) es un registro que el paciente puede ver, al que puede añadir, y a veces controlar, dándole una vista más completa de su propia atención. Un portal de paciente es la interfaz web o de aplicación a través de la cual las personas ven resultados, mensajes, cartas, y registros, y se comunican con su equipo de atención. "El acceso del paciente a los registros" —el derecho a leer tu propio registro de médico de cabecera y cada vez más el hospitalario— es ahora una expectativa predeterminada en Inglaterra, no un favor.

Varios tipos de servicio funcionan encima. La consulta en línea y el triaje en línea permiten a una persona describir un problema digitalmente para que pueda ser dirigido y priorizado sin una cola telefónica. La toma de decisiones compartida en medicina es la práctica de que el clínico y el paciente lleguen juntos a decisiones de atención, apoyados por información clara y ayudas de decisión —capturada en la frase del NHS "ninguna decisión sobre mí, sin mí". Las herramientas de autogestión ayudan a las personas a gestionar condiciones a largo plazo día a día. El monitoreo remoto de pacientes y la telesalud extienden la atención al hogar a través de dispositivos, video, y mensajería asíncrona.

Los conceptos que deciden si algo de esto funciona tratan de personas, no de funcionalidades. La adopción es si las personas comienzan a usar un servicio; la activación es si llegan al punto de obtener valor de él; y la participación sostenida es si continúan usándolo cuando importa. El Patient Activation Measure (PAM) es un instrumento validado para una idea relacionada —el conocimiento, las habilidades, y la confianza de una persona para gestionar su propia salud. Frente a todo esto se sitúa la brecha digital: la brecha en el acceso, la conectividad, y la confianza que significa que un servicio de salud digital puramente digital dejará atrás a algunas personas a menos que se preserven deliberadamente las rutas de asistencia digital y no digitales (véase el Tema 1.9 — Inclusión digital y accesibilidad).

Buenas prácticas#

1. Diseñar toda la puerta de entrada, no una aplicación. Decide deliberadamente qué canales puede usar una persona para alcanzar cada tarea —aplicación, sitio web, teléfono, en persona, a través de un cuidador o proxy— y hazlos consistentes en lugar de competir. Un servicio orientado al paciente es un conjunto de rutas hacia una necesidad, no una única descarga. Mapea dónde la ruta digital se traspasa a una humana y haz esa costura elegante, porque la mayoría de los recorridos reales la cruzan. Trata la elección de canal como algo que le corresponde al usuario, no a ti para forzar.

2. Usar plataformas nacionales en lugar de reconstruirlas. Donde la aplicación del NHS y NHS login ya proporcionan identidad, acceso a registros, citas, y recetas, intégrate con ellas en lugar de construir una puerta de entrada paralela que fragmenta la experiencia y el modelo de seguridad. Esto da a los usuarios una identidad confiable y un lugar donde mirar, y hereda trabajo de aseguramiento que de otro modo repetirías. Reserva la construcción a medida para necesidades genuinamente locales que las plataformas nacionales no satisfacen, y retroalimenta esas necesidades a los equipos nacionales (véase el Tema 9.0 — Colaboración con organizaciones asociadas).

3. Dar a las personas acceso real a sus propios registros, y hacerlo legible. El acceso a los registros construye confianza y apoya la autogestión, pero un registro volcado en pantalla en taquigrafía clínica puede confundir o asustar. Invierte en diseño de contenido para que los resultados, cartas, y entradas codificadas sean comprensibles, y piensa cuidadosamente sobre la información sensible, la salvaguarda, y cómo un proxy o cuidador ve los datos de otra persona (véase el Tema 1.10 — Salvaguarda en los servicios digitales). El acceso del paciente es un problema de diseño, no solo un interruptor para encender.

4. Preservar las rutas de asistencia digital y no digitales como una funcionalidad permanente. Para cada tarea en línea, mantén una forma asistida y una forma completamente sin conexión de completarla, y dótalas de recursos apropiadamente en lugar de tratarlas como sobrecarga heredada. "Digital por defecto" nunca debe significar "solo digital", porque una proporción significativa de la población no puede o no quiere usar la ruta digital, y son desproporcionadamente aquellos con mayor necesidad. Diseña la ruta asistida —una línea telefónica, una recepcionista, un ayudante de biblioteca, un proxy familiar— con el mismo cuidado que la aplicación (véase el Tema 1.9 — Inclusión digital y accesibilidad).

5. Hacer que el triaje en línea sea clínicamente seguro por diseño. Cualquier herramienta que pregunte sobre síntomas y dirija a las personas debe construirse y gobernarse como una actividad de seguridad clínica, con escalada clara para síntomas de bandera roja y un sesgo hacia el sobretriaje seguro. Aplica los estándares relevantes de gestión de riesgo clínico, mantén a un oficial de seguridad clínica nombrado involucrado, y monitorea los resultados en busca de atención perdida o retrasada (véase el Tema 1.6 — Seguridad clínica y gestión de riesgos). Un flujo de triaje que falla silenciosamente no es un defecto de usabilidad; es un incidente de seguridad del paciente.

6. Apoyar la toma de decisiones compartida, no solo las transacciones. El mayor valor en lo digital orientado al paciente es ayudar a las personas a entender opciones y tomar decisiones que se ajusten a sus vidas, no meramente reservar horarios. Ofrece ayudas de decisión, información en lenguaje llano, y avisos que inviten preguntas, y diseña para que una persona pueda pausar, involucrar a la familia, y regresar. Mide si las personas se sienten más informadas y con más control, porque ese es el punto de la herramienta. Las transacciones son necesarias; la deliberación es donde mejoran los resultados.

7. Instrumentar para resultados y experiencia, no métricas vanidosas. Las descargas y los registros casi no te dicen nada; un servicio puede tener millones de usuarios registrados y no cambiar la salud de nadie. Mide la activación y el uso sostenido y significativo, la finalización de tareas, y —donde puedas— resultados clínicos reales y medidas de experiencia y resultado reportadas por el paciente (PREM y PROM). Publica estos junto a los números de adopción para que la organización no pueda confundir alcance con valor (véase el Tema 10.0 — Objetivos y resultados clave (OKR)).

8. Construir confianza a través de la claridad, el consentimiento y la seguridad. Diles a las personas claramente qué hace un servicio, qué no hace, quién ve sus datos, y cómo obtener ayuda o alcanzar a un humano. Haz que las elecciones de consentimiento e intercambio de datos sean genuinas y reversibles, y nunca uses patrones oscuros para hacer que las personas compartan más de lo que pretenden (véase el Tema 1.8 — Ética de datos, consentimiento y confianza pública). En la salud, la confianza es la plataforma sobre la que funciona todo lo demás; una violación de ella cuesta mucho más de lo que cualquier funcionalidad gana.

9. Diseñar para la interoperabilidad desde el principio. Un servicio orientado al paciente que no puede leer de y escribir en los registros subyacentes es un silo que crea doble introducción de datos y error. Usa estándares abiertos para que las reservas, mensajes, y observaciones fluyan hacia y desde los sistemas que realmente usan los clínicos, y para que los datos de una persona la sigan a través de un panorama de atención fragmentado (véase el Tema 4.3 — Interoperabilidad y estándares de datos). El público experimenta la interoperabilidad como "no tengo que repetirme" —y su ausencia como peligro y frustración.

10. Cerrar el bucle con investigación continua y operaciones en vivo. Sigue investigando con usuarios reales y diversos después del lanzamiento, no solo antes de él, y dirige lo que aprendes de vuelta al backlog (véase el Tema 3.0 — Investigación de usuarios y diseño de servicios). Opera el servicio como un producto en vivo con soporte, monitoreo, y respuesta a incidentes apropiados, porque un servicio orientado al paciente que está caído o roto erosiona la confianza instantáneamente (véase el Tema 3.8 — Gestión de servicios y operaciones en vivo). La adopción se gana continuamente, no se captura una vez.

Preguntas para debatir con tu equipo#

1. ¿Quién no puede usar este servicio de la forma en que lo hemos diseñado, y qué le sucede a esa persona? Cada servicio orientado al paciente incorpora supuestos —que las personas tienen un teléfono inteligente, datos, una dirección de correo electrónico, una identidad fija contra la cual verificar, y la alfabetización y confianza para completar un formulario, y la vista, destreza, e idioma para hacerlo. Nombra los grupos que tu diseño actual excluye o desfavorece, y sé específico: personas sin identidad verificable por el NHS, personas que comparten un dispositivo, personas huyendo del abuso que no pueden arriesgarse a un rastro digital, personas con deterioro cognitivo. Para cada uno, decide cuál es realmente la ruta asistida o no digital, quién la dota de recursos, y cómo sabrás que funciona. Una respuesta buena y honesta no afirma servir a todos a través de la aplicación; nombra a los excluidos, los cuantifica donde sea posible, y muestra una alternativa financiada y digna en lugar de un número de teléfono simbólico que nadie contesta. Aquí es donde se gana o se pierde la equidad, y se conecta directamente con el Tema 1.9 — Inclusión digital y accesibilidad.

2. ¿Cómo sabremos que este servicio realmente mejora la salud, no solo que las personas se registraron? Es fácil celebrar los registros y las descargas porque son contables y suben; es mucho más difícil, y mucho más importante, mostrar que alguien está mejor. Discute qué resultado estás realmente tratando de mover —menos citas perdidas, condiciones a largo plazo mejor controladas, presentación más temprana, decisiones más informadas— y cómo detectarías un cambio en él. Debate la disyuntiva entre las métricas que puedes recopilar económicamente ahora y las medidas más difíciles de activación, uso sostenido, y resultado clínico que dicen la verdad. Considera quién es responsable si la adopción es alta pero los resultados son planos, y si estás dispuesto a cambiar o detener el servicio si la evidencia dice que no está ayudando. Una respuesta sólida vincula el servicio a un pequeño número de medidas honestas de resultado y experiencia, admite lo que aún no puedes medir, y se niega a dejar que las métricas vanidosas sustituyan al valor (véase el Tema 1.3 — Decisiones basadas en evidencia y el Tema 10.0 — Objetivos y resultados clave (OKR)).

3. ¿Dónde compensa la conveniencia digital frente a la seguridad clínica, y quién decide? Las herramientas orientadas al paciente crean tensiones reales: el acceso más rápido puede significar menos supervisión clínica; el autotriaje puede pasar por alto la presentación sutil que un clínico captaría; mostrar a las personas sus resultados en crudo puede informar o alarmar; permitir que las personas reserven directamente puede socavar la priorización. Trabaja a través de dónde se inclina tu servicio hacia la conveniencia y dónde debe inclinarse hacia la cautela, y haz esas elecciones explícitas en lugar de emergentes. Pregunta quién posee el caso de seguridad clínica, cómo escalan los síntomas de bandera roja, y cómo monitoreas el daño que solo aparece agregado con el tiempo. Considera también el ángulo de salvaguarda —un servicio que asume que la persona en pantalla es quien dice ser, y está segura, no siempre tiene razón (véase el Tema 1.10 — Salvaguarda en los servicios digitales). Una buena respuesta trata la seguridad como una entrada de diseño desde el primer día, con un oficial de seguridad clínica nombrado y monitoreo en vivo, no como una aprobación de cumplimiento al final.

4. Cuando la ruta digital entrega a una persona a una humana, ¿cuán elegante es esa costura —y quién atrapa lo que se cae por ella? Casi todo recorrido real de paciente cruza de la aplicación a una persona y a veces de vuelta otra vez: un triaje en línea que dirige a una devolución de llamada, una reserva que necesita que una recepcionista la resuelva, una solicitud de proxy que necesita verificarse, un resultado que provoca un mensaje preocupado. Estos traspasos son donde los servicios silenciosamente fallan, porque cada lado asume que el otro tiene a la persona y el contexto. Mapea las transiciones específicas que crea tu servicio y pregunta qué información viaja a través de ellas, cuánto tiempo espera la persona, y qué sucede si ninguno de los lados la recoge. Debate si la ruta digital realmente está reduciendo la carga sobre el personal o meramente la está moviendo a algún lugar menos visible, y si los equipos de primera línea fueron diseñados con, no solo entregados, el nuevo flujo (véase el Tema 3.0 — Investigación de usuarios y diseño de servicios). Una respuesta honesta puede rastrear a una persona de extremo a extremo a través de cada costura, nombra quién posee el traspaso, y muestra la alternativa para cuando la ruta automatizada no puede terminar el trabajo —en lugar de asumir que la puerta de entrada digital cierra el bucle por sí misma.

5. ¿Cuál es el coste total de operar esto bien durante años, y estamos honestamente dotados de recursos para cumplirlo? Los servicios orientados al paciente a menudo se financian como proyectos —una construcción, un lanzamiento, un titular— cuando en verdad son productos en vivo que deben ser apoyados, monitoreados, investigados, y mejorados indefinidamente, junto con las rutas de asistencia digital y no digitales que nunca pueden reemplazar completamente. Discute qué cuesta realmente mantener la línea telefónica dotada de personal, el contenido actualizado, la accesibilidad mantenida, el caso de seguridad clínica vivo, y las integraciones funcionando a medida que las plataformas nacionales cambian debajo de ti. Saca a la luz la incómoda disyuntiva de que un servicio genuinamente inclusivo es más costoso que uno solo digital, y decide si el caso de negocio se construye sobre financiación recurrente real o sobre ahorros optimistas que asumen que todos cambian de canal. Considera qué dejarás de hacer para pagar esto, y quién es responsable cuando la financiación del segundo año se evapora pero el servicio y sus usuarios permanecen. Una respuesta sólida trata la sostenibilidad y el soporte como costes de primer nivel desde el principio (véase el Tema 3.8 — Gestión de servicios y operaciones en vivo y el Tema 6.1 — Economía de la salud), no como una idea de último momento una vez que se gasta el presupuesto de lanzamiento.

6. ¿Quién posee este servicio una vez que termina el lanzamiento, y tiene el mandato para seguir cambiándolo? Un servicio orientado al paciente que nadie posee como un producto vivo se desvía: el contenido se vuelve obsoleto, la accesibilidad retrocede, la integración se rompe silenciosamente, y la investigación se detiene el día que el equipo del proyecto se disuelve. Discute quién sostiene el servicio después de la puesta en marcha, si es un equipo de producto genuino con la autoridad para priorizar, cambiar, e incluso apagar funcionalidades, o meramente una función de mantenimiento que solo puede mantener las luces encendidas. Examina cómo se toman las decisiones cuando los interesados clínicos, operativos, de gobernanza de la información, y de comunicaciones todos tienen un interés y un veto, y si esa vía de decisión es lo suficientemente rápida para arreglar un problema de seguridad o lo suficientemente lenta para proteger uno. Considera cómo la retroalimentación de los usuarios y el personal de primera línea realmente llega a las personas que pueden actuar sobre ella, y si la organización seguirá financiando a un equipo para mejorar algo que ya parece funcionar. Una respuesta honesta nombra al propietario responsable, describe su mandato real y cómo el aprendizaje en vivo alimenta el backlog, y admite dónde la gobernanza protege o paraliza el servicio (véase el Tema 5.0 — Trabajo liderado por producto).

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

Un sistema de atención integrada (ICS) que cubre una población mixta urbana y costera quiere reducir la presión sobre las líneas telefónicas de médicos de cabecera y mejorar el acceso, y propone desplegar una herramienta de consulta y triaje en línea integrada con la aplicación del NHS y NHS login. La tentación es medir el éxito por el número de registros y la caída en el volumen de llamadas, y declarar la victoria dentro de un trimestre.

El líder de entrega insiste en enmarcarlo de forma diferente. En el descubrimiento, el equipo investiga con un grupo deliberadamente amplio: usuarios confiados de la aplicación, pero también una mujer mayor en la costa con banda ancha intermitente, un hombre con baja alfabetización que nunca ha usado correo electrónico, una cuidadora que gestiona citas para su madre como proxy, y una mujer en un refugio que no puede arriesgarse a que se registre su paradero. Encuentran que el manejo de banderas rojas del formulario de triaje es sólido pero que su lenguaje derrota al usuario de baja alfabetización, que el recorrido de proxy es confuso, y que la verificación de identidad en NHS login excluye a personas sin pasaporte o licencia de conducir. Fundamentalmente, encuentran que cuando se despriorizará la línea telefónica a favor de la aplicación, los usuarios costeros y vulnerables simplemente pierden contacto en lugar de cambiar de canal.

Así que el ICS reinicia su plan. Mantiene la línea telefónica completamente dotada de personal como la ruta de asistencia digital, no como un coste heredado, y financia un esquema comunitario de "ayudante de salud digital" a través de bibliotecas y farmacias. Trabaja con el equipo nacional de la aplicación del NHS en el recorrido de proxy en lugar de construir una solución alternativa, y nombra a un oficial de seguridad clínica para poseer el caso de riesgo de triaje con monitoreo para casos donde el triaje digital subclasificó a un paciente que luego se presentó agudamente. También cambia sus medidas: junto a la adopción, rastrea la finalización de tareas por grupo de usuario, uso sostenido, experiencia reportada por el paciente, y un pequeño conjunto de resultados clínicos. Seis meses después, las descargas son más bajas de lo que habría producido un impulso puro de aplicación primero, pero el acceso ha mejorado en todos los grupos incluyendo los más excluidos, y la herramienta de triaje ha escalado de forma segura varias presentaciones graves. La junta directiva acepta la adopción más lenta porque el servicio es demostrablemente más justo y más seguro.

Perspectivas sectoriales#

Startup#

Una pequeña empresa de salud digital vive o muere por la adopción y la retención, así que instrumentará la participación obsesivamente e iterará rápido —una fortaleza genuina de la que el sistema más amplio puede aprender. El peligro es optimizar para las métricas que impresionan a los inversores (descargas, usuarios activos mensuales) en lugar de resultados de salud, y diseñar para los primeros adoptantes confiados que son más baratos de adquirir. Una startup que vende al NHS debe mostrar que cumple con los Criterios de Evaluación de Tecnología Digital (DTAC), se integra con NHS login y estándares abiertos en lugar de atrapar a los usuarios en un silo, y tiene un caso de seguridad clínica creíble. Los fundadores que ganan contratos a largo plazo son los que tratan la inclusión y la seguridad como requisitos de producto, no como carga de cumplimiento.

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— tiene pacientes reales y un deber de cuidado pero casi ninguna capacidad digital o de TI dedicada, así que su movimiento realista es adoptar plataformas nacionales y herramientas de proveedores en lugar de construir su propia puerta de entrada. Debería apoyarse fuertemente en la aplicación del NHS, NHS login, y los sistemas de consulta en línea ya asegurados para su entorno, y gastar su escaso esfuerzo en la costura humana: asegurarse de que la recepción, los clínicos, y los cuidadores puedan manejar lo que la ruta digital les envía y que las rutas telefónica y sin cita previa permanezcan genuinamente abiertas para sus pacientes a menudo mayores o más frágiles. Los mismos deberes de accesibilidad, seguridad clínica, y consentimiento la vinculan como vinculan a un gran fideicomiso, pero sin un equipo de gobernanza, así que debe saber qué proveedor carga con el caso de seguridad clínica y qué obligaciones siguen siendo suyas. Un proveedor pequeño que trata su sistema elegido como un servicio en vivo para configurar y monitorear, no una casilla marcada en la compra, servirá a su comunidad mucho mejor que uno que activa los valores predeterminados y mira hacia otro lado.

Gran organización#

Un gran fideicomiso del NHS o un ICS opera servicios orientados al paciente a escala a través de un patrimonio fragmentado, así que su problema central es la coherencia: múltiples portales, cartas, y aplicaciones que cada uno resuelve una tarea y colectivamente confunden al paciente. Su ventaja es el alcance y la capacidad de financiar apropiadamente las rutas de asistencia digital y no digitales; su riesgo es la inercia, la contratación en silos, y una tendencia a comprar otro portal en lugar de integrarse con plataformas nacionales. La gobernanza es más pesada y lenta, lo que protege la seguridad pero puede privar de recursos a la iteración, así que la gran organización necesita equipos de producto con mandato real para seguir mejorando los servicios en vivo (véase el Tema 5.0 — Trabajo liderado por producto). La medida de madurez es si un paciente experimenta una puerta de entrada coherente o una docena de puertas desconectadas.

Gobierno#

Un organismo nacional como NHS England construye las plataformas —la aplicación del NHS, NHS login, acceso a registros— sobre las que todos los demás construyen, así que sus decisiones establecen el techo para la equidad y la interoperabilidad en todo el sistema. Su responsabilidad es ante el Parlamento y el público por el gasto, la seguridad, y la equidad, lo que correctamente eleva el listón sobre la accesibilidad, la transparencia, y la preservación de rutas no digitales. La tarea difícil es equilibrar una experiencia nacional única y consistente frente a una variación local genuina, y resistir la atracción política de celebrar cifras de registro titulares por encima de resultados reales. La palanca única del gobierno son los estándares y valores predeterminados: lo que exige para la identidad, la interoperabilidad, y la accesibilidad da forma a millones de interacciones que nunca diseñará directamente.

Modos de fallo comunes#

• Teatro de registro. Reportar descargas e inscripciones como éxito mientras nadie comprueba si alguien obtiene valor o mejor salud. Arréglalo midiendo la activación, el uso sostenido, y los resultados desde el principio.
• Deslizamiento solo digital. Retirar o infrafinanciar silenciosamente las rutas telefónica y en persona una vez que existe la aplicación, lo que excluye a los más vulnerables. Arréglalo tratando lo asistido-digital y lo no digital como funcionalidades permanentes y financiadas.
• Proliferación de portales. Cada servicio compra su propio portal de paciente, así que el público enfrenta un laberinto de inicios de sesión. Arréglalo integrándote con plataformas nacionales y estándares abiertos.
• Triaje como funcionalidad, no como caso de seguridad. Lanzar enrutamiento de síntomas sin gobernanza de seguridad clínica o monitoreo de daño. Arréglalo aplicando estándares de riesgo clínico y nombrando a un oficial de seguridad clínica.
• Registros sin comprensión. Exponer datos clínicos en crudo sin diseño de contenido, alarmando o confundiendo a los pacientes. Arréglalo con contenido en lenguaje llano y manejo cuidadoso de datos sensibles y acceso por proxy.
• Consentimiento por patrón oscuro. Empujar a las personas hacia el intercambio de datos que no entienden, corroyendo la confianza. Arréglalo con un consentimiento genuino, llano, y reversible.
• Lanzar y abandonar. Tratar el servicio como un proyecto que termina en la puesta en marcha en lugar de un producto en vivo que debe ser investigado, apoyado, y mejorado.

Modelo de madurez#

Lista de verificación#

• Para cada tarea, existe y está financiada una ruta digital, una asistida-digital, y una no digital
• El servicio se integra con la aplicación del NHS y NHS login en lugar de duplicar la identidad o la puerta de entrada
• Los pacientes pueden acceder a sus propios registros en un idioma que puedan entender, con manejo seguro de proxy y datos sensibles
• Cualquier triaje o enrutamiento de síntomas tiene un caso de seguridad clínica, un oficial de seguridad nombrado, y escalada de bandera roja
• Las medidas de éxito incluyen activación, uso sostenido, finalización de tareas, y resultados reales —no solo descargas
• Las elecciones de consentimiento e intercambio de datos son llanas, genuinas, y reversibles, sin patrones oscuros
• La accesibilidad cumple con WCAG y se prueba con tecnología de asistencia y usuarios excluidos reales
• Las reservas, mensajes, y observaciones fluyen hacia y desde los sistemas clínicos vía estándares abiertos
• El servicio opera como un producto en vivo con soporte, monitoreo, y respuesta a incidentes
• La investigación con una población diversa continúa después del lanzamiento y alimenta el backlog

Fuentes clave#

• NHS England — orientación y documentación para desarrolladores de la aplicación del NHS y NHS login
• Estándar de Servicio del NHS y Manual de Servicio Digital del NHS — diseñar servicios públicos accesibles e inclusivos
• Manual de Servicio de GOV.UK (Government Digital Service) — digital asistido, elección de canal, y diseño de servicios
• NHS England — estándares de gestión de riesgo clínico DCB0129 y DCB0160 para TI de salud
• Criterios de Evaluación de Tecnología Digital (DTAC) — línea base de NHS England para tecnologías de salud digital
• Marco de Estándares de Evidencia de NICE para Tecnologías de Salud Digital
• Web Content Accessibility Guidelines (WCAG) — W3C
• Programa de Toma de Decisiones Compartida NHS RightCare
• Insignia Health / Judith Hibbard — Patient Activation Measure (PAM)

Referencias#

1. NHS app — Wikipedia — https://en.wikipedia.org/wiki/NHS_app
2. Personal health record — Wikipedia — https://en.wikipedia.org/wiki/Personal_health_record
3. Electronic health record — Wikipedia — https://en.wikipedia.org/wiki/Electronic_health_record
4. Patient portal — Wikipedia — https://en.wikipedia.org/wiki/Patient_portal
5. Shared decision-making in medicine — Wikipedia — https://en.wikipedia.org/wiki/Shared_decision-making_in_medicine
6. Remote patient monitoring — Wikipedia — https://en.wikipedia.org/wiki/Remote_patient_monitoring
7. Telehealth — Wikipedia — https://en.wikipedia.org/wiki/Telehealth
8. Patient Activation Measure — Wikipedia — https://en.wikipedia.org/wiki/Patient_Activation_Measure
9. Digital divide — Wikipedia — https://en.wikipedia.org/wiki/Digital_divide
10. Digital health — Wikipedia — https://en.wikipedia.org/wiki/Digital_health
11. GOV.UK Verify — Wikipedia — https://en.wikipedia.org/wiki/GOV.UK_Verify
12. NHS App — NHS England — https://www.nhs.uk/nhs-app/
13. NHS login — NHS England — https://www.nhs.uk/nhs-services/online-services/nhs-login/
14. NHS Service Manual and Service Standard — NHS England — https://service-manual.nhs.uk/
15. GOV.UK Service Manual: Assisted digital and channel choice — Government Digital Service — https://www.gov.uk/service-manual/helping-people-to-use-your-service
16. Clinical risk management standards DCB0129 and DCB0160 — NHS England — https://digital.nhs.uk/services/clinical-safety
17. Digital Technology Assessment Criteria (DTAC) — NHS England — https://www.nhs.uk/about-us/digital-technology-assessment-criteria-dtac/
18. Evidence Standards Framework for Digital Health Technologies — NICE — https://www.nice.org.uk/about/what-we-do/digital-health
19. Web Content Accessibility Guidelines (WCAG) 2.2 — W3C — https://www.w3.org/TR/WCAG22/