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 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 enrolment

1. What’s the business problem?

Allow schools in a school system to enrol students, saving the required information about the students to a jurisdictional data hub.

More…

2. Use Case Description & Pre-Conditions

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

Enrolment conceptual diagram

This conceptual diagram contains interactions beyond this specific technical use case, and is included for context. Secondary objects are shaded grey.

Enrolment SIF objects

Diagrams the interactions between SIF objects for this use case.

Assumptions:

The third party vendor is a current supplier of a SIS product in schools or has knowledge of student administration processes in K-12 Schools.

Pre-conditions:

Here is a summary and a full version of the SIS Baseline Profile which governs the interactions for an enrolment.

3. Use Case Workflow

Workflow summary:

  1. Join

  2. Consume

  3. Process

  4. Provide

  5. Assurance

3.1. Join required to School Zone

3.2. Consume base data from HITS.

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

  1. Consume on the Jurisdiction-established Zone for the app.
  1. Get SchoolInfos: http:// …/SchoolInfos

3.3. Process - processes in third party application.

Third party app creates student enrolments for students enrolling in the given school.

  1. Third party app creates StudentPersonal records.
  2. Third party app creates StudentSchoolEnrollment records, one for each StudentPersonal record. StudentSchoolEnrollment/SchoolInfoRefId is populated with the SchoolInfo RefId for the current school that has been retrieved from HITS.
  3. Third party app creates StudentContactPersonal records.
  4. Third party app creates at least one StudentContactRelationship record for each StudentContactPersonal record, and at least one for each StudentPersonal record.

3.4. Provide authoritative data

Prior to providing: 

  1. Third party expresses return information in SIF/XML.
  2. Third party app connects to Jurisdiction-established Zone for the School (“HITS Zone 1”).
  3. Third party app authenticates to Jurisdiction-established Zone for the School (“HITS Zone 1 Authz”).
  4. Jurisdiction-established Zone authorises write access to objects in the Jurisdiction Zone for the School (“HITS Zone 1 Authn”).

Following is posted by the third party app back to HITS:

3.5. Assurance: Self–confirmation of use case support

  1. Validate StudentPersonal records
  2. Validate StudentSchoolEnrollment records
  3. Validate StudentContactPersonal records
  4. Validate StudentContactRelationship records

The SIF/XML data sent by the third party app to the Jurisdiction Zone for the app must satisfy the following conditions:

More information

What business problem does this use case address?

In brief, this process:

The use case described here satisfies the following scenarios in the SIS Baseline Profile (SBP): 

The use case described above can be straightforwardly extended with update operations to satisfy the following scenarios in the SBP:

Use case preconditions for assurance

As this use case applies to school systems, the enrolment records need to identify the school being enrolled into. This is done with the established SIF mechanism of referencing a SchoolInfo RefId. The master for the SchoolInfo object is the jurisdiction hub, and the third party SIS is meant to retrieve the relevant SchoolInfo object from the hub, in order to reference it correctly.

In particular: - The use of several elements is upgraded from optional to strongly recommended - FamilyName, GivenName, MiddleName are used instead of FullName for students, and are strongly recommended for student contacts - StudentPersonal/PersonInfo/Demographics/Sex is mandatory - StudentPersonal/PersonInfo/Demographics/BirthDate is mandatory - StudentSchoolEnrollment/YearLevel is mandatory

Relevant Service Paths Supported on HITS

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>

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

<StudentContactRelationship>
  <StudentPersonalRefId>{refid}</StudentPersonalRefId>
  <StudentContactPersonalRefId>{refid}</StudentContactPersonalRefId>
</StudentContactRelationship>