What you need before you start:

To use the Hub Testing Integration System (HITS), you'll need the following:

You'll also need a basic knowledge of SIF REST:

You need to know how to work with a usecase in HITS and access the HITS API

If you get stuck: drop us a line at info@nsip.edu.au

How to implement third party timetable provision

1. What's the business problem?

Allow schools to securely provide SIS information to the Timetabling product of their choice, and also to allow timetable records (including teaching groups and scheduled activities) to be published to a jurisdictional data hub.

More...

2. Usecase description & pre-conditions

A third party timetabling application connects to HITS as a jurisdiction hub, collecting the relevant information and publishing back timetable records to the centralised system.

Assumptions:

A third party vendor is a current supplier of a timetabling product in schools or has knowledge of timetabling and scheduling processes in K-12 Schools.

Pre-Conditions:

Here is more information on the Timetable Baseline Profile.

Usecase workflow summary:

  1. Join
  2. Consume
  3. Process
  4. Provide
  5. Assurance

Assurance:

The SIF/XML data sent by the third party app to the jurisdiction zone for the app must be able to provide all the following records within a school:

The SchoolCourseInfo object is only required if the Timetabling application will record the link between the School Course offering (as distinct from the Timetable Subject) and the Teaching Group. This link is optional, and application developers should check with the School Authority on whether they need to provide it.

The ScheduledActivity object is designed for student activities that do not involve classroom instruction, and/or that are not recurring; e.g. excursions. They do not need to be implemented by a TimeTablingApplication (and in fact they relate to scheduling rather than timetabling); application developers should check with the school authority on whether they need to provide it.

More...

3. Join school zone.

4. Consume base data from HITS.

Vendor-facing (pull); HITS represents the Jurisdiction and is the data source for seed information.

Consume:

On the jurisdiction-established zone for the app, third party app accesses: - all StudentPersonal records which are in a StudentSchoolEnrollment relationship with the given School RefId - all StaffPersonal records which are in a StaffAssignment relationship with the given School RefId - all RoomInfo objects linked to the given School RefId. - all TimeTableSubject objects linked to the given School RefId. - all SchoolCourseInfo objects linked to the given School RefId. (optional)

Third party app ingests the relevant SIF objects.

  1. Get SchoolInfos: http://.../SchoolInfos
  2. Get StudentSchoolEnrollments: http://.../StudentSchoolEnrollments
  3. Get StudentPersonals: http://.../StudentPersonals (linked to school via StudentSchoolEnrollment; equivalent to http://..../SchoolInfo/{REFID}/StudentSchoolEnrollments/{REFID}/StudentPersonals).
  4. Get StaffAssignments: http://.../StaffAssignments
  5. Get StaffPersonals: http://.../StaffPersonals (linked to school via StaffAssignment; equivalent to http://.../SchoolInfo/{REFID}/StaffAssignments/{REFID}/StaffPersonals).
  6. Get RoomInfos: http://.../RoomInfos
  7. Get TimeTableSubjects: http://.../TimeTableSubjects
  8. Get SchoolCourseInfos: http://.../SchoolCourseInfos

Endpoints may support additional queries for retreiving data - refer to Query-by-example or service paths? for HITS guidance on queries.

5. Process in third party application.

The third party app uses the consumed data to produce a timetable. The definition and automation of this process is out of scope of HITs.

Steps:

6. Provide authoritative data

Prior to providing:

Third party expresses return information in SIF/XML:

7. Self – confirm  usecase support

Validate:

  1. TimeTable records
  2. TimeTableCell records
  3. TeachingGroup records
  4. ScheduledActivity records

More information

What business problem does this usecase address?

In brief:

Schools currently use third-party timetabling apps locally to supplement their Student Information System (SIS). The seed information for generating timetables is held in the School's SIS and usually exported locally with little security. 

As jurisdictions centralise systems, third party vendors have the opportunity to seed their product/s from a quality assured data hub using automated feeds, rather than manual updates from the school. Third party vendors are also expected to provide information directly back to the centralised system through an automated feed, rather than having the information mediated through the school. 

This use case shows how third party vendors can connect to a centralised data hub to securely access to the required information and publish back the timetable records to the centralised data hub.

Usecase preconditions for assurance

For the purposes of validation, a new TeachingGroup object is well-formed if:

  1. All mandatory elements of the TeachingGroup object are provided.
  2. The TeachingGroup contains a TeachingGroupPeriodList.
  3. The TeachingGroupPeriodList references either TimeTableCellRefId, or a combination of RoomNumber, DayId, and either PeriodId or StartTime
  4. The TeachingGroup must contain a StudentList. The Students referenced in the StudentList must have StudentPersonal RefIds and Names corresponding to those supplied in provisioning.
  5. The TeachingGroup must contain a TeacherList. The Teachers referenced in the TeacherList must have StaffPersonal RefIds and Names corresponding to those supplied in provisioning.
  6. The TeachingGroup must reference a SchoolInfo RefId. 

For the purposes of validation, a new TimeTableCell object is well-formed if it satisfies the following requirements:

Relevant Service Paths Supported on HITS

Relevant Queries By Example Supported on HITS