1. INTRODUCCIÓN Y ENCUADRE DEL TEMA

La movilidad sanitaria comprende el conjunto de soluciones, dispositivos, servicios y modelos organizativos que permiten acceder a información y ejecutar procesos de salud fuera del puesto fijo tradicional. No se limita a «hacer una app»: incluye el acceso móvil de la ciudadanía, el trabajo en movilidad de profesionales, las notificaciones, la identificación digital, la atención remota, la gestión de dispositivos corporativos, la integración con los sistemas clínicos y administrativos y la continuidad de la relación cuando una interacción pasa de un canal a otro. En una organización sanitaria de gran tamaño, el valor no reside en multiplicar interfaces, sino en conseguir que todas ellas participen en un mismo servicio, apliquen reglas homogéneas y mantengan la seguridad, la trazabilidad y el contexto.

El Servicio Andaluz de Salud opera en un entorno especialmente exigente. Atiende a una población amplia y heterogénea, dispone de numerosos centros y niveles asistenciales, maneja datos de salud —categoría especial de datos personales— y necesita prestar servicios de forma continuada. Una solución móvil puede acercar la cita, los informes, la tarjeta sanitaria virtual o el soporte TIC, pero también puede introducir riesgos: exposición de información en la pantalla bloqueada, pérdida del dispositivo, uso de redes no confiables, credenciales almacenadas de forma insegura, versiones desactualizadas, permisos excesivos o decisiones automatizadas mal controladas. Por ello, movilidad, omnicanalidad y seguridad deben diseñarse conjuntamente.

La Estrategia de Salud Digital de Andalucía 2030, aprobada por Acuerdo del Consejo de Gobierno de 23 de diciembre de 2025 y vigente de 2026 a 2030, sitúa entre sus objetivos mejorar y evolucionar los servicios digitales de salud, incrementar la accesibilidad mediante canales digitales y promover una atención más personalizada y proactiva. La estrategia reconoce expresamente como elementos del ecosistema a ClicSalud+, Salud Andalucía y Salud Responde, contempla la evolución de las aplicaciones móviles corporativas y establece indicadores sobre su uso y valoración. Este marco sustituye las referencias antiguas a una estrategia 2024-2028 que aparecían en materiales previos y debe utilizarse como referencia temporal vigente.

Desde la perspectiva del TFA-STI, este tema conecta ingeniería del software, experiencia de usuario, arquitectura de integración, identidad, ciberseguridad, protección de datos, accesibilidad, gestión de servicios e inteligencia artificial. El técnico no se limita a seleccionar una tecnología. Debe traducir necesidades asistenciales y administrativas en requisitos, decidir qué funciones son apropiadas para cada canal, evitar divergencias entre aplicaciones, diseñar APIs y mecanismos de sincronización, participar en el análisis de riesgos, definir pruebas y métricas, gestionar proveedores y garantizar que el servicio siga siendo comprensible y accesible para quien no pueda o no quiera utilizar un smartphone.

El temario diferencia multicanalidad y omnicanalidad. La primera ofrece varios canales; la segunda los coordina para que la persona no tenga que reiniciar el proceso ni repetir información. También exige estudiar el desarrollo móvil y los chatbots. Estos últimos pueden automatizar consultas, guiar trámites y facilitar soporte, pero en sanidad necesitan límites funcionales, transparencia, supervisión humana y una evaluación estricta cuando sus respuestas puedan afectar a decisiones clínicas.

El objetivo de este tema es proporcionar un marco completo: conceptos, arquitectura, patrones de diseño, seguridad, accesibilidad, gestión de dispositivos, funcionamiento de chatbots, aplicación concreta en el SAS y criterios de gobierno. Para el examen conviene dominar tanto las definiciones como las distinciones prácticas: responsive no equivale a omnicanal; una PWA no elimina la necesidad de seguridad del backend; MDM no es un antivirus; un chatbot no debe confundirse con un motor clínico; y ofrecer muchos canales no garantiza que el servicio esté integrado.

2. MOVILIDAD, MULTICANALIDAD Y OMNICANALIDAD

2.1. Movilidad

En sentido técnico, la movilidad es la capacidad de consumir o prestar un servicio digital desde dispositivos portátiles y contextos variables. El contexto puede cambiar por ubicación, conectividad, tamaño de pantalla, identidad, nivel de confianza del dispositivo, situación asistencial o necesidad de accesibilidad. Una aplicación móvil bien diseñada no replica sin más la aplicación de escritorio: prioriza tareas breves, reduce la introducción de datos, contempla interrupciones, adapta controles táctiles y decide qué información puede almacenarse localmente. En el ámbito profesional también debe considerar guantes, iluminación, uso compartido de terminales, movilidad entre dependencias, roaming Wi-Fi, lectura de códigos y trabajo con conectividad intermitente.

Puede hablarse de movilidad de la ciudadanía —citas, información clínica, tarjeta sanitaria, notificaciones— y movilidad profesional —consulta o registro asistencial, soporte TIC, comunicación, logística, mantenimiento o gestión de recursos—. La primera suele ejecutarse sobre dispositivos personales y redes externas; la segunda puede utilizar terminales corporativos gestionados. Esta diferencia condiciona la autenticación, el soporte, la distribución de aplicaciones, el modelo de propiedad y las capacidades de borrado remoto.

2.2. Multicanalidad

Un sistema es multicanal cuando ofrece varias vías de relación: web, app, teléfono, mensajería, correo electrónico, kiosco, atención presencial o asistente conversacional. Cada canal puede ser correcto de forma aislada, pero no compartir el estado del proceso. En ese caso, una cita iniciada en la web puede no ser visible en el chatbot hasta que se produzca una sincronización; una incidencia registrada por teléfono puede no aparecer en la app; o la persona puede tener que identificarse y explicar de nuevo su necesidad al cambiar de canal. La multicanalidad aumenta la accesibilidad y la disponibilidad, pero puede crear silos, duplicidades y reglas diferentes.

2.3. Omnicanalidad

La omnicanalidad es un nivel de integración superior. Los canales se presentan como distintas interfaces de un mismo servicio, con identidad común, reglas compartidas, datos consistentes y continuidad de contexto. Una interacción iniciada en un chatbot puede escalar a una persona agente conservando el historial; una notificación puede abrir la pantalla exacta de la app mediante un enlace profundo; y un trámite iniciado en móvil puede terminarse en web sin repetir los datos ya validados. La persona elige el canal por conveniencia, no porque una determinada función solo exista en uno.

2.4. Canal, punto de contacto y viaje

Un canal es un medio estable de interacción; un punto de contacto es una interacción concreta dentro del viaje de la persona. La app es un canal, mientras que la recepción de una notificación de cita es un punto de contacto. El journey o viaje representa la secuencia completa: necesidad, descubrimiento, identificación, solicitud, confirmación, seguimiento y cierre. Diseñar solo pantallas produce soluciones fragmentadas; diseñar el viaje obliga a tratar errores, derivaciones, tiempos de espera, accesibilidad y transiciones entre canales.

La continuidad no significa que todos los canales deban ofrecer exactamente lo mismo. Un canal de voz puede ser más adecuado para una persona con baja alfabetización digital; una operación sensible puede requerir identificación reforzada; y ciertas tareas profesionales pueden estar restringidas a un dispositivo corporativo. La omnicanalidad exige que las diferencias sean deliberadas, explicables y coherentes, y que el sistema ayude a la persona a continuar por el canal apropiado sin abandonar el proceso.

3. ECOSISTEMA DIGITAL Y CANALES DEL SSPA

El SSPA dispone de canales dirigidos a ciudadanía y profesionales. Entre los primeros destacan el portal ClicSalud+, la aplicación Salud Andalucía, la aplicación Salud Responde, los servicios telefónicos, las comunicaciones mediante SMS y otros mecanismos de notificación. Entre los canales profesionales se encuentran aplicaciones corporativas, portales de soporte, la app y el escritorio de ayudaDIGITAL, el teléfono y la mensajería. El valor estratégico aparece cuando estos canales consumen capacidades comunes y permiten una transición ordenada.

