Skip to main content

Student 2019/20 (Data Futures) specification consultation

Addition: ID 30108 for feedback and review

During the Student 2019/20 specification consultation we were unable to release one item as discussions with statutory customers regarding the implementation options were ongoing. 

However, we are now able to release for review and feedback ID 30108: Expansion of Religion.RELIGION coding frame (England and Wales).

As with previous consultation items, you will need to complete a burden assessment and input those scores into an online survey.

The deadline for responses is 23:59 13 December. Please work with colleagues as needed, as we would request that only one response is given per provider.

ID 30108: Expansion of Religion.RELIGION coding frame (England and Wales) (closing date Thursday 13 December)

Description of requirement

In order to support the DfE (NI)’s requirement for national level data to meet their statutory duties in relation to equal opportunities monitoring it is proposed that the coding frame for Religion.RELIGION is opened up to allow providers in England and Wales to return the appropriate values for students domiciled in Northern Ireland.

Justification

DfE (NI) has a requirement under Section 75 of the Northern Ireland Act 1998 to monitor and promote equality of opportunity in relation to services provided to customers regardless of whether their religious background is Catholic, Protestant and Other Christian, Other religion or No religion.

As approximately ‘one third’ of all NI domiciled university students leave NI to enter full time study in GB each year, the absence of this information is a major gap in the data DfE(NI) require for their duties in relation to equality monitoring and widening participation.

Proposed implementation

‘Christian – Roman Catholic’, ‘Christian – Protestant’ and ‘Christian – Other denomination’ will be made available by providers in England and Wales for students whose permanent home address is in Northern Ireland. The feasibility of a number of options for implementing this are being considered.

Key information

A derived field may be introduced to aggregate back up to the equivalent level of granularity in the 2018/19 Student and AP student coding frames.

Validation may be introduced to ensure that for providers in England and Wales the additional codes are only used for those students domiciled in Northern Ireland.

 

Proposed implementation

Detailed information on the proposed changes to this field can be found in the PDF available below - please note that this is a draft document.

Open ID 30108: Expansion of Religion.Religion coding frame (England and Wales) (draft)

 

Your response

You will need to complete a separate burden assessment (available as a PDF, below) for each proposed change - this will provide a number that you then enter into the survey.

Open Burden Assessment Guide

There is an individual survey for each proposed change: each survey has a 'complete later' option. Please note, you will need to copy the URL provided if you select the 'complete later' option. Closing date for survey: 13 December 2018.

ID 30108: complete survey

 

ID 60757: Recording FTE (England, Northern Ireland, Wales) feedback and outcomes

Description of requirement

HESA’s Statutory Customers have a requirement to collect FTE data from all students at providers in England, Northern Ireland and Wales. SFC are content with the level of data currently specified in the model from providers in Scotland. This is fundamental in their funding allocations, metrics and for regulatory purposes.

Justification To enable the Office for Students (OfS), HEFCW and DfE(NI) to understand the interaction between a student and their provider. This is an important factor relating to funding, used in metrics and in regulatory outcomes.
Proposed implementation

We proposed to add a repeating entity off the Student Course Session, to allow FTE to be returned with a value for each reference period.
The current StudentCourseSession.STULOAD field is not returned until the end of the year, and this does not give enough information soon enough. The StudentCourseSession.STULOAD field would then become a derived field for providers in England, Northern Ireland and Wales, using this new entity. However, the field would remain for providers in Scotland to return.
Although HESA and Statutory Customers could estimate FTE values during each reference period, it was felt that providers would prefer control over this, so that it more accurately reflected what was happening.

Key information This information would be required for students at providers in England, Northern Ireland and Wales. It would be required for all active students.

Consultation feedback

Respondents were asked to provide an assessment of the ‘burden’ associated with this requirement. We received 38 responses. A summary of the responses can be found below. The chart shows the mean review score.

One of the key findings from the burden assessment is that providers did not anticipate the burden of this requirement reducing significantly over subsequent years. Although the upfront cost was typically considered to be high, in general the ongoing ‘run’ cost was less than 1 point lower on the scale than the initial set up cost.

Conversely the HESA assessment of burden, whilst assessing the set up costs as high saw an anticipated decrease in overhead to run in subsequent years for specific lenses:

The chart above reflects the responses of a small group of HESA staff and the high set up costs are reflective of the pervasiveness of FTE through quality assurance processes and collection outputs and a concern that differences in reporting FTE both within and across devolved administrations will create an overhead and complexity in analysis both during and post collection.

The feedback provided in response to this consultation item was very detailed and there were several key themes in the qualitative responses. It was widely recognised that FTE reporting is already one of the more complex aspects of the record, and that there is no single implementation approach that would both satisfy the needs of Statutory Customers and be easily managed and maintained by providers and one respondent summarised that the proposal was ‘no more difficult than any other alternative’.

Several providers did put forward alternative methods, such as providing an estimated/forecasted FTE for the student course session in each reference period. There were also calls for opportunities to work collaboratively with HESA and regulators to identify the optimum solution as this would allow detailed examples to be worked through to develop comprehensive guidance for providers and thus hopefully facilitating consistent approaches to reporting.

A number of respondents highlighted that FTE is not used internally and that providers would therefore not see any tangible benefits from introducing this proposal.

A few of the respondents to the survey highlighted the apparent difference to how the data is returned in HESES: “The continuation of HESES also means we will be asked by OfS to continue to estimate year end FTE for PT students while amending how we calculate FTE for those same students in reference period 1”.
 
Additionally several noted that this approach diverged from the principles of continuous collection and could be considered a retrograde step, reintroducing artificial collection periods.

Consultation outcome

Although the feedback to this consultation item presented a mixed picture, the requirement for this data remains. There are currently three proposed methods to record FTE:

  • Providers in England and Wales return FTE as per the consultation proposal.
  • Providers in Northern Ireland return a predicted FTE against the Student course session and then a final figure in the current STULOAD field.
  • Providers in Scotland should continue as before and only return STULOAD at the end of the Student course session.

