Skip to main content

Student record 2013/14

Back to C13051

Understanding HIN


Version 1.2 Produced 2014-08-14

What is the HIN?

The HIN is a combination of three fields, the Student.HUSID, the Institution.UKPRN and Instance.NUMHUS, which uniquely identify an instance of study. 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.

HIN = HUSID + UKPRN + NUMHUS

For example, the HIN 9811681234562100077941 represents the registration of Peter Smith on a BSc Mathematics course at The University of Glasgow.

Student.HUSID Institution.UKPRN Instance.NUMHUS
9811681234562 10007794 1
image

HIN = 9811681234562100077941

image 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 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. Only where a student is undertaking two entirely independent courses will they have two instances in a collection.

Peter Smith is studying two courses at The University of Glasgow

Student.FNAMES Student.SURNAME Student.HUSID Institution.UKPRN Instance.NUMHUS Course.COURSEAIM Course.CTITLE
Peter Smith 9811681234562 10007794 1 H00 BSc Mathematics
Peter Smith 9811681234562 10007794 2 H90 Further French

Further guidance is available from HEFCE on the reporting of multiple instances for students studying for credit.

How the HIN link works

The HIN is 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. 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:

Dormant records

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. This will satisfy the requirements of the HIN Report C checks.

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 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.

image 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.

imageHIN Target List

In order to assist institutions with making their returns to HESA, a target list of students for whom a record is required is provided. This HIN Target List will be produced by the data collection system, following a successful commit, and will be applicable to the following year's return. The report lists all continuing students for whom a HIN record is expected to be returned in the following year.

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. Breaks in the HIN link will cause HIN validation errors when the data is committed.

Breaking the HIN that links the records by incorrectly changing Instance.NUMHUS

Changing the data returned in Instance.NUMHUS between years could result in the incorrect conclusion that the instance relates to Peter Smith's progress onto another instance. This can be caused by a program error mistakenly updating Instance.NUMHUS on an annual basis.

YEAR Student.FNAMES Student.SURNAME Student.HUSID Institution.UKPRN Instance.NUMHUS Course.COURSEAIM Course.CTITLE
1 Peter Smith 9811681234562 10007794 1 H00 BSc Mathematics
2 Peter Smith 9811681234562 10007794 2 H00 BSc Mathematics

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.

YEAR Student.FNAMES Student.SURNAME Student.HUSID Institution.UKPRN Instance.NUMHUS Course.COURSEAIM Course.CTITLE
1 Zoe Brown 1111727788999 10007852 1 I60 Graduate diploma in Biological Science
2 Zoe Brown 0000571234565 10007852 1 I60 Graduate diploma in Biological Science

Assigning the Instance.NUMHUS to an instance (HE)

When should the HIN change?

A student should be allocated a new HIN (different NUMHUS) when:

  • the student transfers to a course at a different level of study*
  • the student completes a course and proceeds to take another

* Level of study is defined by broad level for the purposes of HIN between postgraduate, undergraduate and further education course aims. An exception is made where the student is studying on an intercalated degree in which case the same Instance.NUMHUS should be retained even where the intercalation is at a different level.

image

image Details of which Course.COURSEAIMs are categorised at each level of study are listed in derived field XLEV301.

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.

Maintaining the HIN Link (HE)

The following examples set out the guidelines for assigning Instance.NUMHUS and maintaining the HIN link.

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.UKPRN Instance.NUMHUS Course.COURSEAIM Course.CTITLE
1
9811681234562 10007794 1 H00 BSc Mathematics
2 9811681234562 10007794 1
H00 BSc Mathematics

There are some cases when it is not expected that Instance.NUMHUS will be retained. These include cases where the previous instance has been successfully completed and where the student withdraws or suspends studies on the previous instance and then returns to study a separate programme.

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 of study, 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.

i. Transfer by changing subject within the same level - do not change the Instance.NUMHUS

YEAR
Student.HUSID Institution.UKPRN Instance.NUMHUS Course.COURSEAIM Course.CTITLE
1
9811681234562 10007794 1 H00 BSc Mathematics
2 9811681234562 10007794 1 H00 BSc Physics

ii. Transfer by changing course aim within the same level - do not change the Instance.NUMHUS

YEAR
Student.HUSID Institution.UKPRN Instance.NUMHUS Course.COURSEAIM Course.CTITLE
1
9811681234562 10007794 1 J30 HND Mathematics
2 9811681234562 10007794 1
H00 BSc Mathematics