3.1. ClicSalud+ y Salud Andalucía

ClicSalud+ proporciona acceso en línea a información de salud y a trámites sanitarios frecuentes. La App Salud Andalucía es la aplicación móvil institucional de referencia para las personas usuarias del SAS y ofrece acceso rápido a los servicios de ClicSalud+, además de la tarjeta sanitaria virtual y otros contenidos. La relación entre ambos ilustra un patrón importante: el canal móvil no debe duplicar toda la lógica del portal, sino apoyarse en servicios comunes y presentar una experiencia adaptada al dispositivo.

La tarjeta sanitaria virtual, disponible desde 2026, ejemplifica la convergencia entre identidad física y digital. Su uso exige un proceso de alta e identificación segura, mecanismos de bloqueo y anulación y un diseño que permita mostrar la credencial sin exponer más información de la necesaria. La implementación debe separar la credencial visual del control de acceso a la historia clínica: mostrar un código de tarjeta no equivale a autenticar a la persona para consultar datos de salud.

3.2. Salud Responde

La app Salud Responde está orientada a servicios como la solicitud y modificación de citas de atención primaria y el acceso a contenidos sanitarios. Convive con otros canales de Salud Responde, incluido el telefónico. Desde la arquitectura, esta coexistencia requiere que la agenda, las reglas de disponibilidad, la identificación y los mensajes de confirmación sean coherentes. Si una cita se modifica por teléfono, el cambio debe reflejarse en la app y en ClicSalud+ sin procesos manuales ni dobles reservas.

3.3. ayudaDIGITAL como caso de omnicanalidad profesional

ayudaDIGITAL es el servicio de soporte integral TIC para profesionales del SAS. Ofrece área personal, aplicación móvil, aplicación de escritorio, canal telefónico, WhatsApp y chat. Su asistente AYDI puede resolver determinadas necesidades, consultar el estado de solicitudes y transferir la conversación a una persona agente cuando no encuentra una solución. Este mecanismo de handoff es una propiedad omnicanal: la automatización no cierra el servicio, sino que conserva la interacción y deriva al nivel humano adecuado.

En 2025 se incorporó AlejandrIA, una funcionalidad de AYDI que consulta manuales de aplicaciones y responde a preguntas de los profesionales. Técnicamente se aproxima a un sistema de recuperación de conocimiento: la respuesta debe estar anclada en documentación controlada, actualizada y versionada. El caso demuestra que un chatbot corporativo no es solo un modelo de lenguaje; necesita fuentes, permisos, registro de conversaciones, mecanismos de derivación, evaluación y gobierno editorial.

3.4. Notificaciones y mensajería

Los canales de notificación pueden incluir avisos dentro de la app, notificaciones push, SMS, correo electrónico o llamada. Deben gestionarse mediante un servicio centralizado que aplique preferencias, consentimiento, prioridad, caducidad, reintentos y trazabilidad. La ESDA 2030 contempla un gestor corporativo de notificaciones capaz de enviar mensajes originados en distintas fuentes a través de diversos canales. Esta centralización evita que cada sistema implemente por separado plantillas, proveedores y reglas de reintento.

Una política omnicanal no envía el mismo contenido por todos los medios. Selecciona el canal según sensibilidad, urgencia, confirmación necesaria, coste y preferencias. Una notificación push puede indicar que existe una novedad y abrir la app tras autenticación; el contenido clínico detallado no debería mostrarse en una pantalla bloqueada. Un SMS puede servir para un recordatorio, pero no es un canal apropiado para transmitir información sanitaria compleja o para acreditar por sí solo una identidad.

4. DISEÑO DEL SERVICIO Y CONTINUIDAD OMNICANAL

4.1. Identidad y perfil común

La continuidad comienza por reconocer de forma segura a la misma persona en los distintos canales. Esto no implica mantener una sesión indefinida ni compartir credenciales. La identidad debe resolverse mediante un proveedor común, con niveles de garantía adecuados a cada operación. Los servicios anónimos pueden ofrecer información general; los trámites personales pueden requerir identificación; y el acceso a información clínica sensible debe aplicar autenticación reforzada y autorización contextual. La federación reduce cuentas duplicadas y permite aplicar políticas homogéneas.

El perfil común agrupa preferencias, consentimientos, idioma, necesidades de accesibilidad, canales autorizados y relaciones de representación. No debe confundirse con una base de datos que copie toda la información clínica. El principio de minimización exige almacenar solo los atributos necesarios para personalizar el servicio. La fuente maestra de cada dato debe estar definida: la dirección de contacto, la identidad, la cita y el informe clínico pueden pertenecer a sistemas diferentes, pero las interfaces deben presentarlos de forma coherente.

4.2. Estado del viaje y correlación

Para continuar un proceso entre canales, el backend necesita un identificador de caso o de viaje y un modelo de estados. Por ejemplo: iniciado, pendiente_identificacion, pendiente_documentacion, confirmado, cancelado. El canal no debe inventar estados propios. Cada transición se registra con actor, fecha, canal, resultado y causa, respetando las reglas de auditoría y protección de datos.

POST /v1/tramites/renovacion
Idempotency-Key: 7f6c3d8e-5b25-4c55-a2b1-83d94a326911
X-Correlation-Id: 9a1f0f26-7a63-4c2e-89ee-16f59cba4046

{
  "canal_origen": "movil",
  "idioma": "es",
  "acepta_notificaciones": true
}

El ejemplo muestra dos conceptos distintos. La Idempotency-Key evita duplicar una operación si el móvil reintenta por una pérdida de conectividad; el X-Correlation-Id permite seguir la petición entre componentes y logs. Ambos son especialmente útiles en redes móviles, donde los reintentos y cambios de conexión son habituales.

4.3. Orquestación y reglas centralizadas

Las reglas de negocio críticas deben residir en servicios centrales. Si la app, la web y el chatbot calculan por separado la elegibilidad de un trámite, aparecerán discrepancias. El canal debería validar aspectos de interfaz —campos obligatorios, formato—, pero la decisión final corresponde al dominio. Esto permite cambiar una regla una sola vez, auditarla y probarla de forma independiente.

La orquestación puede implementarse mediante un motor de procesos, servicios de dominio o una arquitectura dirigida por eventos. No existe una solución única. Lo importante es que el estado del proceso sea recuperable, que los fallos parciales tengan compensación y que el usuario reciba un mensaje comprensible. En un proceso sanitario o administrativo no basta con mostrar «error 500»: debe indicarse si la operación no llegó a registrarse, si se reintentará o si requiere contacto humano.

4.4. Handoff y atención humana

El traspaso desde un canal automatizado a una persona agente debe conservar la información relevante, pero no transferir más datos de los necesarios. El agente necesita el motivo, los pasos ya realizados, las validaciones superadas y los mensajes recientes. No debería obligar a repetir el relato completo. A la vez, el sistema debe evitar que un chatbot sin autenticación entregue al agente datos personales que no ha verificado.

El handoff puede ser síncrono —chat en directo o llamada— o asíncrono —creación de solicitud y respuesta posterior—. Debe explicarse el tiempo estimado, ofrecer un número de referencia y permitir consultar el estado. La calidad omnicanal se mide por la resolución del caso completo, no por la capacidad del bot de cerrar conversaciones.

4.5. Diseño inclusivo y elección de canal

La omnicanalidad no debe convertirse en «solo digital». La brecha digital, la discapacidad, la edad, la situación socioeconómica o una caída del servicio pueden impedir el uso del móvil. El diseño debe mantener canales alternativos y ayudar a elegirlos. La persona no debería recibir peor atención por utilizar teléfono o presencialidad; tampoco debe verse obligada a instalar una app para realizar una gestión pública esencial cuando existe una alternativa web o asistida.