HESA will work closely with Statutory Customers and the sector to develop the most appropriate solution to recording FTE and will issue further guidance to assist in the return of this data. We will work through this and get more information to providers in the coming weeks.

ID 60757: Recording FTE (England, Northern Ireland, Wales) revised specification

ID 51433 Locations information feedback and outcomes

Description of requirement

Statutory Customers have requested a split of the information currently held in the session location field. Paired with proposal ID 63420 this helps identify exactly where a student is located.

Justification

The current use of a UKPRN does not explicitly give a geographical location at which delivery is taking place and so is not fit for purpose. This geographical location is required for a number of purposes including:

  • Funding allocations for delivery in London are based on whether the delivery takes place in London rather than whether the delivery organisation is based in London
  • Teaching Excellence Framework (TEF) metrics take into account ‘local’ students: students being taught at a provider close to where they’re from
  • Regional profiles need to identify cold spots for certain subject areas and monitor student migration by subject area

In each case a UKPRN for the delivery organisation is not sufficient and a postcode is required.

We also need to understand more clearly when students are not expected to be at the provider for that course session, as currently there are potentially overlapping values within the session location field. 

Proposed

implementation

It was proposed to add a few fields to collect whether or not a student is doing a placement, studying abroad during the year, or distance learning in order to allow a mix of the different activities. This also avoids the issues with the current field, where the values aren't necessarily mutually exclusive.

This completes the picture of whether or not the student is physically at the provider. The Off Venue Activity entity would then collect the location of where those students are.

Key information

This requirement is for all providers, as the TEF metrics are calculated by the Office for Students on behalf of the UK.

HEFCW will use this information in determining location of provision, for example, for fee and access plan monitoring, for analysis of Welsh medium provision and monitoring provision available in areas of deprivation.  

Consultation feedback

Respondents were asked to provide an assessment of the ‘burden’ associated with this requirement. We received 35 responses. A summary of the responses can be found below. The chart shows the mean review score.

ID 51433 sector burden assessment

In general respondents understood and accepted the rationale for the requirement although there were requests for this to be expanded upon for clarity. There was some support for the proposal and some providers welcomed this as a simplification in reporting and a solution that could over time lead to improvements in data quality.

The HESA assessment of burden is shown below.

 

In general HESA were supportive of this change and saw it as relatively low although not insignificant cost to set up which would then be expected to be stable in subsequent years.

There were questions around the implementation approach proposed with a number of respondents suggesting that the burden would be less if this were implemented differently. The accompanying free text responses indicated that this proposal has been interpreted in different ways and this may be why the responses were polarised with roughly half strongly in favour and half against. We will be publishing more guidance to accompany this change to clarify the proposal.

Consultation outcome

Based on feedback, the CourseSession.SESSIONLOCATION field will be removed, splitting out the details in that field into multiple fields on the Course Session entity as shown in the following PDF:

ID 51433: Locations information revised specification

 

ID 56444 Proposal to declare MODE at Student level, not course delivery level feedback and outcomes

Description of requirement

Statutory Customers have a requirement to identify at a student level, what Mode of study a student is studying at.

Justification Supplying Mode at a Course Delivery level does not accurately record what every student is doing. 
Proposed implementation

It was proposed to amend the Session Status entity and add a new Mode entity for every student course session (and not by exception as is currently the guidance). This also allows providers to record any changes when they happen. 

Key information Coverage of the entity would include all students at all providers in the UK.
 

Consultation feedback

Respondents were asked to provide an assessment of the ‘burden’ associated with this requirement. We received 35 responses. A summary of the responses can be found below. The chart shows the mean review score.

ID 56444 sector burden assessment

 

The feedback received for this consultation item was very mixed and although the vast majority indicated that the change doesn’t represent a significant increase (or decrease) in burden, the respondents were split as to whether or not they supported the change.

For some it was felt that collecting mode of study at student level is more appropriate and more closely aligned with existing practice and internal systems however for others the reverse position was argued and it was stated that the mode is an attribute of a programme and not an individual.

Several respondents argued in favour of inheriting mode from course delivery and only reporting it at student level where it differs from the associated course delivery to avoid duplication. In the responses a number suggested that this would essentially be the practice adopted internally anyway.

A subset of HESA staff undertook a burden assessment from a HESA perspective and the results are included below:

ID 56444 HESA burden assessment

The HESA scores are markedly different to those of the sector and this is largely due to the pervasiveness of mode throughout quality assurance and enrichment process. A change to how mode is captured would create significant additional work for HESA up front to revisit populations, quality rules and reports specified to date. After initial implementation it would be expected that the maintenance overhead would reduce significantly however the centrality of mode is likely to mean that this requires some regular review.

Consultation outcome

The specification will be updated in accordance with the original proposal however there will be an additional mode of study of '03 - Accelerated full-time’ added for providers in England as per consultation item 54847.

ID 56444: Proposal to declare MODE at Student level, not course delivery level revised specification

ID 57596 and 63208: Amend Reason for ending, valid entries feedback and outcomes

Description of requirement

Statutory Customers have made us aware that they no longer consider it meaningful to use the granularity of data that the Reason for ending field collects. This is because many of the codes in the current draft are not mutually exclusive when a student leaves a course without gaining a qualification or credit. Reasons are often complicated, not just down to one factor and not always easy to specify when returning this data. It was felt that it might be better to combine some of the categories.

Justification

The data is not able to be used at the level of granularity it is collected.

Proposed implementation It was proposed we revise the list of Reason for ending valid entries.
Key information The coverage of the field would remain the same, this would only change the valid entries and labels.

Consultation feedback

