00/04 - November
Dear Colleagues
The 2000/01 (Dec) HESA Student Record Collection (Ref C00011A)
This Circular sets out the plans for the C00011A data collection.
Timescales for Collection
The critical dates in this collection are as follows:
| Return date | Institutions are required to send complete and valid data to HESA no later than Monday 15 January 2001. |
| COMMIT target date | Institutions are encouraged to attempt a COMMIT transaction no later than Monday 22 January 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. |
| 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 2 March 2001. |
| Database closure | In order to meet obligations for hand-over of data to customers, HESA will stop processing student returns on Friday 10 March 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 (http://www.hesa.ac.uk/valid/2000/00html.htm). These kits contain all of the validation checks that are run when files are submitted to HESA.
COMMIT-stage validation checks in the C00011A collection
| Check | Severity |
| If multiple occurrences of INSTID, HUSID and NUMHUS appear then fail | 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 (RECID=YY011 and If FESTUMK = 1 or 3 and GLHRS = 0 or blank) | 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] | Warn |
| 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] | Warn |
| 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] | Warn |
| 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] | Warn |
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
When reporting back the duplicates, code in another report that slots in before the duplicate 4 report that identifies and reports the occurrence of a single type 1 and single type 3 error record for the same student (type 5).
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 |
| Age as at 1 August 2000 is less than 16, and not '##' | Warn |
| Report as warning any records where XDOMCT01 not in (2826, 3826, 4826, 5826, 6826, 7826, 8826, GREU) and FUNDCODE=1 | Warn |
| If (RECID=YY011 and If FESTUMK = 4 and GLHRS = 0 or blank) | Warn |
| If FESTUMK = 1, 3 or 4 and FEQAIM not in (FE Qualaim DBF) | Warn |
Check Documentation
Once a return has successfully passed the COMMIT stage, check documentation [verification information] will be downloadable from the web site (see New Method of Returning Student data to HESA section below) and so will no longer be emailed or posted to you. HESA will also begin scrutiny of the return at this point and may wish to raise quality issues with the Student record contact at this time.A copy of the check documentation template, along with the definitions used in the analyses, can be found on the HESA WWW site at http://www.hesa.ac.uk/datacoll/check.htm.
New Method of Returning Student data to HESA
The 2000/01 HESA Student Record data collection will utilise a new web-based data collection system. This 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 27 November.
Colleagues who have used this system for other HESA data collections should be able to use their existing accounts for the collection. In these cases, the access code will need to be entered under the ‘Add Group' section of Registration details.
The web address for the new data collection system is http://submit.hesa.ac.uk. This site provides step-by-step instructions on how to send a Student return to HESA.
Where the previous data collection system utilised FTP for submission of data and control files, the new data collection system operates entirely via a web interface. The previous transactions CREATE, REPLACE and APPEND are replaced with the transactions INSERT and DELETE. The INSERT transaction adds data to your return and the DELETE transaction deletes any file from your return (invalid files are automatically deleted from the database). Previous Insert transactions that should not be included in the final file must be deleted otherwise it will result in multiple records. As with the previous system, the COMMIT transaction should be submitted when all of the data for your institution has been inserted and successfully passed validation. The web interface removes the need for any control files.
Errors, Warnings, Frequency Counts and Verification Information will be downloadable from this web site and will no longer be emailed or posted to you.
To make full use of the new 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 address in brackets next to them. You may wish to ask your local IT support team to do this for you.
The 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, Frequency Counts 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. To complete your return you will need to print off the reply slip for the latest check documentation and return that to HESA.
Who to Contact During Data Collection
Institutions should consider Institutional Liaison as a general first point of contact for any HESA issue.
|
Alison Berry (alison.berry@hesa.ac.uk)
Overall responsibility for data collection operations
Helen Skitt (helen.skitt@hesa.ac.uk)
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, e.g.
|
New computer systems
As a result of data quality checking institutions data we are increasingly aware of problems due to institutions changing computer packages. We would recommend that institutions ensure that when installing a new computer system a facility is in place to migrate the data from the old system to the new system. Fields such as Highest qualification on entry will often see a large increase in ‘Not known' values after a new computer system is installed. It is particularly critical that the Field 151/136 Student instance number is migrated correctly for all continuing students. Field 151/136 Student instance number is an up to 20 character alphanumeric code. Software must be capable of holding up to 20 characters in this field - we are aware that this is not currently the case for certain software. If the student instance number is changed during the migration to a new computer system this can result in all continuing students for the institution being marked as non-completers. Institutions must ensure that, regardless of software changes, previous Student instance numbers are maintained for continuing students.
Further Information
If you have any queries on the issues raised in this Circular, please contact the Institutional Liaison team (Helen Skitt, Alison Berry or Janet Earl) at HESA, or email (liaison@hesa.ac.uk).
Yours sincerely
Director of Operations