5. MODELOS DE DESARROLLO EN CANAL MÓVIL

La elección tecnológica debe partir del servicio, no de una preferencia del equipo. Influyen la necesidad de acceso a sensores, el rendimiento, el modo sin conexión, la frecuencia de actualización, la accesibilidad, la distribución, la seguridad, la reutilización de código y el ciclo de soporte. En una organización pública debe valorarse además la dependencia de proveedor, la disponibilidad de perfiles, la contratación, el mantenimiento a largo plazo y la compatibilidad con dispositivos heterogéneos.

5.1. Aplicaciones nativas

Una aplicación nativa se desarrolla con las herramientas y APIs propias de cada plataforma. En Android son habituales Kotlin y las bibliotecas oficiales; en iOS, Swift y los frameworks de Apple. Su principal ventaja es el acceso completo y temprano a capacidades del dispositivo: cámara, biometría, NFC, almacenamiento seguro, notificaciones, Bluetooth, ejecución en segundo plano o controles de accesibilidad. También facilita seguir los patrones de interacción de la plataforma y optimizar rendimiento y consumo.

El coste es mantener dos implementaciones o, al menos, dos capas de interfaz y adaptación. Las pruebas deben cubrir versiones de sistema operativo, fabricantes, tamaños y configuraciones. En sanidad, la ventaja de una integración profunda puede justificar el coste cuando se necesita lectura de tarjeta, conexión con periféricos, captura clínica, funcionamiento offline robusto o gestión corporativa avanzada.

5.2. Desarrollo multiplataforma e híbrido

Los frameworks multiplataforma permiten compartir parte significativa del código. React Native, Flutter, .NET MAUI o Kotlin Multiplatform son ejemplos de enfoques actuales con modelos diferentes. Las aplicaciones híbridas clásicas encapsulan una aplicación web en un contenedor nativo y acceden a capacidades mediante plugins; Ionic ha sido una referencia conocida en este ámbito. Compartir código reduce duplicación, pero no elimina el trabajo específico de plataforma: permisos, publicación, accesibilidad, notificaciones, almacenamiento seguro y comportamiento del ciclo de vida siguen requiriendo pruebas nativas.

El riesgo aparece cuando se promete «una única base de código» como solución total. Las abstracciones pueden retrasar el acceso a nuevas APIs, introducir dependencias de plugins o generar diferencias de rendimiento. Debe evaluarse la madurez del ecosistema, la política de actualizaciones y la capacidad de abandonar o sustituir el framework. En contratación pública conviene exigir propiedad del código, inventario de dependencias, documentación de construcción reproducible y ausencia de componentes sin mantenimiento.

5.3. Web responsive

Una aplicación web responsive adapta distribución, tipografía, navegación y controles al espacio disponible. Es accesible mediante navegador y se actualiza en el servidor, lo que simplifica el despliegue. Resulta adecuada para trámites, consulta de información y servicios que no necesitan integración profunda con el dispositivo. Su limitación no es solo técnica: la experiencia puede ser menos integrada, las capacidades offline son más restringidas y el comportamiento depende del navegador y del sistema operativo.

Responsive debe combinarse con diseño táctil, rendimiento y accesibilidad. Reducir columnas no basta. Los objetivos táctiles deben tener tamaño suficiente, los formularios deben usar tipos de entrada apropiados, la navegación debe poder realizarse con tecnologías de apoyo y la interfaz debe soportar ampliación, orientación y contraste. Un diseño móvil que obliga a ampliar continuamente o que oculta acciones esenciales tras gestos no documentados no es usable.

5.4. Progressive Web App

Una PWA utiliza capacidades de la plataforma web para ofrecer una experiencia instalable y resiliente. El Web App Manifest aporta metadatos como nombre, iconos, ámbito y modo de visualización. Los service workers permiten interceptar peticiones, gestionar caché y soportar determinados escenarios offline o en segundo plano. La PWA puede reducir la fricción de distribución y mantener una base web común, pero sus capacidades dependen del navegador y no son idénticas en todas las plataformas.

{
  "name": "Servicio móvil de ejemplo",
  "short_name": "Servicio",
  "start_url": "/inicio",
  "display": "standalone",
  "icons": [
    {
      "src": "/icono-192.png",
      "sizes": "192x192",
      "type": "image/png"
    }
  ]
}

El almacenamiento offline exige especial cautela con datos de salud. Un service worker no convierte automáticamente la aplicación en segura; puede ampliar la superficie de caché y persistencia. Deben definirse recursos públicos cacheables, datos que nunca deben almacenarse, expiración, cifrado cuando proceda, borrado al cerrar sesión y comportamiento ante revocación de permisos.

6. ARQUITECTURA DE UNA SOLUCIÓN MÓVIL SANITARIA

La arquitectura debe separar presentación, dominio, integración y persistencia. El móvil es un cliente no confiable: puede perderse, estar comprometido o ejecutar una versión antigua. Las decisiones de autorización y las reglas críticas no deben descansar exclusivamente en él. El servidor valida identidad, permisos, integridad de las operaciones y estado de los datos. Esta premisa evita confiar en campos ocultos, roles almacenados localmente o controles que pueden alterarse mediante ingeniería inversa.

6.1. Arquitectura en capas en el cliente

En el cliente conviene separar la vista, la lógica de presentación, los casos de uso y los repositorios de datos. Patrones como MVVM, MVI o arquitecturas limpias buscan que la interfaz sea sustituible y que la lógica pueda probarse sin un dispositivo real. La elección del patrón es menos importante que mantener dependencias claras, evitar que la pantalla acceda directamente a la red y representar estados de carga, éxito, vacío, error y sesión caducada.

El estado debe sobrevivir a rotaciones, interrupciones y cierre por falta de memoria sin almacenar innecesariamente información sensible. Una operación en curso debe poder reanudarse o descartarse de forma segura. El diseño debe asumir que una llamada, una notificación o el cambio de aplicación interrumpirá el flujo.

6.2. API Gateway y Backend for Frontend

El API Gateway concentra funciones transversales: terminación TLS, validación de tokens, limitación de tasa, enrutamiento, protección frente a abuso y observabilidad. No debe acumular lógica clínica o administrativa compleja. El Backend for Frontend —BFF— adapta los servicios a las necesidades de un canal. Puede agregar respuestas, reducir viajes de red y presentar un contrato apropiado para móvil sin modificar los servicios de dominio.

Un BFF evita que el móvil tenga que invocar diez APIs internas y conocer su topología. También reduce la exposición de servicios y permite evolucionar la interfaz. Sin embargo, no debe convertirse en una copia del dominio. La regla de negocio debe seguir centralizada. Puede existir un BFF para ciudadanía y otro para profesionales porque sus permisos, rendimiento y flujos son distintos.

6.3. Microservicios, modularidad y monolito modular

La escalabilidad omnicanal no exige automáticamente microservicios. Un monolito modular bien diseñado puede ser más fácil de operar y garantizar transacciones. Los microservicios son útiles cuando existen dominios con ciclos de cambio, escalado o equipos independientes, pero añaden complejidad de red, consistencia, observabilidad y despliegue. La decisión debe basarse en límites de dominio y capacidad operativa, no en una moda.

En ambos casos son esenciales los contratos estables y versionados. Una app instalada puede permanecer semanas sin actualizarse, por lo que el backend debe mantener compatibilidad durante un periodo razonable o negociar versiones. Retirar un campo o cambiar su semántica sin estrategia puede dejar a miles de usuarios sin servicio. Las APIs deben evolucionar mediante cambios compatibles, versiones explícitas o capacidades negociadas.

6.4. Eventos y notificaciones

La arquitectura dirigida por eventos desacopla hechos de sus consumidores. Cuando una cita cambia, se publica un evento; el gestor de notificaciones decide si corresponde push, SMS o correo; la app actualiza su estado; y la auditoría registra la acción. El evento representa un hecho de dominio, no un texto de interfaz. Las plantillas y el idioma se resuelven en el canal de comunicación.