In both of i and ii, 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 the studies leading to the second course aim.

YEAR
Student.HUSID Institution.UKPRN Instance.NUMHUS Course.COURSEAIM Course.CTITLE
1
9811681234562 10007794 1 H00 BSc Mathematics
2 9811681234562 10007794 2 H90 Reflexology

In this example 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.

Further guidance is available from HEFCE on the reporting of multiple instances for students studying for credit.

d) Normal progression

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.UKPRN Instance.NUMHUS Course.COURSEAIM Course.CTITLE
1
9811681234562 10007794 1 L00 MPhil
2 9811681234562 10007794 1
D00 PhD

This would also be the case where a foundation degree and top-up are combined within one course of study.

YEAR
Student.HUSID Institution.UKPRN Instance.NUMHUS Course.COURSEAIM Course.CTITLE
1
9811681234562 10007794 1 J10 Foundation degree Chemistry
2 9811681234562 10007794 1
H00 BSc Chemistry (top-up)

e) Intercalated degrees

When students intercalate to a second degree as part of their overall programme, the intercalation should be reported on the same instance of study. Instance.NUMHUS should be retained and Instance.COMDATE should not be updated.

To identify the intercalating year the Course.COURSEAIM should be altered for that year of the course. 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. Instance.INTERCALATE should be populated with 01 for the duration of the intercalation.

For example, the student below intercalates from their Integrated Masters in Medicine to the third year of a Bachelor degree in Biotechnology.

YEAR
Course.COURSEAIM Course.CTITLE Instance.NUMHUS Instance.YEARSTU Instance.YEARPRG Instance.INTERCALATE
(new field from C13051)
1 M26 Masters in Medicine 1 1 1 n/a
2 M26 Masters in Medicine 1 2 2 n/a
3 H00 Masters in Medicine 1 3 3 01
4 M26 Masters in Medicine 1 4 3 n/a

The student follows the first two years of the 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. In effect the student is recorded as Instance.YEARPRG 3 twice: once for the intercalation and once for the medical degree. The length of study undertaken by the student is shown through the Instance.YEARSTU field.

How should intercalated years be reported when it is being conducted at a different institution?

These students should be returned as dormant by the institution at which they are undertaking their main studies for the year in which they are intercalating at another institution.

How should a student be returned by the institution at which they intercalate?

Where a student joins another institution for the intercalating year, the HEI at which they are intercalating must return the student in the Student record. For example, a student intercalates in their third year. The institution at which they undertake the intercalated year records the student with an Instance.COMDATE reflecting the date at which the student comes to the institution rather than the commencement date of the instance at the first institution. Instance.YEARPRG should be incremented to reflect that this is the intercalating year, therefore if the intercalation occurs in the third year Instance.YEARPRG should be coded 3. The Instance.INTERCALATE flag must be completed in the intercalating year.

YEAR
Course.COURSEAIM Course.CTITLE Instance.COMDATE Instance.YEARSTU Instance.YEARPRG Instance.INTERCALATE
(new field from C13051)
3 (intercalating year) H00 Bachelors in Biotechnology 2010-08-31 1 3 01

f) Withdrawals

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

YEAR
Student.HUSID Institution.UKPRN Instance.NUMHUS Course.COURSEAIM Course.CTITLE
1
9811681234562 10007794 1 H00 BSc Mathematics
2 9811681234562 10007794 1
H00 BSc Mathematics

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

YEAR
Student.HUSID Institution.UKPRN Instance.NUMHUS Course.COURSEAIM Course.CTITLE
1
9811681234562 10007794 1 H00 BSc Mathematics
3 9811681234562 10007794 1
H00 BEd
image It is recognised that some student record systems do not allow the Instance.NUMHUS to be retained for withdrawals. If this is the case allocating a new Instance.NUMHUS is acceptable. However, maintaining the HIN is seen as best practice.

g) Students who spend part of their time overseas

i. Where it is known at the beginning of the course that the student will spend more than 8 consecutive weeks in the UK as part of their course they should be included in the Student record throughout, and will appear on the HIN target list until the instance is closed. Where a student commences studies in the UK but then unexpectedly moves to complete their studies abroad they will need to remain in the Student record until the instance is closed.

For the year(s) where the student spends part or all of the year abroad, Instance.LOCSDY should be coded as 'S' to indicate the student has spent more than 8 consecutive weeks in the UK. Instance.STULOAD should be reduced in these years to reflect only that part of the course undertaken in the UK.

