Student 2013/14: Support guides

We collect data across a number of streams. These streams focus on different aspects of higher education.

The Student stream collects data about students studying at higher education providers in the UK. Details of which students need to be returned to us are included in the Coverage document found in the Coding manual.

The data we collect on behalf of the sector is provided to governments and fundng bodies in order to support the regulation of higher education. We also make anonymised data available to the public to enhance understanding of UK higher education and to support its advancement

Our coding manuals provide you with all the necessary documentation to support your data return. The coding manual contains technical documents giving detailed information on the record's coverage, data specification and submission formats. Familiarising yourself with these documents will help you make an accurate and timely return.

Each collection has its own coding manual which can be found in the Data collection section of our site. By default, you will land on the open collection for each record; you can then select previous or future years.

The coding manuals will be updated throughout the data collection cycle and Record Contacts informed by email when new versions are made live. Be sure to check the manual's Revision history for a summary of changes.

The below table provides an overview of the data collection schedule. A more detailed timetable can be found in the Coding manual.

You submit data via our Data Collection system. To access this, you will need to have an appropriate role in our Identity System (IDS). We publish an IDS user guide which includes information on creating and editing your account.

You will need to be given access to the Data Collection system by the relevant Record Contact at your provider.

Once you have access to the system you will be able to upload files and track the progress of the collection.

The coding manual homepage includes all the technical information you require, including:

• The data specification
• File format specifications
• A detailed collection schedule
• Our XML data entry tool (available for some streams)
• Quality rules.

This Support guides page collects together the following resources:

• User guide
• Data collection system: Known issues and release history.

In the Support area of the HESA website, you can find:

• User guides for our Identity System (IDS) and Issue Management System data quality database (HESA subscribers only).
• Support with using XML files
• Our XML amalgamator tool and Validation kits available for some collections.

Our Data innovation section includes information about:

• Open and recently completed record reviews, including information about changes we are implementing
• Our Data Futures programme which will transform the higher education information landscape.

In the About section, you can find:

• Details of who we are and what we do
• Information about data protection 
• Information for providers including the Code of practice for HE data collections, and information about subscription rates and the fixed database facility.

Our expert analysts have a thorough understanding of our records and processes. We are here to support you throughout the data submission process.

Contact Liaison by email or on +44 (0)1242 388531 

Find out more about Liaison

Our JISCMail groups allow you to discuss specific streams with colleagues from across the sector. We also use the lists to circulate news regarding data requirements and coding manual and validation kit releases.

Join the HESA-Student JISCMail list

If you encounter any problems, contact Liaison

Following the October 2012 consultation, changes were agreed that are being carried forward for the Student record 2013/14.

Documentation summarising the main changes to the Student record for 2013/14 since 2012/13 is available from the C13051 coding manual. Please note that any changes made to the 2013/14 Student record after the first release of the manual will be documented in the Revision history, so you should reference this web page also.

Key changes for C13051 2013/14 Student Return

During data collection the suite of reports containing management information for review to assess data quality will be generated if at all possible regardless of whether a successful TEST_COMMIT or COMMIT transaction has been processed. It is hoped that this will further assist institutions in the validation process. Note that the following list of changes is not exhaustive - please refer to the Revision history for full details.

Changes to Minerva for 2013/14

Following feedback from institutions a number of changes have been made to the radio buttons available in Minerva for the 2013/14 collections. The available options will be:

Where you select ‘will fix by last submission’ the query will remain listed in the outstanding issues page until you reclassify the issue as ‘ready to be fixed’. The ‘I have a related question’ option should be used where further clarification on the query is required before you can provide a response. ‘More than one of the above apply’ should be used in cases where the query contains multiple elements some of which may, for example, be genuine and others that perhaps require resubmission.

You are reminded of the importance of engaging with the data quality process and ensuring that detailed responses are provided in a timely fashion to ensure that the data is fit for purpose.

Changes to the record

A new entity 'FinancialSupport' has been added on Instance to capture the financial support given to students, for OFFA purposes.  Version 1.5 of the coding manual, released in June, contains additional guidance regarding the data items, including the treatment of loans of equipment. We will be contacting institutions to confirm whether loans of equipment have been included in the Student return.

A new field CARELEAVER has been added to capture whether a student is a care leaver or not. This will be included in the UCAS *J file, however institutions that record care leavers for internal purposes should use code 01 where applicable. You should be aware that there may be a need for some recoding where a blank value has been supplied by UCAS.

