1. Student record Advanced Daniel Kidd 12 June 2012

2. ‘The whiff of change’

3. Objectives Provide training on problem fields/areas… …including UCAS session on qualifications and HEFCE on data quality checking Highlight changes to the record for 2011/12 Demonstrate using data supply in pivot tables Introduce and discuss the changes to the Student record 2012/13 and beyond

4. Student information

5. EntryProfile.DOMICILE Country of domicile is becoming increasingly important with regards to monitoring fee regimes and the impact of changes in HE funding Use of XK ‘UK, not otherwise specified’ not permissible for NI, and should be limited for rest of UK… …therefore new exception rules added to capture: -Where >5% of entrants coded XK (error) -Where >2% of entrants coded XK (warning)

6. Instance.DISALL Records whether a student is in receipt of disability allowance Vital for Performance Indicators and ELQ Previously validation would not allow for students being in receipt where they had not disclosed a disability within Student.DISABLE Validation relaxed to a warning… …however new exception will prevent more than 10 students in receipt of allowance where no disability is identified i.e. 00, 97, 98 or 99

7. Qualifications on entry

8. QualifcationsOnEntry.QUALSBJ When calculating tariff scores, identical qualifications are removed by de-duplicating them based on the combination of QUALTYPE and QUALSBJ QUALSBJ of T33 (Total Score) should be used for International Baccalaureate Diploma (IBac)… …some institutions are returning more than one IBac qualification for the same student with different subject codes (not using T33)… …therefore, the second qualification is not being de-duplicated and the tariff score is overstated (potentially quite significantly) QUALSBJ must be coded T33 where QUALTYPE = IE QUALSBJ must be coded B29 where QUALTYPE = ID

9. XTARIFF – total tariff score Derived field is based on ‘Qualifications on entry’ data provided for each student A total tariff score is calculated where a tariff-bearing QUALENT3 is returned for a student Low, high or unknown tariff scores should be investigated Field is supplied through the Data Supply files

10. Changes to XTARIFF The specification has been amended to accommodate the inclusion of a number of additional new qualifications (majority of which are recorded through UCAS and included in ABL) Addition of an existing qualification to the tariff calculation that previously was excluded… …namely the (FA) Diploma in Foundation Studies (Art and Design)… …however will only be included in tariff score where QUALGRADE = D, M or P

11. Check documentation change Item 8 now splits out UK and non-UK instances Split useful to establish ABB+ equivalents Pay particular attention to UK students

12. Qualifications on entry checks Missing qualifications have significant implications for both tariff-league tables and AAB+ policy Exception rules around qualifications on entry were tightened in C10051… …ensuring that qualifications on entry information exists where QUALENT3 is a tariff-bearing qualification… …and where they exist the grade is returned… …and matches the information contained within the *J Further checks around ABB+ to be carried out

13. New qualification checks New exception rules will be introduced to tighten the relationship between QUALENT3 and qualifications on entry -Error where QUALENT3=P91 (L3 of which some or all are subject to UCAS tariff) but there are no QUALTYPEs which are tariff-bearing reported in Qualifications on entry (and vice-versa) -Error where QUALENT3=P92 (L3 of which none are subject to UCAS tariff) but there are QUALTYPEs which are tariff-bearing reported in qualifications on entry (and vice-versa) Only looks at data submitted this year - will not use register Will check QUALTYPE is tariff-bearing in either the UCAS or HESA tariff definitions

14. Updating qualifications on entry The QOE register holds the qualifications data for each student an institution has submitted It is expected in the first year of the student instance and is then stored and reused for all subsequent years Qualifications sent for continuing students replace rather update the QOE data for the particular student… …thus institutions should ensure they resend all qualifications when updating the QOE for continuing students

15. Qualifications on entry register The QOE register holds the qualifications data for previously submitted students and therefore understanding the calculation of XTARIFF for continuing students is difficult Qualifications on entry data has never been more important (from ABB+ funding policy to PIs and league tables) For 2011/12 HESA will provide as part of data supply the QOE register

16. New data supply table Field NameDescriptionElement name in XML output Field length QOE.HUSIDHESA unique student identifierHUSID13 QOE.UKPRNUK Provider Reference NumberUKPRN8 QOE.NUMHUSStudent instance identifierNUMHUS20 QOE.QUALGRADEQualification gradeQUALGRADE11 QOE.QUALSITQualification sittingQUALSIT1 QOE.QUALSBJQualification subjectQUALSBJ3 QOE.QUALTYPEQualification typeQUALTYPE2 QOE.QUALYEARQualification yearQUALYEAR4 XQEYEAR01Year QualificationsOnEntry last updated XQEYEAR014

17. Using the QoE register Should be used in conjunction with the core table A student with more than one qualification on entry will have more than one line of data in this table Filter on HUSID and NUMHUS for instances with low, high or unknown scores in XTARIFF

18. UCAS Data for HESA Qualifications Tim Hall Senior Data Steward UCAS

19. What Qualifications are in the *J?

