Collection design: frequently asked questions
We have compiled a list of frequently asked questions (FAQ).
I don't understand all of the terms referred to
We have included all terms in our Glossary of terms page.
How do resubmissions work?
Data can be resubmitted under two scenarios; 1) the submitted data was incorrect - for example student coded onto the wrong courses or 2) the submitted data has been updated - for example additional or more accurate data about one or more students. Business rules will be developed to ensure these resubmissions are reflected in all of the QA process.
How do deletions work?
A deletion of a course, a student, etc will remove the item from the QA process and allow all / any validation to be rerun. If this materially affects an output that has already been run, this output can be recreated. However the process of how the customers of this data will consume data that has passed the reference point for which is was targeted has yet to designed as it is outside the scope of collection design.
How will continuity rules work in first year as previously submitted data on the 'old' system won't be available?
This is out of scope for collection design, but the current thinking is the in-year collection will be seeded with data submitted for the current return and/or tolerances will be relaxed to allow continuity issues to be passed.
How will the sign-off process work?
There is still work to do here. The proposal is that the reference point will be a sign off point for multiple customer outputs. Who will sign this off is obviously provider specific. We do not currently envisage sign off points for input or integration QA. Only for when the data is transformed into a specific output but has not yet been sent to the provider
Does all the data for a segment need to be submitted if there is a change / deletion?
No. The collection system is intended to accept delta changes. This is more of a question for detailed design. It may also be influenced by the provider specific student information system implementation.
Is it understood that most of our business processes are based around the end of year cycle, so changing to in-year is going to be very challenging
This feedback was very prevalent. We respect each institution’s autonomy in terms of how the returns process is run. However, moving to in-year should harmonise existing business events to data items requiring submission.
During the transition between end of cycle and in-year, this is going to challenging.
We are considering how the wider Data Futures programme can support this.
One early idea is the production of a generic Data Capability plan which each provider could customise so providing a workable plan between the ‘as-is’ towards the ‘to-be’
Will HESA provide any training or other support for the changes required?
While we cannot make specific commitments at this time, we are very interested in understanding what type of help would be required and when it would be most valuable.
Will there will be a Data Entry tool?
We are planning to produce a Data Entry tool and at this stage the plan is for the existing tool to be adapted in order to make it work effectively with the new solution.
In terms of when the Data Entry tool will be available and what features it will provide that will become clearer during the Detailed Design Phase.
What are our options as we do not see internal and ‘HESA’ data as the same thing
We expect this gap to close as in-year collections drive up the quality of data items used operationally, for management reporting and for submission to HESA. We accept this will take time, but believe there is tremendous value in having data within the provider and data being readied for statutory outputs aligned and trusted.
There is also clearly a comms message required through the institution/s and we will be working with you to understand how we can help to frame that message.
How do we manage staff understanding, resourcing and support/cultural shift?
We understand the quality process for HESA data typically takes place either throughout the year or at the end before the return is due. With in-year collection, this will require a far higher quality of data at entry stage if returns are to be made closer to data capture. Consequently, staff involved in data capture who can be those that work across the provider will require a greater understanding of wider data requirements and may require additional resource especially in the initial years of Data Futures collection.
We also see this is more than just a change to business processes but a cultural shift in the way data collections and submission occurs. We believe the cultural shift should be considered a prime target for the HEDIIP data capability framework as this explicitly aligns objectives with the way data is captured and used. HESA is considering the best ways to support this agenda.
How do we deal with in-year changes or corrections?
Please refer to Quality Assurance FAQ for detailed information.
Will we be punished for the lower data quality due to the shortened time period for quality assurance?
Please refer to the Quality Assurance FAQ, but briefly we believe the analysis and feedback from the HESA systems will help drive the quality up to the required level. However we also accept this is going to require significant improvements in some institutional data management capabilities.
How are HESA engaging with software suppliers?
Software suppliers will be at the forefront of implementation during Data Futures and we have expect to have regular engagement with software suppliers during the project. We held an event solely for software suppliers on 14 December to discuss the Collection Design Project and Data Futures, and we consider regular engagement and feedback as essential so providers can work with their software supplier to implement new processes.
How frequently will the elements in S6 need to be returned?
The frequency for the return of the funding data will be driven by the reporting needs of statutory bodies.
Will the Funding and Monitoring be expected for all students?
The funding and monitoring data is an optional requirement in the model. The final mandate for the collection of the data is still to be defined, but the coverage will be the same as now unless a new requirement is identified by a statutory body.
When and why is FundingRecipient required?
Funding recipient is required where more than one organisation is involved in the delivery of the course. It will unambiguously identify which body is in receipt of the funding. It is an optional field as it will only apply where there is funding associated with the student as the other fields in the entity are required for monitoring purposes.
How will this relate to information currently provided for the SLC?
We will aim for a close match and a representative from the SLC is a member of the Data Landscape Advisory Panel. We need to have further discussions with the SLC as attendance monitoring is not part of the current HESA data collection mandate. If it is to become part the mandate, it will be addressed as part of the Governance process.
What is the relationship between the new submission and the HESES return?
We will have further discussions with the funding councils about satisfying their requirements for data at specific reference points. Initially it may be the case that a separate HESES return is continued, but the aim is to reduce the burden on providers by ensuring the HESA return can meet the requirements in the future.
Is a specific way required of identifying clinical band A for HEFCE funding banding?
The need to identify clinical band A for the HEFCE funding banding will be considered as part of the migration to HECoS.
Why is student support eligibility being collected?
The requirement for student support eligibility will be reviewed as HEFCE have requested its removal from the current returns.
Will there be more than one public interest customer whose needs would be met for Scotland?
In addition to the Scottish Funding Council, the Research Councils already receive data for providers in Scotland. The collection of in-year data creates the possibility of delivering data to other statutory bodies, reducing the burden on providers of creating bespoke returns.
What is the justification for collecting the Financial Support scheme/offer?
The Financial Support Scheme and Offer are reference data for the types of schemes on offer which will give consistency and comparability across the sector.
What exactly is required for Course Delivery Financial Support Offer and for what purpose will it be used?
Course Delivery Financial Support Offer will be used to determine situations where financial support is available as a number of places per course, or funding per course. For example, it could cover the articulation programme in Scotland, or the NCTL allocated places in England. It will enable the existence of the funded activity to be captured independently of any individualised records. Hence, the Financial Support Scheme and Financial Support Offer may potentially apply to the HE Provider, rather than individual students.
Is Financial Support Offer intended to collect information on which students did not take up offer as this could add to the burden?
Whilst the model allows the collection of information about students who did not take up financial support offers, there is no intention to collect this data unless a statutory body has a justifiable reason to do so.
Will Northern Ireland, Scotland and Wales be exempt from returning financial support?
Financial support is an optional requirement in the model. The final mandate for the collection of the data is still to be defined, but the coverage will be the same as now unless a new requirement is identified by a statutory body.
Who needs the fee information – how and when do they plan to use it?
The same HESA Statutory Customers who currently need the fees data will continue to receive it from the new collection for use as they do now. This includes monitoring the various fee levels and their spread across the UK; monitoring the actual fees paid by students and which student groups are charged reduced fees; gaining an understanding of the various sources of student fees and the extent to which various bodies are supporting students through payment of their fees.
Is the coverage of fees data being extended and why is the fee invoice data required?
The final mandate for collecting the Fee data is still to be defined, but the coverage of ‘gross fee’ will be the same as now unless a new requirement is identified by a statutory body.
Fee Invoice is a logical representation of net fee. The existing mandate for collecting fee data creates a link between fees and the HESA reporting year. In moving to in-year data, we need to understand which period the fees relate to. The most logical way of doing this is to request data for the fees charged for periods in the control of each provider, i.e. the course session. It is expected that the requirement for fee invoice data will be extended beyond the current requirement for NETFEE as it is the granular data for the derivation of the major source of tuition fees (MSTUFEE) rather than having to return it.
Please note that the InvoiceID does not refer the actual number of an invoice in your organisations accounting system. It is simply a primary key for uniquely identifying a Fee Invoice in the data model.
Why is the payments data required?
Within the current mandate, payment data will only be required for degree and higher apprenticeships in England as they are funded by the Skills Funding Agency (SFA). The SFA’s funding model requires a complete record of payments made by the employer to the provider which must be returned in the ILR (Individualised Learner Record). It is not envisaged that payment data will be required for the other administrations or cohorts of students unless a funding model is introduced that requires them.
As Fee Invoice Amount is being collected, does Fee need to be collected at all?
We must continue to collect comparable data to GROSSFEE in line with the current mandate.
NHS funded students are currently returned as zero fees, would the cost for modules need to be returned twice in S1 dependent upon the funding stream?
One course delivery can cover many funding streams and the Course Delivery Financial Support Offer can define the circumstances for zero fees. The fees for individual students will be retuned according to their own funding characteristics,
If the fees are priced per module, would gross fee be calculated as a per module sum?
This is an issue for the detailed design phase of Data Futures, but it will be possible to do so. Please note that we do not expect to see both module fess and student course session fess for the same student course session.
Would module fees need to be submitted based on home/EU/overseas prices?
Module fees will only be required where a course level fee is not supplied. The coverage and granularity of the requirements will be the same as that of the individual student course level fees.
Net fee currently includes bursary/scholarships/waivers but not necessarily at module level? How would this then need to be returned?
Bursaries, scholarships and waivers will be associated to a Student Course Session via Financial Support. They will not be apportioned to modules and the net fee will be the fee for the course session.
Will every overseas country have to be catered for in Fee Domicile?
Logically fees will be required for every overseas country at module level. However, pragmatically it is expected that categories of ‘Overseas’ and ‘EU’ will be created. The flexibility to add generic codes will cater for any new categories that arise following Brexit.
Why is Fee Domicile being collected as it can be derived from the domicile data?
Fee domicile cannot be derived from domicile data as a student may have a different domicile for fee purposes to the domicile of their physical address.
How is the level of a qualification awarded identified?
The level of the qualification is defined in the Qualification entity itself. Where this is an 'exit qualification' it will be associated with the Course Delivery to identify the course aim. The return of the ResultID in Qualification Award enables the linking to Qualification via Qualification Result, note that this can be different to the Qualification that was being aimed for in the Course Delivery. It should also be noted that whilst qualification on entry and exit awards appear as the same entity in the logical model, to acknowledge the practical difference in this data from a provider’s perspective they are being treated as separate entities in the data dictionary.
How will interim awards be recorded?
An interim award will be recorded as a Qualification award in S5, but no Leaver data will be returned. This will be associated directly to the relevant Student Course Session in which it was awarded
Why is Leaver not an ‘exit’ state of Engagement?
The student registration is the formal contract to educate, so any awards/leaving data for a course delivery relate to the registration rather than the engagement. This is aligned to the logical models definition of Leaver, being the conclusion of a registration. Note that this is broader than HESA's current use of the word, for example in respect of DLHE, which is focussed around those who have successfully completed a registration.
In the HECOS coding frame are there interdisciplinary subject codes at a lower level than the current JACS3 Y000?
The HECoS coding frame includes codes to cover multiple subjects. For example, code 100390 is general science.
Where the natural development of a course over time leads to the recoding of subjects, would it be simpler to introduce new version of the course?
If changes to the subject coding for a course materially changes the content of the course, a new version of the course should be created. However, this may not be the case where a change in subject is due to a change in the subject coding framework rather than the course itself.
Why is collaborative doctoral provision being collected to this level of detail?
In line with the current mandate to collect the data for collaborative doctoral provision, the new collection design supports the differing types of consortia arrangements such as concurrent and sequential provision, doctoral training centres and so forth.
Who will be responsible for setting up the data sharing agreements and what do they need to cover?
As part of setting up the formal collaborative arrangement, all providers in a consortium must ensure the appropriate data sharing agreement is in place. The student will need to be aware that the information needed to fulfil the data requirements for statutory returns will be shared with the partners in the consortium who are making those returns.
Will the proposed approach rely on the main contractor creating the curriculum data subcontractors to add Student registrations?
There is the flexibility to allow the main contractor to return all the data or, in the case of sequential collaboration, allow subcontractor providers to return the data for the periods of time the student is in attendance with them. Where there is no concept of a main contractor, or lead provider, within the terms of the agreement, the partners will need to agree which provider will take responsibility for returning the curriculum and registration data. If the consortium chooses to share the reporting of data for sequential collaborative provision, the main contractor will need to ensure that all subcontractors are aware of the correct ID codes to use to ensure the data is linked correctly.
How will the proposed linkage between the main and subcontractor work?
When setting up the Course Delivery, all the subcontractors are identified using Delivery Roles. The Delivery Roles can also include overseas collaborative partners and UK organisations who are not providers in the HESA constituency, e.g. major museums or industrial partners. The granularity of the data required about partners who are not in the HESA constituency will be determined by the Governance process. Depending on how bespoke the collaborative arrangements for an individual student are, there is the possibility that each student will require a separate Course Delivery. The detailed design phase of Data Futures will address how to make the data submitted by the main contractors visible to subcontractors.
How will the information on proportions of delivery and unit of assessment codes attributed to each collaborative organisation be collected?
In addition to defining course delivery roles, as part of the enrolment data the Supervisor Allocation is collected which includes the REF unit of assessment codes and proportions.
How will the responsibility of reporting the student be passed from the main contractor to a subcontractor?
When the student has completed their period of study with the main contractor, the Student Course Session will be closed, but the registration will not be ended, i.e. no Leaver return will be required unless there is an interim award. The status start date will be a record of the date of transfer to the subcontractor. On the student’s next enrolment, the subcontractor will return the Enrolment and Learning event data using the appropriate IDs to associate them to the data previously submitted by the main contractor. The detailed design phase of Data Futures will address the mechanism to enable subcontractors to link enrolments, learning events and leavers to curriculum and registration data submitted by the main contractor.
How are joint or double awards recorded?
When returning the Qualification associated with a Course Delivery, the Awarding Body Role entity enables all the awarding bodies to be identified and the relationship will identify whether it is a joint or a double award.
Will module data be required for postgraduate research?
In data language modules include research activity. Although the description states that, 'A module is a self-contained, formally structured unit of study, with a coherent and explicit set of learning outcomes and assessment criteria', paragraph 3 of the notes clarifies that, 'Where the course is a research course, there may not be formally structured units of study (or there may be units, such as research skills training, which are not the main focus of the course)’. In the Quality Assurance Agency's Doctoral Degree Characteristics Statement, section 4.1 (Progress and Review), it lays out the requirement for a formal regular progress review. It is therefore appropriate for postgraduate research students to have modules that reflect the division of the research activity linked to the formal review process. Module data that is only pertinent to taught provision will not be required for postgraduate research. This is not currently reflected in the data dictionary and will be addressed in the detailed design phase of Data Futures.
Could the ORCID be used to track postgraduate students instead of HUSID?
The model allows ORCID to be used to track postgraduate research students in the future should all the relevant parties agree.
Why are IntendedThesisTitle and ThesisTitle included in the model as there is no current mandate to collect them?
It is expected that thesis title will be required if Data Futures is to reduce the burden of multiple returns for postgraduate research. The actual mandate for collection and the final requirements will be addressed as part of the Governance process.
How will in-year/mid-course changes in fields/segments be managed?
The process for updating data for both recording in-year changes and making corrections will be defined in the detailed design phase of Futures.
Have course changes been considered for S2/S3?
This will be addressed in the detailed design phase of Data Futures. More time is required to consult with Statutory bodies, including the SLC, about their requirements when a student transfers to a different course.
For non-standard academic years, will TYPEYR need to be derived by HESA?
Whether there is a requirement to derive the equivalent of TYPEYR will be addressed in the detailed design phase of Data Futures. If it is required, the expected end date in Course Delivery will facilitate its derivation. In the cases of CPD modules where there is no expected end date, it will be possible to derive TYPEYR retrospectively.