Skip to main content

23056 Support guides

Our expert analysts have a thorough understanding of our records and processes. We are here to support you throughout the data submission process.

Contact Liaison by email or on +44 (0)1242 388 531 

Find out more about Liaison

Student overview

We collect data across a number of streams. These streams focus on different aspects of higher education.

The Student stream collects data about students studying at higher education providers in the UK. Details of which students need to be returned to us are included in the Coverage document found in the Coding manual.

The data we collect on behalf of the sector is provided to governments and fundng bodies in order to support the regulation of higher education. We also make anonymised data available to the public to enhance understanding of UK higher education and to support its advancement

Our coding manuals provide you with all the necessary documentation to support your data return. The coding manual contains technical documents giving detailed information on the record's coverage, data specification and submission formats. Familiarising yourself with these documents will help you make an accurate and timely return.

Each collection has its own coding manual which can be found in the Data collection section of our site. By default, you will land on the open collection for each record; you can then select previous or future years.

The coding manuals will be updated throughout the data collection cycle and Record Contacts informed by email when new versions are made live. Be sure to check the manual's Revision history for a summary of changes.

You will submit data via the HESA data platform. To access this, you will need to have an appropriate role in our Identity System (IDS). We publish an IDS user guide which includes information on creating and editing your account.

You will need to be given access to the Hesa Data Platform by the relevant Record Contact at your provider.

Once you have access to the system you will be able to upload files and track the progress of the collection.

The coding manual homepage includes all the technical information you require, including:

  • The data specification.
  • File format specifications.
  • A detailed collection schedule.
  • Our XML data entry tool.
  • Quality rules.

This Support guides page collects together the following resources:

  • User guide.
  • HESA data platform: Known issues and release history - to be added

In the Support area of the HESA website, you can find:

Our Data innovation section includes information about:

  • Open and recently completed record reviews, including information about changes we are implementing
  • More information on the Data Futures programme.

In the About section, you can find:

 

Our expert analysts have a thorough understanding of our records and processes. We are here to support you throughout the data submission process.

Contact Liaison by email or on +44 (0)1242 388531 

Find out more about Liaison

A Reference period is a fixed period of time, the end of which, aligns to when HESA’s statutory and public purpose customers require sector-wide data and information. The diagram below summarises the structure of a Reference period:

Key concepts what is a reference period

Key terms relating to a Reference period:

Sign-off: The process of a defined role (for example Vice Chancellor) making a formal declaration that the data submitted to HESA for a given collection represents an honest, impartial, and rigorous account of the HE provider’s events up to the end of the reference period. 

Dissemination point: The specified date, after the end of a Reference period, by which signed-off data will be extracted and supplied to HESA's data customers. Data disseminated at the Dissemination point will be used for official accounts of the higher education provider’s activity for statistical, regulatory, and public information purposes.

 

Technical Population: Controls what records are included in the rule.
Technical Validity: Identities which records within the population should trigger the rule.

Valid or Invalid rules:
Invalid = the rule will trigger if the technical validity statement is true. I.e. not expecting this.
Valid = the rule will trigger if the technical validity statement is false. I.e. this is what we are expecting, and anything outside of this will be flagged.

Please follow these steps in cases where Excel is not displaying SID values correctly:

  1. Ensure the file has not been opened in Excel before,
    • If the file has been previously opened, it should be deleted and downloaded again
    • Once a file is opened in Excel, the application adds the trailing zeros and the correct SID value is lost
  2. Open the file in a different application e.g. Google Sheets,
  3. Format the column to Number,
  4. Choose an option to Download/Export to Excel,
  5. Open the file in Excel,
  6. Save the file.

Ensuring the format of the column is set to Number and the decimal places are reduced to zero should correctly show the SID values.

Following feedback from the Student seminars for more immediate communications, we are introducing two new Student related JISCMail lists.  

HESA Student - system updates

We have created the ‘HESA Student - system updates’ mailing list for Liaison to keep providers updated, with information relating to the Student collection. This will include information on known issues, releases and reprocessing. This is an announcement list, so only Liaison will be able to send messages to the list.

