1. INTRODUCCIÓN

El e-learning o aprendizaje electrónico designa el conjunto de procesos de enseñanza, aprendizaje, comunicación, evaluación y gestión que se apoyan de manera sustancial en tecnologías digitales. No equivale a colocar documentos en una página web. Para que exista un verdadero sistema de aprendizaje electrónico deben coordinarse, al menos, una estrategia pedagógica, contenidos estructurados, herramientas de interacción, mecanismos de seguimiento, servicios de soporte, reglas de gobierno y una infraestructura tecnológica capaz de prestar el servicio con seguridad y continuidad.

En una organización sanitaria pública esta distinción es especialmente importante. La formación afecta a colectivos numerosos, distribuidos geográficamente y sometidos a turnos, guardias y distintas condiciones de acceso. Los contenidos pueden abarcar normativa, prevención de riesgos, protección de datos, ciberseguridad, procedimientos clínicos, aplicaciones corporativas o competencias transversales. Por ello, el sistema debe admitir ritmos diferentes, registrar evidencias de realización, facilitar la actualización de materiales y garantizar que el acceso no excluya a personas con discapacidad o con limitaciones temporales de conectividad.

Desde el punto de vista del TFA-STI, el tema se sitúa en la intersección de varias disciplinas. Intervienen la arquitectura de sistemas, la gestión de identidades, la interoperabilidad, la ingeniería del software, la explotación de datos, la contratación pública, la continuidad del servicio y la experiencia de usuario. También aparecen organismos y normas propios de las tecnologías educativas: Advanced Distributed Learning, IEEE, 1EdTech, W3C, ISO/IEC y los marcos nacionales de seguridad y accesibilidad.

El propósito de este tema es construir una visión completa. Primero se delimitan los conceptos y modalidades; después se estudian las teorías y métodos de diseño; a continuación se analiza el ecosistema de herramientas y, de forma central, los Learning Management Systems. Se desarrollan los estándares de normalización —SCORM, xAPI, cmi5, LTI, QTI, Common Cartridge, Caliper y Open Badges—, los modelos de implantación y las obligaciones de seguridad, privacidad y accesibilidad. Finalmente se estudian los MOOC, la analítica del aprendizaje, las tendencias y la aplicación concreta al Servicio Andaluz de Salud.

En examen suelen plantearse preguntas de distinción: LMS frente a LCMS, SCORM frente a xAPI, repositorio de aprendizaje frente a repositorio de contenidos, curso abierto frente a curso gratuito, o cumplimiento técnico frente a calidad pedagógica. La clave consiste en comprender qué problema resuelve cada componente y no memorizar siglas como si fueran equivalentes.

2. CONCEPTOS, CARACTERÍSTICAS Y MODALIDADES

2.1. Concepto operativo

Una definición operativa de e-learning debe incluir cinco elementos. Primero, existe una finalidad formativa: adquirir conocimientos, habilidades, actitudes o competencias. Segundo, la mediación tecnológica no es accidental, sino que organiza el acceso, la interacción o la evaluación. Tercero, hay una estructura didáctica con objetivos, secuencia y actividades. Cuarto, se generan evidencias que permiten valorar el progreso. Quinto, el proceso se integra en un marco de gestión con roles, soporte y reglas de calidad.

El aprendizaje electrónico puede desarrollarse íntegramente en línea o formar parte de una experiencia mixta. Puede ser formal, cuando conduce a una acreditación o está incluido en un plan institucional; no formal, cuando responde a una actividad organizada sin reconocimiento académico pleno; e informal, cuando surge de la consulta autónoma, la comunidad profesional o la resolución cotidiana de problemas. Un LMS suele concentrarse en lo formal y no formal, mientras que xAPI y los repositorios de registros permiten capturar también experiencias distribuidas.

2.2. Rasgos funcionales

2.3. Modalidades

En el e-learning asíncrono el alumno trabaja sin coincidir temporalmente con el docente. Son típicos los módulos autoguiados, foros, tareas y cuestionarios con plazo. Su ventaja es la compatibilidad con horarios diversos; su riesgo es el aislamiento y el abandono si faltan acompañamiento y recordatorios significativos. En el e-learning síncrono existe coincidencia temporal mediante aula virtual, videoconferencia, chat o práctica remota. Aporta inmediatez, pero exige planificación, ancho de banda, soporte y alternativas accesibles.

El blended learning o aprendizaje combinado integra actividades presenciales y digitales dentro de un único diseño. No consiste en sumar una clase y un PDF: cada modalidad debe asumir aquello que hace mejor. La teoría, la preparación previa y la evaluación diagnóstica pueden desarrollarse en línea; la simulación, la discusión compleja o la práctica con equipamiento pueden reservarse para la presencialidad. El mobile learning adapta la experiencia a dispositivos móviles y contextos breves, pero no debe obligar a ejecutar en una pantalla pequeña tareas que requieren lectura extensa o interacción compleja.

El microlearning organiza unidades breves y orientadas a un objetivo muy concreto. Resulta útil para recordatorios, procedimientos, actualizaciones o refuerzo espaciado. No sustituye por sí solo una formación que necesita integración conceptual, práctica deliberada y evaluación compleja. El social learning emplea foros, comunidades de práctica, anotaciones y producción entre pares. Su valor depende de la moderación, la confianza y la calidad de las fuentes, especialmente cuando se tratan contenidos sanitarios.

3. FUNDAMENTOS PEDAGÓGICOS Y DISEÑO INSTRUCCIONAL

3.1. Tecnología subordinada al aprendizaje

La selección tecnológica debe partir de los resultados de aprendizaje. Si el objetivo es recordar una norma, pueden ser suficientes una explicación breve, ejemplos y práctica de recuperación. Si se pretende tomar decisiones en una situación compleja, serán necesarias actividades de aplicación, casos, simulación y retroalimentación razonada. Un LMS puede alojar ambos diseños, pero no convierte automáticamente un contenido expositivo en una experiencia eficaz.

Las corrientes conductistas aportan la definición observable de objetivos, la práctica repetida y el refuerzo. Los enfoques cognitivos atienden a la memoria de trabajo, la organización de esquemas y la carga cognitiva. El constructivismo pone el acento en la actividad del alumno y la construcción de significado a partir de problemas. El conectivismo resalta la capacidad de localizar, valorar y relacionar conocimiento distribuido en redes. En la práctica profesional no se elige una teoría única: se combinan principios según el tipo de competencia.

