Academic Services feedback to HESA regarding Data Futures V2, prepared by Rebecca Bridges, submitted with Susan Ponsford as the named contact on deadline date (09.02.2017).
Areas of feedback focus
Funding:
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;
- Individual funding attributes can be modelled into the segment where they best fit.
- 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 very clear but this approach distances itself from capturing at the point of collection and potentially moving to a more reporting-based 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.
Much of the finance information requested should be available from SLC and PGT loans data. It is unclear why the extra data items, such as invoice number, payment date etc., are being requested, what this information will be used for and what added benefit it provides. The collection of this data would be onerous as the student finance data is stored in a separate finance system and a reconciliation would be required. We have major concerns regarding the impact on resource that would be caused by the addition of these data items.
Given the timing/availability of most of the data items in S6 they could only be included in S4 (Learning Event). S4 is collecting MODOUT equivalent data which is used to determine FUNDCOMP (equivalent in S6) but, the inclusion of both invoice and financial support data as well, would make the production of S4 even more challenging.
We question why this data is being requested and have major concerns about the additional workload that will result, we do not understand the value/purpose of this data requirement and feel that the resulting increase in workload is disproportional.
Should this requirement be included the slightly better option would be a separate segment rather than trying to embed them into existing S0-S5.
Fee Domicile
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:
- Make Fee more complex to enable capture of all possible eligibility states and their fees.
- Move Fee to be part of the Student Course Session as an additional piece of student level data.
- 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?
Again we are unsure as to why this data is being requested as it could be derived from the Fee and Domicile data that is already being collected. This is not a piece of information that is currently collected separately by BU so this would require additional resource.
Should this requirement be included rather than being derived from the data already being collected then given the Invoice/Payment information currently being cited for S6, Option 3 would be the most appropriate, especially as it gives HEIs the option to provide student-specific data in S3 or S6.
S5 – Outcome
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 fields that are required as a result of the registration being closed. It is the intention that for version 3 this will be reworked so 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.
The inclusion of bespoke classes to hold Qualifications on Entry and Qualifications Awarded separately seems to be a valid development given the existing S5 hybrid class has already been classified as sub-optimal.
Course Subjects
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. We would welcome views from supply-side and demand-side customers in order to advise our approach.
BU has not submitted more than three course or module subjects within the Student HESA before and therefore our data should not be significantly affected by a default roll-forward from JACS to HECoS. In general, however, the more complexity added to subject code means the less likely it is to be used internally so a reduction in the number of codes available would be preferable.
Collaborative doctoral provision
Collaborative doctoral provision can be more fully and accurately represented in the Data Landscape Steering Group (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.
We welcome thoughts on how this could best be implemented, and anticipate that this will represent a work package in the detailed design phase of the Data Futures programme.
BU do not currently have any collaborative provision at doctoral level.
Other
Issues, concerns or opportunities not covered in the questions above.
We have major concerns around the lack of information regarding the timing and frequency of data collection. We are therefore unable to fully assess the impact on resource at this time. Should multiple in- year collections be required for the same segment of data then this would likely have an adverse effect on the ability to provide high quality data and also require additional, highly skilled and experienced (expensive and difficult to source) resource to deliver the segment.
Feedback form: Impact analysis
Business process
With near to capture submissions to HESA, processes around how that data is collected, extracted, transferred, etc. will need to change.
The lack of information regarding the timing and frequency of data collection means that we are unable to fully assess the impact on business processes at this time. Should multiple in- year collections be required for the same segment of data then this would likely have an adverse effect on the ability to provide high quality data and also require additional, highly skilled and experienced (expensive and difficult to source) resource to deliver the segment.. Once this information is available we will be in a better position to assess how processes would need to change.
Data management
Data quality for in-year submission and master data management are likely to be the two biggest changes.
Agreed, given the current level of Quality Assurance imposed by HESA, it could be very challenging to produce comprehensive and robust datasets within (what could be) greatly reduced timescales. Again, timing and frequency of collection will have an effect on this.
Capability
With the changes in business process and data management, there might be need for different capabilities / skills in different parts of the provider.
We need to know what the proposed deadlines are before we can fully appreciate whether our existing resource (and skill-sets) are capable of achieving the new statutory schedule.
Technology
What are the key changes to the student information systems and associated technology platforms.
It is clear that Tribal will have to produce an entire new suite of statutory tools to enable these new cumulative submissions to be generated and they will be under pressure to deliver an appropriate and timely solution. It is likely that the entire SITS user-base will be reliant on Tribal consultancy to deliver online solutions as many will be trying to implement their own process changes within the same timescales and many will require Tribal resource to facilitate their developments.
Given the additional Funding data proposed there will also be a need to reconcile the data between systems to ensure all data items are available in the format required by HESA.
Communication
How will these be communicated at your provider, who are the key stakeholders, what messages do you need help with.
More information is required from HESA regarding timescales before we will be able to assess this.
Implementation
What will be the best way to implement the change - e.g. a new project with dedicated resources / business as usual / as part of a current or planned initiative (e.g. replacing student information system).
Given the increasing diverse nature of the proposed datasetthat would affect stakeholders across BU, a new project with dedicated resource would be the most appropriate course of action. It would not be possible to include this in ‘business as usual’.
Other
Issues, concerns or opportunities not covered in the assessment above.
The lack of information regarding the timing and frequency of data collection means that we are unable to fully assess the impact of the changes at this time. We have major concerns regarding the increase in resource that will be necessary to provide the data and the adverse effect that it may have on the quality of the data being provided. Shorter timescales to deliver data may not allow sufficient time for full quality assurance.
The proposed model appears to be more onerous, particularly for institutions with multiple entry points. It is unclear how multiple entry points will be dealt with at this time, however, our understanding is that multiple submissions of particular segments will be required.
Managing HESA fields that are used purely for HESA reporting purposes may have an adverse impact on the maintenance of fields that are used regularly by institutions. Treating HEIs as customers as well as providers of information may help to address this.