Join the HESA Student - system updates JiscMail list

HESA Student - discussion forum

We have also created the ‘HESA Student – discussion forum’ for providers to discuss the Student collection with each other. Liaison will be monitoring the mailing list.

Join the HESA Student - discussion forum JiscMail list

Please do keep in mind the below points when using this mailing list: 

  • If you have a specific query for your provider then please email Liaison, do not post to JISCMail. 
  • Please do not post any personal information on the mailing list and follow GDPR principals. 
  • The introduction of this JISCMail list is on a trial basis for the remainder of 23056.  
  • Please use the ADMIN-HESA mailing list when posting any job adverts. 

JISCMail lists are optional mailing lists that you can sign-up to if you want to receive these updates.

We will continue to provide Student collection updates via the weekly update.

HESA Data Platform (HDP)

Open issues:

ID Issue Summary Status Date raised Expected release date
HDP-2652 Quality rules report: Back Button on Quality Rule drill down doesn't return user to previous page.  Open 8 April 2024  
HDP-2576 Quality rules report: Quality report issue status takes several minutes to update after a submission. Open 8 April 2024 May 2024
HDPR-9272

Derived fields: Z_TARIFF: This derivation is being set to 0 in some cases where there are entry qualifications with valid points.

Update 17/05/2023: This derived field is deriving incorrectly for QUALTYPEIDs that are a length of 5.

Open 8 April 2024 May 2024
HDPR-9090 Quality rules: STUDENT.StudentCourseSession.NUMHUS.006.V01: This rule is triggering incorrectly in some cases where an EntryProfile exists or where a student has multiple Engagements. Students will an EntryProfile should be outside the population for this rule. Open 8 April 2024  
HDPR-9253 Quality rules report: The URLs in the quality rules report are currently linking to the 22056 coding manual. The latest 23056 coding manual should be referred to for 23056 guidance. Open 11 April 2024 May 2024
HDPR-9273 Quality rules: STUDENT.StudentCourseSession.PLACEMENT.008.V01: This quality rule is triggering incorrectly in some cases where a StudentCourseSession spans reference periods. Open 16 April 2024  
HDPR-9294 Quality rules: STUDENT.StudentCourseSession.YEARPRG.009.V04: This quality rule is triggering incorrectly where the same SCSESSIONID is submitted in the current and previous reference period with the same ID. Open 24 April 2024  
HDPR-9297 Quality rules: STUDENT.Engagement.STUDYINTENTION.002.V01: This rule is triggering incorrectly where Engagement.STUDYINTENTION = L0003 or L0000 Open 24 April 2024  
HDPR-8067 Quality rules: STUDENT.EntryQualificationAward.QUALYEAR.017.V02: This rule is triggering incorrectly in some cases where the student is 16. Open 26 April 2024  
HDPR-9315 Quality rules: STUDENT.EntryProfile.EntryQualificationAward.003.V03 and STUDENT.EntryProfile.EntryQualificationAward.002.V04: These rules are sometimes triggering incorrectly where an Engagement does not have a level 3 qualification as the highest qualification on entry. Open 29 April 2024  
HDPR-9316 Quality rules: STUDENT.StudentCourseSession.ModuleInstance.006.V02: This rule is triggering incorrectly as it is not accurately identifying the number of ModuleInstances associated with a StudentCourseSession in the previous reference period. Open 3 May 2024  
 

Quality rules:

STUDENT.StudentCourseSession.SCSSTARTDATE.006.V01:

STUDENT.StudentCourseSession.SESSIONYEARID.002.V01

STUDENT.StudentCourseSession.SCSMODE.007.V03

STUDENT.StudentCourseSession.PHDSUB.011.V01

These quality rules are linking to previous StudentCourseSessions with a different ID so are triggering incorrectly.

Open 7 May 2024  
HDPR-8177

Credibility reports: HCC1: This report is currently overcounting FTE in some cases.

