📚 TEMA 19
🎯 ¿Por qué este tema es fundamental para tu oposición?
Mira, este tema es de esos que te van a caer seguro en el examen. Y no es casualidad: en el SAS, cada día trabajas con aplicaciones web que sostienen la asistencia sanitaria de toda Andalucía. Estamos hablando de Diraya, el portal de profesionales, ClicSalud+, las aplicaciones móviles para pacientes… Todo eso funciona gracias a las tecnologías que vamos a ver aquí.
He revisado los exámenes de los últimos años y las preguntas sobre HTML, HTTP, JavaScript, frameworks como Angular o Vue.js, REST APIs, accesibilidad web y XML son recurrentes. Así que presta mucha atención porque este tema te puede dar varios puntos en el examen.
Además, y esto es importante, cuando entres a trabajar en el SAS vas a necesitar entender cómo funcionan estas aplicaciones web para poder dar soporte técnico, participar en proyectos de desarrollo o migración, y colaborar con los equipos de desarrollo. No se trata solo de aprobar, sino de estar realmente preparado para el puesto.
1. Introducción y Contextualización
Internet ha transformado radicalmente la forma en que los sistemas de información sanitaria operan y entregan servicios. En el Servicio Andaluz de Salud, la gran mayoría de aplicaciones corporativas funcionan sobre arquitecturas web: desde la Historia Digital de Salud (Diraya) hasta los sistemas de gestión de recursos humanos (Gerhonte), pasando por las aplicaciones móviles que utilizan los profesionales sanitarios en su día a día.
Cuando hablamos de arquitecturas, lenguajes y herramientas para Internet, no estamos hablando de teoría abstracta. Estamos hablando de las tecnologías concretas que permiten que un médico en urgencias del Hospital Virgen del Rocío consulte en tiempo real la historia clínica de un paciente, que una enfermera en un centro de salud de Almería registre las constantes vitales en una tablet, o que un paciente pueda pedir cita online desde su móvil a las tres de la madrugada.
1.1. Marco Normativo y Estratégico del SAS
El desarrollo de aplicaciones web en el SAS no es una actividad libre. Está regulado por un conjunto de normativas y estándares que debemos conocer. La Ley 39/2015 de Procedimiento Administrativo Común establece el marco de la administración electrónica, mientras que el Real Decreto 311/2022 actualiza el Esquema Nacional de Seguridad, que es de obligado cumplimiento en todos los sistemas del SAS.
En cuanto a accesibilidad web, el Real Decreto 1112/2018 sobre accesibilidad de los sitios web y aplicaciones para dispositivos móviles del sector público nos obliga a cumplir con las WCAG 2.1 nivel AA. Esto significa que todas las aplicaciones web del SAS deben ser utilizables por personas con discapacidad visual, auditiva, motora o cognitiva.
2. HTML: El Lenguaje de Marcado de Hipertexto
2.1. Evolución de HTML: De HTML 4 a HTML5
HTML (HyperText Markup Language) es el lenguaje fundamental para estructurar contenido en la web. Aunque muchos lo dan por sentado, entender su evolución es crucial porque en el SAS conviven aplicaciones legacy desarrolladas con versiones antiguas de HTML junto con desarrollos modernos en HTML5.
HTML 4.01, publicado en 1999, fue durante años el estándar de facto. Sin embargo, con la llegada de HTML5 en 2014 (y su evolución continua como HTML Living Standard), el panorama cambió radicalmente. HTML5 introdujo elementos semánticos que mejoran la estructura del documento y la accesibilidad, soporte nativo para multimedia sin plugins, APIs JavaScript potentes, y capacidades offline.
2.2. Características Clave de HTML5 Aplicadas al SAS
En el contexto sanitario, HTML5 aporta funcionalidades críticas. El elemento <canvas> permite renderizar gráficos dinámicos, algo que se utiliza en las aplicaciones de visualización de curvas de constantes vitales en Diraya. Los elementos <audio> y <video> permiten integrar contenido multimedia sin necesidad de Flash, tecnología obsoleta y con problemas de seguridad.
La API de Geolocalización de HTML5 se utiliza en aplicaciones móviles del SAS para servicios de emergencias, permitiendo localizar al profesional sanitario o al paciente. Los Web Workers permiten ejecutar JavaScript en segundo plano sin bloquear la interfaz, algo crucial en aplicaciones complejas como el sistema de alertas de medicación de Diraya.
2.3. Atributos Esenciales en HTML
Los atributos HTML son fundamentales para el correcto funcionamiento de las aplicaciones web. En exámenes anteriores ha caído la pregunta sobre qué atributo se utiliza en un elemento <a> para indicar el destino del enlace. La respuesta correcta es href (hypertext reference), no confundir con «link», «target» o «src».
El atributo «target» en los enlaces controla cómo se abre el destino. Por ejemplo, target=»_blank» abre el enlace en una nueva pestaña, algo que debe usarse con precaución por razones de seguridad y accesibilidad. El atributo «aria-label» proporciona etiquetas descriptivas para lectores de pantalla, siendo obligatorio en muchos contextos por las WCAG.
3. El Protocolo HTTP: Fundamento de la Web
3.1. HTTP/1.1: El Estándar Consolidado
El Protocolo de Transferencia de Hipertexto (HTTP) es el protocolo de comunicación que permite la transferencia de información en la World Wide Web. HTTP/1.1, definido en el RFC 2616 y actualizado por el RFC 7230-7235, ha sido durante décadas el estándar predominante.
HTTP funciona bajo un modelo cliente-servidor sin estado (stateless), donde cada petición es independiente. El cliente (típicamente un navegador web) envía una petición HTTP al servidor, que procesa la solicitud y devuelve una respuesta. Este modelo simple pero efectivo ha permitido la escalabilidad masiva de Internet.
3.2. Códigos de Estado HTTP
Los códigos de estado HTTP informan al cliente sobre el resultado de la petición. Se organizan en cinco familias. Los códigos 1xx son informativos y raramente se usan. Los 2xx indican éxito: 200 OK es el más común, 201 Created se usa cuando se crea un recurso nuevo, 204 No Content indica éxito sin cuerpo de respuesta.
Los códigos 3xx indican redirecciones: 301 Moved Permanently es permanente, 302 Found es temporal. Los 4xx son errores del cliente: 400 Bad Request indica una petición malformada, 401 Unauthorized requiere autenticación, 403 Forbidden indica que el servidor entiende la petición pero la rechaza, 404 Not Found es el famoso «página no encontrada». Los 5xx son errores del servidor: 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable.
3.3. HTTP/2 y HTTP/3: La Evolución del Protocolo
HTTP/2, publicado en 2015, introdujo mejoras significativas de rendimiento. La multiplexación permite enviar múltiples peticiones simultáneas sobre una única conexión TCP, eliminando el problema de «head-of-line blocking» de HTTP/1.1. La compresión de cabeceras con HPACK reduce el overhead, y el server push permite al servidor enviar recursos antes de que el cliente los solicite.
HTTP/3, basado en el protocolo QUIC sobre UDP en lugar de TCP, representa la última evolución. Reduce la latencia en el establecimiento de conexiones, mejora el rendimiento en redes con pérdida de paquetes, y es especialmente beneficioso en aplicaciones móviles del SAS donde la conectividad puede ser variable.
4. XML: El Lenguaje Extensible de Marcado
4.1. Fundamentos de XML
XML (eXtensible Markup Language) es un metalenguaje que permite definir lenguajes de marcado específicos para representar información estructurada. A diferencia de HTML, que tiene un conjunto fijo de etiquetas, XML permite crear tus propias etiquetas según las necesidades del dominio.
En los exámenes ha caído la pregunta sobre qué afirmación acerca de XML es falsa. La respuesta correcta es que «XML no permite anidaciones» es FALSA, porque XML sí permite anidar elementos jerárquicamente, siendo esta una de sus características fundamentales.
4.2. XML en el Contexto Sanitario del SAS
En el ámbito sanitario, XML es omnipresente. El estándar HL7 v3 utiliza XML para representar mensajes clínicos. El CDA (Clinical Document Architecture) es un estándar basado en XML para documentos clínicos estructurados, utilizado en el intercambio de informes médicos entre hospitales del SAS y con otras comunidades autónomas.
DICOM (Digital Imaging and Communications in Medicine) puede usar XML para metadatos de imágenes médicas. Los servicios web SOAP, aunque cada vez menos comunes frente a REST, utilizan XML para los mensajes. Muchas configuraciones de sistemas del SAS (como servidores de aplicaciones) se definen en archivos XML.
4.3. XML vs JSON en Aplicaciones Modernas
Aunque XML sigue siendo relevante, especialmente en interoperabilidad sanitaria, JSON (JavaScript Object Notation) ha ganado terreno en aplicaciones web modernas por ser más ligero y legible. Sin embargo, XML ofrece ventajas como validación mediante DTD o XML Schema, soporte robusto de namespaces, y potentes capacidades de transformación con XSLT.
5. Desarrollo de Aplicaciones Web en el Cliente
5.1. JavaScript: El Lenguaje de la Web
JavaScript es el lenguaje de programación interpretado que se ejecuta en el navegador del cliente, permitiendo crear interfaces interactivas y dinámicas. Creado originalmente por Brendan Eich en 1995 para Netscape Navigator, ha evolucionado hasta convertirse en el lenguaje más utilizado en desarrollo web.
En los exámenes ha caído identificar código JavaScript. Es importante reconocer la sintaxis característica: la palabra clave «var» (o «let»/»const» en versiones modernas), las funciones definidas con «function», el uso de closures (funciones que retornan funciones), y la manipulación del DOM.
5.2. Frameworks y Librerías JavaScript Modernas
Los frameworks JavaScript modernos han revolucionado el desarrollo web. Angular, desarrollado por Google, es un framework completo basado en TypeScript ideal para aplicaciones empresariales complejas. El SAS lo utiliza en varios proyectos por su robustez y escalabilidad.
Vue.js es un framework progresivo más ligero y flexible, excelente para SPA (Single Page Applications). React, de Facebook, es una librería centrada en componentes UI reutilizables. Estos tres dominan el panorama actual del desarrollo front-end.
5.3. AJAX: Comunicación Asíncrona
AJAX (Asynchronous JavaScript And XML) no es una tecnología en sí misma, sino un conjunto de técnicas para crear aplicaciones web interactivas. Permite realizar peticiones HTTP al servidor en segundo plano, sin recargar toda la página, actualizando solo las partes necesarias de la interfaz.
Aunque el nombre incluye «XML», hoy en día AJAX típicamente usa JSON para intercambiar datos por ser más ligero. La API fetch() moderna ha reemplazado en gran medida a XMLHttpRequest. En Diraya, AJAX se utiliza constantemente para consultar datos del paciente, registrar constantes vitales, o validar información sin recargar la página completa.
6. Desarrollo de Aplicaciones Web en el Servidor
6.1. Tecnologías de Back-End
El desarrollo del lado del servidor (back-end) se encarga de la lógica de negocio, acceso a bases de datos, autenticación, autorización, y procesamiento de datos. A diferencia del front-end que se ejecuta en el navegador, el back-end se ejecuta en servidores controlados por el SAS.
PHP sigue siendo ampliamente utilizado en el SAS, especialmente en sistemas legacy. Es un lenguaje de scripting del lado del servidor diseñado específicamente para desarrollo web. Python con frameworks como Django o Flask es cada vez más popular por su legibilidad y potencia. Node.js permite usar JavaScript en el servidor, unificando el lenguaje en front-end y back-end.
6.2. Arquitecturas de Servicios Web
Las aplicaciones web modernas del SAS suelen seguir arquitecturas basadas en servicios. REST (Representational State Transfer) es el estilo arquitectónico dominante, utilizando HTTP como protocolo de comunicación y típicamente JSON como formato de intercambio de datos.
Una API RESTful en el SAS podría exponer endpoints como GET /api/pacientes/{nhc} para obtener datos de un paciente, POST /api/citas para crear una nueva cita, PUT /api/recetas/{id} para actualizar una receta completa, o DELETE /api/alertas/{id} para eliminar una alerta médica.
6.3. Microservicios vs Arquitectura Monolítica
Las arquitecturas monolíticas tradicionales tienen toda la aplicación en una única base de código desplegada como un bloque. Diraya original era así: una gran aplicación J2EE. Los microservicios dividen la aplicación en servicios pequeños e independientes que se comunican mediante APIs, permitiendo escalar y actualizar componentes de forma independiente.
El SAS está evolucionando hacia microservicios en nuevos desarrollos, combinados con arquitecturas basadas en eventos (EDA – Event-Driven Architecture) para mejor escalabilidad y agilidad. Esta combinación apareció en exámenes recientes como la arquitectura más adecuada para sistemas multicanal con grandes volúmenes de usuarios.
7. Componentes Distribuidos y Arquitecturas Web
7.1. Single Page Applications (SPA)
Las Single Page Applications cargan una única página HTML y actualizan dinámicamente el contenido sin recargas completas. Frameworks como Angular, Vue.js y React están diseñados específicamente para crear SPAs eficientes y mantenibles.
En el SAS, muchas aplicaciones modernas son SPAs porque ofrecen mejor experiencia de usuario, menor consumo de ancho de banda tras la carga inicial, y permiten funcionalidad offline mediante service workers. El portal de profesionales del SAS utiliza técnicas SPA para agilizar la navegación.
7.2. Progressive Web Apps (PWA)
Las Progressive Web Apps son aplicaciones web que utilizan capacidades modernas para ofrecer experiencia similar a aplicaciones nativas. Características incluyen funcionamiento offline mediante service workers, instalación en el dispositivo, notificaciones push, y acceso a APIs del dispositivo como cámara o geolocalización.
En el SAS, las PWAs son especialmente valiosas para aplicaciones móviles de profesionales sanitarios que necesitan funcionar en zonas con conectividad limitada, como en urgencias extrahospitalarias o zonas rurales de Andalucía.
8. Gestión y Publicación de Contenidos Web
8.1. Sistemas de Gestión de Contenidos (CMS)
Los CMS (Content Management Systems) permiten crear, gestionar y publicar contenido web sin necesidad de conocimientos técnicos profundos. WordPress, Drupal y Joomla son los CMS más populares. En el SAS, muchos sitios informativos y portales de comunicación utilizan CMS para facilitar la actualización de contenidos por personal no técnico.
Un CMS corporativo debe cumplir con requisitos específicos del SAS: integración con sistemas de autenticación corporativos (IDENTIC), cumplimiento ENS, accesibilidad WCAG 2.1 AA, y capacidad de auditoría de cambios para trazabilidad según RGPD.
8.2. Edición y Personalización de Contenidos
Las herramientas modernas de edición web permiten personalización dinámica de contenidos según el perfil del usuario. En el portal de profesionales del SAS, un médico de atención primaria ve contenidos diferentes a los de un cirujano de hospital terciario, gracias a sistemas de gestión de contenidos personalizados.
9. Accesibilidad Web y Estándares W3C
9.1. WCAG: Pautas de Accesibilidad para el Contenido Web
Las WCAG (Web Content Accessibility Guidelines) del W3C son el estándar internacional para accesibilidad web. La versión actual es WCAG 2.1, con nivel de conformidad AA obligatorio para sector público según RD 1112/2018.
Las WCAG se basan en cuatro principios fundamentales, formando el acrónimo POUR. Perceptible significa que la información debe ser presentada de forma que los usuarios puedan percibirla (textos alternativos para imágenes, subtítulos para vídeos). Operable implica que los componentes de interfaz y navegación deben ser operables (navegable por teclado, tiempo suficiente para leer). Comprensible significa que la información y operación de la interfaz deben ser comprensibles (contenido legible, predecible). Robusto indica que el contenido debe ser suficientemente robusto para ser interpretado de forma fiable por variedad de agentes de usuario, incluyendo tecnologías asistivas.
9.2. WAI-ARIA: Aplicaciones de Internet Ricas y Accesibles
WAI-ARIA (Web Accessibility Initiative – Accessible Rich Internet Applications) es un conjunto de atributos que hacen el contenido y aplicaciones web más accesibles para personas con discapacidad. ARIA es especialmente importante en aplicaciones dinámicas donde el contenido cambia sin recargar la página.
Atributos ARIA comunes incluyen role (define el tipo de elemento), aria-label (proporciona etiqueta accesible), aria-describedby (referencia descripción), aria-live (indica regiones que se actualizan dinámicamente), y aria-hidden (oculta contenido decorativo de lectores de pantalla).
9.3. Cumplimiento de Accesibilidad en el SAS
Todas las aplicaciones web del SAS deben someterse a auditorías de accesibilidad antes de su puesta en producción. Las herramientas de validación como WAVE, aXe, o Lighthouse ayudan a identificar problemas, pero la validación manual con lectores de pantalla (NVDA, JAWS) y navegación solo teclado es imprescindible.
10. Web Semántica y Futuro de la Web
10.1. Conceptos de Web Semántica
La Web Semántica es una extensión de la web actual donde la información tiene significado bien definido, permitiendo que computadoras y personas trabajen en cooperación. Tim Berners-Lee propuso esta visión para que las máquinas puedan entender e interpretar los datos web.
Tecnologías de Web Semántica incluyen RDF (Resource Description Framework) para describir recursos, OWL (Web Ontology Language) para definir ontologías complejas, y SPARQL como lenguaje de consulta. En sanidad, estas tecnologías son fundamentales para interoperabilidad semántica entre sistemas.
10.2. Aplicaciones en el Ámbito Sanitario
Los estándares de terminología clínica como SNOMED CT utilizan principios de web semántica para representar conceptos médicos de forma computacionalmente procesable. Esto permite que sistemas como Diraya puedan razonar sobre diagnósticos, detectar interacciones medicamentosas, o sugerir tratamientos basados en guías clínicas.
📋 Caso Práctico: Modernización de Aplicación Web en el SAS
Escenario: El Hospital Universitario Virgen de las Nieves necesita modernizar su aplicación web interna de gestión de quirófanos, actualmente desarrollada en HTML 4 con PHP 5 y arquitectura monolítica. La aplicación presenta problemas de rendimiento, no es accesible, y no funciona correctamente en dispositivos móviles.
Requerimientos:
1. Cumplimiento WCAG 2.1 nivel AA para accesibilidad
2. Arquitectura que permita escalabilidad horizontal
3. Funcionamiento en tablets para uso en quirófano
4. Integración con Diraya mediante API REST
5. Capacidad offline para zonas sin conectividad
6. Cumplimiento ENS nivel MEDIO
Solución Propuesta:
Migración a arquitectura de microservicios con los siguientes componentes. Front-end desarrollado como Progressive Web App (PWA) con Angular, aprovechando service workers para funcionalidad offline y diseño responsive para tablets. Back-end basado en microservicios con Node.js, exponiendo API RESTful con autenticación OAuth 2.0 y JWT. Base de datos distribuida con PostgreSQL en configuración de alta disponibilidad. Integración con Diraya mediante consumo de APIs REST existentes, utilizando circuit breakers para resiliencia.
Implementación de Accesibilidad: Uso de elementos semánticos HTML5, implementación completa de WAI-ARIA para componentes dinámicos, contraste de colores WCAG AAA, navegación completa por teclado, y textos alternativos para todas las imágenes.
Resultados Esperados: Mejora del 60% en tiempo de carga, reducción del 80% en incidencias de accesibilidad, disponibilidad 99.9% mediante arquitectura distribuida, y experiencia de usuario consistente en todos los dispositivos.
11. Tendencias y Tecnologías Emergentes
11.1. WebAssembly
WebAssembly (WASM) es un formato de código binario portable que se ejecuta en navegadores con rendimiento cercano al nativo. Permite ejecutar código compilado desde C, C++, Rust u otros lenguajes directamente en el navegador, abriendo nuevas posibilidades para aplicaciones web de alto rendimiento.
11.2. WebRTC para Telemedicina
WebRTC (Web Real-Time Communication) permite comunicación de audio, vídeo y datos en tiempo real directamente entre navegadores sin plugins. En el SAS, WebRTC es fundamental para consultas de telemedicina, permitiendo videoconsultas seguras entre profesionales sanitarios y pacientes sin necesidad de instalar software adicional.
11.3. Contenedores y Orquestación
Kubernetes (K8s) es la plataforma líder para orquestación de contenedores, permitiendo desplegar, escalar y gestionar aplicaciones containerizadas de forma automatizada. En exámenes recientes apareció como la opción correcta para «plataforma de contenedores administrada en la nube con escalado automático».
12. Cuestionario de Autoevaluación
Ahora viene la parte importante. He preparado 30 preguntas tipo test basadas en contenidos reales de exámenes anteriores. No te las tomes a la ligera: estas preguntas reflejan el nivel real que te vas a encontrar. Léelas con calma, razona cada opción, y revisa las explicaciones aunque aciertes.
HTML significa HyperText Markup Language (Lenguaje de Marcado de Hipertexto). Las otras opciones son anagramas incorrectos comúnmente confundidos. Esta pregunta evalúa conocimiento básico pero fundamental, ya que HTML es la base de toda aplicación web del SAS.
El atributo «href» (hypertext reference) especifica la URL de destino del enlace. «target» controla cómo se abre el enlace (nueva pestaña, misma ventana), «src» se usa en imágenes y scripts, y «link» no es un atributo válido en <a>. Pregunta aparecida textualmente en examen de promoción interna.
La afirmación falsa es que XML no permite anidaciones, cuando en realidad sí las permite y es una de sus características fundamentales. XML sí es un metalenguaje, es texto plano, y es case-sensitive (sensible a mayúsculas y minúsculas). Pregunta real del examen SAS 2019.
JavaScript es el lenguaje estándar para manipular el DOM en navegadores. Python, Ruby y Perl se usan principalmente en servidor. Esta distinción cliente/servidor es crucial y aparece frecuentemente en exámenes.
PUT actualiza completamente un recurso existente (reemplazo total). PATCH se usa para actualizaciones parciales. POST crea nuevos recursos. MODIFY y UPDATE no son métodos HTTP estándar. Esta pregunta apareció en examen técnico medio 2025.
Angular es framework front-end basado en TypeScript. ASP.NET (Microsoft), Django (Python) y Spring (Java) son frameworks back-end. Diferenciar front-end de back-end es fundamental y se pregunta constantemente.
Vue.js es framework JavaScript ideal para SPAs por su flexibilidad y rendimiento. Django (Python) y Laravel (PHP) son back-end. Express.js es framework de servidor Node.js. También serían correctas Angular o React si aparecieran.
PHP es lenguaje de programación backend ampliamente usado en el SAS. XML es formato de datos, CSS es para estilos, HTML es para estructura. Ninguno de estos tres se usa para lógica de servidor.
«Robusto» es uno de los 4 principios WCAG (POUR: Perceptible, Operable, Comprensible, Robusto). El contenido robusto puede ser interpretado por amplia variedad de agentes de usuario, incluyendo tecnologías asistivas. «Operable» es principio WCAG pero se refiere a navegabilidad, no a compatibilidad tecnológica.
WAI-ARIA (Web Accessibility Initiative – Accessible Rich Internet Applications) es el conjunto de estándares para accesibilidad en aplicaciones web dinámicas. SVG es para gráficos vectoriales, CMS son gestores de contenido.
WAI (Web Accessibility Initiative) es la iniciativa del W3C para accesibilidad web. OWL, RDF y SPARQL son tecnologías de web semántica, no de accesibilidad.
Python es lenguaje de programación back-end ideal para APIs con frameworks como Django REST o FastAPI. HTML estructura páginas, CSS las estiliza, WordPress es CMS. Solo Python puede desarrollar lógica de servidor y acceso a bases de datos.
Este código JavaScript muestra un closure (función que retorna función), característica avanzada de JavaScript. La palabra clave «var» y la sintaxis de funciones son típicas de JavaScript. C, C++ y Pascal tienen sintaxis diferentes.
.NET Core/.NET 5+ es código abierto, multiplataforma (Windows/Linux/macOS) y admite múltiples lenguajes (C#, F#, VB.NET). NO es de pago por uso; es gratuito. Confundir con modelos de cloud computing que sí tienen pago por uso.
Accesibilidad web significa flexibilidad para adaptarse a necesidades y limitaciones de usuarios (visuales, auditivas, motoras, cognitivas). Aunque existen requisitos legales, la definición fundamental es la adaptación a necesidades diversas.
Microservicios + EDA (Event-Driven Architecture) ofrece máxima agilidad y escalabilidad permitiendo desarrollo, despliegue y escalado independiente de componentes. Arquitecturas monolíticas y cliente-servidor tradicional son menos escalables.
Kubernetes es la plataforma líder de orquestación de contenedores con capacidades de escalado automático horizontal (HPA) y vertical (VPA). AWS RDS es para bases de datos, Azure DevOps y GitLab CI/CD son para integración continua.
HTTP/2 introdujo multiplexación (múltiples peticiones simultáneas sobre única conexión TCP) y compresión de cabeceras con HPACK. HTTP/1.1 tiene conexiones persistentes pero no multiplexación. HTTP/3 usa QUIC sobre UDP.
POST se usa para crear nuevos recursos en REST. GET recupera, PUT actualiza completamente, DELETE elimina. Aunque PUT también puede crear si conoces el ID exacto, POST es el método estándar para creación.
404 Not Found indica que el recurso solicitado no existe en el servidor. 400 es petición malformada, 401 falta autenticación, 403 es prohibido (existe pero no tienes permisos).
<div> existe desde HTML 4 como contenedor genérico sin significado semántico. <header>, <nav> y <article> son elementos semánticos nuevos de HTML5 que mejoran la estructura y accesibilidad.
WebRTC (Web Real-Time Communication) permite comunicación peer-to-peer de audio, vídeo y datos sin plugins, fundamental para telemedicina en el SAS. WebSocket es bidireccional pero no específico para multimedia.
aria-live define regiones que se actualizan dinámicamente (live regions), informando a lectores de pantalla sobre cambios en contenido sin recargar. Valores: off, polite, assertive. Fundamental en SPAs y aplicaciones dinámicas del SAS.
PWAs (Progressive Web Apps) utilizan service workers para cachear recursos y permitir funcionamiento offline, notificaciones push e instalación en dispositivo. Ideal para aplicaciones médicas en zonas con conectividad limitada.
JSON (JavaScript Object Notation) es el formato preferido en APIs REST modernas por ser más ligero que XML, directamente parseable por JavaScript, y más legible. Aunque XML sigue usándose en HL7 y otros estándares sanitarios legacy.
«Operable» es el principio WCAG que exige que todos los componentes sean navegables por teclado, permitiendo a usuarios con movilidad reducida usar aplicaciones web del SAS sin ratón.
<article> representa contenido independiente y autónomo que podría distribuirse o reutilizarse separadamente (entrada blog, noticia, comentario). <section> agrupa contenido temático, <aside> es contenido tangencial.
PUT es idempotente: actualizar un recurso múltiples veces con mismos datos produce mismo resultado. POST NO es idempotente: crear un recurso múltiples veces crea múltiples recursos. GET, DELETE también son idempotentes.
El RD 1112/2018 sobre accesibilidad exige nivel AA de WCAG 2.1 para sitios web y apps móviles del sector público español, incluyendo todas las aplicaciones del SAS. Nivel AAA es recomendable pero no obligatorio.
Los frameworks SPA (Angular, Vue) tienen DESVENTAJA en SEO porque el contenido se genera dinámicamente en cliente, dificultando indexación por motores de búsqueda. Aunque existen soluciones (SSR, pre-rendering), el SEO no es una ventaja inherente. Para aplicaciones internas del SAS esto no es crítico.
13. Mapa Conceptual del Tema
14. Casos Prácticos Aplicados al SAS
📋 Caso Práctico 1: Implementación de API REST para Integración de Diraya
Contexto: El Hospital Regional de Málaga necesita integrar su nuevo sistema de laboratorio con Diraya para que los resultados analíticos se incorporen automáticamente a la historia digital del paciente.
Requerimientos Técnicos:
• API REST segura con autenticación OAuth 2.0
• Formato de intercambio JSON según estándar FHIR
• Cumplimiento ENS nivel MEDIO
• Registro de auditoría completo (RGPD)
• Disponibilidad 99.9% (SLA crítico)
• Tiempo de respuesta < 2 segundos
Diseño de la Solución:
Endpoints diseñados siguiendo principios REST:
POST /api/v1/resultados-laboratorio – Crear nuevo resultado
GET /api/v1/pacientes/{nhc}/resultados – Consultar resultados de paciente
PUT /api/v1/resultados/{id}/validar – Validar resultado médicamente
PATCH /api/v1/resultados/{id}/observaciones – Añadir observaciones
Aspectos de Seguridad: Autenticación mediante OAuth 2.0 con tokens JWT de corta duración, cifrado TLS 1.3 obligatorio, validación de entrada contra inyección SQL y XSS, rate limiting para prevenir ataques DDoS, y logs de auditoría inmutables cumpliendo RGPD.
Manejo de Errores: Códigos HTTP apropiados (200 OK, 201 Created, 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 500 Internal Server Error), mensajes de error descriptivos sin exponer información sensible, y mecanismo de retry con exponential backoff para fallos transitorios.
📋 Caso Práctico 2: Migración de Aplicación Legacy a HTML5 y Angular
Situación Inicial: Aplicación de gestión de consultas externas desarrollada en 2010 con HTML 4, JavaScript sin frameworks, arquitectura síncrona con recargas completas de página, no accesible (incumple WCAG), y sin soporte para móviles.
Problemas Identificados: Incumplimiento RD 1112/2018 de accesibilidad, experiencia de usuario deficiente con tiempos de espera largos, no funciona en tablets que usan enfermeras en consultorios, mantenimiento complejo por código espagueti, y imposibilidad de añadir nuevas funcionalidades sin refactorización completa.
Solución de Modernización:
Front-end reconstruido como SPA con Angular 15, implementando diseño responsive Mobile First con Bootstrap 5, cumplimiento WCAG 2.1 AA mediante WAI-ARIA completo, y Progressive Web App (PWA) con funcionalidad offline.
Back-end migrado a arquitectura de microservicios con Node.js/Express, API RESTful siguiendo especificación OpenAPI 3.0, autenticación integrada con IDENTIC corporativo vía SAML 2.0, y base de datos PostgreSQL con replicación para alta disponibilidad.
Resultados Medibles: Reducción del 70% en tiempo de carga inicial, mejora del 90% en puntuación Lighthouse Accessibility, incremento del 40% en productividad de profesionales sanitarios, y cero incidencias de accesibilidad en auditoría externa.
15. Conclusiones y Recomendaciones de Estudio
Llegamos al final de este tema denso pero fundamental. Si has leído hasta aquí con atención, ya tienes una base sólida sobre arquitecturas web, lenguajes y herramientas para Internet. Pero la clave ahora está en cómo estudies este material para el examen.
Ideas Clave que Debes Dominar
Primero, la diferencia entre front-end y back-end es absolutamente crítica. Cada vez que veas una pregunta sobre frameworks o lenguajes, pregúntate: ¿esto se ejecuta en el navegador del cliente o en el servidor? Angular, Vue.js, React son front-end. PHP, Django, Spring son back-end. JavaScript puede ser ambos (navegador y Node.js en servidor).
Segundo, los métodos HTTP en REST no son opcionales. GET recupera, POST crea, PUT actualiza completamente, PATCH actualiza parcialmente, DELETE elimina. Y esto no es teoría abstracta: las APIs de Diraya funcionan exactamente así. Cuando un médico consulta una historia clínica, se hace GET. Cuando registra constantes vitales, se hace POST. Cuando actualiza una alergia, se hace PUT o PATCH.
Tercero, accesibilidad web no es un «nice to have», es obligatorio por ley. Los cuatro principios WCAG (Perceptible, Operable, Comprensible, Robusto) y WAI-ARIA para contenido dinámico son pregunta casi segura en el examen. Y cuando estés trabajando en el SAS, garantizar que las aplicaciones sean accesibles no será solo cumplir normativa, será permitir que profesionales y pacientes con discapacidad puedan usar los sistemas.
Estrategia de Estudio Recomendada
No intentes memorizar este tema de una sentada. Divide el estudio en bloques: dedica un día a HTML/HTTP, otro a JavaScript y frameworks front-end, otro a desarrollo servidor y APIs REST, y otro específicamente a accesibilidad y WCAG. Después, un día completo para hacer y revisar las 30 preguntas del cuestionario.
Haz esquemas propios. El mapa conceptual que te he proporcionado es un punto de partida, pero funciona mejor si creas el tuyo. Dibuja en papel la arquitectura de una aplicación web del SAS: navegador con HTML/CSS/JavaScript → HTTP → servidor con PHP/Python/Node.js → base de datos. Visualiza el flujo de datos.
Practica con ejemplos reales. Abre la consola de desarrollador (F12) en Diraya o cualquier aplicación del SAS. Observa las peticiones HTTP en la pestaña Network. Mira los códigos de estado. Inspecciona el HTML y busca elementos semánticos HTML5. Revisa si usan atributos ARIA. Esta práctica real refuerza muchísimo el estudio teórico.
Conecta con Otros Temas
Este tema se relaciona directamente con otros del temario. El Tema 35 sobre seguridad de las TIC complementa lo que has visto aquí sobre HTTPS, OAuth, JWT. El Tema 36 sobre Esquema Nacional de Seguridad es crucial para entender cómo implementar controles de seguridad en aplicaciones web. El Tema 39 sobre administración electrónica contextualiza el marco normativo de estas tecnologías.
Si estudias desarrollo ágil (Tema 15), verás cómo frameworks como Angular o Vue.js facilitan metodologías como Scrum mediante componentes reutilizables y despliegue continuo. Si estudias bases de datos (Temas 33-34), entenderás mejor cómo las APIs REST actúan como capa intermedia entre front-end y base de datos.
Última Reflexión
Las tecnologías web evolucionan rápidamente, pero los fundamentos que has estudiado aquí son relativamente estables. HTTP, HTML, los principios REST, los estándares de accesibilidad… llevan años siendo la base de Internet y seguirán siéndolo. Lo que cambia son los frameworks específicos (hoy Angular, mañana otro), pero los conceptos subyacentes permanecen.
Cuando estés en el examen y veas una pregunta sobre arquitecturas web, respira hondo, lee con calma, descarta las opciones obviamente incorrectas, y razona desde los fundamentos. ¿Es front-end o back-end? ¿Es para crear, leer, actualizar o borrar? ¿Cumple con accesibilidad? Con esa base, acertarás.
Mucho ánimo en tu preparación. Este tema puede parecer abrumador por la cantidad de tecnologías, pero es uno de los más prácticos y aplicables a tu futuro trabajo en el SAS. Cada concepto que estudias aquí lo usarás casi a diario cuando estés dando soporte a aplicaciones web sanitarias, colaborando en proyectos de desarrollo, o resolviendo incidencias en Diraya.
¡Tú puedes con esto y con toda la oposición!
16. Referencias Normativas y Bibliográficas
Normativa Aplicable:
- Ley 39/2015, de 1 de octubre, del Procedimiento Administrativo Común de las Administraciones Públicas. Marco legal de administración electrónica.
- Real Decreto 311/2022, de 3 de mayo, por el que se regula el Esquema Nacional de Seguridad. Actualización del ENS con requisitos de seguridad para sistemas de información.
- Real Decreto 1112/2018, de 7 de septiembre, sobre accesibilidad de los sitios web y aplicaciones para dispositivos móviles del sector público. Obliga cumplimiento WCAG 2.1 nivel AA.
- Reglamento (UE) 2016/679 (RGPD) y Ley Orgánica 3/2018 (LOPDGDD). Protección de datos personales, especialmente relevante para datos de salud.
- Real Decreto 4/2010, de 8 de enero, por el que se regula el Esquema Nacional de Interoperabilidad. Marco técnico y organizativo para interoperabilidad de sistemas.
Estándares y Especificaciones Técnicas:
- W3C HTML Living Standard. Especificación actual de HTML mantenida por WHATWG. URL: https://html.spec.whatwg.org/
- RFC 9110 – HTTP Semantics. Especificación actualizada de HTTP/1.1 (junio 2022).
- RFC 9113 – HTTP/2 y RFC 9114 – HTTP/3. Versiones modernas del protocolo HTTP.
- W3C Web Content Accessibility Guidelines (WCAG) 2.1. Pautas de accesibilidad web nivel A, AA, AAA. URL: https://www.w3.org/TR/WCAG21/
- W3C WAI-ARIA 1.2. Especificación de Accessible Rich Internet Applications. URL: https://www.w3.org/TR/wai-aria-1.2/
- W3C XML 1.0 (Quinta Edición). Especificación del lenguaje XML.
- ECMA-262 (ECMAScript). Especificación estándar de JavaScript.
- OpenAPI Specification 3.1. Estándar para definición de APIs RESTful.
- OAuth 2.0 (RFC 6749) y OpenID Connect. Estándares de autenticación y autorización.
- HL7 FHIR R4. Estándar de interoperabilidad sanitaria para APIs. URL: https://www.hl7.org/fhir/
Guías y Documentación del CCN-CERT:
- CCN-STIC 807 – Criptología de empleo en el ENS. Algoritmos y protocolos criptográficos (incluye TLS 1.3).
- CCN-STIC 824 – Guía de seguridad de las TIC (ENS) – Seguridad en aplicaciones web.
- CCN-STIC 480 – Seguridad en APIs REST.
Documentación Específica del SAS:
- Política de Seguridad de las Tecnologías de la Información y Comunicaciones del SAS. Documento corporativo interno.
- Estándares de Desarrollo Web del SAS. Guías internas para desarrollo de aplicaciones web corporativas.
- Manual de Estilo de Accesibilidad Web del SSPA. Directrices específicas para cumplimiento WCAG en aplicaciones sanitarias.
- Arquitectura de Referencia de Aplicaciones Web del SAS. Documento técnico de arquitectura corporativa.
Bibliografía Técnica Recomendada:
- Flanagan, David. «JavaScript: The Definitive Guide» (7th Edition). O’Reilly, 2020. Referencia completa de JavaScript moderno.
- Frain, Ben. «Responsive Web Design with HTML5 and CSS» (4th Edition). Packt, 2022. Diseño web responsive y HTML5.
- Richardson, Leonard; Amundsen, Mike; Ruby, Sam. «RESTful Web APIs». O’Reilly, 2013. Diseño de APIs REST efectivas.
- Lawson, Bruce; Sharp, Remy. «Introducing HTML5» (2nd Edition). New Riders, 2011. Introducción completa a HTML5.
- W3C WAI. «Web Accessibility Initiative (WAI) Resources». Documentación oficial sobre accesibilidad web.
- Mozilla Developer Network (MDN). «MDN Web Docs». URL: https://developer.mozilla.org/ – Documentación de referencia web más completa y actualizada.
Recursos Online Actualizados:
- Can I Use (https://caniuse.com/) – Compatibilidad de características HTML5/CSS3/JavaScript en navegadores.
- WAVE Web Accessibility Evaluation Tool (https://wave.webaim.org/) – Evaluación de accesibilidad web.
- Google Lighthouse – Herramienta de auditoría de rendimiento, accesibilidad, SEO y mejores prácticas.
- OWASP Top 10 – Lista actualizada de vulnerabilidades web más críticas.