CHESSN management in TCSI
Previous process
Providers were required to acquire a Commonwealth Higher Education Student Support Number (CHESSN) through HEIMS WebService or HEIMS Administration for their Commonwealth assisted students and then report this information back to the department in various data files to HEIMS.
TCSI
TCSI has created an opportunity to rationalise this existing circular process. Under TCSI, data that identifies a student at a provider is reported and stored in single place – in the provider's 'student' record. The provider can then link course, unit and loans data to that student record so that student data does not have to be reported multiple times on multiple files. That 'student' record has all the information needed for the department to identify a CHESSN for the student.
New CHESSN allocation process
Once providers are using TCSI, they will no longer have to acquire CHESSNs from HEIMS WebService or HEIMS Administration. Instead, once a provider has reported the 'baseline' data for a student, a process will be triggered to automatically find or allocate a CHESSN for the student. Once a CHESSN is found, it will be directly populated into the provider's student record (UID8) within TCSI and a message will be placed on the provider's notification table that the CHESSN is available for retrieval.
The baseline data to trigger the automated CHESSN look-up process is:
- student identification code (E313),
- date of birth (E314),
- student family name (E402),
- student given name first (E403), and student given name others (E404).
- student gender (E315)
In most instances, the baseline data will be sufficient to allocate a CHESSN. However, there may be instances where this is not sufficient, for example, where there are already two or more students in the CHESSN database with the same full name and date of birth and another student with the same name and date of birth is being created. In this case, a message will be placed on the provider's notification table indicating that more data is needed to determine a CHESSN for the student. At this stage, the reporting of a TFN would be most useful and would trigger a re-execution of the CHESSN look-up process and the allocation of a CHESSN to the provider's student record (UID8). CHESSN allocation may be delayed if the TFN does not verify.
Providers will still be able to report a CHESSN if they wish and this could be helpful in the allocation of the correct CHESSN. If the verification process determines that the CHESSN reported by the provider is not correct or is not the master CHESSN (if a concordance has occurred), the system will automatically overwrite the CHESSN supplied by the provider with the master CHESSN and a message will be placed on the provider's notification table indicating that this has occurred.
CHESSN changes
The CHESSN look-up process will be re-executed each time a provider reports or amends:
- the 'baseline' data for a student
- the TFN or CHESSN for a student, or
- a loan record or Commonwealth scholarship record.
Where the re-trigger of the look-up process determines that the existing CHESSN on the student record is incorrect, it will be updated with the correct CHESSN and the provider will receive a message on its notifications table.