08/02 - June

Dear Colleagues

2007/08 HESA STUDENT RECORD COLLECTION (REF: C07051)

This Circular contains links to documents and further guidance that are required for the C07051 data collection. Institutions should review the information contained in the following documents:

• Timescales for the Collection
• Validation Overview
• COMMIT Stage Validation Rules
• Validation Kit
• C07051 Data submission guide

Key deadlines

The timetable for submission remains as operated for previous years. Institutions are reminded of starting early to allow time for the necessary data checking. The data collection system will open for submission at the beginning of August.

Institutions are required to send complete data that has passed both schema and business rules to HESA by 15 September 2008. The last submission of files must be made by 31 October 2008. The sign-off slip is required to be completed and returned to HESA, also by 31 October 2008.

Previously announced changes to the Student Record for 2007/08

Institutions should ensure that they refer to the most recent version of the C07051 Coding manual. Institutions have previously been advised of all changes to the coding manual and these are also listed in C07051 Revision history and C07051 Release notes.

Data quality and onward use of the dataset

Institutions are reminded that the HESA Student Record is used for a wide variety of purposes, many of which rely on data of the highest quality. There is no reason to believe the number and importance of such uses will be reduced this year. Uses made of the Student Record data include Performance Indicators, TQI, NSS, heidi, Statistical First Releases and ad hoc enquiries.

Further Guidance

1) Scottish Gaelic and Scottish History

Institutions in Scotland are requested to ensure that where Scottish Gaelic (Gaidhlig) or Scottish History is the subject of the course or module of study the full JACS codes of Q530 Scottish Gaelic and V212 Scottish History are used, in order to facilitate onward analysis of the data.

2) Parental education

Institutions in England and Scotland are reminded that parental education data is a requirement of all entrants to institutions in England and Scotland where EntryProfile.DOMICILE = XF, XG, XH, XI, XK, XL, GG, JE or IM and Course.COURSEAIM = M22, H00, H11, H16, H18, H22, H23, I00, I11, I16, J10, J16, J20, J26, J30, C20, C30 and Instance.REDUCEDI = 00 and Instance.COMDATE is after 2007-07-31. This data will allow the monitoring of widening participation and may be used in the production of future performance indicators.

3) JACS 2.0

Institutions are reminded that the Joint Academic Coding System (JACS) has been updated for 2007/08 from version 1.7 to version 2.0. It is necessary to ensure that all codes have been correctly mapped across for the following subject areas; Hospitality, leisure sport & tourism; Psychology; Biotechnology; and Physical and terrestrial geographical & environmental sciences. The JACS 1.7 v JACS 2.0 mapping document has been provided by HESA to assist this task.

4) Module outcome and module status

For institutions in England HEFCE intends to use data on module completion from the Student Record to inform additional funding for students who complete less than their original study intentions. Therefore, incomplete or erroneous data in this section of the record is likely to adversely affect the amount of funding received.

5) Qualifications on entry

Qualifications on entry data will impact on the benchmarks for performance indicators. Institutions are therefore advised to carefully check the data presented on tariff as part of the suite of check documentation. For institutions in England, HEFCE also intend to use the data derived from the detailed entry qualifications returned for UCAS entrants to calculate UCAS tariff points for use in their widening participation allocation.

6) HESES

The revision to the Student Record for 2007/08 has necessitated a number of changes to the HESES recreation process. Institutions in England are reminded of the existence of HEFCE's web-facility which allows the re-creation of HESES. HEFCE and HESA recommend that institutions use this facility as an early part of their data quality work.

Data Collection

1) Early validation System

The Early Validation System, which opened on 11 June 2008, provides an opportunity for institutions to expose their student data to the full range of validation checks before the data collection system opens. The Early system provides an INSERT transaction that includes Entry Profile checks and a simplified COMMIT transaction. The full range of COMMIT reports (check documentation, HIN Reports, POPDLHE etc.) will not be implemented until the main data collection system opens. This system has been implemented solely to help institutions identify problems in their data at an early stage. Data submitted to the Early system will not be retained by HESA or forwarded to statutory customers.

With the introduction of a new student record for 2007/08 all institutions are strongly encouraged to make use of this facility. The Early System will close at the end of July, in order to enable the main system to go live in early August.

2) Test_Commit facility

The test_commit facility available as part of the main data collection system allows institutions to process a transaction, which, if successful will generate commit stage reports for scrutiny. These reports are for institutions' purposes only and will not be checked within HESA.

Following a successful test_commit, institutions do not have to contact HESA to ‘decommit' data; changes can be made to the submission by inserting and/or deleting files in the normal way. If no changes are required, institutions can process a COMMIT transaction, which will then generate the same commit reports as are produced following the test_commit. However, these reports will also be checked by HESA, and any data quality issues fed back to institutions.

Note that:
· Institutions do not have to process a test_commit; the facility is optional.
· Institutions must however process a COMMIT transaction by 21 September 2008 as detailed in the Timescales for the Collection.

3) Entry Profile report

