Consultation outcome: incorporating the ITT record into the 2024/25 Student record
Contents
- Overview of the consultation
- Overarching themes
- Data model proposals
- TRN allocation process
- ITT deadlines
- Which students are in coverage?
- Signing off the ITT data
- New validation request
- General questions to finish
Overview of the consultation
This consultation, which proposed to incorporate the ITT record into the Student record, was published on 14 June 2023 and closed on 14 July 2023. We received 33 responses from higher education providers in England. We only accepted online responses; we have provided a PDF of the text and questions included in the consultation for reference purposes only.
As part of our commitment to transparency, we provided the full text of feedback and responses to Statutory Customers; we have included representative comments below to summarise the feedback received in the consultation. No recommendations are included at this stage.
Overarching themes
There were overarching themes raised during the consultation responses, and this section summarises the concerns raised.
75% of respondents mentioned some concerns with the October deadline during their consultation response. Some providers indicated that their assumption had been that when incorporating the ITT return into the Student return, this would be along the same timescales as Student and simply ITT related fields would be added to the data model. Continuing with an October deadline would likely increase the burden and would make it feel like the records are not truly being combined.
This would potentially reduce the data quality of the rest of the Student return if an earlier deadline would take away some focus from the data submitting teams.
Requests were made for DfE to reconsider the October deadline, with some stating examples were data would need to be changed / updated after October, including: students who apply late, students who withdraw or suspend studies, and mis-matches between October and December end of reference period deadlines. Providers requested DfE reconsider exactly what data would be adequate for their statutory purposes in October – would data already on the Register be adequate, what data could wait until December?
66% of respondents raised general concerns about being able to complete a Student record in time for an October deadline (more information needed to be collected, sorted and coded; extra fields and validation when compared to ITT record; whether student record systems would be updated in time to send two separate returns by October 2024 etc.). It should be noted here that many of these respondents assumed we needed a full Student return by October, when the proposal was only for the ITT sub set of fields by October – although many points raised are still valid for the smaller return).
42% of respondents stated concerns with the implementation year of these changes (2024/25). Problems highlighted included: it will be the first in-year return and another change isn’t practical, providers don’t yet have a full understanding of the impact of the Student record changes, subsequent years would be more realistic etc. Concerns were raised about having sufficient notification of the changes being made in order for software suppliers to develop the systems in time to meet this requirement.
Three respondents explicitly suggested that the proposal was delayed until 2025/26 and many others simply requested a delay. Reasons given included: it would give providers and Jisc another year’s experience of doing two reference periods per year, before ITT was added, and it would give providers more time to plan out and test the changes necessary.
30% of respondents gave their support for the principle of combining the definitions and data between the ITT and Student returns. Comments given including: combining would reduce burden and the number of returns made; aligning data definitions is always welcomed and would reduce duplication; removal of unnecessary data items is supported.
Data model proposals
Question 4: To what extent do you agree with the proposals of where fields from the ITT record will be added to the Student record?
| Response | Count |
|---|---|
| Strongly agree | 4 |
| Agree | 23 |
| Neither agree or disagree | 5 |
| Disagree | 1 |
| Strongly disagree | 0 |
Question 5: To what extent do you agree with the proposals for those fields that will no longer be collected?
| Response | Count |
|---|---|
| Strongly agree | 11 |
| Agree | 21 |
| Neither agree or disagree | 1 |
| Disagree | 0 |
| Strongly disagree | 0 |
Question 6: Please provide any contextual information to support your above answers, or any alternative approaches you think should be considered, about collecting data on teacher training students.
Some respondents explicitly supported the data model proposals and others supported the principle of combining the ITT return into the Student record.
Many data model specific suggestions were raised for consideration, including:
- Moving field to different areas of the model (Application number to EntryProfile, Bursary level award to StudentCourseSession, Email addresses to Engagement)
- That Session year start date is not the right replacement for ITT start date, and that Engagement start date (or Trainee start date) would be better replacements.
- Not all agree with the new entity proposal for PGEntryQualificationAward, believing it should be combined with EntryQualificationAward, though others believe the proposal keeps the distinct scope, purpose and detail of collection separate.
Question 7: What would be your preferred method of collecting data on Lead Partners?
| Response | Count |
|---|---|
| UKPRN | 16 |
| URN, or in its avsence UKPRN | 16 |
| Publish teacher training courses and Apply for teacher training courses provider code or in its absence, UKPRN | 0 |
| Some other identifier | 1 |
Question 8: Please provide any contextual information to support your above answers, or any alternative approaches you think should be considered, about collecting data on lead partners.
Among those respondents who would prefer just UKPRN to be returned, some stated that this would align with principles used in other fields in the new Student record (as part of the Data Futures programme). Respondents stated this would be the simplest option, effective and although software and/or process changes would be required, a single identifier would be their preference.
Those respondents who would prefer to return a URN (or in its absence UKPRN), most say this would require the least amount of development work or changes at their provider. It was suggested that the majority of schools would have a URN and that the matching process with Edubase is more robust.
Two suggestions were made to include a marker of the type (like the Host identifier and Host identifier type fields) to align with other Student record principles.
The one respondent who selected “some other identifier” clarified this was because they do not return data on lead schools/partners and so the question was not relevant.
TRN allocation process
Question 9: which method would you prefer to download TRNs for your trainees?
| Response | Count |
|---|---|
| Download TRNs from the HESA system | 7 |
| Download TRNs directly from the DfE system | 16 |
| No preference | 10 |
Question 10: Please provide any contextual information to support your above answer on downloading TRNs.
Of those who preferred to obtain TRNs from the HESA system, 4 respondents preferred using HESA as the single platform for ITT data requirements and reasons came down to staff access. Some saying it means less training for staff on multiple systems, and others that their HESA or student record system staff would be the ones needing access to the TRNs, and not all had access to the DfE’s system. Other respondents indicated that it helped them maintain good data quality by having one source of the truth.
Another stated that they would prefer to remain with the current approach so no system developments would be required. They also requested clarity over cases where multiple notifications of TRN allocation occurs, and would like to understand the criteria used by DfE for allocating TRNs in order to understand the process better.
Of those who preferred to obtain TRNs from the DfE system, seven respondents indicated that this was about their ITT staff having the right access to download the TRNs and this being the right process for their provider. 3 respondents stated that they preferred the data coming from a single source, and that the DfE Register was more appropriate and would be a more consistent approach. Others stated that the Register was easier or simpler to use than the HESA system.
Of those who indicated they had no preference, two respondents mentioned staff access, one stating that staff already had access, the other that access would need to be given to both the ITT side and the student record systems side of the provider.
Other points mentioned the HESA system being friendlier but that it doesn’t always work for them, or that the fewer times data has to be transferred between systems the better. Another respondent mentioned that they had no preference so long as there was a bulk download with student identifiers.
ITT deadlines
Question 11: To what extent do you agree with the proposed timelines?
| Response | Count |
|---|---|
| Strongly agree | 1 |
| Agree | 7 |
| Neither agree or disagree | 11 |
| Disagree | 5 |
| Strongly disagree | 9 |
Question 12: Please provide any contextual information to support your above answers, or any alternative approaches you think should be considered, about the proposed timelines?
The eight respondents who agreed with the proposed timelines, raised a number of concerns about meeting the deadlines, including: clearing schema errors, having meaningful data to send in August, and the October ITT deadline seeming to be a third reference period. Other concerns were raised about when these changes would happening, including: software suppliers being ready in time, lots of conflicting work happening at the same time (other consultations and the in-year return), and the timing of finishing the previous Student alongside the next years ITT return.
The 11 respondents who neither agreed or disagreed, showed concerns for the crunch point of the first ITT submission clashing with the previous Student return, another stating that the Census points work well and are an established pattern.
There was confusion about what the continuous data feed to the DfE meant, and whether all the data futures fields would be required in October. For October only the ITT fields and ITT validation would be required, providers could submit the whole model if they wanted to, but the non-ITT fields would be ignored for October. The current ITT record is sent to DfE on a continuous basis already, and the difference here would be not having set deadlines throughout the year (January, April and July). These update windows are already optional and providers only need to submit data if they have something to update/change – that same principle would apply in that providers would only need to submit data when they needed to tell DfE something had changed or needed updating.
The 14 respondents who disagreed with proposed timescales raised a number of concerns, including the crunch point of making the change, the sign off in October being unrealistic and breaking the two reference period approach in data futures, and that two concurrent returns were not currently possible with software systems. It was noted that subsequent years would become easier as there will be more experience with the new data model and more bugs will have been fixed. One respondents said that having no cut off points would be difficult to manage and it would be better to have a separate cohort of students being sent for each purpose. There could be mismatches between the data being submitted in October and that signed-off in December, which will be misleading for all third parties using the data and the DfE should therefore consider aligning with the data futures timescales.
Question 13: Is this scenario a potential concern at your provider? Is there anything HESA can do to help providers with this transition?
Five providers explicitly said they didn’t have any concerns and five weren’t really sure. 11 respondents believed this scenario could occur for them.
The majority of respondents talked about the concurrent years and the cross over that will occur. Concerns raised included: software suppliers being ready in time, working on multiple returns at the same time not being practical, and getting the previous Student return signed off in time to work on the next years ITT deadline. Respondents also restated that the amount of work and resources required for a full Student return and that October is too early to complete this.
The current purposes of the two records are clear, but if they are included in the same return this is problematic and more difficult to manage. A request was made from a few respondents to keep the dates aligned to reference periods, as it was felt to be pointless to combine the two records if they remain with different dates.
Even for those respondents who didn’t anticipate this being a problem, they noted that it will still be a challenge to make a file with the full Student requirements so early in the academic year and changes to internal practices and systems will present a certain amount of risk. And this is the first time providers will have done so under the new specification.
Two suggestions were made to hold off until 2025/26 to allow providers to test and plan out this change and get to grips with in-year reporting first. Another asking for only essential change to the Student record for 2024/25, to reduce the number of amendments in systems and associated processes. Respondents asked for good e-learning and guidance to be produced when the change is made.
Which students are in coverage?
Question 14: Do you have any comments on the proposed coverage of the student data that will be delivered to the DfE by HESA via the Student record?
Some respondents questioned whether it would be beneficial to include certain students who were outside of the proposal, including: awards given for QTS, withdrawals, dormant students, transfers to non-QTS courses, reporting any student who had previously been reported to DfE.
One respondent stated that the benefit of continuing with in-year deliveries would be to be able to add new students or correct bursary information. Other respondents suggested either a flag or a continuity register to help identify any students who had previously been returned to DfE to help with making updates to the data with DfE.
One respondent clarified that the coverage of the ITT record and Student don’t match and requested the two were rationalised if combined – in the Student record you don’t need necessarily need to include students who are at the provider for less than 2 weeks but in the ITT record if they have engage with the course material at all then they must be reported.
Question 15: Providers would be expected to notify Register about students outside of the coverage of the data transferred between HESA and the DfE. Please comment below if you have any concerns about this approach.
There were 11 respondents who didn’t have any concerns with the proposed approach, three respondents explicitly indicated this was aligned with their current approach, whereas another three respondents stated it would be a change in current practice. Clear guidance on exactly which students are being referred to and what data was being transferred to DfE was requested.
Seven respondents would prefer HESA to manage all student data being fed to DfE, stating it would help toward better quality data, it would reduce the duplication of effort to report data. Most of the five respondents who expressed concerns with the proposal, indicated this to be their preference.
Respondents requested that DfE and HESA work together to provide a simpler process for the data flows to be managed, to make it easier and more straightforward for providers. Adding flags to the data specification or making some sort of built in continuity to pick up students who were previously included in a data transfer to DfE were suggested. Some were not clear why these others students couldn’t already be included in the data transfer.
Signing off the ITT data
Question 16: Would you be happy in principle to confirm you are happy for data to be shared with the DfE, each time you submit data to the HDP?
The majority of respondents were happy with this approach. To clarify the confirmation suggested in the consultation was only when providers were ready to send the data, so anyone suggesting this was their preferred approach has been taken as agreement.
Some respondents added clarifications in their agreement, such as: would this be confirmed in bulk or individually, would we be able to filter down to just the ITT quality rules, or could this just be a tick box option?
Three respondents indicated they weren’t happy with the proposal, one stating they wanted to notify DfE directly, another wanted a formal sign-off process, and another stating concerns around running quality assurance processes for a subset of students within the larger Student file.
Those respondents who were unsure said it would depend on the level of sign off required, or that they needed clarification on the process and exactly what data would be passed to DfE.
Question 17: Do you have a preference on the potential approaches to “remove”
| Response | Count |
|---|---|
| Option one: continue to notify DfE directly | 13 |
| Option two: HESA to explore potential options via the HDP | 14 |
| No preference | 6 |
Question 18: Please provide any contextual information to support your above answers, or any alternative approaches you think should be considered, about a process to “remove” students?
Those respondents who would prefer to notify DfE direct, most stated that their Education teams were the best staff to make the necessary amendments, as they understand the changes that need to be made. Two respondents wanted to understand more about how the other option would work, and another about how providers would indicate the data is ready for official use.
Those respondents who would prefer to submit via the HDP, most considered it more appropriate to remove the data at source and that this would be aligning with the overall vision of incorporating ITT into Student. They would like to use just one platform and automation is preferred to manual updates – a suggestion of using IMS for the audit trail was given, rather than ad hoc communications via email. A flag field on Engagement was also proposed, to help identify students who should be in the transfer to DfE.
Those respondents who did not have a preference, felt there needed to be a sign off process before the data is used by DfE. A question was raised about whether the Student record or DfE’s Register should be considered the primary source of the data (and the other reconciled to it).
New validation request
Question 19: Do you have any feedback on the two new validation requests?
Although the majority of respondents were supportive of the validation proposals, one said: “These two requests illustrate why your normal policy of not consulting on individual validation rules is wise, and we support it.”
Five respondents indicated these would be catching mistakes and another five suggested these could be genuine, from cases they’ve had in the past, and wanted clarification that switches (now tolerances) could be requested.
One respondent was not supportive, stating that they wanted no new or additional barriers to be applied early in the cycle as there was already significant burden on their small team, at an already busy time of year.
General questions to finish
Question 20: Any other comments on the ITT record combining with the Student record in 2024/25?
Those respondents who were supportive of combining, welcomed the approach to rationalised to a single process and a single set of deadlines. They welcomed making two returns consistent and compatible with each other to reduce duplication and support internal quality assurance.
Those respondents who were not happy to combine the records, stated that the timelines for an October deadlines were unrealistic and burdensome and the additional data futures fields were more burdensome. Concerns were given about the business and technical developments needed to support the change, particularly the challenges for software suppliers in supporting two concurrent returns being made to different specifications.
Three respondents indicated that they would simply prefer to keep the returns separate. Two respondents state that it did not feel like it was being combined when the deadlines and reporting schedules were different.
Some queries were raised about exactly what data needed to be returned, exactly which quality rules would apply and whether only the ITT schema checks could apply.
Question 21: would you like to be involved in further development work?
| Response | Count |
|---|---|
| Yes | 21 |
| No | 12 |
Many email addresses were given and we will be contacting those named when we get around to working more on the technical aspects of this ITT change.
Respondents welcomed any further opportunities to contribute to a solution that would work for all stakeholders. Some would have liked to be involved, but given current Student record pressures and existing resources, felt they could not commit the time.
Question 22: Any other comments this consultation?
Most respondents did not add anything further.
Two respondents stated that this was a short consultation period for a very significant change and that it was challenging to gain comments from all interested parties within their provider during the busy exam period. The consultation was presented as a technical one, but it is far from just that and has implications for the whole mechanism of submitting a Student return.
One respondent stated they were grateful to have Jisc clarify the content through a software supplier focus group call and would have welcomed seeing software supplier responses to the consultation. Two respondents explicitly expressed their thanks for the opportunity to offer input and for gathering provider views on this change.