ii. Where study in the UK is optional and it is not known at the outset whether or not the student will come to the UK they should be included in the Aggregate Offshore Collection initially. A full Student record, including entry profile, will need to be returned if and when the student comes to the UK. The COMDATE returned in the Student record should reflect the start of the instance rather than the date at which they came to the UK.

image This will create a HIN error B as the Instance.COMDATE will reference a previous HESA reporting year. In these circumstances these HIN B errors are permissible and can be passed by HESA.

Assigning the Instance.NUMHUS to a FE instance

Note that the guidance for assigning Instance.NUMHUS for FE courses differs from that for HE courses.

a) 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.

YEAR
Student.HUSID Institution.UKPRN Instance.NUMHUS Course.FEQAIMC Course.CTITLE
1
0710571234565 10007851 1 10001086 GCE A level French
1 0710571234565 10007851 2 1000113X GCE A level German

b) FE level courses - the concept of 'normal progression' from one course to another does not apply to FE level courses therefore allocate a new Instance.NUMHUS to the new course

YEAR
Student.HUSID Institution.UKPRN Instance.NUMHUS Course.FEQAIMC Course.CTITLE
1
0710571234565 10007851 1 10001517 GCE AS level French
2 0710571234565 10007851 1
00260005 GCE A2 level French

c) FE level course - student withdraws and returns to study (new course started) at the same level in a future reporting period

Courses with different Course.FEQAIMC codes should not be linked and therefore must have different instance numbers assigned. Note that withdrawal and return to study are treated differently for HE and FE level courses.

YEAR
Student.HUSID Institution.UKPRN Instance.NUMHUS Course.FEQAIMC Course.CTITLE
1
0710571234565 10007581 1 10001086 GCE A level French
3 0710571234565 10007581 2 1000113X GCE A level German

Understanding the HIN Reports

HIN is the linking mechanism used by HESA to track continuing student instances of study between HESA reporting years. The HIN Reports detail potential discrepancies with student instance linking within the inserted data file.

As for other areas of validation HIN checks involve both errors and warnings. To satisfy HIN it is necessary to resolve/explain all errors and/or warnings generated within the HIN reports. HIN checks are split into three different report types; Report A, Report B and Report C. Validation errors can be triggered within each of these reports, with Report A also containing validation warning checks. Full details of the HIN rules each data collection will be provided within the coding manual.

image HIN Reports are split into two parts; HE HIN Reports and FE HIN Reports. The FE HIN Reports are only generated for institutions in Wales and specified institutions in England sending through FE student instances.

HIN statuses

On processing a successful commit transaction the system will run HIN validation. The outcome of this validation will determine both the submission status and the HIN icon displayed. Which HIN icon is displayed is based on thresholds applied to Report B and C errors: Report B threshold = 0.66%, Report C threshold = 0.25% (These thresholds are defined in agreement with the funding councils).

Possible outcomes

Submission status Commit transaction status HIN icon HIN status
Commit Passed, HIN Failed image image HIN errors exist on Report B and/or C and the level of error is above the thresholds, errors could also exist on Report A.
Commit Passed, HIN Failed image image HIN errors exist on Report B and/or C but the level of error is below the thresholds, and/or errors exist on Report A.
Committed image image No HIN errors on Report A, B or C.

How does the status change from 'Commit Passed, HIN Failed' to 'Committed'?

Once all outstanding HIN errors have been resolved/explained HESA will process a COMMIT (HESA) transaction in order for the submission to pass HIN validation.

Submission status Commit transaction status HIN icon HIN status
Committed image image COMMIT (HESA): HIN errors exist on Report B and/or C and the level of error is above the thresholds, errors could also exist on Report A. All remaining errors have been explained to HESA (via Minerva).
image Why are the HIN checks so rigorous?
The HIN checks ensure consistency in the key data defining the life of the instance. HIN is therefore important as it is used to track progression of an instance through to completion and to analyse retention rates. The quality of individual level data is important to ensure that there is confidence in using the Student record for onwards analysis. Note that this analysis is only ever conducted against anonymised data and never in ways that could affect individuals.

Fuzzy matching

Fuzzy matching is carried out where a HIN link cannot be found for an incoming continuing student instance. Fuzzy matching highlights cases where the Student.HUSID and/or Instance.NUMHUS (and sometimes Instance.COMDATE) may have been changed incorrectly between years.

