Skip to main content

Student Alternative student record 2020/21 - File structure and entity overview

Back to C20054

File structure and entity overview

Version 1.1 Produced 2021-01-06

Data format

Data must be returned to HESA as an XML file. XML is the eXtensible Markup Language and is a W3C recommendation. There are many XML training resources on the web, including the W3C Tutorial on XML and the resources of W3Schools.

Files must be encoded with UTF-8 and schema validation will be in place to ensure this. Institutions must specify the encoding used in their XML files in the first line of the file (i.e. <?xml version="1.0" encoding="UTF-8" ?>) and to ensure that their files are actually saved with that encoding. If XML files are edited with some text editors and the encoding is not specified or does not match the actual file encoding, there may be problems when submitting these files for validation.

Ordering of attributes for submission

Within an XML file structure, data items with similar properties are grouped into entities and sub-entities. These groups have a number of inter dependencies and their relationships can be referred to as 'nesting'. The diagram below is based on the File structure for the Student Alternative record and shows how the nesting works in practice:

Entity diagram - AP student record

The order in which entities and fields should be submitted is governed by the C20054.xsd file, which is ordered according to the following principles:

  • Entities are presented in parent-child order, starting with the 'Provider' entity.
  • Fields within entities are presented in the order of primary key fields, candidate key fields, foreign key fields, and non-key fields.
  • Child entities then follow.

Each field or entity within a parent entity is presented in alphabetical order to aid their location.

The physical file structure to be returned to HESA is based on the logical data model but with either repeating elements or specific field requirements expressed separately. The file structure is designed to be future-proof in that it will support incremental submission of data throughout a reporting period with only minimal change: the separation out of data items is designed to allow this.

The elements are:

Logical data model concept Entity Sub-entity Description
CourseCourseCourse SubjectA HECoS subject code and a proportion indicator
CourseDeliveryOrganisationAndLocationData about the organisation(s) delivering the course if they are not the reporting provider
StudentStudentStudentEqualityData items which are required for monitoring equality
Student-Course engagementStudentEntryProfileData items which relate to the student at the outset of their engagement with a course
EntryProfileQualificationsOnEntryQualifications held at the outset of the engagement, returnable many times
StudentInstanceData items which relate to the entirety of an instance of engagement between student and course
InstanceFinancialSupportData relating to financial support received by students
InstanceInstancePeriodData items which pertain to a particular cycle within an instance of engagement
InstancePeriodQualificationsAwardedQualifications awarded during the instance period

The Student Alternative record consists of four main data entities, as illustrated in the Data model. These entities also contain a number of sub-entities which group related data items together into blocks of data. The File structure shows the relationship between the entities and sub-entities and is a useful way to visualise the record.

For example, a provider must return at least one student and that student must have an instance of engagement with the provider (be on a course) and that course must have a subject.

Not all the data items, sub-entities or entities will need to be returned for each student in each reporting year and this document is intended to assist providers in determining which data they will need to return.

Entity diagram - AP student record all years

Those entities and sub-entities in blue in the diagram above are expected every year for all students. The sub-entities in grey are only required under certain circumstances.

Entities and sub-entities


The Provider entity must be returned in each year as this is used to identify the provider making the return.

Course and Course Subject

In each year, the provider must return a full set of course and subject data for each of the courses that are active in the HESA reporting year and fall within the coverage of the record.

Delivery Organisation and Location

The Course entity contains the Delivery Organisation and Location sub entity. Where applicable, this records the organisation(s) delivering the course and the location(s) at which the course is delivered. Where the reporting provider is wholly responsible for delivering the course, this entity is not required.


Every provider must return at least one student to HESA in each year and for each student a certain number of data items are required in order to uniquely identify them and track their activity. The Student entity contains data items related to the personal attributes of the student such as name, date of birth and identifiers (Student.HUSID and Student.SSN for example). These attributes are not expected to change between years however they must be returned in every year that the student is included in the Student Alternative record.

Student Equality

The Student entity contains the 'Student Equality' sub-entity which contains data items relating to equal opportunities characteristics. This sub-entity is compulsory for all students, although some fields are not required for all students. The data returned within this sub-entity for a student are liable to change between years as they should be based on self-assessment by the student. It is important that students are given the opportunity to update this information at least once a year, for example through enrolment and re-enrolment.

Entry Profile and Qualifications on Entry

The Entry Profile sub-entity contains data relating to the student prior to entry onto the Instance and is only required to be returned in the first year in which a student’s Instance is returned to HESA. The Qualifications on Entry sub-entity is attached to the Entry Profile sub-entity and is only returned where an Entry Profile has been submitted and then only for a subset of students. The Qualifications on Entry data is only necessary where the entrant is domiciled in the UK and has a level three (A-level equivalent) or Access course qualification as their highest qualification on entry.

Instance and Instance Period

In addition to capturing information about the student as a person, data about their engagement at the provider is also required. This information is reported through the Instance entity and the InstancePeriod sub-entity. The Instance entity captures the overarching information about what the student is doing at the provider such as what course they were studying, where and when they started studying. Some of this information may change over time if the student changes their study pattern, for example moving to a part-time mode of study or transfers to a different course, and as such the entity must be returned in each reporting period in which the student is submitted.

The InstancePeriod sub-entity is related to the instance but looks in more detail at the specific activity taking place within the HESA reporting period (01 August-31 July). The concept of Instance Period is key to the Student Alternative record and more information can be found within the Data items document. Every student returned within the record must be linked to an instance with at least one Instance Period relating to the reporting year.

Financial Support

Where students are in receipt of financial support as part of the Instance, this entity records details of the amount and type of support received. Where applicable, this also records where the support received is part of the provider’s Access and Participation plan.

Qualifications Awarded

As a result of the activity within the instance period a student may be awarded either a final qualification (if the instance has ended) or an interim qualification. These awards are returned through the Qualifications Awarded sub-entity. The Qualifications Awarded data must only be returned where an award has been made.

More detail on the specific data items contained within each entity and sub-entity can be found within the Data Items document on the coding manual. This contains the coverage statements for the entities which explain under which circumstances the data is expected to be returned.

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