Initial Teacher Training In-Year Record 2010/11
Initial Teacher Training In-Year Collection 2010/11
Data standards in the HESA ITT In-Year Collction
return to index
Version 1.0 Produced 2010-02-15
The Information Standards Board (ISB) for education, skills and children's services (escs) is the overarching authority and governing body for the management and assurance of information and data standards across the escs system. It is both adopting existing data standards and developing new data standards for this domain and is subsuming the standards developed by the MIAP programme. The Aligned Data Definitions adopted by the ISB define a standard set of data definitions and policies .
This document describes the adoption of relevant data standards in the HESA ITT In-Year Collection.
UK Register of Learning Providers
Adoption of the UK Provider Reference Number (UKPRN) is a key element in the standardisation of data definitions between stakeholders' systems. It is envisaged that, over time, all stakeholders will adopt the UKPRN as the primary identifier for institutions. See the the UK Register of Learning Providers (UKRLP) web site for further information.
Unique Learner Number (ULN)
The allocation of ULNs was piloted with a first major roll out in 2007 covering students who were on the National Pupil Database. Systems will be put in place to issue ULNs to mature students and students from overseas. Students who have been allocated a ULN should be aware of this fact and should have access to their number. However, it is likely to be a number of years before all students entering higher education are able to provide this information.
Fields affected by the ISB Aligned Data Definitions (ADD)
The following table shows those fields affected by the ADD. Fields marked as a ADD field are contained within the current set of ADD; those marked as a ADD standard are not specifically included in the current set of ADD, but are affected by ADD standards and/or data policy. Details of the specification can be found in the documentation for each field.
|Field||ADD field||ADD standard||Notes|
|Institution.UKPRN||Y||Valid UK Provider Reference Number from the UKRLP. This replaces the INSTID field.|
|Student.ULN||Y||Standard structure with checksum.|
|Student.FNAMES||Y||Standard character set. Maximum field length of 100 characters. Representation of not applicable with a reason code.|
|Student.SURNAME||Y||Standard character set. Maximum field length of 100 characters.|
|Student.PSURNAME||Y||Standard character set. Maximum field length of 100 characters.|
|Student.SNAME16||Y||Standard character set. Maximum field length of 100 characters.|
|Student.BIRTHDTE||Y||ISO8601 date format. Representation of not known with reason code.|
|Student.GENDER||Y||Standard coding frame based on ISO 5218.|
|Student.DEGCTRY||Y||Standard coding frame based on the ISO-3166-1 Alpha-2 list of country codes and adapted by the Office for National Statistics.|
|Student.DEGSTDT||Y||ISO8601 date format. Representation of not known with reason code.|
|Student.DEGENDDT||Y||ISO8601 date format. Representation of not known with reason code.|
|Student.COMDATE||Y||ISO8601 date format.|
|Student.ENDDATE||Y||ISO8601 date format. Representation of not applicable with reason code.|
|Student.SPLENGTH||Y||Representation of not applicable with reason code.|
|Student.CTITLE||Y||Standard character set. Maximum field length of 255 characters.|
|Student.OWNSTU||Y||Standard character set.|
|Student.NUMHUS||Y||Standard character set.|
In addition to individual field definitions, the Aligned Data Definitions set out areas of data policy that apply to many fields or across the return specification as a whole. The following areas of data policy are adopted in the HESA Student Record. The full set of data policy statements can be found in the ADD documentation on the ISB web site.
- Use of XML schemas that adhere to the W3C XML Schema Recommendation
- Use of the Unicode characterset
- Use of UTF-8 for encoding Unicode characters
- Representation of "no data" - Where there is not a specific code for "no data", an empty string should be used. This must be accompanied by a reason code to indicate the reason for missing data. This approach should be adopted in cases where field entries are not defined in a closed list.
- Representing the Reason for Missing Data - Anywhere that a "null" value is used, it must be accompanied by a reason
1: not provided (reason not specified)
2: not sought (no request has been made for the information)
3: refused (information requested but not provided)
8: see supplementary field
9: not applicable
If the code is "8" additional information must be provided.
This code must be encoded in XML schema as optional attributes, with a business rule to indicate when it must be included.
- Representing Metadata - Additional information (such as the reason for lack of data) shall be represented using attributes in XML Schema. Such data can be represented as elements or attributes. Elements are the more flexible approach, but result in needing another level of hierarchy. Attributes meet the requirements for this data and their use in this context matches the implementation of other e-GIF systems.
Contact Liaison by email or on 01242 211144.