student post collection seminar n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Student Post-collection seminar PowerPoint Presentation
Download Presentation
Student Post-collection seminar

Loading in 2 Seconds...

play fullscreen
1 / 98

Student Post-collection seminar - PowerPoint PPT Presentation


  • 60 Views
  • Uploaded on

Student Post-collection seminar. January 2013. Review of C11051 Student record. The deadlines…Return date 15 September 2012. To put this into context. The deadlines…Commit date 24 September 2012. To put this into context. PCVS usage. PCVS impact. Minerva. Minerva. Responding to queries:

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Student Post-collection seminar' - iokina


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
minerva1
Minerva

Responding to queries:

For C11051 there were still 5%

Minerva queries with no

explanation

importance of responding to minerva queries
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
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
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…
slide12

HIFR reports

Contextual Minerva

pre collection information
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
discussion sessions
Discussion sessions
  • Local management of the data collection
  • Coding MCDATE and MODE
  • Coding ENDDATE
  • YEARSTU
  • TYPEYR
  • STULOAD
1 managing the data collection locally
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
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)
the new rules for c11051
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
The flaw…

Scenario 1: Student presumed active whole of 2010/11but 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
…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.

suggested rule amendment for c12051
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
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:
  • Exception warning to flag cases where a full-time PGR is active for 4+ years (YEARSTU)?
  • 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
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
ENDDATE in practice
  • 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.
enddate in practice 2
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.

enddate in practice 3
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.

validation change for c12051
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
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
YEARSTU & YEARPRG continued…
  • Tables 6a and 6c in the check documentation look at student cohort analysis and the tie-up between YEARSTU and YEARPRG.
5 non standard provision typeyr
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:
typeyr continued1
TYPEYR continued…
  • Coding should be applied consistently
    • How do you decide when to use codes 1 and 2 or 1, 3, 4 and 5?
6 non standard provision stuload
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
STULOAD continued
  • The table below shows real STULOAD data for the full-time non-standard instance year students for one institution.
stuload continued1
STULOAD continued…
  • The 2011/12 rules (below) will be moved to exception

In the example below would the FTE for HESA year 1 ever be 100?

stuload continued2
STULOAD continued…
  • Consider the following rules which are being considered for 2012/13 for undergraduate students to tackle under reporting:
  • Instance.STULOAD<100 where Instance.TYPEYR =1, Instance.MODE =01, Instance.COMDATE<=Y1-10-31, Instance.ENDDATE is null and Instance.NOTACT = 0
  • 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
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
coverage1
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
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
course courseaim
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
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
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
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
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
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
new cost centres
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
entryprofile qualent3
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
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
qualifications on entry1
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
‘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:
  • UCAS supplies file directly to HEFCE (no changes possible)
  • HEI supplies file directly to HEFCE (allowing for changes)
  • The file is integrated with HESA return (must verify quals with student however as no means of flagging unverified)
the advantage of the chicken
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
instance ssn
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
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
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
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
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 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
Example 1
  • Non-standard student studies on a one year course and is charged up front for a fee of £9000
example 2
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
example 3
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)
hesa slc linking
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
Examples

FAIL

NA

Instance.FEEREGIME

Instance.GROSSFEE

Instance.NETFEE

PASS

FAIL

NA

Instance.FEEREGIME (E)

SLC.FEEREGIME (NI, S, W)

SLC.GROSSFEE

SLC.NETFEE

PASS

Instance.FEEREGIME

Instance.GROSSFEE

Instance.NETFEE

PASS

NA

FAIL

equality 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
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
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
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
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
instance elq
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
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
FinancialSupport.FINTYPE
  • Records the type of financial support received by students
financialsupport finamount
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
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
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
What is a mobility?
  • Mobility.MOBTYPE
  • Mobility.MOBDURA
  • A number in weeks between 1 and 52
  • Mobility.MOBLOCA
  • A country code
  • Mobility.MOBSCHEME
changes to other fields
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
Mobility example 1

A full-time student commences study abroad (in France) – it is known that they will come to UK for 2ndyear. In the 3 year they complete their studies via distance learning in France.

mobility example 2
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 3rdyear back in UK.

mobility example 3
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.

mobility example 4
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.

mobility example 5
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

course owncourseid
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
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
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