1. INTRODUCCIÓN Y DEFINICIÓN DEL PORTAL CORPORATIVO

Cuando hablamos de portales corporativos, nos referimos a plataformas web centralizadas que actúan como punto de acceso único (Single Point of Access) a información, aplicaciones y servicios de una organización. En el contexto del SAS, estos portales son la columna vertebral de la relación digital tanto con ciudadanos como con profesionales sanitarios.

En el ámbito sanitario público, los portales corporativos deben cumplir además con:

• Accesibilidad: Cumplimiento de la norma UNE-EN 301549 (nivel AA mínimo)
• Seguridad: Esquema Nacional de Seguridad (ENS), especialmente en autenticación y cifrado
• Protección de datos: RGPD/LOPDGDD para datos personales y de salud (categoría especial)
• Interoperabilidad: Esquema Nacional de Interoperabilidad (ENI) para integración con otros sistemas de la administración
• Administración electrónica: Ley 39/2015 (notificaciones electrónicas, sede electrónica, expediente electrónico)

1.2. Relevancia para el Técnico/a TFA-STI del SAS

Como futuro TFA-STI, tu trabajo con portales corporativos incluirá:

• Soporte técnico: Resolución de incidencias de acceso, rendimiento, integración con sistemas backend (Diraya, BDU, etc.)
• Gestión de contenidos: Supervisión de la publicación de información en intranets, revisión de metadatos, catalogación
• Seguridad: Configuración de políticas de autenticación (LDAP corporativo, certificados digitales, Cl@ve), auditoría de accesos
• Evolución: Participación en proyectos de mejora de portales, migración a nuevas plataformas, implementación de nuevas funcionalidades

El portal corporativo puede actuar como front door digital de la organización: orienta, permite descubrir servicios, identifica a la persona cuando es necesario y deriva cada operación al sistema responsable. El portal no debería duplicar la lógica clínica, económica o de recursos humanos. Su función arquitectónica es componer servicios, aplicar políticas transversales y ofrecer una interacción comprensible. Esta separación reduce inconsistencias y facilita que una misma capacidad pueda utilizarse desde web, aplicación móvil, atención telefónica o un punto presencial.

En el ámbito público conviene distinguir tres planos. El plano informativo publica contenidos generales; el plano transaccional permite iniciar o completar trámites; y el plano personal muestra información vinculada a la identidad, como citas, documentos o solicitudes. Cada plano exige controles distintos. Un error frecuente consiste en aplicar el mismo modelo de seguridad y de publicación a todo el portal: o se protege en exceso la información pública, degradando la usabilidad, o se expone con controles insuficientes una operación sensible.

2. PORTAL, SITIO WEB, INTRANET, EXTRANET, SEDE Y EXPERIENCIA DIGITAL

Los términos relacionados con portales se utilizan con frecuencia como sinónimos, pero en examen debes diferenciarlos por su finalidad y por el perímetro de usuarios. Un sitio web es un conjunto de recursos accesibles mediante HTTP o HTTPS bajo uno o varios dominios. Puede ser puramente informativo y carecer de integración o personalización. Un portal añade agregación de servicios, identidad, búsqueda transversal, navegación por perfiles y, en muchos casos, un área personal.

La intranet es un entorno web dirigido a miembros de la organización. Su acceso se restringe mediante red corporativa, VPN o autenticación. Puede incluir noticias, directorios, procedimientos, aplicaciones internas y espacios colaborativos. La extranet abre parte de ese entorno a terceros relacionados —proveedores, entidades colaboradoras, profesionales externos— aplicando segregación y reglas específicas. La diferencia no es tecnológica: intranet y extranet pueden utilizar los mismos protocolos de Internet; cambia el ámbito de confianza y autorización.

La sede electrónica tiene una naturaleza jurídica específica: es la dirección electrónica cuya titularidad corresponde a una Administración y a través de la cual se realizan actuaciones y trámites con garantías de identificación, autenticidad, integridad, disponibilidad y responsabilidad. Un portal institucional puede enlazar con una sede, pero no todo portal es sede. En una pregunta tipo test, «publicar noticias corporativas» caracteriza un portal; «realizar actuaciones administrativas con identificación de la sede y responsabilidad del titular» apunta a sede electrónica.

Una aplicación web resuelve un conjunto de funciones concretas y puede estar integrada dentro del portal. El portal actúa como contenedor o puerta de acceso, mientras que la aplicación conserva su dominio funcional. En arquitecturas modernas esa integración puede ser visual, mediante componentes, o por navegación federada con identidad única. También puede realizarse mediante microfrontends, donde distintas unidades despliegan módulos de interfaz independientes bajo un marco común.

El concepto de Digital Experience Platform o DXP amplía el CMS. Una DXP integra gestión de contenidos, perfiles, analítica, campañas, personalización, comercio o trámites e integración con sistemas externos. No toda organización necesita una DXP completa: adquirirla sin madurez editorial ni arquitectura de datos genera coste y dependencia. La selección debe partir de capacidades necesarias, no de etiquetas comerciales.

3. EVOLUCIÓN DE LOS PORTALES CORPORATIVOS

Los portales corporativos han evolucionado en paralelo con la web y las necesidades organizativas. La evolución se explica mediante un modelo didáctico y se conecta después con iniciativas del SAS.

3.1. Primera Generación: Portales Informativos (Web 1.0) – 1995-2003

3.2. Segunda Generación: Portales Transaccionales (Web 2.0) – 2004-2010

3.3. Tercera Generación: Portales Colaborativos y Personalizados (2011-2018)

3.4. Cuarta Generación: Portales Inteligentes y Omnicanales (2019-actualidad)

Esta clasificación por generaciones es didáctica, no un estándar normativo. En la práctica coexisten rasgos de varias etapas. Un portal puede ofrecer servicios transaccionales modernos y conservar secciones informativas gestionadas de forma tradicional. La evolución real se mide por el grado de integración, autoservicio, reutilización de capacidades, accesibilidad, gobierno del dato y continuidad entre canales.

La etapa actual se caracteriza por la separación entre contenido, servicios y canales. El contenido se modela y se publica mediante APIs; los servicios de negocio se ofrecen mediante contratos estables; y cada canal compone la experiencia según su contexto. Esta arquitectura permite que una corrección de un contenido sanitario se propague al portal, a la aplicación móvil y a otros puntos de contacto sin copiar y pegar.

Otra línea de evolución es el paso de la personalización superficial —elegir colores o mover portlets— a la adaptación contextual. El sistema puede priorizar contenidos según rol, centro, idioma, dispositivo o fase de un trámite. Sin embargo, cuanto más sofisticada es la personalización, más importantes son la transparencia, el control de sesgos y la conservación de una vía de acceso neutral. En servicios públicos no debe ocultarse información esencial porque un algoritmo estime que es poco relevante para una persona.

4. ARQUITECTURA LÓGICA DE UN PORTAL CORPORATIVO

Un portal corporativo moderno se estructura típicamente en 5 capas lógicas. Vamos a verlas con detalle, porque en el examen te pueden preguntar qué tecnologías van en cada capa o qué hace cada componente.