20. The Qualifications *J includes qualifications from Awarding Bodies only It includes up to 30 qualifications for each applicant If the applicant has over 30 qualifications only the latest 30 are shown Includes Highest Qualification on Entry (QUALENT3)

21. What Qualifications are in the *J? Coding Frames QUALTYPE and QUALSBJ Based on codes UCAS use for ABL All codes are designated by UCAS and do not reflect what we get from the Awarding Bodies We only code up: Tariffable qualifications Where we have an agreement with the Awarding Bodies to receive data

22. What Qualifications are in the *J? Coding Frames QUALTYPE and QUALSBJ Many Apply qualification codes are not compatible with ABL New Taiffable qualifications are given ABL compliant code just in case we get them through ABL at a later date. Apply qualifications are not given Subject Codes

23. What Qualifications are in the *J? Future Plans Looking into the possibility of extending the QUALTYPE coding frame This will include Apply Qualifications Looking into possibility of creating a stand alone Transaction for Apply Qualifications Different from ivFormQuals Would be HESA compliant and include Level 3 qualifications only

24. Awarding Body Linkage

25. What is ABL Data? Verified Qualification data received directly from the Awarding Bodies Where an applicant is not matched to qualifications though ABL they will not get any Qualifications on Entry

26. Awarding Body Linkage How is the Data Matched to the Applicant? Matching happens on the Application record If an applicant has been matched to qualifications in previous years but has reapplied, you will not see their past results in Qualifications on Entry Deferred applicants will retain their Qualifications (if matched) as their original application is carried over year on year Deferred applicants only go through ABL in the year we first receive their application If an applicant does not apply in the same year as they sat their exams they will not be matched

27. Awarding Body Linkage ApplicantApplicationABL Quals *J 2012/13 2013/14 Received

28. Awarding Body Linkage What Information is Received? We receive information on the following sittings: A-Level – Pervious Summer, Winter, Current Summer Scottish Quals – Everything back to 1995 International Bacc – Winter, Summer Everything else – Summer only We only receive SQA and BTEC results where an applicant has entered their Scottish Candidate Number or BTEC Registration Number in Apply These results have to be requested directly from the Awarding Bodies (unlike the others where we receive everything that year)

29. BTEC Questions Why are BTECs not included in the *J? We do not receive BTECs in the same format as other qualifications BETCs are received as a text file version of the certificate Printed off then sent as a hard copy to the HEIs Within our system we set a flag that tells us if a BTEC qualification has been received

30. QUALENT3

31. Where does Highest Qualification on Entry come from? Highest Qualification on Entry is generated during the production of the UCAS Data for HESA table on the UCAS Database Each applicant’s Highest Qualification on Entry is worked out in turn The JAVA script used to create the *J generates the field

32. QUALENT3 What Information goes into Highest Qualification on Entry? Applicant qualifications data gathered through Apply ABL data for all applicants who have been matched What Takes Priority? Neither Set of qualifications override the other Value is based solely on the qualifications themselves

33. QUALENT3 – 2011/12

34. The Process: 1.Apply Applicant enters their qualifications in the ‘Education’ section Applicant marks their qualifications as either Pending or Achieved Achieved quals are given grades Pending quals are not given grades

35. QUALENT3 – 2011/12 The Process: 2.ONYX (our validation system) Qualifications in Apply feed through to 2 coded value flags: HIQE – Highest Qualification Expected HIQA – Highest Qualification Achieved ONYX compares the Apply qualifications to a lookup table It compares each and returns the highest QUALENT3 value HIQA will have a QUALENT3 from achieved quals only HIQE will have a QUALENT3 from expected quals only

36. QUALENT3 – 2011/12 The Process: 3.TOPAZ (our main database) HIQA and HIQE are stored as part of a coded value pair This is being held in an existing structure. No new fields have been created Both HIQA and HIQE are output as part of the ivStarK

37. QUALENT3 – 2011/12 The Process: 4.UCAS Data for HESA Transaction (*J) Initial Calculation Sets FINAL or PROVISIONAL QUALENT3 value If the initial calculation returns a Level 3 qualification the “P91 Rule” applies. QUALENT3 coding frame is taken as a hierarchy

38. QUALENT3 – 2011/12 The Process: 4.UCAS Data for HESA Transaction (*J) Initial Calculation IF HIQE is above Level 3 and is better than HIQA Set HIQE as FINAL QUALENT3 IF HIQA is better than ABL Set HIQA as PROVISIONAL QUALENT3 ELSE Set ABL as PROVISIONAL QUALENT3

39. QUALENT3 – 2011/12 The Process: 4.UCAS Data for HESA Transaction (*J) P91 Rule Calculation Only applies when the PROVISIONAL QUALENT3 is set The calculation is as follows: Count the number of distinct Level 3 QUALENT3 values in the applicant’s ABL qualifications (including BTECs) Add 1 to this count if the applicant’s HIQA value is at Level 3 and different from the ABL values

