Student Record Advanced - June 2013

Objectives Learn the Student record to an advanced level Cover changes to the record for the coming year Give opportunity for questions and discussion Introduce changes for 2013/14

Student record 2012/13

Coverage and Courses

Coverage For 2012/13 institutions are required to return records for UG students who start a course and leave within the first two weeks (without completing) where they have applied for a loan and are present on an SLC attendance confirmation date Confirmation dates are defined as the first day of each term for the course Such students must be returned on a new reduced return 08 Students will not be included in Standard Registration XPSR01 Return MODE as the value it would have been had study continued

Instance.REDUCEDI Type 08 can only be used for UG students with an SSN Credibility check in place to identify where reduced return used but time elapsed is greater than 2 weeks REDUCEDI=08 will be vital in removing students from unrelated validation Return zero STULOAD and no modules… however where STULOAD is returned usual validation will then apply No qualification can be awarded Exception rules and credibility checks will be in place to ensure appropriate use Note that early specification of REDUCEDI=08 wrongly excluded the course entity

Course.CTITLE KIS record has changed how course titles are captured – no longer a free text field This requirement dictates that ‘BA Hons’ etc is removed from the course title stored in your systems Where the same system is producing a Student and KIS record, this has implications for the latter as you will lose that level of detail POPDLHE contains CTITLE

Course.AWARDBOD Collects the qualification awarding body - a UKPRN or generic code e.g. Edexcel, SQA, Pearson etc and can be returned up to 8 times Sits on course entity, therefore if Poppleton University offer the course (awarded by themselves) but there are also students taking it awarded by a different body, then two courses will be required In the majority of cases currently we would expect this value to be the same UKPRN as the reporting institution (min occurrences=1)

Course.AWARDBOD validation Error: If Course.AWARDBOD = 1 (Edexcel) or 2 (SQA) and COURSEAIM not J30 (HND) or C30 (HNC) Exception Error: Where more than 20% of HE instances do not have at least one occurrence of Course.AWARDBOD equal to the institution’s UKPRN (except HEIs without degree awarding power). Institutions in Wales are also expected to return the University of Wales (10008574) as an awarding body and this will need to be treated in the same way as the institution’s own UKPRN Exception Error: Where Course.AWARDBOD contains a UKPRN, it must be for an institution with degree awarding powers

JACS version 3 284 new JACS codes! 45 discontinued codes Impacts upon: EntryProfile.PGCESBJ CourseSubject.SBJCA ModuleSubject.MODSBJ Where these fields are being returned, ensure you are using JACS 3

New to check documentation New item 16 providing an overview of changes to subject coding resulting from JACS2 to JACS3

New cost centres Remember that data must be mapped to the new cost centres for 2012/13 New exception rules: Error where ModuleSubject.COSTCN contains a cost centre code not returned on the Institution profile return Error where a cost centre code has been used in Institution Profile but is not subsequently used in any ModuleSubject.COSTCNs The cost centre sheet in Check Documentation has been updated – but retains the now defunct CCs 29, 31, 33 for reference purposes

Student and Entry Profile data

Equal Opportunity data Student.GENDER has now been replaced with Student.SEXID Valid entry 3 ‘Other’ replaces 9 ‘Indeterminate’, however should be used sparingly (validation warning trigger if returned for more than 2%) Student.ETHNIC has 4 new values (13 ‘White Scottish’, 19 ‘Other White background’ (both Scotland only), 15 ‘Gypsy or Traveller’, 50 ‘Arab)… …the preference is for Scottish HEIs to use 13 and 19 instead of 10 ‘White’ (although this is not mandated) Student.RELBLF, Student.SEXORT, Student.GENDERID have all been added to the record but are optional An additional value of 99 ‘Not known’ has been added to NIDEPEND (although use will be monitored)

EntryProfile.QUALENT3 Highest qualification that the student holds ‘on entry’ For 2012/13 there are two new codes: P93 ‘Level 3 qualifications of which all are subject to UCAS Tariff’ P94 ‘Level 3 qualifications of which some are subject to UCAS Tariff’ New codes to be used instead of P91 ‘Level 3 qualifications of which some or all are subject to UCAS Tariff’ for 2012/13 entrants P91 remains a valid entry for continuing students and there is no requirement to recode P91