┌─────────────────────────────────────────────────────────────────┐
│                    CAPA DE PRESENTACIÓN                         │
│  [Navegador Web] [App Móvil] [Asistente Virtual] [API Externa] │
│        HTML5/CSS3/JavaScript (React, Angular, Vue)              │
│              Responsive Design | PWA | Accesibilidad            │
└─────────────────────────────────────────────────────────────────┘
                              ↓ HTTPS/WSS
┌─────────────────────────────────────────────────────────────────┐
│                     CAPA DE APLICACIÓN WEB                      │
│    [Servidor Web] Apache / Nginx / IIS                         │
│    [Motor Portal] Liferay / SharePoint / Drupal                │
│    • Gestión de sesiones    • Enrutamiento                     │
│    • Autenticación/Autorización  • Renderizado                 │
└─────────────────────────────────────────────────────────────────┘
                              ↓ API
┌─────────────────────────────────────────────────────────────────┐
│                   CAPA DE LÓGICA DE NEGOCIO                     │
│    [Servicios/APIs] REST / GraphQL / SOAP                       │
│    • Orquestación de procesos                                   │
│    • Validación de reglas de negocio                            │
│    • Transformación de datos                                    │
│    • Integración con sistemas backend (ESB)                     │
└─────────────────────────────────────────────────────────────────┘
                              ↓ 
┌─────────────────────────────────────────────────────────────────┐
│                   CAPA DE INTEGRACIÓN                           │
│    [Conectores] a Sistemas Legacy, APIs externas               │
│    [Bus de Servicios (ESB)] Gestión de mensajería              │
│    [API Gateway] Control de acceso, rate limiting, logging      │
│    [Caché] Redis / Memcached para rendimiento                   │
└─────────────────────────────────────────────────────────────────┘
                              ↓ 
┌─────────────────────────────────────────────────────────────────┐
│                      CAPA DE DATOS                              │
│  [BBDD Relacional] Oracle / PostgreSQL / MySQL                 │
│  [BBDD NoSQL] MongoDB / Cassandra (contenidos no estructurados)│
│  [Repositorio Documental] Alfresco / Documentum                 │
│  [Sistemas Backend] sistemas asistenciales, de población y de gestión corporativa                   │
└─────────────────────────────────────────────────────────────────┘
        

4.2. Capa de Presentación

Es la interfaz de usuario, lo que el ciudadano o profesional ve y con lo que interactúa.

4.2.1. Componentes clave

• Navegador web: Chrome, Firefox, Edge, Safari
• Aplicación móvil nativa o híbrida: iOS, Android
• PWA (Progressive Web App): Web que se comporta como app nativa
• Interfaz conversacional: Chatbots, asistentes de voz

4.2.2. Tecnologías frontend

• HTML5: Estructura semántica, nuevos elementos (<header>, <nav>, <article>)
• CSS3: Media queries (responsive), flexbox/grid, animaciones
• JavaScript: Frameworks/librerías modernas
  • React: Componentes reutilizables, virtual DOM
  • Angular: Framework completo, TypeScript
  • Vue.js: Progresivo, fácil integración

4.2.3. Requisitos en el SAS

• Responsive design: Adaptación a móvil, tablet, escritorio
• Accesibilidad: conformidad con el Real Decreto 1112/2018 y la EN 301 549 vigente, aplicando los criterios WCAG incorporados
• Navegación con teclado, textos alternativos en imágenes, contraste suficiente
• Compatibilidad con lectores de pantalla (JAWS, NVDA)

4.3. Capa de Aplicación Web (Servidor Web y Motor de Portal)

Aquí es donde vive el portal como aplicación. Incluye el servidor web y la plataforma de portal.

4.3.1. Servidores web comunes en entornos corporativos

• Apache HTTP Server: Open source, muy configurable, ampliamente usado en Linux
• Nginx: Alto rendimiento, proxy inverso, balanceo de carga
• Microsoft IIS: Integrado con Windows Server, usado con SharePoint
• Apache Tomcat: Contenedor de servlets Java (JSP)

4.3.2. Plataformas de portal (Portal Frameworks)

• Liferay: Java, enterprise, componentes de portal y capacidades enterprise, utilizado en entornos corporativos
• SharePoint: Microsoft, integración Office 365, gestión documental
• Drupal: PHP, CMS flexible, utilizado en portales públicos y corporativos
• Desarrollos custom: Frameworks web (Spring Boot, Django, .NET Core) + frontend

4.4. Capa de Lógica de Negocio

Aquí se implementan las reglas de negocio y los servicios que consumen las capas superiores.

4.4.1. Servicios REST vs SOAP

4.4.2. Funciones de esta capa

• Orquestación: Coordinar llamadas a múltiples sistemas backend según el proceso de negocio
• Validación: Comprobar datos según reglas de negocio (formato NIF, fecha válida, etc.)
• Transformación: Convertir entre formatos (JSON ↔ XML, mapeo de campos)
• Caché de datos: Almacenar temporalmente respuestas frecuentes (Redis)
• Gestión de transacciones: Garantizar consistencia en operaciones distribuidas

4.5. Capa de Integración

Esta capa es crítica en entornos corporativos complejos, donde deben integrarse múltiples sistemas con ciclos de vida, tecnologías y responsables diferentes.

4.5.1. Enterprise Service Bus (ESB)

Un ESB es una plataforma de mediación e integración que puede centralizar transformación, enrutamiento y políticas de intercambio entre sistemas.

4.5.3. API Gateway

Punto de entrada único para todas las APIs del portal. Funciones:

• Autenticación y autorización: Validar tokens (JWT, OAuth)
• Rate limiting: Limitar peticiones por usuario/IP (evitar abuso)
• Logging y monitorización: Trazabilidad de todas las llamadas
• Transformación de respuestas: Adaptar formato según cliente (móvil vs web)

Ejemplos: Kong, Apigee (Google), AWS API Gateway, Azure API Management

4.6. Capa de Datos

Esta capa reúne los repositorios propios del portal y los mecanismos de acceso controlado a datos de sistemas responsables. No implica copiar toda la información de los sistemas integrados.

4.6.1. Tipos de repositorios

• Base de datos relacional (RDBMS):
  • Datos estructurados del portal (usuarios, perfiles, sesiones, logs)
  • Tecnologías: bases relacionales corporativas como PostgreSQL, Oracle Database, SQL Server o MySQL/MariaDB, según arquitectura
  • Ejemplo: configuración del portal, perfiles editoriales y estados de workflow; la identidad corporativa puede residir en un servicio especializado
• Base de datos NoSQL:
  • Contenidos no estructurados, documentos, metadatos complejos
  • Tipos: Documental (MongoDB), clave-valor (Redis), columnar (Cassandra)
  • Ejemplo: Almacenar configuraciones JSON de widgets personalizados
• Repositorio documental:
  • Gestión de documentos (PDFs, Word, imágenes) con metadatos, versiones, flujos de trabajo
  • Tecnologías: Alfresco, OpenText Documentum, SharePoint
  • Ejemplo SAS: Repositorio de documentación interna (protocolos, manuales, formularios)
