![](/sites/default/files/AppNoteHeader.png)
Proposal to Extend 1EdTech OneRoster® to include Student Course Requests
Contributed by: Ryan Triggs, Head of Engineering, Abl Schools
Introduction
Abl is a master scheduling solution that helps address equity and access to ensure every student is college and career ready. The master schedule enables district and school leaders to make strategic changes that optimize conditions for teaching and learning. These changes help ensure that students have access to the courses they need, offered at the most optimal times and locations with the best teachers.
Creating a student-centered master schedule is a challenging process and requires reliable access to course, student, staff, course request, roster, and bell schedule data. 1EdTech Consortium's
OneRoster 1.1 provides an effective way to exchange roster and course information but does not currently support student course requests. Student course request data is central to making more strategic student scheduling decisions. This proposal describes how extending the specification to include course request information supports more scheduling innovation—ensuring students are getting access to the courses they need.
Background
Abl offers a master scheduling solution for middle and high schools. Before building the master schedule, student course requests are typically collected via the Student Information
![Abl Always Be Learning logo](/sites/default/files/memberlogos/ABL%20logo.png)
System (SIS) and then audited. To effectively build a master schedule in Abl, it is critical to have the most up to date and correct course requests. This requires custom mapping rules to translate the SIS course request data model to Abl's as well as frequent pulls from the SIS—typically via their
API1 or CSV extracts. Currently, Abl has to create custom integrations for every SIS to extract course request data.
Once course request data has been loaded into Abl, additional auditing happens via the master schedule. This makes it easier to see what course requests are fulfilled or where there are opportunities to fulfill them.
![Abl Master Schedule image](/sites/default/files/AblAppNote-Schedule.png)
![Abl Course Requests image](/sites/default/files/AblAppNote-CourseRequests.png)
Alternatively, course request data and student data can be used to guide automated rostering of students. By specifying rules for the prioritization of course requests, students can be assigned to the appropriate classes quickly and strategically.
For example, Oakland
Measure N Initiative creates pathways that expose students to more career-focused coursework and helps prepare them for the future. To ensure that students in each pathway are getting placed in the correct classes requires more sophisticated scheduling. In addition to understanding which students, classes, and staff are associated with a given pathway, many Oakland schools also want to factor in a number of other preferences and constraints to ensure students get access to what they need, such as course request priority, transcript data, and special program designations like special education and English language learning.
Abl partnered with Aeries to create new APIs that exposed more rich student data so Oakland could leverage Abl’s scheduling solution to meet its dynamic scheduling needs.
Extending the Specification
Adding student course request information to OneRoster would:
- Reduce the need to integrate with custom SIS APIs or extracts
- Enable more scenarios where course requests are audited and managed
- Support more innovation around the automated scheduling of students and staff
Below are proposed extensions to the OneRoster standard to include these course requests:
Data Elements for Course Requests
Data Element Name |
Multiplicity |
Notes |
sourcedId |
1 |
For example: 9877728989-ABF-0001 |
enrollment |
1 |
Link to enrollment i.e., the Enrollment 'sourcedId'. |
course |
1 |
Link to course i.e., the Course 'sourcedId'. |
isAlternate |
1 |
Boolean ("true" | "false") |
dateLastModified |
1 |
For example: 2012-04-23T18:25:43.511Z |
*At the time of this writing, there needs to be more discussion about how course request designation (primary course requests, alternate course requests, etc.) and other rules that enable smart ways to prioritize fulfilling course requests.
HTTP Endpoints for Course Requests
Service Call |
Endpoint |
HTTP Verb |
Action |
getAllCourseRequests |
/courseRequests |
GET |
Return the collection of all courseRequests |
getCourseRequestsForSchool |
/schools/{school_id}/courseRequests |
GET |
Return the collection of all courseRequests for this school |
getCourseRequestsForEnrollment |
/enrollments/{enrollment_id}/courseRequests |
GET |
Return the collection of all courseRequests for this school |
getCourseRequestsForCourse |
/courses/{course_id}/courseRequests |
GET |
Return the collection of all courseRequests for this school |
A Call for Action
The inclusion of course request data in the OneRoster standard enables some exciting possibilities. Working together with software providers in the market to define a common data model will remove barriers to understanding equity and access across student populations and accelerate innovation in creating more strategic master schedules.