Guide on modern eLearning standards: what to use and why it matters

The number of eLearning platforms, tools, and content providers is increasing every year. Most institutions no longer rely on a single system. They use a mix of learning management systems, assessment tools, content libraries, and analytics platforms.

This creates a practical problem. Each system stores data in its own format. User accounts, course progress, grades, and activity records do not move between systems by default. As a result, teams either manage data manually or invest in custom integrations that are costly to build and maintain.

Industry standards address this problem. They define how systems exchange data, launch external tools, and track learning activity. When these standards are applied correctly, platforms can share information without custom connectors for each new tool.

However, not all standards serve the same purpose. Some focus on content packaging. Others define how applications connect or how learning data is recorded and analyzed. Choosing the wrong approach can limit future system changes or increase integration costs.

This article reviews the key eLearning standards used in modern platforms. It explains what each standard does, when to use it, and how it affects system design. It also reflects how these standards are applied in real development projects.

Modern learning platforms rarely operate in isolation. An LMS often connects to external tools for content delivery, assessments, and analytics. These connections need a consistent way to authenticate users, launch tools, and exchange data. This is where standards from the 1EdTech Consortium, previously known as IMS Global, are used.

LTI (Learning Tools Interoperability)

LTI (Learning Tools Interoperability) defines how a learning management system (LMS) connects to external learning tools. It allows a user to open a third-party application directly from the LMS without creating a separate account.

A typical example is an LMS connected to an external assessment platform. A student clicks a link inside the LMS and is logged into the external tool automatically. The system passes user identity and context during the launch.

LTI 1.3 is the current version used in production systems. It relies on modern security protocols such as OAuth 2.0 and JSON Web Tokens. Earlier versions are still present in legacy systems but are gradually being replaced.

LTI supports three key functions:

• Single sign-on (SSO): Users access external tools without separate credentials
• Context sharing: The LMS passes course and user data during launch
• Standardized links: External tools can be reused across different LMS platforms

LTI Advantage extends the base specification. It adds services that handle grades, content selection, and role provisioning. These services reduce the need for custom API integrations.

When to use LTI

Use LTI when an LMS needs to connect to external tools such as:

• Assessment platforms
• Content libraries
• Virtual labs
• Video learning systems

LTI is not designed for full data synchronization between systems. It focuses on launching tools and exchanging session-level data.

Deep Linking and Grade Return

Deep Linking and Grade Return (Assignment and Grade Services) are part of LTI Advantage. They address two common integration tasks.

Deep Linking allows instructors to select specific content from an external tool and insert it into an LMS course. The selection happens inside the tool, but the result appears as a native LMS link.

Grade Return sends assessment results from the external tool back to the LMS gradebook. This removes the need for manual grade entry or custom data pipelines.

These features are often required in real projects. Without them, integrations remain partial and require additional development.

Read our guide on integrating LMS content using LTI Deep Linking.

QTI (Question and Test Interoperability)

QTI defines how assessment content is structured and exchanged. It focuses on questions, tests, and scoring data.

A typical use case is moving a test bank from one system to another. QTI ensures that questions, answers, and scoring rules are preserved during this transfer.

QTI uses XML to describe assessment data. This makes the format predictable but also more rigid compared to modern API-based approaches.

QTI supports:

• Question and test structure
• Response processing and scoring rules
• Result reporting in a consistent format

When to use QTI

Use QTI when:

• Migrating assessment content between systems
• Importing large question banks into an LMS
• Working with platforms that require standardized test formats

QTI is still widely supported, especially in K–12 and higher education. However, it is often combined with LTI rather than used alone. LTI handles the connection between systems, while QTI defines the structure of the assessment content.

These protocols are often used together in a single system. For example, an LMS may use LTI to launch an external assessment tool, Deep Linking to select content, Grade Return to capture results, and QTI to import question banks.

The choice is not between these standards. The task is to combine them correctly based on system requirements.

These standards define how learning content is delivered and how user activity is tracked. They directly affect reporting, analytics, and future system flexibility.

SCORM

SCORM defines how eLearning content is packaged and launched inside an LMS. It is still widely used, especially in corporate training and legacy systems.

A SCORM course is delivered as a ZIP package. It contains:

• Content files (HTML, media, scripts)
• A manifest file that describes structure and metadata

When uploaded to an LMS, the platform reads the manifest and renders the course structure.

SCORM also defines a runtime layer. This allows the course to send basic data to the LMS, such as:

• Completion status
• Scores
• Time spent

Limitations of SCORM

SCORM works reliably, but it was designed for browser-based learning. It has several constraints:

• Tracks only limited types of user activity
• Depends on LMS session and browser context
• Does not support offline learning or external systems well

These constraints affect reporting quality and system design.