Respondents were asked to provide an assessment of the ‘burden’ associated with this requirement. We received 36 responses. A summary of the responses can be found below – note that this excludes responses supplied in error and those where the respondent confirmed that they were not affected by the requirement. The chart shows the mean review score.

ID 57596 and 63208 sector burden assessment

 

Providers were generally supportive of the drive to reduce the number of valid entries in the field; however, several respondents indicated that the larger list may be retained for internal use.

In addition to providing more general feedback on the request, providers were asked to respond to two specific questions:

ID 57596 and 63208 sector responses

The responses in regard to the proposal to derive RSNSCSEND were mixed, with many tentatively offering support for derivation, but outlining reservations about specific cases such as part-time students and those on flexible study programmes.

HESA also undertook a burden assessment, looking at the change from a HESA rather than provider perspective and the results are included below:

ID 57596 and 63208 HESA burden assessment

Within the team at HESA that contributed to this assessment there were mixed opinions in relation to the potential to derive StudentCourseSession.RSNSCSEND and the reasons for this uncertainty were largely aligned to those raised by providers. The preference from the HESA team was to continue to investigate the potential to derive this data where possible but not to rely on this as the only mechanism to collect this data in the first year of implementation.

Consultation outcome

The valid entries for the Leaver.RSNREGEND and StudentCourseSession.RSNSCSEND fields will be reduced as per the proposal. The StudentCourseSession.RNSCSEND will not be derived; however, HESA will continue to investigate the potential to derive this in the future.

ID 57596 and 63208: Amend Reason for ending, valid entries revised specification

ID 63420: Postcode data feedback and outcomes

Description of requirement

The Office for Students has requested that a postcode be collected for delivery venues, including those of franchise partners, as they need to be able to identify where a student is taught.

Justification

The current use of a UKPRN does not explicitly give a geographical location at which delivery is taking place and so is not fit for purpose. This geographical location is required for a number of purposes including:

  • Funding allocations for delivery in London are based on whether the delivery takes place in London rather than whether the delivery organisation is based in London
  • Teaching Excellence Framework (TEF) metrics take into account ‘local’ students: students being taught at a provider close to where they’re from
  • Regional profiles need to identify cold spots for certain subject areas and monitor student migration by subject area

In each case a UKPRN for the delivery organisation is not sufficient and a postcode is required.

Proposed implementation To add a Postcode field on the Venue entity, to collect the specific geographical location where a Module is being delivered for each student. A proportion field would also need to be added to the Module Delivery Role entity, to ensure the details for franchise arrangements were captured.
Key information

This requirement is for all providers, as the TEF metrics are calculated by the Office for Students on behalf of the UK. This will also be beneficial for HEFCW when understanding franchise arrangements.

HEFCW will use this information in determining location of provision, for example, for fee and access plan monitoring, for analysis of Welsh medium provision and monitoring provision available in areas of deprivation. 

Consultation feedback

Respondents were asked to provide an assessment of the ‘burden’ associated with this requirement. We received 32 responses. A summary of the responses can be found below. The chart shows the mean review score.

In general the responses were fairly neutral in relation to the requirement to capture postcode data however it was generally acknowledged that postcode data is time consuming to quality assure both at the point of capture and return.

The burden assessment completed by a subset of HESA staff picked up on similar issues to providers regarding the quality assurance of postcode data however from a HESA perspective we anticipate a decrease in the effort associated with the management of the rules set and other quality assurance collateral relating to postcodes after the first year of implementation.

Some providers stated that they already capture this data for use internally however several respondents queried how what the requirements would be for different types of students/provision for example distance learning, medical placements and cases where activity is undertaken at multiple locations. We will be reviewing the guidance and will undertake to address all of these questions as soon as possible in the coding manual.

The justification for the data was largely accepted in principle however some did state that they consider this to be a disproportionate solution and would welcome further detail regarding the requirement and why a full rather than outward only postcode is required. We will work to a more detailed justification as soon as possible.

Many of the respondents referred directly to the requirement for the Module Delivery Location Proportion (MDLPROPORTION) field and indicated that this may be more burdensome that the requirement for postcode as this data is not routinely collected and therefore would require not only changes to systems but to business processes, often requiring involvement from delivery partners external to the provider. It was felt that this was likely to be a time consuming and manual process which would be disproportionate to the outcome and yield comparatively low quality data.

Consultation outcome

The change will be implemented as per the proposal; adding three new fields for Venue.Postcode, ModuleDeliveryRole.VenueID and ModuleDeliveryLocation.MDLPROPORTION.

ID 63420: Postcode data revised specification

ID 64078: Module data (England, Northern Ireland & Scotland) feedback and outcomes

Description of requirement

There are a number of fields in the current data model for 2019/20 that are around Module level information (for example: Modules, Module Subjects, Module deliveries, Module delivery locations, Module Instances, Module Outcomes etc.). We would like to understand the burden that providers understand this will be to collect and return to HESA. Please could you answer these questions against the burden of setting up your records to record this data and of continuing to return the data each year.

Please note, that we are not asking this question of Welsh providers as the collection of module information is already well established. If Welsh providers have concerns about the collection of module information, they should contact HEFCW at [email protected].

Consultation feedback

Respondents were asked to provide an assessment of the ‘burden’ associated with this requirement. We received 38 responses. A summary of the responses can be found below. The chart shows the mean review score.

Several providers clarified that they responded to the above burden assessment without taking new consultation items into consideration. Some providers also commented about the restricted time left for development and the lack of guidance having been available from HESA for many of the fields.

Generally, the data collected around Modules is considered to be burdensome for providers. One provider specified that the burden applies to identification of requirements, constructing appropriate changes to automation/other processes and ensuring that all possible scenarios of module will work throughout the year. Another provider also queried whether given changes in the funding environment, whether there would still be a statutory need for this data?

One provider stated that they require detailed module data to run their business, and so there is no additional data gathering required for HESA.