3.2. Modelo ADDIE y alternativas iterativas

El modelo ADDIE resume cinco grandes procesos: análisis, diseño, desarrollo, implantación y evaluación. En el análisis se identifican población, necesidades, contexto, riesgos y restricciones. En el diseño se concretan objetivos, secuencia, actividades, evaluación y estrategia de accesibilidad. En el desarrollo se producen y prueban materiales. En la implantación se configuran plataforma, matrículas, soporte y comunicación. La evaluación verifica tanto el funcionamiento como los resultados.

ADDIE no obliga a un proceso rígido. En entornos cambiantes conviene trabajar de forma iterativa: prototipo, prueba con usuarios, revisión y ampliación. Modelos como SAM y las prácticas ágiles reducen el riesgo de descubrir al final que la navegación es confusa, el contenido no es accesible o las preguntas no miden el objetivo. La iteración no elimina la documentación; la hace proporcional y orientada a decisiones verificables.

3.3. Alineamiento constructivo y evaluación

El diseño de calidad alinea tres elementos: objetivos, actividades y evaluación. Si el objetivo indica «configurar», una prueba que solo pregunta definiciones es insuficiente. Si se pretende «analizar un incidente», la actividad debe presentar evidencias y exigir una decisión justificada. Las rúbricas ayudan a hacer explícitos los criterios cuando la respuesta no es puramente objetiva.

La evaluación puede ser diagnóstica, formativa o sumativa. La diagnóstica identifica el punto de partida y permite ajustar el itinerario. La formativa ofrece retroalimentación durante el proceso y debe indicar por qué una respuesta es adecuada o cómo mejorar. La sumativa determina el logro final y puede sustentar una certificación. En cursos obligatorios conviene separar la evidencia de acceso de la evidencia de competencia: abrir todos los recursos no demuestra aprendizaje.

También deben aplicarse principios de aprendizaje multimedia: coherencia, señalización, segmentación, proximidad espacial y temporal, modalidad adecuada y evitación de redundancias perjudiciales. Un vídeo no mejora el aprendizaje por ser vídeo; debe tener guion, ritmo, subtítulos, controles, alternativa textual y una actividad que active la recuperación o aplicación.

4. ECOSISTEMA DE HERRAMIENTAS DE E-LEARNING

4.1. Componentes principales

Un ecosistema de aprendizaje digital puede incluir varios productos especializados. El LMS gestiona usuarios, cursos, matrículas, actividades, calificaciones y evidencias. El LCMS se orienta a la creación, gestión y reutilización de contenidos mediante repositorios y flujos editoriales. Una LXP ofrece descubrimiento, recomendación y consumo de recursos con una experiencia más centrada en el usuario, aunque suele necesitar integración con el LMS para las obligaciones formales. Un LRS almacena y consulta declaraciones xAPI. El repositorio de objetos conserva ficheros y metadatos; el servicio de vídeo se ocupa de ingesta, transcodificación, subtítulos y distribución.

A estos elementos se añaden herramientas de autor, videoconferencia, foros, pizarras, laboratorios virtuales, simuladores, sistemas de evaluación, proctoring, encuestas, gestores de competencias, catálogos, motores de recomendación y cuadros de mando. La arquitectura debe evitar duplicar la fuente de verdad. Por ejemplo, la identidad profesional puede proceder del directorio corporativo, la situación laboral del sistema de recursos humanos y la evidencia de superación del LMS. Las sincronizaciones necesitan reglas de precedencia, trazabilidad y tratamiento de errores.

4.2. Herramientas de autor

Las herramientas de autor permiten generar páginas, actividades, escenarios ramificados, vídeos interactivos y paquetes normalizados. Algunas son aplicaciones comerciales de escritorio o nube; otras, como H5P, se integran en plataformas y favorecen la creación de contenido interactivo reutilizable. La decisión no debe basarse solo en la facilidad inicial: hay que examinar accesibilidad de la salida, portabilidad, versionado, localización, mantenimiento, dependencia del proveedor y capacidad para separar contenido de presentación.

Un problema frecuente es conservar únicamente el paquete publicado y perder los ficheros fuente. El paquete SCORM puede ejecutarse, pero resulta difícil modificarlo de forma segura. La gestión documental debe conservar fuente, versión publicada, licencias de recursos, guion, archivos multimedia, transcripciones y registro de revisiones. Cuando el contenido afecta a procedimientos o normativa, es necesario identificar propietario, fecha de vigencia y mecanismo de retirada.

4.3. Comunicación y colaboración

Los foros facilitan reflexión y aprendizaje entre pares, pero requieren normas, moderación y una estructura que evite hilos interminables. Las videoconferencias necesitan gestión de acceso, consentimiento y política de grabación. Los chats son útiles para soporte inmediato, aunque generan conocimiento difícil de recuperar si no se resumen. Las comunidades de práctica pueden integrarse con el aprendizaje formal mediante actividades, badges o referencias, sin convertir toda conversación en una evidencia evaluativa.

En el sector sanitario debe evitarse que el espacio formativo se convierta en un canal informal para compartir información identificable de pacientes. Los casos han de estar anonimizados de manera efectiva o ser sintéticos. El acceso restringido no convierte automáticamente un dato clínico en adecuado para formación.

5. LEARNING MANAGEMENT SYSTEMS: FUNCIONES, ROLES Y ARQUITECTURA

5.1. Definición y alcance

Un Learning Management System es una plataforma que administra la oferta formativa y la relación de los participantes con esa oferta. Sus funciones básicas abarcan catálogo, matrícula, organización de aulas, entrega de recursos, actividades, comunicación, evaluación, seguimiento, certificación e informes. En un entorno corporativo debe manejar estructuras organizativas, colectivos, convocatorias, prerrequisitos, itinerarios, equivalencias, caducidades y formación obligatoria.

El LMS no debe confundirse con el sistema de recursos humanos. Puede recibir datos de plantilla y devolver evidencias de formación, pero cada sistema conserva responsabilidades distintas. Tampoco es necesariamente el repositorio maestro de certificados, competencias o expedientes. Una arquitectura bien gobernada define qué sistema origina cada dato, qué identificador común se utiliza, con qué periodicidad se sincroniza y cómo se resuelven inconsistencias.

5.2. Roles

Los roles habituales son alumno, tutor, docente, diseñador, revisor, gestor de formación, administrador funcional y administrador técnico. El principio de mínimo privilegio exige separar funciones. Un tutor puede calificar y comunicarse con su grupo, pero no necesita modificar la configuración global. Un diseñador puede editar contenidos, pero no necesariamente acceder a informes nominales de toda la organización. Las cuentas de administración deben ser nominativas, protegidas y auditadas.