40. QUALENT3 – 2011/12 The Process: 4.UCAS Data for HESA Transaction (*J) P91 Rule Calculation IF the count is greater than 1 Set P91 as FINAL QUALENT3 IF the count is equal to or less than 1 Set previous PROVISIONAL QUALENT3 as FINAL QUALENT3

41. QUALENT3 – 2011/12 Examples: Applicant 1 Qualifications in ApplyQualent3 9 x GCSE - achievedQ80 1 x GCSE Short Course - achieved Q80 4 x GCE Advanced Subsidiary - expected P50 3 x GCE Advanced Level - expected P50 Qualifications in ABLQualent3 4 x GCE Advanced SubsidiaryP50 3 x GCE Advanced LevelP50 HIQA = Q80 HIQE = P50 HIQA = Q80 ABL = P50 QUALENT3 = P50 Is HIQE above Lvl3? – No Is HIQA better than ABL? – No Provisional QUALET3 = ABL (P50) ABL Lvl3 count = 1 Is HIQA Lvl3? – No Final QUALENT3 Lvl3 count =1

42. QUALENT3 – 2011/12 Examples: Applicant 2 Qualifications in ApplyQualent3 6 x GCSE – achievedQ80 4 x GCE Advanced Level – achieved P50 1 x SQA Higher National Dip – expected J30 Qualifications in ABLQualent3 1 x SQA Higher National DipJ30 HIQA = Q80 HIQE = J30 Is HIQE above Lvl3? – Yes Is HIQE better than HIQA? – Yes QUALENT3 = J30

43. QUALENT3 – 2011/12 Examples: Applicant 3 Qualifications in ApplyQualent3 7 x Irish Leaving Certificate - achieved X04 10 x Irish Junior Certificate - achieved X04 1 x Degree (UK Bachelor – Honours) - achieved HUK Qualifications in ABLQualent3 NO ABL QUALIFICATIONSX06 HIQA = HUK HIQE = X06 HIQA = HUK ABL = X06 Is HIQE above Lvl3? – No Is HIQA better than ABL? – Yes ABL Lvl3 count = 0 Is HIQA Lvl3? – No Final QUALENT3 Lvl3 count = 0 Provisional QUALET3 = HIQA (HUK) QUALENT3 = HUK

44. QUALENT3 – 2011/12 Examples: Applicant 4 Qualifications in ApplyQualent3 4 x GCE Advanced Level – achieved P50 1 x OCR National Extended Diploma - achieved P41 1 x OCR National Certificate - achieved P42 Qualifications in ABLQualent3 1 x OCR National Extended Diploma P41 HIQA = P41 HIQE = X06 HIQA = P41 ABL = P41 Is HIQE above Lvl3? – No Is HIQA better than ABL? – No ABL Lvl3 count = 1 Is HIQA Lvl3? – Yes Final QUALENT3 Lvl3 count = 1 Provisional QUALET3 = ABL (P41) QUALENT3 = P41 Is HIQA different to ABL? – No

45. QUALENT3 – 2012/13

46. Same as 2011/12 with minor adjustments Now P91 rule also uses Apply qualifications The calculation is as follows: Count the number of distinct Level 3 QUALENT3 values in the applicant’s ABL and Apply qualifications (including BTECs) IF the count is greater than 1 Set P91 as FINAL QUALENT3 IF the count is equal to or less than 1 Set previous PROVISIONAL QUALENT3 as FINAL QUALENT3

47. QUALENT3 – 2012/13 Examples: Applicant 4 Qualifications in ApplyQualent3 4 x GCE Advanced Level – achieved P50 1 x OCR National Extended Diploma - achieved P41 1 x OCR National Certificate - achieved P42 Qualifications in ABLQualent3 1 x OCR National Extended Diploma P41 HIQA = P41 HIQE = X06 HIQA = P41 ABL = P41 Is HIQE above Lvl3? – No Is HIQA better than ABL? – No ABL and Apply Lvl3 count = 3 Provisional QUALET3 = ABL (P41) QUALENT3 = P91

48. QUALENT3 – 2012/13 Examples: Applicant 1 Qualifications in ApplyQualent3 9 x GCSE - achievedQ80 1 x GCSE Short Course - achieved Q80 4 x GCE Advanced Subsidiary - expected P50 3 x GCE Advanced Level - expected P50 Qualifications in ABLQualent3 4 x GCE Advanced SubsidiaryP50 3 x GCE Advanced LevelP50 HIQA = Q80 HIQE = P50 HIQA = Q80 ABL = P50 QUALENT3 = P50 Is HIQE above Lvl3? – No Is HIQA better than ABL? – No Provisional QUALET3 = ABL (P50) ABL and Apply Lvl3 count = 1

49. Changes to 2012/13 Transaction

50. Small number of changes this year SBJQA1, SBJQA2 and SBJQA3 will now be JACS3 compliant The ethnicity coding frame has been amended to reflect new ethnicity values introduced in the 2010 Census Derivation of the QUALENT3 P91 Rule

