Skip to main content

24056 StudentCourseSession and SessionYear consultation

The survey is now closed: thank you for your responses.

As part of the Student record post implementation consultation Student record 22056 - post implementation consultation, we sought feedback on the 22056 data specification with some questions focused specifically on the StudentCourseSession and SessionYear entities.  

This consultation seeks feedback on four specific proposals for changes to the student record. These are being proposed following a review of feedback provided in the post implementation consultation, post collection seminars and discussions with statutory customers. The changes are proposed for the 24056 Student record; however, this consultation also includes questions seeking feedback on the timelines for implementation, so this may change. 

We have made a PDF of the survey available on the survey overview page to assist you with cross-organisational response, but we expect online responses only. If you require other options or assistance to complete the survey, please contact [email protected].

We will aim to publish outcomes from the consultation in August 2024 alongside an updated Notification of Changes for 24056. 

This survey is aimed at those staff members who are involved in the submission of Student data to Jisc, either directly by sending the data, or indirectly by collecting data which feeds into the Student record. Other responses are welcomed too, but the questions may not all be relevant. 

We ran a webinar on Monday 17 June 2024 at 15:00 where we gave an overview of the proposals in this consultation and includes a Q&A segment for providers - the recording is available below. 

24056 consultation resources

24056 consultation webinar, Monday 17 June 2024

 

 

The proposals are summarised below and more details and examples can be found in each section of the consultation, along with further background information on why these changes are being proposed. Any combination of these proposals may be taken forward post consultation. 

  1. Proposal one: removal of SessionYear. The SessionYear entity has been highlighted by providers as an area that is challenging to return and where the value is not well understood. This proposal looks at the potential removal of this entity and further changes that would be necessary were this to be removed. 
  2. Proposal two: return of previous StudentCourseSessions. This proposal relates to guidance updates to allow the return of a previous StudentCourseSession rather than having to create a new StudentCourseSession in cases where there is no activity to record. 

  3. Proposal three: update to ModuleInstance dates guidance. Feedback from providers has indicated that the requirement for ModuleInstances to be contained within the associated StudentCourseSessions has caused issues due to the need to create start and end dates that do not reflect student activity. This proposal looks at updating this guidance so the ModuleInstance dates can reflect the students’ activity. 

  4. Proposal four: guidance on cumulating StudentCourseSession sub-entities. This proposal relates to the current guidance for SessionStatus, OffVenueActivity and ModuleInstance which require these entities to be returned in the reference period in which the associated StudentCourseSession ends, even if the activity occurred in a previous reference period. This proposes removing this requirement. 

Data processing notice for consultations 

Responses to this survey will be used to support the review of the Student record, and will be used in analysis, documentation, and communications in connection with that activity.  

We may share your survey responses with statutory customers, sector bodies or other organisations involved within the consultation. We will share your response together with your provider name however we will not disclose your name or email address to organisations we share responses with. 

Privacy information

Proposal one

If a Session Year is removed does this mean we would have to return all cohorts the way we are returning postgraduate research students, i.e. StudentCourseSession has to be one year in length?

Yes, that is the proposal - the StudentCourseSession would represent a year of the course (unless it was one of the exception cases, late starters or shorter courses). The StudentCourseSession would not necessarily need to be a full year but start dates would be expected to be broadly consistent between years - see scenario 1 in the draft StudentCourseSession guidance document. 

The consultation proposes new fields if SessionYear is to be removed: would these be required if the SessionYear start date (or course year start date) was on the StudentCourseSession? I'd imagine most providers will know when their course years are being delivered so could add that data into StudentCourseSession alongside the student start date rather than needing to explicitly flag late starts and/or repeaters.

Having a SessionYear start date on the StudentCourseSession would be another alternative option, yes. But in this consultation, we went with the flag fields. Happy for providers to tell us if the exact date would be an easier option.

Removal of SessionYear would be welcome but most of the complexity we faced from the new return is related to having multiple StudentCourseSessions within a reference period. Is there any review of the StudentCourseSession entity planned?

I'm afraid that requirement will still be there in this proposal, so there will be cases where multiple StudentCourseSessions need to be returned for a student.

Can there be a late starter flag AND a partial resit flag?

Yes there can be both if both are applicable.

The consultation states that identifying late starters per StudentCourseSession are part of the current funding model, however the HESES recreation specification does not appear to refer to SessionYear dates so is there further information on how the OfS are using the identification of late starters for current funding decisions?

Response from the OfS:

