10/01 - July

Dear Colleagues

2009/10 HESA STUDENT RECORD COLLECTION (REF: C09051)

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

• Timescales for data collection
• Validation kit
• COMMIT-stage validation rules
• HIN validation rules  
• Student Record data submission user 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 2010.  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 29 October 2010 meaning data quality assurance must also be completed by this date. The sign-off form is required to be completed and returned to HESA also by 29 October 2010. The full schedule the C09051 Student Record data collection can be viewed at Timescales for data collection.

Previously announced changes to the Student Record for 2009/10

Full details of the changes to the Student Record for 2009/10 are detailed in the Summary of changes since 2008/09.

Institutions should ensure that they refer to the most recent version of the C09051 Coding manual. Institutions have previously been advised of any changes to the coding manual, for reference these are also listed in the C09051 Revision history.

Further Guidance

1) Institution.Indicator for HEFCE funding approximations

Institutions in England should be aware that the Institution.INSTAPP and Instance.LOADYRA/B fields are used in calculating the flexible study measure. Institutions are therefore 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. 

2) Instance.LOCSDY 'S'  

A new LOCSDY code has been introduced to the record for 2009/10. It is required that where students studying overseas have spent or will spend more than a block of 8 consecutive weeks studying in the UK they should be returned on the Student Record. See Coverage of the Record for further details. For years where the student spends the whole year at the reporting institution, LOCSDY code 'X' should be used. For years where the student spends part or all of the year abroad, LOCSDY code 'S' should be used.

If it is known at the beginning of the course that a student will spend eight weeks or more in the UK as part of their programme then they should be included on the Student Record throughout. If it is not known at the beginning of the course whether the student will come to the UK for more than a block of 8 consecutive weeks study they should be returned on the Aggregate Offshore Record until this is known.

Where a student previously studying overseas comes to the UK Instance.COMDATE should be returned as the date on which the instance of study commenced overseas.

Note that there is no requirement to send an individualised student record for any student studying for the whole of their programme of study outside of the UK and those not funded for study by distance learning overseas. These students should instead be included on the C09052 Aggregate Offshore Record.

Institutions in England: Student instances coded as LOCSDY = S will be excluded from the HESES re-creation. Where the student is spending the whole of a year in the UK and thus returned as LOCSDY = X it will continue not be possible to exclude these instances from the re-creation.  This may result in a mismatch in the non-fundable or island and overseas columns. It is not expected that these students will be returned as fundable for any years of study, even when in the UK. HEFCE are looking to introduce new codes in Instance.EXCHANGE to assist in excluding these students in the future.

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

Students on Student Associate Schemes (SAS) and Subject Knowledge Enhancement (SKE) programmes should be included in the Student Record for 2009/10. Students undertaking these initiatives should be returned on a reduced return (Course.REDUCEDC and Instance.REDUCEDI codes 06 for SAS and 07 for SKE). Full details of the fields required to be completed for these reduced returns are listed at Reduced returns. 

4) DCELLS funded learners at Welsh institutions

Some changes have been made to the Notes for three fields on the Instance entity; Instance.NUMUNITS, Instance.NOUNTACH, Instance.ENDDATE. These changes describe new guidance applicable to DCELLS funded learners at Welsh institutions. Changes consist of:

• Further guidance on coding Instance.NOUNTACH and Instance.NUMUNITS to improve consistency and accuracy in allocating DCELLS funding and calculating performance measures, based in units/credits attained.
• Further guidance on entering Instance.ENDDATE for learners leaving prior to completion to ensure consistency in allocating DCELLS funding.

5) Research Council funded students

Institutions are required to code Research Council funded students to the specific Research Council providing these funds in Instance.RCSTDNT. For 2009/10 a new exception rule has been introduced to flag where an institution has returned more than 10% of Research Council funded students as 09 Research Council - not specified.

"Instance.RCSTDNT.Exception.3 More than 10% of Research Council funded instances have Instance.RCSTDNR = 09 (Research Council not specified). The instances should be coded to the appropriate Research Council where possible."

6) Amending Entry Profile details 

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 resubmit entry profiles for continuing students, the entry profile entity must be complete; i.e. all fields that apply to a given student within the entry profile must be included and completed and not just the field that is being corrected. All null fields within the entry profile being resubmitted will count as null even if valid codes were submitted in such fields in previous returns. Entry profile fields that are not included in the resubmission will also count as null even if the fields were included in previous returns. Note that this requirement also applies to the Entry profile sub entity Qualifications on Entry.

Example: Outcome of processing the Entry Profile entity for continuing students

Please view Entry Profile Processing for full details.

