C06011 HIN Reports

Section I

1. The HIN

The HESA Student Record is defined on the basis of registrations; a student registered on a single programme of study will have a single record in a collection and a student registered on two entirely independent programmes of study will have two records in a collection. The concept of registrations was further developed in 1998/99 with the introduction of the student instance number (NUMHUS), which identifies studies leading to a qualification aim. Where a student is registered on two entirely independent programmes of study the NUMHUS uniquely identifies each of the programmes in the collection.

In example 1 the record with a HIN of 981168123456201681 represents the registration of Peter Smith on a BSc Mathematics course at The University of Glasgow. Whereas the record with a HIN of 981168123456201682 represents the registration of Peter Smith on a MSc Mathematics course at The University of Glasgow.

The HIN is a combination of three fields, the HUSID, INSTID and NUMHUS, which uniquely identify a student on a programme of study leading to a qualification aim. The HUSID identifies the student, the INSTID the institution at which the student is registered and the NUMHUS identifies studies leading to a qualification aim. Within a given collection the same HIN cannot be used more than once. A student can have more than one record but each record must be identified by a different NUMHUS. Records with the same combination of HUSID, INSTID and NUMHUS will fail validation.

Back to the top

2. The HIN Link

Once a record has been returned for one HESA year, a record with the same HIN will be required for subsequent years, until the student completes the programme of study (RSNLEAVE and DATELEFT completed), suspends their study on the programme (NOTACT completed), or becomes dormant (63 or 64 in MODE).

Where dormant or suspended records are re-opened, a record with the same HIN will continue to be required until a new explicit end statement is received. If the student withdraws from the programme of study from a dormant or suspended mode, a dormant record should be submitted to provide a permanent end statement by completing RSNLEAVE, DATELEFT and where relevant, QUAL1/2.

The HIN serves as a year-on-year linking mechanism and is used to track the progression of the student on the programme from one year to the next and thus from commencement of the programme through to completion. In order for this to be successful, a record that details Peter Smith’s progress on this BSc Maths course must always have a HIN of 981168123456201681.

Back to the top

3. The role of the HUSID in maintaining the HIN link

A student should never have more than one HUSID and a given HUSID should never be assigned to more that one student. Changing the data returned in HUSID between years will result in the incorrect conclusion that the record relates to a different Peter Smith.

Incorrectly assigning more than one HUSID to a student may occur if there is more than one student record system in use e.g. a main student records system and a departmental record system. It may also occur when a student applies to the same institution directly and then through UCAS or vice versa. Where, for example, a UCAS entrant applies directly to the institution for a further programme of study, the UCAS-style HUSID should continue to be returned for the student. The same applies to a direct entrant who subsequently applies to the institution for a further programme of study through UCAS; the UCASNUM should be returned but it should not be used to generate another HUSID – the original HUSID should be returned. Once a HUSID has been assigned to a student, it should be used throughout their experience at HE institutions. That HUSID should never be used for another student.

Within a given data collection records that have the same HUSID must also have the same date of birth and gender. If two records have the same name, date of birth and gender, then it is expected that the HUSID in both records will be the same. Where this does not occur an error is raised alerting institutions to check and amend data as appropriate.

Furthermore, where an explicit HIN link between records in consecutive data collections has been made, the date of birth in both records is checked to ensure that it is the same.

Institutions must check the date of birth in the current year’s record and either confirm that the change in date is a data quality improvement or reinstate correct data.

Back to the top

4. The role of the NUMHUS in maintaining the HIN link

It is essential to understand the role that NUMHUS plays in maintaining the HIN link. Why was it necessary to introduce the concept of a student instance to identify studies leading to a qualification aim? Why not simply use QUALAIM? The problems with using QUALAIM as part of a unique identifier are illustrated in examples 4 and 5 below.

If the qualification aim changes or develops within a programme of study e.g. MPhil/PhD or Cert HE/Dip HE / Degree, the combination of HUSID, INSTID and QUALAIM will change and therefore cannot be used to uniquely identify the student on a programme of study leading to a qualification aim. However, using the NUMHUS as part of a unique identifier will allow records that describe the same student continuing to study on the same overall programme to be linked.

QUALAIM may not be sufficient to identify studies leading to a qualification aim uniquely. A student following two entirely independent programmes at the same time could have the same combination of HUSID, INSTID and QUALAIM for both programmes. However using the NUMHUS as part of a unique identifier will allow for the student's progress on each of these programmes to be tracked independently.

