09/02 - July

Dear Colleagues

2008/09 HESA STUDENT RECORD COLLECTION (REF: C08051)

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

• Timescales for data collection
• Validation overview
• COMMIT-stage validation rules
• Validation kit
• C08051 data submission guide

Key deadlines

The timetable for submission remains as has been operated for previous years. Institutions are reminded of the benefits of starting early to allow time for the necessary data quality 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 2009.  HESA will advise Funding Councils of any institution not providing complete and valid data by this date.  The last submission of files must be made by 30 October 2009 and the sign-off slip is required to be completed and returned to HESA also by 30 October 2009.

Previously announced changes to the collection system for 2008/09

Full details of the changes to the collection system for 2008/09 are covered in Circular 09/01 which was issued in May 2009. An extract from this circular appears below, although institutions are advised to refer to 09/01 in its entirety.

• The data collection system will be set up to send an email to the transaction owner when a transaction has completed processing.
• In order to help institutions better understand how the data they provide will be used in routine publications and has been processed for the Check Documentation, HESA will, following a successful commit transaction, make available standard data tables. These tables will include a core analysis table that gives instance level derived fields (populations, TQI Tariff etc.), an FTE/cost centre table that will enable institutions to replicate cost centre analysis and an FPE/subject table that allows institutions to replicate subject based analysis. The structure of the files will be provided as part of the documentation and the detailed specifications of the derived fields, including TQI Tariff, will be available through the data collection system once this goes live in August.
• HESA has reviewed code efficiency in the main areas of Aardvark processing with the view to improving performance.
• COMMIT-stage validation errors will be downloadable in CSV format.
• TEST COMMIT will be open for the majority of the collection.

Circular 09/01 also contains information about changes to the validation kit and rules, together with advice about running the validation kit locally.

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

Data quality and onward use of the dataset

The introduction of the new Student Record in 2007/08 led to a significant deterioration in data quality from previous returns and this has had an impact on onward use of the data by statutory customers. For 2008/09 statutory customers have advised HESA that they expect more attention to be paid to data quality in 2008/09, in order for there to be confidence in onward use of the dataset. Uses made of the student dataset include Performance Indicators, TQI, NSS, heidi, Statistical First Releases and ad hoc enquiries.Institutions are therefore asked to undertake robust data quality checking of their returns.

Further Guidance

1) Institution.Indicator for HEFCE funding approximations

Institutions in England should be aware that the INSTAPP and LOADYRA/B fields are used in calculating the flexible study measure. Institutions are therefoe encouraged to complete these fields accurately as appropriate. Proper use of these fields by institutions could significantly improve some of the estimates that are used in calculating the flexible study measure.

Fields with data quality issues

2) Instance.Destination of outward credit mobile students

Statutory customers have reported a large number of ‘Not known' values being returned by institutions in 2007/08. Institutions are therefore advised that it is expected there will be fewer 'Not known' students reported in 2008/09. 

3) EntryProfile.New entrant to higher education

BIS reported that in 2007/08 there were a larger number of English and Welsh domiciled students under the age of 18 being returned as code A ‘This student has had prior HE experience in the UK lasting six months or more' than expected. To better assist institutions in addressing this issue HESA has introduced a new exception warning to identify where there are ‘More than 500 students aged 18 or under with EntryProfile.NEWENT = A and Course.COURSEAIM begins D, E, L, M, H, I, J, or C' for 2008/09.

4) HIN linking mechanism extended to FE instances

Although robust HIN checking is in place for HE records returned to HESA, this checking has hitherto not been applied with the same vigour to the FE records returned. It is now necessary to further improve the data quality of FE records returned to HESA. Further information regarding the context in which this change has been made is available for reference from the additional guidance section on the Student Record 2008/09 collection viewer. From 2008/09 HIN checking will be introduced for these FE records, although the results will be reported only as warnings for 2008/09.  Further information on the HIN linking mechanism is available at: http://www.hesa.ac.uk/index.php/component/option,com_studrec/task,show_file/Itemid,233/mnl,08051/href,HIN.html/.

