06/03 - March
Dear Colleagues
REDEVELOPMENT OF THE HESA STUDENT RECORD - SECOND CONSULTATION
In January 2006 HESA published Circular 06/01 which summarised the results of the first consultation on the redevelopment of the HESA Student Record. This Circular performs two functions:
- It informs institutions about the review process to date and the planned timescales
- It contains the second round of consultation
Institutions are invited to send their response to the consultation to consult@hesa.ac.uk no later than 18 April 2006. In addition to responses from HE institutions, we would welcome responses from any software providers affected by the changes proposed in this consultation. Please ensure that we receive no more than one response from your organisation.
A consultation seminar has been arranged for Monday 27 March in London. Details of this event are available here.
Informing |
Consulting |
If you have any queries on the issues raised in this Circular please send them to consult@hesa.ac.uk.
Yours sincerely
C. Jane Wild
Director of Operations
Implications of the move to XML
The move to an XML collection will mean changes to the way HESA publishes the data specification and to the processes used for the collection and quality assurance of the data. This paper aims to set out current thinking on some of these issues.
What is XML?
XML is the eXtensible Markup Language. It is a very flexible text format that is increasingly being used in data exchanges on the web . XML is a W3C recommendation.
There are many XML training resources on the web, including the W3C Tutorial on XML and the resources of W3Schools.
What does this mean for the HESA Student Record?
XML allows the representation of hierarchical data structures in a single file. It also removes the need to collect empty fields and it introduces a new lexicon for the specification of the record.
XML documents (i.e. 'files') contain elements and attributes. An element is identified using tags (defined with 'pointy brackets') and each element must have a start tag and an end tag. Each tag contains the element name and the end tag also contains a / character.
Elements can contain data; for example, a birth date element might look like this:
<Birthdate>1975-06-18</Birthdate>
Elements can be nested within other elements – these nested elements are known as child elements. Nesting also allows us to group related elements together. Elements can also be repeated - so we do not need to define multiple occurances of the same element. For example, the current Student/Module structure includes sixteen module linking fields in the type 12 record, even if only two are used. Moving to XML will allow a return to only include as many or as few of these links as are actually required.
Attributes can also be used to hold information about an element. An attribute exists within an element start tag and we could represent element data as attributes. For example:
<Student HUSID="1234567890123">
<Birthdate>1975-06-18</Birthdate>
<Name>Fred Smith</name>
<Gender>M</Gender>
</Student>
In general, we plan to specify data items as elements instead of attributes. The normal exceptions to this will be structural identifiers (i.e. those things that uniquely identify each element, like HUSID for a Student). The main identifiers in the new structrue will be very similar - if not identical - to the existing fields; INSTID, HUSID, NUMHUS and MODID. There will need to be a course identifier to link the course entity to the instance entity, and this will replace the currently optional field of OWNPSD.
Defining XML
XML Schema is a language for describing the structure and constraining the contents of XML documents. HESA will produce an XML Schema Definition or XSD file as a part of the data specification documentation. An XML Schema defines:
- elements that can or must appear in a document
- attributes that can appear in a document
- which elements are child elements
- the order of child elements
- the number of child elements
- whether an element is empty or can include text
- data types for elements and attributes
- default and fixed values for elements and attributes
- the maximum and minimum number of times an element can occur
Since an XSD contains the rules of the data structure, many (but not all) of the things we currently do in validation kits will, in future, be done by publishing an XSD that institutions must adhere to.
An XML Validating Parser is a piece of software that can read an XML document and check it’s contents against an XSD.
Next Steps
HESA will continue to work with UCISA to engage in dialogue with software providers and technical specialists in HE institutions with the aim of ensuring that the move to XML is successful.
Timescales for the Review (March 2006 onwards)
| Second sector consultation | 6 March – 18 April 2006 |
| Student Record Review Consultation Seminar | 27 March 2006 |
| Collation of responses | 18 – 28 April 2006 |
| Sixth meeting of Review Group | 8 or 9 May 2006 |
| Full proposals completed | 16 May 2006 |
| Full proposals to HESA Board | 23 May 2006 |
| Notification to sector | Early June 2006 |
| Operational Documentation preparation | June/July 2006 |
| Operational Documentation release | 31 July 2006 |
| Implementation | 2007/08 reporting period |
| First collection | Autumn 2008 |
Summary of key issues
Internal Departments
Following the first consultation exercise, and further discussion, it has been agreed that it is not practical to pursue the proposal to include a field to record 'internal department'. It was not clear where in the new structure would be the appropriate place to locate such a field, as institutions had different views as to how departments are structured and consequently had concerns about the usefulness of any such data.
Data for Students Studying Wholly Overseas
There is now a formal requirement to collect some limited data about all students registered with UK HEIs but studying wholly overseas. Return of students was previously optional (LOCSDY, Code 7). However, it is not intended that such students be included on the Student Record. An simple aggregate return will be specified that meets all of the requirements - institutions will be consulted on this at a later stage.
Qualification Aim
HESA has reviewed in detail the coding frame for qualification aims. The new coding frame is intended to take account of new and changed qualifications and in particular to allow mapping to external qualification frameworks. A paper (MS Word document) setting out detailed proposals is available here. The new coding frame is more structured than the current one and consequently looks quite different. Comments on both the approach taken and the consequent detail are sought.
Qualifications on Entry
HESA is currently in discussions with UCAS and the Awarding Bodies to secure a mechanism and format whereby detailed examination data can be passed to institutions as part of the *J transaction for use in populating the HESA student record.
It is likely that four fields will be included in this entity:
- Qualification Type
- Awarding Body
- Subject of Qualification
- Grade
No further detail is available at this stage.
Use of Module Data in England
Following the first consultation the decision was taken to rationalise Student Instance FTE reporting to a single method using the '50-50' approach in cases where a student's programme year spans two HESA reporting periods. However, there may be implications following from decisions on the new HEFCE funding formula. See: Paper from HEFCE
New Information Requirements for Research Students
As HESA establishes its relationship with the Research Councils, it is planned that more of the information currently collected directly by the RCs be instead included on the Student Record. A number of new fields are included in the student instance entity to do this.
Additionally, all research students will need to be allocated to RAE units of assessment.
Implementation of JACS 2.0
Following a limited review of the use of JACS, an amended version will be used from 2007/08. A paper (MS Word document) setting out the new JACS 2 is here. A second document (MS Excel workbook) setting out the changes from JACS 1.7 is here.
Celtic Languages
The existing requirement to record where modules were available in Welsh has been extended to cover other Celtic languages. The coverage of the relevent fields (Proportion of Module Taught in Other Language and Module Available in Other Language) now includes institutions in Wales, Scotland and Northern Ireland.
UCAS Identifier
In order to reflect changes in the UCAS system, HESA will be collecting both the UCAS Personal Identifier and Application Code. These fields have been allocated to the Student and Entry Profile entities accordingly.
Other New Information Requirements
In addition to the areas set out above and as a result of new information requirements received from HESA's Statutory Customers, a range of NEW FIELDS are proposed. These are listed at the top of the pages for each entity. Institutions are particularly encouraged to look at these in detail.
Student Instance
Course
Entry Profile
Student on Module
Finally, the coverage of the following fields has been extended:
Information on Fees and Bursaries
Introduction
It has long been known that the change in student support arrangements would impact on any Student Record data collection after 2006/07.
From September 2006 HEIs in England, Wales, Scotland and Northern Ireland will have different arrangements in respect of charging fees, and HEIs in England and Northern Ireland will be allowed to vary the fees charged to new students - the charging of such variable fees in England and Northern Ireland is dependant upon HEIs signing up to an Access Agreement with the Office for Fair Access (OFFA).
The introduction of change in student support and the assistance available to help with fees and living costs varies across the UK. In addition, many HEIs are offering non-repayable bursaries, or other non-cash bursaries (goods and services).
In the light of planned review of the HESA Student Record for implementation in 2007/08, it was agreed amongst HESA’s statutory data users that no revision would be made to the return in 2006/07 in order to reflect student support changes.
However HESA's statutory data users have a requirement to be able to monitor the effect of changing student support arrangements in the sector over time. There has thus been some discussion within the Student Record Review Group concerning the most efficient method of capturing this information, either from the HESA return, or through some other means.
Fees for Full-time Undergraduate Students and Bursaries
There are thus two possible options for collection of information about fees paid by and bursaries paid to full-time undergraduate students.
One option is to collect this information annually from all institutions through the introduction of new (yet to be specified) fields in the HESA Student Record.
A second option is to satisfy the monitoring requirements for the full-time undergraduate population through negotiating a data sharing arrangement with the Student Loans Company (SLC). Through this singular route it is hoped that the SLC would be able to provide information about fees and bursaries for full-time undergraduate students to the statutory data users.
This option is proposed because, together with student loans and other student finance arrangements, from 2006/07 the SLC are also managing the HE Bursaries Scheme, and (from 2007/08), the National Bursary Scheme in Wales on behalf of the sector. It is thought likely that the majority of HEIs will opt in to this process from 2007/08. Therefore it is hoped that the SLC might be able to provide adequate data about fees and bursaries to the statutory data users, as this information would already be held by the SLC, so removing the need for information to be captured on the HESA Student Record.
The Student Record Review Group suggests that this second option represents the most efficient method of capturing this information. However institutions are asked which of these two options for obtaining fee and bursary information for full-time undergraduate students is preferred – either from the SLC, or through the HESA Student Record.
It should be noted that if the data sharing arrangement proposed was preferred but cannot be successfully negotiated, or if the adoption by the sector of the SLC process to manage the bursary schemes was insufficient, then as a contingency it would be necessary to look again at obtaining this information through the HESA Student Record. There is thus the possibility that following the second sector consultation (closing in mid-April) and before the operational documentation in support of the record is finalised (during the summer) there will be a need to contact institutions again with details of an alternative method of obtaining fees for full-time undergraduate students and bursary information from the HESA Student Record.
Fees for Postgraduate and Part-time Students
For all other students (part-time undergraduates and postgraduates) it has been identified that it is trend information that is required, and not full data each year, i.e. not an annual collection. It is not thought practical to include such a sporadic request for information in the HESA Student Record. Therefore, what is currently being explored in respect of information about fees for all other students is the possibility of carrying out a periodic sample survey of information from HEIs.
Student Record
Within the existing return, there is a suite of HE fields concerning fees: MSFUND, FUNDCODE, FEEELIG, FEEBAND and MSTUFEE. It can be seen from elsewhere in the documentation for this second sector consultation that there is a continuing need to collect the majority of this information, e.g. FUNDCODE, FEEELIG, MSTUFEE and MSFUND.
In addition, the Research Councils have expressed an interest in postgraduate stipends and there has also been some discussion within the Student Record Review Group concerning obtaining information about employer support. The consultation documentation reflects these new requirements - postgraduate stipends as a field belonging to the Student Instance entity and employer support as an element of motivation for part-time study, a field belonging to the Entry Profile entity.
Some fee information is also included in the HESA Finance Statistics Return (FSR) – ref. Tables 1, 5a and 5b. It is thus recognised that some revision to the FSR will be necessary from the 2006/07 reporting period to reflect the different arrangements throughout the UK in respect of charging fees. Such revision is being progressed outside of the Student Record Review.
Implications of the Management Information Across Partners (MIAP) Project
Introduction
Mention was made of the implications of the Management Information Across Partners MIAP (MIAP) programme to the HESA Student Record in the first consultation document.
Background
MIAP is intended to bring coherence to data collection across all post-compulsory education. MIAP is about streamlining how information on learners and learning is shared across the education sector so that excellent services are made available to individuals, employers and communities.
Ministers and the MIAP Stakeholder Group {of which HESA and UCAS are both members} have endorsed a programme of work that will simplify the way information about learners and providers is collected, handled and shared.
MIAP will lead to a wide range of benefits affecting everyone with an interest in post-14 education and training and will result in business improvements across the sector.
The programme of improvement to data collection and sharing will be introduced over several years and is being led by the Department for Education and Skills and delivered by the Learning and Skills Council.
Among a number of strands of the MIAP programme are three projects that will have a certain impact on implementation of the HESA Student Record in 2007/08.
MIAP Projects
Common Data Definitions (CDD)
The development of Common Data Definitions is a key strand of work that will enable the MIAP vision to be fulfilled.
Common Data Definitions will be an important enabler for the operation of the MIAP Learner Registration Service and will allow the MIAP Learning Data Interface to pool relevant information quickly and accurately.
In general terms, the CDD project is proceeding as follows: common data definitions will be introduced in two phases during 2006. During 2006, XML data schemas and data standards recommendations will be published on the MIAP website along with detailed contextual information and guidance on implementation.
For some time now it has been HESA’s intention to adopt national classifications where they exist and are appropriate – there are a number of examples of this in the current return. The adoption of CDD can be seen as a natural extension of this principle; there will no longer be an option to develop coding on an ad hoc basis. It is also anticipated that in many cases the {CDD} definitions will not be dramatically different from those already in use.
There are many advantages to adopting CDD; introducing common data definitions to the returns made both to and by the HE sector will lead to improvements in data quality, data sharing and consolidation, thus streamlining statistical reporting and providing a better understanding of the sector.
Specifically then, the HESA Student Record will adopt the standards defined as a result of the Common Data Definitions (CDD) project on the coding of basic fields, such as gender, as well on more {education-}specific items.
One area where standardisation is necessary relates to the characters used to report names, addresses and any general text fields. In this regard CDD recommends a set of character codes to be used in the HESA Student Record that will support all Latin-based characters and which will replace the various charactersets currently in use.
Another example is the adoption of the International Date Standard for the reporting of dates within the the return. International Standard ISO 8601 specifies the numeric representation of date (and time). This standard has been adopted by HESA such that the valid entry pattern for all dates is: YYYY-MM-DD, where YYYY is the year in the usual Gregorian calendar, MM is the month of the year between 01 (January) and 12 (December), and DD is the day of the month between 01 and 31. For example, the sixth day of March in the year 1989 is recorded as 1989-03-06.
Adoption of CDD by UCAS
Both UCAS and HESA have a track record of planned introduction of change, and wherever possible, seek to co-ordinate such changes across the work of the two organisations, e.g. the introduction of the Joint Academic Coding System (JACS) for 2007 entry (UCAS) and the 2007/08 reporting year (HESA).
It is similarly planned that UCAS will adopt MIAP Common Data Definitions for recording information about applicants in 2007, which will be incorporated into the *J transaction provided by UCAS to HEIs to assist in making HESA returns for the 2007/08 reporting period – the year of first implementation of the new Student Record.
Unique Learner Number (ULN)
MIAP has developed the concept of a Learner Registration Service that will support every learner and their agent to access information about their achievements in education and training.
An operational model of how this service will work in practice for learners, providers and awarding bodies was developed and agreed by major MIAP stakeholders at the end of October 2005.
Prototype applications of the Unique Learner Number are now being developed to test and trial the Learner Registration Service. These prototypes are due to start towards the end of 2006 and will aim to demonstrate in practice the benefits of improved data sharing for both young and older learners.
If the trials are successful, the Learner Registration Service will be rolled out to all learners in the UK from September 2007. The Learner Data Sharing Interface will be designed during 2006, trialled in 2007 and become fully operational by 2010.
Therefore, it is likely that the Unique Learner Number (ULN) will replace the HUSID in the HESA Student Record, although it may be necessary to run the two identifiers in parallel for a number of years as the ULN is phased in.
UK Register of Learning Providers (UKRLP)
The UK Register of Learning Providers (UKRLP) will link information sources on education and training organisations in England, Ireland, Scotland and Wales. Learners, employers, providers, awarding bodies, inspectorates, government agencies and government departments will eventually all have access to this information.
UKRLP was launched in August 2005, implementation of the register is being phased over 2006, and to date, it contains information on over 9,000 learning providers.More information is available from the UKRLP website
The develpoment of the UK Register of Learning Providers (UKRLP) will mean that institution identifiers in the HESA Student Record will change to a standard set.
