HESA Student Record 2009/10
HESA Student Record 2009/10
Year-on-year linkage (HIN)
return to index
Version 1.0 Produced 2009-04-30
Frequently asked questions about year-on-year linkage
|1. Is a dormant instance required for every year in which a student is dormant on an instance?||A dormant instance is required in the first year that the student becomes dormant (and did not complete or suspend study on that course) following a period of active study. Once this dormant instance has been submitted, it is not necessary to continue submitting dormant instances every year, unless a qualification is being returned from the dormant mode, or the student resumes study; in this latter case an active instance will be required.|
|2. Are dormant instances required for students on continuing education courses and other courses where there is a high degree of flexibility in attendance?||Yes a dormant instance must be submitted for students on all types of courses in the first year that the student becomes dormant following a period of active study.|
|3. Will a HIN error be raised for students who commenced an instance before 1994/95 and then subsequently return to continue to study on that instance? If so, how should this be resolved?||Yes, the HIN linking process will raise an error where a HIN link is expected but does not exist for an instance in the current year’s submission with an Instance.COMDATE that indicates this is not the first year of the student on the instance. As part of the credibility checking process, institutions will be required to confirm that Instance.COMDATE is correct. HESA will record such cases where valid entries in Instance.COMDATE precede the inception of HESA and/or the introduction of the Instance.NUMHUS as 'genuine oddities'.|
|4. Will a HIN error be raised for students who resume study on an instance that was closed off properly?||Instances that are closed off properly are kept on the HIN register for two years after closure. However an error will be raised where instances that were closed off prior to 2004/05 are re-opened even if the original Instance.NUMHUS and Instance.COMDATE are retained; under these circumstances institutions will be required to confirm that Instance.COMDATE and Instance.NUMHUS are correct.|
|5. In certain HIN reports the linking is correct but data that is not expected to change between years (such as Student.GENDER) has been changed because it was incorrect in the previous return. How will such data quality improvements be reflected in the HIN reports?||The HIN reports will continue to highlight cases where an explicit HIN link exists but data quality issues are revealed when comparing the instances. As part of the credibility checking process institutions will be required to confirm cases where data that was previously incorrect has been corrected.|
|6. The coverage of Instance.NUMHUS specifies that the field is required for all instances including those for students on FE courses. Will year-on-year validation checks be applied to FE instances?||Yes, year-on-year validation checks will be applied to FE instances but at institutions in England and Wales only.|
The Instance Entity
The instance entity is defined as a coherent engagement with the institution aiming towards the award of qualification(s) or credit. The Instance.NUMHUS uniquely identifies studies leading to a course aim. A student registered at an institution undertakes one or several courses; a course being a combination of subject and qualification that together define what the student is aiming for e.g. BSc Mathematics, GCE A Level French etc. Where a student has a single engagement they will have a single instance in a collection and only where a student is undertaking two entirely independent courses will they have two instances in a collection.
Example 1: Instances of Jane Doe on two courses at The University of Derby
Example 2: Instances of Peter Smith on two courses at The University of Glasgow
Further guidance is available from HEFCE on the reporting of multiple instances for students studying for credit.
The HIN (HUSID + Institution identifier + NUMHUS)
The HIN is a combination of three fields, the Student.HUSID, the Institution.UKPRN and Instance.NUMHUS, which uniquely identify a student on a course leading to a qualification or institutional credit. The Student.HUSID identifies the student, the Institution.UKPRN identifies the institution at which the student is registered and the Instance.NUMHUS identifies particular studies leading to a course aim.
In Example 2 above the instance with a HIN of 9811681234562100077941 represents the registration of Peter Smith on a BSc Mathematics course at The University of Glasgow, whereas the instance with a HIN of 9811681234562100077942 represents the registration of Peter Smith on a Further French course also at The University of Glasgow.
Within a given collection the same HIN cannot be used more than once. A student can have more than one instance but each instance must be identified by a unique HIN. Records with the same HIN will fail validation.
The HIN Link
The HIN is therefore a year-on-year linking mechanism which is used to track the progression of the student on the instance from one year to the next, and thus from commencement of the instance through to completion. In Example 2 above the instance with a HIN of 9811681234562100077941 represents the registration of Peter Smith on the BSc Mathematics course at The University of Glasgow. Whenever an instance that details Peter Smith's progress on this BSc Mathematics course is returned to HESA by the institution, the instance must have the HIN of 9811681234562100077941.
Once an instance has been returned for one HESA year, an instance with the same HIN will be required for subsequent years, until an explicit end statement has been received indicating that the student has:
- completed the instance (Instance.RSNEND and Instance.ENDDATE completed)
- suspended their study on the instance (Instance.NOTACT completed)
- or become dormant (codes 63, 64, 73 or 74 returned in Instance.MODE)
HESA will not assume that a student is dormant on an instance (on which they were active in the previous reporting year) if details of the instance have not been included in the current year's return. Institutions must account for all instances on which a student was active in the previous year (and who did not complete or suspend study on that programme). This is the case even where the student has been dormant throughout the current reporting year; when it is necessary to submit the instance with a dormant mode of study (code 63 or 64) in Instance.MODE.
Where dormant or suspended instances are re-opened, an instance with the same HIN will continue to be required until a new explicit end statement is received. If the student withdraws from the course from a dormant or suspended mode, an instance with a dormant mode should be submitted in order to provide a permanent end statement; this is done by completing Instance.RSNEND, Instance.ENDDATE and where relevant, QualificationAwarded.QUAL.
In order to assist institutions with making their returns to HESA, HESA will make available an electronic list of students for whom a record is required. This HIN Target List will be produced by the data collection system and will be applicable to the following year's return. The following year's system will require an instance on the incoming data for every instance on the previously generated target list, and will also generate the target list for the next year's return.
Breaking the HIN Link
The HIN link is broken when an institution incorrectly changes the Student.HUSID and/or the Instance.NUMHUS assigned to a student instance. Example 3 and 4 below illustrate an incorrectly changed Instance.NUMHUS and an incorrectly changed Student.HUSID respectively.
Example 3: Breaking the HIN that links the records by incorrectly changing Instance.NUMHUS
Changing the data returned in the Instance.NUMHUS between years could result in the incorrect conclusion that the instance relates to Peter Smith's progress on another instance.
Example 4: Breaking the HIN that links the records by incorrectly changing Student.HUSID
Incorrectly assigning more than one Student.HUSID to a single student may occur if there is more than one student record system in use, e.g. a main student record system and a departmental record system. Once a Student.HUSID has been assigned to a student, it should be used throughout their experience at the institution. The Student.HUSID assigned to a given student must never be used for another student.
Assigning the Instance.NUMHUS to an instance
Failure to maintain the HIN link from one year to the next makes tracking the progression of the student on the instance problematic. It is acknowledged that there will be cases where it is difficult to determine when an existing Instance.NUMHUS should continue to be used and when a new one should be allocated. The following examples set out the guidelines for assigning Instance.NUMHUS.
a) Student continues to study on a course at the same level - do not change the Instance.NUMHUS
If a student continues to study on a course at the same level (i.e. undergraduate or postgraduate) at the same institution, then this is treated as the same student instance and the Instance.NUMHUS should not be changed from one year to the next.
|Example 5: Student continues to study at the same level|
b) Transfers by changing subject or course aim within the same level
Where a student transfers courses by changing subject or even course aim but within the same level, this would not, in general, lead to a change in Instance.NUMHUS. It does not matter whether the studies already taken count towards the current course aim or not. Where a student transfers courses and the logical outcome of the first course is that the student changed to studying on the new course - this is shown explicitly by keeping the same Instance.NUMHUS.
HE level courses
i. Transfer by changing subject within the same level - do not change the Instance.NUMHUS
|Example 6: Student changes subject at the same level|
ii. Transfer by changing course aim within the same level - do not change the Instance.NUMHUS
|Example 7: Student changes course aim at the same level|
In both of Examples 6 and 7, Instance.YEARSTU would increment in the second year whereas the value returned in Instance.YEARPRG would depend on which year of the new course the student transferred into.
FE level courses
Note that the guidance for assigning Instance.NUMHUS for FE courses differs from that for HE courses.
i. Transfer by changing course - allocate a new Instance.NUMHUS to the new course
A new instance number should be allocated in cases where a student transfers to a new FE course aim; that is, the student withdraws from the original course aim and starts studying for another course aim. Courses with different Course.FEQAIMC codes should not be linked and therefore must have different instance numbers assigned.
|Example 8: Student changes FE course aim|
|1||0710571234565||10007851||1||10001086||GCE A level French|
|1||0710571234565||10007851||2||1000113X||GCE A level German|
c) Concurrent study – allocate a new Instance.NUMHUS to the new course
Where a student follows two distinct instances concurrently, a new Instance.NUMHUS should be assigned to the second course, in order to uniquely identify the studies leading to the second course aim.
|Example 9: Student studies two distinct instances concurrently|
In Example 9 the instances are distinct in that credits from one instance cannot count towards the other instance. Where the course aim is institutional credit and credits from several courses can be used towards the same qualification, a single instance should be returned; in these cases multiple HINs should not be generated.
d) Student completes course and proceeds to take another at the same level - allocate a new Instance.NUMHUS to the new course
Normally where a student completes a course and then proceeds to take another unrelated course at the same level this should be treated as a new instance, see Example 10. However, this would not be the case where the student was studying for institutional credit where such a pattern of study would normally constitute a single instance.
|Example 10: Student completes course and continues studying at the same level|
|2||9811681234562||10007794||2||H60||Cert in Philosophy|
e) Student completes course and proceeds to take another at a different level - allocate a new Instance.NUMHUS to the new course
Where a student completes an undergraduate degree and then proceeds to take a masters degree, the masters degree is a distinct course at a different level (postgraduate), and as such is treated as a new student instance. Instance.YEARSTU returns to 1 when the new instance begins.
|Example 11: Student completes course and continues studying at a different level|
f) Normal progression
Note that normal progression is treated differently for HE and FE level courses.
i) HE level course - do not change the Instance.NUMHUS
The same student instance number should be returned 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 course aim at the institution.
|Example 12: Normal HE progression route|
ii) FE level courses - the concept of ‘normal progression’ does not apply to FE level courses therefore allocate a new Instance.NUMHUS to the new course
|Example 13: Student studying different FE instances|
|1||0710571234565||10007851||1||10001517||GCE AS level French|
|2||0710571234565||10007851||1||00260005||GCE A2 level French|
g) Intercalated degrees
When students intercalate a second degree (or another qualification of equivalent level) as part of their overall programme, this should be returned as a single instance. In these circumstances the Instance.NUMHUS should be retained and Instance.COMDATE should not be updated. For the duration of the intercalated course, the instance should be linked to a course with a Course.COURSEAIM relating to the intercalated qualification (e.g. H24 for an intercalated first degree). Instance.YEARSTU will increment for the year of intercalation and Instance.YEARPRG will be the actual year of the course for the current course aim. For example, a student who follows two years of a medical degree, then intercalates for one year to join the third year of a BSc degree course, and then returns to the original medical degree, will in effect do two 'Year of course' 3s. When doing their intercalated year Instance.YEARSTU = 3 and Instance.YEARPRG = 3; when returning to their original studies the following year they will be coded as Instance.YEARSTU = 4 and Instance.YEARPRG = 3.
Where a student withdraws part way through the course and then returns later 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 Instance.ENDDATE and Instance.RSNEND) should not preclude the institution from re-opening the record when studies commence again in a future reporting period.
i. Student withdraws and returns to study (course resumed) at the same level in a future reporting period - do not change the Instance.NUMHUS
|Example 14: Withdrawal and resumption of study at the same level|
ii. Student withdraws and returns to study (new course started) at the same level in a future reporting period - do not change the Instance.NUMHUS
Note that withdrawal and return to study are treated differently for HE and FE level courses.
HE level course
|Example 15: Withdrawal and return to study at the same level (HE)|
FE level course
This does not apply to FE level courses. Courses with different Course.FEQAIMC codes should not be linked and therefore must have different instance numbers assigned.
|Example 16: Withdrawal and return to study (FE)|
|1||0710571234565||10007581||1||10001086||GCE A level French|
|3||0710571234565||10007581||2||1000113X||GCE A level German|
Contact Liaison by email or on +44 (0)1242 388 531.