The OfS determines funding on a per-FTE (full-time equivalence) basis and the most recent guidance on counting student activity is given at Annex C of Higher Education Students Early Statistics survey 2023-24 - Office for Students. To calculate FTE for a student within a given year for funding purposes we have previously needed to verify that a late starter has not missed so much as to trigger a change to the classifications used. A combination of SYSTARTDATE and SCSSTARTDATE was being used to identify students who started at a later point than the rest of their cohort, in the calculation of HESFTE_CASE (HESA DF DCT HESES22 comparison technical document (officeforstudents.org.uk)). However, this field has been decommissioned for the purpose of verifying HESES23 data, where FTE has been determined through the calculation of ‘Multiplication Factors’ (as described on the OfS website at www.officeforstudents.org.uk/data-and-analysis/data-collection/multiplication-factors/) and the approach looks directly at SCSMODE.

The OfS will notify providers of changes to 2024 student data surveys to inform funding in due course, and we issued a call for evidence in respect of the approach to OfS public grant funding which was open from 14 March to 23 May 2024. During the pre-election period we are unable to comment on the development of future funding policy and its potential to require the continued identification of late starters. We can though confirm that it has not been required in respect of the HESES23 and 23056 Student data used to inform funding for the 2024-25 academic year.

The year + 14 days I think this is more common than you appreciate... new starters can start for example, 19th September in year 1, in year 2 it could be into October before they start year 2 - this is very common. I can think of a number of institutions where this will apply to all UG year 1 to year 2 students. This will also need to be considered for medic courses- changes each year based on clinical placements etc

We will need to have some validation in place to ensure StudentCourseSessions are returned consistently and representing years of study. We have proposed that rules would trigger if start dates differ by more than 14 days between years which may result in tolerance overrides. Please consider this in your response and provide any feedback.

STUDENT.StudentCourseSession.SESSIONYEARID.003.V01 quality rule has been agreed to allow 14 day leeway for 23056 (this was previously 5 days). So some additional flexibility has been added but tolerance overrides will still be needed in these examples.

For students on an accelerated programme - their 1st year (or session) may start in mid-September - but their 2nd year (session) will start in August.

There is specific guidance on accelerated courses in the consultation document - please see scenario 13 in the draft StudentCourseSession guidance document. 

Every 7 years or so, the SCSSTARTDATE is before 365 days after the previous one. E.g. the start of session might be 26th September one year, and 19th September the following year.

This example would be fine as the dates are within 14 days - the most important thing is that the StudentCourseSessions do not overlap.

Is the year plus 14 days now to allow you to do all the things you need to do for FTE etc? Is there any point in this if we have to apply for tolerances for most of the population?

The 14 days is to allow some flexibility in dates varying between years. If this would require a lot of tolerance overrides please consider this in your consultation response.

Proposal two

Have any conversations taken place with software suppliers regarding their ability to implement the functionality to return a previous StudentCourseSessions in these circumstances?

We will be raising this with software suppliers and have a specific meeting in the diary to talk through the consultation with them.

Is this for the end of year return model, or the in-year return model? I can understand how this works in-year as you can then update data in the second return, but as an end of year return this won’t work.

This guidance applies to an annual or in-year return. Whether these scenarios apply is affected by whether data is known at the point of making a return. In-year reporting may therefore make these scenarios more likely due to compressed timescales but they still apply to an annual return.

Would the dormant from date need to be inside the original/previous year StudentCourseSession period?

The date should reflect when the student actually went dormant, which in this example would be in a previous reference period.

Does the SessionStatus entity need to be a sub-entity of StudentCourseSession? Since it is dated, could it be returned as a sub-entity of Engagement instead?

We did look at moving the SessionStatus entity, but it made some scenarios more difficult. On Engagement it wouldn’t always be clear if there were multiple dormant periods being reported.

If the previous StudentCourseSession was down as completed, would we have to specify the dormancy starts the date after the end date, or could a simple flag and the date be derived afterwards?

The date is here because there are cases where we wouldn’t be able to derive all dormancy periods without specific dates, flags wouldn’t be enough.

Would we have to return all child entities with the StudentCourseSession, such as ModuleInstances, OffVenueActivity etc?

Based on current guidance, yes you would. A validation rule will pick up to make sure nothing else was changed. So please consider whether this is more or less burdensome in your consultation response. This may be affected by the outcome of proposal four which proposes that entities are only required to be returned in the reference period they span. 

Would a provider have the choice of how to return these dormant scenarios? Old or New way?

Ideally we would all do this in the same way, but we will consider allowing both options when we make decisions on this proposal.
 
In the new backdated dormancy scenario, if combined with the removal of SessionYear and forcing of StudentCourseSession to be one year long, would the dormant from date be after the StudentCourseSession year finishes or after the end of the planned activity within that year, as per current guidance? 

SessionStatus records when the student went dormant. StudentCourseSessions would not always be a year- please see draft guidance in the consultation. Please see scenario 1 in the draft StudentCourseSession guidance document. 

Could an additional code for a backdated dormancy in the Leaver entity simplify the return of this scenario rather than needing to be returned in StudentCourseSession?

