Student Alternative student record 2020/21 - File structure and entity overview
File structure and entity overview
Version 1.1 Produced 2021-01-06
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:
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|
|Course||Course||Course Subject||A HECoS subject code and a proportion indicator|
|Course||DeliveryOrganisationAndLocation||Data about the organisation(s) delivering the course if they are not the reporting provider|
|Student||Student||StudentEquality||Data items which are required for monitoring equality|
|Student-Course engagement||Student||EntryProfile||Data items which relate to the student at the outset of their engagement with a course|
|EntryProfile||QualificationsOnEntry||Qualifications held at the outset of the engagement, returnable many times|
|Student||Instance||Data items which relate to the entirety of an instance of engagement between student and course|
|Instance||FinancialSupport||Data relating to financial support received by students|
|Instance||InstancePeriod||Data items which pertain to a particular cycle within an instance of engagement|
|InstancePeriod||QualificationsAwarded||Qualifications 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.
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.
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 students 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.
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 providers Access and Participation plan.
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.