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
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  
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  
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-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-9415 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  
  Quality rules: Fees and financial support: For providers in England, ZFEETOTSCS and StudentFinancialSupport rules use lookup data provided by OfS. These rules are currently using the data provided for 22056 and will be updated to the 23056 data once this is made available in June. Open 22 May 2024 June 2024
HDP-3648

Quality rules download all: Columns in this report are currently shifted to the left after column E so the column headers do not match the data in the columns.

Whilst we work to fix this, you can resolve it when looking at the report by selecting 'insert' and 'shift cells right' on cell E1.

Open 31 May 2024  
 

Quality rules report: Back Button on Quality Rule drill down doesn't return user to previous page. 

Update 4 June 2024: This issue has been resolved in HDP but is persisting in OVT. We are investigating to apply the same updates to OVT.

Open 8 April 2024  
 

Quality rules:

QR.STUDENT.EntryProfile.HIGHESTQOE.008.V01

QR.STUDENT.EntryProfile.HIGHESTQOE.022.V01

These quality rules are currently over triggering for qualifications that are subject to UCAS tariff.

Open 6 June 2024  
  Quality rules: QR.STUDENT.StudentInitiative.STUINITID.001.V01: This quality rule is triggering incorrectly for providers in England returning valid entry 036 'International Relocation Payment'. The enhanced coding frame this rule uses needs updating the correctly reflect this valid entry. Open 7 June 2024 June 2024
  IRIS: The IRIS outputs for providers in England have an issue with the HESES recreation document where the SCSMODE and SCSSTARTDATE are not being correctly taken into account. The OfS are aware of this issue and working on a fix. Open 14 June 2024  
HDPR-9446 Quality rules: QR.STUDENT.StudentCourseSession.ReferencePeriodStudentLoad.003.V04: This rule should only trigger where Z_STULOADSCS = 0 but is applying rounding so is triggering where Z_STULOADSCS < 0.5. Open 14 June 2024  
HDPR-9447 Quality rules: QR.STUDENT.FundingBody.FUNDINGBODY.008.V03: This rule is triggering incorrectly for providers in Scotland. It should only be applicable to providers in England, Northern Ireland and Wales. Open 14 June 2024  
HDPR-9428 Quality rules: QR.STUDENT.StudentCourseSession.ModuleInstance.006.V03: This quality rule is triggering incorrectly for large numbers of records. This has been removed from the collection whilst we resolve this. Open 18 June 2024  
HDPR-9436 Quality rules: QR.STUDENT.ETHNIC.012.V04: This rule is triggering incorrectly where the student has two Engagements, one inside coverage and one outside coverage for the field. In this scenario the field is expected to be returned. Open 20 June 2024  
HDPR-9452 Quality rules: QR.STUDENT.FundingBody.FUNDINGBODY.035.V01: This rule is triggering incorreclty where the funding body value has not changed from the previous year. The previous SCSESSIONID referred to in the rule is incorrect. Open 20 June 2024  
HDPR-9467 Quality rules: QR.STUDENT.Engagement.FEEELIG.005.V02: This rule is triggering incorrectly where FEEELIG = 01. Open 20 June 2024  
  Tariff data: Tariff related quality rules and derived fields are currently using tariff lookups from 22056. This is being updated to use 23056, some tariff point calculations will be incorrect in the meantime. Open 20 June 2024  
HDPR-9470 Quality rules: QR.STUDENT.Student.Engagement.001.V01: Where a Student has two Engagement, this rule should determine if they overlap using the ENGENDDATE where is exists or the EXPECTEDENDDATE where ENGENDDATE does not exist. The rule is currently using EXPECTEDENDDATE which may result in this over triggering where an Engagement ends earlier than expected. Open 24 June 2024  
HDPR-9471 Quality rules: QR.STUDENT.StudentCourseSession.SupervisorAllocation.007.V01: This rule is not correctly matching SCSESSIONIDs between reference periods and so is triggering incorrectly in some cases. Open 24 June 2024  
HDPR-9474 Quality rules: QR.STUDENT.Student.ETHNIC.005.V02: This rule is triggering for students who apply through UCAS but are outside of the coverage of the ETHNIC field. Open 26 June 2024  
HDPR-9473 Quality rules: QR.STUDENT.Course.TTCID.010.V03: This rule is triggering despite there being no change of TTCID between 23056 and 22056. Open 26 June 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
Quality rules report: Quality report issue status takes several minutes to update after a submission. Note: a 'processing' status will appear whilst the issue in IMS is still being updated to make it clear that an update is outstanding. Resolved 8 April 2024 30 May 2024
Quality rules: STUDENT.StudentCourseSession.PLACEMENT.008.V01: This quality rule is triggering incorrectly in some cases where a StudentCourseSession spans reference periods. Resolved 16 April 2024 30 May 2024
Quality rules: STUDENT.StudentAccreditationAim.STUACCID.004.V01: This rule is triggering incorrectly due to not correctly picking up the accreditation information for associated courses. Resolved 16 April 2024 30 May 2024
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. Resolved 8 April 2024 11 June 2024
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. Resolved 24 April 2024 11 June 2024
Quality rules: STUDENT.Engagement.STUDYINTENTION.002.V01: This rule is triggering incorrectly where Engagement.STUDYINTENTION = L0003 or L0000 Resolved 24 April 2024 11 June 2024
Quality rules: STUDENT.EntryQualificationAward.QUALYEAR.017.V02: This rule is triggering incorrectly in some cases where the student is 16. Resolved 26 April 2024 11 June 2024
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. Resolved 3 May 2024 11 June 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.