A new entity 'Mobility' to record the mobility experiences of students has been added to Instance. This entity contains four new fields: Mobility.MOBTYPE, Mobility.MOBDURA, Mobility.MOBLOCA and Mobility.MOBSCHEME.

Changes relating to Research Excellence Framework

REF.UOA2014 has replaced RAEData.UOA2008 to reflect recent changes to the Research Excellence Framework (previously RAE).  To ensure consistency in the data returned we encourage you to liaise with colleagues responsible for the REF as well as those undertaking your institution’s Staff return. We will carry out cross checks between the Staff and Student records to ensure that the REF units of assessment are consistent.

Changes to the check documentation

There are a number of changes made to the check documentation for C13051. The key changes are:

Check_Document_1 worksheet

A new SSN item has been added to display a breakdown of students and reports on students who start and leave within 2 weeks at an institution.

Item 4a has been introduced to report the breakdown of reported mobility.

Item 16 Financial Support has been introduced for C13051 to capture the financial support received by all students for the purposes of the Office for Fair Access (OFFA). 

A new 'unrestricted population' worksheet has been added at the request of institutions to provide a total instance count.

Check_Document_2 worksheet

Item 12 ‘Average Instance FTE' has been broken down further separating out students who have withdrawn and suspended.  

New HESA Identity System

We have recently introduced the HESA Identity System (IDS), which will serve as a single-sign-on portal governing access to all our websites. This means that you will only have one username and password to access all of our services. Use of this portal will be rolled out across our web applications over the coming months.

The first service to use IDS for authentication is Minerva. So, in future, when you go to the Minerva site, you will be redirected to the Identity site, where you will log in, and then be redirected back to Minerva.

Identity System user guide

The Identity System user guide provides detailed help with using our new single sign-on system.

Check documentation guide

To assist institutions in the role of review of committed data we provide a guide to assist in the interpretation of check documentation. This guide is available from the coding manual.   

SLC Analysis Project

We are undertaking a post collection analysis project to compare the content of Instance.GROSSFEE and Instance.NETFEE as provided by the HEI and by SLC. The results from linking 2012/13 data show that 96% of the SSNs submitted in the HESA record (for full-time undergraduates) matched with data received from the SLC. Thus there is a high degree of confidence in the linking process for the core full-time undergraduate population. However, outside of this core population, lower percentages of matching were found. The project continues to look into these discrepancies with assistance from a number of HEIs.

For the 2013/14 data collection the instruction to institutions is unchanged from 2012/13. Therefore in addition to returning Instance.GROSSFEE and Instance.NETFEE for all students not applying for student finance (i.e. no Instance.SSN exists) where FEEREGIME=20, institutions may also wish to complete Instance.GROSSFEE and Instance.NETFEE for all students for whom they have returned a Student Support Number (Instance.SSN), although the latter remains optional.

A record is required for all students that have applied for a loan with the SLC where the attendance has been confirmed to SLC on an SLC attendance confirmation date, even if the student started and left the course within the first two weeks. A type 08 reduced record is acceptable for these students.

In preparing the data for submission in 2013/14, you are reminded of the following guidance notes:

• If a student leaves the HEI part the way through the instance year, HEIs must provide the annualised amount for the course in Instance.GROSSFEE and Instance.NETFEE. The SLC will also supply the annualised fee in this scenario.
• Instances where the NHS (or another body) pays a per-capita charge equivalent to a fee this should be recorded in Instance.GROSSFEE and Instance.NETFEE. However, where the NHS (or another body) pays a single fee that is not linked to individual students then zero should be returned
• For non-standard years where it is not known which or how many modules the student will elect to take in HESA year two of the year of instance, HEIs should return the fee based on modules started in the reporting year.
• There is no requirement to provide Instance.GROSSFEE and Instance.NETFEE for incoming exchange students or dormant students.

The table below shows the typical values expected for groups of students by domicile and location of institution. This table is indicative only.

*Fee information is not required to be submitted where Instance.FEEREGIME=10

IRIS - institutions in Wales

You are reminded that you should scrutinise the IRIS system outputs to ensure that data submitted is correct. HEFCW will not be routinely examining the output. However, if there are any questions about the output from IRIS or if you would like the output to be scrutinised by HEFCW, you should contact the Statistics Team at HEFCW.

IRIS - institutions in England

