1. INTRODUCCIÓN Y CONCEPTO DE PUESTO DE TRABAJO DIGITAL

El puesto de trabajo digital es el conjunto coordinado de medios tecnológicos que permite a una persona profesional identificarse, acceder a la información autorizada, ejecutar aplicaciones, comunicarse, generar documentos y completar procesos de negocio. No se reduce al ordenador visible sobre una mesa. Comprende el dispositivo, sus periféricos, el sistema operativo, el navegador, las aplicaciones locales o remotas, la identidad digital, la conectividad, los mecanismos de seguridad, la configuración corporativa, el soporte y los servicios centrales que hacen posible la actividad. En una organización sanitaria, además, el puesto se integra con sistemas clínicos, administrativos y logísticos cuyo fallo puede afectar directamente a la continuidad asistencial.

La evolución tecnológica ha desplazado el centro de gravedad desde el equipo físico hacia el servicio de puesto. En el modelo tradicional, cada ordenador constituía una unidad relativamente autónoma: almacenaba programas y datos, se configuraba de manera individual y requería intervención local. En el modelo moderno, la identidad, las políticas, las aplicaciones, los perfiles y buena parte de los datos se administran de forma centralizada. El mismo profesional puede iniciar una sesión autorizada desde distintos terminales y recuperar un entorno coherente, siempre dentro de las condiciones de seguridad y del alcance funcional definido por la organización.

En el Servicio Andaluz de Salud, el puesto digital se encuentra condicionado por la dispersión geográfica de centros, la variedad de perfiles profesionales, la coexistencia de actividad asistencial y administrativa, la necesidad de atender consultas y domicilios, la presencia de equipamiento clínico y la obligación de proteger datos relativos a la salud. Un puesto de admisión, uno de consulta de Atención Primaria, una estación de diagnóstico por imagen y una tableta utilizada en movilidad comparten componentes corporativos, pero no tienen los mismos requisitos de rendimiento, periféricos, disponibilidad ni aislamiento.

El diseño debe equilibrar varias dimensiones. La funcionalidad determina qué aplicaciones y dispositivos necesita el perfil. La seguridad establece controles sobre identidad, autenticación, configuración, cifrado, registro y acceso. La disponibilidad obliga a considerar redundancia, recuperación y modos de contingencia. La usabilidad evita que un control técnicamente correcto genere retrasos o errores en la atención. La mantenibilidad permite actualizar miles de equipos de manera homogénea. La economía examina el coste total durante todo el ciclo de vida, no solo el precio inicial de compra.

El Real Decreto 311/2022, que regula el Esquema Nacional de Seguridad, dedica medidas específicas al puesto de trabajo y a los dispositivos portátiles. Entre otras cuestiones, exige caracterizar el puesto, mantener una configuración de seguridad adecuada, bloquearlo tras un periodo prudencial de inactividad y limitar los servicios accesibles cuando un dispositivo portátil se conecta desde redes que no controla estrictamente la organización. Estas medidas no obligan a una única tecnología, pero sí a gobernar el puesto conforme a la categoría del sistema y al análisis de riesgos.

La protección de datos añade obligaciones específicas. Los datos de salud son categorías especiales de datos conforme al Reglamento General de Protección de Datos. Por ello, cualquier solución de movilidad, virtualización, impresión o digitalización debe aplicar minimización, control de acceso, confidencialidad, trazabilidad, conservación limitada y protección desde el diseño. La centralización puede reducir la presencia de datos en los terminales, pero no elimina el riesgo: una sesión remota mal autenticada, una impresión abandonada o una captura enviada a un destino incorrecto siguen constituyendo incidentes de seguridad.

Este tema estudia, en primer lugar, la arquitectura y las tipologías del puesto; después, la movilidad y los modelos BYOD; a continuación, la virtualización de escritorios y aplicaciones; y, finalmente, la impresión, la digitalización y el caso particular del puesto de Atención Primaria del SAS y del sistema LETSAS. El hilo conductor será la decisión técnica: qué componente resuelve cada problema, qué riesgo introduce y cómo se integra dentro de una plataforma corporativa sanitaria.

2. ARQUITECTURA FUNCIONAL Y CICLO DE VIDA DEL PUESTO

Un puesto de trabajo corporativo se construye mediante capas. La primera es el hardware: equipo de sobremesa, portátil, terminal ligero, tableta o teléfono, junto con monitor, teclado, lector de tarjetas, cámara, auriculares, impresora, escáner y otros periféricos. La segunda es el firmware, que incluye BIOS o UEFI y el firmware de dispositivos. La tercera es el sistema operativo, responsable de ejecutar procesos, administrar memoria, almacenamiento y dispositivos, y aplicar mecanismos básicos de seguridad. Sobre él se sitúan agentes corporativos, aplicaciones y servicios de usuario.

La identidad constituye una capa transversal. El acceso no debería depender únicamente de conocer una contraseña, sino de una identidad personal gestionada, un directorio corporativo, mecanismos de autenticación acordes al riesgo y una autorización basada en perfiles. La misma identidad se utiliza para iniciar sesión, acceder a aplicaciones, solicitar certificados, conectarse a recursos remotos y dejar trazas atribuibles. En entornos virtualizados, la identidad también determina qué escritorio o aplicación se asigna y qué recursos locales pueden redirigirse.

La conectividad incluye red cableada, Wi-Fi, redes móviles, VPN o mecanismos de acceso remoto, DNS, DHCP, proxies y pasarelas. No es un mero transporte. La red puede aplicar segmentación, control de acceso, inspección y políticas diferenciadas según el tipo de dispositivo. Un puesto clínico, un equipo de electromedicina y un dispositivo de invitado no deben quedar necesariamente en el mismo segmento ni disfrutar de idéntico alcance.

La administración moderna utiliza una configuración base o línea de referencia. Esta define versión de sistema operativo, parámetros de seguridad, software autorizado, certificados, políticas de navegador, reglas de firewall, bloqueo de pantalla, cifrado y agentes obligatorios. La configuración debe ser reproducible y verificable. Cuando cada equipo se configura manualmente, aparecen desviaciones: versiones diferentes, aplicaciones no autorizadas y controles desactivados. La gestión centralizada permite detectar y corregir estas diferencias.

El ciclo de vida comienza antes de la compra. La organización debe definir perfiles de puesto, requisitos de compatibilidad, prestaciones mínimas, necesidades de accesibilidad, garantía, consumo energético y condiciones de soporte. La homologación reduce la variedad de modelos y simplifica controladores, repuestos e imágenes. En la recepción se inventaría el activo, se asocia a una ubicación o responsable y se incorpora a la plataforma de gestión. Después se realiza el aprovisionamiento: instalación, inscripción en el dominio o plataforma de gestión, aplicación de políticas, instalación de software y validación.

Durante la explotación, el puesto recibe parches, actualizaciones de aplicaciones, renovaciones de certificados, cambios de configuración y soporte. La gestión de vulnerabilidades necesita conocer inventario, versión, exposición y criticidad. La monitorización puede detectar falta de espacio, errores recurrentes, pérdida de conexión o incumplimiento de política. La telemetría debe ser proporcional, estar gobernada y no convertirse en una recogida indiscriminada de información sobre las personas usuarias.

La retirada es una fase de seguridad. Un equipo que deja de prestar servicio puede conservar credenciales, cachés, archivos temporales, certificados o datos en almacenamiento interno. Debe darse de baja del inventario, revocarse su relación con la identidad y realizarse borrado seguro o destrucción del soporte según el riesgo. En dispositivos móviles gestionados se aplican acciones equivalentes: retirada de aplicaciones, revocación de tokens y borrado corporativo o total según el modelo de titularidad.

3. PUESTOS PESADOS Y PUESTOS LIGEROS

La distinción entre puesto pesado y puesto ligero describe dónde se ejecuta el trabajo y qué capacidad reside en el extremo. Un cliente pesado dispone de sistema operativo general, almacenamiento y potencia suficiente para ejecutar aplicaciones localmente. Un cliente ligero concentra su función en iniciar sesión, establecer una conexión y presentar aplicaciones o escritorios ejecutados en servidores. Entre ambos existen configuraciones híbridas: un equipo puede ejecutar navegador y ofimática local, pero consumir una aplicación clínica publicada de forma remota.

3.1. Cliente pesado