51. Changes to 2012/13 Transaction The following new fields have been added to the Transaction for purely informational purposes. These fields do not have to be submitted to HESA: BTEC Received Flag – This field will represent whether or not an applicant has received a BTEC qualification though ABL. It will be either a “Y” or “N” value HIQA – Highest Qualification an applicant has declared they have attained (as entered in Apply) HIQE – Highest Qualification an applicant has declared they are expecting (as entered in Apply)

52. Any Questions? Any questions? Tim Hall, Senior Data Steward Data Quality and Audit Team Contact Us: dqa@ucas.ac.ukdqa@ucas.ac.uk

53. Defining the instance

54. COURSEIDs Where possible the COURSEIDs returned within the Student record should not be subject to year-on-year change This will result in the need to recode the KIS record and might potentially lead to breaks in links between the two datasets

55. Instance.SPLENGTH Records the expected length of study for the instance Vital in determining when a student is entering their final year of study and thus the NSS population Difficulty in coding for flexible provision, part-time study, some postgraduate courses Be aware - new validation rule will error any courses that have an expected length of study of greater than 9 years… …irrespective of level or mode of study Rule will however exclude dormant instances so these only need updating when the instance returns to an active mode

56. Check documentation – Item 5 Check: -expected spread of data -very short or very long courses -Full-time versus part-time

57. NSS Even more important to ensure an accurate NSS population The NSS population and exclusion files should be used to verify the population The NSS subject file can be used to provide an early indication of NSS data for KIS…

58. Instance.YEARSTU Records the number of years the student has been on the instance (and thus is different to years of the course) Over 13,000 instances where YEARSTU=1, TYPEYR=1 (standard year) but COMDATE is in a previous reporting year (in some cases going back to 1997!) Validation rule will prevent this from happening in future for students who are not coded dormant Remember – YEARSTU should be incremented for every year a student is on an active mode – even where it is for just some of the instance year

59. Check documentation change Item 6 has now been split into full-time and part-time

60. Instance.INITIATIVES Institutions in Wales must now use this field where applicable… … 7 ‘Universities Heads of the Valleys Institute’ only Code 6 ‘Undergraduate internships’ is no longer available for English HEIs Exception checks will no longer be run comparing HEFCE counts of Lifelong Learning Networks (code 1) instances Exception will however continue checking 2 ‘Employer engagement co-funded students’

61. Funding information

62. Instance.FUNDCODE Records whether a student instance is fundable or not… …be aware that the definition of fundable is as fluid as its ever been FUNDCODE 4 ‘Fundable by funding council but funds not sought (institutions in England & NI only)’ is no longer a valid code to use… …all such students are now recorded under FUNDCODE 1 FUNDCODE 1 label for all administrations is now ‘Fundable by funding council’ Validation will be in place to ensure that FUNDCODE 4 is not used The code will be removed from the record next year

63. Instance.FUNDCOMP Remains a vital field for determining funding allocations In England and Northern Ireland ‘13 month’ rule definition still applies Exception rule added for C11051 – warning where more than 10% of instances (meeting HESES population definition) are FUNDCOMP=9 (not in HESES population) and STULOAD is => 3 Applies to all levels and full-time/part-time

64. FUNDCOMP reminder! For 2011/12 the year which FUNDCOMP relates to for non- standard years of instance has changed… …HEFCE now fund the year starting rather than ending This mirrors the change to how HESES counts activity and means that the non-standard years countable in HESES11 and HEIFES 11 will be those starting during the 2011-12 academic year, instead of those starting during the 2010-11 academic year Thus in HESA year 2, FUNDCOMP will relate to instance ‘Year two’ as opposed to ‘Year one’

65. StudentOnModule.MODOUT StudentOnModule.MODOUT records both funding completion and credit outcomes for modules Important in deriving FUNDCOMP coding New exception rules added to warn institutions where 5%(FT) or 15% (PT) of student on module records recorded as 6 ‘outcome not yet known’ but MODSTAT = 1 ‘Continuing from previous reporting year’ or 2 ‘Contained within reporting year’

66. StudentOnModule.MODSTAT StudentOnModule.MODSTAT records whether modules span HESA years Data needs updating each instance year to reflect the status of the student on module Where code 1 ‘Continuing from previous reporting year’ is used then it is expected that there will also be student on module records with 3 ‘Continuing into next reporting period ‘ New exception warnings will be in place to check this tie-up where 500+ student on module records have MODSTAT = 1 or 3 – institutions should ensure accurate coding

67. Check documentation change New MODOUT and MODSTAT table Important cross-referencing tool… …will help to quality assure FUNDCOMP derivations

68. Instance.STULOAD A vital field in the Student record which impacts on all uses of the HESA data Concerns of over reporting led to the following rule being introduced last year (C10051): -Where COMDATE and ENDDATE are in the current reporting period, STULOAD must not be greater than 4.2 times the number of weeks -4.2 was used as 100/24 (no. weeks for FT) = 4.1666 For example, where the number of weeks between the start and end of the instance is 10, we would not expect STULOAD to be greater than 42%

