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

1. What's the business problem?

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


2. Usecase description & Pre-conditions

NAPLAN testing is to occur this year, through a national delivery system. Around NAPLAN census time, the SIS lodges bulk information about its NAPLAN candidates to the Assessment Platform (AP), 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.



Usecase 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!


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


3. Join school zone

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

4. Provide authoritative data

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

SIS client expresses information in SIF/XML: - SIS client obtains ACARA ID(s) for its school(s). - SIS client connects to AP zone (“HITS Zone 1”). - SIS client authenticates to AP zone (“HITS Zone 1 Authz”). - AP zone authorises write access to objects in the AP zone (“HITS Zone 1 Authn”, StudentPersonal). - AP zone authorises read access to objects in the AP 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 NAP. - The unique ACARAId of the school that each student is enrolled in, included in StudentPersonal/MostRecent/ACARAId
- AP associates the StudentPersonal records with the school nominated in StudentPersonal/MostRecent/ACARAId. - AP assigns a different PSI to each enrolment.

5. Consume base data from HITS (Students)

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

6. Process in third party apps

7. Self–confirm usecase support

  1. Validate StudentPersonal records

More information

What business problem does this usecase address?

In brief:

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 AP 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 usecase deviates from the usual workflow of HITS: the SIS being tested provides data before it consumes and processes it.

Usecase preconditions for assurance

No further conditions are set on assurance.