El cliente pesado ofrece autonomía y control local de recursos. Es apropiado cuando la aplicación necesita CPU, memoria, gráficos, almacenamiento o periféricos con baja latencia; cuando debe trabajar temporalmente sin conexión; o cuando la virtualización introduce incompatibilidades. Estaciones de imagen, desarrollo, análisis estadístico o aplicaciones con dispositivos especializados pueden justificarlo. La ventaja no procede de «ser un PC» sino de disponer de capacidad local y acceso directo al hardware.

Su principal coste es operativo. Cada equipo aloja un sistema completo que debe parchearse, protegerse e inventariarse. Las dependencias de software pueden entrar en conflicto; las versiones divergen; el almacenamiento local aumenta la superficie de exposición; y una avería puede dejar al usuario sin su entorno si los datos y perfiles no están centralizados. Una buena plataforma de gestión reduce estos problemas mediante imágenes estandarizadas, distribución de software, cifrado, copia de perfiles y control de aplicaciones.

3.2. Cliente ligero

El cliente ligero contiene el mínimo necesario para arrancar, comunicarse y presentar la sesión remota. Puede utilizar un sistema operativo embebido, una distribución Linux adaptada o una edición especializada. Su menor complejidad facilita la uniformidad y reduce el número de componentes locales. Las aplicaciones y los datos permanecen principalmente en la infraestructura central, lo que simplifica despliegues y permite que un cambio en una imagen maestra alcance a muchos usuarios.

La ligereza no significa ausencia de gestión. El terminal requiere firmware actualizado, configuración de red, certificados, cliente remoto, políticas de dispositivos y mecanismos de soporte. También puede almacenar cachés y registros. Un equipo ligero desatendido puede convertirse en un punto de entrada, aunque no guarde la historia clínica. Su seguridad depende de un arranque controlado, una configuración bloqueada, comunicaciones protegidas y una sesión correctamente autenticada.

La contrapartida es la dependencia del servicio central. Si fallan la red, el broker, el hipervisor, la autenticación o el almacenamiento de perfiles, numerosos puestos pueden quedar afectados simultáneamente. La centralización reduce fallos individuales, pero puede aumentar el impacto de un fallo común. Por eso debe acompañarse de redundancia, capacidad suficiente, monitorización y procedimientos de contingencia.

3.3. Criterios de elección

La decisión no debe basarse solo en el precio del dispositivo. Debe modelarse el coste total de propiedad: adquisición, licencias, energía, soporte, red, servidores, almacenamiento, copias de seguridad, renovación y tiempo de indisponibilidad. Un terminal barato puede requerir una plataforma central costosa; un PC más caro puede abaratar infraestructura, pero multiplicar el mantenimiento. El resultado depende del volumen, la concurrencia y el perfil de uso.

También se debe evaluar la experiencia de usuario. La latencia, el ancho de banda disponible, la resolución de pantalla, el audio, el vídeo, la impresión y la redirección USB influyen en la percepción. Las aplicaciones de oficina toleran mejor la presentación remota que una interacción gráfica intensiva o un periférico con controlador propietario. Una prueba piloto debe reproducir el escenario real, incluidos picos, enlaces lentos y cambio de ubicación.

En el SAS, la documentación formativa oficial identifica el terminal ligero como un dispositivo de uso destacado en centros de Atención Primaria y vincula LETSAS con un sistema operativo propio basado en Linux. Esta referencia permite afirmar la presencia del modelo ligero, pero no autoriza a extenderlo a todos los puestos ni a atribuirle modelos de hardware, porcentajes de despliegue o protocolos concretos sin documentación adicional.

4. MOVILIDAD Y DISPOSITIVOS MÓVILES

La movilidad amplía el puesto más allá del centro físico. Incluye portátiles, tabletas, teléfonos inteligentes y dispositivos especializados que acceden a servicios corporativos desde ubicaciones variables. En sanidad, facilita atención domiciliaria, guardias localizadas, consulta de agendas, comunicación profesional y captura de información en el punto de atención. La ventaja principal es reducir la distancia entre el profesional, el paciente y el sistema de información; el riesgo principal es operar fuera del perímetro físico y sobre redes y entornos menos controlados.

Un dispositivo móvil integra sistema operativo, almacenamiento cifrable, sensores, cámara, micrófono, conectividad Wi-Fi y celular, servicios de localización y una tienda de aplicaciones. Esta riqueza funcional crea riesgos adicionales: pérdida o robo, aplicaciones maliciosas, permisos excesivos, redes Wi-Fi hostiles, copias automáticas en nubes personales, sincronización con ordenadores no gestionados, captura de pantalla y uso de canales de mensajería no autorizados. La gestión debe contemplar el dispositivo completo y no solo la aplicación corporativa.

La movilidad se diseña a partir del caso de uso. Un portátil corporativo para teletrabajo puede ejecutar un sistema completo, conectarse mediante acceso remoto y almacenar temporalmente datos cifrados. Una tableta de atención domiciliaria puede necesitar una aplicación adaptada a pantalla táctil, funcionamiento con conectividad intermitente y sincronización controlada. Un teléfono destinado a autenticación o avisos puede requerir pocas funciones corporativas, pero una fuerte protección del registro y de las credenciales.

4.1. Conectividad y funcionamiento desconectado

Las redes móviles y Wi-Fi no garantizan cobertura uniforme. Una aplicación que solo funciona con conexión permanente puede fallar en interiores, zonas rurales o edificios con interferencias. El diseño offline-first permite conservar un conjunto mínimo de datos y operaciones durante una interrupción, pero aumenta la complejidad: hay que cifrar el almacenamiento local, definir caducidad, resolver conflictos y sincronizar de forma transaccional. No todos los datos deben estar disponibles sin conexión; la minimización exige descargar solo lo imprescindible para la tarea y el periodo necesarios.

La conexión remota debe limitar el alcance. Una VPN tradicional extiende conectividad hacia la red corporativa, mientras los modelos de acceso de confianza cero intentan autorizar cada recurso de acuerdo con identidad, estado del dispositivo, contexto y política. El enfoque no significa eliminar siempre la VPN, sino evitar que la mera presencia en una red conceda confianza implícita. NIST SP 800-207 formula este principio y NIST SP 800-124 Rev. 2 desarrolla la gestión segura del ciclo de vida de dispositivos móviles empresariales.

4.2. Diseño de aplicaciones móviles

Las aplicaciones pueden ser nativas, web adaptativas, aplicaciones web progresivas o interfaces remotas. La elección depende de sensores, rendimiento, distribución, actualización, accesibilidad y seguridad. Una aplicación web reduce la instalación local, pero sigue necesitando autenticación, sesión segura y protección frente a pérdida del dispositivo. Una aplicación nativa puede integrar cámara, firma o modo desconectado, aunque aumenta el esfuerzo de mantenimiento y debe distribuirse mediante canales controlados.

La experiencia multicanal no se consigue únicamente haciendo una pantalla responsive. Deben conservarse identidad, contexto, autorizaciones, estado de la operación y trazabilidad entre canales. Una actuación iniciada en una tableta y continuada en un PC no debe duplicarse ni perder datos. El servidor debe seguir siendo la fuente de verdad y aplicar las mismas reglas de negocio con independencia del dispositivo.

4.3. Riesgos operativos y humanos

La movilidad altera hábitos. El profesional puede trabajar en lugares con terceros presentes, dejar el dispositivo en un vehículo, recibir notificaciones en la pantalla bloqueada o mezclar fotografía clínica y galería personal. Por ello son necesarias políticas claras, formación y diseño que reduzca la posibilidad de error. Bloqueo automático, ocultación de contenido sensible en notificaciones, borrado remoto, cifrado, autenticación reforzada y prohibición de transferencias a cuentas personales son controles complementarios.

La organización debe ofrecer un canal de soporte capaz de identificar si el problema está en la cobertura, la inscripción del dispositivo, la identidad, la aplicación o el servicio backend. La monitorización del estado de cumplimiento y la telemetría técnica permiten resolver fallos sin exigir al usuario conocimientos avanzados, pero deben respetar la privacidad y diferenciar datos corporativos de información personal cuando el modelo lo requiera.

5. BYOD Y MODELOS ALTERNATIVOS DE TITULARIDAD

BYOD, sigla de Bring Your Own Device, describe el uso de un dispositivo propiedad de la persona para realizar actividades corporativas. No es una tecnología concreta, sino un modelo de gobierno. Puede limitarse al acceso a correo o extenderse a aplicaciones sensibles; puede utilizar contenedores, navegador gestionado, escritorio remoto o aplicaciones nativas. Por eso no basta con afirmar que una organización «permite BYOD»: hay que definir qué dispositivos, usuarios, datos, aplicaciones, redes y controles quedan incluidos.