• Sistemas backend corporativos:
  • Diraya (historia clínica digital)
  • BDU (base de datos de usuarios)
  • Sistemas corporativos de listas de espera y agendas asistenciales
  • Sistemas corporativos de recursos humanos

La arquitectura debe entenderse como un conjunto de responsabilidades, no como una lista rígida de productos. En un despliegue pequeño varias responsabilidades pueden residir en el mismo servidor; en uno corporativo se distribuyen para escalar, aislar fallos y gobernar los cambios. La referencia útil para el examen es seguir una petición desde el navegador hasta el sistema de negocio.

El servidor web termina o reenvía conexiones HTTP, sirve recursos estáticos y puede actuar como proxy inverso. El motor de portal compone páginas, navegación, componentes y áreas personales. El CMS administra contenidos; el buscador mantiene índices optimizados; y la capa de servicios ejecuta las reglas de negocio. Confundir estas piezas conduce a diseños donde el CMS contiene lógica transaccional difícil de probar y mantener.

El API Gateway concentra políticas de entrada: validación de tokens, límites de consumo, enrutamiento, observabilidad y transformaciones ligeras. Un ESB o plataforma de integración aborda mediación más compleja, composición y adaptación entre sistemas heterogéneos. En arquitecturas de microservicios puede sustituirse parte del ESB por eventos, colas y servicios especializados; no obstante, el problema de integración sigue existiendo aunque cambie el producto.

La capa de datos debe separar el repositorio de contenidos, los perfiles, los índices de búsqueda, la caché y los datos maestros. No es correcto copiar toda la historia clínica a la base de datos del portal para acelerar consultas. El portal debe acceder a servicios autorizados, aplicar minimización y cachear únicamente aquello que sea seguro, coherente y tenga una política de caducidad definida.

GET /api/agenda/v1/citas
Authorization: Bearer <token>
X-Correlation-ID: 7c3d...
Accept: application/json

HTTP/1.1 200 OK
Cache-Control: no-store
Content-Type: application/json

El ejemplo muestra tres controles: identidad mediante token, trazabilidad mediante identificador de correlación y prohibición de caché para una respuesta personal sensible. La arquitectura no se limita a «que funcione»; debe expresar requisitos de seguridad y operación en cada contrato.

5. IDENTIDAD, SEGURIDAD, PRIVACIDAD E INTEROPERABILIDAD

Un portal sanitario combina información pública con datos personales y, en determinadas áreas, datos de salud. Por ello necesita un diseño de seguridad por zonas. La portada pública puede beneficiarse de CDN y caché amplia; el área personal requiere autenticación, autorización, sesiones protegidas y ausencia de almacenamiento compartido de respuestas sensibles. La segmentación debe reflejarse en dominios, rutas, políticas de caché, cabeceras y monitorización.

5.1. Identificación, autenticación y autorización

Identificar es declarar quién es la persona; autenticar es verificarlo; autorizar es decidir qué puede hacer. El inicio de sesión único puede implementarse con SAML 2.0 o con OpenID Connect sobre OAuth 2.0. OAuth 2.0 por sí solo delega autorización; OpenID Connect añade una capa de identidad. En aplicaciones móviles deben emplearse flujos adecuados para clientes públicos, navegador del sistema y PKCE, evitando incrustar credenciales en la aplicación.

La autorización puede ser RBAC, basada en roles, o ABAC, basada en atributos y contexto. En un portal profesional el rol «editor» puede publicar en una sección, mientras que los atributos «centro», «unidad» y «tipo de contenido» restringen su alcance. En servicios de ciudadanía, la representación de otra persona no debe resolverse compartiendo credenciales: requiere una relación representativa verificada, acotada y auditable.

5.2. Sesiones y protección web

Las cookies de sesión deben utilizar Secure, HttpOnly y una política SameSite adecuada. Deben renovarse identificadores después de autenticar, establecer tiempos de inactividad y absolutos y permitir revocación. Frente a CSRF se emplean tokens, cabeceras y políticas de origen; frente a XSS, codificación contextual, plantillas seguras y Content Security Policy; frente a inyección, consultas parametrizadas; y frente a cargas maliciosas, validación de tipo, antivirus, almacenamiento aislado y control de tamaño.

Content-Security-Policy: default-src 'self'; img-src 'self' data:; object-src 'none'
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin

Estas cabeceras reducen superficies de ataque, pero no sustituyen una programación segura. Un CMS actualizado puede seguir siendo vulnerable por un complemento inseguro o por permisos excesivos. La gestión de extensiones, temas y dependencias debe formar parte del inventario y del proceso de cambios.

5.3. ENS, protección de datos y trazabilidad

El Esquema Nacional de Seguridad exige gestionar riesgos y aplicar medidas proporcionadas a la categoría del sistema. En el portal deben definirse responsables, inventario, control de acceso, protección de comunicaciones, registro, detección, copias, continuidad y gestión de incidentes. El RGPD y la LOPDGDD añaden licitud, transparencia, minimización, limitación de finalidad y derechos. Los registros de acceso deben ser suficientes para investigar y rendir cuentas, pero no convertirse en una copia indiscriminada de datos sensibles.

La analítica web merece un tratamiento específico. Medir rendimiento y uso es legítimo cuando se diseña con minimización y una base jurídica adecuada, pero no todo identificador es anónimo. Direcciones IP, identificadores persistentes y combinaciones de comportamiento pueden ser datos personales. Deben documentarse finalidades, retención, proveedores, transferencias y mecanismos de exclusión cuando procedan.

5.4. Interoperabilidad

El portal debe interoperar en los planos organizativo, semántico y técnico. La interoperabilidad organizativa define responsables y procesos; la semántica garantiza que «centro», «profesional» o «episodio» tengan significado compartido; y la técnica utiliza estándares, APIs y formatos. En sanidad pueden aparecer HL7, CDA o FHIR para datos clínicos, pero el portal no debe inventar su propio significado cuando existe un modelo corporativo.

6. GESTIÓN DE CONTENIDOS: DEFINICIÓN, MODELOS Y COMPONENTES

Un CMS es el software que permite crear, gestionar, organizar y publicar contenidos digitales sin necesidad de conocimientos técnicos avanzados.

6.1. Definición y Concepto

6.2. Tipos de CMS

6.2.1. CMS Tradicional (Coupled / Monolítico)

El CMS gestiona tanto el contenido como la presentación. Backend y frontend están acoplados.

• Ejemplos: WordPress, Joomla, Drupal (en modo tradicional)
• Ventajas: Fácil de usar, ecosistema de plugins/temas, menor curva de aprendizaje
• Desventajas: Menos flexibilidad para múltiples canales (web + app móvil), rendimiento limitado en escala

6.2.2. Headless CMS (Desacoplado)

El CMS solo gestiona el contenido y lo expone mediante APIs. La presentación es responsabilidad de aplicaciones externas.

• Ejemplos: Strapi, Contentful, Sanity, Directus
• Ventajas:
  • Omnicanalidad real: mismo contenido para web, app móvil, smartwatch, kiosco
  • Flexibilidad tecnológica: frontend en React, Angular, Vue, app nativa iOS/Android
  • Mejor rendimiento: APIs RESTful o GraphQL optimizadas