You are reminded that you should scrutinise the IRIS system outputs to ensure that data submitted is correct. HEFCE will be examining the output and where necessary raise queries which institutions are expected to respond to.

IRIS - institutions in Scotland

You are reminded that as part of your data checks you should look at the IRIS system outputs. If there are any questions about the output from IRIS, you should contact the Funding Policy Group at the SFC. 

Responding to Minerva queries

You are required to actively engage with data quality checking and the resolution of Minerva queries during the collection period. Best practice suggests you interact with Minerva and our data collection system frequently throughout the checking period. This allows you to gradually resolve issues either through providing explanations of genuine data or submitting revised data that corrects issues. Through adopting this approach, you can iteratively improve the quality of your data and expose issues in a timely manner leading to better quality returns.

We expect you to have responded to all queries raised prior to sign-off by the head of your provider. Failure to do so may result in the sign-off not being accepted.

C13041 Institution profile data collection

Following the submission of the C13041 Institution profile return, this data will then be used to validate cost centre data used in the Staff, Student and FSR data collections. Details about the collection can be viewed in the coding manual. Student record contacts have been given read-only access to C13041 so that they can view the Institution profile data record.

C13042 Estates management record

Student record information is included in some of the data items contained in the C13042 Estates management record. Those data items used are detailed within the student and staff counts fields of the Estates record.

Record contact changes

The record contact is the first point of communication during data collection. Access and PIN codes will be sent out to your institution's nominated record contact. If these details have changed please ensure you notify Liaison to prevent any delay in the receipt of these codes. 

A. Sending data

Send data by clicking on the 'send data' button in the data collection system. Note that actions not currently available will be greyed out.

Browse your computer to locate the file you wish to submit, and upload the file to the data collection system. 

Tips:

• Files can have any name
• Files must be in XML and conform to the relevant XML Schema Definition (XSD) file
• Files can be compressed using PKZip/WinZip which will significantly reduce the upload time
• Only a single file can be held on the system.

B. Validation

Automated validation checks (quality rules) will now run.

Further details on the quality rules which apply to this collection can be found in the coding manual.

The Quality rules report will contain the details of any rules triggered by the submission. Make any necessary amendments to the data and resubmit the file to the system. To pass validation, the file must not trigger any validation errors.

You can run some of these validation checks through our validation kit before submitting data to the data collection system. The kit enables you to test your data locally against schema and business stage validation rules prior to submission. You are strongly encouraged to use the validation kit as part of your data preparations.

Remember that you need to process and pass the business-stage validation in order to meet the requirements of the return deadline.

How to obtain a switch

When errors are triggered in the Data Collection system but the data has been checked and is genuine, you need to request a switch. This is because your file will not pass the validation requirements of the collection deadlines if there are any remaining errors.

Please email your switch request to Liaison, stating which rule is causing the error to be triggered and for how many records, together with an explanation as to why the data is genuine.

This will then be forwarded to your funding council/regulator for them to review. They may agree the switch, ask for more information or state how they wish the data to be returned so that an error is no longer triggered.

This request should be sent well in advance of any deadline, to allow sufficient time for a decision to be made.

When a switch has been agreed, it will be applied to your data for the count specified and the data will be reprocessed. This will resolve the error.

If the count increases, the rule will be triggered again, and you will need to request that the count on the switch be increased. This will be forwarded to your funding council/regulator for approval.

To proceed to the next stage in the submission process, a valid file needs to have been submitted. The data will then be classed as 'committable' and the option to process a COMMIT transaction will be made available through the data collection system.  

Prior to committing data, you should review all of the reports produced on the data collection system and make any necessary corrections to the data.

The COMMIT transaction sends a copy of your submission to our data quality assurance team and, where appropriate, to the relevant funding council. We analyse your return in parallel with your own analysis.

Decommitting

A passed commit transaction will lock the system to prevent the data from being amended. This is to allow our data quality assurance team to analyse the submission. To unlock the system you will need to request a DECOMMIT transaction.

Request a decommit by email or on +44 (0)1242 388531

Remember that you need to process and pass a COMMIT transaction in order to meet the requirements of the commit deadline.

Once we have analysed your committed return, data quality queries will be posted onto the Issue Management System data quality database. Relevant users will be notified by email when these queries are available to view. The Issue Management System user guide provides help on using the Issue Management System.

Access the Issue Management System data quality database

Once your data has passed all the stages of validation, and any issues highlighted during credibility checking have been addressed, we will set the return to CREDIBLE. This produces the sign-off form.