El atractivo de BYOD reside en aprovechar dispositivos ya disponibles, favorecer la familiaridad y ofrecer flexibilidad. Sin embargo, parte del coste se desplaza hacia seguridad, soporte, asesoramiento jurídico y gestión de la relación con la persona propietaria. La organización no controla el ciclo completo del hardware, puede desconocer reparaciones o cesiones, debe convivir con múltiples versiones y tiene límites para inspeccionar o borrar información. En sanidad, estos límites son especialmente relevantes por la sensibilidad de los datos y por la necesidad de continuidad.

5.1. Separación entre ámbito personal y corporativo

La separación puede implementarse mediante un perfil de trabajo, contenedor, espacio administrado o aplicación protegida. El objetivo es impedir que datos corporativos se copien a aplicaciones personales, cuentas privadas o servicios no autorizados. La separación también protege a la persona: la administración no debería acceder innecesariamente a fotografías, mensajes o localización privada. Deben explicarse con transparencia las capacidades de gestión, los datos que se recogen y las acciones que pueden realizarse.

Existen dos modalidades de borrado. El borrado selectivo retira aplicaciones, claves, perfiles y datos corporativos, conservando el contenido personal. El borrado completo restablece el dispositivo y puede ser adecuado en equipos propiedad de la organización, pero resulta problemático en BYOD salvo consentimiento y condiciones muy claras. La elección debe estar prevista antes de una pérdida o del fin de la relación profesional.

5.2. Modelos alternativos

COBO (Corporate Owned, Business Only) significa que la organización es propietaria y restringe el dispositivo al uso profesional. Facilita la configuración estricta y reduce la mezcla de datos. COPE (Corporate Owned, Personally Enabled) mantiene la propiedad corporativa, pero admite un uso personal limitado y separado. CYOD (Choose Your Own Device) permite escoger dentro de un catálogo homologado; la propiedad puede definirse contractualmente, por lo que la sigla no debe usarse como sinónimo automático de COPE. También existe el modelo de dispositivo compartido o dedicado, habitual en terminales de sala o equipos asignados a una función.

5.3. Política BYOD

Una política completa define condiciones de admisión, versiones soportadas, cifrado, bloqueo, autenticación, aplicaciones obligatorias y prohibidas, recogida de registros, soporte, incidentes, pérdida, inspección, privacidad, salida del programa y responsabilidades económicas. También debe definir qué sucede con copias de seguridad personales, dispositivos rooteados o con jailbreak, tarjetas de memoria, asistentes de voz y servicios de nube del fabricante.

El consentimiento laboral no resuelve por sí solo todos los tratamientos de datos, pues puede existir desequilibrio entre las partes. La base jurídica, la proporcionalidad y la información a la persona deben analizarse de acuerdo con el RGPD y la normativa laboral aplicable. La política técnica debe coordinarse con protección de datos, seguridad, recursos humanos, prevención y representación de los trabajadores cuando corresponda.

En un entorno sanitario, puede ser preferible ofrecer aplicaciones web de bajo riesgo o un escritorio remoto que evite almacenamiento local, mientras se reservan equipos corporativos para funciones asistenciales más sensibles. Aun así, la presentación remota no impide capturas, observación por terceros o robo de sesión. Deben aplicarse autenticación fuerte, caducidad, bloqueo, restricciones de portapapeles y descarga cuando proceda.

6. MDM, EMM Y UEM: ADMINISTRACIÓN Y SEGURIDAD

MDM (Mobile Device Management) es la gestión centralizada de dispositivos móviles. Permite inscribir equipos, distribuir configuraciones, exigir cifrado y bloqueo, instalar certificados, inventariar versiones, localizar el estado de cumplimiento, desplegar aplicaciones y ejecutar acciones remotas. EMM (Enterprise Mobility Management) amplía el concepto hacia aplicaciones, contenidos e identidades móviles. UEM (Unified Endpoint Management) intenta administrar desde una plataforma común móviles, ordenadores y otros extremos.

Las fronteras comerciales entre estos términos no son rígidas. Muchos productos denominados MDM incorporan funciones EMM o UEM. En una pregunta técnica debe atenderse a la función: una plataforma que administra una flota Android, aplica políticas, distribuye aplicaciones y permite borrado remoto pertenece al dominio MDM/EMM, no a un CMS, un SIEM o una herramienta de virtualización de servidores.

6.1. Inscripción y confianza

La inscripción establece una relación de gestión entre el dispositivo y la organización. Puede realizarse mediante códigos, cuentas corporativas, certificados, programas del fabricante o aprovisionamiento automatizado. En equipos corporativos se busca una modalidad que impida retirar fácilmente la gestión. En BYOD se utiliza un perfil de trabajo o control de aplicaciones con menor alcance. La plataforma emite o instala credenciales que deben revocarse al retirar el dispositivo.

La organización define una política de cumplimiento: versión mínima, cifrado activo, bloqueo, ausencia de manipulación, protección antimalware cuando corresponda y presencia de aplicaciones obligatorias. El acceso condicional combina identidad y estado del dispositivo. Un usuario autorizado puede ser rechazado si accede desde un equipo que no cumple; del mismo modo, un dispositivo correcto no obtiene acceso sin una identidad válida.

6.2. Gestión de aplicaciones y datos

La gestión de aplicaciones permite crear un catálogo corporativo, instalar o retirar software, definir configuraciones y limitar intercambio de datos. Las políticas pueden impedir copiar desde una aplicación clínica a una mensajería personal, guardar en almacenamiento no aprobado o abrir documentos con aplicaciones no gestionadas. La gestión de contenidos controla repositorios y sincronización, evitando que cada aplicación implemente su propia solución insegura.

La evaluación de aplicaciones no debe limitarse al origen de la tienda. Debe revisar permisos, bibliotecas, cifrado, comunicaciones, gestión de sesión, actualización y tratamiento de datos. NIST SP 800-124 Rev. 2 contempla la seguridad durante despliegue, uso y retirada del dispositivo, y utiliza conceptos como EMM, MDM, evaluación de aplicaciones móviles y defensa frente a amenazas móviles.

6.3. Respuesta ante incidentes

Ante pérdida, la primera acción es evaluar el riesgo y revocar credenciales o sesiones. El bloqueo y borrado remoto dependen de conectividad; por tanto, el cifrado local y la caducidad de tokens son controles previos imprescindibles. La localización puede ayudar en un equipo corporativo, pero debe estar autorizada y ser proporcional. La plataforma debe registrar quién ordenó el borrado, cuándo se ejecutó y qué alcance tuvo.

Un dispositivo comprometido puede quedar en cuarentena, perder acceso o requerir restauración. El procedimiento debe coordinar MDM, directorio, certificados, aplicaciones y servicio de soporte. No basta con cambiar la contraseña si permanecen tokens activos. Tampoco basta con borrar la aplicación si existe información en copias o almacenamiento compartido.

El ENS refuerza este enfoque al exigir configuración segura, control de dispositivos presentes en la red y limitación de servicios cuando un portátil se conecta desde redes no controladas. La medida concreta depende de la categoría del sistema y de la aplicación del marco de medidas, pero la idea transversal es que el estado del extremo debe ser conocido y gobernado.

6.4. Privacidad y mínima administración

Una plataforma UEM puede recoger modelo, identificadores, versión, aplicaciones gestionadas, cumplimiento y eventos. En BYOD debe configurarse para evitar datos personales innecesarios. La organización debe documentar finalidades, plazos, acceso a la consola y auditoría de administradores. El principio de privilegio mínimo también se aplica al personal técnico: quien distribuye una aplicación no necesita necesariamente consultar localización o ejecutar un borrado completo.

7. VIRTUALIZACIÓN DEL PUESTO DE TRABAJO: VDI Y PUBLICACIÓN DE APLICACIONES

VDI (Virtual Desktop Infrastructure) entrega a la persona usuaria un escritorio que se ejecuta en una máquina virtual alojada en infraestructura central. El dispositivo local captura teclado, ratón, audio u otros canales y recibe la representación visual de la sesión. El procesamiento principal y el almacenamiento del escritorio permanecen en el centro de datos o plataforma de nube. Esta arquitectura separa el entorno de usuario del terminal físico.

