What you need before you start:

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

• A HITS testing account - apply from the Request an account section of the HITS Dashboard.
• This will give you access to your own testing environment 
• Your testing environment will provide you with all necessary authentication and access tokens to work with the HITS API.

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

• Here is some information from the SIF Association.
• Here is a short (1-day) course in developing with SIF 3 REST.

You need to know how to work with a use case 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 Student Attendance Timelist Recording

1. What’s the business problem?

Allow schools to securely provide SIS information to the Attendance product of their choice, and also to allow school attendance records to be published to a jurisdictional data hub, recording attendance at an arbitrary degree of granularity.

More…

2. Use Case Description & Pre-Conditions

A 3rd Party Attendance application connects to HITS as a jurisdiction hub, collecting the relevant information and publishing back attendance records (at an arbitrary degree of granularity) to the centralised system.

Timetable Attendance conceptual diagram

This conceptual diagram contains interactions beyond this specific technical use case, and is included for context.

Timetable Attendance SIF objects

Diagrams the interactions between SIF objects for this use case.

Assumptions:

3rd Party Vendor is a current supplier of a Student Attendance product in schools or has knowledge of Student attendance reporting processes in K-12 Schools.

Pre-Conditions:

• Vendor has access to HITS
• HITS has been provisioned with School Data
• Vendor has mapped the relevant SIF Objects to their systems:
  • StudentPersonal
  • StudentSchoolEnrolment
  • CalendarDate
  • CalendarSummary
  • StudentAttendanceTimeList
  • RoomInfo
  • TimeTableSubject
  • TimeTableCell
  • ScheduledActivity
  • SessionInfo (optional)
  • SchoolInfo (SchoolInfoRefId is mandatory for ScheduledActivity objects.)
  • StudentSchoolEnrollment, Staff Assignment (if clients interact only with a single-school zone, mapping these objects is not necessary. See School Zone Objects.)

Here is the XSD schema for SIF 3.4.3, and a detailed description of the Attendance Baseline Profile.)

3. Use case workflow

Workflow summary:

3.1. Join

3.2. Consume

3.3. Process

3.4. Provide

3.5. Assurance

3.1. Join required School Zone.

• Third party app connects to Jurisdiction-established Zone for the School (“HITS Zone 1”)
• Third party app authenticates to Jurisdiction-established Zone for the School (“HITS Zone 1 Authz”)
• Jurisdiction Zone authorises read access to objects in the Jurisdiction Zone for the School (“HITS Zone 1 Authn”)

3.2. 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.
• on the Jurisdiction-established Zone for the App, Third party app accesses all CalendarSummary objects linked to the given School RefId, and all CalendarDate objects linked to the given CalendarSummary objects. (The calendar objects are only used to identify which days of the school year students are expected to attend school; they are not otherwise referenced by return objects. Typically in a Student Attendance Timelist deployment, the calculation of attendance fractions is done centrally, so it is not essential for Attendance applications to know ahead of time whether a given day is a day when attendance is required.)
• Depending on the granularity of reporting, the third party app may choose to access the following objects, which can optionally be referenced by the StudentAttendanceTimeList object: ScheduledActivity, and either TimeTableSubject, TimeTableCell, StaffPersonal, or SessionInfo. (The information in SessionInfo, which aligns period attendance to the timetable, is replicated by the other optional objects, and the two groups of objects should be considered as redundant to each other.)
• Third party app ingests the relevant SIF Objects.

The following is a list of calls that need to be made to consume the required information:

1. Get SchoolInfos - http://.../SchoolInfos  (HITS should determine the URLs eg http://hits.nsip.edu.au/SchoolInfos - access this information from your Dashboard.)
2. Get StudentPersonals -  http://.../StudentPersonals (linked to school via StudentSchoolEnrollment; eg: equivalent to  http://.../SchoolInfo/\\{REFID}/StudentSchoolEnrollments/{REFID}/StudentPersonals)
3. Get CalendarDates - http://.../CalendarDates
4. Get TimeTableSubjects -  http://.../TimeTableSubjects
5. Get TimeTableCells -  http://.../TimeTableCells
6. Get ScheduledActivitys -  http://.../ScheduledActivitys
7. Get StaffPersonals -  http://.../StaffPersonals
8. Get SessionInfos -  http://.../SessionInfos

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

NOTE: The “Attendance” option for database generation in the HITS Dashboard applies to both the Basic Daily Attendance use case and the Student Attendance TimeList use case.

3.3. Process in 3rd Party Application.

3rd Party App uses the consumed data to produce a schedule. The definition and automation of this process is out of scope of HITS.

Steps:

• Third party app processes information and gathers Student Attendance Information
• Third party application creates return Student Attendance Timelist objects specific to the School

3.4. Provide Authoritative Data

Prior to providing:  

  Third party expresses return information in SIF/XML:

• Third party app connects to Jurisdiction-established Zone for the School (“HITS Zone 1”)
• Third party app authenticates to Jurisdiction-established Zone for the School (“HITS Zone 1 Authz”)
• Jurisdiction-established Zone authorises write access to objects in the Jurisdiction Zone for the School (“HITS Zone 1 Authn”)
• Following is provided by the 3rd Party App back to HITS;
  3. Post StudentAttendanceTimeList to http:// .../StudentAttendanceTimeLists

3.5. Assurance: Self – Confirmation of Use Case Support

1. Validate StudentAttendanceTimeList records