The FE HIN Target List produced from the 2007/08 Student Record (C07051) was issued to institutions on 16 May 2009. This is a list of all FE instances that were ‘live' at the end of the C07051 data collection, and for which a record must be returned in C08051 (2008/09).

5) Entry profile processing

Submitting entry profiles for new entrants is compulsory, however resubmitting entry profiles for continuing students is required only in cases where institutions are correcting data sent in previous years.

Where institutions do resubmit entry profiles for continuing students, the entry profile entity must be complete; i.e. all fields within the entry profile that apply to a given student must be included and completed, not just the field that is being corrected.

Guidance on resubmitting entry profiles for continuing students is available at: http://www.hesa.ac.uk/index.php/component/option,com_studrec/task,show_file/Itemid,233/mnl,08051/href,EP_guidance.html/.

From 2008/09 HIN validation at COMMIT will include checks to compare entry profile data submitted originally with that in the resubmission.

6) Pre-Initial Teacher Training courses at institutions in England

Students on Student Associate Schemes (SAS) and Subject Knowledge Enhancement (SKE) programmes should not be included in the Student Record in 2008/09.  Institutions should however be aware that new fields connected with these initiatives are being introduced from 2009/10 onwards. 

Data Collection

7) Early Validation System

The Early Validation System, which opened 15 June 2009, provided an opportunity for institutions to expose their student data to the full range of validation checks before the data collection system opens. This system has been implemented solely to help institutions identify problems in their data at an early stage. Institutions have been strongly encouraged to make use of this facility. The Early system provided 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. Data submitted to the Early system will not be retained by HESA or forwarded to statutory customers.

The Early System closes at the end of July, in order to enable the main system to go live in early August.

8) Access and PIN codes

HESA places a great deal of importance on the security of the systems that process HESA data. Following a review of security mechanisms that support the HESA Data Collection System (known as "Aardvark") the Agency has introduced some changes to the user registration process which are now being implemented across the various streams of data collection. In the past record contacts at institutions used an emailed Access Code to create accounts and/or add new permissions to existing accounts.

From now on, in addition to the Access Code, users will also need a PIN code to create new accounts and/or add permissions to existing accounts. The PIN code will be distributed by letter a few days in advance of the Access Codes that will continue to be distributed by email. Both the Access Code emails and the PIN letters are sent to the nominated Student Record contact at institutions. It is imperative that any changes to contact details are notified to HESA immediately by contacting Institutional Liaison.

9) 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 22 September 2009 as detailed in the Timescales for data collection.

10) 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
  [C08051 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.

11) HIN processing

The 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 is of the highest standard. Therefore increasing emphasis has been afforded to HIN linking since 2006/07; there will be zero tolerance in respect of the standard of linking in 2008/09.

COMMIT passed but HIN failed

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, together with the icons used and the reports generated, 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

12) Operational documentation

To help institutions use the Field list and detail in the Student Record, HESA has introduced a Sort by field name feature from 2008/09.

13) Check documentation

Institutions are advised to ensure that sufficient time is spent examining the check documentation produced through a successful commit to ensure that new record errors have not been introduced which would cause any degradation to data quality.

14) Data structure

Institutions are reminded the C08051 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

XML files must be encoded with UTF-8 if they contain characters beyond the standard ASCII character set. Institutions are advised to specify the encoding used in their XML files (i.e. <?xml version="1.0" encoding="UTF-8" ?>) and to ensure that their files are actually saved with that encoding. Files with an explicit encoding declaration other than UTF-8 will be rejected. Files with undeclared encoding will be assumed to be UTF-8. If encoding is not specified or does not match the actual file encoding, institutions are warned that there is a risk that data contained in the files may be changed on submission to HESA.

15) Downloadable files

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

16) 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 30 October 2009.

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