QUALENT3 validation changes Use of P80 ‘Other qualification at level 3’ should be limited as it is preferred that P9* codes are used instead Error if more than 10% of students with code P80 and no Qualifications on Entry (QoE) data… …beware that UCAS currently use P80 in *J X00 and X01 ‘HE access course QAA/Not QAA’ were previously treated as an unknown level of qualification, however for 2012/13 they will now be deemed level 3 and therefore QoE data will be required P93 is not valid where any associated QUALTYPE is non-tariff bearing (using either HESA or UCAS definition of tariff)

New to Check Documentation Item 7 now split into 7a & 7b ‘proportion of highest qualification on entry for first years’ Subtotals also added to item 7a

Qualifications on entry Captures the qualifications on entry data for relevant students A student can have up to 30 tariff-bearing qualifications Detail captured through fields: QUALTYPE e.g. A ‘GCE A Level’ or AH ‘Advanced Highers’ QUALSBJ e.g. S11 ‘Sociology’ QUALGRADE (where applicable) e.g. B or DMM QUALYEAR e.g. 2012 QUALSIT e.g. S ‘Summer’ or W ‘Winter’ Data is vital in deriving an average tariff score (XTARIFF) which is used in KIS, PIs, league tables For institutions in England this data is used by HEFCE when checking and setting SNC Don’t use ‘best fit’ when recording qualifications

Qualifications on entry - coverage The coverage for 2012/13 makes it 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 ABB+ 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 (ABL) Qualifications for all entrants will require extending the coding frame to qualifications not currently part of the UCAS awarding bodies processing of exam results Coverage for Northern Ireland, Scotland, and Wales institutions remains just UCAS entrants with tariff-bearing qualifications

Level 3 expansion file To help English HEIs meet the requirements of the extended coverage, UCAS have made available a file containing all unverified level 3 qualifications a student enters into APPLY Non-England HEIs also have access to the file (and our survey suggests just over 50% will be including the data in the Student record) England HEIs were able to choose whether to provide this additional data directly to HEFCE (through either UCAS (a) or themselves (b)) or by including it in the HESA Student record (c)

Considerations Unverified data supplied directly to HEFCE will be ring-fenced for SNC purposes only Data submitted by HEIs through option C will be deemed as verified by the HEI and used in all routine analysis– including XTARIFF calculations – and validation checks A known issue with the expansion file is that it contains come level 2 qualifications that should not be returned – these are restricted to Asset Languages qualifications where the grade achieved dictates whether they are level 2 or 3

FTE reporting

Instance year An instance year is the period from commencement date (Instance.COMDATE) to on or near the anniversary of that date The activity within each instance year is captured within each HESA reporting period… * * *

Instance.TYPEYR – standard years Defines whether the activity within the instance year is contained within a HESA reporting period or not Where it is contained TYPEYR should equal 1… …’Course academic year contained within the HESA reporting year 1 August – 31 July 1 1 1

Instance.TYPEYR – non-standard The complexity comes with non-standard provision (activity or course year overlaps HESA reporting years) which are recorded as TYPEYR equal 2 (or 3/4/5) New validation for 12/13 will ensure that codes 3, 4 and 5 are being used correctly when compared to COMDATE 2 2

Changing TYPEYR TYPEYR does not typically change within an instance… …however for courses containing partial years/stubbys or where students go into writing-up mode it can 1 2 2 1 2 1

Instance.STULOAD Under and over-reporting of STULOAD remains a problem – particularly for TYPEYR 2s… …for which the FTE must be split (unless in Scotland) Determined using benchmark for FTE using either time or completed credit... …however be careful when using modules to derive UG standard is 120 credits which equals a STULOAD of 100.00 PGT standard is 180 credits which also equals a STULOAD of 100.00 STULOAD should be reduced for PT provision and those who withdraw

Misreporting STULOAD 1 One year PGT running from October 2012 until October 2013 All FTE is being reported in HESA year 1, meaning that in HESA year 2 a dormant award is made with a STULOAD of 0 or the award is returned as if it was given in HESA year 1 TYPEYR=2 instances will only tend to have a load of 100.0 where the course is =>2 years in length or it is accelerated 100.0 0.0