VDI no es sinónimo de acceso remoto genérico. Una sesión de soporte a un PC físico, un servidor de terminales multiusuario y un escritorio virtual individual comparten técnicas de presentación remota, pero tienen modelos distintos. En VDI, cada escritorio suele ejecutarse como máquina virtual o instancia asignada, persistente o no persistente. En la virtualización de sesiones, varios usuarios comparten un sistema operativo de servidor con sesiones aisladas.

7.1. Componentes

El hipervisor ejecuta las máquinas virtuales. El broker autentica o integra la autenticación, consulta asignaciones y dirige al usuario hacia el recurso adecuado. El agente de entrega se instala en la máquina que aloja el escritorio o aplicación y establece la comunicación con la plataforma. La pasarela protege el acceso desde redes externas. Los servicios de perfiles, imágenes, almacenamiento y licencias completan la solución.

La imagen maestra contiene sistema operativo y aplicaciones comunes. En escritorios no persistentes, las instancias se crean o restablecen a partir de esa imagen, mientras los datos y preferencias se externalizan. Esto facilita parches homogéneos, pero exige diseñar perfiles, cachés y aplicaciones que no supongan persistencia local. En escritorios persistentes, cada usuario conserva cambios, lo que se aproxima a un PC virtual y aumenta la gestión.

7.2. Persistencia y perfiles

Un escritorio persistente conserva modificaciones y puede admitir personalización profunda. Resulta útil para perfiles especializados, pero acumula desviaciones y necesita mantenimiento individual. Un escritorio no persistente vuelve a un estado conocido y favorece la seguridad y la escalabilidad. La personalización se conserva mediante perfiles, discos de usuario, carpetas redirigidas o servicios equivalentes.

El inicio de sesión puede degradarse si el perfil crece, se corrompe o se descarga desde una ubicación lenta. La administración debe excluir cachés innecesarias, controlar tamaño, distribuir almacenamiento y monitorizar tiempos. La experiencia del usuario depende tanto del broker como del perfil y de los servicios de identidad.

7.3. Publicación de aplicaciones

La publicación remota entrega una aplicación concreta en lugar del escritorio completo. El programa se ejecuta en un servidor o máquina virtual y su ventana se integra visualmente con el entorno local. Es útil para clientes pesados heredados, aplicaciones con dependencias complejas o software que no se desea instalar en cada equipo. Reduce despliegues locales, pero mantiene la aplicación original y no corrige por sí sola sus limitaciones arquitectónicas.

La virtualización de aplicaciones puede referirse también a empaquetado y aislamiento local. Debe distinguirse de la publicación remota. En el primer caso, la aplicación se ejecuta en el dispositivo dentro de un entorno aislado; en el segundo, se ejecuta en infraestructura central y solo se presenta la interfaz.

7.4. Redirección de periféricos

El protocolo remoto puede transportar portapapeles, impresoras, unidades, audio, vídeo, cámara, dispositivos USB y tarjetas. Cada canal añade funcionalidad y riesgo. La redirección de discos puede facilitar exfiltración; la de impresoras aumenta complejidad de controladores; la cámara requiere ancho de banda; y un dispositivo clínico puede necesitar comunicación específica no compatible. Las políticas deben habilitar solo canales necesarios y comprobarlos en el escenario real.

La experiencia depende de latencia, pérdida, variación temporal, ancho de banda y codificación. Un enlace con gran capacidad no garantiza baja latencia. La plataforma adapta compresión y calidad, pero no elimina las leyes físicas. Para voz y vídeo se utilizan optimizaciones que descargan parte del procesamiento en el extremo, siempre que el cliente sea compatible.

7.5. Ventajas y riesgos

VDI centraliza imágenes, facilita recuperación de sesión, reduce datos locales y permite usar terminales heterogéneos. También concentra impacto, exige inversión en infraestructura y depende de servicios compartidos. Un ransomware en la capa de perfiles o un error en la imagen puede afectar a muchos usuarios. La alta disponibilidad debe abarcar broker, pasarela, hipervisores, almacenamiento, red, identidad y licencias.

8. DAAS Y MODELOS DE IMPLANTACIÓN ON PREMISE, CLOUD E HÍBRIDOS

DaaS significa Desktop as a Service. Aplica principios de servicio cloud a la entrega de escritorios: aprovisionamiento bajo demanda, elasticidad, acceso por red y medición o consumo del servicio. El término no implica necesariamente que todos los componentes estén en una nube pública ni que el proveedor administre el sistema operativo y las aplicaciones. La distribución de responsabilidades depende del contrato y de la arquitectura.

La definición de computación en nube de NIST SP 800-145 identifica características como autoservicio bajo demanda, acceso amplio a red, agrupación de recursos, elasticidad rápida y servicio medido. DaaS puede construirse sobre IaaS, servicios gestionados de escritorio o plataformas especializadas. Para valorar si una oferta es realmente DaaS no basta con que se facture mensualmente; debe analizarse cómo se aprovisiona, escala, aísla y gobierna.

8.1. Implantación on premise

En un VDI local, la organización controla centro de datos, hipervisores, red, imágenes, broker, pasarelas y operación, salvo componentes externalizados. Obtiene control sobre ubicación y diseño, y puede optimizar latencia hacia centros conectados a la red corporativa. A cambio, asume capacidad, renovación, licencias, alta disponibilidad, copias y personal especializado. El escalado requiere prever o adquirir recursos.

«On premise» no significa automáticamente más seguro. La seguridad depende de arquitectura, operación y recursos. Una plataforma local obsoleta puede ser más vulnerable que un servicio actualizado; un proveedor cloud mal configurado también puede exponer datos. La comparación debe basarse en controles, evidencias, certificaciones, ubicación, acceso administrativo y responsabilidad.

8.2. Implantación en cloud

En DaaS cloud, el proveedor gestiona parte de la infraestructura y ofrece mecanismos para crear catálogos, escritorios y políticas. La elasticidad permite aumentar capacidad para campañas, incorporaciones o contingencias sin instalar hardware local, aunque el coste variable debe controlarse. La red hacia la región o ubicación del servicio condiciona latencia y continuidad. También se deben dimensionar perfiles, almacenamiento, directorio, conectividad con aplicaciones internas y tráfico de salida.

La residencia de datos y metadatos, el soporte, los subencargados, el cifrado, la reversibilidad y la eliminación deben quedar contractualmente definidos. El RGPD exige garantías cuando un proveedor trata datos personales; el ENS establece requisitos para sistemas de su ámbito. La organización conserva responsabilidad sobre clasificación de información, identidades, autorizaciones y configuración aunque externalice infraestructura.

8.3. Modelo híbrido

Un modelo híbrido puede mantener escritorios cerca de sistemas internos y utilizar control, capacidad de contingencia o componentes en cloud. También puede dividir colectivos. La hibridación aumenta flexibilidad, pero añade dependencias, consolas, sincronización de identidades y complejidad de diagnóstico. Debe existir una arquitectura de referencia y una matriz clara de responsabilidades.

8.4. Dimensionamiento

El dimensionamiento parte de usuarios concurrentes, perfiles de carga y tiempos de uso. Se miden CPU, memoria, operaciones de almacenamiento, tamaño de perfiles, tráfico, resolución, multimedia y picos de inicio de sesión. El promedio oculta los boot storms y login storms, cuando numerosos escritorios arrancan o inician sesión simultáneamente. Se necesita margen, pruebas de carga y capacidad de degradación controlada.

La economía debe incluir licencias de sistema, aplicaciones, acceso, seguridad, almacenamiento, copia, red, soporte y salida del proveedor. El coste por usuario no siempre disminuye con la virtualización. Perfiles intensivos pueden necesitar GPU o recursos reservados. El beneficio puede encontrarse en agilidad, control y continuidad, no solo en ahorro.

8.5. Seguridad e identidad

La sesión debe asociarse a una identidad personal y registrar accesos. La autenticación multifactor es especialmente relevante fuera de redes controladas. Se aplican políticas de portapapeles, impresión, descarga, unidades y duración. La administración de la plataforma requiere cuentas separadas, privilegio mínimo, trazabilidad y protección reforzada.

8.6. Reversibilidad y dependencia del proveedor

Antes de implantar DaaS deben definirse exportación de imágenes y perfiles, formatos, recuperación de datos, continuidad al finalizar el contrato, transferencia de conocimiento y eliminación certificada. La portabilidad de una imagen no garantiza portabilidad de toda la solución: brokers, automatización, perfiles, políticas y licencias pueden ser específicos. La reversibilidad debe probarse, no quedar como una cláusula genérica.