Los eventos deben diseñarse con idempotencia, orden y reintentos. En sistemas distribuidos puede recibirse el mismo evento más de una vez. El consumidor debe reconocerlo y evitar una segunda notificación o una doble operación. También debe existir una cola de errores y procedimientos de reproceso controlado.

7. APIs, INTEROPERABILIDAD Y SINCRONIZACIÓN

7.1. Contratos de API

Las APIs deben especificar recursos, operaciones, errores, permisos, límites y compatibilidad. OpenAPI puede documentar APIs HTTP y permitir generación de clientes, pruebas contractuales y publicación controlada. En un entorno sanitario, la documentación no debe exponer ejemplos con datos reales. Los contratos deben distinguir identificadores técnicos de identificadores clínicos y evitar que una URL predecible permita acceder a recursos de otra persona.

REST es frecuente para interacción síncrona, pero no es la única opción. GraphQL puede reducir sobreobtención de datos, aunque exige controles de complejidad y autorización por campo. La mensajería asíncrona es apropiada para notificaciones y procesos largos. En interoperabilidad clínica pueden utilizarse estándares como HL7 FHIR cuando el caso requiera recursos sanitarios normalizados. Adoptar FHIR no elimina la necesidad de perfiles, terminologías, consentimiento y gobierno semántico.

7.2. Errores comprensibles y recuperables

El contrato debe separar el código técnico del mensaje para la persona. Un error como APPOINTMENT_SLOT_NOT_AVAILABLE permite al canal mostrar una explicación y ofrecer alternativas. No deben revelarse trazas, nombres de tablas o detalles internos. El backend debe indicar si el error es reintentable, si requiere nueva autenticación o si la solicitud quedó registrada.

{
  "type": "https://servicios.ejemplo.es/errores/cita-no-disponible",
  "title": "La cita seleccionada ya no está disponible",
  "status": 409,
  "code": "APPOINTMENT_SLOT_NOT_AVAILABLE",
  "correlation_id": "9a1f0f26-7a63-4c2e-89ee-16f59cba4046"
}

El formato se inspira en el patrón de detalles de problema para APIs HTTP. El identificador de correlación permite que soporte encuentre la operación sin pedir a la persona datos técnicos. La aplicación puede actualizar la agenda y mantener los datos ya introducidos.

7.3. Funcionamiento offline

Offline no significa copiar todo el sistema al dispositivo. Deben clasificarse las operaciones: consulta de datos previamente sincronizados, captura local pendiente, acciones que requieren conexión y funciones prohibidas offline. En movilidad profesional puede ser necesario continuar ante zonas sin cobertura; en ciudadanía quizá baste con mostrar información pública y el último estado no sensible. La decisión se basa en riesgo, necesidad asistencial y capacidad de resolver conflictos.

La sincronización debe registrar versión, fecha y origen. Si dos canales modifican el mismo dato, una estrategia «último en escribir gana» puede perder información. Pueden usarse control optimista mediante ETag, versiones de entidad o reglas específicas. Para datos clínicos o administrativos relevantes, el conflicto debe resolverse de forma explícita, no ocultarse.

7.4. Idempotencia y reintentos

Las redes móviles fallan de forma parcial: el servidor puede completar una operación y la respuesta perderse. Si el cliente repite sin idempotencia, puede crear dos solicitudes. Una clave de idempotencia asociada a la identidad, operación y ventana temporal permite devolver el resultado previo. Los reintentos deben aplicar espera progresiva y variación aleatoria para evitar sobrecargar el sistema.

7.5. Integración con sistemas heredados

Los canales modernos suelen integrarse con sistemas de larga vida. No es recomendable que la app acceda directamente a bases de datos corporativas. Una capa de servicios protege el legado, traduce formatos y controla permisos. El patrón anticorrupción evita que modelos antiguos contaminen el contrato público. La evolución puede realizarse gradualmente, sustituyendo capacidades sin cambiar todos los canales simultáneamente.

La disponibilidad del canal no puede superar la de sus dependencias sin mecanismos de degradación. Si el sistema de informes está temporalmente indisponible, la app puede seguir ofreciendo citas y mostrar un mensaje específico. Los circuit breakers, timeouts y cachés controladas evitan que un fallo se propague. La degradación debe preservar seguridad: nunca se omite autorización por estar una dependencia caída.

8. IDENTIDAD, SEGURIDAD Y PROTECCIÓN DE DATOS

La seguridad móvil se diseña por capas. El dispositivo puede estar perdido, rooteado, con malware o conectado a una red hostil. La aplicación puede ser descompilada y sus comunicaciones observadas. El servidor debe asumir que cualquier dato recibido ha podido ser manipulado. A la vez, los controles no deben crear barreras desproporcionadas para personas mayores o con discapacidad. La meta es una seguridad basada en riesgo, usable y verificable.

8.1. Marco normativo

El Reglamento General de Protección de Datos considera los datos de salud una categoría especial. Su tratamiento requiere una base jurídica válida, finalidad determinada, minimización, seguridad y respeto de los derechos. La LOPDGDD completa el marco español. En el sector público, el Real Decreto 311/2022 regula el Esquema Nacional de Seguridad y exige una gestión integral y basada en riesgos, control de accesos, protección de información almacenada y en tránsito, vigilancia continua y reevaluación. La categoría del sistema y las medidas aplicables deben determinarse mediante análisis formal, no por intuición.

La privacidad desde el diseño implica decidir qué datos necesita realmente el canal, cuánto tiempo se conservan, quién puede consultarlos y cómo se informa a la persona. Los SDK de analítica, publicidad o diagnóstico de terceros merecen especial revisión: pueden enviar identificadores, telemetría o contenido fuera del control del responsable. En una app sanitaria no deben incorporarse por comodidad sin evaluación de impacto, contrato, configuración y garantía de transferencias.

8.2. OAuth 2.0, OpenID Connect y PKCE

OAuth 2.0 delega autorización y OpenID Connect añade una capa de identidad. En aplicaciones nativas, el flujo de código de autorización con PKCE protege frente a la interceptación del código. RFC 8252 recomienda utilizar el navegador externo o una pestaña segura del sistema, no un webview embebido que pueda capturar credenciales. RFC 9700 consolida buenas prácticas actuales y exige PKCE para clientes públicos.

1. La app genera code_verifier y code_challenge.
2. Abre el navegador del sistema para autenticar.
3. El servidor devuelve un authorization_code.
4. La app intercambia code + code_verifier por tokens.
5. La API valida firma, audiencia, emisor, caducidad y permisos.

Los tokens no deben almacenarse en preferencias sin protección. Deben utilizarse los almacenes seguros de la plataforma, limitar su vida, rotar tokens de refresco cuando proceda y revocarlos ante pérdida o cierre de sesión. La biometría local puede desbloquear una credencial almacenada, pero no sustituye al proveedor de identidad ni garantiza por sí sola quién está usando el dispositivo.

8.3. Autorización contextual y mínimo privilegio

Autenticar responde a «quién es»; autorizar responde a «qué puede hacer». La API debe comprobar rol, relación, finalidad y contexto. Un profesional no obtiene acceso a toda la historia por pertenecer al SAS; necesita relación asistencial o habilitación conforme a las políticas. Una persona representante puede tener permisos distintos según edad y situación. El canal móvil no debe deducir estos derechos localmente.

8.4. Protección de datos en reposo y tránsito

Las comunicaciones utilizan TLS configurado con algoritmos vigentes y certificados validados. No debe afirmarse que una única versión sea obligatoria en todos los escenarios sin atender a la política aplicable; TLS 1.3 es la versión moderna definida por RFC 8446 y TLS 1.2 puede seguir admitiéndose bajo configuraciones seguras y requisitos corporativos. El pinning de certificados puede aumentar resistencia a intermediarios, pero complica la rotación y debe diseñarse con mecanismos de respaldo.