Misreporting STULOAD 1 One year PGT running from October 2012 until October 2013 FTE should be accurately split between HESA years with the student being awarded from an active mode in HESA year 2… …unless you are a Scottish HEI… 85.0 15.0

Misreporting STULOAD 2 180 credit PGT running from January 2012 to January 2013 All modules are assigned to the student from the outset… …meaning the STULOAD is recorded as 100.0 in year 1 and 0.0 in year 2 with a dormant mode 100.0 0.0

Misreporting STULOAD 2 180 credit PGT running from January 2012 to January 2013 STULOAD must be split accordingly: HESA year 1 should include the STULOAD from completed modules A and B and some (not all) of load from C 50.0 50.0

StudentOnModule.MODSTAT Details whether modules span HESA reporting years Can be important in allocation of STULOAD between years Validation added in recent years to flag up relationship between status and outcomes 2 2 3 1 2

Instance.MODE Records the mode of study for the student instance year – not the reporting period i.e. non-standard instance years will have the same mode in both reporting periods New validation in place to flag where codes 01 ‘full-time according to FC definitions’ and 23/24 ‘Sandwich thick/thin’ are used but time elapsed is less than 24 weeks

Instance.MODE – writing-up (43/44) Many HEIs are not using the writing-up codes at all – even with a large number of PGRs in their data PGR & PGT students who have been studying for more than 4 years but remain on FT MODE with 100.0 STULOAD being reported… …or at times a STULOAD <10.0 Remember that where a student instance overshoots the anniversary of its commencement date (i.e. more time is required) then they move to a writing up mode… …and there STULOAD should be capped to 10.0 for a full-year writing-up

Suspending studies Where a student suspends studies during the year then NOTACT should be set to 1… …with the STULOAD reduced to reflect the interruption PG students at HEIs in England and Northern Ireland should also have their MODE adjusted to 73/74 ‘Change to dormant status’ and the date at which they went inactive recorded in Instance.MCDATE Note for C12051 the issues around MCDATE validation have been resolved

New to Check Documentation Item 12 has been broken down further to provide a three way split of starters, leavers and ‘others’. The different groups may have very different FTE values that impact the average

Fee data

Fee Information A plethora of fields capturing information regarding student fees: Instance.FEEELIG – defines eligibility to pay home fees Instance.SPECFEE – identifies special fees and thus can be used to cross-check NETFEE e.g. SPECFEE=3, NETFEE must be 0 Instance.MSTUFEE – indicates the major source of tuition fees

Instance.FUNDCODE At the individual student level, FUNDCODE records whether the student is counted as 'fundable‘… …and should be consistent with the early statistics return to each funding council For new regime students ‘fundable’ includes all those who are eligible for an SLC loan For 2012/13 Code 4 ‘Fundable by funding council but funds not sought’ has been removed from the coding frame The label for 1 has now been altered to remove the ‘and sought’ clause From 2012/13 instances fundable by funding council should be returning under code 1 'Fundable by funding council' irrespective of whether funding was taken up or not

Instance.FEEREGIME - England Captures the fee regime that the student is following: 10 Pre-Sept 2012 regime 20 Post-Sept 2012 regime For institutions in England this field is required for all full and part-time undergraduate and taught postgraduate instances (irrespective of whether they have applied for student finance) Ensure HESES definition of fee regime is used Field cannot be returned for students outside of the coverage but can be for dormant or writing-up students Crucial in establishing population for whom fee information is required

Wales, NI For institutions in Northern Ireland and Wales, the SLC will have this information for students who apply for student finance so this field is not required if the Student Support Number (Instance.SSN) is returned. It is required for all students not applying for student finance. Code 10 'Pre-Sept 2012 regime' applies to those students who started pre-September 2012 and, hence, are not covered by the new fee regime. Code 10 'Pre-Sept 2012 regime' should also be used for students starting at the institution in 2012 who are not under the new fee regime. This will be, for example, students who transfer in from another institution or come from another institution to do a top up to a degree, having started their original course before 1 September 2012.

Scotland For institutions in Scotland, the SLC will be able to provide this information to HESA for students who are paying tuition fees (typically fee regime 20 'Post-Sept 2012 regime' these are students domiciled in England, Wales and Northern Ireland) and so this field can either be completed by the HEI directly or be populated with SLC data if the Student Support Number (Instance.SSN) is returned Code 10 should be used for Scottish domiciled students

