Collection Design: Changes from V2 to V3
Below is an explanation of the alterations we have made as a result of feedback on version 2 and further analysis we have undertaken in response to questions.
Please note, version 3 pages are still available for your reference, but we have disabled links to avoid confusion: please refer to the Data Futures Resources page for project documents for your consideration.
A number of attributes associated with FE provision have been excluded from this consultation. Due to time pressure, we have not completed the modelling of these attributes, and at this stage prefer to remove them rather than leave them in a partly-modelled state. The Data Futures Programme Team is currently considering how best to take forward this piece of work.
We have made some substantive changes to the data, and some structural changes to the segments to indicate where a ‘schema’ can be ‘split’ or returned in two parts separated over time – this is in cases where a single logical entity contains data that is not all available at the same time in many cases (or explicitly has some characteristics that cannot be known until a later point in time than other data in the segment). Such segments might be returned once in a partial state, and later to finalise or ‘close-off’ the record. We have diagrammed this as a box-within-a-box in the appropriate places.
S0 – Organisations and Venues
Renamed from 'Reference Data'.
This Segment comprises reference information about the provider and the venues at which its activities take place.
No changes, other than to the name of the Segment, to make it more descriptive.
S1 – Courses and Modules
This Segment comprises the planned or advertised Course, Module and Qualification reference information that is required to make sense of the student journey.
The S1 segment is shown as having a sub-type for modular data. This is to make clear in presentation that the ‘course’ data and ‘module’ data do not have dependencies on each other, and hence could be returned separately. The model always did allow for course deliveries and module deliveries to be returned at separate times – the new presentation makes this more obvious.
We have added a CourseDeliveryTitle to the Course Delivery (which has broadly the same properties as the logical CourseTitle – itself very similar to CTITLE). We have added CourseName to Course in its place. This feels more natural, as Courses can be described as aggregated by the HEP, and Course Deliveries can more closely match the advertised curriculum (e.g. the CourseName=”French” can have CourseDeliveryTitles =”French Literature” =”French Language and Literature” and “French Cultural Studies”).
The HECoS implementation guide does not require any changes to the logical or physical models. It is proposed to require at least one HECoS subject, and to allow up to three HECoS subjects for each Course, Module or Qualification.
We have added ‘Awarding Body Role’ as a new physical entity, to permit joint and double awards to be recorded. This change will need to be exposed to the governance process as it is a logical state that the Logical Model does not yet capture.
Module Delivery Role has been added to enable franchised-out provision to be recorded accurately – this was an omission in V2 – thanks to the providers who pointed this out.
We have removed the Fee entity from this segment, and moved it to Segment S3 (more detail below).
S2 - Registration
This Segment comprises information about the person registering as a student, their intentions and attributes on admission.
StudyIntention has been redefined to cover all categories of student. See Appendix B for details.
EndDate and ReasonEnd have been moved from the Student Registration Entity to the new Leaver entity in S5.
S3 - Enrolment
This Segment comprises information about the status and mode of a student’s ongoing engagement with their studies.
We have shown the Enrolment segment into two sections, one to denote the creation, and the other to denote the closing off-of a Student Course Session.
We have introduced an amendment to the way that Status is recorded. We have added a sub-entity of Student Course Session, called Status. Status holds a StatusID (FK), StatusFromDate, and StatusToDate. Live, StatusID and StatusChangeDate have been deleted from the Student Course Session as a consequence. This change enables certain changes in Status to be recorded without forcing the requirement for a new Student Course Session, making the transition from provisional enrolment (StatusID=O, if returned) to ‘live’ status (StatusID=L) and a subsequent change to part-time mode (StatusID=M) all recordable within a single Student Course Session, rather than forcing two Student Course Sessions to exist for this scenario, which seems unnatural.
We have added a StudentCourseSession.StartDate. Normally, a Student Course Session will inherit the relevant CourseSession.StartDate, but in cases where a student engages with provision in a non-standard way (e.g. as the result of an internal course transfer after the first term) then the presence of a StartDate allows this to be recorded.
We have amended the way we record Fee in the model in response to the feedback you gave us – thanks. The issue raised with the Fee entity in the V2 consultation is resolved by moving the Fee entity to the S3 segment (on the grounds the maximum fee chargeable to the student must be known by this point). The Fee is now modelled as student-level data, rather than curriculum data as originally intended. The amendments are spelt-out in detail in Appendix A, but in essence we have reintroduced a concept more in harmony with the current concept of GROSSFEE. The direct relationship with Course Session has been removed, and a new relationship with the Student Course Session has been made. A Student Course Session can have one or many Fees, and the sum of all FeeAmounts will be the maximum chargeable fee for that Student Course Session. Where necessary, individual Fees can be given ModuleDeliveryIDs to indicate that they are Modular fees. The presence of a FeeDomicile still enables cross-border UK students (for instance) to be identified. In line with this thinking, FeeTBC has been removed, and null values in FeeAmount are not permitted.
S4 – Learning Event
This Segment comprises information about the student’s participation in learning activities, and the outcomes of study.
We added a new entity: Module Outcome. This breaks out the information from the Module Instance that can only be known once the Module Instance has concluded (ModuleOutcome, ModuleResult, EndDate) to simplify reporting. Module Language has been made a child of Module Outcome for the same reason.
S5 - Leaver
Renamed from 'Outcome'.
This Segment comprises information about the awards made as an outcome of study, and marks the end of a student’s registration.
We have renamed this Segment, to denote that its main function is to establish the Leaver role for the person. We recognise that HESA uses the terminology ‘Leaver’ in respect of the Destinations of Leavers from HE survey, and that it’s meaning in that context is closer to ‘graduate’. In this context we are using the term ‘Leaver’ in the context of ‘a student who has left’ or more precisely, a Student Registration with an associated Leaver.EndDate. We have also added IntentionEndDate to indicate the difference between an end of a Student Registration, and the end of an Engagement.StudyIntention (i.e. the final Student Registration in an Engagement).
In line with this we have added a Leaver entity, which relocates ReasonEnded and EndDate from the Student Registration. This is a cut-down version of, and potential amendment to, the Leaver entity in the Logical Model. It permits the Student Registration to be ‘closed off’ with a potentially much smaller data return, and marks the transition to a new role for the Person.
S6 – Funding and Monitoring
Renamed from 'Funding'.
This Segment comprises information about how students and courses are funded, and the populations into which students are grouped for both funding and monitoring purposes.
We renamed this Segment (and the entity with the same name) from ‘Funding’ to ‘Funding and Monitoring’ in line with its observed purpose of both recording funding information, and establishing populations of students.
The two links to Organisation (FundingBody FK and FundingRecipient FK) have been made optional.
We added HEAPESPOP to the Funding and Monitoring entity, in order that this population can still be produced.
The collection logical model has been updated to reflect this change.