HESA Student Record 2007/08
HESA Student Record 2007/08Year-on-year linkage (HIN) |
return to index |
Version 1.4 Produced 2008-07-31
Frequently asked questions about year-on-year linkage
| 1. Does the student instance identifier need to be completed for students on FE courses? | Yes the coverage of Instance.NUMHUS specifies that the field must be completed for all instances regardless of the level of the course. |
| 2. Do student instance identifiers for students on FE courses have to start at 1? | The format of the student instance identifier will be dependent on the way in which the institution’s system currently generates values for HE instances. The field length is 20 to allow institutions to use an identifier held internally. However institutions may find it easier to use a simpler format (e.g. 1 or A). A student can have more than one instance but each instance must be identified by a different Instance.NUMHUS. The combination of Student.HUSID and Instance.NUMHUS must be unique within a given data collection. |
| 3. 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 which case an active instance will be required. |
| 4. 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. (See also Q3). |
| 5. Will a HIN error be raised for students who commenced an instance before 1994/95 and then return in 2007/08 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'. |
| 6. 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 currently kept on the HIN register for a further year after closure. This process has been revised and from 2005/06 instances that are closed off properly will held on the 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. |
| 7. 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. |
| 8. From 2007/08, submitting entry profile data for students continuing on an instance is optional. How will data on the entry profile be included in the HIN checking process for 2007/08? | For continuing students, HESA will map entry profile data from the 2006/07 student record across to the 2007/08 record for any purposes deemed necessary. It is therefore essential for institutions to resolve all of the HIN issues that are raised during the 2006/07 data collection. In exceptional circumstances, where entry profiles are submitted in 2007/08 for continuing students in order to correct errors in data submitted previously, institutions will be required to confirm that these are data quality improvements. |
| 9. How will FE instances that span the 2006/07 and 2007/08 reporting periods be linked? | In order to link FE instances that span the 2006/07 and 2007/08 reporting periods, institutions should either provide entry profile information again in 2007/08 or return student instance numbers in the 2006/07 data to allow linking to entry profile information in subsequent years. |
| 10. 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? |
a) Once an instance has been returned for one HESA year, an instance with the same combination of Student.HUSID and Instance.NUMHUS will be required for subsequent years, until an explicit end statement has been received indicating that the student has:
b) If a current year instance is submitted without entry profile information, the current year instance must link to an instance submitted in a previous year. If the year-on-year linking mechanism cannot produce a link, entry profile information will need to be returned for the current year instance. This check will be applied to all instances. |
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 define what the student is aiming for e.g. BSc Mathematics. 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 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 identifier 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 identifier of the institution at which the student is registered and the Instance.NUMHUS identifies studies leading to a course aim.
The instance with a HIN of 981168123456201681 represents the registration of Peter Smith on a BSc Mathematics course at The University of Glasgow. Whereas the instance with a HIN of 981168123456201682 represents the registration of Peter Smith on a Further French course 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.
Adoption of the UK provider Reference Number (UKPRN)
The HESA Student Record specification now includes the UKPRN as the institution identifier. The UKPRN is managed by the UK Register of Learning Providers and is being adopted as the standard institution identifier across the education sector. The INSTID field is no longer a part of the data that institutions must submit to HESA. However, for the purposes of the year-on-year linking described in this document, UKPRN and INSTID will act interchangeably.
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. An instance with a HIN of 981168123456201681 represents the registration of Peter Smith on the BSc Maths course at The University of Glasgow. Whenever an instance that details Peter Smith’s progress on this BSc Maths course is returned to HESA by the institution, the instance must have a HIN of 981168123456201681.
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 no longer 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) even those where the student has been dormant throughout the current reporting year, by submitting 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 to provide a permanent end statement 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 to institutions 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 as well as generating 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 2: Breaking the HIN linking the records by 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 3: Breaking the HIN linking the instance by changing Student.HUSID Changing the data returned in Student.HUSID between years could result in the incorrect conclusion that the instance relates to a different Peter Smith.
|
The role of the Student.HUSID in maintaining the HIN link
Incorrectly assigning more than one Student.HUSID to a 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 HE experience. 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. 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.
| YEAR | Student.HUSID | Institution identifier | Instance.NUMHUS | Course.COURSEAIM | Course.CTITLE |
| 1 | 9811681234562 | 0168 | 1 | H00 | BSc Maths |
| 2 | 9811681234562 | 0168 | 1 | H00 | BSc Maths |
b) Transfers by changing subject or course aim within the same level
Where a student transfers courses by changing subject or even course aim 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, 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.
i. Transfer by changing subject within the same level - do not change the Instance.NUMHUS
| YEAR | Student.HUSID | Institution identifier | Instance.NUMHUS | Course.COURSEAIM | Course.CTITLE |
| 1 | 9811681234562 | 0168 | 1 | H00 | BSc Maths |
| 2 | 9811681234562 | 0168 | 1 | H00 | BSc Physics |
ii. Transfer by changing course aim within the same level - do not change the Instance.NUMHUS
| YEAR | Student.HUSID | Institution identifier | Instance.NUMHUS | Course.COURSEAIM | Course.CTITLE |
| 1 | 9811681234562 | 0168 | 1 | J30 | HND Maths |
| 2 | 9811681234562 | 0168 | 1 | H00 | BSc Maths |
In both of these examples, 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.
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 studies leading to the second course aim.
| YEAR | Student.HUSID | Institution identifier | Instance.NUMHUS | Course.COURSEAIM | Course.CTITLE |
| 1 | 9811681234562 | 0168 | 1 | H00 | BSc Maths |
| 1 | 9811681234562 | 0168 | 2 | H90 | Reflexology |
In this example the instances are distinct in that credits from one instance cannot count towards the other. 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. 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 would be treated as a new instance. However, this would not be the case where the student was studying for institutional credits where it would normally constitute a single instance.
| YEAR | Student.HUSID | Institution identifier | Instance.NUMHUS | Course.COURSEAIM | Course.CTITLE |
| 1 | 9811681234562 | 0168 | 1 | H60 | Cert in Maths |
| 2 | 9811681234562 | 0168 | 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 it is treated as a new student instance. Instance.YEARSTU returns to 1 when the new instance begins.
| YEAR | Student.HUSID | Institution identifier | Instance.NUMHUS | Course.COURSEAIM | Course.CTITLE |
| 1 | 9811681234562 | 0168 | 1 | H00 | BSc Maths |
| 2 | 9811681234562 | 0168 | 2 | M00 | MSc Maths |
f) Normal progression - 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.
| YEAR | Student.HUSID | Institution identifier | Instance.NUMHUS | Course.COURSEAIM | Course.CTITLE |
| 1 | 9811681234562 | 0168 | 1 | L00 | MPhil |
| 2 | 9811681234562 | 0168 | 1 | D00 | PhD |
g) Intercalated degrees
When students intercalate a second degree (or another qualification of equivalent level) as part of their overall course, 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 another course to complete a first degree, 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.
h) Withdrawals
Where a student drops out part way through the course 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 Instance.ENDDATE and Instance.RSNEND) should not preclude the institution from re-opening it when studies commence again in a future reporting period.
i. Student drops out and returns to study (course resumed) at the same level in a future reporting period - do not change the Instance.NUMHUS
| YEAR | Student.HUSID | Institution identifier | Instance.NUMHUS | Course.COURSEAIM | Course.CTITLE |
| 1 | 9811681234562 | 0168 | 1 | H00 | BSc Maths |
| 3 | 9811681234562 | 0168 | 1 | H00 | BSc Maths |
ii. Student drops out and returns to study (new course started) at the same level in a future reporting period - do not change the Instance.NUMHUS
| YEAR | Student.HUSID | Institution identifier | Instance.NUMHUS | Course.COURSEAIM | Course.CTITLE |
| 1 | 9811681234562 | 0168 | 1 | H00 | BSc Maths |
| 3 | 9811681234562 | 0168 | 1 | H00 | BEd |
Contact Liaison by email or on +44 (0)1242 388 531.