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:
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 Wellbeing Recording
1. What’s the business problem?
Allow schools to securely provide SIS information to the Wellbeing product(s) of their choice, and also to allow various wellbeing records to be published to a jurisdictional data hub.
More…
2. Use Case Description & Pre-Conditions
A 3rd Party Wellbeing application connects to HITS as a jurisdiction hub, collecting the relevant information and publishing back wellbeing records to the centralised system.
Wellbeing conceptual diagram
This conceptual diagram contains interactions beyond this specific technical use case, and is included for context.
Wellbeing recording SIF objects
Diagrams the interactions between SIF objects for this use case.
Assumptions:
3rd Party Vendor is a current supplier of a Wellbeing product in schools or has knowledge of Wellbeing 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
- StaffPersonal
- StudentContactPersonal
- TimeTableSubject
- TimeTableCell
- ScheduledActivity
- PersonalisedPlan
- WellbeingResponse
- WellbeingEvent
- WellbeingCharacteristic
- WellbeingAppeal
- WellbeingAlert
- SchoolInfo (Objects to be written back need to reference SchoolInfo, whether on a single-school zone or not)
- 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.
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. Because of the complexity of the Wellbeing technical use case, not all seed information will be needed for all objects, and vendors who will not generate all Wellbeing objects may need only a subset of them; we indicate the dependencies between seed information and Wellbeing objects in the following.
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. (Referenced by PersonalisedPlan, WellbeingResponse, WellbeingEvent, WellbeingCharacteristic, WellbeingAppeal, WellbeingAlert.)
- on the Jurisdiction-established Zone for the App, Third party app accesses all StaffPersonal records which are in a StaffAssignment relationship with the given School RefId. (Referenced by WellbeingEvent.)
- on the Jurisdiction-established Zone for the App, Third party app accesses all StudentContactPersonal objects which are in a StudentContactRelationship relationship with one of the students accessed. (Potentially accessed by WellbeingEvent/PersonalInvolvementList/PersonalInvolvement/PersonRefId.)
- on the Jurisdiction-established Zone for the App, Third party app accesses all TimeTableSubject, TimeTableCell and ScheduledActivity records. (Referenced by WellbeingResponse/Suspension/WithdrawalTimeList/Withdrawal.)
- 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:
- Get SchoolInfos -
http://.../SchoolInfos
(HITS should determine the URLs eg http://hits.nsip.edu.au/SchoolInfos
- access this information from your Dashboard.)
- Get StudentPersonals -
http://.../StudentPersonals
(linked to school via StudentSchoolEnrollment; eg: equivalent to http://.../SchoolInfo/\\{REFID}/StudentSchoolEnrollments/{REFID}/StudentPersonals)
- Get StaffPersonals -
http://.../StaffPersonals
(linked to school via StaffAssignment; eg: equivalent to http://.../SchoolInfo/\\{REFID}/StaffAssignments/{REFID}/StaffPersonals)
- Get StudentContactPersonals -
http://.../StudentContactPersonals
- Get TimeTableSubjects -
http://.../TimeTableSubjects
- Get TimeTableCells -
http://.../TimeTableCells
- Get ScheduledActivitys -
http://.../ScheduledActivitys
Endpoints may support additional queries for retrieving data - refer to Query-by-example or service paths? for HITS guidance on queries.
3.3. Process in 3rd Party Application.
3rd Party App uses the consumed data to produce various types of wellbeing information. The definition and automation of this process is out of scope of HITS.
Steps:
- Third party app processes information and gathers Wellbeing Information
- Third party application creates return Wellbeing 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;
- Post PersonalisedPlan to
http:// .../PersonalisedPlans
- Post WellbeingResponse to
http:// .../WellbeingResponses
- Post WellbeingEvent to
http:// .../WellbeingEvents
- Post WellbeingCharacteristic to
http:// .../WellbeingCharacteristics
- Post WellbeingAppeal to
http:// .../WellbeingAppeals
- Post WellbeingAlert to
http:// .../WellbeingAlerts
3.5. Assurance: Self – Confirmation of Use Case Support
- Validate Wellbeing 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 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—or to another object being published by the App—e.g. WellbeingResponse/PlanRequired/PlanRequiredList/Plan/PersonalisedPlanRefId referencing PersonalisedPlan). 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.
More…
What business problem does this use case address?
In brief:
- Allow schools secure access to SIS information
- Allow schools to use the Wellbeing products of their choice
- Allow 3rd Party Wellbeing apps automated access to base information
- Allow 3rd Party Wellbeing apps to publish wellbeing records to a jurisdictional hub.
Schools currently use third-party wellbeing applications locally to supplement their Student Information System (SIS). The seed information for recording of wellbeing 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 wellbeing vendors can connect to a centralised data hub to securely access to the required information and publish back Wellbeing records to the centralised data hub.
Use case preconditions for assurance
For the purposes of validation, a new Wellbeing object (PersonalisedPlan, WellbeingResponse, WellbeingEvent, WellbeingCharacteristic, WellbeingAppeal, WellbeingAppeal) is well-formed if it satisfies the following requirements:
- All mandatory elements of the Wellbeing object are provided.
- The Wellbeing object points to a valid StudentPersonal and SchoolInfo object.
- Where provided, the Wellbeing object points to valid TimeTableSubject, ScheduledActivity, TimeTableCell, StudentContactPersonal and/or StaffPersonal objects.
- Where provided, a WellbeingResponse object points to valid PersonalisedPlan objects; a WellbeingEvent object points to valid WellbeingResponse objects; a WellbeingAppeal object points to valid WellbeingResponse objects.
Other business-specific rules for validation, including plausibility of any dates supplied, are not enforced by HITS.
Relevant Service Paths Supported on HITS
- SchoolInfos/{}/StudentPersonals
- SchoolInfos/{}/StudentSchoolEnrollments
- SchoolInfos/{}/StudentContactPersonals
- SchoolInfos/{}/StaffPersonals
- SchoolInfos/{}/StaffAssignments
- SchoolInfos/{}/TimeTableSubjects
- SchoolInfos/{}/ScheduledActivitys
- SchoolInfos/{}/TimeTableCells
- SchoolInfos/{}/PersonalisedPlans
- SchoolInfos/{}/WellbeingResponses
- SchoolInfos/{}/WellbeingEvents
- SchoolInfos/{}/WellbeingCharacteristics
- SchoolInfos/{}/WellbeingAppeals
- SchoolInfos/{}/WellbeingAlerts
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>
<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>