The HIN validation in place at COMMIT will include checks to compare entry profile data submitted originally with that in the resubmission. 

7) General Social Care Council (GSCC)

HESA will be providing student data to General Social Care Council (GSCC) for 2009/10 onwards and will rely on coding in Course.REGBODY in order to identify correctly the appropriate student records. Is it therefore vital that Course.REGBODY is coded 08 'General Social Care Council (GSCC)' only for courses that have been approved by GSCC. There are historic examples of incorrect use of code 08 in Course.REGBODY incorrectly and therefore HESA will be receiving information from GSCC which will allow this coding to be checked during data collection.

8) JACS subject coding

From 2009/10 institutions are required to make appropriate use of the full 4-digit JACS coding in all subject areas. This is needed to future-proof work on strategically important and vulnerable subjects, so that as the landscape changes, it will be possible to assess the past performance of newly important subjects. This requirement applies to both CourseSubject.SBJCA and ModuleSubject.MODSBJ. There will be some courses and modules where it remains appropriate to code at principal subject level, but others where a more detailed code should be used. So for example, a general Biology course would continue to be coded as C100, but a specific course/module in Biodiversity would be coded C181. Similarly, a generic Religious Studies course would be V600, but a specific Islamic Studies course would be V622.

9) Instance.STULOAD

If a student drops out of their studies early then Instance.STULOAD should reflect this. The FTE should be less than if the student had completed the whole of the course academic year. The notes in the Instance.STULOAD field state: 'All students following a course would initially be assumed to have the same FTE. An adjustment may need to be made at individual student level if a student did not actually follow the whole course academic year, e.g. because they left half way through. This individual student adjustment need only be at a very broad-brush level.' However, the Instance.STULOAD does not have to be adjusted to reflect differences in individual study patterns of full-time students if the students study for the whole of the course academic year. That is, a student on a standard full-time course who studies for the full academic would be expected to have an Instance.STULOAD of 1.

10) Course coding

Institutions are reminded to ensure courses are coded correctly. It is not expected that different years/presentations will be recorded as distinct courses.

11) Instance.INITIATIVES 

This new field identifies students who are part of a specific scheme that is to be monitored independently. Valid entries will change from year to year to reflect current schemes. For 2009/10 the following schemes should be coded in this field:

12) Postcode date

Institutions are reminded of the importance of accurate postcode data. This data is used in record linking for Performance Indicator purposes, widening participation funding and assists HEFCE in mapping their POLAR classification of participation.

13) Tariff calculation

From 2009/10 onwards HESA's tariff calculation will include EntryProfile.QUALENT2 codes 39, 40, 41 and 47.

Data Collection 

14) File structure and format 

The C09051 Student Record data needs to be returned in XML format. The physical file structure to be returned to HESA is based on the data model. Further technical information is available at Technical formats.

15) Pre-collection Validation System

The Pre-collection Validation System, which opened on 14 June 2010, provides an opportunity for institutions to expose their 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 are strongly encouraged to make use of this facility.

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. Data submitted to the Early system will not be retained by HESA or forwarded to statutory customers.

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

16) Access and PIN codes

To submit C09051 Student Record data to the HESA Data Collection System (known as "Aardvark") users require an access and PIN code. These codes allow users 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.

For assistance with registering for the data collection system please view the Registration help guide.

17) 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.
  C09051.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.

18) TEST_COMMIT facility

The TEST_COMMIT facility, which is available for the majority of the data collection period, allows institutions to process a transaction which, if successful, will generate the commit stage reports for local scrutiny. These reports are for institutions' purposes only and will not be checked within HESA.

Institutions are strongly encouraged to make use of the TEST_COMMIT facility as part of their data preparations. TEST_COMMIT serves as a useful interim facility in the data collection process. The facility enables institutions to view the commit reports and assess submitted data for anomalies before processing a full COMMIT to be scrutinised by 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. 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; use of the facility is optional, although strongly encouraged.
· Institutions must however process a COMMIT transaction by 22 September 2010 as detailed in the Timescales for data collection.

19) Exception Report 

In previous years the exception report was limited to display only the first one hundred errors.  This year, at institutional request, the exception report will feature the option to download the totality of records failing exception checks.  

20) HIN processing

For 2009/10 the method in which HIN failure percentages are calculated for Reports A and B have been updated to increase their accuracy. In consequence the percentages of records failing these HIN checks may increase at institution.

In 2008/09 HIN Report A (HIN link but conflicting year-on-year data) was currently calculated on the total number of incoming records. For 2009/10 HIN Report A will be calculated on the total number of records with a HIN link.