This report has the same popultion as the CCAnalysis report so we recommend providers review FTE data in this additional collection report.

Open 9 May 2024  
HDPR-8461

Credibility reports: FTE: The FTE credibility reports are being reviewed for 23056 related to the following points:

  • Where providers have returned FTE data for the previous reference periods, this is being included in the average FTE calculations for the FTE reports when it should be excluded.
  • Due to changes in the way writing-up students are returned, they are now included in the active student count for PGR and are therefore included in the FTE tables. Where a provider has a significant proportion of students that are writing up this may bring the average FTE below the threshold for the rules in the tables.
Open 9 May 2024  
HDPR-9332 Quality rules: STUDENT.CollaborativeProvision.COLPROVTYPEID.002.V01: This quality rule is triggering incorrectly in some cases where the Engagement existed in 22056 and 21056. Open 9 May 2024  
HDPR-9335 Quality rules: STUDENT.StudentCourseSession.ZFEETOTSCS.029.V01: This quality rule is triggering incorrectly in some cases where their is a fee specified by OfS but the rule display indicated a maximum fee of 0. Open 9 May 2024  
HDPR-9364 Quality rules: STUDENT.StudentAccreditationAim.STUACCID.004.V01: This rule is triggering incorrectly due to not correctly picking up the accreditation information for associated courses. Open 16 May 2024  
  Derived fields: DerivedSubject: This derived field is failing to generate in some cases. This is being investigated and more detail will be added once known. This will result in the SBJ1 credibility table not populating. Open 17 May 2024  

Resolved issues:

Issue summary

Status

Date raised

Date resolved

Derived fields: Z_STULOADSCS: This derivation requires an update to correctly assign FTE for the 23056 collection. A number of validation rules use this derivation and so will trigger incorrectly until this is updated.

Resolved

12 February 2024 16 April 2024
Derived fields: Z_MODACTFROM/TO: These are not correctly reflecting module dates in some cases. This impacts the Z_CCFTE_CYC and Z_CCFTESCSEND_CYC derivations. Resolved 8 April 2024 16 April 2024
OVT: Search feature in the Quality Rules report - the search feature is not working when you enter a search term and then select the "search" icon. Entering the search term and then pressing enter will correctly filter the list of quality rules. Resolved 8 April 2024 16 April 2024
Quality rules report: Quality rules details sometimes fail to download when the rule is failing for a large number of records. The download all functionality can be used to download details for each quality rule. Resolved 8 April 2024 3 May 2024
Schema error report: In some cases the schema errors are not providing the IDs for the records failing schema. Resolved 9 May 2024 15 May 2024
Release ID Release date Release summary
24 15 May 2024

Quality rules

There have been a number of updates to quality rules, the full list can be seen in the Release 24 quality rules.xlsx spreadsheet.

Derived fields

The following derived fields has been updated:

  • Z_POPSR_CYC-this derived field has been updated to remove the dependency on Z_STATUSSCS_CYC as this is covered by other exclusions.
  • Z_QAWARDGMRK_CYC, Z_QAWARDHMRK_CYC, Z_QAWARDHMRK_RP- these derived fields have been updated to use historic data to deduplicate qualifications. This could not be done in 22056 due to the nature of migrated data.
  • Z_CCFTE_CYC and Z_CCFTESCSEND_CYC- this was previously calculating incorrectly where ModuleInstances spanned reference periods. This has been resolved.
23.5 09 May 2024

The HESA Data Platform (HDP) is now available for submissions. The Online Validation Tool (OVT) is still available and can be used for testing files against quality rules before a full submission is made to HDP.

HDP has the following additional functionality now available:

  • TSV enriched file.
  • First release of credibility reports.
  • Frequency counts report.
  • PGR transfers in and out report
  • The ability to request tolerances for quality rules in the Issue Management System (IMS). Guidance on this process can be found in the IMS user guide. For reference you will be able to view last year's comments and tolerance requests in issues triggering for 23056 in the Issue Management System (IMS), to help aid you in responding to rule failures.

