09/01 - May

 

Dear Colleagues

HESA Student Record - 2007/08 post-implementation and future (2008/09, 2009/10 and 2010/11) requirements

Background

HESA is currently undertaking a post-implementation review of the first collection of the redeveloped 2007/08 Student Record. This review aims to learn about the experiences of the redeveloped record from the perspectives of institutions, data users and HESA, with reference to record design and specification, development of systems within institutions and at HESA, preparation and support, the data collection process and the quality of the data returned.

During January and February HESA held seven Post-Collection Workshops to provide an opportunity for institutional colleagues to feed back their experiences of the 2007/08 Student Record data collection. A total of 196 delegates representing 124 institutions attended these workshops. Feedback included comments on the validation kit, the data collection system, the documentation and the reports issued by HESA.

In parallel, HESA established a Post-Implementation Review Group comprising Statutory Customers, institutional representatives, HESA colleagues and representatives from SROC, ARC and UCISA. The group has met monthly since January, with each member of the Review Group having dedicated time to report on their experience of the 2007/08 Student Record. A range of issues has been raised during the Workshops and Review Group meetings and responses to these will impact on the 2008/09, 2009/10 and 2010/11 returns, depending on their nature.

Some of the changes set out below have already been incorporated into earlier releases of the documentation and the validation kits, many of the remainder will be included in releases made in May and June. All are included here for completeness.

Student Record 2008/09 specification changes