Once a NUMHUS has been assigned to the programme on which the student is registered, it must continue to be used for that programme every time details of the student on the programme are returned to HESA. Changing the NUMHUS between years will result in the incorrect conclusion that the record relates to Peter Smith’s progress but on another programme of study.

The NUMHUS field is 20 characters in length, allowing institutions to return an identifier held internally. Where an internal code is returned in NUMHUS, institutions must continue to use that code even when transfers or natural progressions occur. Where qualification aim develops within a programme, the NUMHUS relating to the original QUALAIM should not change to reflect the new QUALAIM.

In practice, internally held course codes such as 100MPhil are likely to be changed incorrectly when the student progresses onto a PhD. As a consequence, institutions are advised to use a simple format for data returned in NUMHUS, which can be increased sequentially with each new instance of the student e.g. 1, 2, 3 or A, B, C etc. Institutions should return internally held student and programme identifiers in field 149/134, OWNSTU and field 150/135 OWNPSD respectively.

Institutions should note that a new NUMHUS format can only be introduced for records that have not already been returned to HESA. This will be the case for new entrants and for continuing students commencing programmes of study that have not previously been returned to HESA. Records that have been returned to HESA will have a unique HIN, which must not be changed by changing the NUMHUS.

Numbers 1 and 01 will be interpreted as different codes in NUMHUS

100.MAT and 100..MAT will be interpreted as different codes in NUMHUS.

For further guidance on assigning the NUMHUS refer to Section III.

Back to the top

Section II

5. The HIN Reports

The HIN Reports are produced when data submitted to HESA passes second stage validation checks. Four reports are produced which detail the issues that arise in carrying out the year-on-year linking of registration records using the HIN.

Records in Report A are those where a HIN link has been established, however data quality issues (e.g. change in domicile) are revealed when comparing the records. Checks within this report are set at the level of a warning. Assuming that the HIN linking for such records is correct, institutions will have changed data ‘on entry to the programme’ either in error or to correct data that was previously incorrect or 'Not Known'. Institutions are required to check the HIN linking, restore valid data or confirm that changes are data quality improvements.

Records in Reports B and C are those where a HIN link to another record should exist but does not. Checks within these reports are set at the level of an error. An active record is required in the current year for those students who were active on a programme last year and who have returned in the current year to continue to study on the programme. A dormant record is required in the current year for those students who were active on a programme last year (and who did not complete or suspend study on that programme) and who have not returned in the current year to continue on the programme. Furthermore, where a record submitted in the current year is that for a student continuing on a programme, the record submitted should link to the one submitted to HESA previously. Institutions are required to restore HIN links and/or correct data in relevant fields as appropriate.

Records in Report D are those where BIRTHDTE, POSTCODE and QUALAIM matching suggests that the records describe the same student continuing to study on the same overall programme of study, however the institution has closed one student instance and opened another. Institutions are required to check the suggested matches and correct the HIN as appropriate.

The following table lists the checks within each HIN report. HIN checks 6 and 7 have been upgraded from warnings to errors. This is a new requirement for the 2006/07 reporting year. Institutions should note that once HIN Report C errors have been resolved by establishing the HIN link, a further resubmission may be required, in order to resolve data quality issues that are revealed when comparing the linked records as outlined in HIN Report A.

For further information on the detail of the HIN reports refer to Section IV.

Back to the top

6. The HIN Target List

The HIN Target List is produced when data submitted to HESA passes second stage validation checks. This is a list of all records in the current year's submission that have not been closed-off in one of the following ways:

• RSNLEAVE and DATELEFT completed or
• NOTACT completed or
• codes 63 or 64 returned in MODE
.

Institutions are required to account for all HINs present in the HIN Target List in the next year's submission by either submitting an active record indicating that the student returned to resume study on the instance, or submitting a dormant record indicating that the student has been dormant for the whole of the reporting period. HESA will no longer assume dormancy where a record that is expected (because it was present in the HIN Target List) is missing from the submission. From 2007/08 institutions are required to state explicitly that the student is dormant by submitting a dormant record. Once this dormant record has been submitted it is not necessary to continue submitting records in subsequent years, unless the student resumes study, in which case an active record will be required, or a qualification is being reported from the dormant mode. Institutions are encouraged to adopt this practice for 2006/07.

Back to the top

Section III

7. Further guidance on assigning the NUMHUS