69. STULOAD rule changes The 4.2 rules will be in place but increased to 5 times the number of weeks in order to address the issues with the rule last year STULOAD should be less than 100 where TYPEYR is not equal to 1 (i.e. non-standard years) and COMDATE is greater than Y1-07-31 STULOAD should be less than 100 where TYPEYR is not equal to 1 (i.e. non-standard years) and ENDDATE is in the current reporting period -Only warnings to take into account accelerated learning

70. STULOAD rule changes STULOAD must be greater than 0 where FTEMETHOD=1 (50:50) and MODE not 51, 61 or 64 STULOAD must be greater than 0 where FTEMETHOD=2 (100:0) and COMDATE is greater than Y1-07-31 Institutions should review STULOAD and its relationship with FTEMETHOD as there are 000s of instances that would currently fail the above rules

71. Check documentation change Item 12 ‘Average instance FTE’ will be split into two – 12ai for standard years of instance, 12aii for non- standard Designed to enable institutions to better identify STULOAD reporting errors

72. Postgraduate students

73. Instance.MODE Codes 73/74 capture where a student instance changes to dormant status having previously been active on a full or part- time mode A significant number of HEIs failed to code any PG students as changing to dormant during the reporting period New exception warning in place to flag where this occurs For larger institutions this will also be raised in credibility checking

74. Instance.MCDATE Records the date when a PG student moves from an active mode of study to a non-active mode (writing- up, dormant, sabbatical) or vice-versa Used in conjunction with Instance.MODE 73/74 It is used in HEFCE’s funding algorithm and is therefore very important to get right

75. MCDATE validation New validation rule error ‘Instance.MCDATE must not be null where Instance.MODE = 73 or 74’… …this rule impacts upon 12% of all PG instances An additional rule added (also an error) ensuring that MCDATE is earlier than Instance.ENDDATE

76. MCDATE and HIN New HIN errors to be introduced to ensure that MCDATE is not null where: -MODE was inactive in the previous year and is now active -MODE was active in the previous year and is now inactive This is contrary to the previous guidance which stated that a change of MODE between reporting years did not require MCDATE to be populated… …and consequently expands MCDATE coverage to include dormant students 70,212 instances which were returned as dormant in C10051 but were active in C09051…of which 21 had MCDATE populated

77. Instance.PHDSUB Records the first submission date of the PhD thesis Compulsory for RC funded students, optional for non-RC students New validation rule: -‘Instance.PHDSUB date must be earlier than Instance.ENDDATE (where Instance.RSNEND=01) Consider that in the future additional validation might focus on the time lapse between the PhD submission and end dates with a view to improving the quality of data Additional data quality issue with regards to PGR awards being duplicated for a single instance

78. New REF items in check doc Contextual data provided to the panels will be preview to HEIs through check documentation PGR awards reported in a previous reporting period will not be counted in ‘included in REF’ HEIs should check awards not included in the REF and other inconsistencies Item 2b will be queried by HESA

79. ITT students

80. Course.TTCID New rule for institutions in Northern Ireland and England: -TTCID must not be coded 0 where COURSEAIM = H11 or I11 (i.e. BEd) SAS reporting has now been removed from HESA

81. Here TDA, gone tomorrow Much of the functions of the TDA and GTCE have continued within the Teaching Agency (TA) Performance Profiles will still be generated off HESA Student record… …The Profiles are becoming more important as TA make use of them to monitor provider performance and benchmarking which may have an impact on allocations

82. ITT In-Year record This data collection continues... The provisional registration requirement of data submission within 28 days from the commencement date of the student’s studies is no longer in place However timely submission remains vital for funding census information and to generate a TREF number for each student The TA have confirmed that the collection will not be updated with the 2012/13 update to equality opportunity fields

83. Awarding

84. CLASS New codes record the classification of integrated taught masters degrees… -12 Distinction13 Merit14 Pass …therefore COURSEAIMs M22/M26 must be coded 01-14 within CLASS First degrees must be returned with a CLASS within 1-11 No rule prevents foundation degrees, diplomas and relevant postgraduate qualifications from being returned with 12, 13 or 14 12, 13 and 14 are treated as ‘unclassified’ in XCLASS01

85. DLHE population DLHE inclusion population has changed: -More qualifications included -Dormant awarded PGR students included -Overseas (non-EU) students included Be aware of these increases when checking your population files What did you have last year, and how many should you have this year with the changes

86. Check documentation change New DLHE item (contained in a new DLHE tab) breaking down DLHE population by JACS level 2 Beneficial for understanding future KIS reporting

87. Data quality checking: What does your HESA return say about your institution?

88. HESA Student Record Advanced Seminar Stephenson Room, Broadway House, London 12 June 2012 Anthea Beresford

89. The aim of this session is to advise you: why we are doing this; and why it is so important now. HEFCE’s verification work on the HESA 2011-12 student record

90. Context Moving from a funding system that was insensitive: +/-5% tolerance band; Dampening in the system; Second chances. This system was predicated on dampening and stability.