Providers raised a number of points explaining where they have the most difficulty with the data around Modules. Specific points that were raised are:

  • MODSTAT and MODOUT are challenging areas.  
  • We suspect Module Outcomes and the link to FUNDCOMP might be the most difficult aspect for us.
  • Burden increased by introduction of HECoS coding. Also, others questioned the usefulness of holding HECOS coding at a modular level.
  • Module Cost Centre information being captured at the Module Delivery level (rather than the Module level).
  • Adding Postcode data increases the burden.
  • The date fields in the model. For example, Module start and end dates are not collected at present and will require business process rewriting. Also, the year and module status fields on the student module outcome entity being replaced with precise start and end dates at module delivery level, and then module outcome end data where this varies at a student module instance level.  
  • A suggestion to mimic the course structure by removing 'module' and keeping module delivery as the base level to simplify.
  • Module instance terminology is confusing.
  • The addition of the new (or newly mandatory) fields, such as delivery location and module results is an unwelcome increase.
  • Issues here is building in Module Delivery Location and Venue ID.
  • We are unclear on what is required on Module Delivery Location (as Venue guidelines seem to indicate the entity has to do with the management of the course, not the place where the course teaching is delivered.) It is also difficult to record for medical modules and for placements.
  • The need to treat everything in terms of modules, when not all courses are really modular is a significant burden.  Having to create dummy modules, especially for the less straightforward students who are not full-time and/or undergraduate, can be problematic.
  • PGR students don’t typically have modules.  Creating and supporting ‘virtual’ or dummy modules is onerous, particularly tying them back to the appropriate course delivery/course session is very complicated.
  • Modules that overlap and/or are longer than course sessions (for example, determining module outcome for module instances that represent only the first part of a module is not something we do currently and would be difficult to derive)
  • Module.FTE and ModuleInstance.Proportion seem to be duplication as otherwise would there not be separate Modules? Would it not be more appropriate for the FTE to be a delivery level so that module would aggregate to the same level regardless of FTE count within different courses (I'm thinking particularly UG vs PG).
  • FTE will be complex to tie in with STULOAD now STULOAD will be split across multiple returns.

Consultation outcome

No change to the data model for version 2.0.0 as there was no specific proposal here, this was more about collecting information from providers.

 

ID 42695: Relocation of OffVenueActivity feedback and outcomes

Description of requirement

The OffVenueActivity entity collects details of students undertaking activity that is not at the provider or partner(s) venue. This might include industrial placements, studying abroad or teacher training placements, although not distance learning.

In the current Data Futures model OffVenueActivity is associated with the ModuleInstance; however, feedback from the sector at recent seminars is that associating this with modular data may not be the optimum solution. We are therefore seeking feedback on moving this entity to be associated with a StudentCourseSession rather than the ModuleInstance.

Please note that we are not consulting on the requirement for this data to be submitted, rather the structure in which it will be returned.

Justification

Feedback from the sector has prompted a review of the implementation of this requirement. Although it is recognised that the requirement for the data is valid, alternative implementation options are being considered.

Proposed implementation

The OffVenueActivity and OffVenueActivityLocation entities were planned to be relocated to be child entities of the StudentCourseSession rather than the ModuleInstance. All the fields within these entities would remain. The Module.MOBSCHEME field would be moved to the OffVenueActivity entity as this would no longer be relevant at a Module level. The Module Instance identifier would be added to the entity, so that those placements that are taken as part of a particular Module (e.g. those that are credit bearing) could be linked back to the relevant Module Instance. The fields and entities would therefore be:

OffVenueActivity:
Off venue activity identifier (OVAID)
Activity duration amount (ACTDURATION)
Activity duration type (ACTDURATIONTYPE)
Activity end date (ACTENDDATE)
Activity start date (ACTSTARTDATE)
Activity type identifier (ACTTYPEID)
Host identifier (HOSTID)
Host identifier type (HOSTIDTYPE)
Host name (HOSTNAME)
Lead school (LEADSCHOOL)
Mobility scheme (MOBSCHEME)
Module Instance identifier (MODINSTID) 

Off venue activity location:
Country (COUNTRY)
Postcode (POSTCODE)

Key information In the consultation we were seeking feedback on the preferred method of implementation, not on the data requirements.

Consultation feedback

Respondents were asked to provide an assessment of the ‘burden’ associated with this requirement for the two different options suggested. We received 44 responses. A summary of the responses can be found below. The chart shows the mean review score.

Student 2019/20 (Data Futures) ID42695 sector burden assessment (module instance)

Student 2019/20 (Data Futures) ID42695 sector burden assessment (course session)

Student 2019/20 (Data Futures) ID42695 implementation option preferred approach

Providers were very supportive of moving the Off Venue Activity entity to the Student course session, for a number of reasons, including: it is difficult to collect at modular level, and not all placements are associated with modules. Many indicated they would have to set up dummy modules or would end up with duplicated data if they needed to return this associated with modules. Generally, it was felt that associating Off Venue Activity with Student course session would be less development work initially and less ongoing maintenance.

Many providers noted that having Off Venue Activity associated with Module Instance will involve more members of staff at providers, for both training initially and during the data quality assurance, as this is visible to substantially more people and that could leave it prone to manual errors.

The few who did support it at a Module Instance level already associate their Off Venue Activity with modules anyway, so it aligned with their current business processes.

There were a few questions raised about how quality assurance would work around this data, particularly as the quality rules have not yet been written. Some specified that moving MOBSCHEME to be within the entity also makes sense.

For completeness, HESA also undertook a burden assessment to look at the impact of the change for HESA. The lenses are broadly consistent with those used by providers.

Student 2019/20 (Data Futures) ID42695 HESA burden assessment (module instance)

Student 2019/20 (Data Futures) ID42695 HESA burden assessment (course session)

Consultation outcome

The Off Venue Activity entity will move to sit off the Student course session entity. The MOBSCHEME field will also be moved and a Module Instance identifier will be added to this entity.

Please note that the MODID field will allow those providers who do directly link Off venue activity with modules to associate the two together, particularly when they are credit bearing.

ID 62879: Additional items for removal feedback and outcomes

Description of requirement

It has been proposed that the following items are removed from the model as they are either no longer required or are serviced elsewhere in the model.

  1. EntryQualificationAward.RESULTSCORE and QualificationAwarded.RESULTSCORE
    All results are to be captured under the RESULT field on the appropriate entity, therefore the use case for these fields no longer exists.
  2. StudentFee.FEEDOMICILE and StudentModuleFee.FEEDOMICILE
    With the proposed removal of StudentRegistration.FEEREGIMECOUNTRY it is believed that FEEDOMICILE is also redundant.

Consultation feedback

Respondents were asked to provide an assessment of the ‘burden’ associated with this requirement. We received 32 responses. A summary of the responses can be found below. The chart shows the mean review score.

Student 2019/20 (Data Futures) ID62879 sector burden assessment

Most providers didn’t have any comments on this proposal, other than to support it as it reduces duplication within the current model. Some found this difficult to assess, given they weren’t currently set up to collect this data. There were also some general concerns raised about how late they are in receiving the final data specification more generally for 2019/20.

Having one result data field on each entity was felt to be a sensible suggestion and more straightforward for providers. For clarity – this is in the QUALRESULT field.

Reducing the number of fee fields was also welcomed as it will simplify and reduce duplication. There were suggestions that keeping the FEEDOMICILE fields could have helped with understanding a student’s fundability status. Therefore, it will be important to get the guidance clear around the permanent address type country field to make it clear that this is the equivalent to the current DOMICILE field.

Consultation outcome

Based on the feedback from the consultation, these items will all be removed from the record for 2019/20.

ID 48665: Expansion of Ethnicity.ETHNICITY coding frame (Scotland) feedback and outcomes

Description of requirement

The valid entries in the ETHNICITY coding frame are based in part on the 2011 census categories. Analysis of the census data has identified that a significant proportion of the population in Scotland identify as ‘White - other British’; however, this is not available as an option in the Student record. To better align with the census coding frame for Scotland, it is proposed that this new code is added to the coding frame from 2019/20.

Justification

The 2011 census in Scotland included the following categories for white people:

•           White: Scottish,
•           White: Other British,
•           White: Irish,
•           White: Gypsy/Traveller,
•           White: Polish and
•           White: Other White.

Every category is covered in the existing code list except ‘White; Other British’. Results from the 2011 census showed that over 400,000 (about 8%) of people in Scotland were classified as 'White - Other British'; this should, therefore, be reflected in the coding frame available to providers in Scotland.

Proposed implementation A new valid entry of ‘White – Other British’ was proposed to be added to the ETHNICITY coding frame.
Key information The new valid entry of ‘White - Other British’ is only applicable to providers in Scotland. Providers are encouraged to use the specific ‘White’ codes where possible

Consultation feedback

Respondents were asked to provide an assessment of the ‘burden’ associated with this requirement. We received 8 responses. A summary of the responses can be found below. The chart shows the mean review score.

Providers accepted that it was a good idea to include this data, but there were some concerns about this being in Scotland only (which it was suggested could result in incomplete coverage and inaccurate data) and the short timescales they would have to implement this change. Having multiple categories for ‘White’ was thought to be potentially confusing, particularly the ‘White – Polish’ category.

It was noted that it would be important for UCAS to also make this change, or this data won’t be captured for UCAS entrants.

There was a question around whether or not continuing students (particularly existing ‘white’ students) would need to be resurveyed? The intention is not, this would only be required for new entrants starting in 2019/20.

For completeness, HESA also undertook a burden assessment to look at the impact of the change for HESA. The lenses are broadly consistent with those used by providers, though slightly less in some areas.

Consultation outcome

Based on the feedback from the consultation, the changes to the Ethnicity.ETHNICITY field will be implemented for 2019/20 as per the proposal.

ID 13083: Term-time accommodation types feedback and outcomes

Description of requirement

There have been a number of comments from users that the current valid entries in the term-time accommodation type field are confusing and don’t clearly identify what should be recorded in each category. We have attempted to review the codes and come up with a different suggestion of groupings.

Justification The current valid entries can be confusing to students when they are asked this question by their providers.
Proposed implementation

We proposed to use a different set of valid entries in the term-time accommodation type field.  

Key information This information would continue to be required for all full-time students.

Consultation feedback

Respondents were asked to provide an assessment of the ‘burden’ associated with this requirement. We received 41 responses. A summary of the responses can be found below. The chart shows the mean review score.

Most providers acknowledged that this field has always been difficult to understand. Many believed that the proposed new definitions will be more easily understood by students and staff and welcomed the change. They agreed that this would help to reduce the data quality assurance burden for this item, though they have asked for clear guidance and definitions to support the change.

However, some stated that they were unconvinced about the quality of the data being returned, even with the suggested changes helping.

Further work is needed to clarify the definitions of the different accommodation types as some of these could still be unclear to students. A few suggestions were raised on items within the field, mostly around different label suggestions for some of the valid entries. The term ‘student flat’ was considered to be open to different interpretations by students.
 
It was mentioned that no consideration had been given to other scenarios, for example: People who live with a partner where the partner is the sole owner, Students living in property of other family members rather than parents and University / Private partnership accommodation. We are not aware of a requirement for this data, which is why it doesn’t have these aren’t separate categories in this field.

One provider asked about whether continuing students will need to be recoded. The intention is not, only new entrants from 2019/20 onwards would be required to use these new categories.

For completeness, HESA also undertook a burden assessment to look at the impact of the change for HESA. The lenses are broadly consistent with those used by providers.

Consultation outcome

Based on the feedback from the consultation, the changes to the PersonAddress.ACCOMTYPEID field will not be implemented for 2019/20 but will be deferred to a later cycle to allow more consideration to be given to the coding frame.

ID 54847: Identification of accelerated courses (England) feedback and outcomes

Description of requirement:

To support policy and funding requirements in England, it is proposed that accelerated course deliveries are explicitly identified.

Justification To enable the Office for Students (OfS) to monitor the impact of policy in relation to accelerated learning and allow the correct allocation of funding.
Proposed implementation It was proposed that an additional valid entry of ‘Accelerated full-time’ would be added to the CourseDelivery.COURSEDELMODETYPE
Key information

The new valid entry would only be applicable to providers in England.

The glossary published in the Regulatory Framework defines an accelerated course as: 

"A qualification at level 6 of the Framework for Higher Education Qualifications where the number of academic years to be completed is at least one fewer than would normally be the case for that course. A variety of terms is in use for degree qualifications which appear to be accelerated, including ‘fast-track’, ‘two-year’, ‘compressed’, ‘time-compressed’, ‘condensed’ and ‘intensive’".

Consultation feedback

Respondents were asked to provide an assessment of the ‘burden’ associated with this requirement. We received 20 responses. A summary of the responses can be found below. The chart shows the mean review score.

 

Student 2019/20 (Data Futures) ID54847 sector burden assessment

 

Providers were generally happy with this proposal; however, some of the providers who responded didn’t currently have any accelerated courses.

Some providers suggested that this shouldn’t be collected as part of the Mode field, particularly where this would mean a fundamental change to their student record systems but also because this moves away from the simple full-time/part-time split as defined originally in the data model. Instead, it should be its own flag off either the Student course session or as an attribute to a course.

For those who were happy with this being part of the Mode field, they did recommend that the Session Status entity should also include this new valid entry. This is helpful for examples where a student is studying on an accelerated full-time course and has a period of dormancy, if they return to their studies during the same Student Course Session providers will be unable to indicate the correct study mode for the student on their return.

For completeness, HESA also undertook a burden assessment to look at the impact of the change for HESA. The lenses are slightly higher for some areas than providers, mostly due to the unknown factors at the time of scoring about where this new data item would fit into our current categories, and therefore how many quality rules, derived fields, enhanced coding frames etc. would need to change.

 

Student 2019/20 (Data Futures) ID54847 HESA burden assessment

 

Consultation outcome

Based on the feedback from the consultation, the changes to the CourseDelivery.COURSEDELMODETYPE field will be implemented for 2019/20 as per the proposal. This addition will also be added to either the SessionStatus.STATUSCHANGEDTO or SCSMode.SCSMODETYPE field, depending on the outcome of the third consultation item on Mode.

ID 52084: Items for removal feedback and outcomes

Description of requirement

It was proposed that the following items were removed from the model as they were either no longer required or were serviced elsewhere in the model.

Entities for removal:

  1. Course Delivery Financial Support Offer entity
    The use cases for this entity were to record the number of Articulation places available on a given Course delivery in Scotland and to capture the number of NCTL-funded bursaries in England. Articulation arrangements are now captured through Student Initiatives, actual bursaries are captured through the Student Financial Support entity. This course-level information is therefore not required.

Fields for removal:

  1. StudentRegistration.FEEREGIMECOUNTRY
    This information is no longer required to be captured.
  2. StudentRegistration.FEEREGIMEINDICATOR
    This information is no longer required as it is captured elsewhere in the model.
  3. FundingAndMonitoring.FundingRecipient
    Information about funding arrangements is captured elsewhere in the record and this field is therefore no longer required.
  4. FundingAndMonitoring.HESESPOP
    This field is no longer required as it can be derived.
  5. FundingAndMonitoring.HEAPESPOP
    The HEAPES survey will cease running from 2018/19 and this field can therefore be removed.
  6. FinancialSupportoffer.MAXAWARDSAVAILABLE
    With the removal of the Course Delivery Financial Support Offer entity, also proposed in this consultation, the MAXAWARDSAVAILABLE field can also be removed as information about Articulation and Allocated places are captured elsewhere in the model.
  7. StudentInitiative.DESCRIPTION
    There is currently no use case for this field as the StudentInitiative.INITIATIVEID already includes the scheme/initiative name.

Consultation feedback

Respondents were asked to provide an assessment of the ‘burden’ associated with this requirement. We received 32 responses. A summary of the responses can be found below. The chart shows the mean review score.

Student 2019/20 (Data Futures) ID52084 sector burden assessment

All respondents welcomed the change and the drive to remove unnecessary items from the record however the impact, although overall minimal, did vary significantly depending on how far forward providers were with system developments. It was highlighted by several respondents that the changes are coming later than would typically be expected which contributes to an environment of ‘high risk’ and may have negative impact on the ability to work with software suppliers to prepare systems.

Consultation outcome

Based on the feedback from the consultation these items will all be removed from the record for 2019/20. In the coming weeks guidance will be published where appropriate to show how items are being derived.

ID 58838: British Sign Language (BSL) users (Scotland) feedback and outcomes

Description of requirement

In 2015, the Scottish Parliament passed the British Sign Language (Scotland) Act, which then led to the development of the British Sign Language National Plan. The plan sets out Scotland's ambition to be the best place in the world for BSL users to live, work and visit. It is framed around ten long-term goals covering early years and education; training and work; health; culture and the arts; transport; justice and democracy.

To support this policy the SFC require information on the number of UK domiciled students at providers in Scotland that are BSL users.

Justification The BSL National Plan states that by 2020 the Scottish Government “expect all colleges and universities will publish BSL plans, setting out how students who use BSL are supported, with a clear measurable commitment to improvement where necessary. These plans link with college and university Outcome Agreements and will be reviewed annually by the Scottish Funding Council (SFC), to ensure that inequalities experienced by D/deaf and Deafblind BSL students are being addressed.”
Proposed implementation

We proposed a new person characteristics entity be added to the Student return for 2019/20. To collect this, draft entity and field pages were published.

Consultation feedback

Respondents were asked to provide an assessment of the ‘burden’ associated with this requirement. We received 14 responses. A summary of the responses can be found below – note that this excludes responses supplied in error and those where the respondent confirmed that they were not affected by the requirement. The chart shows the mean review score.

Student 2019/20 (Data Futures) ID58838 sector burden assessment

There was broad support for the inclusion of this data however concerns were expressed about the ability of providers to respond in time for the 2019/20 registration period and the potential for students to misunderstand the definition which may result in reduced data quality or high levels of unknown data.

A number of respondents confirmed that this is not data that is currently collected and therefore would require changes to registration/enrolment processes and student records systems in order to store the information in the required format.

A number of respondents queried the implementation approach proposed in the consultation and cited the following concerns:

  • The need to record valid to/from dates
  • The limitations for expanding the items to collect more granular data about fluency or other forms of non-spoken language in the future

HESA also undertook a burden assessment, using broadly similar lenses, to assess the impact of the change on HESA. For completeness, the output is included below:

Student 2019/20 (Data Futures) ID58838 HESA burden assessment

It should be noted that the HESA assessment was made against the original implementation proposal; however, during the assessment HESA rasied the same concerns highlighted by providers.

Consultation outcome

In light of feedback received we have reviewed this and instead propose to expand the existing Language Proficiency entity to encompass this data. This will require an additional field on the entity – please see the entity and field pages in the below PDF.

ID 58838: British Sign Language (BSL) users (Scotland) revised specification

 

ID 39547: Service leavers (Scotland) feedback and outcomes

Description of requirement

The SFC would like to capture information on the veteran status of Scottish domiciled students studying on undergraduate courses at a provider in Scotland regulated by the SFC. Optionally this data would also be collected for Scottish domiciled students on postgraduate courses at providers in Scotland regulated by the SFC.

Justification

In November 2016, the Scottish Veterans Commissioner published his third report The Veterans Community: Employability Skills and Learning which made various recommendations including “The Scottish Funding Council, universities and colleges to specifically consider the veterans community as they embark on the expansion of articulation, as recommended by the Commission on Widening Access”. In order to take forward and implement the recommendations the SFC need to establish a benchmark of the current number of veterans in the HE sector and monitor changes in the numbers of students from this group. SFC requires this information to monitor access and retention of veterans at Scottish universities. This information will help develop policies to support this group of students.

SFC will only use the information to support national policy development and to inform Outcome Agreement discussions with institutions on how they are supporting veterans. This information will not be based on individuals. Any information presented to other interested parties will not identify individuals.

Proposed

implementation

As previously announced in the 2018/19 Initial Teacher Training Notification of Changes, the Department for Education require data regarding whether Initial Teacher Training students in England have served in the armed forces. This data will be collected in the 2018/19 ITT return.

It was therefore proposed to add an entity (Student.ServiceLeaver) to the Data Futures model to collect data regarding service leavers which will cover both purposes. The consultation is however limited to the SFC's requirement.

Key information

A veteran is defined as ‘anyone who has served for at least one day in Her Majesty's Armed Forces (regular and reserve) or Merchant Mariners who have seen duty on military operations’.

Data would be required to be maintained throughout the lifetime of the student’s record as their veteran status could change over time. This information would be required for continuing students as well as new students.

Quality checks would be in place to monitor the levels of unknown and refused data. It is expected that different thresholds for unknown data would be in place for part-time and full-time students.

Consultation feedback

Respondents were asked to provide an assessment of the ‘burden’ associated with this requirement. We received 9 responses. A summary of the responses can be found below – note that this excludes responses supplied in error and those where the respondent confirmed that they were not affected by the requirement. The chart shows the mean review score.

Student 2019/20 (Data Futures) ID39547 sector burden assessment

Respondents were broadly supportive of the implementation approach but acknowledged that the data is not currently collected and therefore would require changes to the registration and enrolment processes and student record systems. The scale of change for 2019/20 was raised as an issue and some respondents suggested that this would be difficult to accommodate.

There were concerns about the quality of data received as there may be a high level of unknown data or instances where the student misinterprets the definition. A question was raised about whether the student should provide evidence to support their claim to veteran status; however, this is not required – a self-assessment is sufficient.

It is expected that veteran status can change over time and quality assurance will be in place to highlight cases where a student goes from being recorded as a veteran to not a veteran as this is not a legitimate scenario – the original data should have been removed as a correction.

For completeness, HESA also undertook a burden assessment to look at the impact of the change for HESA. The lenses are broadly consistent with those used by providers.

Student 2019/20 (Data Futures) ID39547 HESA burden assessment

The largest impact on HESA would be in respect of the quality assurance of the data and identifying appropriate checks and thresholds with the SFC.

Consultation outcome

Based on the feedback from the consultation this item will be implemented as proposed for the 2019/20 collection. HESA will work with the SFC to agree thresholds for quality assurance and specifically the level of ‘unknown’ data in the first year of collection.

ID 51352: Module marks for courses regulated by the General Medical Council feedback and outcomes

Description of requirement

As previously announced, HESA is working with the General Medical Council (GMC) to provide them with education and assessment data on medical students. To meet the requirements of the GMC and remove the need for separate direct data collection HESA propose to add two fields (Module.MARKSCHEME and ModuleOutcome.MODULEMARKS) to the Student record for 2019/20 to capture assessment data for students on courses regulated by the GMC.

Justification

As a regulator of doctors and medical education, the GMC has a requirement to understand how assessments relate to outcomes, to research the quality of doctor selection and assessment mechanisms and to analyse progression.
Other avenues for data collection have been explored however they do not offer complete coverage and may otherwise require a separate collection of data.
All data is subject to the UKMED Research Policy, which complies in full with this code (https://www.ukmed.ac.uk/documents/UKMED_research_application_form.pdf) and will not be used to support decisions about individuals. Data is protected from disclosure through mechanisms compliant with that policy.

Proposed implementation We proposed to add two fields (Module.MARKSCHEME and ModuleOutcome.MODULEMARKS) to the specification.
Key information This information would only be required for students on courses regulated by the GMC. This information would not be required for modules taken during intercalation.

Consultation feedback

Respondents were asked to provide an assessment of the ‘burden’ associated with this requirement. We received 25 responses. A summary of the responses can be found below. The chart shows the mean review score.

The responses to this item were quite mixed with several respondents indicating that this represents a reduction in burden or at least a minimisation as these are existing requirements that would be reasonably straightforward to service through data already captured within student record systems. This was not a universal view and some of the key concerns and common themes in the responses can be found below:

  • There may be higher than expected use of the 97 'Other marking scheme' and 98 'The module is assessed on a pass/fail basis and marks are not awarded' categories in Module.MARKSCHEME due to the flexibility of marking schemes and non-modular curriculum design.
  • Concerns were raised by some providers about the comparability of the data across or within providers.
  • There were questions around how modules that may be taken as part of a GMC accredited programme but are themselves not accredited by the GMC would be identified.
  • A number of respondents suggested that this is an area that they would expect to continue developing over coming months and therefore found it difficult to complete the burden assessment.
  • One respondent proposed that a survey of mark recording practices might help identify any deficiencies in the proposed coding frames as they were not felt to be comprehensive.

In response to the feedback from the sector the GMC has provided the following statement:

"The GMC requires more detailed in school progression data to support the UKMED project in order that the sector as whole can research the predictive validity of medical school examinations. Schools themselves have the opportunity to use UKMED to understand how their graduates progress through postgraduate training. At this stage there is no intention to use module data to make judgements about individual schools. Furthermore data held within UKMED are only held for research purposes and cannot be used to make decisions affecting individual doctors and their careers.

The GMC will be launching the Medical Licensing Assessment in 2022.

To enable the collection and reporting of clinical and professional skills assessments (CPSA) which will be administered via the medical schools, from 2020 schools will be required to have a MODULE labelled 'CPSA' so that we can work towards capturing overall CPSA exam outcomes via HESA. Having an overall CPSA outcome that is more detailed than pass/fail will assist with studies looking at the predictive validity of the CPSA.

The UKMED researchers are aware of the challenges of consistency with regard to recording both over time and across different schools. Many measures currently used in UKMED research, for example the educational performance measure -deciles captured as part of the application to foundation training, have this problem.

We appreciate that we will need to have more detailed conversations with school to ensure these data are usable and to provide a more detailed specification. We can do this via the MSC Education leads forum and via visits to individual schools. We would prefer to collect student level data via HESA than any GMC process. If documentation at school level is required to ensure the HESA data are usable we would propose to collate that via the Medical School Annual Report.

We appreciate that schools will differ in their readiness to make module returns to HESA and we are comfortable that returns will differ initially and the degree of convergence to a more standard approach is currently unknown, but we feel it would be useful to make a start on having a better understanding of within school student progression."

For completeness HESA also used the burden assessment methodology to score the request from its own perspective and the results can be found below.

The run cost for the ‘Gathering’ and ‘Assurance of data quality’ lenses were scored slightly higher than the initial set up cost and this was attributed to this being a developing area where requirements and guidance are likely to evolve within the first few cycles of collection for the reasons articulated by providers and in the GMC response however the scale of this was unknown.

Consultation outcome

Module.MARKSCHEME and ModuleOutcome.MODULEMARKS will be implemented as per the proposal. HESA will continue to work with the GMC to develop the guidance for these data items in response to the specific questions raised as part of the consultation and through the Liaison service.

ID 54347: HND to degree bridging courses feedback and outcomes

Description of requirement

There is an existing requirement to capture whether a course delivery is a foundation degree to degree bridging course. For the purposes of more complete monitoring HEFCW have a requirement to expand the coverage of the existing CourseDelivery.BRIDGE field for providers in Wales to include HND to degree bridging courses as well.

Please note that whilst this requirement only applies to providers in Wales, it has an impact on all providers as it results in the removal of valid entry 01 which is replaced by a new, broader code 00.

Justification The data is required to enable monitoring of the progression of students onto degrees via bridging courses and to determine if degree courses are top ups.
Proposed implementation It was proposed to expand and change the valid entries in the CourseDelivery.BRIDGE field to cater for the return of this information.
Key information Whilst this requirement only applies to providers in Wales, it has an impact on all providers as it results in the removal of valid entry 01 which is replaced by a new, broader code 00.

Consultation feedback

Respondents were asked to provide an assessment of the ‘burden’ associated with this requirement. We received 19 responses. A summary of the responses can be found below. The chart shows the mean review score.

Student 2019/20 (Data Futures) ID54347 sector burden assessment

The majority of respondents were not affected by the change because they do not offer bridging courses; however, of those that were, the main area of impact was in relation to system change to accommodate the revised coding frame. However, this was regarded to be a limited change with minimal impact.

For completeness, HESA also undertook a burden assessment to look at the impact of the change for HESA. The lenses are broadly consistent with those used by providers.

Student 2019/20 (Data Futures) ID54347 HESA burden assessment

This was considered to be a minor change for HESA with limited set up costs with regard to quality assurance and data enrichment and no significant running costs.

Consultation outcome

Based on the feedback from the consultation, the changes to the CourseDelivery.BRIDGECRS field will be implemented for 2019/20 as per the proposal. Please see the entity and field pages in the below PDF.

ID 54347: HND to degree bridging courses revised specification