Failure to maintain the HIN link from one year to the next makes tracking the progression of the student on the programme of study problematic. There will be cases where it is difficult to determine when an existing student instance number should continue to be used and when a new number should be allocated. The following examples set out the guidelines for assigning student instance numbers.

I Student continues to study on a programme at the same level
II Transfers by changing subject or QUALAIM within the same level
(a) Transfer by changing subject within the same level
(b) Transfer by changing qualification aim within the same level
III Transfer from HND to degree course
(a) Transfer from HND to Degree - Continuation of studies
(b) Transfer from HND to Degree - New programme of study
IV Concurrent study
V Student completes programme and proceeds to take another at the same level
VI Student completes programme and proceeds to take another at a different level
VII Normal progression
VIII Withdrawals
(a) Student drops out and returns to study (programme resumed) at the same level in a future reporting period
(b) Student drops out and returns to study (new programme started) at the same level in a future reporting period

I Student continues to study on a programme at the same level

Where a student continues to study on a programme at the same level (i.e. undergraduate or postgraduate) at the same institution this is treated as the same student instance. Therefore the NUMHUS should not change from one year to the next.

II Transfers by changing subject or QUALAIM within the same level

Where a student transfers programmes by changing subject or even qualification aim within the same level, this would not, in general, lead to a change of the student instance. It does not matter whether the studies already taken count towards the current qualification aim or not. Where a student transfers programmes, the logical outcome of the first programme is that the student changed to studying on the new programme - this is shown explicitly by keeping the same student instance number.

(a) Transfer by changing subject within the same level

(b) Transfer by changing qualification aim within the same level

III Transfer from HND to degree course

Where a student transfers after two years from an HND course to the second year of a degree course (with or without being awarded the HND) this is treated as the same student instance if within the institution this is regarded as a seamless continuation of studies.

(a) Transfer from HND to degree - continuation of studies

However, a new student instance should be generated if within the institution this is viewed as completing one programme and then starting a new one.

(b) Transfer from HND to degree - new programme of study

If the institution chooses to return the records in this way, then the HIN which identifies the HND must be closed-off by completing field 33, RSNLEAVE, field 35, DATELEFT and field 37, QUAL1. In addition, a new NUMHUS must be assigned to the degree programme, and all of the relevant fields must be updated, such as ‘on entry to programme of study’ fields and:

• Field 21, Highest qualification on entry
• Field 26, Date of commencement of programme
• Field 30, Year of student on this programme
• Field 72, Year of programme

If an institution does not have a clear preference between the two methods of reporting, it is recommended that the first method, using a single student instance, be used. This general guidance would also apply to other similar cases.

IV Concurrent study

Where a student follows two entirely distinct programmes of study concurrently, a new NUMHUS should be assigned to the second programme in order to separately identify studies leading to the second qualification aim.

V Student completes programme and proceeds to take another at the same level

Where a student completes an undergraduate programme and then proceeds to take a further entirely distinct undergraduate programme at the same institution, this is treated as a new student instance.

It is likely that, under these circumstances where the record with NUMHUS 1 has been closed off, a HIN Check 8 warning will be raised, essentially asking the institution to check that the records do not describe the same student continuing to study on the same overall programme of study.

VI Student completes programme and proceeds to take another at a different level

Where a student completes an undergraduate degree and then proceeds to take a masters degree, the masters degree is a distinct programme of study at a different level (postgraduate), and as such it is treated as a new student instance.

VII Normal progression

Where the qualification aim develops within the same overall programme, the same student instance number should be returned, e.g. where a student registers first for an MPhil and then progresses onto a PhD, if this is regarded as the normal progression route for this qualification aim at the institution.

VIII Withdrawals

Where a student drops out part way through the programme of study and then returns to the same institution to study at the same level, this is treated as the same student instance. The fact that the HIN has been closed (by completing field 35, DATELEFT and field 33, RSNLEAVE) should not preclude the institution from re-opening it when studies commence again in a future reporting period.

(a) Student drops out and returns to study (programme resumed) at the same level in a future reporting period - do not change the NUMHUS

(b) Student drops out and returns to study (new programme started) at the same level in a future reporting period - do not change the NUMHUS

Back to the top

Section IV

8. Further information on the detail of the HIN reports

HIN Report A: HIN link but data quality issues revealed by linking the two records
HIN Report B: No HIN link for an incoming record that commenced prior to the reporting period (Check 6)
HIN Report C: No incoming record for a HIN with Live status in last year's data (Check 7)
HIN Report D: BIRTHDTE/POSTCODE/QUALAIM matching suggests records should be linked (Check 8)