En reposo se utiliza el almacenamiento seguro de claves, cifrado del dispositivo y bases locales protegidas cuando sean imprescindibles. Los secretos incluidos en el código no son secretos: una clave de API embebida puede extraerse. Las claves privadas de servidor nunca residen en la app. Los logs deben excluir tokens, datos clínicos, documentos y campos de formularios.

8.5. OWASP MASVS y pruebas

OWASP MASVS proporciona controles para almacenamiento, criptografía, autenticación, red, interacción con plataforma, calidad de código, resiliencia y privacidad. Puede utilizarse como referencia de requisitos y aceptación. Se complementa con pruebas estáticas, dinámicas, análisis de dependencias, revisión manual, pruebas de API y ejercicios sobre dispositivos reales. La seguridad móvil no termina con una herramienta automática.

9. GESTIÓN DE DISPOSITIVOS Y APLICACIONES MÓVILES

9.1. Modelos de propiedad

La gestión depende de quién es propietario del terminal y de qué uso se permite. En BYOD, el dispositivo es personal y la organización debe separar el ámbito corporativo sin invadir la privacidad. En COPE, la organización es propietaria y permite cierto uso personal. En COBO, el equipo es corporativo y se dedica exclusivamente al trabajo. También existen dispositivos compartidos o de tarea específica, habituales en entornos asistenciales y logísticos. Cada modelo exige políticas distintas de inscripción, borrado, soporte y responsabilidad.

En sanidad, la elección debe considerar continuidad asistencial, turnos, desinfección, autenticación rápida, préstamo, pérdida, batería y disponibilidad de accesorios. Un terminal compartido requiere cierre automático, cambio ágil de usuario y ausencia de datos persistentes entre sesiones. Un dispositivo asignado puede usar biometría local y certificados vinculados al equipo, pero necesita procedimiento de sustitución.

9.2. MDM, MAM y UEM

MDM gestiona dispositivos: inscripción, configuración, cumplimiento, cifrado, bloqueo, borrado y actualización. MAM se centra en aplicaciones y datos corporativos, incluso con menor control del dispositivo. UEM amplía la gestión unificada a móviles, ordenadores y otros endpoints. Estas plataformas pueden exigir código de bloqueo, impedir versiones vulnerables, distribuir certificados, configurar Wi-Fi o VPN, instalar aplicaciones y ejecutar borrado selectivo.

MDM no sustituye a EDR, antivirus, IAM o gestión de vulnerabilidades. Son capas complementarias. Tampoco garantiza que una aplicación sea segura: puede distribuir una app con defectos. Su valor es aplicar políticas coherentes y conocer el estado del parque. La telemetría debe respetar la proporcionalidad, especialmente en dispositivos personales.

9.3. Distribución y firma

Las aplicaciones ciudadanas suelen distribuirse por tiendas públicas. Las corporativas pueden utilizar tiendas gestionadas o distribución empresarial conforme a las políticas de cada plataforma. Todo paquete debe estar firmado; la clave de firma es un activo crítico porque permite publicar actualizaciones confiables. Debe custodiarse con controles, copias seguras y separación de funciones. Perderla puede impedir actualizar la aplicación; comprometerla permite distribuir software malicioso bajo una identidad legítima.

El proceso de publicación incluye revisión de permisos, textos de privacidad, capturas, clasificación por edad, declaración de uso de datos y seguimiento de políticas de tienda. Una actualización urgente de seguridad puede depender de plazos de revisión externos, por lo que conviene diseñar controles del lado servidor, desactivación de funciones y versiones mínimas soportadas.

9.4. Política de versiones

La fragmentación obliga a definir versiones mínimas de sistema operativo y ventana de soporte. Mantener versiones muy antiguas aumenta la superficie de ataque y el coste de pruebas; abandonarlas demasiado pronto excluye a personas con dispositivos modestos. La decisión se basa en datos de uso, riesgo y alternativas. Debe comunicarse con antelación y proporcionar acceso web cuando sea posible.

El backend puede aplicar feature flags para activar funciones de forma gradual y detenerlas si aparece un problema. No deben utilizarse para eludir pruebas. Las migraciones de datos locales necesitan versiones, rollback y protección frente a pérdida. En terminales corporativos, el despliegue escalonado permite detectar incompatibilidades antes de afectar a todo el parque.

9.5. Redes y posicionamiento

La experiencia móvil depende de Wi-Fi, 4G/5G, VPN y roaming. El diseño debe asumir cambios de red y direcciones IP. No es correcto vincular una sesión exclusivamente a una IP móvil. Para guiado en interiores, GPS pierde precisión y pueden utilizarse balizas Bluetooth, Wi-Fi u otras tecnologías según el caso. La infraestructura física, la calibración y el consentimiento de ubicación son parte del servicio.

10. DATOS LOCALES, NOTIFICACIONES Y CONTEXTO MÓVIL

10.1. Minimización del estado local

La aplicación debe almacenar el mínimo estado necesario. Las preferencias no sensibles pueden persistirse; los tokens van al almacén seguro; los documentos clínicos solo se descargan si existe una necesidad clara y con controles de cifrado, caducidad y borrado. Las miniaturas, capturas y vistas previas pueden quedar en cachés del sistema, por lo que el desarrollador debe conocer el comportamiento de la plataforma y marcar contenido sensible para impedir capturas o previsualización cuando proceda.

El cierre de sesión debe revocar o invalidar credenciales, borrar datos locales vinculados a la cuenta y cancelar tareas. En un dispositivo compartido no basta con volver a la pantalla de inicio. También deben eliminarse notificaciones pendientes y accesos rápidos que revelen información. La restauración automática de copias de seguridad del sistema puede reintroducir datos y debe configurarse.

10.2. Notificaciones push

Las notificaciones push utilizan servicios de plataforma, como FCM en Android y APNs en el ecosistema Apple. El servidor envía a un token de dispositivo, no directamente a una persona. Los tokens cambian, pueden quedar obsoletos y deben asociarse de forma segura a cuentas y dispositivos. Al cerrar sesión se desasocian; los errores permanentes provocan su eliminación.

El payload debe ser mínimo. En lugar de «Su resultado de oncología es…», se comunica «Tiene una nueva información disponible» y se exige autenticación al abrir. El usuario debe poder configurar categorías y horarios, salvo avisos legalmente necesarios. La app debe distinguir notificaciones informativas de órdenes clínicas o alertas urgentes, que requieren canales y garantías adicionales.

{
  "notification_type": "appointment_update",
  "resource_id": "appt_8f3c2a",
  "expires_at": "2026-08-05T12:00:00Z",
  "requires_authentication": true
}

El ejemplo evita incluir nombre, diagnóstico o centro. El resource_id no debe permitir acceso sin autorización. La aplicación consulta el detalle tras validar la sesión. La caducidad impide mostrar avisos antiguos fuera de contexto.

10.3. Enlaces profundos

Un enlace profundo abre una pantalla específica. Debe validarse para evitar redirecciones, suplantación o acceso a rutas no autorizadas. Los enlaces universales o app links verificados son preferibles a esquemas personalizados sin asociación de dominio. Abrir una pantalla no concede permiso: la API vuelve a comprobar identidad y autorización.

10.4. Sensores y permisos

Cámara, micrófono, ubicación, Bluetooth y datos de actividad pueden mejorar servicios, pero cada permiso amplía el riesgo. Se solicita en contexto, cuando la función lo necesita, con una explicación clara. Debe existir alternativa cuando sea posible. La denegación no debe bloquear funciones no relacionadas. Los permisos se revisan porque los sistemas operativos pueden revocarlos o limitar su uso en segundo plano.