In addition to schema and business rule checks, an Entry Profile (EP) check will also be carried out as part of INSERT-stage validation. This check cannot be included in the validation kit as it relies on data submitted to HESA in a previous return. The check ensures that for students continuing on an instance, there is a record in a previous year's return that can be HIN linked to the record in the current year's return. Therefore where entry profile data is submitted at the start of the instance but not in subsequent years, the Entry profile check will ensure that Entry profile data can be found and linked to the incoming instance.

The Entry Profile report will detail records failing the following check:

• No HIN link for an incoming instance (submitted without Entry Profile) that commenced in a previous reporting period
  [C07051 Instance EntryProfile Exception 2 (Error)]: EntryProfile entity must exist where the corresponding Instance has not been previously reported (i.e. cannot be found on the EntryProfile register) and corresponding Instance.REDUCEDI = 00, 01, 03 or 04.

4) HIN Processing

The redeveloped 2007/08 Student Record is reliant on robust HIN linking. Information about entrants that is not expected to change in subsequent years is collected once, for new entrants, and not for continuing students. Thus the Entry Profile entity contains fields describing a student's academic and personal history as at the beginning of the Instance, and the Qualifications on Entry entity contains details of the qualifications held by the student when the Instance begins. This information is only required in the year of entry - the Entry Profile and Qualification on Entry entities are only compulsory when a new instance is created. HESA will therefore rely on HIN linkage to link data from these entities to the Instance in subsequent years.

Consequently it is necessary to ensure that HIN linking in 2007/08 onwards is of the highest standard. For this reason, and because statutory customers can afford there to be little or no tolerance in respect of the standard of linking needed in 2007/08, further strengthening of HIN linking was introduced for 2006/07.

The status of COMMIT passed but HIN failed introduced for the 2006/07 Student Record data collection will continue to be operated for 2007/08. If there are any HIN errors then the status of the transaction that would otherwise have passed COMMIT stage validation will be COMMIT passed but HIN failed. Check documentation and all other reports resulting from a successful COMMIT transaction will be produced when an outcome of COMMIT passed but HIN failed is generated. Institutions will need to resolve HIN errors and resubmit data to produce a successful COMMIT. Submissions can also be set to COMMIT by Institutional Liaison once errors are resolved. A summary of this procedure is shown below.

Possible outcomes of COMMIT transaction

Exception	HIN	Result	Status	Icons	Reports
Passed	Passed	Passed	Committed
Passed	Failed	Failed	Commit passed but HIN failed
Failed	Passed	Failed	Valid data - Commit failed
Failed	Failed	Failed	Valid data - Commit failed

5) Check documentation

Institutions are advised to ensure that sufficient time is spent examining the check documentation produced through a successful commit to ensure that following the introduction of the new record errors have not been introduced which impede previously attained levels of data quality.

6) Data Structure

Institutions are reminded the C07051 Student Record data needs to be returned in xml format.

• Special characters in XML

Elements that include characters with special meaning in XML (such as < less than, > greater than, & ampersand, ' apostrophe and " quotation mark) must be replaced with the appropriate entity reference. Further information is available at: http://www.w3schools.com/xml/xml_syntax.asp.

• File format

Institutions are advised to compile their XML files in the following format:

<COURSEID>ENGLISH01</COURSEID>

And not;

<COURSEID>

ENGLISH01

</COURSEID>

The inclusion of additional formatting line breaks within the element with its data may result in a schema error, with the file read to contain spaces which may not comply with the required data type.

• Encoding

Student record XML files should be encoded with UTF-8. Institutions are advised to specify the encoding used in their XML files in the first line of the file (i.e. <?xml version="1.0" encoding="UTF-8" ?>) and to ensure that their files are actually saved with that encoding. If XML files are edited with some text editors and the encoding is not specified or does not match the actual file encoding, there may be problems when submitting these files for validation.

7) Downloadable files

The downloadable files produced through the commit transaction will be made available in both xml and CSV format.

8) Sign-off procedure

This procedure is designed to increase awareness of the importance of the verification stage as an integral part of making the return.

It is required that the sign-off slip for this return is completed by the Head of the reporting institution, or by a person with suitable authority. To assist in this process, once HESA has reviewed submitted data, and this data has been deemed credible, an automated email will be sent to the Head of the institution. The sign-off slip will be attached to this email.

The deadline for completion and return of the Student Record sign-off slip is 31 October 2008.

Post-collection amendments to HESA return (Fixed database)

The Fixed database process is separate from the main data collection and will only be available to an institution on the explicit instruction of the appropriate statutory customer, e.g. Funding Council. Furthermore, statutory customers will only approve specific changes to the collection and so institutions will need to get approval for every field they wish to change. Institutions should also be aware that onward use of information, for example in HESA publications, or for TQI, will be based on the original data collected and not on any amended data. This is because the availability of the Fixed database necessarily extends well beyond the publication date of information.

The agreements with statutory customers provide for the costs of processing such exceptional amendments through the Fixed database to be recovered from institutions by HESA, with assistance from the appropriate Funding Council. It has been agreed that for the Student Record this charge should be set at 20% of the institution's annual subscription.

Who to contact during the data collection

If you have any queries on the issues raised in this Circular, please contact the Institutional Liaison team at HESA, or email (liaison@hesa.ac.uk).

Yours sincerely

C. Jane Wild
Director of Operations