Tel: 01242 255577
Fax: 01242 211122
In November 2005 HESA and UCAS published a joint statement regarding a corruption in the calculation of the check digit in the UCAS application number for some 2006/07 applications. This Circular aims to provide a timely reminder for institutions about this issue and the agreed approach to working around this problem.
A copy of the full statement follows below.
If you have any queries on the issues raised in this Circular please contact the HESA Institutional Liaison team at HESA (firstname.lastname@example.org).
Director of Quality and Development
This paper defines the problem relating to the UCAS application number, considers its downstream impact and suggests a solution for mitigating the effects of this problem in onward use of the data.
There has been an error in the calculation of the check digit on some UCAS application numbers. The problem relates to applicants for the 2006/07 academic year and involves a single batch of applicant numbers. These numbers can be defined as being in a particular range (See Appendix); every number in this range has a check-digit calculated on a different basis to the standard UCAS method. Therefore the range of failure can be precisely defined and the failure is consistent and predictable.
By chance, some of the check digits calculated using the incorrect algorithm coincide with what the check digit should have been, were it calculated with the correct algorithm.
The application number is effectively the primary key for the application process, both at UCAS and within institutions. Since these corrupted numbers have been released – and are being used in application decisions – it is not possible to correct these numbers. Any potential correction would involve deleting the application and putting the student back through the application process from the beginning. This is not a feasible solution.
Any process that attempts to validate the application number using the check digit will be affected by this problem. The superset of processes will include processes within HEI systems – UCAS are speaking with software providers and individual HEIs on this issue.
UCAS are also liaising with the SLC on this issue.
The UCAS number is used twice in the HESA record; once in its raw form (UCASNUM) and once as an element within the HESA student identifier (HUSID) for those students that entered through UCAS.
UCASNUM is collected to identify students that entered through UCAS for their current programme and to identify which UCAS system the student entered through. It is also used by HEFCE to link to the UCAS database.
The HUSID is defined as four zeros plus the UCAS application number for those students that have entered through UCAS and do not already have a HUSID. The HUSID check digit uses the same algorithm as the UCAS number and the padding of the field with zeros means that a HUSID based on a correctly calculated UCAS number will pass the HUSID checksum validation tests. It therefore follows that a HUSID based on an incorrectly calculated UCAS number will fail the HUSID checksum validation tests (except in those cases where, by chance, the correct and incorrect checksums coincide).
The proposed solution for the UCASNUM field in the HESA record is to collect the UCAS application number in its original form, including any incorrectly calculated check digits. This will necessitate an extension to the HESA validation on the UCASNUM field, to identify the erroneous batch and allow incorrectly calculated check digits to pass by re-creating the incorrect algorithm.
This solution means that HEIs do not need to change the UCAS application number and that subsequent links to the UCAS database will retain their integrity.
In the *J transaction, UCAS will generate a HUSID based on a corrected UCAS application number. (The *J transaction also includes the UCASNUM field – this will be the application number including any erroneous check digits).
The proposed solution for HUSID is to offer three options to HEIs.
All of these options result in the HUSID check digit being calculated (and validated) correctly. Whichever option HEIs choose to generate the HUSID, the principle that the HUSID should not change once allocated is absolutely fundamental to the quality assurance and onward analysis of the HESA database.
18 November 2005
The applications that are have an incorrectly calculated checksum can be identified as follows:
The checksum should be calculated as the modulus 10 value of the sum of the products using the weights 1, 3, 7, 9, 1, 3, 7, 9. The applications noted in the ranges above were calculated using the weights 0, 3, 7, 9, 0, 3, 7, 9.