• Desventajas: Requiere equipo de desarrollo, mayor complejidad inicial

6.2.3. Hybrid CMS

Combina lo mejor de ambos mundos: tiene frontend propio pero también expone APIs.

• Ejemplos: Drupal en modo desacoplado, WordPress con REST API
• Uso típico: Administraciones públicas que necesitan web tradicional + apps móviles

6.3. Componentes Funcionales de un CMS

6.4. Herramientas CMS: Comparativa

6.4.1. WordPress

6.4.2. Drupal

6.4.3. Liferay Portal

6.4.4. Microsoft SharePoint

6.4.5. Alfresco

El CMS debe separar tres conceptos: contenido, presentación y canal. El contenido es una unidad con significado —una noticia, una guía, una ficha de servicio—; la presentación es la plantilla que la muestra; y el canal es el medio de entrega. Cuando el contenido se almacena como bloques estructurados, puede reutilizarse sin copiarlo. Cuando se guarda como una página HTML monolítica, la reutilización y la accesibilidad dependen de edición manual.

Un modelo de contenido describe campos, tipos, obligatoriedad, relaciones, validaciones y taxonomías. Por ejemplo, una ficha de servicio sanitario puede incluir título, resumen, destinatarios, requisitos, pasos, canal, responsable, fecha de revisión y nivel de identificación. Este enfoque permite generar páginas, resultados de búsqueda, tarjetas móviles y datos estructurados desde una misma fuente.

{
  "type": "servicio-digital",
  "title": "Consulta de citas",
  "audience": ["ciudadania"],
  "authenticationLevel": "alto",
  "owner": "unidad-responsable",
  "reviewDate": "2026-12-01",
  "channels": ["web", "app"]
}

El modelo evita que cada editor redacte de forma distinta los mismos conceptos. También facilita controles automáticos: impedir publicar sin responsable, avisar de revisiones vencidas o excluir de la caché contenidos marcados como personales. La calidad editorial se convierte así en una propiedad del sistema, no solo en una revisión manual.

7. CICLO DE VIDA, WORKFLOW Y GOBIERNO EDITORIAL

La gestión de contenidos comienza antes de escribir y termina después de retirar la publicación. El ciclo de vida habitual comprende planificación, creación, revisión, aprobación, publicación, distribución, actualización, archivo y eliminación. Cada fase debe tener un propietario, criterios de entrada y salida y evidencias. Sin este gobierno, el portal acumula páginas duplicadas, normativa derogada, teléfonos antiguos y documentos sin responsable.

7.1. Estados y transiciones

Un workflow sencillo utiliza los estados borrador, en revisión, aprobado, programado, publicado y archivado. La transición debe exigir permisos y puede incluir firma o conformidad. El autor no debería aprobar su propio contenido cuando el riesgo exige segregación de funciones. En una información clínica divulgativa, la revisión técnica puede corresponder a una unidad asistencial y la revisión editorial a comunicación o ciudadanía.

7.2. Versiones y auditoría

El versionado conserva el historial y permite comparar, restaurar y atribuir cambios. No sustituye a una copia de seguridad: la copia protege ante pérdida o corrupción del sistema; el versionado protege la evolución lógica de cada contenido. Para evidencias administrativas o documentos firmados pueden requerirse repositorios documentales y políticas de conservación diferentes de las del CMS.

La auditoría debe registrar quién creó, modificó, aprobó, publicó, despublicó o eliminó, así como los cambios de permisos y configuración. Los registros deben ser íntegros y revisables. Una cuenta compartida «editor_web» impide atribución y debe evitarse. Las cuentas de servicio se limitan a integraciones y no deben utilizarse para edición humana.

7.3. Responsabilidades

7.4. Conservación y retirada

Archivar no significa dejar una página antigua indexada como si estuviera vigente. Debe decidirse si se conserva por valor histórico, si se redirige a una versión actual, si se retira del buscador o si se elimina conforme a una política. Los enlaces entrantes y los códigos de respuesta HTTP forman parte del proceso: una redirección permanente es adecuada cuando existe sustituto; un 410 puede indicar retirada definitiva; un 404 genérico sin orientación degrada la experiencia.

8. CATALOGACIÓN, METADATOS, TAXONOMÍAS Y ONTOLOGÍAS

8.1. Catalogación de Contenidos

La catalogación es el proceso de organizar y clasificar contenidos mediante metadatos estructurados para facilitar su búsqueda, recuperación y gestión.

8.1.1. Sistemas de clasificación

8.1.2. Taxonomías (jerárquicas)

• Clasificación en categorías y subcategorías en forma de árbol
• Ejemplo SAS:
  • Salud Pública
    • Vacunación
      • Calendario vacunal infantil
      • Vacunas para viajeros
    • Programas de cribado
      • Cribado de cáncer de mama
      • Cribado de cáncer colorrectal

8.1.3. Folksonomías (etiquetado social)

• Etiquetas libres que los usuarios asignan
• Útil para descubrir conexiones inesperadas
• Problema: Vocabulario no controlado (sinónimos, errores ortográficos)

8.1.4. Ontologías (semánticas)

• Definen relaciones complejas entre conceptos
• Usado en búsqueda semántica, IA
• Ejemplo sanitario: SNOMED CT (terminología clínica), CIE-10 (diagnósticos)

8.1.5. Metadatos esenciales

Los metadatos pueden clasificarse en descriptivos —título, resumen, autor, materia—; administrativos —responsable, permisos, estado—; técnicos —formato, tamaño, resolución—; estructurales —relaciones entre partes—; y de preservación —eventos, procedencia, integridad—. Un mismo campo puede servir a varias funciones, pero el esquema debe definir significado, cardinalidad y vocabulario.

Dublin Core proporciona términos ampliamente utilizados para describir recursos, como title, creator, subject, description, publisher, date, type, format, identifier, language, relation, coverage y rights. No obliga a que un portal use exactamente esos nombres internos, pero ofrece una base interoperable y evita esquemas improvisados.

8.2. Vocabularios controlados

Una taxonomía organiza conceptos, normalmente de forma jerárquica. Un tesauro añade relaciones de equivalencia, jerarquía y asociación, incluyendo términos preferidos y no preferidos. Una folksonomía surge de etiquetas libres y puede mejorar descubrimiento, pero introduce sinónimos, errores y ambigüedad. Una ontología formaliza clases, propiedades, restricciones y relaciones con semántica procesable.

En un portal sanitario conviene reutilizar terminologías corporativas para centros, unidades, especialidades y tipos de documento. No debe utilizarse una terminología clínica compleja para cualquier etiqueta editorial, pero sí evitar que «AP», «Atención primaria» y «Primaria» sean categorías independientes sin equivalencia. La gobernanza del vocabulario incluye alta, modificación, depreciación y mapeo de términos.

8.3. Clasificación facetada

La clasificación facetada permite combinar dimensiones independientes: audiencia, tema, centro, tipo de recurso, fecha o canal. Es más flexible que un árbol único. Un manual puede pertenecer a «profesionales», «gestión TIC», «ayudaDIGITAL» y «PDF» sin duplicarse en cuatro ramas. El buscador utiliza esas facetas para filtrar resultados.