Los datos de sensores no se consideran inocuos. Una ubicación puede revelar visitas a centros; una fotografía puede contener documentos; el identificador Bluetooth puede facilitar seguimiento. El análisis de protección de datos debe considerar inferencias, no solo campos explícitos.

10.5. Telemetría y observabilidad

La telemetría ayuda a detectar fallos, latencia, versiones y abandonos, pero debe pseudonimizarse y minimizarse. Los eventos de producto describen acciones funcionales sin capturar contenido. Por ejemplo, appointment_search_failed puede registrar código de error y versión, no el motivo clínico. La correlación con backend utiliza identificadores temporales y accesos restringidos.

Las métricas técnicas incluyen tiempo de arranque, tasa de errores, consumo de batería, ANR, cierres inesperados y éxito de sincronización. Las métricas de servicio incluyen finalización de trámites, resolución en primer contacto, transferencia a agente, repetición de información y satisfacción. Una app estable puede prestar un servicio deficiente si obliga a cambiar de canal.

11. ACCESIBILIDAD, USABILIDAD Y DISEÑO CENTRADO EN LAS PERSONAS

Las aplicaciones móviles del sector público están sujetas al Real Decreto 1112/2018, que transpone la Directiva (UE) 2016/2102. Sus disposiciones para aplicaciones móviles son aplicables desde el 23 de junio de 2021. La norma exige requisitos de accesibilidad, declaración de accesibilidad, mecanismo de comunicación y seguimiento. La conformidad se apoya en la norma europea EN 301 549 vigente y en los criterios WCAG incorporados por referencia.

La accesibilidad es un requisito de calidad y un derecho, no una prueba al final. Afecta a arquitectura de navegación, componentes, contenido, autenticación, documentos y soporte. Una app puede tener botones etiquetados y seguir siendo inaccesible si el flujo de identificación depende de leer un QR sin alternativa o si el tiempo de sesión es insuficiente para una persona con dificultades motoras.

11.1. Principios aplicados al móvil

El contenido debe ser perceptible: texto escalable, contraste, alternativas para imágenes y compatibilidad con lectores de pantalla. Debe ser operable: controles táctiles suficientes, navegación por teclado o dispositivos de apoyo, ausencia de gestos como única vía y tiempo ajustable. Debe ser comprensible: lenguaje claro, errores explicados, etiquetas persistentes y comportamiento predecible. Debe ser robusto: semántica correcta y compatibilidad con tecnologías de asistencia.

Las plataformas ofrecen APIs de accesibilidad. Un botón visual debe exponerse como botón con nombre y estado; una lista debe conservar orden lógico; los cambios de pantalla deben anunciarse; y los gráficos necesitan alternativa textual. Los componentes personalizados requieren más trabajo que los nativos. La accesibilidad se prueba con TalkBack, VoiceOver, ampliación, contraste, tamaño de fuente y navegación alternativa.

11.2. Usabilidad sanitaria

La usabilidad reduce errores y carga cognitiva. En un trámite de salud, las personas pueden estar preocupadas, tener poca experiencia digital o actuar con prisa. Conviene utilizar tareas cortas, mostrar progreso, conservar datos al producirse un error y confirmar acciones irreversibles. Los términos administrativos o clínicos se explican. La interfaz distingue claramente información, recomendación y acción.

La autenticación debe equilibrar seguridad y fricción. Recordar un dispositivo no equivale a mantener acceso ilimitado. Puede aplicarse autenticación escalonada: una sesión permite información de bajo riesgo y se solicita refuerzo para descargar documentos o modificar datos sensibles. Los errores no deben revelar si una persona existe en el sistema, pero sí orientar sobre cómo recuperar acceso.

11.3. Diseño responsive y adaptativo

Responsive reorganiza contenido según espacio; adaptativo puede seleccionar diseños o funciones según contexto. El dispositivo no determina por sí solo el rol: una tableta personal sigue siendo externa y un móvil corporativo puede tener permisos profesionales. La detección contextual debe combinar identidad, postura del dispositivo, red y política.

11.4. Pruebas con personas

La evaluación automática detecta parte de los problemas, pero no sustituye pruebas manuales y con personas. Deben incluirse perfiles diversos, situaciones de baja conectividad y dispositivos reales. Las métricas de éxito incluyen tiempo, errores, abandono y comprensión, no solo satisfacción. Un problema repetido debe incorporarse al sistema de diseño para evitarlo en nuevas pantallas.

12. CHATBOTS Y ASISTENTES VIRTUALES: FUNDAMENTOS Y ARQUITECTURA

12.1. Definición y tipos

Un chatbot es una interfaz conversacional que recibe mensajes y produce respuestas o acciones. Puede ser textual o de voz. Los chatbots basados en reglas siguen árboles y comandos; los basados en NLU clasifican intenciones y extraen entidades; los generativos producen texto mediante modelos de lenguaje; y los asistentes transaccionales combinan conversación con herramientas que consultan o modifican sistemas. En sanidad, la clasificación importa porque determina riesgo, verificabilidad y capacidad de prueba.

Un bot de preguntas frecuentes puede responder desde un catálogo. Un bot transaccional puede consultar una cita tras autenticar. Un asistente de soporte puede buscar manuales y escalar a agente. Un sistema que orienta sobre síntomas puede influir en decisiones de salud y requiere límites, validación clínica y evaluación regulatoria muy superiores.

12.2. Intenciones, entidades y diálogo

La intención representa el objetivo: consultar_cita, recuperar_contrasena o registrar_incidencia. Las entidades aportan parámetros: fecha, centro, aplicación o identificador. El gestor de diálogo mantiene slots, estado y contexto. Debe manejar ambigüedad, negación, correcciones y cambios de tema. Una confianza baja no se resuelve inventando: se pregunta, ofrece opciones o deriva.

{
  "intent": "consultar_estado_solicitud",
  "confidence": 0.94,
  "entities": {
    "numero_solicitud": "AD-2026-004812"
  },
  "next_action": "require_authentication"
}

La respuesta técnica no debe contener datos antes de autenticar. El bot puede reconocer la intención, pero la acción consulta una API autorizada. La conversación y la lógica de negocio permanecen separadas.

12.3. Recuperación aumentada y conocimiento

En un esquema RAG, la consulta se transforma en una búsqueda sobre documentos autorizados; se recuperan fragmentos; y el modelo genera una respuesta apoyada en ellos. Esto reduce, pero no elimina, alucinaciones. La calidad depende de fuentes, segmentación, metadatos, permisos y evaluación. Los manuales deben tener propietario, versión y fecha. Los documentos obsoletos se retiran del índice.

El sistema debe mostrar o registrar la fuente utilizada, establecer umbrales y responder «no dispongo de información suficiente» cuando corresponda. Para procedimientos críticos puede preferirse una respuesta extractiva o plantilla aprobada. La generación libre no debe alterar requisitos legales, instrucciones clínicas ni pasos de seguridad.

12.4. Herramientas y acciones

Los modelos modernos pueden invocar herramientas: consultar una cita, crear una solicitud o recuperar un manual. El modelo propone una llamada estructurada; una capa de control valida esquema, permisos y contexto; y el servicio ejecuta. Nunca se concede al modelo acceso directo a bases de datos o credenciales. Las acciones sensibles requieren confirmación y pueden exigir autenticación reforzada.

La conversación debe ser idempotente. Si la persona pulsa dos veces o el bot reintenta, no se crean dos citas. La respuesta de la herramienta se transforma en lenguaje, pero los datos importantes se presentan de forma estructurada y verificable.

12.5. Integración omnicanal

El bot es un canal adicional. Debe consumir las mismas APIs, identidad y reglas que la web y la app. Puede estar integrado en web, app, WhatsApp o escritorio, pero la lógica de conversación debe ser reutilizable. El historial se conserva según finalidad y política; no se transfiere sin control entre contextos personales y profesionales.

El handoff incluye resumen, intención, entidades y pasos realizados. El agente puede corregir la clasificación y esa información alimenta la mejora, con datos anonimizados o pseudonimizados. El objetivo no es maximizar respuestas automáticas, sino resolver de forma segura.