9. SISTEMAS CORPORATIVOS DE IMPRESIÓN

La impresión transforma información electrónica en un soporte físico que puede salir del control técnico del sistema. En sanidad siguen existiendo informes, etiquetas, consentimientos, justificantes, documentación administrativa y materiales de trabajo que requieren papel. Por ello, la impresión no debe tratarse como un periférico aislado, sino como un servicio corporativo con colas, controladores, permisos, trazabilidad, consumibles, mantenimiento y protección de la confidencialidad.

9.1. Arquitectura de impresión

Una impresora local se conecta directamente al puesto, por ejemplo mediante USB. Simplifica algunos escenarios, pero dificulta inventario, sustitución y gestión de controladores. Una impresora de red dispone de conectividad IP y puede recibir trabajos directamente o a través de un servidor de impresión. El servidor centraliza colas, permisos, controladores y auditoría, y desacopla a los clientes de la dirección física del dispositivo.

El flujo típico comprende aplicación, subsistema de impresión del sistema operativo, controlador, spooler, cola y dispositivo. El controlador transforma el documento en un lenguaje que la impresora entiende. Los lenguajes pueden ser específicos o estándares de facto. La diversidad de controladores introduce incompatibilidades, especialmente en VDI; los controladores universales reducen variedad, aunque pueden no exponer todas las funciones.

IPP, definido en RFC 8010 y RFC 8011 para IPP/1.1, proporciona un protocolo de impresión basado en operaciones y atributos. Puede transportarse con TLS cuando se utiliza una URI segura. El estándar IPP Everywhere, impulsado por Printer Working Group, busca impresión sin controladores específicos mediante formatos y capacidades interoperables. En una organización real pueden coexistir IPP, colas Windows y protocolos heredados; la selección debe atender a soporte y seguridad.

Windows PowerShell:
Get-Printer
Get-PrintJob -PrinterName "NombreCola"

Linux con CUPS:
lpstat -p -d

Estos comandos son ejemplos de consulta. Get-Printer enumera impresoras instaladas en Windows; Get-PrintJob consulta trabajos de una cola; lpstat -p -d muestra impresoras y destino predeterminado en sistemas que utilizan CUPS. Su disponibilidad depende del sistema y de los permisos.

9.2. Impresión en entornos VDI y DaaS

En un escritorio virtual, la aplicación se ejecuta lejos de la impresora. La plataforma puede redirigir la impresora local, mapear colas de red según ubicación o utilizar un servicio de impresión universal. La redirección automática mejora movilidad, pero puede crear numerosas colas, cargar controladores incompatibles y transportar grandes trabajos a través del protocolo de sesión. La asignación por ubicación es más predecible en centros con puestos compartidos.

La impresión debe probarse con formatos reales, etiquetas, doble cara, bandejas y códigos de barras. Un controlador genérico puede imprimir texto correctamente y fallar con una etiqueta clínica o una bandeja específica. El diagnóstico distingue fallo de aplicación, cola, spooler, red, controlador, dispositivo y consumible. Reiniciar indiscriminadamente puede ocultar la causa y perder trabajos.

9.3. Impresión segura

La impresión segura o pull printing retiene el trabajo hasta que la persona se autentica en un dispositivo autorizado. Reduce documentos abandonados, permite liberar en diferentes equipos y evita que una cola asociada a una ubicación antigua produzca una copia fuera del control del usuario. La autenticación puede realizarse con tarjeta, PIN u otro mecanismo integrado; debe asociarse a una identidad individual.

La retención no elimina otros riesgos. El servidor de impresión puede almacenar temporalmente documentos; la multifunción puede disponer de disco; los administradores pueden tener acceso privilegiado; y los registros pueden revelar metadatos. Se deben cifrar comunicaciones cuando corresponda, limitar privilegios, definir caducidad, borrar trabajos y proteger soportes en mantenimiento o retirada.

La trazabilidad debe ser proporcional. Registrar usuario, cola, hora, páginas y resultado puede apoyar auditoría y costes. Registrar el contenido del documento sería mucho más intrusivo y normalmente innecesario. El diseño debe aplicar minimización y limitar el acceso a registros.

9.4. Disponibilidad y gestión

El servicio se gestiona mediante catálogo de modelos homologados, inventario, mantenimiento, niveles de consumibles y repuestos. La alta disponibilidad del servidor no resuelve una impresora averiada en una consulta; por ello se definen alternativas de ubicación y procedimientos de contingencia. Para etiquetas o documentos críticos pueden ser necesarios dispositivos redundantes o colas alternativas.

10. SISTEMAS DE DIGITALIZACIÓN DOCUMENTAL

Digitalizar es convertir un documento en soporte físico en una representación electrónica. En una administración pública, la digitalización relevante no consiste simplemente en obtener una fotografía. Debe producir un documento electrónico con calidad suficiente, metadatos, integridad, vinculación al expediente o sistema y garantías que permitan su gestión posterior. Cuando se pretende una copia electrónica auténtica, deben cumplirse las condiciones jurídicas y técnicas aplicables.

10.1. Captura y dispositivos

Los escáneres planos son adecuados para documentos frágiles, libros o elementos que no pueden alimentarse automáticamente. Los equipos con alimentador automático procesan lotes y pueden digitalizar ambas caras. Las multifunciones integran impresión y escaneo, pero deben gobernarse como equipos con almacenamiento, red, libreta de direcciones y funciones de envío. La cámara móvil puede capturar documentos en movilidad, siempre que la aplicación controle perspectiva, calidad, destino y protección.

La resolución se expresa en puntos por pulgada. Elegirla exige equilibrio: una resolución insuficiente perjudica lectura y OCR; una excesiva aumenta tamaño sin aportar valor. El color, escala de grises, compresión y formato dependen del documento. No debe fijarse una cifra universal para todo; la Norma Técnica de Interoperabilidad de Digitalización de Documentos establece requisitos sobre imagen, metadatos, control de calidad y firma en el contexto administrativo.

10.2. Flujo de digitalización

1. Preparación: identificar documento, retirar grapas, ordenar páginas y comprobar autorización.
2. Captura: generar imagen con parámetros establecidos y detectar doble alimentación.
3. Procesamiento: recortar, enderezar, limpiar y aplicar OCR cuando proceda, sin alterar el contenido.
4. Control de calidad: verificar integridad, legibilidad, orientación, número de páginas y correspondencia.
5. Indexación: asignar metadatos y relacionar con persona, episodio, procedimiento o expediente correcto.
6. Incorporación: almacenar en repositorio o sistema autorizado, con permisos y trazabilidad.
7. Tratamiento del original: conservar, devolver o destruir según normativa y procedimiento.

El OCR reconoce caracteres y permite búsqueda o extracción, pero no garantiza exactitud. Nombres, dosis, fechas, códigos y texto manuscrito pueden interpretarse mal. El texto reconocido es una ayuda; la imagen original sigue siendo la representación primaria salvo que el proceso normativo defina otra cosa. Los datos extraídos que alimentan un sistema clínico requieren validación.

10.3. Formatos y preservación

TIFF se utiliza para imágenes rasterizadas y admite compresión sin pérdida; JPEG es eficiente para fotografías, pero su compresión con pérdida puede degradar texto; PNG ofrece compresión sin pérdida; PDF encapsula páginas e información; PDF/A es una familia ISO orientada a preservación. La elección depende de interoperabilidad, archivo, firma, búsqueda y tamaño. El formato no sustituye a metadatos ni a una política de conservación.

TWAIN y WIA son interfaces utilizadas para comunicar aplicaciones con escáneres en determinados entornos. SANE proporciona una arquitectura habitual en sistemas Unix y Linux. Estas interfaces resuelven adquisición, no el gobierno documental completo. Una aplicación puede capturar perfectamente y enviar al paciente equivocado si la indexación es deficiente.

Ejemplo de inventario de escáneres con SANE:
scanimage -L

El comando scanimage -L consulta dispositivos reconocidos por SANE. Es un ejemplo de diagnóstico técnico; no demuestra por sí solo que el flujo documental, los permisos o la autenticidad sean correctos.

10.4. Seguridad y protección de datos

La digitalización concentra información en colas, carpetas temporales, memoria del equipo y repositorios. Debe evitarse el envío a correo personal, USB no autorizado o carpeta genérica. Las multifunciones pueden conservar imágenes en disco; su configuración, mantenimiento y retirada deben incluir borrado y protección. Las libretas de direcciones deben impedir selección accidental de destinos externos.