8.4. Identificadores, URL y relaciones

Los contenidos deben tener identificadores persistentes independientes del título. Las URL legibles ayudan a personas y buscadores, pero no deben convertirse en la clave primaria. Las relaciones es versión de, sustituye a, forma parte de o está relacionado con permiten construir navegación contextual y preservar trazabilidad.

9. SUBSCRIPCIÓN, SINDICACIÓN Y DISTRIBUCIÓN DE CONTENIDOS

9.1. Suscripción de Contenidos

Los usuarios pueden suscribirse para recibir notificaciones cuando se publique contenido relevante.

9.1.1. Mecanismos de suscripción

• RSS/Atom feeds: Estándar XML para sindicación de contenidos
  • Los usuarios agregan feeds a lectores (Feedly, Inoreader)
  • Útil para blogs, noticias, actualizaciones
• Newsletters por email:
  • El usuario proporciona su correo y elige frecuencia (diaria, semanal, mensual)
  • Resumen de novedades enviado automáticamente
• Notificaciones push:
  • En apps móviles o navegadores web (Web Push API)
  • Ejemplo genérico: una aplicación profesional envía avisos sobre eventos relevantes autorizados
• Alertas personalizadas:
  • El usuario define criterios (tema, autor, categoría)
  • Sistema notifica solo cuando hay coincidencia

9.1.2. Ejemplo práctico en el SAS

El enunciado oficial utiliza «subscripción»; en el uso actual también es frecuente «suscripción». Técnicamente consiste en registrar el interés de una persona o sistema por un tema, evento o recurso para recibir cambios sin consultar continuamente el portal. Debe distinguirse de la sindicación, que publica un flujo estructurado para que otros consumidores lo recuperen, y de la notificación, que entrega un aviso por un canal concreto.

9.2. Pull y push

En el modelo pull, el cliente consulta periódicamente un feed RSS o Atom. Es simple y desacoplado, pero introduce demora y tráfico. En el modelo push, el servidor envía un evento mediante notificación móvil, correo, webhook o protocolo de publicación-suscripción. El push reduce demora, aunque requiere gestionar disponibilidad del receptor, reintentos, duplicados y consentimiento.

<entry>
  <title>Actualización de guía profesional</title>
  <id>urn:sas:content:guia-123:version-7</id>
  <updated>2026-08-04T12:00:00Z</updated>
  <category term="gestion-tic"/>
  <link href="https://portal.example/guia-123"/>
</entry>

El identificador y la fecha permiten al consumidor detectar novedades sin depender del título. En integraciones máquina a máquina conviene firmar o autenticar webhooks, incluir un identificador de evento y hacer idempotente el receptor para soportar reenvíos.

9.3. Preferencias y granularidad

Una buena suscripción permite seleccionar tema, frecuencia y canal. Las opciones «inmediata», «resumen diario» o «resumen semanal» reducen fatiga. Debe existir una forma sencilla de cancelar o modificar preferencias. En comunicaciones esenciales —por ejemplo, una incidencia de seguridad o una cita— la base y las reglas pueden ser distintas de un boletín voluntario; no deben mezclarse en la misma casilla de consentimiento.

9.4. Eventos y arquitectura

Los portales modernos utilizan brokers de mensajes y eventos de dominio. Cuando se publica una nueva versión, el CMS emite un evento; el buscador reindexa, la caché invalida, el servicio de notificaciones evalúa suscriptores y la analítica registra el despliegue. Esta arquitectura evita llamadas síncronas encadenadas, pero exige gobierno de esquemas, trazabilidad y manejo de errores.

10. PERSONALIZACIÓN, SEGMENTACIÓN Y RECOMENDACIÓN

10.1. Personalización de Contenidos

Adaptar la experiencia del portal a las preferencias, rol y comportamiento de cada usuario.

10.1.1. Tipos de personalización

10.1.2. Personalización explícita (usuario configura)

• Widgets/portlets configurables: El usuario elige qué ver en su dashboard
  • Ejemplo: Médico en E-atención al profesional elige ver: «Mis turnos», «Nómina», «Formación pendiente»
• Preferencias de idioma
• Tema visual: Modo claro/oscuro, tamaño de fuente
• Frecuencia de notificaciones

10.1.3. Personalización implícita (sistema adapta automáticamente)

• Basada en rol:
  • Médico de Atención Primaria ve recursos de AP
  • Enfermera de UCI ve protocolos de críticos
  • Administrativo ve gestión de citas, facturación
• Basada en ubicación:
  • Usuario en Hospital Virgen del Rocío ve noticias del centro
  • Usuario en consultorio rural ve información de AP
• Basada en comportamiento (Machine Learning):
  • Si consulta frecuentemente protocolos de cardiología → recomendación de cursos de formación en cardio
  • Si descarga habitualmente manuales de Diraya → sugerencia de nuevas funcionalidades

10.1.4. Tecnologías de personalización

• Cookies y sesiones: Recordar preferencias
• Perfil de usuario: Almacenar configuración en BBDD
• Reglas de negocio: If rol=médico AND especialidad=pediatría THEN mostrar_sección(«Pediatría»)
• Sistemas de recomendación: Filtrado colaborativo (usuarios similares), filtrado por contenido

10.1.5. Cuidado con la personalización

La personalización puede ser explícita, cuando la persona selecciona preferencias; basada en perfil, según rol o unidad; contextual, según dispositivo, idioma o momento; conductual, según interacciones; y predictiva, cuando un modelo estima relevancia. Cada tipo incrementa complejidad y riesgo. La primera opción suele ser preferible cuando resuelve la necesidad con mayor transparencia.

10.2. Reglas frente a modelos

Las reglas deterministas son fáciles de explicar: «si el usuario pertenece al centro X, mostrar avisos de X». Los modelos de recomendación pueden descubrir patrones, pero requieren datos, evaluación y supervisión. En un portal público, la mejora marginal de clics no justifica por sí sola perfilar extensamente a la ciudadanía. Deben definirse métricas de servicio, no solo de interacción.

10.3. Límites de seguridad y equidad

La personalización nunca debe ampliar permisos. Puede ordenar contenidos que la persona ya está autorizada a ver, pero no sustituye la autorización del backend. Tampoco debe ocultar derechos, plazos o información de seguridad. Los modelos deben evaluarse por grupos relevantes y ofrecer alternativas. Una recomendación sanitaria no puede presentarse como decisión clínica si no ha sido diseñada y gobernada para esa finalidad.

10.4. Privacidad desde el diseño

Debe aplicarse minimización: usar el atributo menos intrusivo que resuelva el caso, limitar retención y separar analítica de identidad cuando sea posible. La información al usuario debe explicar qué se adapta, con qué datos y cómo desactivarlo. El perfilado definido por el RGPD comprende tratamiento automatizado para evaluar aspectos personales; si produce decisiones con efectos jurídicos o significativamente similares, entran además las garantías específicas del artículo 22.