13. SEGURIDAD, ÉTICA Y REGULACIÓN DE LOS CHATBOTS SANITARIOS

13.1. Transparencia

La persona debe saber que interactúa con un sistema automatizado. El Reglamento europeo de Inteligencia Artificial establece obligaciones de transparencia para sistemas destinados a interactuar directamente con personas, salvo que resulte evidente por el contexto. En la práctica, el asistente debe identificarse, explicar su finalidad, advertir de sus límites y ofrecer acceso a atención humana. No debe presentarse como profesional sanitario ni inducir a pensar que una respuesta generada constituye un diagnóstico.

La transparencia incluye indicar qué datos se utilizan, si la conversación se conserva, cómo se puede reclamar y qué ocurre al escalar. Un aviso genérico de privacidad no basta cuando el bot solicita información sensible. La información se ofrece en el momento apropiado y con lenguaje comprensible.

13.2. Delimitación funcional

El catálogo de intenciones debe definir lo permitido y lo prohibido. Son apropiados los horarios, la orientación de navegación, el estado de una solicitud, la recuperación de manuales o la preparación de un trámite. Son más delicadas la interpretación de síntomas, la recomendación terapéutica, la priorización clínica o la modificación de tratamientos. Cuando el software persigue una finalidad médica puede entrar en el ámbito del Reglamento de productos sanitarios y, según su uso y clasificación, en obligaciones adicionales del Reglamento de IA.

La frontera no depende de que el producto se llame «chatbot». Depende de su finalidad prevista, las afirmaciones del proveedor y el impacto de la salida. Un asistente administrativo no se convierte en producto sanitario por hablar de salud general; un sistema que recomienda una actuación clínica puede tener una finalidad médica aunque use la misma tecnología.

13.3. Riesgos de modelos generativos

Los modelos generativos pueden alucinar, mezclar fuentes, reproducir sesgos o responder a instrucciones maliciosas. La prompt injection intenta alterar la conducta mediante contenido del usuario o de documentos recuperados. Debe aislarse el contenido no confiable, limitar herramientas, validar salidas y aplicar listas de acciones permitidas. La entrada de un manual no debe poder ordenar al sistema que revele secretos o ignore políticas.

La protección no se consigue con un único prompt. Se requieren arquitectura de mínimo privilegio, filtros, evaluación, monitorización y revisión humana. Los secretos no se incluyen en el contexto del modelo. Las herramientas reciben tokens de alcance mínimo y los resultados se filtran. Las conversaciones se someten a controles contra exfiltración, abuso y contenido peligroso.

13.4. Privacidad y minimización

El bot debe evitar solicitar datos que no necesita. Para una pregunta general no se identifica a la persona. Para consultar una solicitud, se autentica y utiliza un identificador interno. Los mensajes pueden contener espontáneamente datos clínicos; el sistema debe clasificarlos, aplicar retención y restringir acceso. El uso de proveedores externos exige contrato, localización, transferencias y garantía de que los datos no se reutilizan para entrenar modelos sin base jurídica.

13.5. Evaluación y supervisión

Las métricas incluyen exactitud de intención, cobertura, tasa de no comprensión, resolución, escalado, tiempo y satisfacción. Para RAG se evalúan recuperación, fidelidad a fuente, completitud y abstención. En casos sanitarios se añaden seguridad, sesgo y revisión clínica. Un bot que responde con fluidez pero no sabe abstenerse es peligroso.

La evaluación utiliza conjuntos representativos, variantes lingüísticas, errores ortográficos, lenguaje coloquial y casos adversariales. Debe repetirse tras cambios de modelo, documentos o prompts. La versión de cada componente queda registrada para reproducir una respuesta ante una incidencia.

14. CASOS DE USO EN EL SERVICIO ANDALUZ DE SALUD

14.1. Ciudadanía: acceso y trámites

La App Salud Andalucía actúa como referencia móvil institucional. Sus casos de uso incluyen acceso a servicios de ClicSalud+, consulta de información y tarjeta sanitaria virtual. La arquitectura debe ofrecer acceso rápido sin convertir la pantalla inicial en un catálogo inabarcable. La personalización puede priorizar tareas frecuentes, pero debe permitir encontrar el resto y evitar inferencias sensibles visibles antes de autenticación.

ClicSalud+ representa el canal web y comparte capacidades con la app. La coherencia exige mismas reglas de cita, documentos y representación. Si una función existe solo en web por razones técnicas, la app debe informar y abrir una transición segura, no dejar a la persona sin explicación. A medida que la ESDA 2030 impulsa la evolución de servicios, las decisiones deben registrarse en un mapa de capacidades por canal.

14.2. Citas y recordatorios

La cita es un viaje omnicanal clásico: búsqueda, selección, confirmación, recordatorio, modificación y cancelación. Puede iniciarse en app, continuar por teléfono y finalizar en web. El sistema maestro de agenda debe ser único. Las notificaciones incorporan enlaces profundos y caducidad. La cancelación debe reflejarse inmediatamente para liberar recursos y evitar mensajes posteriores.

14.3. Tarjeta sanitaria virtual

La tarjeta sanitaria virtual permite presentar la identificación desde el móvil. Deben gestionarse alta, almacenamiento, bloqueo, desbloqueo, anulación y sustitución. El código visual se protege frente a uso indebido y se diferencia de credenciales de acceso. La experiencia contempla menores y representación, con niveles de identificación adecuados.

14.4. Salud Responde

La app Salud Responde complementa el canal telefónico. La transición debe ser bidireccional: la información de citas se comparte y el teléfono puede atender excepciones. En picos de demanda, la automatización puede absorber operaciones sencillas, mientras los agentes atienden situaciones complejas. La prioridad no es desviar llamadas a cualquier coste, sino asignar cada necesidad al canal apropiado.

14.5. Profesionales y ayudaDIGITAL

La movilidad profesional incluye la app ayudaDIGITAL, el escritorio y la mensajería. Una incidencia puede registrarse desde el móvil, consultarse en área personal y continuar por chat. AYDI automatiza tareas y deriva a agente. AlejandrIA recupera conocimiento de manuales. Este caso reúne omnicanalidad, chatbot, RAG, soporte y gestión de conocimiento.

El sistema debe conservar un único expediente de solicitud, no crear uno por canal. Los mensajes, adjuntos y cambios de estado se integran con permisos. La persona agente ve el contexto y la persona profesional recibe notificaciones sin exponer detalles en la pantalla bloqueada.

14.6. Recursos humanos

mGerhonte y E-atención al profesional ilustran canales móviles y web para servicios de personal. La omnicanalidad exige inventariar funciones, permisos y diferencias. Algunas operaciones pueden reservarse a web por seguridad o complejidad, pero la decisión debe ser explícita. Las discrepancias históricas utilizadas en preguntas de examen se estudian como ejemplo, no como garantía del estado actual.

14.7. Telemonitorización y movilidad clínica

La ESDA 2030 contempla telemonitorización de pacientes crónicos y conexión con la historia clínica. Estos proyectos añaden dispositivos, datos continuos, alertas y responsabilidades. Deben definir qué medida es válida, cómo se calibra, qué ocurre sin conexión, quién revisa alertas y en qué plazo. Una app que recoge constantes no garantiza un servicio de telemonitorización si no existe circuito asistencial.

En movilidad clínica, los terminales pueden consultar o registrar datos junto a la cama, leer códigos o coordinar tareas. La seguridad incluye autenticación rápida, bloqueo automático, limpieza, batería, conectividad y modo degradado. La usabilidad se evalúa en el entorno real, no solo en laboratorio.

15. GOBIERNO, CICLO DE VIDA, PRUEBAS Y OPERACIÓN

15.1. Gobierno de canales