La trazabilidad registra quién captura, cuándo, desde qué dispositivo y dónde incorpora el documento. No se debe atribuir a un usuario una digitalización realizada con una cuenta compartida. La revisión de calidad puede separarse de la captura en procesos de alto riesgo. Los permisos del repositorio deben derivarse del rol y del contexto asistencial o administrativo.

10.5. Integración con el expediente y sistemas clínicos

El documento debe vincularse mediante identificadores correctos. La búsqueda por nombre no basta cuando existen homónimos. El flujo debe utilizar identificadores corporativos, validar contexto y evitar que una sesión anterior permanezca activa. La pantalla de confirmación debe mostrar la información mínima necesaria para comprobar destino sin exponer datos a terceros.

La digitalización puede automatizar clasificación, separación de lotes y extracción de campos. La automatización debe incluir umbrales de confianza y revisión humana. Un sistema que asigna automáticamente un documento con baja confianza puede generar un error clínico más difícil de detectar que una cola manual.

11. REQUISITOS DEL PUESTO DE TRABAJO EN ATENCIÓN PRIMARIA

La Atención Primaria combina consultas programadas, atención urgente, actividad administrativa, enfermería, seguimiento de crónicos, atención domiciliaria y coordinación con otros niveles. Los centros presentan tamaños y ubicaciones diferentes, y pueden incluir consultorios con menor dotación técnica. El puesto debe sostener una actividad continua, con tiempos de interacción breves y múltiples cambios de paciente. Esto convierte rendimiento, identidad y usabilidad en requisitos asistenciales.

11.1. Perfil funcional

El profesional necesita acceder a historia de salud, agenda, prescripción, pruebas, informes, comunicaciones y herramientas generales. El personal administrativo utiliza identificación, citación, documentación y gestión. Los periféricos pueden incluir impresora, lector de tarjetas, escáner, cámara, audio o dispositivos específicos. El catálogo debe definirse por función y no por una imagen uniforme que ignore diferencias.

Los puestos suelen ser compartidos por turnos o sustituciones. El diseño debe favorecer inicio y cierre de sesión rápidos, impedir que una persona continúe bajo la identidad anterior y recuperar preferencias de forma segura. Las cuentas genéricas son incompatibles con una trazabilidad adecuada. Cuando se necesita continuidad entre ubicaciones, el perfil o la aplicación debe seguir al usuario, no depender de archivos guardados en el escritorio local.

11.2. Disponibilidad y contingencia

Una caída puede impedir consultar antecedentes o emitir documentación. La continuidad debe analizar dependencias: alimentación, LAN, WAN, DNS, DHCP, identidad, escritorio virtual, sistemas centrales e impresión. La contingencia no es solo disponer de otro PC. Si todos los terminales dependen del mismo enlace, cambiar de equipo no resuelve la avería. Se requieren procedimientos operativos, contactos, priorización y, cuando proceda, alternativas de conectividad o modos de contingencia de aplicaciones.

Los datos utilizados en contingencia deben reconciliarse posteriormente. Formularios en papel o registros temporales crean riesgos de duplicidad y pérdida. El procedimiento debe definir custodia, incorporación, validación y destrucción. La formación es importante: una medida de continuidad desconocida no estará disponible cuando se necesite.

11.3. Rendimiento y ergonomía

El tiempo de respuesta debe medirse desde la acción del usuario hasta la presentación útil, incluyendo autenticación, perfil y aplicación. Un escritorio que conecta rápido pero tarda en abrir la historia no cumple el objetivo. La monitorización debe separar red, servidor, base de datos, perfil y extremo. Las métricas técnicas se complementan con tareas: iniciar consulta, recuperar paciente, prescribir, imprimir o cerrar sesión.

La ergonomía incluye tamaño y resolución de pantalla, posición, teclado, ratón, ruido y accesibilidad. La densidad de información clínica puede justificar monitores adecuados. Una interfaz accesible debe permitir navegación por teclado, contraste, ampliación, lectura y adaptación. El Real Decreto 1112/2018 y la norma EN 301 549 son referencias para accesibilidad de sitios y aplicaciones móviles del sector público; WCAG 2.2 aporta criterios técnicos actuales del W3C.

11.4. Movilidad asistencial

La atención domiciliaria requiere acceso desde fuera del centro. El dispositivo debe ser transportable, resistente al uso, con autonomía suficiente y posibilidad de conectividad segura. Debe minimizar datos locales, ocultar información en notificaciones y bloquearse rápidamente. La cámara puede aportar captura documental o clínica, pero su uso debe estar integrado en una aplicación autorizada para evitar que imágenes terminen en galerías o nubes personales.

La sincronización offline debe ser selectiva. Descargar historiales completos «por si acaso» contradice minimización. El sistema puede preparar agendas y un subconjunto de información necesario, cifrado y con caducidad. Las modificaciones se sincronizan con control de conflictos y auditoría. Si el riesgo no permite almacenamiento local, el diseño puede requerir conectividad permanente o limitar la funcionalidad.

11.5. Segmentación de perfiles

No todos los profesionales necesitan idénticas aplicaciones. El principio de mínimo privilegio exige asignar según rol, centro y función. Las sustituciones y cambios deben gestionarse con rapidez, pero sin mantener permisos históricos. La autorización no debe confiar en la ubicación física: sentarse en una consulta no convierte a una persona en facultativo de esa unidad.

12. ESTRATEGIA DE EVOLUCIÓN DEL PUESTO EN EL SAS

La evolución del puesto del SAS debe entenderse como un proceso continuo de estandarización, centralización selectiva, modernización de aplicaciones, movilidad y refuerzo de seguridad. No es prudente atribuir una hoja de ruta cerrada, cifras de despliegue o proveedores concretos sin una fuente oficial vigente. Sí pueden identificarse líneas coherentes con la documentación pública: uso de terminales ligeros en Atención Primaria, servicios de escritorio virtual Citrix, gestión de activos con Altiris, aplicaciones corporativas y la Estrategia de Salud Digital de Andalucía 2030.

Un anexo público de aplicativos centrales del SAS incluye servicios de acceso remoto a aplicaciones corporativas, escritorios virtuales centralizados, escritorios virtuales hospitalarios y de Atención Primaria, así como gestión de activos mediante Altiris. Esta evidencia confirma que la virtualización y la administración centralizada forman parte del ecosistema, pero no implica que todo puesto se entregue de la misma manera ni que la arquitectura permanezca inalterada.

12.1. Estandarización y catálogo

La evolución comienza por definir perfiles funcionales: consulta, admisión, administración, movilidad, diagnóstico, desarrollo y otros. Cada perfil especifica dispositivo, pantalla, periféricos, aplicaciones, conectividad y nivel de soporte. La estandarización reduce modelos y facilita compras, imágenes, formación y repuestos. Debe conservar excepciones justificadas por necesidad clínica o técnica.

El catálogo debe estar relacionado con la gestión de activos y configuración. Cuando un equipo cambia de ubicación o función, deben actualizarse inventario, asignación, políticas y periféricos. La automatización de aprovisionamiento reduce errores y tiempos. La plataforma puede aplicar configuración según identidad y ubicación en lugar de mantener imágenes manuales distintas.

12.2. Modernización de aplicaciones

La publicación virtual permite mantener clientes heredados, pero a largo plazo la evolución hacia aplicaciones web, APIs e interfaces adaptativas puede reducir dependencias del puesto. La modernización debe conservar funcionalidades, rendimiento y seguridad. No toda aplicación debe convertirse en móvil; se priorizan procesos con valor asistencial o necesidad de movilidad.

Una interfaz web no elimina el puesto: necesita navegador gestionado, certificados, identidad, políticas y soporte. Las aplicaciones deben probarse con versiones corporativas y accesibilidad. La actualización central del servidor reduce despliegue local, pero aumenta la importancia de pruebas y reversión, pues un error llega a todos los usuarios.

12.3. Identidad y confianza cero

La identidad personal se convierte en el eje del acceso. La autenticación reforzada se aplica según riesgo, especialmente en acceso remoto o privilegiado. El estado del dispositivo y el contexto complementan la identidad. El objetivo es conceder el mínimo acceso necesario y reevaluarlo, no confiar automáticamente por estar dentro de la red.

La transición debe cuidar la experiencia clínica. Métodos demasiado frecuentes o lentos pueden provocar atajos. Se pueden combinar autenticación inicial fuerte, bloqueo rápido y mecanismos seguros de reanudación. Las sesiones privilegiadas deben separarse de las de uso ordinario.