Please see the upcoming releases section below for information on when further functionality will be available.

22/23 30 April 2024

Quality rules

There have been a number of updates to quality rules, the full list can be seen in the Release 23 quality rules.xlsx spreadsheet.

Other updates

  • The schema has been updated to align with the 1.3.0 coding manual.

 

20/21 16 April 2024

Quality rules

There have been a number of updates to quality rules, the full list can be seen in the Release 21 quality rules.xlsx spreadsheet.

Derived fields

Updates have been made to the following derived fields:

  • Z_MODACTFROM/TO- these dates were previoulsy deriving incorrectly in some cases, this has been resolved. This impacts the DerivedEngagementCostCentre values.
  • Z_CARELEAVER_EP/Z_RELIGIOUSBGROUND_EP- these derivations were failing to generate in some cases. This issue has been resolved.
  • Z_PRINONUK- this has been updated to reflect the new Engagement.ENGPRINONUK field added to replace StudyLocation.PRINONUK in 23056.
  • Z_STULOADSCS- this has been updated to use historic FTE data where a StudentCourseSession started in a previous reference period. This was not done in 22056 due to the migrated data not having reliable FTE by StudentCourseSession.

 

 

19 08 March 2024

 

Quality rules

There have been a number of updates to quality rules, the full list can be seen in the Release 19 quality rules.xlsx spreadsheet.

Derived fields

An update has been made to the Z_ENTQUALAGRP1/2 derived fields to resolve an issue with some invalid grades being included.

Other updates

Updates have been made to the quality rules download all report to include a status column indicating whether the rule is inside or outside tolerance and remove duplication in columns.

18 20 February 2024

 

Quality rules

The following quality rules have been added following resolution of known issues.

  • STUDENT.Student.SERLEAVE.001.V03
  • STUDENT.Student.SERLEAVE.006.V03
  • STUDENT.Student.SERSTU.001.V03
  • STUDENT.Student.SERSTU.004.V03
  • STUDENT.Student.SERSTU.006.V02

 

16 31 January 2024

The Online Validation Tool (OVT) for 23056 is now available for provider submissions. Information on the OVT can be found in the OVT User Guide.

This contains rolled on quality rules and derived fields from 22056 and these will be updated iteratively for 23056 in future releases.

 

A high-level summary of the 23056 major external component releases is highlighted below.

This summary shows the features scheduled for release by month and may be subject to change.

 

January

  • Online Validation Tool (OVT) with rolled on rules and derived fields from 22056. Updates to quality rules and derived fields will be released to the OVT iteratively from this point to the end of July.

     

April

  • OVT updated to schema version 1.3.0.

May

  • HESA Data Platform (HDP) opens- week commencing 06/05
  • First release of credibility reports. Updates to quality rules, derived fields and credibility reports will be released to the HDP iteratively from this point to the end of July.
  • Frequency counts report
  • PGR transfers report
  • TSV enriched file
  • Expected Engagement Population report

June

  • Cost centre analysis report

July

  • Finalised quality rules, derived fields and credibility reports. We propose to freeze implementation of additional quality rules, derived fields and credibility reports beyond July, excluding in exceptional circumstances. From August onwards we will continue to address bugs that arise through collection.

     

August

  • Auto raising of issues in Issue Management System
  • NSS report*
  • IRIS report for providers in Wales*
  • Interim submissions to HDP

*The release dates of the IRIS reports for the different administrations and the NSS reports are subject to change. We will reflect any change to the proposed dates in the schedule. We will add to this schedule with the proposed dates for IRIS for providers in England and Scotland once confirmed by OfS and SFC.

 

We have completed our post collection tolerance review of 22056 to identify where rules need to be amended for future collections.

Following this we have prioritised all outstanding rules updates that have been identified. This has been shared with Statutory Customers and once the prioritisation is agreed we will share a list of high priority rule updates we expect to implement for 23056. Lower priority changes will remain on the backlog to be considered for future collections.

 

Data Entry Tool

The majority of HESA collections are submitted in XML format.  