HIN Report A: HIN link but data quality issues revealed by linking the two records

Check 1: HIN link but level differs (PG/UG based on QUALAIM codes)
Check 2: HIN link but COMDATE after the start of reporting period
Check 3: HIN link but conflicting information on entry to programme of study fields
Check 5: HIN link but different personal details

Check 1: HIN link but level differs (PG/UG based on QUALAIM codes)

In the following example it is either the HIN link or QUALAIM that is incorrect.

• Correct the HIN: If the QUALAIM codes are correct then the current year’s record should not be linked to a record from a previous year. A new NUMHUS should be allocated to the current record and the relevant data submitted for the other record as appropriate.
• Correct the QUALAIM: If the HIN linking is correct then the records should have the same QUALAIM. Data returned in QUALAIM should be corrected.
• Data quality improvement: Report data quality improvement to HESA if QUALAIM was incorrectly returned previously and has been corrected in this year’s record.

Check 2: HIN link but COMDATE after the start of reporting period

In the following example it is either the HIN link or COMDATE that is incorrect.

• Correct the HIN: If the COMDATE is correct then the current year’s record should not be linked to a record from a previous year. A new NUMHUS should be allocated to the current record and the relevant data submitted for the other record as appropriate.
• Correct the COMDATE: If the HIN linking is correct then the records should have the same COMDATE. Data returned in COMDATE should be corrected.
• Data quality improvement: Report data quality improvement to HESA if COMDATE was incorrectly returned previously and has been corrected in this year’s record.

Check 3: HIN link but conflicting information on entry to programme of study fields

This check affects data returned in several fields as follows:

• Check 3c QUALENT2
• Check 3d POSTCODE
• Check 3h DOMICILE
• Check 3j ETHNICITY
• Check 3m YRLLINST
• Check 3q UCASNUM
• Check 3u TOTALTS

In the following example it is either the HIN link or QUALENT2 that is incorrect.

• Correct the HIN: If the QUALENT2 codes are correct then the current year’s record should not be linked to a record from a previous year. A new NUMHUS should be allocated to the current record and the relevant data submitted for the other record as appropriate.
• Correct ‘on entry to programme of study fields’: If the HIN linking is correct, data returned in these fields should be as ‘on entry to the programme of study’. The information should not be changed between years unless incorrect data or a 'Not known' value was previously returned.

Check 5: HIN link but different personal details

This check affects data returned in several fields as follows:

• Check 5a BIRTHDTE
• Check 5b GENDER
• Check 5c SNAME

In the following example it is either the HIN link or GENDER that is incorrect.

The records should be reviewed and if the HIN linking is correct, data returned in these fields should not be changed between years unless incorrect data was previously returned or a 'Not known' value is being populated.

HIN Report B: No HIN link for an incoming record that commenced prior to the reporting period (Check 6)

Category 1: Incoming record(s) were matched to a record returned previously using BIRTHDTE/POSTCODE/QUALAIM

Category 2: Incoming record(s) were matched to a record returned previously using BIRTHDTE/POSTCODE/QUALAIM but the record was properly closed off

Category 3: Incoming record(s) could not be matched to a record returned previously using BIRTHDTE/POSTCODE/QUALAIM

Records in HIN Report B have failed Check 6 because the incoming record for a student continuing on a programme (i.e. COMDATE before 01 August 2006) does not link to a record returned previously. In the absence of a HIN link, HESA uses BIRTHDTE/POSTCODE/QUALAIM to suggest a match to a record returned previously. (Suggested matches can only be returned if data in all three fields of both records match exactly.)

There are three categories of records within Check 6:

Category 1: Incoming record(s) were matched to a record returned previously using BIRTHDTE/POSTCODE/QUALAIM

• Correct the HIN: Examine suggested matches and if they are genuine, then the NUMHUS or HUSID in the current record should be restored to its original value. If the COMDATE has also been changed this should be returned to its original value as well.
• Correct the COMDATE: If the suggested matches should not be linked, then why does an incoming record for a student continuing on a programme not link to a record returned previously? Should the COMDATE for the incoming record fall within the current reporting period i.e. student commencing a programme of study this year – if so correct the COMDATE. Furthermore, appropriate information for the other record should be returned if necessary.
• Missing record: If the suggested matches should not be linked and the incoming record is for a student continuing on a programme that has not been returned previously, report the record missing from previous submission to HESA. Furthermore, return the appropriate information for the other record if necessary.