12.4. Movilidad gestionada

La movilidad debe apoyarse en dispositivos y aplicaciones gestionados, acceso condicional y catálogo. La elección entre BYOD y propiedad corporativa depende del caso de uso. Para datos clínicos y funciones críticas, un equipo corporativo permite mayor control. Para servicios de menor riesgo, un acceso web limitado desde dispositivo personal puede ser admisible con controles. La política debe ser explícita y revisable.

12.5. Virtualización y cloud

VDI y DaaS pueden proporcionar continuidad entre dispositivos y centralizar mantenimiento. La decisión de llevar componentes a cloud exige evaluación del ENS, protección de datos, contratación, residencia, conectividad y reversibilidad. Un modelo híbrido puede ser adecuado, pero no debe adoptarse por moda. Las pruebas deben incluir centros con distintas condiciones de red.

12.6. Observabilidad y experiencia

La evolución se gobierna con métricas: tiempo de inicio, disponibilidad, incidencias por puesto, cumplimiento de parches, éxito de despliegues, latencia y satisfacción. Las métricas deben permitir localizar cuello de botella y priorizar mejoras. Un promedio regional puede ocultar un consultorio con mala conectividad. Se necesitan vistas por servicio, centro y perfil sin invadir la privacidad.

12.7. Transición y gestión del cambio

Una implantación debe incluir piloto, compatibilidad, formación, soporte reforzado, reversión y comunicación. Los profesionales necesitan conocer qué cambia, cómo iniciar sesión, dónde guardar datos y cómo comunicar incidencias. El equipo técnico necesita runbooks, inventario y herramientas de diagnóstico. El cambio no termina con instalar hardware; concluye cuando el servicio funciona de forma estable y el soporte ordinario lo asume.

La renovación debe evitar dependencias innecesarias. Imágenes, perfiles, configuraciones y documentación deben ser exportables. Los contratos deben definir niveles de servicio, seguridad, actualizaciones, fin de soporte y salida. La estrategia tecnológica se alinea con continuidad asistencial y sostenibilidad, no solo con renovación presupuestaria.

13. SISTEMA LETSAS

LETSAS es el sistema operativo de desarrollo propio del SAS, basado en Linux, asociado a terminales ligeros distribuidos en centros de Atención Primaria. La documentación formativa oficial del SAS señala que proporciona acceso a los aplicativos y servicios TIC corporativos necesarios para el trabajo profesional. Esta formulación es la base segura para estudiarlo; no debe expandirse la sigla ni atribuirle fabricantes o versiones concretas si no constan en una fuente válida.

13.1. Finalidad

LETSAS responde a la necesidad de disponer de un entorno robusto y gestionable de forma centralizada para ejecutar o acceder a aplicaciones asistenciales de Atención Primaria. El terminal ligero presenta un entorno homogéneo y reduce la instalación individual de clientes. La documentación del SAS explica que los servidores mantienen la última versión de aplicaciones y dan servicio a los puestos conectados, mientras una plataforma propia permite actualización remota y desatendida de terminales.

El valor del sistema se encuentra en la estandarización. Distintos modelos físicos pueden proporcionar funciones equivalentes: acceso a red, herramientas de productividad y aplicaciones corporativas. La capa LETSAS abstrae parte de la heterogeneidad y permite administrar configuración y actualización. Esto facilita soporte en una red territorial amplia.

13.2. Arquitectura lógica

El terminal ejecuta el sistema local basado en Linux y los componentes necesarios para interfaz, red, periféricos y acceso a servicios. Las aplicaciones pueden ser web, locales o remotas según su diseño. La documentación pública y los inventarios de servicios confirman la existencia de escritorios virtuales de Atención Primaria basados en Citrix, pero no debe suponerse que cada función de LETSAS dependa necesariamente de un único protocolo o que todas las aplicaciones se ejecuten dentro del mismo escritorio.

13.3. Administración y soporte

La pregunta oficial de 2025 identifica como combinación correcta para administración y soporte Terminal de Consola, Panel Web local y Altiris. La terminal de consola permite diagnóstico y administración local; el panel web local ofrece una interfaz de configuración del terminal; Altiris proporciona gestión centralizada de activos y despliegue. ayudaDIGITAL es el canal de soporte al usuario, pero no sustituye a estas herramientas de administración.

La consola local resulta útil cuando la interfaz gráfica o la conexión central no están disponibles. El panel web facilita parámetros y comprobaciones. Altiris permite operar a escala: inventario, distribución y acciones remotas. El técnico debe seleccionar la herramienta según capa del fallo. Utilizar una plataforma central no sirve si el terminal no tiene conectividad; operar localmente no resuelve una incidencia que afecta a una imagen o servicio central.

13.4. Actualización y configuración

La actualización remota reduce desplazamientos y evita versiones divergentes. Debe planificarse por grupos, probarse en piloto, disponer de reversión y controlar terminales desconectados. Un despliegue «correcto» en la consola no basta: se debe verificar arranque, acceso, periféricos y aplicaciones. La distribución escalonada limita impacto de un defecto.

La configuración central puede definir red, clientes, certificados y políticas. Las excepciones locales deben estar documentadas; de lo contrario, la siguiente actualización puede perderlas. La gestión de configuración debe saber qué versión se espera y qué versión está realmente instalada.

13.5. Periféricos

La documentación formativa del SAS describe terminales con monitor, teclado y ratón, acceso a red, herramientas como LibreOffice, aplicaciones corporativas y, habitualmente, impresora monopuesto USB. Esta referencia evidencia que un terminal ligero no es un dispositivo sin periféricos. Debe soportar impresión y otros elementos necesarios, lo que obliga a gestionar controladores, permisos y compatibilidad.

Los fallos de periféricos pueden encontrarse en la capa local o remota. Si una impresora USB no es reconocida por LETSAS, el problema es local; si se reconoce pero no aparece en la aplicación virtual, puede fallar la redirección; si aparece y no imprime, se revisan cola, controlador y dispositivo. Un diagnóstico por capas evita reinstalaciones innecesarias.

13.6. Seguridad

La homogeneidad permite endurecer el sistema, limitar software, centralizar actualizaciones y reducir datos locales. Sin embargo, el terminal sigue expuesto físicamente y conectado a la red. Debe bloquear sesiones, proteger credenciales, restringir puertos y evitar cambios no autorizados. La administración remota debe estar autenticada y registrada.

La identificación debe permanecer personal. Un terminal compartido no justifica cuenta compartida. La persona cierra sesión y la siguiente inicia la suya. Las trazas deben distinguir actividad del usuario, del terminal y del administrador. En una investigación, estos tres niveles permiten saber quién accedió, desde dónde y qué cambio técnico se realizó.

13.7. Continuidad y evolución

LETSAS depende de conectividad y servicios corporativos. La continuidad debe contemplar enlace, autenticación, aplicaciones virtuales y actualización. Un fallo central puede afectar a muchos terminales, por lo que los servicios compartidos necesitan redundancia y monitorización. En el centro, deben existir procedimientos de contingencia ajustados a la actividad.

La evolución puede incorporar nuevos mecanismos de accesibilidad, comunicación, navegadores y clientes, como señala la documentación del SAS al describir actualizaciones continuas. Debe mantenerse el principio de plataforma controlada y compatible. Sustituir componentes no cambia su finalidad: proporcionar un acceso estable y gestionable a los servicios necesarios en Atención Primaria.

14. OPERACIÓN, SOPORTE, CONTINUIDAD, RENDIMIENTO Y ACCESIBILIDAD

El puesto de trabajo se convierte en servicio real durante la operación diaria. La arquitectura puede ser correcta y, sin embargo, fracasar por un inventario incompleto, actualizaciones mal coordinadas, soporte fragmentado o ausencia de métricas. La operación integra gestión de incidencias, peticiones, problemas, cambios, activos, configuración, capacidad, disponibilidad, seguridad y conocimiento. El centro de servicios ofrece el punto de contacto, mientras equipos especializados resuelven cada capa.

14.1. Diagnóstico por capas

Ante «no puedo trabajar», el técnico debe convertir el síntoma en alcance y capa. ¿Afecta a una persona, un terminal, un centro o toda la organización? ¿Funciona la red? ¿Se resuelve DNS? ¿Autentica la identidad? ¿Conecta el escritorio? ¿Abre la aplicación? ¿Accede al dato? ¿Imprime? Esta secuencia reduce escalados erróneos. El historial de cambios y la comparación con puestos equivalentes aportan evidencia.