Una arquitectura prudente almacena preferencias en un servicio dedicado, registra su procedencia y permite exportarlas o borrarlas. Las cachés deben variar por los atributos necesarios; incluir demasiados atributos fragmenta la caché y puede provocar fugas entre perfiles si las claves están mal diseñadas.

11. HERRAMIENTAS DE GESTIÓN DE CONTENIDOS Y CRITERIOS DE SELECCIÓN

El mercado agrupa herramientas con finalidades diferentes. Un WCMS gestiona contenido web; un DMS o gestor documental controla archivos y expedientes; un ECM cubre contenido empresarial; un DAM administra activos multimedia; una wiki favorece conocimiento colaborativo; y una DXP orquesta experiencias. Elegir por marca sin distinguir la categoría produce requisitos contradictorios.

11.1. Familias habituales

11.2. Criterios funcionales

Deben evaluarse modelado de contenido, edición, workflow, versiones, multilingüismo, accesibilidad del editor, taxonomías, buscador, formularios, integración, APIs, previsualización, programación, publicación multisitio, personalización y analítica. Los requisitos se expresan como casos verificables: «un revisor puede devolver una versión con comentario sin modificar el original» es mejor que «workflow avanzado».

11.3. Criterios no funcionales

Incluyen seguridad, rendimiento, escalabilidad, disponibilidad, portabilidad, observabilidad, mantenibilidad, soporte, comunidad, ciclo de actualizaciones y compatibilidad con la infraestructura. Debe analizarse el modelo de licencias completo: software, suscripciones, módulos, base de datos, infraestructura, soporte, desarrollo y migración. El coste de salida es tan importante como el de entrada.

11.4. Interoperabilidad y bloqueo de proveedor

La exportación debe conservar contenido, metadatos, relaciones, versiones relevantes y activos. Una API propietaria no garantiza portabilidad si los datos solo pueden extraerse en una representación incompleta. Estándares como CMIS facilitan trabajar con repositorios de gestión de contenidos mediante un modelo y bindings comunes, aunque no eliminan todas las diferencias de producto.

Para reducir vendor lock-in se definen modelos propios, contratos API, formatos abiertos, automatización de despliegue, propiedad del código y pruebas de exportación. La pregunta oficial TFA-STI SAS 2025 sobre bloqueo de proveedor lo definió como dependencia que dificulta migrar a otra plataforma; este concepto es plenamente aplicable a un CMS.

11.5. Selección mediante prueba de concepto

Una prueba de concepto debe utilizar contenidos reales y cubrir el camino completo: crear, revisar, publicar, buscar, consumir por API, invalidar caché, restaurar versión y exportar. No basta una demostración preparada por el proveedor. Deben medirse tiempos editoriales, rendimiento, accesibilidad y esfuerzo de operación.

12. BÚSQUEDA, INDEXACIÓN, SEO Y WEB SEMÁNTICA

El portal pierde valor si la persona no puede encontrar el contenido. La búsqueda corporativa suele utilizar un motor de índices invertidos independiente de la base transaccional. El CMS envía documentos normalizados; el motor tokeniza, analiza idioma, calcula relevancia y genera facetas. Las actualizaciones deben reindexarse de forma incremental y existir procedimientos de reconstrucción completa.

12.1. Relevancia y experiencia

La relevancia combina coincidencia textual, campos con distinto peso, actualidad, popularidad y reglas de negocio. Debe evitarse que la popularidad oculte información oficial reciente. Las páginas críticas pueden tener promociones controladas. Las búsquedas sin resultado son una fuente de requisitos: revelan vocabulario de usuarios, contenidos ausentes o sinónimos no contemplados.

El buscador debe mostrar título, resumen, tipo, fecha y contexto; permitir filtros; tolerar errores; respetar permisos; y no indexar datos personales en un índice público. La seguridad por ocultación en la interfaz es insuficiente: cada resultado y cada descarga deben comprobar autorización.

12.2. SEO y arquitectura de información

El SEO técnico incluye títulos únicos, encabezados jerárquicos, URL estables, metadatos, enlaces internos, mapas del sitio, datos estructurados y rendimiento. En un portal público el objetivo no es captar tráfico comercial, sino que la información oficial aparezca ante consultas reales. La redacción debe usar lenguaje ciudadano sin abandonar precisión.

12.3. Datos estructurados y semántica

JSON-LD y vocabularios como Schema.org permiten describir organizaciones, servicios, eventos y preguntas frecuentes. RDF y OWL ofrecen modelos más formales. La web semántica no consiste en añadir palabras clave ocultas; consiste en representar entidades y relaciones de modo procesable. En sanidad, las ontologías y terminologías deben gobernarse y mapearse con cuidado.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "GovernmentService",
  "name": "Servicio sanitario digital",
  "provider": {"@type": "GovernmentOrganization", "name": "Organismo responsable"}
}
</script>

El bloque se muestra como ejemplo conceptual; en el fragmento final de WordPress no se insertan scripts porque el contrato del tema los prohíbe. Lo importante es reconocer el formato y su finalidad.

12.4. Búsqueda semántica moderna

La búsqueda vectorial representa textos como vectores y recupera proximidad de significado. Puede combinarse con búsqueda léxica, filtros y reranking. En documentación sanitaria o técnica debe conservarse la trazabilidad: el resultado debe enlazar a la fuente, respetar permisos y no inventar respuestas. Los asistentes generativos pueden resumir, pero necesitan recuperación controlada, citas y límites de uso.

13. ACCESIBILIDAD, USABILIDAD, RENDIMIENTO Y CALIDAD

La accesibilidad es un requisito del servicio público, no una fase estética al final. El Real Decreto 1112/2018 regula la accesibilidad de sitios web y aplicaciones móviles del sector público y remite a la norma armonizada aplicable, EN 301 549. WCAG organiza sus principios en contenido perceptible, operable, comprensible y robusto. WCAG 2.2 es la recomendación W3C actual y fue reconocida como estándar ISO/IEC 40500:2025, aunque la referencia jurídica concreta debe comprobarse en la norma armonizada vigente.

13.1. Contenido y componentes accesibles

Las imágenes necesitan alternativa textual cuando transmiten información; los formularios requieren etiquetas, instrucciones y errores asociados; la navegación debe funcionar con teclado; el foco debe ser visible; y la estructura de encabezados debe representar el documento. Los componentes personalizados deben exponer nombre, rol, estado y valor. ARIA complementa HTML cuando es necesario, pero no corrige una semántica incorrecta.

El CMS debe ayudar al editor: impedir saltos de encabezado, pedir texto alternativo, generar tablas con cabeceras, comprobar contraste y ofrecer previsualización. Sin estas salvaguardas, cada publicación puede degradar la conformidad aunque la plantilla sea accesible.

13.2. Usabilidad y lenguaje claro

La usabilidad evalúa eficacia, eficiencia y satisfacción en un contexto. Deben realizarse pruebas con tareas reales, incluyendo personas con discapacidad y baja alfabetización digital. Los nombres internos de aplicaciones o unidades no deben dominar la navegación. La persona busca «consultar una cita» o «registrar una incidencia», no necesariamente conoce la estructura organizativa.