The Data Entry Tool is a piece of software that allows users to input the data they have collected, and if necessary, amend an existing XML data file. The tool has been created by HESA to allow users to produce XML data in the format required for their submission.   

The Data Entry Tool for the HESA Data Platform is currently available to download from the 23056 coding manual on the HESA website. 

We recommend you run it on a machine with the minimum specification of a 64-bit processor. The kit was developed using Microsoft's .Net Framework 4.8, so your computer should meet the minimum specifications published by Microsoft. 

The Data Entry Tool has been updated to be compatible with the Student - Data Futures schema. The Data Entry tool can be used to validate multiple schemas. This includes the 22056 and 23056 Student records.   

You will first need to load the relevant schema you wish to submit data to. 

The schema to be used, for the 23056 and 22056 Student collections, can be added into the Data Entry Tool:

1. Download the schema from the coding manual and save it locally.

2. Click on ‘Schema’ in the Data Entry Tool and the ‘Add Existing Schema File’.

Adding schema to data entry tool

 

3.    Select the schema that you've just saved.
4.    This should then appear as an option in the Active schema list.

Selecting correct schema

Top tip: It is important to select the correct and most up-to date schema for the collection being worked on. Check the revision history of the specific collection for the date of the release of the XSD.  It is good practice to keep a check on any updates, so you are not using an old schema

Note: The Data Entry Tool can be used for the 23056 and 22056 Student collections, so it is important to select the relevant collection.

Online Validation Tool (OVT) (23056)

What is the Online Validation Tool?
The Online Validation Tool (OVT) is a separate area within the HESA Data Platform which will enable providers to test their data ahead of the data submission period.
The OVT replaces the offline validation toolkit for the Student - Data Futures 2022/23 collection onwards.  Providers will be able to test and quality assure their files ahead of making a full submission to a live collection on the HESA Date Platform (HDP). 

The OVT user guide is available in the Support section of the HESA website. This guide includes details on:
•    Roles required to access the OVT
•    Logging into the OVT
•    Uploading a file to the OVT
•    File processing
•    Accessing the quality report

A comparison between the OVT and the Validation kit:

OVT Validation kit
Used to test data ahead of submission. Used to test data ahead of submission.
Available online as part of the HESA Data Platform. Downloadable from the collection coding manuals.
Increased validation included, for example historic checks. Less validation, historic checks not included.
Includes feature to download all issues. Results can be saved but not downloaded.
Working online, so providers can ask the Liaison team to view the data if support is needed. Working offline, so the Liaison team is unable to see the data.
More secure as held with other data. Downloaded so may not be as secure.

 

Data Specification

We recently attended the Student Record Officers Conference in Leeds.

We presented two sessions at the conference.

Breakout 3: Upcoming student record changes and StudentCourseSession/SessionYear

Below you can find a copy of the slides and responses to questions asked during the session. Some of these questions were answered on the day but have been included so they are available to all providers

SROC 2024 Breakout 3.pptx

Question Response
Is the Engagement.ENGPRINONUK field returned where there a student spends half of their time in the UK and half outside the UK? The Engagement.ENGPRINONUK field is defined as being returned where the student will spend the majority of their Engagement outside the UK. If half of the Engagement was outside the UK, this would therefore not be returned.
Why are there two valid entries for the Artificial Intelligence and Data Science postgraduate conversion programme initiative?

These valid entries are different between the two fields and have different labels:

  • CourseInitiative.COURSEINITID: 031 'Artificial Intelligence and Data Science postgraduate conversion course scholarship programme'. This records courses that are part of the programme.
  • StudentInitiative.STUINITID: 034 'Artificial Intelligence and Data Science postgraduate conversion course scholarship'. This records students that are in reciept of the scholarship.
Will you be going back to the errors and warnings approach to quality rules from previous student collections?

We are not planning on returning to the concept of errors and warning.