The fuzzy matching process looks at the HIN Register of student instances for the submitting institution and attempts to match on:

  • Student.BIRTHDTE where not null on the incoming record
  • NAMECAT (Student.SURNAME + ',' + first character of Student.FNAMES (where SURNAME exists on the incoming record)
  • Level of study (Derived field XLEV301)*

*An exception is made for students commencing or returning from an intercalating year

Matching constraint:

  • SKE instances (Course.TTCID = F) are only linked to other SKE instances and are not matched where Instance.COMDATE is more than 2 years old

Matching exclusions:

  • The instance on the HIN Register is closed with a qualification obtained.
  • The last year in which 'live' record was sent to HESA was more than 4 years ago.

Report A

HIN link found but there is conflicting year-on-year data within the instance

Report A considers a range of fields within the return where it is not expected that the data will change between instance years. These are split into a series of separate errors and warnings. When viewing the HIN Report the system will as a default only display those Report A rules which have been triggered by the submission. Clicking the 'Show zero values for current transaction' link will display the full list of Report A HIN validation rules run against the data.

Errors are triggered where:

  • The data returned last year has been overwritten this year with a 'not known' code
  • Specific data items that are not expected to be updated have been changed
  • Type of instance has been altered

Warnings are triggered where:

  • The data returned last year has been changed to a different valid entry

How to resolve

  • If the data submitted this year is incorrect, the record should be amended and resubmitted
  • If the data submitted this year is correct and represents a genuine data improvement this should be confirmed via Minerva

Report B

Error: No HIN link can be found for a submitted instance that has a COMDATE in a previous reporting period

Category 1 of 2: Possible match found

Where a direct HIN match cannot be located for a student instance fuzzy matching is undertaken against the HESA database to find potential matches. These matches are listed under category 1.

Reason for error How to resolve
Instance has been returned with the wrong HUSID and/or NUMHUS this year Amend HUSID and/or NUMHUS and resubmit
COMDATE is incorrect and should refer to a date in the current HESA reporting year Amend COMDATE and resubmit
COMDATE is correct and the instance does not link to the possible match. The student instance was mistakenly left out of the earlier HESA Student record when the instance commenced, e.g. a late enrolment that did not get transferred onto the system in time Confirm to HESA (via Minerva) why the instance has not been returned previously

Category 2 of 2: No match found

Where no matches can be found for a continuing student (i.e. an instance that did not commence in the current reporting period) this will be listed under category 2.

Reason for error How to resolve
COMDATE is incorrect and should refer to a date in the current HESA reporting year Amend COMDATE and resubmit
The student instance was mistakenly left out of the earlier HESA Student record when the instance commenced, e.g. a late enrolment that did not get transferred onto the system in time Confirm to HESA (via Minerva) why the instance has not been returned previously

Report C

Error: No HIN link can be found for an instance included on last year's HIN Target List

Category 1 of 2: Possible match found

Where a direct HIN match cannot be located for a student instance fuzzy matching is undertaken against the HESA database to find potential matches. These matches are listed under category 1.

Reason for error How to resolve
Instance has been returned with the wrong HUSID and/or NUMHUS this year Amend HUSID and/or NUMHUS and resubmit
COMDATE is incorrect and should refer to a date in the current HESA reporting year Amend COMDATE and resubmit

Category 2 of 2: No match found

Where no matches can be found for a student instance listed on the Target List the instance will be listed under category 2.

Reason for error How to resolve
The student instance was 'live' during the current HESA reporting year and has been missed out of the submission A 'live' record should be submitted
The student instance was not 'live' during the current HESA reporting year A dormant record should be submitted and leaving information returned if appropriate

HIN compare facility

For the second and subsequent successful test-commit/commit transactions the HIN report will provide comparison information. This additional functionality within the HIN report displays the number and percentage of HIN errors and warnings in the current transaction alongside the change since a previous transaction for comparison.

image The comparison will default to the current and immediately prior transaction. If you wish to change the comparative transaction you are able to select a different transaction number in the drop down menu. Note that the comparison can only be between the current and a previous transaction.

The table includes the difference in value and/or percentage since the previous transaction. Each column will display the difference between transactions followed by the actual value for the previous transaction in brackets. Pink signifies an increase in errors, blue signifies a decrease in errors and black will signify no change in errors from previous transactions. The report can be used to improve the quality of data between transactions.

Contact Liaison by email or on 01242 211144.