Los mensajes de error deben indicar qué ocurrió, cómo resolverlo y si la operación se registró. En trámites sensibles se debe evitar que un reintento duplique la solicitud. La confirmación debe incluir referencia y siguiente paso. Un diseño responsive solo adapta la disposición; no garantiza que el viaje sea comprensible ni accesible.

13.3. Rendimiento

El rendimiento influye en accesibilidad, satisfacción y capacidad. Se optimizan imágenes, fuentes, JavaScript, caché, compresión y entrega por CDN. Los indicadores de experiencia web ayudan a detectar problemas, pero deben complementarse con tiempos de backend y tareas completas. Una portada rápida que tarda treinta segundos al autenticar no ofrece buen servicio.

La caché debe diferenciar contenido público, personalizado y sensible. El contenido público versionado puede usar tiempos largos e invalidación; las respuestas personales suelen usar no-store. La invalidación se integra con publicación para evitar mostrar versiones antiguas después de una corrección urgente.

13.4. Calidad verificable

14. ADMINISTRACIÓN, DEVSECOPS, OBSERVABILIDAD Y CONTINUIDAD

Un portal corporativo es un servicio en producción que debe operarse durante años. El modelo operativo incluye entornos separados, control de configuración, despliegues automatizados, gestión de secretos, parcheo, copias, monitorización, capacidad y soporte. La administración manual directa en producción impide reproducibilidad y aumenta errores.

14.1. Entornos y despliegue

Desarrollo, integración, preproducción y producción deben tener configuraciones controladas. El contenido puede seguir un flujo diferente del código, pero ambos requieren promoción y reversión. Las migraciones de esquema se prueban con volumen representativo y plan de vuelta atrás. Los secretos no se almacenan en repositorios ni en plantillas del CMS.

El enfoque DevSecOps integra análisis de dependencias, pruebas estáticas y dinámicas, escaneo de contenedores, validación de infraestructura y pruebas de accesibilidad. No todos los hallazgos tienen el mismo riesgo; deben priorizarse según exposición, impacto y explotabilidad. Las extensiones del CMS son software y entran en el mismo proceso.

14.2. Observabilidad

La observabilidad combina métricas, logs y trazas. Deben medirse tasas de error, latencia, saturación, colas, caché, indexación y publicación. Un identificador de correlación permite seguir una solicitud por gateway, servicios e integración. Los datos de observabilidad deben minimizar información personal y aplicar retención y acceso.

Los monitores sintéticos comprueban recorridos críticos; la monitorización real de usuario observa experiencia; y las pruebas de salud verifican componentes. Un 200 OK de la portada no demuestra que se pueda completar una cita o registrar una petición. Los indicadores de nivel de servicio deben representar viajes.

14.3. Copias y recuperación

Se copian bases, activos, configuración, claves y, cuando proceda, índices regenerables. La copia no es válida hasta restaurarla. RPO y RTO se acuerdan según criticidad. El buscador puede reconstruirse desde el repositorio; el contenido aprobado y su auditoría no deben depender únicamente del índice. Las copias sensibles se cifran y se prueban controles de acceso.

14.4. Continuidad editorial

Durante una indisponibilidad puede ser necesario publicar avisos urgentes. Conviene disponer de mecanismos alternativos controlados, plantillas de crisis y responsables. Estos mecanismos no deben convertirse en puertas traseras permanentes. La continuidad incluye dependencias externas como identidad, DNS, CDN, proveedores de mensajería y sistemas backend.

14.5. Gestión de incidentes

Los incidentes pueden ser técnicos, de seguridad, de datos o de contenido. Una guía sanitaria errónea es un incidente aunque la plataforma funcione. Deben existir procedimientos para despublicar, invalidar caché, comunicar, preservar evidencia y revisar causas. El postmortem debe producir acciones de sistema: validaciones, formación, segregación o automatización.

15. INICIATIVAS Y PORTALES EN EL SERVICIO ANDALUZ DE SALUD

Las iniciativas del SAS deben estudiarse por audiencia, finalidad y relación entre canales. Las funcionalidades cambian; por tanto, debes distinguir lo que consta en una fuente oficial actual de lo que apareció como situación concreta en un examen. La lista siguiente se formula con la información institucional disponible en agosto de 2026 y con preguntas oficiales no anuladas.

15.1. ClicSalud+ y App Salud Andalucía

ClicSalud+ proporciona a las personas atendidas en el SAS 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 y ofrece acceso rápido a los servicios de ClicSalud+, además de la tarjeta sanitaria virtual. Arquitectónicamente, ambos canales deben consumir capacidades comunes de agenda, información clínica, identidad y datos personales.

ClicSalud+ diferencia servicios que pueden utilizarse introduciendo datos personales de aquellos que, por su sensibilidad, exigen identificación segura. Entre los mecanismos admitidos en operaciones concretas figuran certificado digital, DNI electrónico y Cl@ve. No debe afirmarse que todas las funciones usan el mismo nivel de autenticación: el sistema aplica el requerido en cada caso.

La información institucional agrupa servicios en agenda sanitaria, salud, trámites y datos personales. El portal permite consultar citas y, con identificación segura, acceder a información más sensible. La documentación actual indica que ClicSalud+ y Salud Andalucía pueden mostrar datos relevantes de la historia clínica, aunque la disponibilidad depende de la integración de los sistemas fuente.

15.2. e-atención al profesional y mGerhonte

e-atención al profesional es un portal de servicios para profesionales del SAS cuyo contenido y funciones varían según el perfil. mGerhonte lleva al canal móvil determinadas capacidades relacionadas con la gestión profesional. Deben entenderse como canales complementarios sobre procesos de recursos humanos, no como repositorios aislados.

La lección arquitectónica es más importante que memorizar una pantalla: la omnicanalidad exige compartir identidad, reglas, datos y estado del proceso. No obliga a que todos los canales sean idénticos. Una operación sensible puede requerir un canal o factor reforzado, siempre que la diferencia sea deliberada y exista continuidad.

15.3. ayudaDIGITAL

ayudaDIGITAL es el servicio de Soporte Integral TIC para profesionales del SAS. La información oficial describe un ecosistema con portal y área personal, aplicación móvil, ayudaDIGITAL Escritorio, teléfono, correo corporativo, WhatsApp y chat. La app móvil permite registrar y seguir solicitudes y acceder a soluciones de autorresolución. El asistente AYDI se utiliza en distintos canales y puede derivar a una persona agente cuando no resuelve la necesidad.

El portal de aplicaciones de ayudaDIGITAL funciona además como catálogo y punto de descubrimiento de herramientas corporativas. Esta doble condición —soporte y catálogo— ilustra el tema: contenido, clasificación, búsqueda, autoservicio e integración con gestión de solicitudes.

15.4. Ventana Abierta a la Familia

Ventana Abierta a la Familia es una plataforma orientada a familias, con información y servicios relacionados con salud infantil, crianza, desarrollo y formación. El programa ha incorporado contenidos y recursos formativos sobre parentalidad positiva y corresponsabilidad. Es un ejemplo de portal segmentado por audiencia y de suscripción a contenidos preventivos.

15.5. Intranet, acceso remoto y otros espacios