Providers have fed back that this was helpful for prioritisation of outstanding issues. We have now updated the quality rules webpage with information on the tolerance approvers for each rule. This defines whether the a tolerance request for a rule would be approved by the provider, HESA or Statutory Customer. The aim is that this would assist with prioritisation of outstanding rules. The proivder approved rules would be the most similar to 'warnings' from previous student collections. Guidance on engaging with this information can be found in the validation overview page.

Will you be running continuity rules in 23056? We expect many providers will be resolving issues found in 22056 data so may trigger continuity rules. We will be running continuity rules in 23056. The exact nature of these will depend on the field and the quality rules webpage should be referred to for details. If you become aware of issues with previously signed off data, this should be raised with your regulator/funder. If this is data that needs to be resubmitted in 23056, for example if it relates to StudentCourseSessions spanning reference periods, this should be corrected in 22056. If this results in continuity rules, a tolerance should be requested.
Why are we required to return all StudentCourseSession sub-entities such as ModuleInstance in the final reference period a StudentCourseSession spans? This guidance was agreed in order to allow corrections to e.g. ModuleInstances that were previously submitted in error. We have had feedback on this area from providers so the guidance is under review. This guidance applies to the ModuleInstance, SessionStatus and OffVenueActivity entities and remains in place for 23056.
What continuity checks will be in place in 23056 for data that may have genuinely changed between reference periods? The validation in place will depend upon the specific field/entity that has been updated, the quality rules webpage should be referred to for details.
Related to the dormant leavers scenario on slide 22, if students are just handing in assessments or resitting exams in the second reference period, are they considered dormant?

Yes, resubmitting assessments is not counted as activity so if no other activity was undertaken, the student would be considered dormant.

 

Would dormant students fall into the Graduate Outcomes population? In most cases, no. The exception to this is postgradaute research students who are awarded from a dormant status.
Related to the postgraduate research dormancy example on slides 25-28, what is the relationship between the StudentCourseSessions and year of programme? This is challenging to return when the two are not lining up, particularly when the students have multiple short periods of dormancy. The updated guidance for postgraduate research students is designed to give greater flexibility for providers to return StudentCourseSessions more in line with the study years they hold internally. Some additional PGR related scenarios have been added to the dormancy guidance document- please see students 8, 9 and 10. The dates here are examples, so they may not line up with how your system is set up internally but the principle is to allow shorter StudentCourseSessions in some cases where this would reflect the internal study years. If you have specific examples you would like to discuss, please get in touch with the liaison team.
Related to the thick sandwich example on slides 28-29, can this guidance also be applied to students on a full study year abroad? Yes, we have raised this with Statutory Customers who have agreed the same guidance can apply. We will update the relevant guidance in the coding manual to reflect this.
What is the purpose of StudentCourseSession/SessionYear?

The concept of 12 month years of study is required for definitions in certain fields e.g. mode or FTE. The guidance around StudentCourseSession therefore aims to enforce this 12 month period. SessionYears record the planned start date for a course year and so give context to the associated StudentCourseSessions. E.g. allows identification of when a student starts a course year late or where they move between different cohorts. This allows greater flexibility in the return of StudentCourseSessions rather than having to enforce a 12 month StudentCourseSession in all cases where this may not be appropriate.

We have recieved feedback that the justification and use of these entities has not been articulated sufficiently. This is an area we will be consulting on and as part of that we are working with Statutory Customers to be clearer about the use cases.

 

Why do we have to send a new StudentCourseSession to report a student has gone dormant where there is no activity to report? Why can't we return the previous StudentCourseSession again? This is an area where we have had feedback form providers and so is under review. This guidance remains in place for 23056.
What if we returned a StudentCourseSession in 22056 that should have had an SCSENDDATE but this was not returned? Can we return thie previous StudentCourseSession again to report the end date? Yes, the StudentCourseSession can be returned again with the SCSENDDATE updated. We would not expect other data against the StudentCourseSession to change in this scenario.
Could SessionYears be derived? We do not think this would be possible. StudentCourseSessions record the dates the student starts and finishes on a course year and so do not align with the planned course start dates in many cases.
If any changes are made to the data model for 24056, will you ensure you consider timelines for providers and software suppliers so any changes can be implemented? As part of the upcoming consultation we have included questions asking for feedback on the proposed changes and on the proposed timelines for these changes. We will consider the responses when making decisions with Stautory Customers on any changes.