5.3. Arquitectura lógica

En despliegues de cierta escala se separan presentación, servicios de aplicación, base de datos, almacenamiento de ficheros, caché, colas y servicios de búsqueda. El balanceo distribuye peticiones; la caché reduce cargas repetidas; las colas desacoplan procesos como notificaciones o generación de informes. El almacenamiento de vídeo requiere capacidades distintas de las páginas y cuestionarios. La monitorización debe cubrir disponibilidad, tiempos de respuesta, errores, saturación, colas, uso de almacenamiento y experiencia real del usuario.

La arquitectura puede ser local, alojada, SaaS o híbrida. El software libre, como Moodle u Open edX, ofrece acceso al código y capacidad de adaptación, pero no elimina costes de operación, actualización, seguridad, soporte y gobierno. Un producto comercial puede reducir tareas técnicas, aunque requiere analizar portabilidad, costes recurrentes, ubicación y tratamiento de datos, niveles de servicio, reversibilidad y dependencia del proveedor. «Código abierto» y «on-premise» no son sinónimos; un LMS abierto puede ofrecerse como servicio, y un producto comercial puede instalarse en infraestructura dedicada.

5.4. Productos representativos

Moodle es un LMS de código abierto y extensible; Open edX combina un LMS con herramientas de autor y se diseñó para experiencias de gran escala. Existen además productos comerciales orientados a educación, empresa o gestión del talento. En oposición interesa comprender categorías y criterios, no memorizar un ranking cambiante. La elección debe justificarse por requisitos y evidencias, no por popularidad.

6. NORMALIZACIÓN I: OBJETOS, METADATOS Y SCORM

6.1. Objetivos de la normalización

La normalización persigue que contenidos, herramientas y datos puedan intercambiarse con menos dependencia de implementaciones propietarias. Sus beneficios son portabilidad, reutilización, integración, comparabilidad y reducción del coste de cambio. No garantiza por sí sola una migración perfecta: cada estándar cubre una parte y puede admitir perfiles opcionales. Por ello deben especificarse versiones, niveles de conformidad, pruebas de importación y exportación y criterios de aceptación.

Un objeto de aprendizaje es una unidad digital diseñada para apoyar un objetivo y susceptible de reutilización. Puede ser una explicación, un caso, una simulación o una evaluación. Los metadatos describen título, idioma, autoría, versión, materia, derechos, requisitos y finalidad educativa. IEEE 1484.12.1, conocido como LOM, proporcionó un modelo de metadatos ampliamente utilizado. Los perfiles de aplicación seleccionan elementos y vocabularios para un contexto concreto; sin gobernanza, los metadatos terminan incompletos o inconsistentes.

6.2. SCORM como modelo de referencia

SCORM significa Sharable Content Object Reference Model. Fue impulsado por la iniciativa Advanced Distributed Learning para reunir y perfilar especificaciones previas. No es un formato de vídeo ni una herramienta de autor: es un modelo de referencia que define cómo empaquetar contenido, cómo lo lanza el LMS y cómo intercambian determinada información durante la sesión.

Las dos familias que el opositor debe reconocer son SCORM 1.2 y SCORM 2004. SCORM 1.2 mantiene una enorme presencia por compatibilidad. SCORM 2004 incorporó un modelo más desarrollado de secuenciación y navegación; su cuarta edición es la referencia final de esa familia. La elección no debe decidirse por «versión más alta», sino por interoperabilidad real entre herramienta de autor, contenido y LMS.

Un paquete se distribuye habitualmente como archivo comprimido que contiene recursos y un manifiesto XML. El LMS importa el paquete, interpreta la organización y lanza los SCO. En tiempo de ejecución el contenido localiza la API proporcionada por el LMS y usa las llamadas definidas para inicializar, leer o establecer valores y terminar la sesión. La comunicación está condicionada por el navegador y por el contexto de lanzamiento, lo que explica parte de las limitaciones frente a arquitecturas distribuidas.

<manifest identifier="curso-ejemplo">
  <organizations default="org-principal">
    <organization identifier="org-principal">
      <title>Curso de ejemplo</title>
      <item identifier="unidad-1" identifierref="recurso-1">
        <title>Unidad 1</title>
      </item>
    </organization>
  </organizations>
  <resources>
    <resource identifier="recurso-1" href="inicio.html">
      <file href="inicio.html"/>
    </resource>
  </resources>
</manifest>

El fragmento es ilustrativo: un paquete real debe incluir espacios de nombres y requisitos de la versión concreta. En contratación no basta con pedir «compatible con SCORM»; debe probarse la importación, el lanzamiento, la persistencia, la reanudación, el envío de resultados y el tratamiento de errores con paquetes de referencia.

6.3. Fortalezas y límites

SCORM resolvió de forma práctica la portabilidad de cursos autocontenidos y la comunicación básica con el LMS. Sus límites aparecen cuando la experiencia ocurre en aplicaciones móviles, simuladores, práctica presencial, dispositivos o servicios externos. Tampoco fue diseñado como un almacén analítico abierto para consultar libremente toda la experiencia. Por ello xAPI no debe describirse como una «versión de SCORM», sino como otro enfoque para registrar experiencias.

7. NORMALIZACIÓN II: xAPI, cmi5 Y LRS

7.1. Experience API

xAPI permite comunicar datos sobre experiencias de aprendizaje mediante un modelo JSON y una API web REST. La especificación evolucionó desde la versión conocida como Tin Can y fue normalizada como IEEE 9274.1.1-2023. Su ventaja conceptual es separar el registro de experiencias del lanzamiento tradicional de un paquete dentro del LMS. Una aplicación, un simulador, un recurso móvil o un sistema presencial instrumentado pueden emitir declaraciones hacia un Learning Record Store.

La unidad principal es el statement. Incluye actor, verbo y objeto, y puede añadir resultado, contexto, autoridad y marca temporal. La aparente simplicidad no elimina la necesidad de vocabularios controlados. Si cada aplicación inventa verbos e identificadores distintos, los datos serán técnicamente válidos pero difíciles de combinar. Los perfiles xAPI establecen reglas, conceptos e identificadores comunes para un dominio.