Historical position – new regime students At post-collection seminars in January we proposed that HEIs would either return an SSN (which we would use to link to SLC data and capture the fee information) or provide the fee information directly within the Student record (where an SSN did not exist)… but not both! This proposal was not welcomed by HEIs

Current position – new regime students Linking between HESA and SLC data difficult due to inconsistent definitions, therefore: SSNs must be returned where they exist Where SSN does not exist but FEEREGIME=20 then GROSSFEE and NETFEE must be returned HEIs cannot elect to just return GROSSFEE/NETFEE where SSN exists HEIs can elect to return GROSSFEE/NETFEE alongside an SSN (and in such cases HESA will not carry out any checks during collection which try to match or correlate HEI supplied fee data with SLC fee data

Instance.SSN Required for all students in receipt of statutory student finance (except where COURSEAIM ends in 90 or 99)… …however must not be returned for PGR and most PGT students, as well as those not eligible to pay home fees An SSN cannot be duplicated at a HUSID level but might (on occasion) be duplicated within an instance Using the SLC data file provided to HESA in June a new exception rule (warning) will trigger when the HEI submits an SSN that does not match any SSN supplied by the SLC. Where amatch cannot be established there is, however, no requirement for the HEI to return Instance.GROSSFEE and Instance.NETFEE A new exception rule (warning) will also trigger when an SSN/DoB combination submitted by the HEI does not match an SSN/DoB supplied by the SLC Whilst warnings, both rules will be queried through Minerva where they are triggered

Scotland issue Due to SAAS issuing dummy SSNs for Scottish domiciled students, HESA will not attempt to link to SLC data where SSN exists Where student is domiciled outside of Scotland HESA will require the SSN and will link to SLC data Scottish HEIs should return GROSSFEE and NETFEE where SSN does not exist Fee information only required for non-Scottish domiciled students Can SSNs be returned for COURSEAIMs outside the coverage?

Instance.GROSSFEE Must exist where Instance.FEEREGIME=20 and SSN does not – HEIs can optionally return it where SSN does exist Must not exist for old regime students Records an annualised amount for the instance year i.e. if a student withdraws the amount they would have paid for the course year should be returned For Welsh domiciled students in the UK, and EU domiciled students in institutions in Wales, the Instance.GROSSFEE should be the fee charged before the fee grant is applied Where a student repeats a term or semester in an additional year to the agreed structure of the course, HEI should report the additional fee in Instance.GROSSFEE… …however the value cannot exceed £9000 Where the fee for the entire course is charged up front this should be split over the number of programme years to give an annualised fee

Instance.NETFEE Must exist where Instance.FEEREGIME=20 and SSN does not – HEIs can optionally return it where SSN does exist Captures the net fee charged, that is after any financial support from the institution such as waivers are taken into account Examples of waivers might include where a faculty or external body has subsidised fee, NSP (where implemented as a fee waiver) In-kind contributions should not be factored into the value within NETFEE

OFFA checks Where GROSSFEE/NETFEE are returned they will be subject to checks against the data returned to OFFA… …this is still the case where fee fields and SSN are returned Checks undertaken at TEST and FULL COMMIT stage Where just an SSN exists the checks will not be undertaken Check (at HEI level) will look at CERTHE/DIPHE, First Degree and Foundation Degree values as submitted within OFFA agreement Error where GROSSFEE exceeds the value

Additional fees Where the student is charged additional fees these should be reflected in GROSSFEE/NETFEE e.g. a writing-up period which incurs a fee Graduate Diplomas excluded out of validation capping fees at £9000 but all UG courses are not

Bridging courses Report the fee in the year in which the bridging course ends

Non-standard years (TYPEYR=2) For non-standard years the full fee for the year of instance should be returned in the reporting year within which the year of instance commences In future years HIN linking will ensure fee is not reported twice (where course length = 1)

However… …additional fees will need to be considered Therefore HIN linking will need to take into account the amount For example fail where fee in HESA year 2 is => than value of HESA year 1

NHS and other bodies Where the NHS or other body pays a per-capita charge equivalent to a fee this should be recorded in Instance.NETFEE This was previously causing validation errors however FUNDCODE=5 ‘Funded by the DoH’ has now been removed out of the rule capping fees at £9000 However where the NHS pays a single fee that is not linked to individual students then zero should be returned in NETFEE

Part-time fees An annualised fee based on module selection of the student should be returned in GROSSFEE/NETFEE 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 a fee based on the typical module selection of a part-time student on the course? Return the fee based on modules started in the reporting year?

Onwards use of fee data Linked SLC fee data will not be included in any output to HEIs as part of this collection HESA will undertake post-collection analysis of linking and data integrity using evidence from where institutions have returned both a linked SSN and GROSSFEE/NETFEE Data returned in GROSSFEE/NETFEE will not be used in outputs There is a live project at HESA addressing the challenges of linking between the Student record and SLC ahead of C13051

New to check documentation New fees tab within check documentation Provides an instance count for FT and PT UG and PG students

Defining the Instance

Instance.INITIATIVES Identifies students who are part of a specific scheme that requires monitoring Any given instance can be on up to two initiatives during its life – providing they are not the same A number of codes removed for 12/13 (1, 3, 4, 5, 6) 3 new codes 8 ‘One Wales Scheme’ (W), 9 ‘European Social Fund’ (W), and A ‘National Scholarship Programme’ (E) have been added for 12/13 Where NSP for 300 students has been subsumed into general HEI support and then distributed to 1500 students – all 1500 should be flagged as NSP The tactical solution of code B, used to record the ABB+ equivalency of an ‘Access to HE Diploma’, will remain in place for another year as UCAS are unable to provide the detail of grade

Instance.INITIATIVES validation HEFCW have supplied counts for code 8 (One Wales Scheme) which will be used to cross-validate NSP can only be flagged for UG students and where Instance.FEEREGIME=20 No more than 5% of NSP flagged instances can be domiciled from outside of England HEFCE are considering supplying NSP counts by HEI for cross-validation purposes

Instance.SPLENGTH This field is used to indicate the normal elapsed time in the units indicated by Instance.UNITLGTH from the commencement of study, to completion of the instance Vital in determining accurate NSS population A course length should not be adjusted for students with different lengths e.g. direct entrants It is expected that part-time courses will take twice as long as their full-time equivalent – and should be coded to reflect this Incorrect course lengths = incorrect NSS = incorrect KIS

Instance.YEARPRG Records the programme year of the course that the student is currently on Integrated foundation degrees are coded as 0 in this field, as shown in the example below New validation will prevent the use of 0 in YEARPRG where the course length is 1 year or less

Instance.YEARPRG validation New warning to flag where YEARPRG value is greater than the course length (>SPLENGTH where UNITLGTH=1) Dormant students will be included in the check as YEARPRG must not be (but often is) incremented for periods of dormancy… …the warning will also help reinforce the guidance that a course length should not be adjusted for students with different lengths e.g. direct entrants New error enforcing that YEARPRG must not be 99 where UNITLGTH is not 9 ‘no defined length’ where MODE <>63/64… …24,620 instances would have failed this rule in C11051… …however for Scotland this rule will exclude MODE=39 (part-time unstructured)

Instance.YEARPRG and Instance.YEARSTU YEARSTU records the number of years the student has been on the instance The two fields should typically increment together Where the two get significantly out of line this should be investigated e.g. YEARSTU 10 but YEARPRG 2 Full-time Full-time - retake Part-time

Completion and Awards

Instance.FUNDCOMP In England, for non-standard years of instance HEFCE fund the year starting rather than ending This mirrors the change to how HESES counts activity Thus in HESA year 2, FUNDCOMP will relate to instance ‘Year two’ as opposed to ‘Year one’ This inevitably results in an increase of FUNDCOMP=3 hence the survey HEFCE have been carrying out It is anticipated that the survey will be run again next year

Instance.FUNDCOMP considerations Module level data is likely to be required to accurately derive funding completion at an instance level Consider the tie-up between TYPEYR and FUNDCOMP – for example how many TYPEYR=2 first year students could possibly be a FUNDCOMP=1? FUNDCOMP remains critical as the volume measure in funding methods for both old and new-regime students is based on completed FTEs

Instance.PHDSUB Records the date of first submission of thesis Often not recorded correctly or incorrectly updated hence an increase in validation (particularly around ENDDATE) New guidance for 2012/13: Where an award is made without submission due to death or serious illness the award should be returned in QualificationsAwarded.QUAL but the submission date should be returned with <PHDSUB ReasonForNull="9"></PHDSUB>

Instance.ENDDATE Records the date the student left the student instance… …defined as being the point at which the taught or structured part of the instance, including any formal writing-up period, is completed A new warning (will be an error in C13051) has been added to ensure that an ENDDATE exists where H10, H11, H16, H22, H23, H50, M00, M01, M10, M11, M16, M22, M50, M71, M86, E00 or D00 are awarded 3555 instances would have flagged this warning/error last year

Making an award Institutions will typically know the award status of instances which finished in the reporting year i.e. by 31 July 2013 In such cases the award should be made with Instance.RSNEND set to 1, and the relevant QualificationAwarded.QUAL Note that a new error has been introduced to trap where a PhD award is made to a student studying at a level below PGR There are also two new qualifications added: M44 Certificate at level M H62 Pre-reg grad diploma/certificate leading to eligibility

Squeezing awards A common reporting error is where HEIs squeeze an award into the wrong reporting period because the instance ends just before collection closure Students who complete their instance by 31 July 2013 but whose final confirmation of award by exam boards may be after this date can be included in the C12051 Student record where their results are known before the data collection closes

New to Check Documentation What is the difference between 2 and 2a?

Quality Assurance

Quality assurance We need to understand the importance of data and its impact in order to make live informed decisions Everything we do has an opportunity cost

“Let’s play Opportunity cost!!!” Student study lengths Qualifications on entry Incorrect course lengths result in the Home Office banning you from recruiting students under tier 4 Missing qualifications on entry data means that HEFCE have to make assumptions about the number of ABB+ students meaning you hit your SNC earlier The same incorrect lengths mean your NSS population is incorrect resulting in a fall in total satisfaction at your HEI thus impacting KIS and league tables Your average tariff score is reduced as a result of missing or inaccurate qualifications – this impacts the performance indicators, KIS, and league tables

“Let’s play Opportunity cost!!!” Equal opportunity miscoding Qualifications awarded Your data shows that no one at the institution has a disability, this results in several newspaper articles being written. 70% of unknowns for the ETHNIC field calls into question the institution’s ability to monitor equal opportunities. The poor quality data impacts on your funding council and ECU’s ability to analyse equal opportunity and social mobility. You fail to report a number of awards resulting in your DLHE population shrinking and impacting upon KIS. The misreporting also impacts on other measures such as RDQRs, league tables, and publications.

“Let’s play Opportunity cost!!!” Student FTE Incorrect JACS coding within Course You have over-reported FTE in the STULOAD fields which results in an inflated SSR and subsequently you fall two places in a league table. The over-reporting also results in funding reconciliation issues. Incorrect course data results in not being able to link between the Student and KIS records which impacts on aggregations. A number of league tables, as well as the Unistats website, excludes you from certain subjects that you do actually offer.

The tools at your disposal Check documentation Exception – and its ever changing role Minerva Data Supply HESA for Planners manual which details how to recreate check documentation items, undertake additional DQ checks

Minerva Important stage in quality assurance so ensure that the questions asked are responded to in full If you need help understanding what is being asked then contact Institutional Liaison team DQ checks by HEFCE will continue with questions asked through the system Contextual Minerva to continue

Data supply changes Core table: Student.UCASPERID, Instance.FEEREGIME, Instance.GROSSFEE, Instance.NETFEE, Instance.SSN all added XPDLHE01 removed (XPDLHE02 is retained) Module table: Module.FRANIND added Qualifications on Entry: Student.OWNSTU and Instance.OWNINST added New Student on Module tables (see appendix 2) New Course table (see appendix 2)

Check doc changes for 2012/13 Revised tolerances Items 1, 2 & 3 will now highlight year on year changes of +/- 10%/50 students Item 11 will look at sector averages rather than just the previous year Move to JACS3 and new cost centre coding frame New Fees tab More detailed breakdowns, summations and percentage changes added to enable checking

Check documentation walk-through

HESA Identity System Replacing the plethora of logins and passwords HESA contacts have to use (i.e. for Minerva, Aardvark, heidi) Minerva will be the first system to adopt the new system Expected in Summer 2013

Aardvark Regeneration Interactive display of failing records. User can add the column they want. User can drill into other entities Interfaces to better understand the overall quality picture. Which entities/attributes have most quality issues? Tolerances operate at institution level. Tolerances adjustable during collection Current thinking is downloadable validation kit will be replaced by on-line service that includes checks and reports currently only available in collection system Quality issues surfaced to users as early as possible. Expecting to do away with TEST-COMMIT and to automatically run all quality issues and reports every time data changes Integrate above with Minerva (or Minerva with above). E.g. auto-detection and removal of issues fixed by resubmission An API for use by HEIs

HIFR HESA Institutional Feedback Report Student record contact at each HEI will have the report from C11051 In June the Senior Liaison contact at HEI will receive all reports across all records for the institution

Student Record 2013/14

2013/14 Key areas

EntryProfile.CARELEAVER Records whether a student is a care leaver To allow England to calculate the population of WP students To monitor participation in HE of people who have been looked after in Scotland To allow Wales to monitor participation in HE of Care leavers Now on the EntryProfile entity rather than Student

EntryProfile.CARELEAVER continued Only expected for new entrants to 2013/14 Includes NCTL students , excludes NHS funded students Not to be returned outside of the coverage No age limit Institutions recording care leavers for internal purposes (i.e. as part of their OFFA Access Agreement, or where the institution holds the Buttle UK Quality Mark) must use code 01 where applicable Institutions where this is not the case should complete this field using data supplied through the UCAS Data for HESA (*J) transaction

UCASPERID & CARELEAVER HEFCW do not want data for non UCAS applicants If no UCASPERID is returned, no CARELEAVER can be returned If UCASPERID is returned and cannot be linked to *J data HESA will accept If a link can be made to *J but a value of unknown is returned on the *J, HESA will accept either If a link to the *J can be made but there are differences between the two, an error will be returned

Collecting the CARELEAVER data For non UCAS entrants this data must be collected for FT and PT UG and should be coded as ’01’ if they are care leavers HEIs are able to collect care leaver data at enrolment via registration form The registration form will be acceptable provided that the definition of the student having been in care on or after their 16th birthday is included

Instance.ELQ This field will capture whether a student is aiming for an Equivalent or Lower Qualification than one already achieved All instances at HEIs in England where Instance.FEEELIG= 1 and Course.COURSEAIMbegins with E, M, H, I, J or C To assist in determining whether a student is non-fundable under the ELQ policy Code 09 ‘Not required’ is acceptable for the following students: ITT students on courses that lead to QTS INSET students who hold QTS NHS funded students who are non-fundable

Instance.INTERCALATE This field indicates whether a student is on an intercalating course Must only be used for the year(s) that a student is intercalating May be returned for students intercalating to a course of any level For the year in which a student is intercalating, Course.COURSEAIMshould be changed to record the intercalating course aim, but Instance.NUMHUS should remain the same

Financial Support This new entity will capture the financial support given to students allowing OFFA to analyse the effect of the investment being made across the sector The data will allow comparisons to be made between groups of students, including those from low-income and other under-represented groups Must be completed for all instances of Home and EU, HEFCE / NCTL fundable students in receipt of financial support Not to be returned outside of the coverage Reflects the current instance year OFFA will provide a total support figure to HESA which will be used as an exception check against the total amounts returned by the HEI on the Student record

FinancialSupport.FINTYPE This field records the type of financial support received by the students Exclude any amounts funded through DSA, Access to Learning Funds (ALF) and any fee waivers/free foundation year offered to the students Also exclude any other support to reduce student fees Include amounts awarded through NSP, where these awards are offered as bursaries/scholarships or discounted accommodation, and awards paid through charitable funds secured by institutions Should be summed and returned once (e.g. cash can only exist once for a given instance)

FINTYPE Valid Entries & Labels HESA will check ‘03’ against the values returned in TTACCOM

FinancialSupport.FINAMOUNT This field records the amount of financial support received by the students All instances at institutions in England where Instance.FEEELIG= 1 and Instance.FUNDCODE= 1 or 7 Submitted in conjunction with the associated FinancialSupport.FINTYPE, to provide amounts for each type of Financial Support Values to be returned in pounds (£) Minimum value will be 1 Warning value = £10,000, error value= £25,000 in any academic year

Instance.Mobility entity New entity designed to collect data on the mobility of students Defined as an international credit-bearing or compulsory mobility Can include things like field trips (where they are credit bearing or compulsory) However it is optional where the duration of the mobility sums to less than 4 weeks If the student undertakes study and work in the same country – these should be recorded as a single mobility with the duration lengths added together (as long as they are for the same MOBSCHEME)

Mobility.MOBTYPE Code 02 ‘Work abroad’ is used in situations where a student is doing paid work, such as an internship Code 03 ‘Volunteering’ is used in situations where a student is unpaid

Mobility.MOBDURA This field records the elapsed length in weeks of the mobility experience The expected duration of the mobility at its outset Should not be updated where the student decides to extend or curtail their mobility Number in weeks between 1 and 52 should be returned Where a single mobility consists of two types (i.e. work and study) then the duration should be added together Mobility should be split over two years in cases of non- standard years Exception is if the mobility length remaining in Y2 is less than 4 weeks, in which case the entire mobility length should be returned in Y1

Mobility.MOBSCHEME This field records the type of mobility scheme that the student is on Code 01 -‘Institutional’ includes anything organised as part of the institution’s course (i.e. placements, field work etc.) Code 02 - should be used for sandwich placement students, to identify which Mobility experience counts as their sandwich placement. This should exclude any placement that is part of an ERASMUS scheme, which should be coded 03 Code 03 - includes Erasmus Mundus, Comenius, Tempus and Erasmus for All

Mobility.MOBLOCA This field records the country location of the mobility experience This coding frame is determined by the National Statistics Country Classification 2006 (NSCC)

Impact of new Mobility entity on other fields Instance.LOCSDY Codes A, B, C, G, J, N, P, Q and X removed New codes T ‘Abroad for the whole year’, U ‘Abroad for a proportion of the year’, and Z ‘At institution or a partner for whole year’ D & E ‘On industrial placement…’ are for UK placements only Instance.EXCHANGE All outgoing EXCHANGE codes have been removed Instance.MODE Optional and compulsory year out codes 52 & 53 removed Instance.DESTOCM Field has been removed from the record

NHS changes Course.MSFUND New codes added for Wholly and Partially NHS funded Course.NHSBURSARY Field removed following changes to MSFUND and REGBODY Instance.DHFUND Code list reduced to the new Local Education and Training Boards (LETBs)

Course.REGBODY New codes added to capture GDC and HCPC specialities Code 08 'Health and Care Professions Council (HCPC): social workers in England' has been removed Code 07 has been revised to ‘Health and Care Professions Council (HCPC)' Coverage of codes 02 ‘General Dental Council (GDC)' and 07 ‘Health and Care Professions Council (HCPC)' revised to exclude England

REFData The RAEData entity will be updated to reflect the new REF 2014 Units of Assessment REFData.UOA2014 will now require letter suffix to denote the multiple submission the staff member is associated with (i.e. A, B, C or Z)

Course.TTCID The following codes have been added: The following codes have been removed: The following codes have been renamed to:

Student.ETHNIC Coverage statement has been extended to include all non-UK ITT students to bring data in line with the ITT record Code 80 'Other ethnic background' should be used when a student indicates their ethnicity as something not included in the coding frame Code 90 'Not known' can be used when a student genuinely does not know their ethnicity, for example individuals who were adopted Code 98 'Information refused' should be returned when a student has explicitly refused to provide the information. The phrase 'Prefer not to say' can be used when collecting the data HESA will monitor percentage of unknowns

Instance.EXCHANGE Codes have been revised following implementation of the new Mobility entity, to avoid duplication of data The following codes have been removed: The following codes have been added:

Instance.INITIATIVES& Instance.ITTSCHMS Instance.INITIATIVES- The following code has been added: This is applicable to ITT instances only Instance.ITTSCHMS- This field is no longer required for Wales The following codes have been removed:

Discussion: Are you ready?... How prepared are you for 2013/14? What challenges do you foresee? What processes/ systems do you have in place?

Student Record Advanced - June 2013