La organización necesita un catálogo de canales y capacidades. Para cada servicio se identifica propietario funcional, propietario técnico, datos, APIs, nivel de seguridad, accesibilidad, métricas y soporte. Un comité de gobierno decide prioridades y evita crear una nueva app para cada necesidad. La ESDA 2030 impulsa la racionalización de sistemas y la mejora continua de aplicaciones móviles corporativas, coherente con este enfoque.

El design system comparte componentes, lenguaje, accesibilidad y patrones entre web y móvil. No obliga a que todas las pantallas sean idénticas, sino a que la experiencia sea reconocible. Los componentes se versionan y prueban. El catálogo de APIs hace lo mismo en el backend.

15.2. Descubrimiento y requisitos

Antes de desarrollar se investigan personas, tareas y contexto. Las historias de usuario se complementan con requisitos no funcionales: disponibilidad, latencia, accesibilidad, seguridad, privacidad, soporte offline, versiones y observabilidad. Se modelan viajes y excepciones. Los prototipos permiten validar sin construir el sistema completo.

Los criterios de aceptación incluyen transiciones de canal. Por ejemplo: «Dado un trámite iniciado en móvil, cuando la persona accede por web con la misma identidad, entonces recupera el estado y continúa desde el último paso confirmado». También se definen escenarios de pérdida de conexión, token caducado, actualización pendiente y derivación a agente.

15.3. DevSecOps móvil

La integración continua compila, analiza dependencias, ejecuta pruebas y firma artefactos en entornos controlados. Las claves no se almacenan en el repositorio. La cadena de suministro se protege con inventario de componentes, revisión de plugins y generación de SBOM. Los entornos separan desarrollo, pruebas y producción. Las cuentas de tienda aplican MFA y mínimo privilegio.

Las pruebas incluyen unitarias, integración, contrato de API, interfaz, accesibilidad, rendimiento, seguridad y compatibilidad. Los emuladores son útiles, pero se necesitan dispositivos reales y redes degradadas. Los chatbots añaden pruebas de intención, conversación, recuperación, seguridad y regresión.

15.4. Despliegue y actualización

El despliegue escalonado limita impacto. Se observa telemetría antes de ampliar. Las feature flags permiten desactivar funciones. El backend mantiene compatibilidad con versiones soportadas. Cuando una versión es insegura, puede exigirse actualización, pero debe distinguirse entre bloqueo total y restricción de funciones sensibles.

15.5. Operación y soporte

La operación necesita cuadros de mando, alertas y procedimientos. Se vigilan disponibilidad de APIs, latencia, errores, éxito de autenticación, entrega de notificaciones y tasas de caída. Los logs se correlacionan sin datos sensibles. El soporte recibe versión, dispositivo y correlation ID, evitando pedir capturas con información clínica.

Los acuerdos de nivel de servicio deben abarcar el viaje completo. La app puede estar disponible mientras una API crítica falla. Por eso se miden SLI de negocio: porcentaje de citas completadas, documentos abiertos o solicitudes resueltas.

15.6. KPIs omnicanal

16. RETOS Y TENDENCIAS

16.1. Brecha digital

La principal amenaza de una estrategia centrada en móvil es excluir a quien carece de dispositivo, conectividad, habilidades o apoyo. La ESDA 2030 incorpora accesibilidad universal, humanización y capacitación digital. Las soluciones deben ofrecer alternativas, ayuda contextual, formación y atención asistida. El éxito no se mide solo por descargas, sino por acceso efectivo.

16.2. Fragmentación y deuda técnica

Muchas apps con funciones solapadas generan confusión y coste. La tendencia es concentrar capacidades, reutilizar identidad y notificaciones y racionalizar el catálogo. Esto no implica una «superapp» monolítica sin límites; puede existir una experiencia unificada sobre módulos y servicios independientes. La gobernanza decide cuándo integrar y cuándo mantener una app especializada.

16.3. IA generativa

Los asistentes generativos mejoran búsqueda y lenguaje natural, como muestra AlejandrIA. El reto es garantizar fuentes, permisos, trazabilidad y abstención. Los modelos pueden ejecutarse en infraestructura propia o servicios externos, pero la decisión debe considerar coste, latencia, soberanía, seguridad y actualización. No se debe trasladar información sanitaria a un servicio público de IA sin autorización y contrato.

16.4. Wearables e Internet de las cosas

Relojes, sensores y dispositivos domésticos pueden aportar datos, pero su calidad y finalidad varían. La integración requiere identificar dispositivo, unidad, frecuencia, calibración y contexto. No todos los datos de consumo son aptos para decisión clínica. La interoperabilidad y el gobierno de alertas son más importantes que el volumen.

16.5. 5G, edge y conectividad

5G puede mejorar capacidad y latencia, pero no elimina zonas sin cobertura ni garantiza calidad extremo a extremo. Edge computing acerca procesamiento a la fuente, útil para latencia o privacidad, pero añade nodos que gestionar. La arquitectura debe degradarse con seguridad y no depender de condiciones ideales.

16.6. Credenciales digitales

La tarjeta sanitaria virtual y la evolución de la identidad europea impulsan credenciales móviles. Deben aplicarse minimización, revocación, verificación y separación entre identificación y autorización. Una credencial prueba atributos; la aplicación destino decide si permiten la acción.

16.7. Sostenibilidad

La movilidad también consume recursos: dispositivos, baterías, redes y centros de datos. Un diseño eficiente reduce transferencias, procesos en segundo plano y actualizaciones. La prolongación del soporte debe equilibrarse con seguridad. La compra corporativa considera reparabilidad, ciclo de vida y borrado seguro.

17. CONCLUSIONES E IDEAS CLAVE PARA EL REPASO

La movilidad es una capacidad organizativa y técnica que permite prestar servicios en contextos variables. El móvil no es un simple tamaño de pantalla: introduce interrupciones, redes cambiantes, sensores, almacenamiento local, pérdida del dispositivo y distribución mediante tiendas. La arquitectura debe asumir un cliente no confiable y mantener reglas y autorización en el servidor.

Multicanalidad significa disponer de varios canales. Omnicanalidad significa integrarlos con identidad, contexto, datos y reglas comunes. Responsive solo adapta la interfaz. La continuidad se apoya en identificadores de viaje, estados compartidos, APIs, eventos, idempotencia y handoff a personas agentes.

Los modelos de desarrollo —nativo, multiplataforma, híbrido, web responsive y PWA— se seleccionan por requisitos. PWA utiliza manifest y service workers, pero no elimina límites de plataforma ni riesgos de caché. Ionic es un referente de desarrollo híbrido preguntado en examen.

La seguridad se fundamenta en RGPD, LOPDGDD, ENS, CCN-STIC y referencias como OWASP MASVS. OAuth 2.0 y OpenID Connect con PKCE son patrones relevantes para clientes públicos. MDM gestiona dispositivos; no es equivalente a EDR, CMS ni GPO. Las notificaciones minimizan contenido y exigen autenticación para acceder al detalle.

La accesibilidad móvil del sector público se rige por el Real Decreto 1112/2018 y la norma EN 301 549 aplicable. Debe integrarse desde diseño y probarse con tecnologías de apoyo. La omnicanalidad debe mantener alternativas para evitar exclusión digital.

Los chatbots pueden ser reglados, basados en NLU o generativos. Intenciones, entidades, diálogo, RAG y herramientas son componentes distintos. La respuesta generativa no es una acción autorizada: una capa de control valida permisos y llamadas. En sanidad son esenciales transparencia, límites, abstención, supervisión y posible evaluación como producto sanitario según la finalidad.

En el SAS, Salud Andalucía, ClicSalud+, Salud Responde, ayudaDIGITAL, AYDI y AlejandrIA ofrecen ejemplos concretos. La ESDA 2030 constituye el marco estratégico vigente y contempla evolución de aplicaciones, accesibilidad digital, notificaciones y medición de servicios.

18. MAPA CONCEPTUAL