{
  "actor": {
    "objectType": "Agent",
    "account": {
      "homePage": "https://formacion.example.org",
      "name": "usuario-12345"
    }
  },
  "verb": {
    "id": "https://w3id.org/xapi/adl/verbs/completed",
    "display": {"es": "completó"}
  },
  "object": {
    "id": "https://formacion.example.org/actividades/modulo-seguridad",
    "definition": {
      "name": {"es": "Módulo de seguridad"}
    }
  },
  "result": {
    "completion": true,
    "success": true
  }
}

El ejemplo utiliza un identificador seudónimo y evita un correo personal. En un sistema real deben definirse identidad, base jurídica, control de acceso, retención y propósito analítico. El LRS no es un almacén sin límites: recibe, valida, conserva y permite consultar declaraciones; su acceso debe estar protegido y sus datos sometidos a gobierno.

7.2. Diferencias con SCORM

7.3. cmi5

xAPI es deliberadamente general. Para el caso «el LMS lanza contenido y necesita reglas interoperables de sesión, finalización, puntuación y estructura», se utiliza cmi5. cmi5 es un perfil de xAPI que define mecanismo de lanzamiento, autenticación, gestión de sesión, informes y estructura del curso. Permite aprovechar la riqueza de xAPI sin perder la previsibilidad que necesita un LMS.

La distinción es relevante: xAPI puede existir sin LMS y registrar experiencias muy variadas; cmi5 se centra en contenido lanzado desde un LMS. Un paquete informal llamado en ocasiones «Tin Can package» no equivale a cmi5, porque carece de sus reglas completas de interoperabilidad.

7.4. Diseño de un ecosistema de datos

Antes de instrumentar debe definirse el catálogo de actividades, verbos, identificadores, contexto y resultados. Conviene establecer un perfil, un registro de cambios y pruebas de validación. También hay que decidir qué datos necesita realmente el caso de uso. Para detectar dificultades quizá basta con intentos, resultados y secuencia; registrar cada movimiento de ratón sería intrusivo y poco útil.

Los cuadros de mando deben distinguir correlación y causalidad. Que una persona pase poco tiempo en un módulo puede indicar dominio previo, abandono o contenido demasiado sencillo. La analítica necesita contexto pedagógico y revisión humana. En el sector público, la transparencia del propósito y la minimización son tan importantes como la capacidad técnica.

8. NORMALIZACIÓN III: LTI, QTI, COMMON CARTRIDGE, CALIPER Y CREDENCIALES

8.1. Learning Tools Interoperability

LTI, de 1EdTech, permite que una plataforma de aprendizaje integre herramientas externas de forma normalizada. El LMS actúa como plataforma y el servicio externo como herramienta. El usuario puede acceder desde el contexto del curso sin gestionar una cuenta independiente en cada integración, siempre dentro de las reglas de identidad y autorización acordadas.

La versión actual de referencia es LTI 1.3. Mejora el modelo de seguridad y utiliza mecanismos modernos basados en OpenID Connect, OAuth 2.0 y tokens firmados. Los servicios conocidos como LTI Advantage facilitan, entre otras capacidades, vinculación profunda de contenidos, intercambio de nombres y roles cuando esté autorizado y devolución de calificaciones. No debe enviarse al proveedor más información de la necesaria; los contratos y la configuración deben limitar atributos, finalidad y retención.

8.2. Question and Test Interoperability

QTI define estructuras para intercambiar preguntas, pruebas, respuestas, reglas de puntuación y resultados. QTI 3.0 amplía la interoperabilidad de evaluaciones, incorpora una base más web y mejora las capacidades de accesibilidad y pruebas adaptativas. La portabilidad real exige acordar tipos de ítem, extensiones y comportamiento, porque un proveedor puede soportar solo un subconjunto.

QTI resuelve un problema distinto al de SCORM. Un examen puede integrarse dentro de un paquete SCORM, pero sus preguntas quedarían encapsuladas. Con QTI, el banco puede importar y editar los ítems de forma estructurada, aplicar reglas de presentación y reutilizarlos en diferentes pruebas. La seguridad del banco —permisos, exposición, trazabilidad y control de versiones— es crítica.

8.3. Common Cartridge

Common Cartridge proporciona una forma normalizada de empaquetar e intercambiar recursos educativos, enlaces, organización y evaluaciones entre plataformas. Puede combinar especificaciones de 1EdTech y favorece migraciones más ricas que una simple carpeta de ficheros. Su existencia no elimina la necesidad de revisar enlaces externos, licencias, tipos de actividad y funciones propias del LMS de origen.

8.4. Caliper Analytics

Caliper Analytics ofrece un lenguaje y perfiles métricos para capturar y compartir eventos de actividad desde aplicaciones educativas hacia agregadores. Se parece a xAPI en que normaliza eventos, pero pertenece a un ecosistema y modelo diferentes. No deben mezclarse statements xAPI y eventos Caliper como si fueran el mismo formato. La elección depende de las herramientas, los casos de uso y la estrategia de interoperabilidad.

8.5. Open Badges y credenciales verificables

Open Badges 3.0 representa logros mediante credenciales digitales interoperables. Puede describir emisor, criterio, evidencia, titular y alineamiento con competencias. La versión 3.0 se alinea con el modelo de credenciales verificables del W3C y mejora la seguridad y movilidad. Un badge no es automáticamente una titulación oficial: su valor depende del emisor, del criterio y de la evidencia.

En un pliego de contratación, la mención a un estándar debe acompañarse de versión, perfiles, certificación o pruebas, operaciones requeridas y tratamiento de extensiones. La frase «compatible con estándares» es insuficiente y favorece interpretaciones comerciales no verificables.

9. SISTEMAS Y METODOLOGÍA DE IMPLANTACIÓN

9.1. Gobierno y caso de negocio

Implantar un sistema de e-learning no es instalar una aplicación y abrir cursos. El proyecto debe comenzar con un modelo de gobierno que identifique patrocinio, responsables de formación, propietarios de contenidos, responsables técnicos, seguridad, protección de datos, accesibilidad, soporte y proveedores. El caso de negocio debe relacionar la inversión con necesidades concretas: cumplimiento normativo, actualización profesional, reducción de desplazamientos, homogeneización de procedimientos, incorporación de personal o desarrollo de competencias digitales.

Los requisitos se agrupan en funcionales y no funcionales. Entre los funcionales se encuentran catálogo, convocatorias, matrícula, grupos, tutores, actividades, evaluación, certificados, equivalencias, itinerarios y explotación. Entre los no funcionales figuran rendimiento, disponibilidad, escalabilidad, accesibilidad, interoperabilidad, seguridad, mantenibilidad, auditabilidad y reversibilidad. La contratación debe distinguir requisito obligatorio, criterio valorable y evidencia de cumplimiento.