When to use SCORM

Use SCORM when:

• You need compatibility with existing LMS platforms
• Your content is course-based and browser-driven
• Advanced analytics is not required

In many projects, SCORM is kept for legacy content rather than new development.

xAPI (Experience API)

xAPI defines how learning activity is recorded across systems. It is not limited to a single LMS.

Instead of tracking only course completion, xAPI records detailed user actions. Each action is stored as a statement, for example:

• “User completed module”
• “User watched video”
• “User passed assessment”

These records are stored in a Learning Record Store (LRS).

This approach allows tracking across:

• Mobile applications
• External tools
• Offline activities
• Simulations and real-world tasks

Why xAPI matters now

Modern learning systems rely on data from multiple sources. xAPI allows these sources to report activity in a consistent format.

This data is then used for:

• Learning analytics
• Progress tracking across platforms
• Input for recommendation systems and AI models

Without a standard like xAPI, this data remains fragmented.

When to use xAPI

Use xAPI when:

• You need detailed tracking beyond course completion
• Learning happens outside a single LMS
• Analytics or personalization is part of the system

cmi5

cmi5 connects SCORM-style content with xAPI tracking. It was designed to solve a practical problem: how to keep structured courses while using modern tracking.

It defines:

• How content is launched from an LMS
• How xAPI statements are structured in that context

This makes it possible to:

• Reuse SCORM-like courses
• Store activity in an LRS
• Avoid SCORM runtime limitations

When to use cmi5

Use cmi5 when:

• You are migrating from SCORM to xAPI
• You need structured courses with improved tracking
• You want a standard launch mechanism with modern data collection

These standards define how systems exchange operational data such as users, enrollments, and academic records. They are critical for automation and system consistency.

OneRoster (1EdTech)

OneRoster defines how student, staff, and enrollment data is shared between systems such as SIS and LMS.

Without a standard, this data is often:

• Entered manually
• Duplicated across systems
• Inconsistent over time

OneRoster addresses this by defining a common data model and exchange format.

It supports CSV-based data import and REST API for real-time integration.

Typical data includes:

• Students and teachers
• Class rosters
• Course enrollments
• Grades

Practical impact

With OneRoster:

• Class rosters are created automatically
• Teachers assign work to entire groups instead of individuals
• System setup time is reduced

See how we applied Roster-based integration standards to connect LMS and SIS platforms in a real-world implementation.

When to use OneRoster

Use OneRoster when:

• Integrating LMS with SIS
• Managing large numbers of users and classes
• Reducing manual data handling

Ed-Fi

Ed-Fi defines a broader data model for educational systems. It focuses on how data is structured and shared across an entire ecosystem, not just between two systems.

It covers domains such as:

• Student records
• Attendance
• Assessments
• Schedules and calendars

Unlike OneRoster, which focuses on data exchange, Ed-Fi defines how data should be organized.

Why Ed-Fi matters

In complex environments, data comes from multiple systems. Without a shared model:

• Reporting becomes inconsistent
• Analytics require custom transformations
• System changes increase costs

Ed-Fi reduces this problem by standardizing data structure.

When to use Ed-Fi

Use Ed-Fi when:

• Building a data platform across multiple systems
• Implementing analytics or reporting layers
• Working in K–12 environments with defined data requirements

Most platforms do not rely on a single standard. They combine several, each solving a specific task. The challenge is not understanding the standards in isolation, but selecting the right combination for an exact system.

A useful way to approach this is to look at what the platform needs to support.

If your focus is course delivery

If the platform delivers structured courses inside an LMS, SCORM is often already in place. It remains a practical option when compatibility with existing content is required.

However, for new systems, SCORM is rarely enough. It limits tracking and makes it harder to extend the platform later.

In these cases, cmi5 is a more flexible option. It keeps the course-based structure while allowing detailed tracking through xAPI.

If your platform includes multiple tools

When content, assessments, or simulations are provided by different vendors, LTI becomes necessary. It allows these tools to be launched from the LMS without separate authentication.

In most cases, LTI 1.3 with Advantage services is used. It supports content selection and grade return without custom development.

Without LTI, each integration becomes a separate project. This increases cost and slows down further changes.

If you need detailed tracking and analytics

When the platform requires more than completion data, xAPI should be part of the architecture.
It allows tracking across systems and stores activity in a format that can be reused for reporting or analytics. This is especially relevant for platforms that plan to introduce recommendation features or performance analysis.

If xAPI is not included from the start, adding it later often requires changes in multiple parts of
the system.

If your system depends on academic data

When the platform integrates with an SIS or manages large user groups, OneRoster simplifies data exchange.

It automates the transfer of users, classes, and enrollments. This reduces manual setup and prevents data inconsistencies.

