Student record Advanced
Daniel Kidd
12 June 2012
‘The whiff of change’
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
Student information
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)
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
Qualifications on entry
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
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
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
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
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
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
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
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
New data supply table
Field Name
Description
QOE.HUSID
HESA unique student identifier
Element name in Field length
XML output
HUSID
13
QOE.UKPRN
UK Provider Reference Number
UKPRN
8
QOE.NUMHUS
Student instance identifier
NUMHUS
20
QOE.QUALGRADE
Qualification grade
QUALGRADE
11
QOE.QUALSIT
Qualification sitting
QUALSIT
1
QOE.QUALSBJ
Qualification subject
QUALSBJ
3
QOE.QUALTYPE
Qualification type
QUALTYPE
2
QOE.QUALYEAR
Qualification year
QUALYEAR
4
XQEYEAR01
Year QualificationsOnEntry last
updated
XQEYEAR01
4
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
UCAS Data for HESA Qualifications
Tim Hall
Senior Data Steward
UCAS
What Qualifications are in the *J?
What Qualifications are in the *J?
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)
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
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
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
Awarding Body Linkage
Awarding Body Linkage
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
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
Awarding Body Linkage
Applicant
Application
ABL Quals
Received
2012/13
Received
2013/14
Received
*J
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)
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
QUALENT3
QUALENT3
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
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
QUALENT3 – 2011/12
QUALENT3 – 2011/12
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
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
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
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
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
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
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
QUALENT3 – 2011/12
Examples:
Applicant 1
HIQA = Q80
HIQE = P50
Qualifications in Apply
Qualent3
9 x GCSE - achieved
Q80
1 x GCSE Short Course achieved
Q80
4 x GCE Advanced Subsidiary
- expected
P50
3 x GCE Advanced Level expected
P50
Qualifications in ABL
Qualent3
4 x GCE Advanced Subsidiary
P50
3 x GCE Advanced Level
P50
QUALENT3 = P50
Is HIQE above Lvl3? – No
HIQA = Q80
ABL = P50
Is HIQA better than ABL? – No
Provisional QUALET3 = ABL (P50)
ABL Lvl3 count = 1
Is HIQA Lvl3? – No
Final QUALENT3 Lvl3 count =1
QUALENT3 – 2011/12
Examples:
Applicant 2
Qualifications in Apply
Qualent3
6 x GCSE – achieved
Q80
4 x GCE Advanced Level –
achieved
P50
1 x SQA Higher National Dip –
expected
J30
HIQA = Q80
HIQE = J30
Is HIQE above Lvl3? – Yes
Is HIQE better than HIQA? – Yes
Qualifications in ABL
Qualent3
1 x SQA Higher National Dip
J30
QUALENT3 = J30
QUALENT3 – 2011/12
Examples:
Applicant 3
HIQA = HUK
HIQE = X06
Qualifications in Apply
Qualent3
7 x Irish Leaving Certificate achieved
X04
10 x Irish Junior Certificate achieved
X04
1 x Degree (UK Bachelor –
Honours) - achieved
HUK
Is HIQE above Lvl3? – No
HIQA = HUK
ABL = X06
Is HIQA better than ABL? – Yes
Provisional QUALET3 = HIQA (HUK)
Qualifications in ABL
Qualent3
NO ABL QUALIFICATIONS
X06
ABL Lvl3 count = 0
QUALENT3 = HUK
Is HIQA Lvl3? – No
Final QUALENT3 Lvl3 count = 0
QUALENT3 – 2011/12
Examples:
Applicant 4
HIQA = P41
HIQE = X06
Is HIQE above Lvl3? – No
Qualifications in Apply
Qualent3
4 x GCE Advanced Level –
achieved
P50
1 x OCR National Extended
Diploma - achieved
P41
HIQA = P41
ABL = P41
Is HIQA better than ABL? – No
1 x OCR National Certificate achieved
P42
Provisional QUALET3 = ABL (P41)
Qualifications in ABL
Qualent3
1 x OCR National Extended
Diploma
P41
ABL Lvl3 count = 1
Is HIQA Lvl3? – Yes
Is HIQA different to ABL? – No
Final QUALENT3 Lvl3 count = 1
QUALENT3 = P41
QUALENT3 – 2012/13
QUALENT3 – 2012/13
• 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
QUALENT3 – 2012/13
Examples:
Applicant 4
HIQA = P41
HIQE = X06
Qualifications in Apply
Qualent3
4 x GCE Advanced Level –
achieved
P50
1 x OCR National Extended
Diploma - achieved
P41
1 x OCR National Certificate achieved
P42
Is HIQE above Lvl3? – No
HIQA = P41
ABL = P41
Is HIQA better than ABL? – No
Provisional QUALET3 = ABL (P41)
Qualifications in ABL
Qualent3
1 x OCR National Extended
Diploma
P41
QUALENT3 = P91
ABL and Apply Lvl3 count = 3
QUALENT3 – 2012/13
Examples:
Applicant 1
HIQA = Q80
HIQE = P50
Qualifications in Apply
Qualent3
9 x GCSE - achieved
Q80
1 x GCSE Short Course achieved
Q80
4 x GCE Advanced Subsidiary
- expected
P50
3 x GCE Advanced Level expected
P50
Qualifications in ABL
Qualent3
4 x GCE Advanced Subsidiary
P50
3 x GCE Advanced Level
P50
QUALENT3 = P50
Is HIQE above Lvl3? – No
HIQA = Q80
ABL = P50
Is HIQA better than ABL? – No
Provisional QUALET3 = ABL (P50)
ABL and Apply Lvl3 count = 1
Changes to 2012/13 Transaction
Changes to 2012/13 Transaction
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
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)
Any Questions?
Any questions?
Tim Hall, Senior Data Steward
Data Quality and Audit Team
Contact Us: dqa@ucas.ac.uk
Defining the instance
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
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
Check documentation – Item 5
•
-
Check:
expected spread of data
very short or very long courses
Full-time versus part-time
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…
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
Check documentation change
• Item 6 has now been split into full-time and part-time
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’
Funding information
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
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
FUNDCOMP reminder!
• For 2011/12 the year which FUNDCOMP relates to for nonstandard 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’
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’
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
Check documentation change
• New MODOUT and MODSTAT table
• Important cross-referencing tool…
• …will help to quality assure FUNDCOMP derivations
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%
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
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
Check documentation change
• Item 12 ‘Average instance FTE’ will be split into two –
12ai for standard years of instance, 12aii for nonstandard
• Designed to enable institutions to better identify
STULOAD reporting errors
Postgraduate students
Instance.MODE
• Codes 73/74 capture where a student instance changes to
dormant status having previously been active on a full or parttime 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
Instance.MCDATE
• Records the date when a PG student moves from an
active mode of study to a non-active mode (writingup, 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
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
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
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
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
ITT students
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
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
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
Awarding
CLASS
• New codes record the classification of integrated taught
masters degrees…
- 12 Distinction
13 Merit
14 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
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
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
Data quality checking:
What does your HESA return say about your institution?
HESA Student Record
Advanced Seminar
Anthea Beresford
Stephenson Room, Broadway House, London
12 June 2012
HEFCE’s verification work on the
HESA 2011-12 student record
The aim of this session is to advise you:
• why we are doing this; and
• why it is so important now.
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.
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.
Key areas we will be looking at
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).
Why HEFCE and not HESA?
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.
Demands made of student data
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.
Methodology this year
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.
Engagement of the sector in the
verification process
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.
Thank you for listening
a.beresford@hefce.ac.uk
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
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
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
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)
• Derived fields are now including in the coding
manual
Using data supply
•
•
•
•
•
•
Quality assurance
Benchmarking
Trends and analysis
Internal queries
‘HESA for Planners’ seminar coming soon!
Demonstration of Data Supply…
Student Record 2012/13
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)
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
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?
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
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
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
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
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 PostSept 2012 fee regime (Instance.FEEREGIME = 20) that are not
domiciled in Scotland or the EU
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?
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
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
Student.SEXID
• This field will replace the current Student.GENDER field and
will record the biological/legal sex of the student:
- 1 Male
- 2 Female
- 3 Other
• 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
Student.GENDERID
• This field will record the gender identity of the student
• Students should, accordingly to their own selfassessment, 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?
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
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
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 resurvey or re-code continuing students. All of the
existing ethnicity codes map into the new structure
Course.AWARDBOD
• 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
Module.FRANIND
• Indicates if a module is part of a franchised or other
collaborative arrangement (in addition to PCOLAB and
TINST)
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
• 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
StudentOnModule.APEL
•
•
•
•
•
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
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
Instance.INITIATIVES
•
•
•
Valid entries of existing field to be expanded to include:
8
One Wales (W)
9
European Social Fund (W)
A NSP (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
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
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
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
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
Institution
Engineering
Theology and
Philosphy
Arts and
Law
History and
Classics
History
Life
Sciences
English and
Drama
Classics
Tier 1
Medicine
Law
Archaeology
Tier 2
Department
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
CCENTRE
DEPARTMENT
TIER2
PROPINDEPT PROPOFDEPT
Economics and
Econometrics
Business
studies
School of Business
and Finance
75
100
Economics and
Econometrics
Mathematics
School of
Engineering &
Mathematics
25
50
Student Record 2013/14
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
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
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