9.2. Modelos de despliegue

La decisión requiere analizar coste total de propiedad, no solo licencia. Deben incluirse infraestructura, almacenamiento, tráfico, soporte, administración, personalización, integraciones, migración, formación, auditoría, pruebas, renovación y cierre. La reversibilidad exige poder exportar usuarios, historiales, contenidos, calificaciones, certificados y configuraciones en formatos documentados, con plazos y asistencia definidos.

9.3. Fases técnicas

1. Descubrimiento: inventario de sistemas, usuarios, cursos, datos, integraciones, restricciones y deuda técnica.
2. Diseño: arquitectura, modelo de identidad, datos maestros, roles, catálogo, estándares, seguridad, accesibilidad y operación.
3. Prototipo: instalación mínima, integración de identidad, importación de paquetes y prueba de un curso representativo.
4. Piloto: población limitada, medición de carga, soporte, usabilidad, accesibilidad y resultados pedagógicos.
5. Migración: limpieza, mapeo, transformación, verificación y conservación de evidencias.
6. Despliegue: comunicación, formación, escalado progresivo, centro de soporte y gestión del cambio.
7. Operación: monitorización, parches, copias, continuidad, revisiones de contenido y mejora continua.

El prototipo y el piloto deben incluir casos difíciles: reanudación de SCORM, caracteres especiales, usuarios con múltiples roles, matrícula masiva, cuestionarios con varios intentos, emisión de certificado, contenido multimedia, navegación con teclado, lector de pantalla y picos de concurrencia. La aceptación no puede basarse exclusivamente en una demostración comercial.

9.4. Migración

La migración empieza por clasificar. Hay cursos vigentes, caducados, duplicados, sin propietario, incompatibles o sin fuentes editables. Migrarlo todo reproduce el desorden. Cada objeto debe asociarse a propietario, vigencia, licencia, estándar y decisión: migrar, transformar, archivar o retirar. Las calificaciones históricas y certificados pueden tener valor probatorio; su conservación debe definirse con criterios funcionales, documentales y de protección de datos.

Los identificadores son críticos. Una persona puede tener cambios de categoría, centro o relación laboral; el sistema debe utilizar una identidad estable y evitar crear duplicados por variaciones del correo. Las equivalencias entre cursos necesitan reglas explícitas y fecha de vigencia. Después de transformar datos se ejecutan reconciliaciones: número de usuarios, matrículas, finalizaciones, certificados y muestras nominales autorizadas.

9.5. Gestión del cambio

La adopción requiere segmentar públicos. El alumno necesita instrucciones breves y soporte; el tutor, herramientas para seguimiento; el autor, plantillas accesibles; el gestor, informes; el administrador, procedimientos. La formación de administradores debe incluir no solo uso, sino recuperación, diagnóstico, actualización y gestión de incidentes. Los primeros meses conviene disponer de una red de referentes y un catálogo claro de solicitudes.

10. SEGURIDAD, PRIVACIDAD Y CONTINUIDAD

10.1. Aplicación del Esquema Nacional de Seguridad

Un sistema del sector público incluido en el ámbito del Esquema Nacional de Seguridad debe aplicar el Real Decreto 311/2022. La categoría no se asigna por el nombre «LMS», sino por la valoración del impacto de un incidente en las dimensiones de seguridad: disponibilidad, autenticidad, integridad, confidencialidad y trazabilidad. Un portal abierto de divulgación y una plataforma que acredita formación obligatoria pueden requerir medidas diferentes.

El análisis debe considerar activos, amenazas, dependencias y servicios externos. Son relevantes la gestión de identidades, la separación de roles, el registro de actividad, la protección de comunicaciones, la gestión de vulnerabilidades, las copias, la continuidad, la protección frente a código malicioso y la seguridad de la cadena de suministro. Los plugins y extensiones amplían funcionalidad, pero también superficie de ataque; deben inventariarse, mantenerse y retirarse cuando pierdan soporte.

La autenticación puede integrarse con el proveedor corporativo mediante SAML 2.0 u OpenID Connect, según la arquitectura. OAuth 2.0 es un marco de autorización y no debe presentarse por sí solo como protocolo de autenticación; OpenID Connect añade la capa de identidad. El MFA es especialmente adecuado para roles privilegiados. Las sesiones deben expirar, las cuentas genéricas evitarse y los permisos revisarse.

10.2. Protección de datos

El LMS trata datos identificativos, de contacto, relación profesional, actividad, resultados y, en ocasiones, necesidades de accesibilidad. El tratamiento debe cumplir el RGPD y la Ley Orgánica 3/2018. Han de definirse finalidad y base jurídica, informar a las personas, limitar los datos, controlar conservación, atender derechos y formalizar encargos cuando intervienen proveedores.

La formación obligatoria de empleados públicos no se basa normalmente en un consentimiento libre como condición general, pues existe una relación jurídica y una obligación organizativa. La base concreta debe ser determinada por el responsable según la normativa aplicable, la misión de interés público, la obligación legal o la gestión de la relación. El consentimiento puede ser pertinente para finalidades opcionales separadas, pero no debe utilizarse como fórmula automática.

La analítica plantea riesgos adicionales. Un modelo de abandono puede inferir rendimiento o comportamiento. Antes de implantarlo deben evaluarse necesidad, proporcionalidad, calidad de datos, sesgos, transparencia y consecuencias. Las decisiones relevantes no deben delegarse acríticamente en una puntuación. La seudonimización reduce exposición, pero no convierte los datos en anónimos si existe posibilidad razonable de reidentificación.

10.3. Seguridad de contenidos y evaluaciones

Los bancos de preguntas requieren controles de acceso, versionado y registro de exportaciones. El navegador no puede garantizar secreto absoluto si el contenido se entrega al dispositivo. Las medidas deben ser proporcionales: aleatorización, bancos amplios, límites de intento, preguntas de aplicación, renovación, supervisión cuando proceda y análisis de patrones. El proctoring añade tratamiento intensivo y posibles datos biométricos; solo debe utilizarse con necesidad, base jurídica, evaluación de impacto cuando corresponda y alternativas accesibles.

10.4. Continuidad

