00/02 - June
Dear Colleagues
The 1999/00 (July) HESA Student Record Collection (Ref C99011B)
This Circular sets out the plans for the C99011B data collection.
Timescales for Collection
The critical dates in the collection are as follows:
| Return date | Institutions are required to send complete and valid data to HESA no later than Friday 15 September 2000. |
| COMMIT target date | Institutions are encouraged to attempt a COMMIT transaction no later than Friday 22 September 2000 (institutions are reminded that more validation is performed on a COMMIT request and that the return can be rejected as invalid at this stage). A successful COMMIT will trigger the generation of check documentation, the Target list for the July 2001 Student Return and the POPTAR list for the 1999/00 FDS collection. |
| Last submission of data files | In order to meet obligations for hand-over of data to customers, HESA needs to receive all data files by Friday 27 October 2000.. |
| Database closure | In In order to meet obligations for hand-over of data to customers, HESA will stop processing student returns on Friday 3 November 2000. |
| Late return of results (LLR) |
As
with previous collections, institutions are able to submit results and
leaving information later than the main data return date. All LLR files
must however be returned and successfully committed no later than Friday 3 November 2000.
A successful COMMIT of LRR data will result in the generation of a new pack of check documentation, a new Target list for the July 2001 Student Return and a new POPTAR list for the 1999/00 FDS collection. |
| LRR database closure | In order to meet obligations for hand-over of data to customers, and to allow the commencement of processing of December 2000 returns, HESA will stop processing LLR data on Friday 3 November 2000. |
Student Record Validation
As with previous recent data collections, two stages of validation
take place; 'Submission level' validation and 'COMMIT-stage' validation.
Validation kits for the submission level validation rules are
available from the Validation section of the HESA WWW server (http://www.hesa.ac.uk/valid/1999/00html.htm).
These kits contain all of the validation checks that are run when
files are submitted to HESA.
COMMIT-stage validation checks are only run once
a COMMIT request has been received by the data collection system.
These checks can only operate within a database-type environment
and, therefore, cannot be included in the submission level validation
kits. Institutions are reminded that any return that fails
COMMIT-stage validation will require a resubmission to be made.
Institutions are therefore advised to attempt to COMMIT their
data as soon as they have sent the entire return in and have received
the appropriate frequency counts and status report.
There are no new commit-level checks for 1999/00 (apart from the specific HIN checks, see section below), but listed below are the rules that were implemented last year and will again be run this year.
COMMIT-stage validation checks in the C99011A
collection
| Check | Severity | |
| If multiple occurrences of INSTID, HUSID and NUMHUS appear then fail | Error | |
| If a MODID is quoted on the Student Record (YY012) then that module must exist on the Module Record (YY013) | Error | |
| Duplicate MODID within the YY013 data | Error | |
| Incorrect INSTID in data | Error | |
| If 2 records have the same HUSID then the Date of Birth and Gender must be consistent | Error | |
| If FESTUMK = 1 or 3 and GLHRS = 0 or blank
if (RECID=YY011 and If FESTUMK = 1 or 3 and GLHRS = 0 or blank) OR (RECID=YY012 and FESTUMK = 1 or 3 and STULOAD <> 000.0 or LOCSDY <> 4 or 5 and GLHRS = 0 or blank) |
Error | |
| If RECID = YY012/YY112 and LOCSDY =1 and PCOLAB > 000.0 in any module | Error | |
| If RECID = YY012/YY112 and LOCSDY = 2 or 3 and PCOLAB = 000.0 in all modules | Error | |
| If FE student (QUALAIM codes 53-55, 71-83, 99), qualification obtained cannot be at PG or UG level (QUAL1 or QUAL2 codes less than or equal to 52) | Error | |
| If multiple occurrences of INSTID, HUSID and QUALAIM appear in cases where QUALAIM in (02 - 52) and MODE in (01, 23, 24, 52, 53) and DATELEFT is blank then fail(Type 1) | Error | |
| If multiple occurrences of INSTID, HUSID and QUALAIM appear in cases where QUALAIM in (61, 62, 97, 98) and MODE in (01, 23, 24, 52, 53) and DATELEFT is blank then warn (Type 2) | Warning | |
| If multiple occurrences of INSTID, HUSID and QUALAIM appear in cases where QUALAIM in (02 - 52, 61, 62, 97, 98) and MODE not in (01, 23, 24, 52, 53) and DATELEFT is blank then warn (Type 3) | Warning | |
| If multiple occurrences of INSTID, HUSID and QUALAIM appear in cases where QUALAIM not in (02 - 52, 61, 62, 97, 98) and DATELEFT is blank then warn (Type 4) | Warning | |
| If multiple occurrences
of INSTID, HUSID and QUALAIM appear in cases where QUALAIM in (02 - 52,
61, 62, 97, 98) and DATELEFT is blank then warn (Type 5) [See technical spec. below] |
Warning |
The Decision tree for the Type 1, Type 2, Type 3 and Type 4 commit-stage validation rules is :
Start : Duplicate INSTID, HUSID, QUALAIM, DATELEFT where DATELEFT is blank.
QUALAIM 02 - 52 MODE 01, 23, 24, 52, 53 result = Type 1 Otherwise result = Type 3 61, 62, 97, 98 MODE 01, 23, 24, 52, 53 result = Type 2 Otherwise result = Type 3 Otherwise result = Type 4Additional Type 5 report = occurrence of a single Type 1 and single Type 3 error record for the same student.
COMMIT checks continued:
| If multiple occurrences of BIRTHDTE, GENDER, soundex (SURNAME), soundex (FNAMES) and different HUSIDs and RECID is not YY21x, YY31x, YY41x then warn | Warning | |
| If sum of Module FTEs for a student is greater than (STULOAD+100.0) then warn (July collections only) | Warning | |
| Age as at 1 August 1999 is less than 16, and not ‘##' | Warning | |
| Report as warning any records where DOMICILE not in (UK or EC) and FUNDCODE=1 | Warning | |
| If FESTUMK = 4 and GLHRS = 0 or blank if (RECID=YY011 and If FESTUMK = 4 and GLHRS = 0 or blank) OR (RECID=YY012 and FESTUMK = 4 and STULOAD <> 000.0 or LOCSDY <> 4 or 5 and GLHRS = 0 or blank) |
Warning | |
| If FESTUMK = 1, 3 or 4 and FEQAIM not in (FEFC Qualifications database) | Warning | |
| MODRES01 blank for all cases of RECID = YY012/YY112 for the complete return | Warning | |
| QUALAIM in (02, 04, 06, 14) and TYPEYR = 1 | Warning | |
| For full-time first
degrees (MODE = 01, 23-24 and QUALAIM = 19-24) report as warning any
records where YEARPRG is inconsistent with the level of credit shown in
LEVLCRD1/Module LEVLPTS.[If LEVLCRD1/Module LEVLPTS = 1-4, then YEARPRG
should be 1 if LEVLCRD1/Module LEVLPTS = 1, 2 if LEVLCRD1/Module
LEVLPTS = 2 etc.] [See technical spec. below] |
Warning |
LEVLCRD technical spec.
Start: QUALAIM in (19-24) AND MODE in (01, 23, 24, 52, 53) AND YEARPRG <> 99
Combined 011 or 111
Check that if LEVLCRD1 or LEVLCRD2 have values in the range 1 to 4 then check that either of them is the same as YEARPRG, if not warn.
Student/Module 012 112
Check that LEVLPTS for any of the modules that the student is studying have values in the range 1 to 4 then check that any of them for is the same as YEARPRG, if not warn.
New HIN Validation Checks and Warnings
The student record re-development for 1998/99 onwards introduced the concept of a Student instance number, with each record being uniquely defined by the combination of field 4, Student identifier, and field 2, Institution identifier, and field 151/136, Student instance number (HUSID + INSTID + NUMHUS or HIN). Linkage between different years of the student on the programme of study will be through HIN. The re-development also established that once a record had been returned for one HESA year, a record with the same HIN is required for subsequent years until it is terminated by either date left, suspension of active studies or mode of study ‘Dormant'. As part of the July 1998/99 data collection, HESA sent target lists to institutions of students for whom a record is expected in this coming July 1999/2000 collection. The following details the checks that will be implemented to monitor the target lists and to verify the linkages. Please note that these checks will be made on HE level records only; FE level records do not return a student instance number. In future, target lists will list HE level records only.
The reports outlined below (A, B and C) will be sent to institutions as attachments to the HIN Validation Checks and Warnings email. Attachments will only be provided where records fail the checks outlined below. The commit-level validation will be performed against all HE-level records to the Static Target List Register created from the 1998/99 July Student Record. The severity of the checks will be at a level of warning, but institutions will be expected to check the credibility of the HIN link. The reports associated with the following checks and warnings will be delivered in a fixed-length format, electronically, in a manner that can be read automatically.
Checks on incoming record against the target list register
A - COMMIT level Checks - match found
1. Warning - HIN match in TLR, Level differs (UG/PG based on QUALAIM)
Institutions have made an explicit HIN link but this is queried because the two linked records are for qualification aims at a different level (PG/UG based on QUALAIM codes).
Warning - HIN match in live or non-active register, Level differs
The implication here would be that the cases highlighted should be reviewed to see if the linking is appropriate. If not a new NUMHUS should be allocated.
2. Warning - COMDATE after start of reporting period and HIN match in TLR (COMDATE)
Institutions have made an explicit HIN link but this is queried because this is the first year of study (COMDATE after start of reporting period).
Warning - COMDATE after start of reporting period and HIN in live or non-active register
The implication here would be that the cases highlighted should be reviewed to see if the linking is appropriate. If not a new NUMHUS should be allocated. If the linking is correct then the information in field 26, COMDATE, should be changed back to the original COMDATE as held in the register.
3. Warning - HIN match in TLR, conflicting ‘information on entry to programme of study' details (QUALENT2, COMDATE)
Institutions have made an explicit HIN link but this is queried because information on entry to the programme of study details which would not be expected to be up-dated annually are not consistent between years. (Field 21 and Field 26).
Warning - HIN match in live or non-active register, conflicting ‘information on entry to programme of study' details.
The implication here would be that the cases highlighted should be reviewed to check that information in the highlighted fields has not been wrongly up-dated for this HIN.
Note that in cases where a data item was previously Not Known and now has a valid data entry, these records will not be selected as having conflicting ‘information on entry to programme of study' details.
NB. There are other fields in the record that should not change between years. These include fields 5, 8, 9, 12, 13, 14, 15, 16, 18, 19, 23, 24, 25, 75, 148/133, 157/142, 158/143 and 159/144. It is likely that checks will be extended in future years to include some of these fields - particularly where statutory customers advise that their inclusion would help improve data quality for progression statistics used in performance indicators.
4. Warning - HIN match in TLR, conflicting YEARSTU/ENTRYCDE details - YEARSTU not incremented and neither record dormant; YEARSTU incremented and ENTRYCDE the same (YEARSTU, ENTRYCDE)
Institutions have made an explicit HIN link however details which would be expected to be incremented each year have not been up-dated between years for the same HIN. (YEARSTU, ENTRYCDE the same).
Warning - HIN match in live or non-active register, conflicting YEARSTU/ ENTRYCDE details - YEARSTU not incremented and neither record dormant; YEARSTU incremented and ENTRYCDE the same
The implication here would be that the cases highlighted should be reviewed to check that information in the highlighted fields is correctly up-dated for this HIN.
5. Warning - HIN match in TLR, different personal details (BIRTHDTE, GENDER)
Institutions have made an explicit HIN link but there are conflicting personal details (Field 10 and 11).
Warning - HIN match in live or non-active register, different personal details
The implication here would be that the cases highlighted should be reviewed to check that the information in the highlighted fields is correct for this HIN.
Note that in cases where a data item was previously Not Known and now has a valid data entry, these records will not be selected as having different personal details.
Report A for checks 1-5 - fields and layout
| Field Name | Length | Position | Notes |
|---|---|---|---|
| WARNON | 06 | 001 | Indicator for checks warned on, e.g. ‘1-3---‘ indicates warned on checks 1 and 3 |
| HUSID | 13 | 007 | from incoming record |
| INSTID | 04 | 020 | from incoming record |
| NUMHUS | 20 | 024 | from incoming record |
| SURNAME | 10 | 044 | from incoming record, truncated |
| PTITLE | 25 | 054 | from incoming record, truncated |
| OWNSTU | 20 | 079 | from incoming record |
| OWNPSD | 20 | 099 | from incoming record |
| QUALAIM | 02 | 119 | from incoming record |
| QUALAIM | 02 | 121 | from matched Target List Register record |
| MODE | 02 | 123 | from incoming record |
| MODE | 02 | 125 | from matched Target List Register record |
| COMDATE | 10 | 127 | from incoming record |
| COMDATE | 10 | 137 | from matched Target List Register record |
| QUALENT2 | 02 | 147 | from incoming record |
| QUALENT2 | 02 | 149 | from matched Target List Register record |
| YEARSTU | 02 | 151 | from incoming record |
| YEARSTU | 02 | 153 | from matched Target List Register record |
| ENTRYCDE | 01 | 155 | from incoming record |
| ENTRYCDE | 01 | 156 | from matched Target List Register record |
| BIRTHDTE | 10 | 157 | from incoming record |
| BIRTHDTE | 10 | 167 | from matched Target List Register record |
| GENDER | 01 | 177 | from incoming record |
| GENDER | 01 | 178 | from matched Target List Register record |
| (Total length | 178) |
B - COMMIT level Checks - no match found
6. Warning - COMDATE before start of reporting period & HIN not in TLR
Institutions have not made an explicit HIN link but it is queried whether the HIN should provide a link to a previous record, because this is not the first year of study (COMDATE before start of reporting period). COMDATE on or after 01 August 1998 would definitely imply a previous HIN; COMDATEs before 01 August 1998 could pre-date the existence of HIN.
Warning - COMDATE before start of reporting period and no HIN match in Target List Register
The implication would be that the cases highlighted where the COMDATE does not indicate first year of study should be reviewed to see if there should be an explicit linking to an earlier record. If so, the NUMHUS should be changed to be the same as that returned for the earlier record.
Report B for check 6 - fields and layout
| Field Name | Length | Position | Notes |
|---|---|---|---|
| WARNON | 06 | 001 | Indicator for checks warned on, always ‘-----6' to indicate warned on check 6 |
| HUSID | 13 | 007 | from incoming record |
| INSTID | 04 | 020 | from incoming record |
| NUMHUS | 20 | 024 | from incoming record |
| SURNAME | 10 | 044 | from incoming record, truncated |
| PTITLE | 25 | 054 | from incoming record, truncated |
| OWNSTU | 20 | 079 | from incoming record |
| OWNPSD | 20 | 099 | from incoming record |
| QUALAIM | 02 | 119 | from incoming record |
| QUALAIM | 02 | 121 | blank for check 6 as no match found |
| MODE | 02 | 123 | from incoming record |
| MODE | 02 | 125 | blank for check 6 as no match found |
| COMDATE | 10 | 127 | from incoming record |
| COMDATE | 10 | 137 | blank for check 6 as no match found |
| QUALENT2 | 02 | 147 | from incoming record |
| QUALENT2 | 02 | 149 | blank for check 6 as no match found |
| YEARSTU | 02 | 151 | from incoming record |
| YEARSTU | 02 | 153 | blank for check 6 as no match found |
| ENTRYCDE | 01 | 155 | from incoming record |
| ENTRYCDE | 01 | 156 | blank for check 6 as no match found |
| BIRTHDTE | 10 | 157 | from incoming record |
| BIRTHDTE | 10 | 167 | blank for check 6 as no match found |
| GENDER | 01 | 177 | from incoming record |
| GENDER | 01 | 178 | blank for check 6 as no match found |
| (Total length | 178) |
N.B. reports A & B are of a similar format to allow merging of data if required.
Checks on the target list register against the incoming record
C - Target List Register Checks - no match found
7. On TLR but no HIN match to incoming data
Checks against target list to identify missing records i.e. those for whom a record is expected but for which a match cannot be found.
Warning - No incoming record can be found to match the following HINs held on the active register and for whom a record is expected
The implication here is that institutions either have missing records, or that the records are present in their returns but have not been allocated the correct NUMHUS to establish the correct HIN link. If this is the case, the records should be re-submitted using the original NUMHUS as held in the live register. Any records remaining on the live register with no match found will be marked as ‘assumed dormant' and may be treated as non-completion in progression statistics.
Where a HUSID/QUALAIM match can be found to the incoming data, this is indicated as a possible record that should be linked by NUMHUS. Note that multiple possible matches can occur; if more than two exist this is indicated by a ‘*' in the field OTHERS.
Report C for check 7 - fields and layout
| Field Name | Length | Position | Notes |
|---|---|---|---|
| WARNON | 01 | 001 | Indicator for check warned on, always ‘7' to indicate warned on check 7 |
| HUSID | 13 | 002 | from unmatched Target List Register record |
| INSTID | 04 | 015 | from unmatched Target List Register record |
| NUMHUS | 20 | 019 | from unmatched Target List Register record |
| SURNAME | 10 | 039 | from unmatched Target List Register record, truncated |
| PTITLE | 25 | 049 | from unmatched Target List Register record, truncated |
| OWNSTU | 20 | 074 | from unmatched Target List Register record |
| OWNPSD | 20 | 094 | from unmatched Target List Register record |
| QUALAIM | 02 | 114 | from unmatched Target List Register record |
| MODE | 02 | 116 | from unmatched Target List Register record |
| COMDATE | 10 | 118 | from unmatched Target List Register record |
| NUMHUS | 20 | 128 | from incoming record, possible match #1 or blank |
| NUMHUS | 20 | 148 | from incoming record, possible match #2 or blank |
| OTHERS | 01 | 168 | ‘*' if >2 possible matches, otherwise blank |
| (Total length | 168) |
HIN Validation Checks and Warnings - E-Mail
Reports A, B and C above will be sent to institutions as attachments to the HIN Validation Checks and Warnings E-mail where records exist that require warnings for the above detailed checks.
Note: If there are no records that require warnings, the E-mail will still be sent minus the attachments.
The E-mail will include field names and layout details for the reports.
Also included in the body of the E-mail will be a short management information summary detailing counts of records included in each report, for example:
Report A - COMMIT level Checks - HIN match found in Target List Register
| Check | Count | Notes |
|---|---|---|
| 1 | 000023 | Level differs (UG/PG based on QUALAIM) |
| 2 | 000000 | COMDATE after start of reporting period |
| 3 | 000145 | Conflicting information on entry to programme of study details (QUALENT2, COMDATE) |
| 4 | 000000 | Conflicting YEARSTU/ENTRYCDE details - YEARSTU not incremented and neither record dormant; YEARSTU incremented and ENTRYCDE the same |
| 5 | 002098 | different personal details (BIRTHDTE, GENDER) |
Report B - COMMIT level Checks - no HIN match found in Target List Register
| Check | Count | Notes |
|---|---|---|
| 6a | 000367 | COMDATE before start of reporting period and on and after 01/08/1998 |
| 6b | 000896 | COMDATE before start of reporting period and before 01/08/1998 |
Report C - Target List Register Checks - no HIN match found to incoming data
| Check | Count | Notes |
|---|---|---|
| 7a | 000067 | |
| 7b | 000123 | On TLR but no HIN match to incoming data - HUSID/QUALAIM match found |
Checking target list registers
Where a return does not include some records on the target list, institutions have the option of providing a dormant record, or authorising HESA to, in effect, create such a record. However, the Funding Councils, and HESA, recommend that this should not be done without clear evidence that the student has indeed simply temporarily discontinued his or her studies.
Through the experience gained in the producing of PIs, the Funding Councils have found that poor data quality can often create the impression that studies have discontinued prior to completion. Some of the more common problems found are:-
- Students have qualified, but the qualification obtained field has not been returned, either in the original record, with late results, or even as a qualification from dormant status.
- A new HUSID has been created. (A new HIN would have the same effect.)
- No records have been returned at all for some students.
If the records on the target list are not included for any of the above reasons, and the institution, without investigation, simply signs off the return, thus allowing HESA to create the equivalent of dormant records, a completely misleading picture of the institution's progression rates will be created.
Currently the Funding Councils publish PIs on the progression of full-time first degree students, so that records pertaining to these students should be prioritised when investigating any shortfalls with respect to the target list.
Check Documentation
Once a return has successfully passed the COMMIT stage, check documentation will be automatically printed and despatched. HESA will begin scrutiny of the return at this point and may wish to raise quality issues with the student record contact.
A copy of the check documentation template, along with the definitions used in the analyses can be found soon on the HESA WWW site at (http://www.hesa.ac.uk/datacoll/check.htm).
Late Return of Results (LLR)
As with previous years' collections, institutions have the option to return results and leavers information via the ‘Late Return of Results'. Valid and complete data must be returned to HESA by Friday 3rd November 2000. All LRR submissions must have a record identifier of 99511 or 99512 and a 'CREATE' transaction in the control file. Only the LRR fields (as defined in Appendix 9 of the Student Record Coding Manual and with the addition of Field 36 Good standing marker for FE records) will be validated and loaded to the database. The late return of results does not provide institutions with an opportunity to update any other parts of the database.
A valid submission will be matched to the existing database using the fields HUSID, INSTID and NUMHUS (HIN) for HE level students and a matching report will be generated. For FE level records where Student Instance Number (NUMHUS) is not collected a valid submission will be matched to the existing database using the fields INSTID, HUSID and QUALAIM. (The LRR will need to be committed to the database in the same way as the main student return. Once committed, new check documentation and updated Target lists and POPTAR lists will be generated and despatched.
Due to the changed arrangements for data collection of the 1999/2000 First Destination Supplement [to the Student Record] (FDS) (see section below) HESA has had to bring forward the date by which late return of results (LRR) files must be returned and successfully committed. Note then that database closure for both the main student return and for any LLR files will be Friday 3 November 2000. Note also that following HESA systems developments, a new web-based data collection, designed to provide institutions with greater usability and a faster response to submissions, will be adopted for the student return in 2000/01. On introduction of this new data collection system, it is proposed that HESA removes the option of completing a Late Return of Results reduced record. If you would have serious problems with the removal of LLR, then please contact Institutional Liaison at HESA.
Arrangements for the 1999/2000 First Destinations Supplement Data Collection (FDS)
There is a government requirement that an employability performance indicator (PI) will be published that is based on the 1999/2000 FDS return. This PI will be at an institutional level and will be produced by HEFCE, on behalf of the Performance Indicators Steering Group. The publication date is 31 March 2001. Consequently it has been agreed that certain changes will be made to the data capture arrangements for the FDS, in order to meet ministerial expectations of improved robustness of the data now it is to be used as a basis to produce performance indicators. These changed arrangements (which apply specifically to the PI sub-population of the FDS) mainly affect colleagues involved in returning the FDS, but there are also implications for the student return. The particular effects on student record colleagues are:
- The likely requirement to provide information from the student records system to assist with preparation for the mailing of FDS questionnaires. There is a first scheduled mailing of FDS questionnaires in the week of 25 September 2000. Many FDS colleagues will rely on their institution's student record systems (i) to indicate those students in the target population, and (ii), to provide contact addresses for those students.
- The strong encouragement to COMMIT the student return as early
as possible in order to generate POPTAR lists for the FDS. Institutions
may consider an early COMMIT to generate a POPTAR, even in the
knowledge that a de-commit and resubmission of data will be necessary
before the student data can be finally signed-off.
- The bringing forward of the date by which late return of results (LRR) files must be returned and successfully committed. Database closure for both the main student return and for any LLR files is Friday 3 November 2000. This is in order to have all POPTAR lists available by Friday 10 November, at the latest, so that all institutions will have seen the official POPTAR lists from HESA before the second scheduled mailing of FDS questionnaires in the week of 20 November 2000.
- Student data stream colleagues are therefore asked to liaise closely with first destination colleagues at each institution to establish best practice for their institution.
FDS Populations
1. POPTAR
The target population for the FDS (POPTAR) is the same as last year with the exception that non-EU overseas domiciled students are now excluded. Channel Islands and IOM domiciled students will still be included in POPTAR, although not in the PI population. Non-EU overseas students will be excluded by their domicile code.
In terms of coding within the Individualised Student Return, a student is counted within the POPTAR population when all of the following criteria are met:
| MODE= | |
|---|---|
| 01/ | Full-time according to Funding Council definitions |
| 02 | Other full-time (If expected length of study programme 24 weeks or more) |
| 23 | Sandwich (thick) according to Funding Council definitions |
| 24 | Sandwich (thin) according to Funding Council definitions |
| 25 | Other sandwich course/programme (If expected length of study programme 24 weeks or more) |
| 41 | Writing up and requiring more than 2 hours of supervision/week. (Continuing Students only) |
| 42 | Writing up and requiring less than 2 hours of supervision/week. (Continuing students only) |
| 43 | Writing-up - previously full-time. |
QUAL1 or QUAL2 =
| 02 | Doctorate degree mainly by research |
| 03 | Doctorate degree not mainly by research |
| 04 | Masters degree mainly by research |
| 05 | Masters degree not mainly by research |
| 06 | Postgraduate bachelors degree mainly by research |
| 07 | Postgraduate bachelors degree not mainly by research |
| 12 | Ordinary PGCE |
| 13 | Articled PGCE |
| 19 | First degree with eligibility to register to practice (doctor/dentist/veterinary surgeon) |
| 20 | First degree with Qualified Teacher Status/registration with General Teaching Council |
| 21 | First degree |
| 22 | Enhanced first degree |
| 23 | First degree and diploma (to be obtained concurrently) |
| 29 | Diploma of Higher Education |
| 30 | Certificate of Higher Education |
| 41 | HND |
| 42 | HNC. |
LOCSDY<> 7 (Whole of the programme outside the UK)
RSNLEAVE <> 05 ( Death)
DOMICILE =
1610 - Austria
1614 - Belgium
1641 - Denmark
1651 - Finland
1653 - France
1656 - Germany
1659 - Gibraltar
1661 - Greece
1676 - Irish Republic
1678 - Italy
1693 - Luxembourg
1710 - Netherlands (Holland)
1728 - Portugal
1751 - Spain
1755 - Sweden
3826 - Channel Islands
4826 - Isle of Man
5826 - England
6826 - Wales
7826 - Scotland
8826 - Northern Ireland
(In addition, if Domicile information is not provided, then an assumption of UK is made unless DOMICILE = ‘1782' or ‘1783' and FEEELIG = ‘2'.)
2. The PI Population
The employability PI population consists of UK-domiciled students obtaining first degrees following full-time study. Whether a student is in this population or not will be indicated on the POPTAR lists issued by HESA.
In terms of the HESA student record base codes, the definition of the employability PI sub-population of POPTAR is:
RECID in (99011, 99012)
DOMICILE in ‘5826', ‘6826', ‘7826',
‘8826' (In addition, if Domicile information is not provided, then an
assumption of UK is made unless DOMICILE = ‘1782' or ‘1783' and FEEELIG
= ‘2'.)
QUALAIM in (19-52, 61, 97)
QUAL1 or QUAL2 in (19, 20, 21, 22, 23)
MODE in (01, 23, 24)
LOCSDY <> 7
RSNLEAVE <> 5
Other Performance Indicators
HEFCE have asked HESA to point out that, although this year the Funding Council is accepting data amendments for incorporation into the performance indicators (PIs) calculations, in future, it will be expected that the data supplied and signed-off to HESA is correct, and that this data may be used without amendment.
In view of this expectation, you are asked to particularly check the following fields on individual student records, which are all used in producing the performance indicators and the institutions' benchmarks.
Student and Combined records
The key fields for the PIs are:-
| Field name | Field number - combined record | Field number - student record |
|---|---|---|
| QUALENT2 | 21 | 21 |
| ALEVPTS | 23 | 23 |
| HIGHPTS | 24 | 24 |
| COMDATE | 26 | 26 |
| QUAL1 | 37 | 37 |
| QUALAIM | 41 | 41 |
| MODE | 70 | 70 |
| YEARPRG | 72 | 72 |
| ALEVELS | 157 | 142 |
| HIGHERS | 158 | 143 |
| VOCQUALS | 159 | 144 |
The following fields are also used:-
| Field name | Field number - combined record | Field number - student record |
|---|---|---|
| BIRTHDTE | 10 | 10 |
| LASTINST | 18 | 18 |
| OCCCODE | 25 | 25 |
| SBJQA1 - SBJQA3 | 43 - 45 | 43 - 45 |
| POSTCODE | 75 | 75 |
The commonest mistakes in the individual student records affecting the PIs that HEFCE have found are:
- miscoding YEARPRG, so that students appear to remain in the same year, or skip a year;
- omitting QUAL1 values for students who have obtained a qualification.
Both of these errors have serious effects on the progression rates obtained.
Finance Record
For you information, HEFCE also use the following information from the Finance Record to construct some of the PIs:
Total value (column 9) in TABLE 4 (Research Grants and Contracts), for cost centres, and Academic Staff Costs (column 1) in TABLE 6 (Expenditure by Activity), for academic departments.
Further Guidance on the Student Record 1999/00
The guidance below has been developed in conjunction with HESA's Statutory Customers.
Field 3 Campid
A separate campus identifier should be used if the student is studying on a campus at a substantial distance from where the main institution is based, such that it would be regarded as being in a different region (county) of the country. The need for this information is becoming more critical with an increased emphasis on regional analysis.
Field 15 Disability Allowance
Field 16 Disabled
The guidance for completing these fields for a student
receiving Disabled Student Allowance (DSA), but who has not advised the
institution of the nature of their disability is that Field 15
Disability Allowance should be coded 4 ‘The student has a disability
and is in receipt of Student Disability Allowance' and Field 16
Disabled should be coded as 09 ‘A disability not listed above'.
Field 21 Highest qualification on entry
Field 157 A and AS levels
Field 158 SCE Highers and CSYS
Field 159 Vocational qualifications at Level 3/Advanced
The three fields ALEVELS, HIGHERS and VOCQUALS, (fields
157, 158 and 159 in the combined record, 142, 143 and 144 in the
student record) introduced with the 1998/99 record re-development are
intended to distinguish between A-levels, Scottish Highers, and Level 3
vocational qualifications. Institutions are therefore encouraged to
complete these fields for all students where Qualent2 is returned as
code 40, and not just those entering through UCAS. In addition, it is
expected that in most cases a code other than 99 would be used.
Detailed codes giving the numbers of A levels, Highers and Vocational
qualifications are expected for UCAS entrants - i.e. not codes 97 or
99.
Field 25 Occupational Code
The occupational code and social-economic indicator are of particular importance to the Government for the purposes of monitoring the uptake of HE by students from different social backgrounds. Institutions are encouraged to provide this information for all students with a qualification aim of PGCE, first degree, HND, HNC or Dip HE (i.e. shown as code 12, 19-24, 29, 41-42 in field 41 QUALAIM). The guidance is that for students under 21 the coding reflects the occupation of the parent,step-parent or guardian who has or had the highest income in the household in which the student was brought up. If he or she is retired or unemployed give the most recent occupation. For those 21 and over it is the student's own occupation which is coded.
Field 52 Special programmes
Code 09 ‘Other' - use of this code for FE level students at institutions in England will be interpreted as meaning ‘dedicated provision delivered for an employer, normally on the employer's premises'.
Field 68 Major Source of Tuition Fees
Students entering under the new student support arrangements in 1998/99 and beyond: for the academic/financial year 1999/00, the Student Loans Company (SLC) will be paying the public contribution of fees for those students who had their assessments for eligibility and financial support towards their fees carried out by English and Welsh LEAs, DFHETE/Northern Ireland Education and Library Boards or in the case of EU students in England and Wales, by the DFEE.
For the purposes of coding Field 68 Major source of tuition fees, students for whom a public contribution to fees has been assessed as payable should be coded according to the body that carried out the assessment. Thus, English and Welsh LEAs should be coded 02, DFHETE/Northern Ireland Education and Library Boards should be 04 and EU students in England and Wales assessed via DFEE should be coded 02.
The Student Loans Company will be sending Fee Notification Reports to institutions, which notify the public contribution towards student tuition fees that has been assessed. The first four characters of the student support number appearing in these schedules will allow the assessing body to be identified. Students who have been assessed by DFHETE/Northern Ireland Education and Library Boards will have one of the following codes: NBFT, NEST, NSET, NSTH, NWES or NDAN. EU students in England and Wales will have the code EURS. All other students on the SLC schedules will have been assessed by English or Welsh LEAs.
Tuition fees for Scottish domiciled students [and EU students in Scotland] will still be distributed by SAAS and so will not appear on the SLC schedules. These students should be coded 03 in Field 68.
For students who are covered by the previous student support arrangements (all of their fee automatically paid by English and Welsh LEA, SAAS and DFHETE/Northern Ireland Education and Library Boards) should continue to be coded 02, 03 or 04 as appropriate.
Institutions are reminded of the general guidance for completing Field 68 in that code 01 should include students who have applied to an LEA, DFHETE/Northern Ireland Education and Library Boards or SAAS and been assessed to receive no fee support and have to pay the complete amount, as well as those students who decide not to be assessed by the LEA and pay the complete amount themselves. Code 01 should only be used where the student pays all the fees themselves and there is no element of support. Codes 02 - 97 should be used where somebody other than the student pays the total or a proportion of the tuition fees i.e. where there is some element of support, however small. Analysis of the July 1998/99 Student Record showed that there is inconsistent coding of this field. Some institutions appeared to be overly using code 02 ‘English or Welsh LEA award (Student Award Agency)' for their home domiciled full-time undergraduate students (some approaching 100%) and some overly using code 01. As a broad guide, for English and Welsh domiciled entrants to full-time first degree, HND and DipHE courses in 1999/00 nationally, the DfEE is expecting 36% of students to be paying the full fee themselves.
Field 70 Mode of study
It is expected that students who are returned as full-time on funding council early statistics would be coded as 01 ‘Full-time according to Funding Council definitions'. Investigations by the funding councils have shown that some institutions are coding students as 02 ‘Other full-time', when code 01 is the appropriate coding.
Codes 52 and 53 should only be used for study related years out which count towards the qualification aim. Language years out that are not classed as thick sandwich programmes should be coded 52 or 53 in the year the student is abroad.
Misuse of dormant records
Institutions are reminded that if a student is active at any time during the academic year, a dormant record must not be returned.
Investigations by the funding councils have revealed that dormant records have been returned for some entrants who have left during their first year of study, sometimes to transfer elsewhere. Since COMDATE is not included in the reduced record for dormant students, it is not possible to simply identify such cases on receipt of the return. Institutions themselves, however, may be able to make sure that no dormant records are returned for students whose commencement date is within the academic year.
Field 71 Location of study
This field has codes that are not mutually exclusive. The following rules should apply:-
1 = 1 AND NOT (4 OR 5 OR 6 OR 7 OR 8)
2 = 2 AND NOT (7)
3 = 3 AND NOT (7)
4 = 4 AND NOT (2 OR 3 OR 7)
5 = 5 AND NOT (2 OR 3 OR 7)
6 = 6 AND NOT (2 OR 3 OR 7 OR 8)
8 = 8 AND NOT (2 OR 3 OR 7)
Field 72 Year of Programme
Foundation Years
The year of programme of study should only be coded as 0 for foundation courses of a particular type. The term 'foundation course' is applied to a range of quite different HE and FE provision, but in this context its use is restricted to:
'a course, offered by an institution of higher education, which is designed to prepare students for entry specifically to the first year of an associated named degree or diploma (e.g. HND) programme offered by that institutions, and successful completion of which guarantees progression to that degree or diploma programme'.
The prospectus description of such courses is usually something like 'four year BSc course with foundation year', making it clear that the foundation year is an integral part of the course. If a student on such a course attends full-time, and satisfies the domicile and other conditions, then he or she will be eligible for a full-time undergraduate loan and means tested regulated fee. The conditions were originally set out in DfEE Circular 9/92.
Foundation or 'year 0' years fall into two broad categories:
- 'Conversion' foundation courses are for students with traditional entry qualifications (A-levels) in subjects that are not relevant to their chosen subject of study in higher education.
- 'Preparatory' foundation courses provide a route to higher education for those who do not have traditional entry qualifications; they are particularly aimed at mature students.
Note that a full-time degree programme that includes a foundation year will be one year longer than an equivalent standard full-time degree programme.
Year of programme should not be coded as 0 for courses described as 'foundation' in a different sense from that described above. For example, 'foundation courses' in Art and Design, which are usually at further education level, some 'foundation' courses leading to professional qualifications, and common first years of degree programmes taken by all students within a faculty, which are sometimes called 'foundation' years, should not be coded as year of programme = 0.
Fields 100-145 Cost Centres 1-16
The cost centre breakdown, whether returned through the separate Student and Module structure or the Combined Record structure, must reflect the individual student's actual programme of study and not the norm for the programme of study as a whole. The HESA return is an individualised student record.
Field 117 - 132 Module Result 1-16
In 1999 the funding councils did not publish performance indicators based on module results, because of a number of data problems, but their intention is to do so in the future, probably from 2000. As advised in Circular 99/01, the indicators will initially only relate to part-time undergraduate programmes. Institutions should therefore make every effort to complete the module result field. Institutions are reminded that a blank should only be returned when a module is continuing into the next academic year.
In Circular 99/01 a particular problem was identified for institutions that return their FTE for courses following a non-standard academic year using the '100:0' method, for those modules starting in one academic year and finishing in another. In order that their results could be included in the performance indicators, institutions were given the opportunity to return a module identifier and result in the following year, so long as the module FTE was 000.0.
Experience has since shown that in some cases, though a module is completed in an academic year, the result is not know in time to include with the return. This can create a similar problem to that described above, for all institutions, not just those using the '100:0' method of returning FTE. In these cases institutions may now also return a module identifier in the following year with the module result, again so long as the module FTE is 000.0.
In the past, as part of the data collection process, HESA has not allowed module data when the student record has shown a student FTE (field 74) as 000.0. In 1999/2000, validation will be changed to permit this. This will enable the funding councils to use late module results in the production of PIs.
Students who leave before 1 Dec
Institutions are required to return records on both the December and July returns for all students active within the HESA reporting periods. However, it was recognised that this requirement would place a considerable burden on institutions. Guidance in the 1998/99 HESA Student Record Coding Manual was amended therefore to permit ‘anyone who leaves a programme of study so early that they are discounted as a starter in the institution's own records' not to be returned to HESA. Following work carried out by the HEFCE, wide variation in practice has been discovered. To allow consistent analysis of HESA records the following guidance is intended to replace that previously given.
Institutions need not return records for students who start a course and leave within the first two weeks without completing. Students who start a course and do not leave within the first two weeks will need a record returned on all applicable datasets. It should be noted that any records returned for students who start a course and leave within the first two weeks without completing will be excluded from any progression analyses by Statutory Customers or HESA. If a student is registered at the institution on the 1 December they must be returned to HESA whether they leave within the first two weeks of the programme or not. There are no current plans to create Performance Indicators (PI) based on early leavers but there is a policy interest in the extent to which students leave early in the course.
HESA Training Seminars
Due to the considerable demand for the HESA training seminars, HESA has organised a repeat of the introductory student training seminar held in May. The student seminar will be held at Cheltenham and Gloucester College of HE on Tuesday 15 August 2000. The aim of the seminar is to provide delegates with an overview of HESA, the records, the data collection mechanism and the processes of data quality. If you are interested in attending this seminar please contact Janet Earl or Clara Elcocks at HESA. There is a booking fee of £25.00 per delegate to cover the cost of the seminar and a buffet lunch.
Further Information
If you have any queries on the issues raised in this
Circular, please contact the Institutional Liaison office (Helen
Skitt, Alison Berry or Janet Earl) at HESA, or email (liaison@hesa.ac.uk).
Yours sincerely
Director of Operations