Category 2: Incoming record(s) were matched to a record returned previously using BIRTHDTE/POSTCODE/QUALAIM but the record was properly closed off (i.e. DATELEFT and RSNLEAVE completed, or NOTACT completed, or dormant in MODE)

• Correct the HIN: Examine suggested matches and if they are genuine, then the NUMHUS or HUSID in the current record should be restored to its original value. If the COMDATE has also been changed this should be returned to its original value as well.
• Correct the COMDATE: If the suggested matches should not be linked, then why does an incoming record for a student continuing on a programme not link to a record returned previously? Should the COMDATE for the incoming record fall within the current reporting period i.e. student commencing a programme of study this year – if so correct the COMDATE. Furthermore, appropriate information for the other record should be returned if necessary.
• Missing record: If the suggested matches should not be linked and the incoming record is for a student continuing on a programme that has not been returned previously, report the record missing from previous submission to HESA. Furthermore, return the appropriate information for the other record if necessary.

Category 3: Incoming record(s) could not be matched to a record returned previously using BIRTHDTE/POSTCODE/QUALAIM

• Correct the HIN: These records should be reviewed to see if there should be a HIN link to a record in a previous return. If so, the HIN link should be restored by changing the NUMHUS and/or HUSID to be the same as that returned in the earlier record. COMDATE, BIRTHDTE, POSTCODE and QUALAIM should also be checked to ensure they are accurate.
• Missing record: If the COMDATE is correct and this is an incoming record for a student continuing on a programme that has not been returned previously, report the record missing from previous submission to HESA.

HIN Report C: No incoming record for a HIN with Live status in last year's data (Check 7)

Check 7g - Matched to an incoming record using BIRTHDTE/POSTCODE/QUALAIM
Check 7h – Not matched to an incoming record

Records in HIN Report C have failed Check 7 because there is no record in the current year’s submission that links to a record that was live in last year's submission. Records are either missing from the current submission or have been returned with incorrect data in NUMHUS and/or HUSID. Records are split into two checks; those where a match to an incoming record can be found using BIRTHDTE/POSTCODE/QUALAIM (Check 7g) and those for which a match cannot be found (Check 7h).

Check 7g - Matched to an incoming record using BIRTHDTE/POSTCODE/QUALAIM

Records are split into two categories within Check 7g:

Category 1: Matched to an incoming record using BIRTHDTE/POSTCODE/QUALAIM

Category 2: Matched using BIRTHDTE/POSTCODE/QUALAIM but to an incoming record which has a current year COMDATE

In both cases:

• Correct the HIN: The suggested matches should be examined and if they are genuine the NUMHUS and/or HUSID in the current year’s record should be restored to their original value. Data returned in COMDATE should also be checked to ensure that it is as ‘on entry to the programme’.
• Return appropriate information for both records: If the suggested matches should not be linked then the appropriate data should be returned for both records. Records that were live in the previous reporting period must be accounted for in the current year, by either submitting another live record or submitting a dormant record.

Check 7h – Not matched to an incoming record

Records that fail Check 7h could not be matched using BIRTHDTE/POSTCODE/QUALAIM to any incoming record. Records are either missing from the current submission or they have been returned in such a way that they do not link to a record in the previous year’s submission using either the HIN or BIRTHDTE/POSTCODE/QUALAIM matching process.

Institutions are required to correct the HIN or submit missing records:

• Correct the HIN: The HUSID and/or NUMHUS should be restored to their original value and data returned in COMDATE, as well as BIRTHDTE, POSTCODE and QUALAIM, should be checked to ensure it is correct
• Submit missing records: Records that were live in the previous reporting period must be accounted for in the current year by either submitting another live record or submitting a dormant record. Qualifications obtained should also be reported as appropriate.

HIN Report D: BIRTHDTE/POSTCODE/QUALAIM matching suggests records should be linked (Check 8)

Check 8: Possible link based on BIRTHDTE/POSTCODE/QUALAIM

Records in HIN report D have failed Check 8 because there is no HIN link to a record in a previous submission. BIRTHDTE/POSTCODE/QUALAIM matching suggests that the institution has closed one student instance and then opened another, for what appears to be the same student continuing to study on the same overall programme of study.

The suggested links should be examined, and if they are genuine, the NUMHUS and/or HUSID in the current year's record should be restored to their original value in order to re-create the HIN link.