La continuidad comienza con el análisis de impacto. Se definen RTO, RPO, dependencias, procedimientos manuales y prioridades de recuperación. Una copia no es una estrategia si nunca se restaura. Deben probarse base de datos, ficheros, configuración, claves y documentación. Las convocatorias con fecha límite requieren planes para indisponibilidad: ampliación de plazo, comunicación, registro de incidencia y recuperación de intentos.

La monitorización debe combinar métricas técnicas y de negocio: errores de autenticación, tiempos de carga, fallos de tareas programadas, colas, almacenamiento, correo rechazado, paquetes que no comunican progreso y tasas anómalas de abandono. Un servicio puede estar «encendido» y ser inutilizable para el alumno.

11. ACCESIBILIDAD, USABILIDAD Y DISEÑO INCLUSIVO

11.1. Marco aplicable

El Real Decreto 1112/2018 exige garantizar la accesibilidad de sitios web y aplicaciones móviles del sector público dentro de su ámbito. La accesibilidad debe considerarse de forma integral en diseño, gestión, mantenimiento y actualización. La presunción de conformidad se vincula a las normas armonizadas publicadas en el ámbito europeo. La norma EN 301 549 establece requisitos de accesibilidad para productos y servicios TIC y constituye una referencia esencial en contratación.

En el plano técnico, W3C publicó WCAG 2.2 como recomendación. Sus principios son perceptible, operable, comprensible y robusto. Debe distinguirse entre la versión más reciente de las pautas y la versión incorporada en la norma armonizada aplicable a una obligación concreta. Un pliego puede exigir mejoras adicionales, pero debe expresar claramente el criterio de conformidad y su método de verificación.

11.2. Accesibilidad de la plataforma y del contenido

Una plataforma accesible puede alojar un curso inaccesible. El producto debe permitir navegación por teclado, foco visible, estructura semántica, compatibilidad con tecnologías de apoyo, contraste, ampliación y mensajes de error claros. El contenido debe aportar encabezados jerárquicos, texto alternativo, subtítulos, transcripciones, instrucciones no dependientes del color, tablas marcadas, lenguaje comprensible y actividades que no exijan una habilidad motora o sensorial sin alternativa.

Los paquetes generados por herramientas de autor deben probarse en el LMS real. Un contenido puede ser accesible de forma aislada y perder usabilidad dentro de un marco, ventana emergente o navegación duplicada. Las pruebas automáticas detectan parte de los fallos; se necesitan revisión manual, teclado, lectores de pantalla y usuarios con diversidad funcional.

11.3. Usabilidad y carga cognitiva

La usabilidad reduce el esfuerzo dedicado a entender la interfaz. Debe existir consistencia en botones, navegación, plazos y mensajes. El alumno necesita conocer progreso, requisitos de finalización, intento disponible y consecuencias de abandonar. Los errores deben indicar cómo resolverlos. Una interfaz muy decorada puede perjudicar señalización y atención.

El diseño responsive adapta distribución, pero no resuelve todas las necesidades móviles. Los objetivos táctiles deben ser adecuados, las tablas complejas requieren alternativa, los ficheros pesados deben advertirse y la actividad ha de poder reanudarse. La descarga para uso sin conexión debe considerar control de versión y sincronización segura.

11.4. Proceso de conformidad

La accesibilidad debe incluirse en definición de hecho, plantillas, formación de autores, revisión editorial, pruebas de aceptación y gestión de incidencias. Es importante publicar la declaración correspondiente y habilitar mecanismos de comunicación. Una auditoría puntual no garantiza que los nuevos contenidos mantengan el nivel; se necesita gobierno continuo.

12. CALIDAD, EVALUACIÓN Y MEJORA CONTINUA

12.1. Concepto de calidad

La calidad de un sistema de e-learning comprende eficacia pedagógica, adecuación a necesidades, accesibilidad, fiabilidad técnica, soporte, seguridad, actualización y eficiencia. Un curso con alta tasa de finalización puede ser irrelevante; otro con buena valoración puede no modificar la práctica. La evaluación debe combinar perspectivas y evitar indicadores de vanidad.

ISO/IEC 40180:2017 proporciona fundamentos y un marco de referencia para asegurar, gestionar y mejorar la calidad del aprendizaje apoyado por tecnologías. ISO 21001:2025 establece requisitos para sistemas de gestión de organizaciones educativas. En España, UNE 66181 ha servido como referencia para identificar características de calidad de la formación virtual. Estas normas no sustituyen el diseño del servicio; ayudan a estructurar procesos, responsabilidades, evidencias y mejora.

12.2. Indicadores

El modelo de Kirkpatrick distingue reacción, aprendizaje, comportamiento y resultados. Es útil como marco, pero no debe aplicarse mecánicamente. La reacción se mide con encuestas; el aprendizaje con pruebas válidas; el comportamiento con observación o indicadores del puesto; los resultados con efectos organizativos. Cuanto más lejos se avanza, mayor dificultad para atribuir el cambio exclusivamente a la formación.

12.3. Ciclo de mejora

El ciclo PDCA organiza la mejora: planificar objetivos y cambios, ejecutar a escala controlada, comprobar evidencias y actuar para estandarizar o corregir. En cada edición se revisan incidencias, preguntas con comportamiento anómalo, abandono, accesibilidad, comentarios y cambios normativos. Los contenidos deben tener fecha de revisión y propietario. Si una instrucción ha quedado obsoleta, el curso debe retirarse o actualizarse, no permanecer disponible por inercia.

Las pruebas A/B pueden comparar elementos de interfaz o comunicación, pero no deben alterar de forma injusta una evaluación. Los experimentos necesitan hipótesis, métricas, tamaño suficiente y protección de los participantes. La mejora no consiste en aumentar continuamente notificaciones; un exceso puede producir fatiga.

12.4. Soporte y acuerdos de servicio

El soporte debe diferenciar incidencias técnicas, consultas funcionales y dudas académicas. La primera la atiende el servicio TIC; la segunda, gestores o administradores; la tercera, tutores o propietarios del contenido. El catálogo debe indicar canal, horario, prioridad, información necesaria y plazo. La base de conocimiento transforma casos repetitivos en autoservicio, pero debe mantenerse.

13. LEARNING ANALYTICS Y GOBIERNO DEL DATO FORMATIVO

13.1. Definición

Learning analytics es la medición, recopilación, análisis y comunicación de datos sobre alumnos y contextos con el propósito de comprender y optimizar el aprendizaje. La definición incluye propósito. Recoger eventos sin una decisión asociada produce un lago de datos costoso y arriesgado. Cada indicador debe responder a una pregunta: dónde se atascan los alumnos, qué recurso ayuda, quién necesita soporte o si la formación logra el resultado esperado.

