Student Post-collection seminar
January 2013
Review of C11051 Student record
The deadlines…Return date 15 September 2012
Number of institutions
Met return
date
Extension
to return
date
Missed
deadline
To put this into context
Met return
date
C11051
C10051
133 HEIs
82%
137 HEIs
84%
The deadlines…Commit date 24 September 2012
Number of institutions
Met
commit
date
Extension
to commit
date
Missed
deadline
To put this into context
Met commit
deadline
C11051
C10051
79%
68%
PCVS usage
45
40
35
30
PCVS usage
25
20
15
10
5
0
2009/10
2010/11
2011/12
PCVS impact
Return date
Met deadline
Missed deadline
Minerva
C11051
C10051
No. Commits checked
697 (+ 13.2%)
616
Average wait for
queries
2 working days
2 working days
Maximum wait
5 working days
5 working days
Average no.
transactions checked
per HEI
4
4
Maximum no.
transactions checked
12
9
Average number of
queries raised per HEI
23 (+ 28%)
18
Minerva
Responding to queries:
For C11051 there were still 5%
Minerva queries with no
explanation

Importance of responding to Minerva queries
• Information used during collection, but also
afterwards by our Information Services unit and by
HESA’s Statutory Customers to understand the
dataset.
• New pace point for C12051 timescales currently
under discussion at HESA
Contextual information in Minerva
• At the request of the National Planners Group HESA
are formulating a ‘public’ version of Minerva
• Designed to give users of the data additional context
• HESA has published a query to Minerva to which HEIs
can add notes about their institution e.g. ‘we
recently opened a new department’
• HESA will not interact with what is added
• Will remain open throughout the year
• HESA will extract and send the information to
accompany data requests
HESA Institution Feedback Reports (HIFRs)
• We are in the process of finalising the HIFR for your
institution
• These reports are intended to be used to inform local
planning of the data collection process.
• A copy of all the reports for the 2011/12 collection
year will be sent to your HEI’s Senior Liaison contact
in early Summer.
• We would welcome your comments on these
reports…
HIFR reports Contextual Minerva
Pre-collection information
• Email sent out to all record contacts in July 2012 to
ask if there was anything we should be aware of that
could impact your submission progress
• Responses received from 15 HEIs – issues included
staff changes, software issues, mergers, the Olympics
and re-evaluation of coding
• Information found to be useful to IL to target services
• Plan to continue this approach for 2012/13
C11051 – common issues
Discussion sessions
1.
2.
3.
4.
5.
6.
Local management of the data collection
Coding MCDATE and MODE
Coding ENDDATE
YEARSTU
TYPEYR
STULOAD
1. Managing the data collection locally
• Suggested discussion topics;
–
–
–
–
–
Pre-collection preparation
Analysing the commit reports
Reviewing and responding to Minerva queries
Use of Data Supply
Use of IRIS
2. What is MCDATE?
• MCDATE records the date on which a postgraduate
instance changes from active mode to inactive mode
in the reporting period (and vice-versa)
Inactive modes
43/44 Writing up
51 Sabbatical
73/74 Changed to dormant
63/64 Dormant
Worked examples
A. In 2011/12 the student studies part time all year, in 2012/13 the student becomes dormant on 21
November 2012
Year
2011/12
2012/13
Instance.MODE
Instance.MCDATE
B. In 2011/12 the student is writing up – previously full-time, in 2012/13 the student becomes dormant on
2 March 2013.
Year
2011/12
2012/13
Instance.MODE
Instance.MCDATE
Worked examples continued…
C. A student is on a sabbatical throughout 2011/12 and then returns to full time study on 31 October
2012.
Year
2011/12
2012/13
Instance.MODE
Instance.MCDATE
D. In 2012/13 the student commences the year on a part-time basis then moves to dormant from 1
January 2013. The student then returns to part time study on 28 May 2013.
Year
2012/13
Instance.MODE
Instance.MCDATE
The new rules for C11051
• MCDATE required where an instance is dormant for
the entire reporting period (having been active at the
end of the previous reporting period)
• MCDATE must not be null where MODE 73/74 – the
date on which the instance moved to dormant
should be recorded
• Where returned, MCDATE must be earlier than
ENDDATE
The flaw…
Scenario 1: Student presumed active whole of 2010/11
but did not return 2011/12
Scenario 2: Student left 2010/11 but now needs to be
returned from dormant to give award
Issue = MCDATE not returned in 2010/11
…continued
Field guidance states:
Where a student is non-active for an entire reporting period, having
been on an active mode of study at the end of the previous reporting
period, Instance.MCDATE should be returned as Y1-08-01.
But ENDDATE was in previous reporting period (and not always
reported…)
This led to switches for 21 HEIs to pass business rule validation
Instance.MCDATE.9 .
Change proposed for 2012/13 to remove the need for MCDATE where
MODE =63/64 and ENDDATE is in the previous period.
More worked examples
Suggested rule amendment for C12051…
• For PGTs allow ENDDATE and MCDATE to be equal
where RSNEND is 01 (successful completion of
course) or 98 (Completion of course – result
unknown).
• Would this help?
• Issues when coding MCDATE?
Heads-up: Use of Writing up mode
• Writing up modes 43/44 are not being used
consistently in the sector and in some institutions no
students are being recorded as writing up.
• Consider the following:
1. Exception warning to flag cases where a full-time
PGR is active for 4+ years (YEARSTU)?
2. For institutions in England and NI,
Instance.STULOAD should be >10 where MODE=01,
Course.COURSEAIM begins with D, E, L or M and
Instance.ENDDATE is null
3. Postgraduate ENDDATE
Guidance for ENDDATE differs for PGT and PGR
PGT = For the purpose of HESA returns, completing an
instance is defined as being the point at which the taught or
structured part of the instance, including any formal
writing-up period, is completed, i.e. once the student is no
longer actively following the course.
PGR = The award should be recorded when the institution's
Senate, or other body or person empowered, formally
approves the award. For such students this field should be
completed with the same date.
ENDDATE in practice
1. MA in Classics commences 23 September 2012,
students must hand in their masters dissertation by
10 October 2013. The dissertations are then marked
by tutors with results confirmed by 5 December
2013.
Instance.COMDATE
Instance.ENDDATE
20120923
20131205
Instance.COMDATE
Instance.ENDDATE
20120923
20131010
ENDDATE in practice - 2
An Arabic studies PhD student commences their course
on 2 May 2008, they complete and hand in their thesis
on 28 November 2012, the thesis then passes the viva
and the award is conferred by the institution on 9 May
2013.
Instance.COMDATE
Instance.ENDDATE
20080502
20121128
Instance.COMDATE
Instance.ENDDATE
20080502
20130509
ENDDATE in practice - 3
An MSc in Astronomy commences 5 October 2012, the
student withdraws for personal reasons sometime in
June 2013, the student does not return to complete
their course or hand in their dissertation in autumn
2013.
Instance.COMDATE
Instance.ENDDATE
Instance.MCDATE
Validation change for C12051
It is planned to add in a new exception rule where
QualificationAwarded.QUAL has been returned as H00,
H11, H16, H22, H23, H50, M00, M01, M10, M11, M16,
M22, M50, M71, M86, E00 or D00
This should prevent ended instances from being
inadvertently missed out of the DLHE population where
ENDDATE has not been completed.
Do you envisage any issues with this new rule?
4. YEARSTU & YEARPRG
• Analysis of the raw data suggests that within HEIs there are
some unusual approaches to coding these fields such as:
YEARSTU=1, YEARPRG=10
This particular scenario seems unlikely, but there are potential
explanations for a discord between the two fields
• Part-time students are often coded incorrectly and it is
important to make sure that YEARPRG is amended to reflect
that the course is taken over a longer period of time.
• YEARPRG is used for the NSS population so it is important to
make sure the coding is correct
YEARSTU & YEARPRG continued…
• Tables 6a and 6c in the check documentation look at
student cohort analysis and the tie-up between
YEARSTU and YEARPRG.
Item 6a - Student cohort analysis - Full-time and
Sandwich
(Derived from fields Instance.YEARSTU, Instance.YEARPRG, Instance.COMDATE, Instance.MODE)
Year of
Student
1
2
3
4
5
0
153
2
0
0
0
1
6,126
187
4
1
0
Year of Course
2
3
16
0
3794
18
111
3576
3
140
1
3
4
0
0
5
643
6
5
0
0
0
0
0
5. Non-standard provision - TYPEYR
• TYPEYR can be a tricky concept and we often see
TYPEYR being coded/changed incorrectly.
• How should TYPEYR be coded in the following cases:
October Y1
May Y2
Year one
Year two
HESA year 1
HESA ye
HESA year 2
TYPEYR continued…
Student suspends studies in December
Year one
HESA year 2
TYPEYR continued…
• Coding should be applied consistently
– How do you decide when to use codes 1 and 2 or 1, 3, 4
and 5?
1
Course academic year contained within the HESA reporting year 1 August - 31 July
2
Course academic year not contained within the HESA reporting year 1 August - 31 July
3
Student commencing a course running across HESA reporting years
4
Student mid-way through a course running across HESA reporting years
5
Student finishing a course running across HESA reporting years
6. Non-standard provision: STULOAD
• Apportioning STULOAD for non-standard years still
appears to be a problem.
• For institutions in England, Wales and Northern
Ireland FTE must not be front-loaded but should be
apportioned between years based on activity
undertaken…
STULOAD continued
• The table below shows real STULOAD data for the full-time non-standard
instance year students for one institution.
STULOAD continued…
• The 2011/12 rules (below) will be moved to exception
Instance.STULOAD.BusinessRule.12 (warning)
For institutions in England, Northern Ireland and Wales, Instance.STULOAD should be less than 100
where Instance.TYPEYR is not equal to 1 and Instance.COMDATE > Y1-07-31.
Instance.STULOAD.BusinessRule.13 (warning)
For institutions in England, Northern Ireland and Wales, Instance.STULOAD should be less than 100
where Instance.TYPEYR is not equal to 1 and Instance.ENDDATE > Y1-07-31.
In the example below would the FTE for HESA year 1
ever be 100?
STULOAD continued…
• Consider the following rules which are being considered for
2012/13 for undergraduate students to tackle under
reporting:
1. Instance.STULOAD<100 where Instance.TYPEYR =1,
Instance.MODE =01, Instance.COMDATE<=Y1-10-31,
Instance.ENDDATE is null and Instance.NOTACT = 0
2. Instance.STULOAD<50 where Instance.MODE =01,
Instance.COMDATE is between Y1-11-01 and Y2-01-31,
Instance.ENDDATE is null and Instance.NOTACT=0
• Would these work for your institution and the way STULOAD
is calculated?
The HESA website
• We are currently reviewing the coding manual and
additional support sections of our website
• Your views are sought on the usability of these pages
• If you have any specific comments you would like to
share please email liaison@hesa.ac.uk
Student Record 2012/13
Coverage
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
• A count in check documentation will be provided
Instance.REDUCEDI
• Type 08 can only be used for UG students
- 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
• Type 09 (Unistats only) cannot be used
Courses
Course.COURSEAIM
• Two new valid entries for 2012/13:
- M44 ‘Certificate at level M’
- H62 ‘Pre-regisation graduate diploma leading
towards elibility to register’
• Students on H62 will have a FUNDLEV of 20 or 21
(i.e. PGT)
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
• Required for all UK institutions where Course.COURSEAIM begins D, E,
L, M, H, I, J or C and Course.COURSEAIM does not end with ‘99’ and
Course.REDUCEDC = 00, 01, 03 or 04
• 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
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
Course.TTCID
•
•
-
Records the type of teacher training for the course
New codes introduced for 2012/13:
G School Direct initiative (mainstream)
H School Direct initiative (flexible)
J School-led HEI provision (mainstream)
K School-led HEI provision (flexible)
JACS version 3
• 284 new JACS codes!
• 45 discontinued codes
• A review (particularly of discontinued codes) should
be undertaken with a view to recoding
• A mapping document is available from:
http://www.hesa.ac.uk/content/view/1806/281/
EntryProfile.PGCESBJ
• Field records the subject of the first degree of PGCE
students
• New students must have their first degree subject
coded using JACS3
• Where Entry Profile for continuing students is not
sent in, HESA will map from JACS2 to JACS3 for the
purposes of HIN
• Where Entry Profile for continuing students is sent
in, then JACS3 code must be used. HESA will also flag
up warnings where HEI mapping differs to our
expectations
Course Subject
Module Subject
All codes
2012/13
New JACS3
codes used (for
added
granularity)
2012/13
All codes
2011/12
JACS2 Codes which
could be redefined
2011/12
All codes
2012/13
New JACS3
codes used (for
added
granularity)
2012/13
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
D - Veterinary science, Agriculture &
related subjects
0
0
0
0
0
0
0
0
F - Physical sciences
0
0
0
0
0
0
0
0
G - Mathematical sciences
0
0
0
0
0
0
0
0
H - Engineering
0
0
0
0
0
0
0
0
J - Technologies
0
0
0
0
0
0
0
0
K - Architecture, building & planning
0
0
0
0
0
0
0
0
L - Social studies
0
0
0
0
0
0
0
0
M - Law
0
0
0
0
0
0
0
0
N - Business & administrative studies
0
0
0
0
0
0
0
0
Q - Linguistics, Classics & related
subjects
0
0
0
0
0
0
0
0
R - European Languages, Literature &
related subjects
0
0
0
0
0
0
0
0
T - Eastern, Asiatic, African, American &
Australasian Languages, Literature &
related subjects
0
0
0
0
0
0
0
0
V - Historical & philosophical studies
0
0
0
0
0
0
0
0
W - Creative arts & design
0
0
0
0
0
0
0
0
All codes
2011/12
JACS2 Codes which
could be redefined
2011/12
B - Subjects allied to medicine
0
C - Biological sciences
New cost centres
• Remember that data must be mapped to the new
cost centres for 2012/13
• Validation likely for HEIs in England to ensure that
cost centres used within the Student record have
been identified and mapped to departments within
the Institution Profile return
Qualifications on entry
EntryProfile.QUALENT3
• 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
• New rule ensuring that at least one A-Level exists in QOE
where QUALENT3=P50… however…
QUALENT3 guidance
• No hierarchy is implied in level 3 qualifications. If a mixture of
qualifications are relevant, then use code P92, P93 or P94 rather
than any single qualification included, such as A/AS level
• Code ‘P92 Level 3 qualifications of which none are subject to
UCAS Tariff’ relates to the type of qualification. This code should
not be used in cases where the student holds non-tariff bearing
grades for a tariff-bearing qualification. In these circumstances
the appropriate P code for the level 3 qualification or P93/P94
should be used in EntryProfile.QUALENT3
• Use of P80 ‘Other qualification at level 3’ should be limited (new
exception validation for home students likely) as it is preferred
that P9* codes are used instead…
• …beware that UCAS currently use P80 in *J
QUALENT3 examples
2011/12 entrant
2012/13 entrant
Quals on entry
required?
3 A-levels
P50
P50
YES
1 A-level and 1 certificate (nontariff)
P91
P94
YES
1 A-level and 1 diploma (level 3)
P91
P93
YES
1 diploma (level 3)
P41
P41
YES
Key skills (non-tariff)
P92
P92
NO
A-level and HNC
C30
C30
Ideally
Music Theory Level 6
P80
P80
YES
Entry qualifications
Qualifications on entry
• 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
‘Son of *J’
• For 2012/13 HEIs will be supplied by UCAS a text file
containing unverified qualifications (not otherwise
supplied through ABL) supplied by accepted applicants
within UCAS Apply system
• Only included in file where a type and grade can be
established
• Data ready by end of January 2013
• HEI has three options to return the data:
a) UCAS supplies file directly to HEFCE (no changes possible)
b) HEI supplies file directly to HEFCE (allowing for changes)
c) The file is integrated with HESA return (must verify quals
with student however as no means of flagging unverified)
The chicken or the egg
The advantage of the chicken
• Where the data is provided directly to HEFCE it will be ring-fenced
for student number control purposes…
• …therefore HEIs should be aware that it will not feature for
benchmarking or derived statistics purposes
• e.g. University A returns the contents of the file to HESA, their
XTARIFF will take the additional qualifications into account.
University B returns the data directly to HEFCE and therefore they
potentially suffer a lower XTARIFF value
• Consider also the relationship between QUALENT3 and incomplete
Qualifications on Entry data – particularly in relation to validation i.e.
exception rule 9 ‘Where more than 10% of students have a tariffable
highest qualification but there are no Qualifications on Entry data
• Validation rules such as ensuring A-Level exists in QOE where
QUALENT3= P50 is also reliant on data being returned via HESA
Fee data
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 same SSN must not be used for more than one
Student.HUSID (error)… though it can be used for more than
one instance within the same HUSID (warning to check)
• SSN must not exist for particular COURSAIMs (i.e. majority of
PGR, PGT and FE)
• For HEIs in E, NI, W, SSN must not exist where FEEELIG = 2 or 3
(not eligible to pay home fees)
• Exception error: More than 20% of FT UG instances that are
eligible to pay home fees do not have an SSN returned
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)
• Separate coverage statements for each devolved
administration…
• …not required for incoming exchange students
• Not required for dormant instances (although not positively
excluded)…
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 in the
reporting year within which the year of instance commences
• Where the fee for the course is charged up front the
institution should divide this over the number of the years of
the course
• Validation will prevent GROSSFEE being returned where SSN
exists and can be matched to SLC data
• For institutions in England, GROSSFEE must be less than or
equal to 50% of the OFFA agreed amount (where SPECFEE
indicates sandwich, language year or final year of course
lasting less than 15 weeks)
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 in the
reporting year within which the year of instance commences
• 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
Exception Validation
• Exception errors will be in place that will compare
GROSSFEE with the maximum fee by broad
COURSEAIM as set out in your OFFA agreements
• First degree, Foundation degree, HNC/HND, PG ITT,
CERTHE/DIPHE
• Where a fee for a COURSEAIM has not been
stipulated in OFFA agreement the validation will
expect a fee of £6000 or less…
• …this may be the result of incomplete/incorrect
OFFA agreements or incorrect Student record coding
Example 1
• Non-standard student studies on a one year course
and is charged up front for a fee of £9000
Fee information
HESA year one
HESA year two
£9000
0
Example 2
• Standard student is charged £9000 fee a year which
is divided and charged at the beginning of each
semester. The student leaves before the 2nd semester
HESA year one
Fee information
£9000
Example 3
• A non-standard student undertakes a two year
course for which they are charged the entire fees
(£12,000) up front. The student is then charged an
additional fee for writing-up (£200)
Fee information
HESA year one
HESA year two
HESA year three
£6000
£6000
£200
HESA/SLC linking
• Where possible HESA will use SLC data to populate
the FEEREGIME, GROSSFEE and NETFEE fields
• HESA will receive a file containing the relevant
information (i.e. SSN, gender, date of birth, fee fields)
from SLC in June
• The additional processing will take place at COMMIT
stage
• Difficulties exist around franchised students
• Full system only – review data in Data Supply
Examples
SSN returned?
GROSSFEE/NETFEE
returned?
FEEREGIME
returned?
Outcome
Data used
Known value
YES
YES
FAIL
NA
Unknown value
YES
YES
PASS
Instance.FEEREGIME
Instance.GROSSFEE
Instance.NETFEE
Unknown value
NO
NO
FAIL
NA
Known value
NO
YES
PASS
Instance.FEEREGIME (E)
SLC.FEEREGIME (NI, S, W)
SLC.GROSSFEE
SLC.NETFEE
No value
YES
YES
PASS
Instance.FEEREGIME
Instance.GROSSFEE
Instance.NETFEE
No value
NO
NO
FAIL
NA
Student and Instance data
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.ETHNIC changed so that 13 ‘White - Scottish’ is available
only to HEIs in Scotland – code 10 not available to Scottish HEIs…
Instance.INITIATIVES
•
•
Valid entries of existing field to be expanded to include:
7
Universities Heads of the Valleys Institute (W)
8
One Wales Scheme – foundation degree (W)
9
European Social Fund (W)
A
NSP (for those receiving support) (E)
B
Access to HE Diploma marker (E)
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.INITIATIVES should continue to identify the scheme
• All other HEFCE codes (e.g. Lifelong Learning) except for A & B have been
removed for 2012/13
• Use of code B will remain the method for identifying ABB+ equivalents
with an Access to HE Diploma…
• …and HEIs should ensure that continuing students retain code B
Instance.INITIATIVES = A
• Poppleton University are given NSP support for 300
students but it is subsumed into general HEI support
and distributed to 2000 students
• Is this a common issue?
• In such circumstances you should code up all 2000
students as being in receipt of NSP
Instance.YEARPRG
• Indicates the year number of the course that the
student is currently studying
• Known issue with regards to coding of foundation
years…
• …therefore new validation error preventing YEARPRG
from being 0 where the course length is one year or
less
• Implemented to reinforce that integrated foundation
years must be part of a longer course
• 901 instances would have failed this rule in C11051
Instance.ENDDATE
• New exception validation to warn where specified
awards (namely first degrees, masters etc) have been
made without an end date
• Introduced as it is not expected that such awards would
be made without an end date as they are not typically
‘interim awards’ and will improve POPDLHE accuracy
• Will be an error for C13051
• 3555 instances in C11051 would have triggered the
warning
• There will be a number of intercalated instances that are
flagged in C12051, however this issue will not persist
when upgraded to an error as we will have an
‘intercalated’ flag in 2013/14
Preparations and challenges discussion?
Student record 2013/14
Instance.ELQ
• Captures whether a student is aiming for an Equivalent
or Lower Qualification:
- 01 Non-exempt ELQ
- 02 Exempt ELQ
- 03 Not ELQ
- 04 Unknown
- 09 Not required
• Needs to be completed for all students. Unknowns may
be acceptable for students who are non-fundable for
other reasons e.g. ITT and INSET students holding QTS
Student.CARELEAVER
• Records whether a student is a care leaver to allow OFFA
to calculate population of WP students
-
01 Care Leaver (16+)
02 UCAS defined care leaver
03 Not a care leaver
04 Not known
05 Information refused
• When submitting a code for any student in the first two
categories, it is reasonable to expect that a student could
fall into both of these. In this case category 01 takes
priority over category 02
FinancialSupport.FINTYPE
• Records the type of financial support received by
students
01 Cash
02 Near Cash
03 Accommodation
discounts
04 Other
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
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.
Discounted accommodation in University Halls / Residences
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
FinancialSupport.FINAMOUNT
• Records the amount of financial support received by
students…
• …rounded to the nearest £50
• Between 1 and 999999
• Should be submitted in conjunction with the
associated FINTYPE to provide amounts of each type
Instance.INTERCALATE
• A new field will be added on the instance entity to
flag intercalating students (including Master and PhD
degrees), on the years they are intercalating
• This will enable more accurate reporting and
validation of data
• Flag suggested through the consultation
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 is less than 4 weeks (even where multiple
mobility add up to greater 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
What is a mobility?
• Mobility.MOBTYPE
01 Study abroad
02 Work abroad
03 Study & work
04 Volunteering
• Mobility.MOBDURA
- A number in weeks between 1 and 52
• Mobility.MOBLOCA
-
A country code
• Mobility.MOBSCHEME
01 Institutional
02 ERASMUS
03 Other national scheme
Changes to 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 ‘On industrial placement…’ are for UK placements only
• Instance.EXCHANGE
- All outgoing EXCHANGE codes have been removed as this is now
captured within mobility entity
• Instance.MODE
- FE-specific mode codes have been removed
• DESTOCM
- Field has been removed from the record
Mobility example 1
A full-time student commences study abroad (in France) – it is known that they will
come to UK for 2nd year. In the 3 year they complete their studies via distance learning
in France.
LOCSDY
EXCHANGE
MODE
STULOAD
Mobility
Year 1
S
N
01
0
No
Year 2
Z
N
01
100
No
Year 3
S
N
01
0
No
Mobility example 2
A full-time student commences study in UK – it is not known from outset whether
they will have a year abroad – they end up studying (on an ERASMUS scheme for 38
weeks) in France and working the remaining time in the same country during their 2nd
year before finishing their 3rd year back in UK.
LOCSDY
EXCHANGE
MODE
STULOAD
Mobility
Year 1
Z
N
01
100
No
Year 2
T
N
01
100
Yes
Year 3
Z
N
01
100
No
Year 2
MOBTYPE
MOBDURA
MOBLOCA
MOBSCHEME
03
52
FR
02
Mobility example 3
A student commences study on a 3 year collaborative programme where it is initially
thought that the student will spend year 1 and the majority of the course time in UK.
In year 2 however the student elects to study abroad for the 2nd and 3rd year.
LOCSDY
EXCHANGE
MODE
STULOAD
Mobility
Year 1
Z
Y
01
100
No
Year 2
T
Z
01
100
Yes
Year 3
T
Z
01
100
No
MOBTYPE
MOBDURA
MOBLOCA
MOBSCHEME
Year 2
01
52
FR
01
Year 3
01
52
FR
01
Mobility example 4
A full-time student is on a three year course (starting in UK). In their 2nd year they take
3 different outgoing exchange programmes – in Spain (ERASMUS), France and
Germany – but finish the year in the UK.
LOCSDY
EXCHANGE
MODE
STULOAD
Mobility
Year 1
Z
N
01
100
No
Year 2
U
N
01
100
Yes
Year 3
Z
N
01
100
Yes
MOBTYPE
MOBDURA
MOBLOCA
MOBSCHEME
Year 2
01
3
ES
02
Year 2
01
7
FR
01
Year 2
01
8
DE
01
Mobility example 5
A sandwich student commences study in the UK – they undertake a work placement
abroad in their 3rd year of the course, before returning to complete their course in the
UK. However they are required to go into a 5th year to write up and do so abroad
LOCSDY
EXCHANGE
MODE
STULOAD
Mobility
Year 1
Z
N
23
100
No
Year 2
Z
N
23
100
No
Year 3
T
N
23
100
Yes
Year 4
Z
N
23
100
No
Year 5
S
N
43
10
No
MOBTYPE
MOBDURA
MOBLOCA
MOBSCHEME
02
08
FR
01
Year 3
Course.OWNCOURSEID
• Requested by HEIs…
• …a field on the Course entity for Institutions to use
for their own internal identifier for the course
• Free text field
Things that didn’t make it
• The QUALSTAT field
• Entrepreneurship flag on modules for Welsh HEIs
• Requirement for Welsh HEIs to report fee
information for PT students
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