01/02 - June
Dear Colleagues
THE 2000/01 (JULY) HESA STUDENT RECORD COLLECTION (REF C00011B)
This Circular sets out the plans for the C00011B 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 by Saturday 15 September 2001. |
| COMMIT target date | Institutions are encouraged to attempt a COMMIT transaction no later than Friday 21 September 2001. 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 2002 Student Return and the POPTAR list for the 2000/01 FDS collection. |
| Last submission of data files | In order to meet obligations for hand-over of data to its customers, HESA needs to receive all data files by Friday 2 November 2001. |
| Database closure | In order to meet obligations for hand-over of data to its customers, HESA will stop processing student returns on Friday 9 November 2001. |
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 (index.php?option=com_content&task=view&id=607&Itemid=233). 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-stage validation checks for 2000/01.
COMMIT-stage validation checks in the C00011B 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 [See technical spec below]) | 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 [See technical spec below]) | 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 [See technical spec below]) | 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 [See technical spec below]) | 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 4
Additional 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 | |
| Report as warning any records where DOMICILE not in (UK or EC) and FUNDCODE=1 | Warning | |
| If FESTUMK = 4 and GLHRS = 0 or blankif (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 specification.
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.
HIN
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’.In general, the assumption should be that if a student continues to study at the same level (that is undergraduate or postgraduate) at the same institution, then this is treated as the same student instance. Where a student transfers programmes by changing subject or even qualification aim within the same level this would not, in general, lead to a change of the student instance. It does not matter whether the studies already taken count towards the current qualification aim or not. Where a student transfers programmes, the logical outcome of the first programme is that the student changed to studying on the new programme - this is shown explicitly by keeping the same student instance number. Replacement pages are issued for fields 26, 30 and 151/136 deleting all reference to whether the studies already taken count towards the current qualification aim or not. As part of the July 1998/99 data collection, HESA produced target lists for institutions of students for whom a record was expected in the July 1999/2000 collection. For your information, these target lists will be re-issued to institutions by email to the liaison contact in the week ending 29 June. Similar lists will be produced during the processing of the July 2000/01 return, which will be applicable to the 2001/02 July returns.
New HIN Validation Checks and Warnings
The following details the checks that will be implemented as part of the commit-level validation to monitor the target lists and to verify HIN linkages between 1999/00 and 2000/01. The comparison will be based on whether there is a HUSID-INSTID-NUMHUS (HIN) match between the two years. Please note that these checks will be made on HE level records only; FE level records do not return a student instance number.
The checks will be performed against all HE-level records to the Static Target List Register created from the 1999/00 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 will be readable on the data collection web page and there will also be associated downloadable files.
The checks can be divided into 4 distinct categories:
- There is a link but there are data quality issues revealed by linking the 2 records (checks 1-5)
- There is no link for an incoming record which commenced before the reporting period (check 6)
- There is no incoming record for a HIN with ‘live’ status in last year’s data (check 7) (live means DATELEFT blank, NOTACT blank, MODE not equal to 61, 63 or 64)
- There is no link but a DOB/POSTCODE/LEVEL match exists, suggesting that the two records should be linked by HIN (check 8).
A) There is a link but there are data quality issues revealed by linking the 2 records
(checks 1-5)
The data quality issues may be in one of 5 areas:
Check 1, HIN link, Level differs
Check 2, HIN link, COMDATE after start of reporting period
Check 3, HIN link, Conflicting information on entry to programme of study details
Check 4, HIN link, Expected information not incremented
Check 5, HIN link, Different personal details.
Institutions are asked to review the cases highlighted and where appropriate to alter the incoming record for 2000/01 to resolve the data quality issue.
B) There is no link for an incoming record which commenced before the reporting period (check 6)
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 (as indicated by COMDATE being before the start of the reporting period). The cases highlighted should be reviewed to see if there should be an explicit linking to a record in a previous return. If so, the HIN link should be restored by changing the NUMHUS and/or HUSID to be the same as that returned in the earlier record.
For some records that fail the type 6 check, it is possible to suggest a record in the institution's previous return to which they should be linked based on matching the student by Date of Birth and Postcode and the student instance by Level. However either the NUMHUS or the HUSID has been changed for the incoming record so that the HIN link is broken. Suggested links should be examined, and if they are genuine, then the NUMHUS and HUSID in the incoming record should be restored to their original value to re-create the HIN link.
C) There is no incoming record for a HIN with ‘live’ status in last year’s data (check 7) (live means DATELEFT blank, NOTACT blank, MODE not equal to 61, 63 or 64)
The implication here is that institutions either have missing records, or that the records are present in their incoming return but have not been allocated the correct NUMHUS or HUSID to establish the correct HIN link. If this is the case, the records should be re-submitted using the original NUMHUS or HUSID as held in last year’s data. Any records remaining on the live register with no match found will be marked as ‘assumed dormant’ and can be treated as non-completion in the progression statistics. It is very important that institutions check that they have reported any qualifications obtained for these students. Qualifications obtained which missed being reported in one reporting period should be reported as results from dormant status in the following reporting period (MODE must equal 61, 63 or 64).
For some records that fail the type 7 check, it is possible to suggest a record in the incoming dataset to which they should be linked based on matching the student by Date of Birth and Postcode and the student instance by Level. However either the NUMHUS or the HUSID has been changed for the incoming record so that the HIN link is broken. Suggested links should be examined, and if they are genuine, then the NUMHUS and HUSID in the in-coming record should be restored to their original value to re-create the HIN link.
D) There is no link but a DOB/POSTCODE/LEVEL match exists, suggesting that the two records should be linked by HIN (check 8)
These records have not failed either check 6 or 7. However DOB/POSTCODE/LEVEL matching suggests that they do describe the same student continuing to study on the same overall programme of study although the institution has closed one student instance and opened another. A proliferation of student instances is not required. Suggested links should be examined and if they are genuine, then the NUMHUS (and if necessary, the HUSID) in the incoming record should be restored to the original value to re-create the HIN link. A distinction is drawn between records for which no qualification has previously been reported (QUAL1 previously blank) and those for which a qualification obtained has previously been reported and where therefore the closure of one record and the commencing of another is more likely to be legitimate (QUAL1 previously not blank).
HIN and progression statistics
Ultimately it is intended that progression statistics and progression performance indicators will be based on analysis of these HIN links.
HEFCE have asked HESA to point out that although previously the Funding Council has accepted data amendments for incorporation into the performance indicators (PIs) calculations, it is now 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 type 7 errors for HIN indicating potential missing records that can adversely affect the progression performance indicators for an institution by inflating the number of non-completers. It is very important that institutions check that they have reported any qualifications obtained for these students. Qualifications obtained which missed being reported in one reporting period should be reported as results from dormant status in the following reporting period (MODE must equal 61, 63 or 64).
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. Future PIs may be extended to cover other groups.
Any records remaining on the live register with no match found will be marked as ‘assumed dormant’ and can be treated as non-completion in the progression statistics.
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 or as a qualification from dormant status.
- A new HUSID or NUMHUS has been created so breaking the HIN tracking link.
- No records have been returned at all for some students.
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. A dormant record explicitly returned by the institution can include Dateleft and Qualification obtained where appropriate. A record assumed dormant by HESA will have neither of these fields completed.
In essence an institution's data for 2000/01 for the progression statistics will be made up of two parts: (a) records sent in by the institution in their July return and (b) all check 7 records missing from the target list from 1999/00 and marked as 'assumed dormant' by HESA. Institutions are accepting both elements (a) and (b) in signing-off their 2000/01 July student data. 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 authorising HESA to create assumed dormant records, a completely misleading picture of the institution's progression rates can be created since a record assumed dormant by HESA can have neither the Dateleft nor Qualification obtained fields completed.
Check Documentation
Once a return has successfully passed the COMMIT stage, check documentation will be downloadable from the web site (see Method of Returning Student data to HESA section below) and so will no longer be emailed or posted to you. At this point HESA will also begin scrutiny of your return 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 analyses, can be found shortly on the HESA WWW site at index.php?option=com_content&task=view&id=111&Itemid=233.
(FEFCE)/LSC ISR files from the December Record – Institutions in England
Last year some problems were experienced with the processing of files through the FEFC funding software. HESA have therefore re-visited the agreed mapping with the LSC and re-programmed the ISR look-alike files. If you would the revised version of the ISR December files to be emailed to you please contact Institutional Liaison (liaison@hesa.ac.uk).
Clarification about the use of UCAS data in making HESA returns
As announced in Report 01/02, published by HEFCE in January, UCAS, HESA and the funding councils, in consultation with government education departments, have agreed an implementation plan designed to improve the links between data captured by UCAS and data that institutions provide to HESA.Record contacts may not be aware that currently there are a series of transfer records available from the UCAS on-line record transfer system (MARVIN) that should be used to assist institutions in the use of UCAS data in making returns to HESA in 2001-02. Following Report 01/02, UCAS and HESA have identified where each of the items in the HESA Student Record originally coded by UCAS appear in these UCAS transactions. For clarification therefore details of these MARVIN transactions are contained in a table that will shortly be published on the websites of both organisations. Where mapping from the MARVIN source is necessary, as indicated in the table, the underlying algorithms will also be made available via the web. Descriptions of the processing checks applied to this data by UCAS are also shown in the table. This document can be found on both the HESA and UCAS websites. WWW page at XXXXXXXX:
Institutions should use these MARVIN transactions in making their 2001-02 submission and feed back to UCAS/HESA any comments arising from experience of their use. Where the status of a field is ‘Compulsory for UCAS entrants’, it is acceptable for institutions to simply incorporate into the HESA returns the information that UCAS provides, as already coded by UCAS. Institutions may take further steps to improve the accuracy of this information, but are not obliged to do so in 2001-02. In the case of entrants for whom UCAS has supplied a ‘not known’ value in a particular field, institutions may simply copy this across into the HESA returns: it is not necessary to ask the students concerned for the missing information. (In these cases the default ‘not known’ or ‘not stated’ codes should be used, rather than returning a blank).
Institutions should carry forward the information obtained from UCAS into their HESA returns for these students for subsequent years of the programme of study.
The implementation plan referred to above also includes a commitment by UCAS to work towards the introduction of the new HERCULES admissions system that will include a user-friendly facility which will enable institutions to download appropriate data relating to all the 2002/03 HESA fields for which data from specified applicants has originally been collected by UCAS. This information will be pre-processed from the UCAS sources that most closely match HESA definitions and presented in exactly the same format as required for the 2002/03 HESA record, for use in preparing HESA returns for entrants in the 2002/03 academic year onwards.
Further details about HERCULES and the procedure for downloading the data required by HESA will be available in due course from UCAS. UCAS and HESA will also make available descriptions of the processing checks applied to this data by UCAS.
Method of Returning Student data to HESA
The 2000-01 HESA Student Record data collection will utilise the web-based data collection system. This system is designed to provide institutions with greater usability and a faster response to submissions.Colleagues in institutions will need to register as users of the data collection system in order to administer their submission. Registration requires an access code, which will be emailed to Student record contacts during the week commencing 23 July 2001.
Colleagues who have already created user accounts for the web-based data collection system can use these accounts for the Student Record collection, but will need the access code issued to enter this collection. Existing user account holders will then need to add themselves to the group for this particular Student collection through the ‘Registration Details’ section of the data collection system site.
The web address for the data collection system is http://submit.hesa.ac.uk.
This site provides step-by-step instructions on how to send a Student Record to HESA.
The data collection system operates via a web interface and uses transactions to identify the processes to be undertaken. The INSERT transaction adds data to your return and the DELETE transaction deletes any selected file from your return. The COMMIT transaction should be submitted when all of the data for your institution has been inserted and has successfully passed validation. The web interface removes the need for any control files.
You can send data in either its standard raw format (ASC/CSV) or compressed using pkzip/winzip. Compressing data can sometimes solve the problem of not being able to send large amounts of data through your institution’s Firewall (the protection between your computer and the Internet). Please look at the online data collection system help for further information on identifying and solving problems that might be experienced when sending data.
Errors, Warnings, Frequency Counts and Check Documentation and other information will be downloadable from this web site and will no longer be emailed or posted to you.
To make full use of the data collection system you need to use one of the following web browsers:
- Microsoft Internet Explorer 4.0 or above (http://www.microsoft.com/windows/ie/)
- Netscape Navigator 3.0 or above (http://www.netscape.com/)
- Microsoft Internet Explorer 3.0 with the file upload add-on installed
- Any other RFC 1867-compliant browser.
Most browsers can be downloaded free of charge from the Internet. The browsers above can be obtained from the addresses in brackets next to them. You may wish to ask your local IT support team to do this for you.
The new data collection system is an interactive system, allowing institutions full control of their data submissions. However, colleagues should note that they need to be pro-active in requesting feedback information from the system - Errors, Warnings and Verification information need to be downloaded from the web page (simply by clicking on the appropriate icon) - these reports will no longer be emailed or posted to you. Similarly, whilst using the system, you may need to re-activate the web page by pressing the ‘Refresh’ button - otherwise you may think the system has not responded simply because your screen is no longer showing you the live picture. Collection and system news will be displayed on the system through the collection, please read these items as they provide information regarding the ongoing data collection operations.
Student Record Coding Manual 2001/02
Field 37/38 Qualification obtained 1 / 2A new code has been introduced to identify the Foundation degree as a qualification aim. Code 28 ‘Foundation Degree’ is intended to cover those programmes which HEIs are running as Foundation Degrees that are consistent with the 'Statement of Design Principles' for Foundation Degrees being issued by CVCP and SCOP. A replacement page for the 2001/02 Student Record Coding Manual is enclosed, this page was mistakenly not included with Student Circular 00/03.
Further Guidance on the Student Record 2000/01
Field 15 Disabled student allowance
The Funding Councils calculate premium payments using data on the number of students in receipt of a Disabled Students Allowance (DSA) as a proxy measure for the total number of disabled students in an institution. Therefore, it is important that data provided by institutions to HESA is as complete as possible. The Councils recognise that students do not have to declare to their institution that they receive DSA, and that some students will choose not to make the information available. A student's right to refuse to provide such data should continue to be respected.
Field 27 New Entrant to HE
As a result of analysis of this field and visits by HEFCE to institutions it has been identified that many institutions are inferring this information from highest qualification on entry for students rather than directly asking them the question. Institutions should request this information from students during the enrolment/registration process. The New Entrant to HE field is used to indicate whether the student has previously studied at higher education level, at a UK institution, whether or not the course resulted in success. This field is important to the DfES to quantify "initial entrants" to HE.
Medical students
Students on free-standing pre-clinical medicine and dentistry courses should have subject of qualification aim coded as A1 (pre-clinical medicine) or A2(pre-clinical dentistry) and code the qualification aim as 19 (Degree with eligibility to practice). The course length should be coded appropriately for the free-standing course alone and should not take account of any potential future courses required to become a doctor. These students on completion of the course should have their qualification obtained coded as 21 and not 19.
HND to Degree bridging courses
Institutions have flexibility in deciding whether to maintain a HIN link between HND and degree. However, where a student moves directly from an HND or foundation degree to a bridging course and then on to a degree, subsequent analysis using the record is simplified if institutions treat this as a single student instance. We would therefore ask institutions to maintain the same HIN. In many cases this will cause the year of programme of study to become non-standard, but institutions should treat this as being part of a standard year of programme of study.
Where a student takes a significant break between the HND and the bridging course or the bridging course and the degree these may be treated as separate student instances.
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 therefore amended 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 (PIs) based on early leavers but there is a policy interest in the extent to which students leave early in the course.
Performance Indicators
HEFCE have asked HESA to point out that, although previously the Funding Council has accepted data amendments for incorporation into the performance indicators (PIs) calculations, it is now expected that the data supplied and signed-off to HESA is correct, and that this data may be used without amendment.
Staffing changes in Institutional Liaison
After 7 years in post Helen Skitt will be leaving HESA on 20 July. She would therefore like to send her best wishes to colleagues in institutions who deal with the HESA returns. Alison Berry has subsequently been promoted to the post of Head of Institutional Liaison. Marietta Nkweta has recently joined the Institutional Liaison team as an Institutional Liaison Officer. Clara Elcocks will be joining the team during the busy data collection periods. Alison Berry will also be taking maternity leave from mid September.
Who to Contact During Data Collection
Institutions should consider Institutional Liaison as a general first point of contact for any HESA issue.The Institutional Liaison team also cover specific areas as indicated below:
| Alison Berry (alison.berry@hesa.ac.uk)
Overall responsibility for data collection operations Marietta Nkweta (marietta.nkweta@hesa.ac.uk) Janet Earl (janet.earl@hesa.ac.uk) Clara Elcocks General mailbox: liaison@hesa.ac.uk |
The liaison team cover the following specific areas as well as being a first point of contact for any HESA issue:
|
If you have any queries on the issues raised in this Circular, please contact the Agency’s Institutional Liaison office (Alison Berry, Janet Earl or Marietta Nkweta) at HESA, or email (liaison@hesa.ac.uk).
Yours sincerely
Director of Operations