La analítica descriptiva explica qué ocurrió; la diagnóstica busca causas; la predictiva estima resultados; la prescriptiva recomienda acciones. Cuanto más se avanza, mayores son las exigencias de calidad, explicabilidad y supervisión. Los datos de un LMS suelen estar condicionados por el diseño: una actividad no registrada puede ser pedagógicamente relevante y una interacción registrada puede ser irrelevante.

13.2. Arquitectura

El modelo de identidad debe resolver que una persona participe con distintos roles y en diferentes periodos. Los eventos necesitan zona horaria, contexto, versión del curso y significado estable. Un cambio en la forma de registrar «finalización» puede romper series históricas. Por ello los indicadores deben documentar fórmula, población, exclusiones y fecha.

13.3. Casos de uso

Un cuadro de mando operativo puede mostrar inscripciones, activación, progreso, finalización e incidencias. Un análisis pedagógico puede detectar una pregunta con discriminación negativa, un vídeo abandonado siempre en el mismo punto o un itinerario con salto frecuente. Un tutor puede recibir una alerta si se acumulan intentos fallidos, siempre que la alerta sea interpretable y facilite una acción útil.

La personalización puede recomendar refuerzo según resultados. Debe evitar etiquetar de forma permanente. La competencia es dinámica y depende del contexto. Cuando se usan datos de recursos humanos para evaluar transferencia, la finalidad y acceso deben estar claramente limitados.

13.4. Ética y protección

El principio de minimización obliga a preguntar si el dato es necesario. Los cuadros agregados pueden ser suficientes para planificación. La transparencia debe explicar qué se registra, para qué, quién accede y durante cuánto tiempo. Los modelos predictivos deben evaluarse frente a sesgos por edad, categoría, centro, discapacidad, disponibilidad horaria o brecha digital.

El derecho a aprender incluye poder equivocarse en un entorno seguro. Una analítica excesivamente punitiva reduce experimentación y participación. Los datos formativos no deben reutilizarse para finalidades incompatibles sin base y garantías. El acceso del mando debe responder a una necesidad y no convertirse en vigilancia detallada de cada clic.

14. MOOC: CONCEPTO, MODELOS, PLATAFORMAS Y LIMITACIONES

14.1. Definición

MOOC significa Massive Open Online Course: curso en línea, abierto y diseñado para participación masiva. «Masivo» implica que la metodología y la tecnología soportan un número elevado de participantes sin que la tutorización individual sea el único mecanismo. «Abierto» puede referirse al acceso sin requisitos formales o a la inscripción amplia, pero no garantiza gratuidad total, licencia abierta de contenidos ni certificado gratuito.

El término se popularizó a partir de experiencias conectivistas de 2008 y tuvo una expansión notable desde 2012 con plataformas de escala global. La masividad obliga a automatizar parte de la evaluación, utilizar foros, revisión por pares, vídeos breves y analítica. También aumenta el riesgo de abandono, participación superficial y dificultad para verificar identidad.

14.2. Tipologías

Los cMOOC se asocian al conectivismo. El conocimiento emerge de la red, la agregación y la producción de participantes; el itinerario es más abierto. Los xMOOC presentan una estructura más definida, con vídeos, actividades y pruebas, próxima al curso convencional escalado. La clasificación es analítica: muchas propuestas combinan ambos enfoques.

Los SPOC son cursos en línea privados y de alcance limitado, útiles en organizaciones. Los NOOC o nano cursos se centran en una competencia breve. Los microcredentials agrupan aprendizajes más pequeños que una titulación y pueden apoyarse en credenciales digitales. No toda formación masiva interna debe llamarse MOOC; si el acceso está restringido, «curso masivo corporativo» o SPOC puede ser más preciso.

14.3. Plataformas y arquitectura

Open edX es una plataforma de código abierto con LMS y herramientas de autor, utilizada para cursos de gran escala. Moodle puede organizar cursos masivos, aunque su arquitectura y operación deben dimensionarse. Plataformas comerciales y agregadores ofrecen catálogo, marketing, pagos y certificación. La elección depende de identidad, escala, vídeo, foros, evaluación, internacionalización, soporte y modelo económico.

La masividad requiere distribución de contenido, procesamiento asíncrono, caché, observabilidad y moderación. Los vídeos pueden entregarse mediante servicios especializados. Los foros necesitan mecanismos de búsqueda, reputación y detección de abuso. La evaluación por pares requiere rúbricas y control de consistencia. Los certificados verificados añaden identificación y prevención del fraude.

14.4. Ventajas y problemas

Los MOOC amplían acceso, permiten reutilizar docencia experta y generan comunidades internacionales. También pueden servir como puerta de entrada a itinerarios más profundos. Sus problemas incluyen tasas de finalización bajas, heterogeneidad, idioma, brecha digital, accesibilidad, sostenibilidad y reconocimiento. La tasa de finalización debe interpretarse según la intención: muchos usuarios se inscriben para consultar una parte, no para completar.

En sanidad, un MOOC puede difundir conocimiento, pero no sustituye la acreditación práctica cuando la competencia exige observación, simulación supervisada o desempeño real. La certificación debe expresar qué evidencia se obtuvo.

15. APLICACIÓN EN EL SERVICIO ANDALUZ DE SALUD

15.1. Formación continuada y GESFORMA

El Servicio Andaluz de Salud dispone de estructuras y herramientas para la formación de profesionales. La referencia corporativa que debe memorizarse es GESFORMA, cuyo objetivo oficial es la gestión de los planes de formación continuada de profesionales del SAS. Existen accesos asociados a centros y ámbitos, lo que refleja una gestión distribuida dentro del marco corporativo.

La lección técnica es importante: GESFORMA es la denominación funcional corporativa conocida. No debe afirmarse sin evidencia qué producto concreto constituye todas sus capas internas ni atribuirle integraciones no documentadas. En un tema de oposición se diferencia el servicio corporativo de las tecnologías que podrían implementarlo.

La página de formación del SAS señala que los centros sanitarios son proveedores principales y que existe formación en línea específica, además de otros proveedores dependientes de la Consejería. En 2025, el portal ayudaDIGITAL comunicó una oferta amplia de actividades y remitió a GESFORMA de Servicios Centrales, junto con videotutoriales y recursos. Este ejemplo muestra la combinación de catálogo, inscripción, contenidos y soporte.

