Synopsis

This document proposes an API structure for sourcing classroom data on student performance from Learning Management Systems (LMSs). The API surface is a "write" API with CRUD-based methods that a LMS provider would call to perform near real-time data transfer, either on a periodic basis or in response to specific system events.

The LMS data elements represented in the API are ones identified by the Ed-Fi Learning Management Systems Data and Analytics Special Interest Group as most critical and most useful to assessing student progress on coursework and providing instructors and related school staff with actionable insights on intervention opportunities, and generally track the ability of a teacher to recognize a disengaged learner or a learner struggling to complete coursework.

Contents

General Discussion 

Evolution of LMS Systems in K12

Learning Management Systems systems have long been a part of school district technology offerings and have long been integrated into the process of educating students at the classroom level, but the scope and regularity of usage has increased considerably in recent years.

These systems initially emerged as important tools in many critical but peripheral use cases and areas of K12, such as virtual schooling, online courses designed to expand course catalog offerings, and credit recovery programs. Deployments of LMS systems were slow to spread from those use cases, and access and use of a LMS was far from universal across K12 schools and even within school districts. Likewise, even where there was access, teacher training and norms and policies for usage have often been missing, leading to LMS usage that was low and inconsistent, both across school districts and within them. 

Over time, school districts have been working on these issues and building capacity for effective LMS system usage at scale: usage has become more common, more clearly defined in terms of process, and more valuable in classroom instruction. The COVID-19 pandemic accelerated this process massively, as LEAs quickly pivoted to online learning at scale.

The outcome of this evolution is that LMS data has become a valuable source of information on student progress. The Learning Management Systems API surface proposes a standard transmission mechanism for important LMS data, so that the data can be integrated into analytics and decision-making processes for classroom instructors and others who need to understand student academic process and intervene effectively.

Data Model

Assignment Focus

Important to design of the API was the question of which LMS data is most important. This question was a large focus of the Ed-Fi Learning Management Systems Data and Analytics Special Interest Group (SIG).

The Ed-Fi SIG observed that assignment data is likely the strongest initial focus point, for these reasons:

• Assignment workflow data is a very "core" classroom process, and so is carefully managed and therefore a useful indicator of student performance

• There is great similarity in assignment workflows across K12 generally, so the opportunity to use the data has more scale

• An analysis of LMS systems and their data models reflected these data and process similarities

On the second bullet, the SIG reflected at length on the use of more general "activity" data from the LMS. While activity data may be a better leading indicator of factors like student engagement, it is often platform-specific and open to platform interpretation.

For example, an activity element like a "student login to the LMS" (which seems semantically clear) acquires a platform-specific flavor when you consider the usage of a LMS on a computer vs on a mobile device, where login credentials may be cached for extended periods of time. Similarly page counts or similar view counts may be misleading, misinterpreted, or impacted by configuration the student technology devices themselves.

The highly transactional nature of assignments and the common K12 workflows around these have made them the proposed starting point for this API.

Representing the Concept of an "Assigned Assignment"

Different systems have different approaches to noting if an assignment was assigned to a particular student.

In some cases, there was no concept or representation of if an assignment was assigned to a particular student. In such cases, there is likely a default assumption that the assignment applies to all students in the section, e.g., "Assignment X is for all students in section Y"

However, the more common pattern was to explicitly call out that an assignment was assigned to a student, as in "Assignment X was assigned to student A." Although arguably the concept of an "assigned assignment" deserves its own data model representation, the most common pattern to representing this concept within source systems was to create an "empty" assignment submission for the student and assign it a workflow status indicating the assignment.

The API therefore adopts this pattern via a normative requirement (see section ED-FI WORKING DRAFT 9 - LEARNING MANAGEMENT SYSTEMS API#OtherNormativeRequirements below) that the API client provide a "empty" assignment submission with the proper workflow status (SubmissionStatusDescriptor) for all instances of assignment, whether assumed or explicit.

Workflow Diversity

In analyzing existing LMS systems, a number of variations in workflows for assignment submissions were observed. While there were many similarities, different systems layered over individualized stages and semantics.

For example, a workflow might make a distinction between a submission that was "in draft" vs one that was simply "new." Likewise, there were variations like the distinction that an assignment had been "returned" to the student vs one that had been "reclaimed" by the student. These variations were platform specific and not universal.

The API therefore takes a strategy of allowing for variation in capturing workflows statuses, via provider-specific values for SubmissionStatusDescriptor.

Use Cases

• As a teacher or building-level educator, I want to assess the level of student engagement and student performance in course work and combine this data with data from other key systems (such as SIS and assessment data) in order to support teachers and administrators in making the best possible decisions about the needs of and intervention options for individual students. 

API Surface

Open API Specification

OpenAPI file: Working-Draft-9-LMS-API.json

Swagger view:

Other Normative Requirements

Systems creating an assignment MUST create and manage an AssignmentSubmission for each individual student to whom the assignment was assigned. When initially created, that AssignmentSubmission is essentially a placeholder denoting assignment   Users of the data are to interpret that the lack of a AssignmentSubmission for a Student for an Assignment means that the Assignment was NOT assigned to the Student.

Descriptors