91. Context (cont.) Moving to a system where “every student counts”. Be we looking at: Student Number Control; Phase-out funding; New funding in the new regime. Every bit of FTE has a monetary value attached to it.

92. In general the areas will be the same as last year. We will be looking at the robustness of the data affecting the following areas of our funding : Widening participation; Teaching enhancement and student success; Fund-out rates; Research degree programme. We will be looking at ABB+ qualifications on entry (replacing the AAB+ from last year’s exercise). Key areas we will be looking at

93. Long term advantage to institutions Ultimately it must be HEFCE because when it comes to funding decisions, based on the data: It will have been HEFCE that made judgments on data and on responses to queries; HEFCE has an understanding of the funding. During the verification process we will have raised queries and understood responses with reference to the funding consequences. We will have decided whether to probe further. Further down the line, if institutions have given HESA explanations we may not agree with, there can be issues. It is better to get the data right BEFORE submission. Why HEFCE and not HESA?

94. These have changed over the years. From about 1994-95 to the early 2000’s, student records were, in the main, statistical records that were required to be about right. In the last 5 years or so, the requirements made of student data have meant that greater accuracy in individual student data is a requirement. HEFCE’s involvement in the verification work is aiding this move towards greater accuracy AT THE POINT OF SUBMISSION. We have seen the fruit of our involvement in the 2010-11 verification work in that if the same thresholds were used for the Funding and monitoring exercise as were used for the 2009-10 reconciliation exercise, HALF the number of institutions would have been selected. Demands made of student data

95. As stated, similar areas will be reviewed as last year. We aim to provide detailed guidance on our website to assist institutions. Queries raised will be very similar to last year. Possible use of Minerva This depends on the outcome of consultation within HESA. HESA and HEFCE have agreed in principle that both organisations want to go down this route, following feedback from the sector. Whether this comes to fruition depends whether this is technically achievable. If it cannot be achieved, we will issue e-mails with attachments containing our queries as we did last year. Methodology this year

96. We appreciate the HESA collection process is iterative. We do not expect data to be in its final condition when we first review it. However, we believe it useful to engage early in the process, to highlight areas where data, if they remain as they are when we review them, could have funding implications. We very much urge institutions to engage with our queries as early as possible, to ensure any issues are identified and corrections made in plenty of time for sign-off, assisting in ensuring the institutions receives the correct level of funding based on data as submitted initially, and not following amendments down the line. Engagement of the sector in the verification process

97. Thank you for listening a.beresford@hefce.ac.uk

98. Early system Allows for early testing of data against the exception rules in place for the coming collection… …therefore much more beneficial than just using the kit Early system opened on 8 May 2012 Encouraging early use made of the system

99. HIN reports HESA remain committed to 0% HIN errors Institutions are still able to pass where errors below 1% however and explanation is needed HIN compare introduced for c10051 and should help focus remedial work HIN remains critical for completion rates and onwards use of the data

100. Sign-off date The sign-off date has changed…. …for C11051 the sign-off date will be 1 November 2012… …giving institutions an extra day between last submission of files and sign-off

