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)
a.
b.
c.
None of
the above
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
2
2
1
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
100.0
0.0
• 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
Misreporting STULOAD 1
• One year PGT running from October 2012 until October 2013
85.0
15.0
• 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…
Misreporting STULOAD 2
• 180 credit PGT running from January 2012 to January 2013
• All modules are assigned to the student from the outset…
100.0
0.0
• …meaning the STULOAD is recorded as 100.0 in year 1 and 0.0
in year 2 with a dormant mode
Misreporting STULOAD 2
• 180 credit PGT running from January 2012 to January 2013
• STULOAD must be split accordingly:
50.0
50.0
• HESA year 1 should include the STULOAD from completed
modules A and B and some (not all) of load from C
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 'PostSept 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 a match 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
HESA year 1
9000
HESA Year 2
9250
HESA year 1
9250
HESA Year 2
9000
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
HESA year 1
HESA year 2
GROSSFEE
9000
0
NETFEE
9000
0
• 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:
a) Return a fee based on the typical module selection
of a part-time student on the course?
b) 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 crossvalidation 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
YEARPRG
HESA year 1
0
HESA year 2
1
HESA year 3
2
HESA year 4
3
• 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 (parttime 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
Full-time
Full-time - retake
Part-time
YEARSTU
YEARPRG
YEARSTU
YEARPRG
YEARSTU
YEARPRG
1
1
1
1
1
1
2
2
2
2
2
2
3
3
3
2
3
3
4
3
4
4
5
5
6
6
• Where the two get significantly out of line this should be
investigated e.g. YEARSTU 10 but YEARPRG 2
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?
Item 2
Item 2a
Shows the qualifications awarded to
students in the format that will be
published in the student volume
Displays the year on year differences
using the qualifiers field of XQLEV501
(including the split out of PGCE and Post
grad cert in Education.
Used to check that the qualification
awarded are, in the main, those which
they were aiming for
More consistent with the SFR variance
figures
Item 2a - Qualifications obtained by students on HE course by level of qualification obtained and mode of study (2012/13 and 2011/12)
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
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.
Qualifications awarded
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.
Incorrect course data results in not being
able to link between the Student and KIS
records which impacts on aggregations.
The over-reporting also results in
funding reconciliation issues.
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. autodetection 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
New for 2013/14
Instance.INTERCALATE
Instance.ELQ
Student.CARELEAVER
Instance.FinancialSupport
entity
Instance.Mobility entity
Course.OWNCOURSEID
Changing for
2013/14
Course.MSFUND
Course.REGBODY
Instance.REFData
Removed for
2013/14
Course.NHSBURSARY
Instance.DESTOCM
EntryProfile.NEWENT
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
Valid Entry
Label
01
Care leaver (16+)
02
Looked after in Scotland
03
In care in the rest of UK
04
UCAS defined care leaver
05
Not a care leaver
98
Information refused
99
Not known
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.COURSEAIM begins with E, M, H, I, J or C
• To assist in determining whether a student is non-fundable under
the ELQ policy
Valid Entry Label
01
Non-exempt ELQ
02
Exempt ELQ
03
Not ELQ
09
Not required
• 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.COURSEAIM should be changed to record the intercalating
course aim, but Instance.NUMHUS should remain the same
01
This student is studying on an intercalated course
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
01 Cash
Any bursary/scholarship/award that is paid to the student, where
there is no restriction on the use of the award. This will include
BACS payments, cheques, cash awards and any means tested
hardship funds that fall outside of the ALF returns.
02 Near cash
This constitutes any voucher schemes or prepaid cards awarded to
students where there are defined outlets or services for which the
voucher/card can be used. (E.g. Aspire cards.)
03 Accommodation discounts
Discounted accommodation in University Halls / Residences
04 Other
This includes all in-kind support that is not included in the above
categories. This will include, but is not limited to:
•Travel costs
•Laboratory costs
•Printer credits
•Equipment paid for (e.g. laptops, course literature)
•Subsidised field trips
•Subsidised meal costs
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
01 Study Abroad
02 Work abroad
03 Volunteering
– 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 nonstandard 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
01 Institutional 02 Sandwich placement
03 ERASMUS
04 Other national scheme
• 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:
Valid Entry
Label
L
School Direct Training Programme (self-funded)
M
School Direct Training Programme (self-funded - flexible)
N
School Direct Training Programme (salaried)
P
School Direct Training Programme (salaried- flexible)
• The following codes have been removed:
Valid Entry Label
J
School led HEI provision (mainstream)
K
School led HEI provision (flexible)
• The following codes have been renamed to:
Valid Entry Label
G
School Direct Training Programme
H
School Direct Training Programme (flexible)
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:
Valid Entry
Label
Valid Entry
Label
0
Not an exchange or visiting student
G
Incoming ERASMUS student
2
Incoming TEMPUS student
N
7
Other outgoing exchange student
Not an incoming exchange or
visiting student
8
Incoming LLP ERASMUS student
9
Incoming LLP COMENIUS student
A
Incoming ERASMUS MUNDUS student
B
Outgoing TEMPUS student
C
Outgoing LLP ERASMUS student
D
Outgoing LLP COMENIUS student
E
Outgoing ERASMUS MUNDUS student
Instance.INITIATIVES & Instance.ITTSCHMS
• Instance.INITIATIVES– The following code has been added:
Valid Entry
Label
C
Troops to teachers
– This is applicable to ITT instances only
• Instance.ITTSCHMS– This field is no longer required for Wales
– The following codes have been removed:
Valid Entry
Label
1
Fast-track
3
Fast-track & previously completed a Student Associate Scheme
Discussion: Are you ready?...
• How prepared are you for 2013/14?
• What challenges do you foresee?
• What processes/ systems do you have in place?