Student record 2008/09

Version 1.1 Produced 2009-04-30

MIAP is a BIS-led programme supported by a large number of partner organisations, including HESA. The MIAP programme contains a number of strands of activity including the implementation of the UK Register of Learning Providers (UKRLP) and the development a Unique Learner Number (ULN) registration service. MIAP has also created a standard set of data definitions and policies through the Common Data Definitions (CDD) project. Details of the CDD standards can be found on the MIAP web site.

This document describes the adoption of the CDD standards on the HESA Student Record.

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.

A software developers toolkit - to support the development of UKRLP web services - can be found by following the Software Development Kit link from http://schemas.lsc.gov.uk/

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. In the long term, it is anticipated that the ULN will replace the HESA Unique Student Identifier (HUSID) and will also be used by UCAS, SLC etc.

Fields affected by the MIAP CDD project

The following table shows those fields affected by the CDD project. Fields marked as a CDD field are contained within the current set of CDD; those marked as a CDD standard are not specifically included in the current set of CDD, but are affected by CDD standards and/or data policy. Details of the specification can be found in the documentation for each field.

Data Policy

In addition to individual field definitions, the MIAP Common 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 CDD documentation on the MIAP 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 code:

  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.