Student record 2020/21 - Understanding student continuity and the UHN link
Version 1.3 Produced 2021-10-08
- What is the UHN?
- The instance entity
- How the UHN link works
- Breaking the UHN link
- Assigning the Instance.NUMHUS to an instance (HE)
- Assigning the Instance.NUMHUS to a FE instance
- Understanding Student Continuity validation
What is the UHN?
UHN is the linking mechanism used by HESA to track continuing student instances of study between HESA reporting years. The UHN is a combination of three fields, the Institution.UKPRN, the Student.HUSID, and Instance.NUMHUS, which uniquely identify an instance of study. The Institution.UKPRN identifies the provider at which the student is registered, the Student.HUSID identifies the student and the Instance.NUMHUS identifies particular studies leading to a course aim.
UHN = UKPRN + HUSID + NUMHUS
For example, the UHN 1000000098116812345621 represents the registration of Peter Smith on a BSc Mathematics course at The University of Poppleton.
UHN = 1000000098116812345621
The instance entity
The instance entity is defined as a coherent engagement with the provider aiming towards the award of qualification(s) or credit. The Instance.NUMHUS uniquely identifies studies leading to a course aim. A student registered at a provider 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 Poppleton
Further guidance is available from Office for Students on the reporting of multiple instances for students studying for credit.
How the UHN link works
The UHN 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 UHN of 1000000098116812345621 represents the registration of Peter Smith on the BSc Mathematics course at The University of Poppleton. Whenever an instance that details Peter Smith's progress on this BSc Mathematics course is returned to HESA by the provider, the instance must have the UHN of 1000000098116812345621.
Once an instance has been returned for one HESA year, an instance with the same UHN 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. Providers 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 'Continuity report C: Expected instances not returned' checks.
Where dormant or suspended instances are re-opened, an instance with the same UHN 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.
In order to assist providers with making their returns to HESA, a list of students for whom a record is required is provided. This population file 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 UHN record is expected to be returned in the following year.
Breaking the UHN link
The UHN link is broken when a provider incorrectly changes the Student.HUSID and/or the Instance.NUMHUS assigned to a student instance. Breaks in the UHN link will cause Student Continuity validation errors when the data is committed.
Breaking the UHN 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.
Breaking the UHN 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 provider. The Student.HUSID assigned to a given student must never be used for another student.
Assigning the Instance.NUMHUS to an instance (HE)
When should the UHN change?
A student should be allocated a new UHN (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 UHN between postgraduate, undergraduate and further education course aims.
Failure to maintain the UHN 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 UHN Link (HE)
The following examples set out the guidelines for assigning Instance.NUMHUS and maintaining the UHN 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 provider, then this is treated as the same student instance and the Instance.NUMHUS should not be changed from one year to the next.
There are some cases when it is not expected that Instance.NUMHUS will be retained. These include:
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.
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.
In this example the instances are distinct in that credits from one instance cannot count towards the other instance. Where the course aim is provider credit and credits from several courses can be used towards the same qualification, a single instance should be returned; in these cases multiple UHNs should not be generated.
Further guidance is available from Office for Students 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 provider.
This would also be the case where a foundation degree and top-up are combined within one course of study.
When students intercalate to a second qualification (regardless of level) 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.
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 provider?
These students should be returned as dormant by the provider at which they are undertaking their main studies for the year in which they are intercalating at another provider.
How should a student be returned by the provider at which they intercalate?
Where a student joins another provider for the intercalating year, the HEP at which they are intercalating must return the student in the Student record. For example, a student intercalates in their third year. The provider at which they undertake the intercalated year records the student with an Instance.COMDATE reflecting the date at which the student comes to the provider rather than the commencement date of the instance at the first provider. Instance.YEARPRG should 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.
Where a student withdraws part way through the course, and then returns later to the same provider to study at the same level, this is treated as the same student instance. The fact that the UHN has been closed (by completing Instance.ENDDATE and Instance.RSNEND) should not preclude the provider from re-opening the record when studies commence again in a future reporting period.
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 expected population 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 record initially. A full Student record, including entry profile, will need to be returned if and when the student comes to the UK. The Instance.COMDATE returned in the Student record should reflect the start of the instance rather than the date at which they came to the UK.
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.
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
c) FE level course - student withdraws and returns to study (new course started) at the same level in a future reporting period
Note that withdrawal and return to study are treated differently for HE and FE level courses.
Understanding Student Continuity validation
UHN is the linking mechanism used by HESA to track continuing student instances of study between HESA reporting years.
As for other areas of validation, Continuity checks involve both errors and warnings. To satisfy these checks it is necessary to resolve/explain all errors and/or warnings generated.
Full details of the Continuity rules for each data collection are provided within the coding manual.
From the 2020/21 Student collection, the way that Continuity stage validation is implemented will change.
For previous collections, continuity stage validation has been displayed in the 'HE Continuity' report and categorised by Report C, B and A errors, and Report A warnings. From the C20051 collection onwards, the 'HE Continuity' report will be removed from the Data Collection system. The 'Commit passed', 'Continuity failed' status of continuity quality rule errors will also be removed. Instead, triggered rules will be visible in the Data Collection System 'Quality rules' report feature.
From C20051, the majority of continuity errors will be amended to warnings, and the remainder will be implemented as switchable errors. In addition, a number of two-part rules will also be split into two separate rules: (i) Possible match found and (ii) No match found. The full list of continuity quality rules can be found on the corresponding Quality rules page on the coding manual, which can be filtered to show continuity errors and warnings separately. These changes will ensure that providers are still able to commit their data without resolving all the continuity issues. Providers should note that these issues, including warnings, will however need to be resolved or explained in the Issue Management System (IMS) by the Final Commit deadline.
Instead of the 'HE Continuity' report, Continuity quality rules warnings that are still triggering after Commit will be raised via IMS templates to inform users that there are Continuity issues that need to be addressed before submissions can be made credible.
This change has been introduced to further align the Student and Student Alternative records and will also reduce the processing time of Student submissions. It also has the benefit of allowing rule implementations to be tested automatically, rather than manually as per the current 'HE Continuity' report ensuring a greater degree of confidence in quality.
The Continuity checks ensure consistency in the key data defining the life of the instance. The UHN link 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 is carried out where a UHN 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 Continuity register of student instances for the submitting organisation 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
- The instance on the UHN Register is closed with a qualification obtained.
- The last year in which 'live' record was sent to HESA was more than 4 years ago.
UHN link found but there is conflicting year-on-year data within the instance
The validation 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.
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 Issue Management System
Continuity errors: Continuing instances not previously returned
No UHN link can be found for a submitted instance that has a COMDATE in a previous reporting period
Possible match found: Instance.NUMHUS.3
Where a direct UHN match cannot be located for a student instance, fuzzy matching is undertaken against the HESA database to find potential matches.
No match found: Instance.NUMHUS.11
Where no matches can be found for a continuing student (i.e. a 'live' instance that did not commence in the current reporting period).
Continuity errors: Expected instances not returned
No UHN link can be found for an instance included on last year's expected population list
Possible match found: Instance.ENTRYPROFILE.3
Where a direct UHN match cannot be located for a student instance fuzzy matching is undertaken against the HESA database to find potential matches.
No match found: Instance.ENTRYPROFILE.4
Where no matches can be found for a student instance listed on the expected instance population report.
Contact Liaison by email or on +44 (0)1242 388 531.