In 2008/09 HIN Report B (No HIN link for an incoming instance (submitted with EP) that commenced in a previous reporting period) is currently calculated on the total number of incoming records. For 2009/10 HIN Report B this calculation will be restricted to compare the total number of incoming records with an Instance.COMDATE prior to the start of the reporting period (before 1 August 2009).

The calculation for Report C remains unchanged. HIN Report C (No HIN link in incoming data for an instance that was 'live' last year i.e. appeared on the HIN Target List) is calculated on the total number of records on the institution's HIN target list.

HIN rules have been renumbered for 2009/10 to separate them from the exception rules. The HIN rules now include a 'HIN.' label rather than an 'Exception.' label e.g. Instance.NUMHUS.HIN.1.   

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.

21) COMMIT passed but HIN failed

If there are any HIN errors then the status of a 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 Committed by Institutional Liaison once errors are resolved/explained. 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	Status icon	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

22) Check documentation

To assist institutions in their analysis of the check documentation tables HESA has created a C09051 check documentation guide. This guide provides details on each of the items included within the check documentation and points out key issues institutions should look out for during their own scrutiny of the data. Institutions are reminded that the data quality checking of submitted data is a shared responsibility of both institutions and HESA.

Institutions are advised to ensure that sufficient time is spent examining the check documentation produced through a successful commit to check that errors have not been introduced which would cause any degradation to data quality. As institutions are in a better position than HESA to recognise more detailed anomalies within their data, using local knowledge of the intricacies of their own institutions, they are strongly encouraged to closely scrutinise the check documentation reports.

The check documentation provides the opportunity to preview uses made of the student dataset including Performance Indicators, Statistical First Releases ,TQI, NSS, heidi, and ad hoc enquiries. Consequently it is suggested that institutions undertake robust data quality checking of their returns. 

Changes to the check documentation for C09051 

The check documentation has been reordered for 2009-10.

• The two key items relating to Student numbers and qualifier rates are grouped together on Check_Document_1 to assist comparative analysis.
• ITT sheet: two new tables added (1c and 2c) to provide details of the number of students gaining teaching qualifications and QTS for the 14-19 Diploma teaching bracket.
• CCANLYSIS: at institutional request a further breakdown of cost centre analysis by level of study and Instance.FUNDCODE will be provided in item 14 on the 'Institutional_information' sheet.

Mapping of check documentation items: 

23) Data Supply

The Data Supply files will again be provided for 2009/10. These files provide the HESA derived fields and populations along with and the majority of the Student Record data fields in flat files to enable institutions to replicate the populations used in the check documentation. These files can also be exported to institutions' local systems to act as a basic data management tool. For 2009/10 Course.COURSEID, Module.MODID, Instance.OWNINST will be included within the structure of these files.

24) Minerva data quality database

For the 2009/10 data collection cycle HESA is launching a new data quality (DQ) database: Minerva. From C09051 onwards data quality queries raised by HESA as part of the data quality checking process will no longer be emailed to institutions. Instead institutions will be notified by email when queries have been logged on the Minerva database.

Institutions will then need to log into Minerva to view and respond to these data quality queries. Institutional record contacts will be issued with a password to be used to enter the Minerva DQ database. Assistance on using the Minerva DQ database can be found at: Minerva user guide.

25) Information Reporting Interface Service (IRIS)

For institutions in England and Northern Ireland the HESA Data Collection System will automatically send a file to HEFCE following every successful commit in order for HEFCE to conduct their reconciliation calculations. The results of these calculations will then be fed back to institutions through the HESA Data Collection System. Note: this system will not impact upon the processing of the HESA Student Record data system.

This service will be implemented after the opening of the main data collection at the beginning of August. Institutions in England will be notified when the service become operational.

26) Downloadable versions of COMMIT reports

The file structures for downloadable reports produced by a successful COMMIT transaction can be viewed at File structures for downloadable files. The downloadable files produced through the commit transaction will be available in both XML and CSV formats.

27) NSS

Institutions are reminded to check the NSS survey population files created as part of the COMMIT transaction to ensure the population is correct.

28) Sign-off procedure

Verification (sign-off) is an integral part of making the return, and complete the process of data collection.

It is required that the sign-off form for this return is completed by the Head, or Acting Head of the reporting institution. 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 form will be attached to this email.

The deadline for completion and return of the Student Record sign-off form is 29 October 2010 as detailed in the Timescales for data collection.

29) 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 formal agreements with statutory customers provide for HESA making a charge to institutions for use of the Fixed database. It has been agreed that for the Student Record this charge should be set at 20% of the institution's annual subscription, or £7,000 whichever is the lower figure. This charge does not attract VAT.

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