Dormancy

This document runs through seven scenarios of students taking a break in learning under different circumstances.

General principles

The SessionStatus entity records where a StudentCourseSession changes status. The student is considered to be dormant when the SessionStatus.STATUSCHANGEDTO is returned as:

• 02 ‘Dormant’
• 03 ‘Intercalate’ - the return of this status means the student is intercalating at another provider and so is dormant at the reporting provider (see student 7).

The principles of returning a student are the same for reporting they have a status of ‘Dormant’ or ‘Intercalate’.

If a student moves to a dormant status, this must be returned in the data, it cannot be assumed that the student is dormant based on them not being returned in a given collection. This should be declared when the provider is aware the student had changed to dormant status. The point at which the provider knows this may affect the way in which the data is returned (see students 4 and 5).

Once an Engagement has been returned as dormant and all associated StudentCourseSessions closed, this does not need to be returned again until they either resume study or they will not be returning to their Engagement (see student 6). A StudentCourseSession must continue to be returned until it has been closed with a StudentCourseSession.SCSENDDATE returned. Each time a StudentCourseSession is returned, all SessionStatus updates for that StudentCourseSessions must be returned, even if the status change applies in a previous reference period.

The SessionStatus.STATUSVALIDFROM date records the date from which the relevant status applies.

The SessionStatus.STATUSVALIDFROM should not be prior to the current StudentCourseSession.SCSSTARTDATE unless:

• The SessionStatus.STATUSCHANGEDTO is 04 ‘Writing up’ and the student moved to writing up in a previous StudentCourseSession
• The student is being returned to indicate that they went dormant at the end of the previous StudentCourseSession, as this was not known at the point the previous StudentCourseSession ended (see student 5). In this case the SessionStatus.STATUSVALIDFROM must not be equal to or before the previous StudentCourseSession.SCSENDDATE
• There was an error made in the data in a previous collection and so the date must be backdated into the previous StudentCourseSession to correct this. This would cause a validation issue to highlight this. Validation issues will need to be explained and tolerances approved by the relevant regulator or funding body.

Student 1: A student goes dormant part way through a StudentCourseSession

Student 1 begins studying and so has a StudentCourseSession returned to record this activity. Part way through the StudentCourseSession, the student takes a break in learning.  A SessionStatus entity would be returned to indicate the student has changed to dormant status and the date of the status change.

The StudentCourseSession must continue to be returned in every reference period until it is given an end date in StudentCourseSession.SCSENDDATE. The SessionStatus would continue to be returned each time the StudentCourseSession is returned.

The student is still dormant at the end of the StudentCourseSession i.e. when the associated SessionYear has ended or (where there is no associated SessionYear) where the StudentCourseSession is a year in length. The StudentCourseSession would be given a reason for ending.

As the student has been returned as interrupted in this StudentCourseSession, they do not need to be returned again until they either resume study or they will not be returning to their Engagement (see student 6).

Student 2: A student goes dormant part way through a StudentCourseSession and is known to be going dormant for a year

Student 2 begins studying and so has a StudentCourseSession returned to record this activity.  Part way through the StudentCourseSession, the student takes a break in learning and has 
agreed with the provider that they will take a break lasting for the remainder of the StudentCourseSession.

A SessionStatus entity would be returned to indicate the student has changed to dormant status and the date of the status change.

As the student will not be returning to study within this StudentCourseSession, the StudentCourseSession is closed with an end date and reason for ending.

As the student has been returned as interrupted in this StudentCourseSession, they do not need to be returned again until they either resume study or they will not be returning to their Engagement (see student 6).

If the student were to return to study earlier than expected, this StudentCourseSession could be reopened by returning the StudentCourseSession without the end date and reason for ending removed and a SessionStatus update indicating that the student is now active. If the student returned to active study on a different Course or SessionYear, a new StudentCourseSession would be required to record this rather than reopening the previous StudentCourseSesison.

Student 3: A student goes dormant and resumes study within the same StudentCourseSession

Student 3 begins studying and so has a StudentCourseSession returned to record this activity.  Part way through the StudentCourseSession, the student takes a break in learning.  Shortly after the student resumes study.  Two SessionStatus updates would be returned for the StudentCourseSession, one when the student went dormant and one when they resume study, with associated dates.

Note: This scenario would be returned in this way where the student's break in learning did not mean they moved to a new SessionYear (or where learning did not have an associated SessionYear). If the student resumes study against a different SessionYear, a new StudentCourseSession would need to be returned associated with the appropriate SessionYear.

Student 4: A student completes a StudentCourseSession and is known to be going dormant

Student 4 completes a StudentCourseSession as expected but, at the time of returning this, the provider knows the student will be taking an agreed break in learning. The StudentCourseSession would be closed with a SessionStatus entity indicating the move to dormant status at the end.

As the student has been returned as dormant at the end of the StudentCourseSession, they do not need to be returned again until they either resume study or they will not be returning to their Engagement (see student 6).

Student 5: A student completes a StudentCourseSession and is expected to return the next year but subsequently goes dormant

Student 5 completes a StudentCourseSession as expected and is expected to return the following year.

This StudentCourseSession would therefore be closed with a reason for ending of 04 ‘Ended’.  The student does not return to continue studying the following year as expected. As the previous StudentCourseSession did not indicate the student was dormant, a new StudentCourseSession is required to be returned to record this.

The StudentCourseSession must be associated to the SessionYear that the student was expected to be returning to. The exceptions to this are Postgraduate Research students and students on fully flexible courses where SessionYears are not required.

Student 6: A dormant student informs the provider that they will not be resuming study

Student 6 has previously moved to a dormant status, this was returned against a previous StudentCourseSession. They then inform the provider that they will not be resuming study.

A new StudentCourseSession is not required to be returned as the student has not undertaken any new activity.

This student would be returned again with a Leaver entity to record the student's end date and reason for ending. The QualificationAwarded entity would also be returned if applicable to record any exit qualification(s).

Note: It is not normally expected that a student would be dormant for more than two years and returned as part of the same Engagement. If a student was dormant for two years, a Leaver record would need to be returned to close the Engagement and if the student did return to study, a new Engagement would be returned.

Student 7: A student intercalates at another provider

Student 7 is studying at provider A and will be taking an intercalation year at provider B during which they will undertake no activity with provider A.

At the end of the StudentCourseSession prior to the intercalation year, a SessionStatus update would be recorded indicating that the student will be intercalating.

A StudentCourseSession is not required to be returned by Provider A for the intercalating year as the SessionStatus update has indicated the student will be intercalating elsewhere.

Provider B would then return the student for that year with the StudentCourseSession.INTERCALATION field indicating the intercalating year.

If a student is intercalating at the same provider, this SessionStatus value would not be returned and the provider would return the intercalating year with the StudentCourseSession.INTERCALATION field.