15.2. Requisitos de un ecosistema formativo sanitario

Un ecosistema del SAS debe poder segmentar por centro, categoría, unidad, perfil y necesidad, evitando dar acceso a información no necesaria. La identidad se integra con servicios corporativos conforme a la arquitectura autorizada. Las altas, bajas y cambios organizativos requieren sincronización. Los certificados y evidencias deben conservarse de acuerdo con las reglas de formación y gestión documental.

La operación debe considerar turnos, movilidad y redes con condiciones diversas. Los cursos han de reanudarse, funcionar en navegadores soportados y ofrecer alternativas si una videoconferencia coincide con actividad asistencial. El soporte debe distinguir problemas de acceso, matrícula, contenido y evaluación. Los responsables formativos necesitan informes agregados y seguimiento de convocatorias; el acceso nominal debe ajustarse a funciones.

15.3. Casos de uso

15.4. Función del TFA-STI

El perfil TFA-STI puede participar en requisitos, arquitectura, integraciones, contratación, pruebas, explotación, soporte y seguridad. Debe traducir necesidades formativas a servicios tecnológicos sostenibles. También coordina con formación, recursos humanos, seguridad, protección de datos, accesibilidad y proveedores. Su valor no consiste en conocer todos los contenidos docentes, sino en garantizar que el sistema permita gestionarlos con rigor.

En una incidencia SCORM analizará si falla el paquete, el navegador, la API o la configuración. En una migración comprobará integridad y reconciliación. En una auditoría aportará inventario, registros, procedimientos y evidencias. En una nueva integración LTI revisará atributos, seguridad, contrato y reversibilidad. Esta visión transversal explica la inclusión del tema en un programa técnico.

16. TENDENCIAS: IA, APRENDIZAJE ADAPTATIVO, XR Y MICROCREDENCIALES

16.1. Inteligencia artificial

La IA puede apoyar generación de borradores, tutores conversacionales, recomendación, traducción, clasificación de preguntas y retroalimentación. Su uso debe estar sometido a revisión experta, especialmente en sanidad. Los modelos generativos pueden producir información plausible y falsa. No deben recibir datos personales o clínicos fuera de entornos autorizados, ni sustituir la responsabilidad del autor.

Un tutor basado en IA necesita una base de conocimiento controlada, instrucciones, límites, registro y mecanismo de escalado a una persona. La evaluación debe evitar que la herramienta facilite respuestas sin aprendizaje. Pueden diseñarse tareas que exijan justificar, contrastar fuentes, detectar errores y aplicar conocimiento a un caso.

16.2. Aprendizaje adaptativo

Los sistemas adaptativos modifican secuencia, dificultad o recomendación según evidencias. La adaptación puede basarse en reglas transparentes —si falla un objetivo, ofrecer refuerzo— o en modelos estadísticos. Debe preservarse la posibilidad de revisar el itinerario y evitar que una predicción limite oportunidades. El contenido necesita granularidad y metadatos de competencias.

16.3. Realidad extendida y simulación

La realidad virtual, aumentada y mixta permite practicar procedimientos, comunicación y decisiones. La tecnología aporta inmersión, pero no garantiza transferencia. Se necesitan objetivos, fidelidad suficiente, debriefing, evaluación y control de mareo, seguridad física y accesibilidad. xAPI resulta adecuado para registrar eventos, aunque debe definirse un perfil coherente.

16.4. Microlearning y aprendizaje en el flujo de trabajo

Las píldoras, ayudas contextuales y guías integradas acercan conocimiento al momento de necesidad. Son útiles para tareas infrecuentes o cambios de aplicación. Deben coordinarse con la documentación oficial y tener control de versión. La búsqueda y la recuperación rápida son tan importantes como el formato breve.

16.5. Microcredenciales

Las microcredenciales certifican unidades de aprendizaje menores y pueden acumularse. Open Badges 3.0 y credenciales verificables facilitan portabilidad técnica. La organización debe definir emisor, criterio, evidencia, vigencia y revocación. La apariencia digital no convierte un logro en reconocimiento oficial.

16.6. Interoperabilidad y soberanía del dato

La tendencia más estructural es pasar de una plataforma monolítica a un ecosistema interoperable. APIs, LTI, xAPI, QTI y credenciales reducen acoplamiento, pero también aumentan dependencias y flujos. La arquitectura necesita inventario, contratos de interfaz, observabilidad y gobierno de identidades. La soberanía implica capacidad de comprender, exportar y reutilizar datos sin quedar atrapado.

17. CONCLUSIONES E IDEAS CLAVE

El e-learning integra pedagogía, tecnología y gobierno. El LMS administra la oferta y la ejecución; el LCMS gestiona contenidos; el LRS almacena declaraciones xAPI; la LXP favorece descubrimiento. La arquitectura debe apoyarse en identidades corporativas, datos maestros, estándares, seguridad, accesibilidad y operación.

SCORM sigue siendo relevante para paquetes lanzados por el LMS. xAPI registra experiencias distribuidas en un LRS; cmi5 añade reglas para el lanzamiento desde un LMS. LTI integra herramientas externas; QTI intercambia preguntas; Common Cartridge agrupa recursos; Caliper normaliza eventos analíticos; Open Badges representa credenciales.

La implantación requiere gobierno, requisitos, piloto, migración, gestión del cambio y reversibilidad. El ENS se aplica según categorización; el RGPD exige finalidad y minimización; la accesibilidad afecta tanto a plataforma como a contenidos. La analítica debe conducir a acciones y respetar a las personas.

Los MOOC son cursos en línea, abiertos y masivos, pero abierto no equivale necesariamente a gratuito. En el SAS, GESFORMA es la referencia funcional para la gestión de planes de formación continuada. El TFA-STI debe ser capaz de relacionar esta necesidad corporativa con arquitectura, integración, contratación, seguridad, soporte y datos.

• LMS: gestión de usuarios, matrículas, cursos, actividades, evaluación e informes.
• SCORM: paquete y ejecución interoperable en el LMS.
• xAPI: statements JSON hacia un LRS.
• cmi5: perfil xAPI para contenido lanzado por LMS.
• LTI: integración segura de herramientas externas.
• QTI: intercambio de pruebas e ítems.
• MOOC: masividad y apertura, con retos de apoyo y finalización.
• GESFORMA: gestión de planes de formación continuada del SAS.

18. MAPA CONCEPTUAL