There have been a small number of changes to the specification of the Record for 2008/09. Some of these result from the review, others were already planned:

  • Maximum number of modules that can be attached to an instance has been increased from 24 to 128 in response to comment from institutions that 24 was not sufficient, particularly where it was necessary to return ‘results-only' modules in addition to those being studied in the current reporting period.
  • Coverage of Instance.LOADYRA and Instance.LOADYRB (where Institution.INSTAPP =1), for institutions in England and Northern Ireland, has been amended to exclude FE and PGR students.
  • Fields required for FE students at institutions in Wales have been updated. Institutions in Wales were already aware of this planned change. All information is available in (http://www.hesa.ac.uk/08051/ferecords_v2).
  • Coverage of EntryProfile.PARED has been extended to include UCAS entrants to institutions in Wales and Northern Ireland. This was indicated at the time when the 2007/08 documentation was first released. This data is available from UCAS from 2008 for all entrants entering through UCAS.
  • New field for institutions in Wales, StudentOnModule.MODCOUNT. Again, institutions in Wales were aware of this change in advance.

The presentation of the field lists in the documentation now allows institutions to choose whether fields are ordered alphabetically by description or short name. Also, at the top of each field page is a link to jump directly to the valid entry list.

Validation

Feedback that HESA received about validation related to both the performance of the kits and to the rules themselves; there are changes being implemented in both of these areas.

Kits

Following a survey of institutions to better understand why the performance of the kits in 2007/08 varied so significantly between institutions, HESA is able to issue the following guidance on how to get the best from the kits. There are three things that are important to get right to ensure best performance when validating data using VK-framework. These are:

  • Hardware: HESA recommends using a machine with the minimum specification of a Dual core processor and 2 GB RAM
  • Environment: HESA recommends using local folders for results (and rules) and not using a network
  • Batch size (this is configurable in the VK-framework (Windows standalone version), with the default value set to 10):
  • The default value is not the optimal value
  • The batch size will need to be changed to an optimal value for a given hardware configuration
  • A bigger value of batch size does not necessarily mean better performance (the maximum for 2GB memory is about 700 or 800) and therefore setting this value to a larger number will not result in better performance. However, trial and error will be needed in order to set the correct value for this parameter for any specific configuration.

This information will be repeated in the Quick Start document for the kit.

In addition, HESA is preparing a new framework for the kit, which it is hoped will give improved usability for all institutions. At the request of institutions the output from this new framework will include hyperlinks to the relevant coding manual pages. The new framework will be issued early June.

Institutions asked if the kits could be constructed so that it was possible to run the business rules without data having first passed the schema rules, thus allowing checking and correcting of the two sets of errors to happen in parallel. HESA has investigated the possibility of allowing the validation framework to ignore some schema failures and continue executing business rules. It has been concluded that this is not a sensible approach since the XML parser, on identifying a schema error, stops processing that branch and moves to the next branch - leaving whole sections of unvalidated XML, which could contain any number of (structural) errors. Therefore any attempt to process the business rules with a schema error effectively means attempting to process the rules with chunks of XML not (structurally) validated at all. To address the most significant concern that institutions raised, the format checks on postcode fields have, for 2008/09, been moved out of the schema and will be included as business rules. However, HESA would encourage institutions to look to validate data such as postcodes at the point of collection and to begin working through schema checks at a much earlier stage of data preparation than submission.

Rules

There are many changes to the validation rules, as always happens between annual data collections. Full detail of the business rules for 2008/09 is set out in http://www.hesa.ac.uk/studrec0809-businessrules. Institutions' attention is drawn to a number of significant changes, in addition to that for postcode as mentioned above:

  • QualificationsOnEntry.QUALTYPE and QualificationsOnEntry.QUALGRADE - in 2007/08 failures for cross-checks between these fields were reported as warnings. For 2008/09 they will be reported as errors for those qualifications included in the Tariff calculation (these are identified in http://www.hesa.ac.uk/08051/qualsonentry). HESA has worked with UCAS to ensure that all data provided in *J (UCAS Data for HESA) will pass validation, although institutions will need to remove QUALGRADE where UCAS provides a NULL value.
  • Student.TTPCODE - the number of identical postcodes that will trigger an exception error has been raised to 600.
  • EntryProfile.NEWENT - a new exception check will look for high numbers of young (aged 18 and under) entrants reporting previous HE experience of more than 6 months.
  • Student.GENDER - a new exception check will look for more than one student coded as ‘indeterminate'. HESA is reviewing the terminology in this area, but institutions are reminded that ‘indeterminate' should not be used as a proxy for unknown. Widespread use of the ‘indeterminate' code is not expected.


Changes to the collection system for 2008/09 collection

During this review process institutions have raised issues relating to the collection and the collection system, and as a consequence there will be a number of planned changes made in time for the 2008/09 collection:

  • The data collection system will be set up to send an email to the transaction owner when a transaction has completed processing.
  • In order to help institutions better understand how the data they provide will be used in routine publications and has been processed for the Check Documentation, HESA will, following a successful commit transaction, make available standard data tables. These tables will include a core analysis table that gives instance level derived fields (populations, TQI Tariff etc.), an FTE/cost centre table that will enable institutions to replicate cost centre analysis and an FPE/subject table that allows institutions to replicate subject based analysis. The structure of the files will be provided as part of the documentation and the detailed specifications of the derived fields, including TQI Tariff, will be available through the data collection system once this goes live in August.
  • HESA is reviewing code efficiency in the main areas of Aardvark processing with the view to improving performance.
  • COMMIT-stage validation errors will be downloadable in CSV format.
  • TEST COMMIT will be open for the majority of the collection.
  • HIN checking will be extended to include FE students, although the results will be reported only as warnings for 2008/09. Separate notification about this change has been made to relevant institutions. Further information regarding the context in which this change has been made will be available for reference from the website.

Additional changes to the record specification and collection system for 2009/10

Colleagues will be aware that Statutory Customers requested a number of small-scale changes to the 2009/10 record about which institutions were consulted in June of last year, with a detailed summary of the resultant changes being published in September (http://www.hesa.ac.uk/C09051). As a consequence of the review process, a number of additional changes are now to be made to the Record for 2009/10:

  • Following requests from institutions a field has been added to the ‘Instance' entity which allows an institution to record its own identifier for a student if it would be useful to do so. Instance.OWNINST is available for institutions in England, Northern Ireland, Scotland and Wales and is optional for all instances.
  • Three further codes have been added to the Course.COURSEAIM coding frame in addition to those announced last year. These are:
  • M02 Masters in Teaching and Learning
  • D01 New Route PhD
  • M26 Integrated undergraduate/postgraduate taught Masters degree on the enhanced/ extended pattern leading towards obtaining eligibility to register to practice with a Health or Social Care or Veterinary statutory regulatory body
  • These three new codes plus those already announced as being added to the COURSEAIM coding frame have all been added to QualificationAwarded.QUAL.
  • The coverage for the new Course.BURSARY field will now include institutions in Wales and, at the request of institutions, will be implemented as Course.NHSBURSARY.
  • Some additional codes will be added to StudentOnModule.MODOUT to cover modules returned in error and modules not completed for funding purposes.
  • At the request of institutions UCAS will include March starters in the *J (UCAS Data for HESA) file.
  • The coding frame for Instance.EXCHANGE is being revised and brought up to date.
  • A code for PT ITT is being added to Instance.SPECFEE.
  • A code is being added to Instance.LOCSDY for students who are on the Student Record who will spend or have spent a period of more than 8 weeks in the UK.

Proposals for the 2010/11 Student Record

In addition to the changes set out above, HESA is now planning changes for 2010/11.

Qualifications on Entry

The current coding frame for EntryProfile.QUALENT2 is recognised as being out of date and not fit for purpose, particularly for institutions which are subject to the ELQ policy. HESA has developed a proposed new coding frame which is based on the structure already implemented for the Course COURSEAIM field but intended to account for the newer 16-19 qualifications and some of the detail needed at the HE level to support ELQ.

Currently the proposed new coding frame includes separate codes for EU and other overseas qualifications at each level, comments are welcomed on whether or not this is an achievable and useful disaggregation.

As an alternative to that proposed, the full Course.COURSEAIM coding frame for HE qualifications could be used for this purpose, without the proposed simplifications. However, the coding frame would still need to be expanded at the pre-HE levels as proposed. Institutions might, however, consider even the proposed new coding frame to be too detailed.

Institutions are invited to comment generally on the proposed new coding frame and the practicalities of implementing it. The field would be renamed EntryProfile.QUALENT3 in recognition of this significant change.

Masters in Teaching and Learning

The TDA is launching a new qualification, a Masters in Teaching and Learning (MTL), and to support monitoring of this, new fields will need to be added to the Student Record. The qualification is designed in phases and TDA will need phase completion information and also the school where the student is teaching will need to be recorded. TDA is consulting with the institutions likely to be involved in this initiative on the detail of the requirements; HESA Student Record contacts are encouraged to ensure that they are involved in these discussions locally. Institutions should note that MTL students are likely also to be included alongside the in-year information currently collected for ITT students through the ITT data stream.

Percentage of module taught in Celtic language

Currently the field that records the percentage of a module taught in a Celtic language is situated on the Module entity. HEFCW have requested that the field be moved and instead be situated on the StudentOnModule entity. This will mean that where students on the same module take different proportions through the medium of a Celtic language this can be recorded accurately for each student. Institutions in Wales have already indicated that they are content with this move: institutions in Scotland and Northern Ireland who would also be affected are invited to comment.

Capturing data about why students withdraw from courses

A recent House of Commons Committee of Public Accounts Report "Staying the course: the retention of students on higher education courses" (http://www.publications.parliament.uk/pa/cm200708/cmselect/cmpubacc/322/322.pdf) included the following recommendation:

Information on why students withdraw from their courses is not reliable. Although some data is collected nationally it is often incomplete and inconsistent. Little is known, for example, as to the extent to which mental or physical illness or domestic circumstances contribute to withdrawal. The Funding Council together with the Higher Education Statistics Agency and universities should develop a common standard and principles which define the types of retention information which need to be collected and reported.

To which the Government responded as follows:

Previous attempts to capture such information via the Higher Education Statistics Agency (HESA) record did not deliver sufficiently reliable data. However, the Funding Council will explore with HESA and universities how we can collect reliable data in this area. To ensure that the burden and cost implications for universities are proportionate, it may be necessary to consider methods, which involve collecting data on a sample basis rather than collecting data centrally for every student, every year. (http://www.official-documents.gov.uk/document/cm73/7364/7364.pdf).

Given the recommendations of the report it is now timely that the sector evaluates not only the data that are collected but also how their reliability can be improved. Institutions are invited to suggest changes to the data collected that could improve the information available, these might include enhancing the coding frame or adding extra fields to aid capture of the multi-faceted reasons for student non-completion. Institutions are also invited to give details of how they have managed to capture reasons for student non-completion so that good practice can be identified and shared. Finally, if institutions are able to identify specific issues with collection of these data they are invited to identify them so that any best practice identified can specifically address these.

Next steps

Institutions are invited to note the changes and updates being made for 2008/09 and 2009/10 set out above, and also to comment on the proposals made for 2010/11. Responses should be sent by email to consult@hesa.ac.uk by Monday 8 June 2009.

A new version of the 2008/09 documentation and validation rules is being published in parallel with this circular. The first full version of the documentation for 2009/10 will follow shortly. A new validation kit framework will be released in early June.

Following analysis of the responses to this consultation, and consequent further discussions with Statutory Customers and other interested parties, further details about any changes to be made for the Student Record in 2010/11 will be published by the end of July 2009, and record contacts notified in the usual way.

 

Yours Sincerely

C. Jane Wild

Director of Operations