As part of this session our Data Management team also gave an overview of the improvements they have been making to the coding manual and associated tools. The new look 23056 coding manual has now been published and incorporates feedback from providers, such as improvements to the derived field specifications and quality rules webpage. We welcome any feedback on this, please get in touch with [email protected] if you have any feedback to share.

 

Breakout 4: AOR major review

Below you can find a copy of the slides from breakout 4. Work on upcoming changes to the Aggregate Offshore and Student record for TNE students is continuing. Further information will be communicated this Summer.

SROC 2024 Breakout 4.pptx

Submission stages on the HESA Data Platform (HDP)

From the ‘Manage Submissions’ page you can either upload a file or display the previous files that have been uploaded. Once ‘upload file’ has been selected it will take you to the ‘Upload’ stage. 

 

The ‘Upload’ stage is where a file can be uploaded to the HESA Data Platform (HDP). Here you will have the option to either use the ‘drag and drop’ or select a file to upload.  

The ‘Upload’ cog of the progress tracker will  display a green tick when this is complete. If a file fails to upload it will not be logged as an attempted upload in the HDP activity log. Failure may be caused due to a loss of connection to the HDP. If a file fails to upload then the same file can be uploaded again. 

Tips: 

  • Files can have any name 
  • Files must be in XML and conform to the relevant XML Schema Definition (XSD) file 

Once uploaded, the file will begin processing and will go through the following stages: 

The processing screen will show the status of the processing of your submission as it moves through the various stages.

  • A green tick will appear next to each section once that specific check has been completed
  • Checks that have not yet been completed will have an hourglass symbol against them
  • Checks that have failed (such as the schema check) will have a red ‘X’ against them

Please note that the time taken by the system to process a data file will depend on both the size of the file and the number of errors that need to be reported.

The schema checks ensure that your file meets the schema specification. If your file does not meet the schema specification, then no further checks will be made against your file and a red 'X' (as mentioned above) will appear. An additional report will be generated, displaying all relevant schema errors. This report can also be downloaded from this screen. The next section – enrichment – is where the derived fields are created. A downloadable file will be made available, which includes both the submitted data and derived fields.

 

Within the ‘Quality assurance’ section the quality and credibility reports will be displayed, along with any additional reports.  

Image of the quality reports available in the HDP

The Quality report will contain the details of any rules triggered by the submission. To pass validation all quality rules need to be within tolerance or be resolved through amending the file. When a new file needs to be uploaded please navigate to the ‘Manage submissions’ menu. Requests for changes to tolerances and thresholds are to be raised as an issue and are managed in the Issue Management System. 

Further details on the quality rules which apply to this collection can be found in the coding manual

The Credibility reports section provides an overview of the data submitted. The tables are broken down into chapters such as ‘Student instance profile’ and will look at year-on-year differences between your data.  

Additional reports will include IRIS, PGR Transfers In/Out.  

What is different?

Previously, you could request a switch for errors by contacting Liaison.

From the Student 2022/23 collection, this is all handled by the HDP and you will no longer contact Liaison for a switch.

Please raise all quality issues in the IMS and request a tolerance override within the issue. These issues will either be self-approved by the provider, or approved by HESA or the relevant Statutory Customer.

This means that rules that were previously warnings will also be dealt with in the same way, and a tolerance override will need to be requested. 

How to raise a tolerance override request

Please raise tolerance override requests for issues that are triggering for a genuine reason. More details are available in the IMS user guide.

