Skip to main content

V2: feedback and questions form

Your feedback
While we welcome any and all feedback on the material in version 2, we would very much appreciate a focus on items described on this page. Working through the design, these are the items which we feel would benefit the most from the expertise and experience of the sector. As you review the material within version 2, you will find references to these items. Please collate your feedback and submit it on the Feedback Form below.
Funding in the collection model differs from other segments in that it doesn't follow the natural flow of the data. Many of the fields collected are specifically for regulatory or statutory purposes and don't generally have any value for the provider. The Data Landscape Steering Group (DLSG) logical model can therefore be realised in two ways; 1. Individual funding attributes can be modelled into the segment where they best fit. 2. All funding entities (and associated attributes) can be split into a separate funding segment - as shown in the documentation in this release of the design - and collected as a 'bundle'. With 1- the benefit of fewer collection segments must be balanced with the potential for more returns of multiple segments outside of the normal business events. With 2- the burden of this part of the collection is made vey clear but this approach distances itself from capturing at the point of collection and potentially moving to a more reporting model where data is submitted when required by the public interest customer. The S6 Funding Segment brings together most aspects of funding and financial accountability-related data as per 2. above. By locating these attributes together, we aid the stability of the rest of the model, and ensure that it describes student activity in a long-term, sustainable way. Since funding schemes and organisations can come and go, we believe this is the most pragmatic approach to identifying data that relates to accountability in this area. Is this assumption correct? Are there elements in the S6 Funding Segment that could be rationalised, removed or derived? As part of this consultation, please review the entities, attributes, definitions and relationships in S6 and provide feedback to which would be your preference, and the reasons for this preference.
The current fee entity on S1 isn’t robust enough to meet our needs as the concept of FeeDomicile, in that doesn’t take into account all of the factors that determine the ‘sticker price’ for that piece of curriculum. We believe the requirement for what was GrossFee is the maximum fee that could be 'charged', where 'charged' is an assessment of student eligibility, and not a theoretical maximum price for a course. There are three options to resolve this: 1. Make Fee more complex to enable capture of all possible eligibility states and their fees. 2. Move Fee to be part of the Student Course Session as an additional piece of student level data. 3. Move Fee to sit between Student Course Session and Fee Invoice amount to make this a student specific fee. This can then be collected either at S3 or S6. Have we understood the issue, and is there a preferred option?
Within the current scope of S5 there are several attributes that logically live within different segments (principally S2). The implication of this is that the current shape of the S5 segment is incorrect and this needs to be redesigned to include these outlying attributes. Provisionally this would appear to be based around the transition of a student to a leaver and the updated that are required as a result of the registration being closed. It is the intention that for V3 this has been reworked so that there is no overlap between S2, S3 and S5, which is likely to result in the restructure of the Registration and Student Course Session entities.
Implementation of Course Subjects should be compliant with the approved Higher Education Classification of Subject (HECoS) implementation guide. Default 'roll-forward' from current position would imply that this entity is returned 16 times. However, this does not align well with known current sector use or module-level data. HESA is aware of 20% of HE providers who have at least some courses that would benefit from additional codes to describe them fully. Item for consultation - to advise our approach, we would welcome views from supply-side and demand-side customers to understand the amount of codes required in the future.
Collaborative doctoral provision can be more fully and accurately represented in the DLSG data language. Our initial thoughts about how this kind of activity should be represented as follows: The Main Contractor should take responsibility for setting up the Course with an appropriate CourseIDType. The Main Contractor will also assign Course Roles. Subcontractor Course Roles can also link Course Deliveries to the Course. They can of course create Modules and Module Deliveries. Any Main Contractor or Subcontractor can attach a Student Registration to appropriate Course Sessions at Segment S3 – Enrolment. Any Main Contractor or Subcontractor can attach one of its Module Instances to an appropriate Student Course Session at Segment S4 – Learning event. HESA will develop a quality assurance view as part of its standard toolset that enables the appropriate Course Roles to see a single view of the data. This will require an appropriate data sharing agreement to be in place. HESA will establish a process for determining the authoritative view on the data, and ensuring responsibility for the contract to educate either rests with the party creating the initial Student Registration, or that control is transferred.
Issues, concerns or opportunities not covered in the questions above.