In this scenario, the student is taking an agreed break in leaning but has not left the Engagement so a Leaver entity would not be returned.

How does it affect the student load calculation (or maybe it doesn't make it easier).

The ReferencePeriodStudentLoad entity has a YEAR and REFPERIOD associated with it so it relates to a specific reference period. This is only required to be returned for the current reference period but if being re-returned for a previous reference period, the FTE for that reference period should be returned.

For providers in Scotland, the STULOAD field would be returned recording the FTE for the StudentCourseSession.

Proposal three

What would the SCSESSIONID look like on the proposed new guidance for modules (ModuleInstance1 on the diagrams)?

SCSESSIONID is part of the primary key to uniquely identify the ModuleInstance. This means the primary key for the ModuleInstance would change when returned against StudentCourseSession 1 and 2. Linking between StudentCourseSessions would therefore likely need to be based upon the MODID.

If HEFCW is the only funding body using module dates for funding purposes, why do providers outside Wales report them? Do the OfS need module dates for a specific reason?

Response from OfS:

The OfS has considered module dates from English providers important to OfS and DfE modelling and policy development work in preparation for implementation of the Lifelong Learning Entitlement (LLE). During the pre-election period we are unable to comment on the extent to which that requirement will persist, nor on any subsequent requirement for use of the fields for purposes related to the LLE or any other emerging aspects of our regulation or government policy.

Response from SFC:

Module dates can be used to assign module activity to academic sessions, which can be used to get a breakdown of activity in cost centres by academic session, which in turn enables us to obtain a breakdown of activity in our teaching price groups by academic session. Module dates indicate when activity takes place during an academic session and when in-year returns are introduced the spread of module activity over previous academic sessions can be used to inform estimates of the amount of activity that will take place in the rest of the academic session.

Is proposal 3 relevant to Approved providers, as Approved providers do not return module data based on 22056?

If you do not return module data now, then no that would not apply to you.

Proposal four

If proposal 4 goes ahead, could we return all modules if we wanted to?

Ideally we would all do this in the same way, but we will consider allowing both options when we make decisions on this proposal.

Would there be any validation that looked back at the previously returned child entities and compared to those being returned for the current period, e.g. a SessionStatus returned in previous period and a subsequent one returned in the current period.

If this proposal went ahead, child entities would not be required to be consistent between reference periods for a StudentCourseSession so we would not validate that they aligned. Some validation may be in place for logical consistency checks.

Would HESA be willing to provide some examples as to what is considered OffVenueActivity?

Yes, we are working through the suggestions that were given in the post-implementation consultation to add into the guidance. Please do drop Liaison an email if you can’t find your specific example.

Consultation feedback will likely be in the context of current software solutions. We won't know before 5th July if software suppliers will be able to be changed to make proposals either work or to reduce any burden associated with the change.

We will pick this up with software suppliers, please include any concerns in your consultation response.

Currently we are not returning modules that sit outside of the SCS and this is generating errors, what is this data used for in England. Can tolerance be requested? 

ModuleInstances from a previous StudentCourseSession are not required to be returned against subsequent StudentCourseSessions. There is a known issue with the ModuleInstance.006 rule, this has been removed from the system whilst we resolve this. This proposal relates to return of sub-entities within the same StudentCourseSession when these span reference periods.

Could you show where in the current guidance it says that ModuleInstances not in an StudentCourseSession or reporting year of the current return needs to still be returned?

ModuleInstances should be submitted against the StudentCourseSession, not just the reference period in which they occurred. Therefore all of the ModuleInstance associated with the StudentCourseSession will be returned for the reference period in which the StudentCourseSession finishes.

In the old legacy Student return, MODSTAT=4 indicated the module did not contribute to that reporting year. How is this being done now, how are able to ignore modules that do not contribute to the StudentCourseSession, is via start and end dates?

You only need to return the ModuleInstance for the StudentCourseSessions that it spans, that does not mean it needs to be returned for the whole Engagement.

If it's QR.STUDENT.StudentCourseSession.ModuleInstance.006.V03, I had about 88000 errors in that rule until I submitted a new file this morning.

There is a known issue with the ModuleInstance.006 rule, this has been removed from the system whilst we resolve this.

This will get complicated: QR.STUDENT.ModuleInstance.MODINSTSTARTDATE.001.V01. ModuleInstance start date must not be before StudentCourseSession start date.

Yes this rule will need to be changed if this proposal goes ahead. 

Overall questions

Another concern is the amount of change. Preparation for 2025/6 UK Partnerships needs to start in 2024/5, and planning for pre-emptive collection of TNE etc info and in year for 2026/7.  

Yes there is a lot of change happening in the coming years. Based on feedback we believe these changes will benefit providers but please include information in your response if you disagree based on volume of change.

Please clarify how we can respond to the proposal?

24056 StudentCourseSession and SessionYear consultation