La Intranet del SAS agrupa comunicación y accesos para profesionales. Los portales internos deben aplicar identidad corporativa, segmentación por perfil y gobierno de contenidos. El examen de promoción interna de 2025, pregunta 15, identificó SARAC como el portal destinado a facilitar acceso remoto de profesionales a aplicaciones corporativas desde fuera de la Red Corporativa de la Junta de Andalucía.

Otros espacios institucionales —transparencia, contratación, formación, bibliotecas, investigación o portales de centros— pueden utilizar tecnologías y propietarios diferentes. El objetivo de arquitectura corporativa no es forzar una única herramienta para todo, sino asegurar identidad visual, accesibilidad, metadatos, seguridad, integración, analítica y ciclo de vida comunes.

15.6. Principios de diseño aplicables al SAS

• Una fuente de verdad: datos clínicos y profesionales permanecen en sistemas responsables y se exponen mediante servicios.
• Identidad y representación: autenticación proporcional, roles y relaciones verificadas.
• Omnicanalidad: web, app y soporte comparten capacidades y estado.
• Contenido estructurado: reutilizable en ClicSalud+, apps, buscadores y asistentes.
• Accesibilidad y lenguaje claro: requisito transversal para ciudadanía y profesionales.
• Soporte integrado: ayudaDIGITAL como puerta de entrada para incidencias y conocimiento.
• Vigencia: responsables y fechas de revisión para contenidos sanitarios y administrativos.

16. CASO PRÁCTICO, TENDENCIAS Y SÍNTESIS PARA EXAMEN

16.1. Caso: renovación de un portal sanitario

Un área sanitaria dispone de un portal antiguo con miles de páginas, documentos duplicados, extensiones sin soporte y navegación basada en la estructura interna. Se desea renovarlo y reutilizar contenido en web y aplicación móvil. El error sería comenzar instalando un CMS nuevo. La primera fase es inventariar contenido, propietarios, audiencias, datos, integraciones, tráfico, obligaciones y riesgos.

Después se define la arquitectura de información y el modelo de contenido. Se decide qué se migra, actualiza, fusiona, archiva o elimina. Se diseñan workflows y taxonomías, y se prueba con contenidos reales. La selección de herramienta se realiza mediante criterios ponderados y prueba de concepto: accesibilidad, APIs, permisos, exportación, búsqueda, rendimiento, seguridad y coste total.

La migración incluye transformación de HTML, metadatos, documentos, redirecciones y validación. Se automatizan pruebas de enlaces, títulos, alternativas textuales y permisos. La salida se realiza por oleadas con monitorización, soporte y reversión. Finalmente se mide éxito por tareas completadas, búsquedas, vigencia, accesibilidad y reducción de incidencias, no por el simple hecho de «haber migrado».

16.2. Tendencias

Las tendencias relevantes son contenido componible, CMS headless o híbrido, arquitecturas API-first, búsqueda semántica, asistentes con recuperación, personalización responsable, automatización editorial, generación de variantes accesibles y observabilidad de la experiencia. También crece la necesidad de gobernar contenido producido con IA: procedencia, revisión humana, citas, caducidad y prohibición de publicar datos inventados.

La tendencia composable DXP propone ensamblar capacidades especializadas mediante APIs en lugar de adquirir una suite monolítica. Mejora flexibilidad, pero eleva el coste de integración y operación. La decisión debe atender a madurez, equipo y criticidad. En el sector público, la portabilidad y el cumplimiento pesan más que la novedad.

16.3. Mapa de memoria

                        PORTALES CORPORATIVOS
                                  │
        ┌─────────────────────────┼─────────────────────────┐
        │                         │                         │
    EVOLUCIÓN              ARQUITECTURA              GESTIÓN CONTENIDOS
        │                         │                         │
   ┌────┴────┐              ┌────┴────┐              ┌────┴────┐
   │         │              │         │              │         │
 Web 1.0   Web 2.0     5 CAPAS    CMS TIPOS      CATALOGACIÓN
   │         │              │         │              │
   │         │              │         │              │
Estático  Dinámico   Presentación  Traditional  Taxonomías
           │              │         │              │
           │              │         │              │
        Web 3.0      Aplicación   Headless    Metadatos
           │              │         │              │
           │              │         │              │
      Inteligente    Lógica      Hybrid      Folksonomías
           │              │         │
           │              │         │
        Web 4.0      Integración  EJEMPLOS
           │              │         │
           │              │         │
      Omnicanal       Datos   ┌────┴────┐
                                │         │
                           WordPress  Drupal
                                │         │
                            Liferay  SharePoint
                                      │
                                  Alfresco


                    INICIATIVAS EN EL SAS
                            │
        ┌───────────────────┼───────────────────┐
        │                   │                   │
    CIUDADANOS         PROFESIONALES      SOPORTE TIC
        │                   │                   │
   ClicSalud+         E-atención al        ayudaDIGITAL
        │              profesional              │
   • Cita previa           │               • Incidencias
   • Receta           • Nóminas           • Peticiones
   • Historia         • Vacaciones        • SPOC
   • Tarjeta          • Formación
        │                   │
        │             mGerhonte (App)
        │                   │
        │              • Notificaciones
        │              • Omnicanal
        │
   Ventana Abierta
    a la Familia


                   CONCEPTOS CLAVE
                         │
        ┌────────────────┼────────────────┐
        │                │                │
   PERSONALIZACIÓN  SUSCRIPCIÓN      SEGURIDAD
        │                │                │
   • Explícita      • RSS/Atom        • ENS
   • Implícita      • Newsletters     • RGPD
   • Basada en rol  • Push            • Autenticación
   • ML/IA          • Alertas         • HTTPS
                                       • SSO/SAML
        

16.5. Claves finales

16.6. Ideas Clave del Tema

16.7. Estrategia de Memorización

16.8. Aplicabilidad Práctica en el Puesto TFA-STI

Como TFA-STI, trabajarás con portales en:

• Soporte de segundo nivel: Incidencias de usuarios que no pueden acceder a ClicSalud+ → comprobar si es problema de certificado digital, de red, de integración con BDU
• Gestión de contenidos: Supervisar publicación de protocolos en intranet, asegurar que metadatos están bien, que los permisos son correctos
• Proyectos de mejora: Participar en ampliación de funcionalidades de E-atención al profesional, migración de CMS obsoletos
• Seguridad: Auditar accesos a portales, revisar logs ante incidentes, configurar políticas de autenticación

16.9. Conexiones con Otros Temas del Temario

• Tema 77 – Esquema Nacional de Seguridad: Los portales deben cumplir ENS (MEDIO o ALTO según datos que traten)
• Tema 78 – RGPD: Gestión de consentimientos, perfilado, derechos de los interesados en portales
• Tema 84 – Servicios de Internet: HTTPS, DNS, correo electrónico usados en portales
• Tema 91 – ayudaDIGITAL: Centro de servicios integrado con portales
• Tema 92 – Puesto de trabajo: Acceso a portales desde equipos corporativos, VPN
• Tema 94 – Trabajo colaborativo: Herramientas como Confluence vs gestores documentales vs portales corporativos