101. Data supply Within the data supply icon you will now find heading templates for each of the templates i.e. Excel spread sheet with the field headings already populated Further guidance on how to use pivot tables added (http://www.hesa.ac.uk/pivot_instructions)http://www.hesa.ac.uk/pivot_instructions Derived fields are now including in the coding manual

102. Using data supply Quality assurance Benchmarking Trends and analysis Internal queries ‘HESA for Planners’ seminar coming soon! Demonstration of Data Supply…

103. Student Record 2012/13

104. Data model The data model has been changed… Changes only need to be taken into account by those English institutions who return FE data through HESA New entities: -Learner Employment status (0, unbounded) -Learner funding and monitoring (0, 16) -Learning delivery funding and monitoring (0, 20)

105. Funding Significant changes in direct response to the changes in fee regimes across the UK As fees are now variable and operating under different regimes in different parts of the UK, there is a requirement to understand eligibility and how much students are being charged, wherever in the UK they study Reporting needs to be undertaken on a UK-wide basis

106. Coverage Currently institutions need not return records for students who start a course and leave within the first two weeks without completing Coverage expanded to include any UG student registered on a SLC attendance confirmation date (October/February/May) irrespective of leaving within two weeks Return zero STULOAD and no modules Instance.SSN will be required for students Students will not be included in Standard Registration XPSR01 What information do HEIs need – a check documentation count?

107. Qualifications on entry Current coverage of this entity is all entrants where EntryProfile.UCASAPPID exists and this data has been provided by UCAS The coverage has been extended so that it is compulsory for English HEIs to return details of all level 3 qualifications held by all full-time entrants to undergraduate courses whose highest qualification on entry is below first degree… …HEFCE is also encouraging the completion of these data for students who entered with HE qualifications below full-degree Required to support the AAB+ policy within England This also extends the coverage for UCAS entrants where only results from the two most recent cycles are currently included in UCAS admissions transactions Qualifications for all entrants will require extending the coding frame to qualifications not currently part of the UCAS awarding bodies processing of exam results

108. Instance.SSN Student Support Number (SSN) should be returned by all institutions… …for all students in receipt of SLC supported loans Enables linking between HESA and SLC data at a statutory level The SSN can change, however only in exceptional cases and we will therefore validate that it does not through HIN Exception will error duplicates for instances SSN will likely be added to Data Supply

109. HESA/SLC linking Ensuring data integrity and accurate linking will be essential It is envisaged that as part of this SLC could provide HESA with a list of valid SSNs by institution… …although differences between in SLC and HESA in the definition of which institution a student belongs to might need to be overcome There are not currently any plans to allow HEIs to preview the data

110. Instance.FEEREGIME Captures the fee regime that the student is under, either the old pre-2012/13 or the new regime in for 2012/13 onwards Compulsory for FT UG and PGCE instances in Scotland, Northern Ireland and Wales with home fee eligibility (or fee eligibility not assessed) where Instance.SSN does not exist Compulsory for FT and PT UG and PGT instances in England with home fee eligibility (or fee eligibility not assessed) (where FEEELIG= 1 or 3 and FUNDLEV is not 30 or 31) English HEIs must supply this irrespective of an SSN existing using HESES definitions Institutions are required to code existing students HIN checks will be introduced as well as exceptions comparing FEEREGIME with COMDATE

111. Instance.GROSSFEE Captures gross fees; that is fees before any financial support such as waivers or bursaries are taken into account A value in pounds (£) for new regime students (although can be returned for old regime) Institutions in England: Undergraduate and taught postgraduate students with home fee eligibility (or fee eligibility not assessed) Institutions in Wales: Undergraduate and PGCE students with home fee eligibility (or fee eligibility not assessed) Institutions in NI: All full-time undergraduate instances with home fee eligibility (or fee eligibility not assessed) covered under Post-Sept 2012 fee regime (Instance.FEEREGIME = 20) Institutions in Scotland: All full-time undergraduate instances with home fee eligibility (or fee eligibility not assessed) covered under Post- Sept 2012 fee regime (Instance.FEEREGIME = 20) that are not domiciled in Scotland or the EU

112. Instance.GROSSFEE (continued) Not required for dormant instances For non-standard years (where Instance.TYPEYR = 2, 3, 4 or 5) the full fee for the year of instance should be returned Where the fee for the course is charged up front the institution should divide this over the number of the years of the course Employer sponsored courses – HEFCE are working this through but would welcome an institutional view: -If NHS paying fees on student behalf, should GROSSFEE be £9000 but NETFEE £0?

113. Instance.NETFEE Captures net fees; that is after any financial support from the institution such as waivers are taken into account Coverage statements for NETFEE are consistent with GROSSFEE For non-standard years (where Instance.TYPEYR = 2, 3, 4 or 5) the full fee for the year of instance should be returned Not required where a valid SSN is returned Required for new regime students not applying to the SLC Where GROSSFEE exists NETFEE must also and be less than the value of GROSSFEE

114. Equality data The Equality Act (2010) defines a new Public Sector Equality Duty that expands the range of quality characteristics that apply to HE institutions Use of consistent coding frames and central collection will allow comparisons and benchmarking both within the sector and with the local/regional populations It also assists the sector in demonstrating its commitment to equality issues It will be optional for institutions to collect and supply this data and optional for individual students to answer the relevant questions if asked This data will not be provided through UCAS *J

115. Student.SEXID This field will replace the current Student.GENDER field and will record the biological/legal sex of the student: -1Male -2Female -3Other All UK institutions (compulsory) No requirement to recode existing students Code 3 should not be used as ‘not known’ or ‘prefer not to say’… …10% threshold for use of code will apply

116. Student.GENDERID This field will record the gender identity of the student Students should, accordingly to their own self- assessment, indicate if their gender identity is the same as the gender originally assigned to them at birth Optional for all students throughout the UK Suggested question: Is your gender identity the same as the gender you were originally assigned at birth?

117. Student.RELBLF This field records the religious belief of student, on the basis of their own self-assessment Optional for all students throughout the UK Census questions to be used, namely: -England and Wales: What is your religion? -Scotland: What religion, religious body, or denomination do you belong to? -Northern Ireland: What religion, religious denomination or body do you belong to? Consistent coding frame with HESA Staff Record

118. Student.SEXORT This field records the sexual orientation of the student, on the basis of their own self-assessment Optional for all students throughout the UK Suggested question: What is your sexual orientation? 01 Bisexual 02 Gay man 03 Gay woman/lesbian 04 Heterosexual 05 Other 98 Information refused

119. Ethnicity The changed coding frame is in line with benchmarking against different national census questions New codes for Scotland domiciled students – ’13 White – Scottish’ The new coding frame has been designed to ensure that non-Scottish institutions do not have to re- survey or re-code continuing students. All of the existing ethnicity codes map into the new structure

120. Course.AWARDBOD will collect the qualification awarding body A UKPRN and others… e.g. Edexcel, SQA, Pearson etc Sits on course entity therefore if Poppleton University offer the course (awarded by themselves) however there are students taking it awarded by a different body, then two courses will be required Maximum occurrences of 8 for where the award is a collaboration In the majority of cases currently we would expect this value to be the same UKPRN as the reporting institution (min occurrences=1) This field is not intended to record a body that accredits a course awarded by the institution e.g. ITT courses that lead to QTS awarded by the Teaching Agency or engineering courses that lead to Chartered Engineer status This field is not applicable to FE provision Course.AWARDBOD

121. Module.FRANIND Indicates if a module is part of a franchised or other collaborative arrangement (in addition to PCOLAB and TINST) Institutions in Wales (only) If the module is part of a franchise arrangement then code 1 should be used regardless of whether the module is also part of another collaborative arrangement ‘Other collaborative arrangements’ could be joint courses 1 Taken as part of franchise arrangement (in whole or part) 2 Taken as part of a collaborative arrangement (in whole or part) other than a franchise 3 Not taken as part of franchise or other collaborative arrangement

122. Indicates if the module was taken through APEL (not required for England, Northern Ireland or Scotland) -1 Module taken through APEL -2 APEL module -3 Module not taken/available through APEL Code 1 is to be used where the student on the module was assessed through APEL, where the module can be assessed through APEL or other means Code 2 is to be used where the module the student is on is available through APEL only APEL FTE does not contribute to STULOAD This can't be captured using MODOUT as the categories will not be mutually exclusive StudentOnModule.APEL

123. FE students For English HEIs who report their FE students to HESA… …the existing field Student.ULN will become compulsory for a student where any Instance.FESTUMK is coded 1, 3 or (possibly) 4 New fields bringing the HESA return in line with the ILR added to Instance entity as well as the new FE entities

124. Instance.INITIATIVES Valid entries of existing field to be expanded to include: -8One Wales (W) -9European Social Fund (W) -ANSP (for those receiving support) (E) Maximum occurrences remains as 2 This field collects information with respect to student instances that are part of a scheme. Where a student transfers course within the same instance, Instance.INITIATI VES should continue to identify the scheme All other HEFCE codes (e.g. Lifelong Learning) except for NSP are to be removed for 2012/13

125. JACS coding JACS version 3 should be used for 2012/13 Course.SBJCA and ModuleSubject.MODSBJ will only accept a valid JACS3 code from 2012/13 onwards The generic codes that consist of a subject group letter and three zeros (and Y000) can be used in the Course.SBJCA field to describe a truly interdisciplinary course only

126. Cost Centres 2012/13 Detail of changes to specific cost centres can be found on HESA website… …general approach was to future proof cost centres and allow institutions greater ability to do benchmarking work… …as well as align cost centres to REF UOAs Now a 3 digit code Mapping document is available online

127. Institution Profile Formerly the Campus record, the Institution Profile data collection will in addition to campus information collect as contextual data each institution's allocation of departments to (revised) Cost Centres The provision of mapping information to HESA will be compulsory in England and optional for institutions in Wales, Scotland and Northern Ireland The data will be collected via Institution Profile collection in June 2013 The allocation of professional services to Non-academic Cost Centres (Professional Services Cost Centres from 2012/13) will not be mapped and returned to HESA

128. Mapping cost centres to departments 1 Cost centre -Should relate to where staff are located for the activities they undertake i.e. CC follows the money Department -Free text field containing the name of the department from which staff are mapped to CCs Institutional structure tier 2 -Optional free text field containing the middle tier of the organisational structure Institutional structure tier 1 -Optional free text field containing the top tier of the organisational structure Tier 1 should only exist where tier 2 has been completed

130. Mapping cost centres to departments 2 Consideration should also be given to departments and cost centres which may not map on a one-to-one basis Proportion of the CC in the department -% of the CC represented in the given department Proportion of the department in CC -% of the department that the academic cost centre makes up CCENTREDEPARTMENTTIER2PROPINDEPTPROPOFDEPT Economics and Econometrics Business studies School of Business and Finance 75100 Economics and Econometrics MathematicsSchool of Engineering & Mathematics 2550

131. Student Record 2013/14

132. Mobility, mobility, mobility The original 12/13 consultation included 4 new fields as part of a new entity to capture information about student mobility… …type, duration, location and scheme …it is anticipated this data will be collected for 2013/14 Work is being done the relationship between this new entity and the existing fields in the Student record Institutions are encouraged to consider how they might capture this data

133. Online help Support Centre www.hesa.ac.uk/supportcentre – Quick guides on common issues inc. sandwich students, distance learning and CE students – Understanding the NSS reports Coming soon… Check documentation checking guide Help on analysing your submission C11051 Preparation guide Key SC requirements

134. Keep in touch If you require additional training help, including bespoke visits to your institution, get in touch with the training department… w:www.hesa.ac.uk/training e:training@hesa.ac.uk t:01242 211472 Follow us on Twitter: @HESATraining