The SIF/XML data sent by the 3rd Party app to the Jurisdiction Zone for the app must satisfy the following conditions:

• Any SIF object published by the App must be valid against the SIF-AU 3.4 schema
• All mandatory elements of the submitted SIF objects are provided
• All SIF objects posted by the Attendance App must have referential integrity. Any RefId contained in the SIF object must refer to a SIF object provisioned to the App—e.g. SchoolInfo, StudentPersonal, RoomInfo).This condition applies recursively to all additional SIF objects posted by the App. The test of this condition is done only when the App indicates that it has finished publishing to the Zone the objects required for the test.

NOTE: The “Attendance” option for validation in the HITS Dashboard applies to both the Basic Daily Attendance use case and the Student Attendance TimeList use case.

More…

More information…

What business problem does this use case address?

In brief:

• Allow schools secure access to SIS information
• Allow schools to use the Attendance product of their choice
• Allow 3rd  Party Attendance apps automated access to base information
• Allow 3rd  Party Attendance apps to publish school attendance records to a jurisdictional hub, at an arbitrary level of granularity (including both daily and period).

Schools currently use third-party attendance applications locally to supplement their Student Information System (SIS). The seed information for recording of attendance is held in the School’s SIS and usually exported locally with little security.

As jurisdictions centralise systems, 3rd 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. 3rd  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 3rd  party attendance vendors can connect to a centralised data hub to securely access to the required information and publish back Attendance records to the centralised data hub.

The SIF-AU specification provides separate objects that capture attendance at the granularity of the day or half-day (StudentDailyAttendance), and at the granularity of individual periods (StudentPeriodAttendance). Neither option is catered for in this use case: this use case instead uses the StudentAttendanceTimeList object to capture arbitrary start and end points for attendance during the day, with optional links to periods. The BasicDailyAttendance use case uses the StudentDailyAttendance object. Because of lack of demand to date, no HITS use case currently uses StudentPeriodAttendance.

Use case preconditions for assurance

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

• All mandatory elements of the StudentAttendanceTimeList object are provided.
• The StudentAttendanceTimeList object points to a valid StudentPersonal and SchoolInfo object.
• Where provided, the StudentAttendanceTimeList points to valid RoomInfo, TimeTableSubject, SessionInfo, ScheduledActivity, TimeTableCell, and/or StaffPersonal objects.

The following additional requirements will be expected in production, but are not performed by HITS:

• The start times and end times reported for each attendance timespan should not overlap
• The absence value of the attendance timespan should be derived from the start time and end time by a consistent calculation
• The TimeTablePeriod value reported for a period attendance timespan should correspond to a value used in the school timetable
• The date for a period attendance timespan should match the date of the entire StudentAttendanceTimeList object
• The Start Time and End Time for a period attendance timespan should match the start and end time defined for a period in the school timetable

Relevant Service Paths Supported on HITS

• StudentPersonals/{}/StudentAttendanceTimeList
• SchoolInfos/{}/StudentAttendanceTimeList
• SchoolInfos/{}/StudentPersonals/{}/StudentAttendanceTimeLists
• SchoolInfos/{}/StudentPersonals
• SchoolInfos/{}/StudentSchoolEnrollments

Relevant Queries By Example Supported on HITS

<SchoolInfo>
    <LocalId>{schoolCode}</LocalId>
</SchoolInfo>

<StudentPersonal>
  <LocalId>{id}</LocalId>
  <PersonInfo>
    <Name>
      <FamilyName>{familyName}</FamilyName>
      <GivenName>{givenName}</GivenName>
    </Name>
  </PersonInfo>
</StudentPersonal>

<StudentSchoolEnrollment>
  <TimeFrame>{type}</TimeFrame>
  <YearLevel><Code>{yearlevel}</Code></YearLevel>
</StudentSchoolEnrollment>

<StudentAttendanceTimeList>
  <StudentPersonalRefId>{refid}</StudentPersonalRefId>
  <Date>{date}</Date>
  <SchoolYear>{year}</SchoolYear>
</StudentAttendanceTimeList>

<CalendarDate>
  <Date>{refId}</Date>
  [<CalendarSummaryRefId>{refId}</CalendarSummaryRefId>]
  <CalendarDateType><Code>{DateType}</Code></CalendarDateType>
  <StudentAttendance><CountsTowardsAttendance>{bool}</CountsTowardsAttendance></StudentAttendance>
</CalendarDate>

<RoomInfo>
  <LocalId>{id}</LocalId>
  <RoomNumber>{number}</RoomNumber>
  <Capacity>{capacity}</Capacity>
</RoomInfo>

<TimeTableSubject>
  <SubjectLocalId>{id}</SubjectLocalId>
  <AcademicYear>{year}</AcademicYear>
  <AcademicYearRange><Start>{start}</Start><End>{end}</End></AcademicYearRange> <!-- TBD -->
  <SubjectShortName>{name}</SubjectShortName>
  <Semester>{semester}</Semester>
  <SchoolYear>{year}</SchoolYear>
</TimeTableSubject>

<TimeTableCell>
  <TimeTableRefId>{refId}</TimeTableRefId>
  <TeachingGroupRefId>{refId}</TeachingGroupRefId>
  <SubjectLocalId>{id}</SubjectLocalId>
</TimeTableCell>

<StaffPersonal>
    <LocalId>{eNumber}</LocalId>
</StaffPersonal>