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 NAPLAN standalone registration

1. What’s the business problem?

Allow schools with a SIS to provide information about NAPLAN candidates, and read back the Platform Student Identifier (PSI) assigned to each student by the Assessment Platform.

More…

2. Use case description & Pre-conditions

Around NAPLAN census time, the SIS lodges bulk information about NAPLAN candidates for the current year to the National Assessment Platform (NAP), on behalf of one or more schools. Any other information, including registration of students to particular NAPLAN testing events, personal needs and preferences, and assigning staff members and invigilators, is done out of band on the AP web site.

Naplan registration SIF objects

Diagrams the interactions between SIF objects for this use case.

Assumptions:

• SIS can both read and write SIF records.
• SIS manages information for an individual school, a systemic authority data hub, or a third party data hub.
• Quality assurance may be deferred until after records are uploaded, through record editing is permitted by the NAP.
• Contact details of the school or school system administrator for NAPLAN Online are known to the NAP.
• School (or school system) administrator has access to the NAP as a registered and authorised user, so that they can authorise SIS access, confirm the upload data, and authorise other staff on the NAP.
• Allocation of staff accounts for teachers in schools is done outside of this process.
• The school(s)’ ACARA ID is known to the SIS. The mechanism for this is out of scope for this use case: school systems are expected to arrange a feed to the Australian School List, while non-systemic schools will likely query a web interface.
• Personal Needs and Preferences are manually entered into the NAP, and are not contributed using this method.
• NAP is tenanted: the SIS client does not have access to data outside its tenancy (= sector, in the current implementation).
• NAP does not use zones to segregate schools: the one endpoint is used for the entire data tenancy.
• NAP is purged of data at the end of each assessment cycle: only current student records are available from it.
• StudentPersonal/MostRecent includes all information necessary for student registration in NAPLAN, without needing to resort to StudentSchoolEnrollment.
• StudentPersonal records are only assigned to one school for the purposes of NAPLAN. If they need to be assigned to more than one school within a system, multiple StudentPersonal records need to be created for the same student, each representing a different enrolment.

Pre-conditions:

• Vendor has access to HITS.
• Vendor has mapped the relevant SIF object to their systems:
  • StudentPersonal
  • SchoolInfo (used for ACARA IDs and local IDs of school enrolment).

3. Use Case Workflow

Workflow summary:

1. Join

2. Provide

3. Consume (Students)

4. Process (Students)

5. Assurance

NOTE: Consume and Process occur after Provide in this use case!

3.1. Join NAP zone

Join: - SIS client registers with NAP. - NAP communicates to SIS client out-of-band credentials for connecting to the NAP zone.

3.2. Provide authoritative data

Vendor-facing (push); HITS represents NAP and is the data sink.

SIS client expresses information in SIF/XML: - SIS client obtains ACARA ID(s) for its school(s), out of band. - SIS client connects to NAP zone (“HITS Zone 1”). - SIS client authenticates to NAP zone (“HITS Zone 1 Authz”). - NAP zone authorises write access to objects in the NAP zone (“HITS Zone 1 Authn”, StudentPersonal). - NAP zone authorises read access to objects in the NAP zone (“HITS Zone 1 Authn”, StudentPersonal). - The SIS client provides to HITS the following:
- Post StudentPersonal to URL http://.../StudentPersonals all StudentPersonal records of students eligible for NAPLAN. - The unique ACARAId of the school that each student is enrolled in, included in StudentPersonal/MostRecent/ACARAId
- NAP associates the StudentPersonal records with the school nominated in StudentPersonal/MostRecent/ACARAId. - NAP assigns a different PSI to each enrolment.

3.3. Consume base data from HITS (Students)

SIS client gets from NAP: - One or more StudentPersonal records, corresponding to every StudentPersonal posted by the SIS client, and containing the PSI identifier for each student. The PSI is added to the StudentPersonal record as StudentPersonal/OtherIdList/OtherId/@type="NAPPlatformStudentIdentifier"

3.4. Process in third party apps

• SIS client ingests the PSI identifier, by matching the student records received against the student records it has sent.
• Matching is assumed to be done on StudentPersonal/LocalId. (TBC)
• SIS clients must not assume that the StudentPersonal@RefId sent will be the same as the StudentPersonal@RefId received.

3.5. Self–confirm use case support

1. Validate StudentPersonal records

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

• All StudentPersonal records are well-formed SIF records.
• None of the SIF records submitted have dependencies on any other SIF records (no RefID references). Schools that the students are enrolled in are only referenced through their ACARA id in StudentPersonal/MostRecent/ACARAId.

More…

More information

What business problem does this use case address?

In brief:

• Allows schools to provision StudentPersonal records to the Assessment Platform (as potential candidates for NAPLAN).
• Enables those schools to retrieve the Platform Student Identifier that the Assessment Platform associates with StudentPersonal records.

The SIS is presumed to have limited technical capabilities. In particular, there is no requirement for it to read SIF objects from external sources (such as the Australian School List), although schools are presumed to be able to supply their own ACARA Id. The SIS is not required to be able to relate objects to each other (e.g. through StudentSchoolEnrollment). The use case is applicable to both individual school and to school systems; in the case of school systems, the SIS is expected to have system-wide scope.

This use case is quite restricted, and does not support extending SIS capability to other areas (such as online assessment or census). It requires the NAP to do school-specific processing for each SIS client. It is not currently clear whether this use case provides enough information to support NAPLAN reporting back to the school.

This use case deviates from the usual workflow of HITS: the SIS being tested provides data before it consumes and processes it.

Use case preconditions for assurance

No further conditions are set on assurance.

Relevant Service Paths Supported on HITS

• /StudentPersonals

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>