Student (Data Futures) specification consultation
As communicated in Data Futures: programme update, Data Futures will not be going live in 2019/20.
The team at HESA is working on a revised plan for delivering the student data collection for 2019/20, including the AP and ITT student collections, and a solution for new providers. We will be working with the Statutory Customers to formalise plans and will provide further information in due course.
Description of requirement
In order to support the creation of Institutes of Technology in England it is proposed that the coding frame for StudentInitiatives.INITIATIVEID is amended to include an Institute of Technology flag.
Providers involved in Institutes of Technology (IoTs) are required to meet key performance metrics as part of the awarding of an IoT title. In order for the DfE and OfS to produce these metrics a method to identify the students at these providers is required.
| Justification | For DfE and OfS to accurately award providers Institute of Technology status some metrics are required. Capturing this as part of the Student record enables the OfS and DfE to monitor and regulate the IoTs without the need for separate direct data collection. |
| Proposed implementation | Institute of Technology (IoT) will be made available to providers in England only. This aligns with the IoT competition set up by the DfE which was applicable to England providers only. |
| Key information | For providers in England we will introduce basic checks to ensure that IoT providers have returned some IoT students and that those providers that are not part of the IoT network have not inadvertently returned the code. |
Consultation feedback
Respondents were asked to provide an assessment of the ‘burden’ associated with this requirement. A summary of the responses can be found below. The chart shows the mean review score.
Providers considered this to be a very minor impact, although it is worth noting that most providers who commented were not currently running this particularly scheme. Many indicated that they would add this to their coding frames anyway for future proofing.
Outcome
The change will be implemented in 2019/20 as per the proposal, but in the Student (C19051) and AP Student (C19054) records.
This code will also be added to the StudentInitiatives.INITIATIVEID field in the Data Futures model.
Description of requirement
The Department for Education (DfE) have made us aware that they require two new initiatives codes, for:
- Transition to Teach
- Now Teach
These are two new ITT programmes that will commence in September 2019. It is proposed to add these two new valid entries to the StudentInitiatives.INITIATIVEID field.
These programmes offer support and guidance to anyone moving into a career in education. They are designed for people who may be interested in using their skills, knowledge and life experience to become a teacher. Each programme helps individuals to understand their options and provide practical and individualised support to assist the transition to becoming a teacher.
They are both employment based, postgraduate programmes covering eBacc subjects. Data is required to facilitate any financial incentives and provide analysis on its success.
Please note that these codes will be added to the C19053 ITT record in the Student.INITIATIVES field. If you want to add any comments on the late change to that record, please also include them in this consultation item.
| Justification | For DfE-EYSG to track the success of the schemes to determine if they warrant expansion. DfE need to be able to confirm any associated financial incentives (e.g. uplifts to bursaries) with any ITT providers. |
| Proposed implementation | It is proposed to add two new valid entries for ‘Transition to Teach’ and ‘Now Teach’ into the StudentInitiatives.INITIATIVEID field. |
| Key information | Providers in England would need to return this data when it applies to their ITT students. Validation will be added to ensure that these student initiatives codes can only be entered if: the qualification aim is a postgraduate qualification, the entry route is either School Direct Salaried or School Direct Tuition Fee routes, and the subject code(s) are one of the eBacc subjects. |
Consultation feedback
Respondents were asked to provide an assessment of the ‘burden’ associated with this requirement. A summary of the responses can be found below. The chart shows the mean review score.
Providers considered this to be a minor impact. There would be some changes needed to systems to accommodate the new code, but no big concerns were raised. Not all providers responding currently had these codes.
A couple of providers suggested that we needed a more joined up approach when considering new initiatives codes and that perhaps in some cases this data would be better sourced elsewhere. It was also noted that more focussed information on any new initiatives would be helpful.
Outcome
The change will be implemented in 2019/20 as per the proposal, but in the Student record (C19051).
These two new codes will also be added to the StudentInitiatives.INITIATIVEID field in the Data Futures model.
Description of requirement
Statutory Customers have made us aware that they no longer require the Regulatory body reference number in the 2019/20 specification. This is code 05 in the PersonIdentifier.IDTYPECODE field.
| Justification | This data is not required by Statutory Customers any longer. |
| Proposed implementation | It is proposed we remove valid entry 05 from the PersonIdentifier.IDTYPECODE field. It is proposed to remove this from 2019/20, but it could be removed from 2020/21 instead, if this will cause providers problems at this late stage. |
| Key information | It is still necessary for providers to record the Regulatory body reference number, but it is not needed in the HESA Student record from 2019/20 onwards. |
Consultation feedback
Respondents were asked to provide an assessment of the ‘burden’ associated with this requirement. A summary of the responses can be found below. The chart shows the mean review score.
In general providers welcomed this change and were happy that this would have a low impact. It was observed that this change was being proposed relatively late in the process; however, the Data Futures programme is now not going live 2019/20.
Many providers indicated that they had not been returning this data anyway, or have not been happy with providing the data, or have consistently returned the default codes and would really welcome it being removed from the record.
However, one provider questioned whether this change is aligned with the aim of reducing burden across the sector given that it is still in use by some organisations, albeit not organisations that currently receive data from HESA. This will be reconsidered if the organisations using this data are onboarded to receive data from HESA.
One provider asked if we could look at removing the UCAS application number in a future review, given that it has not been valid for students since 2011/12.
Outcome
The change will be implemented in 2019/20 as per the proposal but it will be removed from the Student record (C19051).
It will also be removed from the PersonIdentifier.IDTYPECODE field in the data futures model.
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:
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.
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. |
| 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 update
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
Final outcome
After working with Statutory Customers and providers over the past couple of months, we have now reached a final decision on how FTE will be recorded across the sector:
1. Providers in England and Wales have three options for returning FTE:
- Return STULOAD at the end of the Student course session and return module data
- Return the planned FTE, which can be updated at each reference period
- Return FTE per reference period
If providers use the first option, then a derived field will calculate a reference period FTE for them. Please see the blogpost, Defining a new approach to recording FTE, for more detail on the thought process behind these decisions.
2. Providers in Northern Ireland return a predicted FTE against the Student course session and then a final figure in the current STULOAD field. The derived field will also be calculated.
3. Providers in Scotland should continue as before and only return STULOAD at the end of the Student course session.
The field specifications for each method of returning FTE are already in the data model – only the coverage statements will need to be updated to reflect the above, which will happen in a future model release.
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. |
| Proposed implementation |
‘Christian – Roman Catholic’, ‘Christian – Protestant’ and ‘Christian – Other denomination’ will be made available to providers in England and Wales for students whose permanent home address is in Northern Ireland. It is proposed that the use of these codes is mandatory in Wales and optional in England. |
| Key information |
A derived field may be introduced to map 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. |
Consultation feedback
Respondents were asked to provide an assessment of the ‘burden’ associated with this requirement. A summary of the responses can be found below. The chart shows the mean review score.
In general respondents did not support this change being made, for a number of reasons: the change to business processes and enrolment forms is disproportionate to the number of students affected; the change would be difficult for software providers to implement within the timeframe for the 2019/20 collection; the change would create additional complexity that could lead to an increased risk of error; the concern that the list of religions is not comprehensive.
The feedback from the consultation indicates that unless the collection were made mandatory few providers would capture the data voluntarily because of the complexity it adds to the data capture process.
The responses also raised a broader point regarding the capture of personal characteristics data as several respondents expressed a preference for a broader coding frame to be available to all students, irrespective of country of domicile or provider. This would make data capture simpler for providers as it would mean that the UCAS data collected through Apply could be used. This is not something we could consider for the 2019/20 collection but will be considered for a future implementation cycle as the DfE (NI)’s requirement for this data remains.
Consultation outcome
Based on the feedback from the consultation, the changes to the Religion.RELIGION field will not be implemented for 2019/20 but will be deferred to a later cycle to allow more consideration to be given.
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:
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.
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
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.
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:
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
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.
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:
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:
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
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.
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 location: |
| 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.
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.
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.
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.
- 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. - 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.
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.
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, 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.
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.
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.
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.
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.
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:
- 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:
- StudentRegistration.FEEREGIMECOUNTRY
This information is no longer required to be captured. - StudentRegistration.FEEREGIMEINDICATOR
This information is no longer required as it is captured elsewhere in the model. - FundingAndMonitoring.FundingRecipient
Information about funding arrangements is captured elsewhere in the record and this field is therefore no longer required. - FundingAndMonitoring.HESESPOP
This field is no longer required as it can be derived. - FundingAndMonitoring.HEAPESPOP
The HEAPES survey will cease running from 2018/19 and this field can therefore be removed. - 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. - 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.
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.
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.
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:
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
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.
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.
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.
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. |
| 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.
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.
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.
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