If the system also requires centralized reporting across multiple platforms, Ed-Fi can be used to standardize how data is structured.

A typical combination

In many projects, the final setup looks like this:

• LTI connects external tools
• xAPI collects activity data
• cmi5 or SCORM delivers structured courses
• OneRoster manages users and enrollments

This combination supports both day-to-day operations and future extensions.

AI is now a standard requirement in many learning platforms. Product teams expect features such as recommendations, adaptive paths, and performance analysis. These features depend on data, not only on models.

This is why it makes sense to look at e-Learning standards from a different angle. They do not add AI capabilities by themselves, but they define what data the system can collect and reuse.

What changes when AI is introduced

In a basic LMS setup, the system usually tracks completion, scores, and time spent. This works for reporting, but it leaves gaps. It does not show how a learner interacts with content or where they face difficulties.

AI features require more detailed input. For example, a recommendation system needs to know which topics were skipped or repeated. A risk detection model needs to see patterns over time, not just final results.

Standards such as xAPI make this possible. They record user actions as structured events and store them in a Learning Record Store. This creates a dataset that can be used across different tools and services.

Example: from basic tracking to usable data

Consider two similar platforms:

• The first one uses SCORM only. It knows that a learner completed a course and scored 80 percent. Based on this, the system can suggest the next course in a predefined sequence.
• The second platform uses xAPI. It tracks which questions were answered incorrectly, how long the learner spent on each section, and where they stopped. Based on this data, the system can recommend specific modules or repeat certain topics.

The difference is not in the interface. It is in the data available for decision-making.

Data across multiple tools

Most learning environments include several systems. Content delivery, assessments, and simulations are often handled by different tools.

LTI allows these tools to be launched from the LMS and used within a single workflow. xAPI collects activity data from each of them. This combination creates a consistent record of user activity, even when learning happens outside the LMS.

Without this setup, each system keeps its own data. This makes it difficult to combine results or apply analytics across the full learning process.

What to plan in advance

AI features are often added after the initial release. At that stage, teams may find that the system does not collect enough data for meaningful analysis.

To avoid this, standards should be selected with future use in mind. xAPI supports detailed tracking. cmi5 allows structured courses with the same level of data collection. LTI connects external tools that generate additional data.

These decisions affect how easily new features can be added later.

Understanding standards is not the difficult part. Most issues appear during implementation. Here are the typical challenges you may encounter:

Treating standards as interchangeable

Each standard solves a specific task. SCORM handles course packaging. LTI connects tools. xAPI records activity.

Problems start when one standard is expected to cover multiple roles. For example, using SCORM for advanced analytics or relying on LTI for full data synchronization. This leads to gaps that are discovered only after release.

Adding standards too late

In some projects, standards are introduced after the platform is already built. At that point, data structures and integrations are fixed.

Adding xAPI tracking or LTI connections later often requires changes across multiple components. This increases cost and delays new features.

Planning these elements early avoids rework.

Inconsistent data structure

Even when standards are used, data can still be inconsistent. For example, activity tracked via xAPI may not match course structure defined in the LMS. This creates problems in reporting and analytics.

A consistent data model across systems is required, especially when multiple tools are involved.

Over-reliance on custom integrations

Some teams build direct integrations between systems instead of using standards. This may work for a small number of tools.

As the platform grows, each new connection requires additional development and maintenance. Over time, this becomes difficult to manage.

Standards reduce this dependency by providing predictable integration points.

Standards define how systems connect. The result depends on how they are applied in a specific platform. In our work, this is handled as a sequence of decisions rather than a one-time setup.

Step 1. Define how the system will be used

We start with usage, not technology.

We look at how content is delivered, which tools are involved, and what kind of data needs to be collected. This includes reporting requirements and possible extensions such as analytics or AI features.

This step sets the direction for all technical choices.

Step 2. Assign standards to clear roles

Each standard is selected for a specific task. LTI is used for tool access. xAPI is used for activity tracking. OneRoster handles user and enrollment data.

This prevents overlap and avoids situations where one standard is forced to solve multiple problems.

Step 3. Define the data structure early

Data consistency affects everything that comes later. We define how learning activity, users, and results are structured across systems. This ensures that tracking, reporting, and integrations work without conflicts.

If this step is skipped, issues usually appear when analytics or new features are added.

Step 4. Limit custom integrations

Whenever possible, we rely on existing standards instead of building direct connections. This reduces development effort and makes it easier to add or replace tools later. Most modern platforms already support LTI or xAPI, which allows faster integration.

Step 5. Plan for change

Learning platforms change over time. New tools are added. Reporting requirements grow. Features expand.

The architecture should support these changes without requiring major rework. Standards make this possible, but only if they are applied correctly from the start.