Resolved 7 May 2024 11 June 2024
Quality rules: STUDENT.StudentCourseSession.ZFEETOTSCS.029.V01: This quality rule is triggering incorrectly in some cases where there is a fee specified by OfS but the rule display indicated a maximum fee of 0. Resolved 9 May 2024 11 June 2024
Schema: The schema in HDP and OVT is currently version 1.3.0. The latest published schema (1.4.0) has not yet been implemented in the system. The only change in schema 1.4.0 is the addition of valid entry 42 in the EntryQualificationAward.QUALTYPEID field. Resolved 4 June 2024 11 June 2024
Release ID Release date Release summary
27 20 June 2024

Quality rules

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

The STUDENT.SessionYear.SYENDDATE.002.V02 quality rule has been removed as it is no longer required.

Other updates

  • The Expected Engagement population is now available in the additional collection reports. This report shows the Engagements that would be expected to be submitted in the 24056 collection.
26 11 June 2024

Quality rules

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

Other updates

  • The schema in HDP and OVT has been updated to version 1.4.0 to align with the latest coding manual.
  • An issue with the EYTS1 credibility table failing to generate has been resolved.

 

25.1 31 May 2024 IRIS files are now available for providers in England. A new file will need to be submitted to the HDP for the file to be generated.
25 29 May 2024

Quality rules

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

The following quality rules have been removed as they are no longer required:

  • STUDENT.StudentCourseSession.SupervisorAllocation.008.V01
  • STUDENT.Course.PREREQUISITE.003.V02
  • STUDENT.StudentCourseSession.INVOICEFEEAMOUNT.003.V01

Derived fields

The Z_EXPECTO derived fields have been updated to use historic data for continuing Engagements. This could not be done in 22056 due to the nature of migrated data.

Other updates

Navigation has been improved in the quality assurance section so that filters and table options persist when the back button is used.

 

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
  • IRIS report for providers in England*

June

  • Cost centre analysis report
  • OVT and HDP updated to schema 1.4.0
  • Fees and financial support data lookups updated to 23056 data. Associated rules are currently using the 22056 data until 23056 is made available
  • Expected Engagement Population 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 Scotland once confirmed by SFC.

 

Quality rule updates

The 23056 high priority rule amendments.xlsx spreadsheet shows a list of quality rule updates we plan to make for the 23056 collection. These are based on feedback from providers and statutory customers, rule reviews undertaken post 22056, and updates following the 23056 Notification of Changes.

The document indicates which rules are new or an amendment. Where a rule is indicated as 'new' it means it is not currently in the 23056 collection but will be added. This includes some rules that were deferred from 22056 and some rules that were in 22056 but required updates based on 23056 changes and so were removed until these updates were made.

Please note that there may be further rule amendments and/or bug fixes for 23056. This may be due to issues being raised during the collection or lower priority updates being made. Based on feedback from providers, we propose to freeze implementation of additional quality rules beyond July, excluding in exceptional circumstances. Lower priority updates may therefore be made for 23056 depending on what can be completed in this timescale.

Please see the release history for information on which rules have been added or updated in each release.

 

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

Student record 23056 Masterclass recordings

HESA Website Navigation and Additional Resources: This masterclass explores key resources that will guide you through the Student Record 23056 data return. Explore coding manuals, support guides, and e-learning modules, ideal for new staff or those seeking resource optimisation

HESA Website Navigation and Additional Resources

Dormancy Guidance and Scenarios: This masterclass covers the significance of the SessionStatus entity in the Student Record and will aid you to gain proficiency in recording different Dormancy scenarios.   

Dormancy Guidance and Scenarios

StudentCourseSession & SessionYear Guidance and Scenarios: This masterclass delves into StudentCourseSession and SessionYear entities to gain insights into their distinct purposes and the link between them. We looked at various scenarios to gain insight into the application of these entities.

StudentCourseSession & SessionYear Guidance and Scenarios

August Interim Submission Requirements: In this masterclass we aim to understand the rationale behind the August interim submission and to gain clarity on the data collection schedule, deadlines, and milestones to ensure confidence in the submission process. 

August Interim Submission Requirements

Guidance and Support on Tolerances: In this masterclass we look to gain insight into rolling tolerances and how to effectively raise tolerance overrides. We hope this masterclass can aid providers to navigate through potential discrepancies with confidence and accuracy while understanding upcoming changes to credibility.   

Guidance and Support on Tolerances

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.