1 - In the HDP ‘Create issue’ for the relevant rule by selecting the three dots under 'Issue status' then 'Create issue'. This will automatically create an issue in the IMS. Only request a tolerance override when the issue is triggering for the total number of records expected. Otherwise, you will need to request the tolerance again when it triggers for more records. Tolerances should not be requested for quality rules that are known issues. The known issues log can be found by clicking on the support guides for the relevant collection on the Data Collection page. If the rule is on the known issues page, please disregard the rule for the time being. We will update the page once it is resolved. If a quality rule is not listed as a known issue please contact [email protected].

Image of how a quality rule is displayedImage of how to create an issue for IMS

2 - Within the issue select the ‘Request Override’ button.

 

3 - Make sure you enter a value for the number of records the rule is triggering for. This will be the tolerance that you want to apply to this rule: if it is triggering for 33.33% of records, the tolerance override value will be 33.33%. The tolerance override box must be filled in before the request can be reviewed.

In some cases it may be appropriate to request a tolerance as a higher count or percentage than is currently triggering the rule. This may be in the case where it is expected that the records triggering a rule will increase. If you are requesting a tolerance at a higher level that is currently triggering, please include information in your request as to why this is. This will then be considered by your Statutory Customer or HESA when approving the tolerance. This may not be approved in all cases, for example high priority rules where any increase in numbers would need to be confirmed.

4 - Provide a supporting explanation for why this data is genuine.

5 - The tolerance request will go to the relevant approver for that rule, e.g. HESA or a Statutory Customer.

6 - If the tolerance override is approved the query will be archived and the provider will receive a notification. If it is a provider-approved rule, the query will be archived.

7 - Once a tolerance override is approved, please resubmit the file for the rule to move inside tolerance, or Liaison can re-process your most recent file upon request.

8 - If the tolerance is declined, then a comment will be added to explain why and the issue will be assigned back to the provider.

The Issue Management System can be accessed here: https://issuemanagement.hesa.ac.uk/

All quality issues will need to be resolved, either by an amendment in tolerance or correction to the data to progress to the final ‘Approval & sign-off’ stage.

Rolling tolerances

When your Statutory Customer or HESA is reviewing a tolerance request, this can be applied to multiple reference periods if applicable. When applying for a tolerance, please indicate if the tolerance should apply to multiple reference periods. This is done on the basis of a count of reference periods. So a tolerance applied in 23056 with a rolling tolerance of 1 would apply to the 23056 and 24056 reference periods.

IMS best practice tips

1 - Check the known issues page if a rule isn’t working as expected before requesting a tolerance override. The known issues log can be found by clicking on the support guides for the relevant collection on the Data Collection page. If the rule is on the known issues page, please disregard the rule for the time being. We will update the page once it is resolved. If a quality rule is not listed as a known issue please contact [email protected]

2 - You don’t need to request a decommit. If you have changes then you can upload a new file to the HDP. This will update any open IMS queries that you have.

3 - Complete the Data Futures Quality Assurance e-learning to supplement your understanding.

4 - If you plan to upload a new file to fix an issue, you don’t need to add a comment. However, you could mark it as ‘awaiting resubmission’.

Once all issues in the Issue Management System (IMS) have been resolved and the reference period has ended, the data can be submitted for approval within the submit section of the HESA Data Platform (HDP).

Users will need the 'Provider HDP Sign Off - Student' role within the HESA Identity System in order to submit for approval.

Once you have submitted the file for approval, you will not be able to submit another file to HDP unless the submission is not approved by HESA or the OfS (for English providers). If you need to upload a new file to HDP after submitting for approval, please contact Liaison.

HESA and the OfS (for English providers) will then confirm that your most recent submission can progress to sign-off. An email will be sent to users with the HDP submitter role in the HESA Identity System (IDS) once the sign-off form is available.

Section C of the sign-off form allows providers to include any comments about their data. This should only be used to make us aware of any specific issues with your data and the information will be shared with relevant parties to help inform analysis of the data. Whilst the provisions of Clause 2.9 of the providers subscription agreement continue to apply generally, given the above circumstances, if you would like to provide any feedback on the collection, then we ask that this is either sent to Liaison or your regulator/funder.

Your data will need to be signed off by your Accountable Officer/Head of Provider.