En un puesto ligero, un fallo local puede manifestarse igual que uno central. Pantalla en negro puede ser cable, cliente remoto, broker o escritorio. La herramienta de monitorización debe correlacionar estado del terminal, sesión y backend. La observabilidad extremo a extremo emplea métricas, eventos y trazas, pero debe presentar una vista comprensible al soporte.

14.2. Incidencias, peticiones y problemas

Una incidencia restaura servicio; una petición solicita una prestación estándar; un problema busca la causa de incidencias repetidas. Reinstalar un controlador puede cerrar una incidencia, pero si el mismo defecto reaparece en cientos de puestos se necesita gestión de problemas y cambio en la imagen. La solución temporal debe documentarse y no sustituir indefinidamente a la corrección estructural.

La prioridad combina impacto y urgencia. Una impresora personal averiada puede tener impacto reducido, mientras una cola de etiquetas utilizada por varias consultas puede ser crítica. El contexto asistencial modifica la valoración. La automatización puede clasificar y recopilar datos, pero la prioridad debe reflejar servicio afectado, usuarios y alternativa disponible.

14.3. Gestión de cambios y despliegues

Los cambios de sistema operativo, navegador, cliente remoto, controlador o política pueden afectar a aplicaciones y periféricos. Deben pasar por pruebas, aprobación, ventana, comunicación y reversión. El piloto debe incluir perfiles representativos y centros con distintas condiciones. Un despliegue gradual limita alcance del fallo y genera evidencia antes de continuar.

Las actualizaciones de seguridad urgentes requieren rapidez, pero no omitir control. Se puede utilizar un procedimiento de cambio urgente con evaluación abreviada, autorización y revisión posterior. El inventario permite saber qué equipos quedan fuera por estar apagados o desconectados. El cumplimiento se mide por instalación efectiva, no por haber publicado el paquete.

14.4. Capacidad y rendimiento

La capacidad del puesto virtual se gestiona en varias capas. CPU y memoria determinan densidad; almacenamiento afecta arranque y perfiles; red condiciona presentación; identidad influye en inicio; aplicaciones y bases de datos dominan la transacción. Se deben medir percentiles, no solo medias, y observar horas punta. Un P95 elevado indica que una parte significativa de usuarios sufre demoras aunque la media sea aceptable.

Los objetivos deben expresarse en tareas. «Latencia de red inferior a X» no garantiza una consulta rápida si la aplicación tarda. Se registran tiempo de arranque, inicio de sesión, lanzamiento de aplicación, carga de paciente, impresión y cierre. La experiencia digital del empleado puede medirse con telemetría técnica y encuestas, evitando recopilar contenido personal.

14.5. Continuidad y recuperación

La continuidad identifica funciones esenciales, tiempo máximo de interrupción, dependencia y alternativa. En puestos virtuales se necesitan copias y recuperación de configuración, imágenes y perfiles, pero también redundancia de identidad, red y aplicaciones. Un plan que recupera máquinas virtuales sin DNS o certificados no restaura servicio. Las pruebas deben ser periódicas y documentar tiempos reales.

El puesto local puede tener una configuración de emergencia, pero debe mantenerse. Equipos de reserva necesitan parches, batería y credenciales válidas. La documentación debe estar disponible durante una caída del sistema de conocimiento. La contingencia manual debe contemplar reconciliación y protección de documentos.

14.6. Accesibilidad

La accesibilidad debe considerarse desde la adquisición. Pantallas, teclados, lectores, ampliadores, reconocimiento de voz y aplicaciones deben interoperar. Un escritorio remoto puede bloquear atajos o no transmitir correctamente tecnologías de apoyo. Las pruebas deben incluir personas y herramientas reales, no limitarse a validadores automáticos.

El diseño universal beneficia a todos: texto legible, foco visible, navegación por teclado, mensajes claros y tiempo suficiente reducen errores. Las adaptaciones individuales deben viajar con el perfil cuando sea posible, sin exponer datos de salud del trabajador. El soporte debe conocer cómo preservar estas configuraciones durante una sustitución.

14.7. Seguridad operacional

El puesto aplica bloqueo automático, actualizaciones, protección de código, filtrado, cifrado, mínimo privilegio y registros. Las cuentas administrativas se separan. Los dispositivos extraíbles se controlan según riesgo. La detección y respuesta en endpoints puede aislar un equipo; en VDI, debe coordinarse con la naturaleza no persistente para no perder evidencia.

Los administradores de MDM, VDI, impresión y LETSAS tienen privilegios significativos. Sus acciones deben autenticarse, registrarse y revisarse. La consola central es un objetivo de alto valor: comprometerla puede desplegar software o borrar dispositivos a escala. Se aplican MFA, segmentación, estaciones de administración protegidas y control de cambios.

15. CONCLUSIONES E IDEAS CLAVE

El puesto de trabajo moderno es una arquitectura distribuida. El dispositivo visible es solo el extremo de una cadena que incluye identidad, red, servicios centrales, aplicaciones, datos, impresión, soporte y seguridad. Esta visión evita respuestas simplistas. Un cliente ligero no es siempre mejor que un PC; BYOD no es siempre más barato; DaaS no es siempre más seguro; y centralizar no elimina la necesidad de continuidad.

Los puestos pesados ejecutan localmente y resultan adecuados cuando se requiere capacidad, offline o periféricos. Los puestos ligeros desplazan ejecución y datos hacia servicios centrales, lo que favorece homogeneidad y movilidad, pero aumenta dependencia de red e infraestructura. La elección se realiza por perfil, no por preferencia tecnológica.

La movilidad introduce valor asistencial y nuevos riesgos. Los modelos BYOD, COPE, COBO y CYOD definen titularidad y uso. MDM, EMM y UEM aplican gestión, pero su alcance debe respetar propiedad y privacidad. La seguridad móvil se basa en ciclo de vida: inscripción, configuración, cumplimiento, acceso condicional, respuesta y retirada.

VDI virtualiza el escritorio; la publicación remota entrega una aplicación; DaaS aplica un modelo de servicio cloud a la entrega de escritorios. On premise aporta control directo, cloud elasticidad y responsabilidad compartida, e híbrido combina ambos con mayor complejidad. El diseño debe incluir identidad personal, perfiles, periféricos, capacidad, observabilidad, reversibilidad y contrato.

La impresión y digitalización son parte del tratamiento de información. Una impresión puede exponer datos físicos; una multifunción puede almacenar copias; un OCR puede equivocarse; y una digitalización mal indexada puede incorporarse al paciente incorrecto. Colas, liberación segura, metadatos, control de calidad y trazabilidad son controles esenciales.

En Atención Primaria, el puesto debe responder a dispersión, movilidad, uso compartido y continuidad. La documentación del SAS sitúa LETSAS como sistema basado en Linux para terminales ligeros, gestionado centralmente y orientado al acceso a aplicaciones y servicios corporativos. Su administración se asocia, en la pregunta oficial, a Terminal de Consola, Panel Web local y Altiris.

15.1. Reglas de repaso

• Cliente pesado: ejecución y recursos locales; mayor autonomía, mayor gestión del extremo.
• Cliente ligero: acceso a recursos centrales; menor complejidad local, mayor dependencia común.
• BYOD: propiedad personal; requiere política, separación, transparencia y acceso limitado.
• MDM: administración de dispositivos; no es un modelo de propiedad ni un SIEM.
• VDI: escritorio completo virtualizado.
• Aplicación publicada: programa remoto sin entregar necesariamente escritorio completo.
• DaaS: escritorio como servicio; elasticidad y gestión compartida, no ausencia de responsabilidad.
• Impresión segura: retención y liberación tras autenticación.
• OCR: reconocimiento de texto, no garantía de autenticidad.
• LETSAS: sistema propio basado en Linux para terminales ligeros de Atención Primaria.

15.2. Trampas frecuentes

• Confundir terminal ligero con escritorio virtual.
• Afirmar que CYOD determina siempre quién es propietario.
• Suponer que el borrado remoto funciona sin conectividad.
• Creer que VDI elimina el riesgo de captura o impresión.
• Confundir agente VDA con la totalidad de una plataforma DaaS.
• Equiparar escaneo, OCR, indexación y copia auténtica.
• Usar una cuenta compartida porque el terminal es compartido.
• Atribuir a ayudaDIGITAL la administración técnica de LETSAS.

16. MAPA CONCEPTUAL