Updates on the Student Record 2007/08 & ITT In-year Record 2008/09 SROC, Belfast, 1 st April 2008

Objectives for the session Identify potential data submission issues Introduce validation and the new kit Provide further updates on C07051 Overview of the ITT In-year Record

Potential issues of the new structure…

Submitting more than one file… If an institution submits multiple files, for example from separate campuses, then validation will ensure that the attributes for any student, module or course are unique within an institution, even if the student, course or module is submitted in multiple files Each submission must be complete and discrete. This means that the validation for each submission will ensure that : -Each Student entity is unique (on the basis of HUSID) -Each Module entity is unique (on the basis of MODID) -Each Course entity is unique (on the basis of COURSEID) -Every Course and Module that an Instance refers to must exist within that submission -Multiple Instances within a Student entity must be unique

Student Instance 1 BAHIS Student Instance 2 FOUND Student Instance 1 BAHIS Instance 2 FOUND HESA Data Collection System

Student Instance 1 BAHIS Student Instance 2 FOUND Student Instance 1 BAHIS Student Instance 2 FOUND HESA Data Collection System Exception Error: HUSID Must be Unique

Other potential issues Entry profile can be sent each year however we would prefer it to be sent just once at the start of the student instance - data degradation is an issue If entry profile is sent each year HIN checks will be applied Our preference is for COURSEIDs and MODIDs not to change from one year to the next…

FE Potential Issues All FE instances must have a NUMHUS returned… ……if an FE instance submitted previously is being returned Entry Profile data must be included unless institutions returned NUMHUS last year allowing us to HIN link to previously returned Entry Profile data

(Re)Introducing Validation

First stage validation Still carried out at the ‘INSERT’ stage. First stage validation now referred to as ‘Schema checks’ and ‘Business rules’ First stage validation goes through schema checks first and then the business rules

Schema Checks Checks that the XML is 'well formed' and that it conforms to the rules of the schema definition (the XSD files): -Every element in the file must have the correct opening and closing tags -Elements must be correctly nested -Elements must contain the correct type of data (strings, dates, valid entries etc.) -The Schema controls the ANARCHY

Business Rules A set of rules to checks the business logic of the submission: -Consistency between pairs or groups of elements (e.g. RSNEND must not exist where FUNDCOMP = 3) -Elements that are compulsory under certain circumstances -Range checks

Introducing the validation kit Changes from previous releases: -Automatically searches for updates to validation rules on HESA server -Validation is now performed in two separate phases: 1) Schema checks 2) Checking against the business rules

Demonstration of the kit…

Viewing validation errors Currently we view errors by student and then error Future releases will change the way we can view errors so they will be grouped by field and then the students failing the rule Export functionality will also exist…

Potential validation problems Incorrect nesting and tagging of entities – consult the XSD for structure! Structural errors preventing you from seeing business rule checks – you need to pass one before you can see the other XML and fields with no content – the use of null codes and returning blank fields Using old coding frames

Validation issues with XML White space – has no meaning in XML Case sensitive e.g. field abbreviations must be in capitals Well formed – Tags need to be opened and closed, entities need to be correctly nested and fields must be in right order

Validation issues with Schema Reports COLLORG in wrong order within Course 1 Reports MTITLE error in Module 1 on kit Now reports COURSEAIM in wrong order within Course 1 Attempt 1Attempt 2Attempt 3

INSERT Transaction INSERT transaction processed on the data collection site will run: -Validation checks within the validation kit -Entry Profile checks that cannot be included in the kit –No HIN link for an incoming instance (submitted without Entry Profile) that commenced in a previous reporting period –No HIN link for an incoming instance (submitted with Entry Profile) that commenced in a previous reporting period

COMMIT Transaction COMMIT transaction processed on the data collection site: –Builds an entire institutional return from the various files that have been sent and processes institution level checks –COMMIT will check that attributes for any Student, Module or Course are unique within the submission even if the Student, Module or Course are submitted in multiple files

COMMIT Transaction HIN checks (zero tolerance) –All Instance.NUMUHS for a Student.HUSID must be unique (FE instances) [Error] –No HIN link in incoming data for an instance that was 'live' last year i.e. appeared on the HIN Target List produced last year [Error] –HIN link, but conflicting year-on-year data (DOMICILE, POSTCODE, QUALENT2, COMDATE, BIRTHDTE, ETHNIC, GENDER, SURNAME)

Other Updates

Student Associate Scheme (SAS) students No longer collected through the HESA Student Record 2007/08 (C07051) The collection in 2008 will instead be undertaken via the existing web based TDA system The primary reason for this is that the majority (75%) of students who take part in the SAS Scheme are enrolled at a different institution to the one managing their SAS programme

Early systems The DLHE April Target List System Opens in April each year Helps institutions identify students to be included in the DLHE April survey Subset of Student Record fields in XML are used to generate the DLHE April target list

Early systems Pre Collection Validation System (PCVS) Will be open in June… …access codes sent to record contacts… …allows early testing against first and second stage validation…

Report format For 2007/08 all reports will be generated in XML format… …this includes the POPDLHE and NSS files Reports will however be usable in spreadsheets

Aggregate Overseas Record The Aggregate Overseas record has been confirmed as a compulsory collection Full data specification available on the website Arrangements will be in place for those HEIs who do not provision meeting the record coverage

Check Documentation… Several changes from previous years…... including new ITT and ‘Mapping’ tabs Some items have been removed and new ones added Changes highlighted in red

Update: the ITT in-year record

Background  Previously… TDA census – funding and recruitment, and early statistics GTCE has maintained a register of qualified teachers Separate processes, covering similar constituency

New requirement  Provisional registration From 1 August 2008, trainee teachers in England are required to achieve ‘provisional registration’ with the General Teaching Council for England (GTCE) within 28 days of commencing their training programmes  The issue is how to achieve compliance with this new requirement whilst creating minimal burden on institutions

ITT In-year record Developed to meet requirements for provisional registration Same data also used for TDA census System remains open for students starting courses throughout year

What is the same…  Aardvark data collection system  Field specifications follow HESA Student record where possible, or GTCE conventions

What is different… In-year, not historical New transaction: ‘Add or Replace’ Process to approve records for provisional registration Process to send data to TDA for census

Summary of process

Coverage

ITT in-year record fields UK Provider Reference Number (UKPRN) Record type indicator (RECID) HESA unique student identifier (HUSID) Institution's own identifier for student (OWNSTU) Teacher Reference Number (TREFNO) National insurance number (NIN) Unique Learner Number (ULN) Independent Safeguarding Authority Reg’ Number (ISANUM) Student instance identifier (NUMHUS) Title (TITLE) Forenames (FNAMES) Family name (SURNAME) Immediately prior surname (PSURNAME) Family name on 16th birthday (SNAME16) Date of birth (BIRTHDTE) Gender (GENDER) Disability (DISABLE) Disabled Student Allowance (DISALL) Ethnicity (ETHNIC) Positive indication that self-certification complete (INDSLFCRT) Previous Degree country (DEGCTRY) Previous Degree establishment (DEGEST) Previous Degree Type (DEGTYPE) PGCE class of undergraduate degree (PGCECLSS) PGCE subject of undergraduate degree (PGCESBJ) Previous Degree Start Date (DEGSTDT) Previous Degree End Date (DEGENDDT) Previous Degree Length in Years (DEGLENGTH) Skills test number (SKILLTEST) Start date of instance (COMDATE) Fundability Code (FUNDCODE) End date of instance (ENDDATE) Reason for ending instance (RSNEND) Year of student on this instance (YEARSTU) Year of course (YEARPRG) Expected length of study (SPLENGTH) Units of length (UNITLGTH) Mode of Study (MODE) Teacher training Course (TTCID) ITT phase/scope (ITTPHSC) ITT schemes (ITTSCHMS) Course identifier (COURSEID) ITT Qualification Aim (ITTAIM) Course title (CTITLE) Subject of ITT course (SBJCA)

Governance Project Board - an advisory group chaired by the Chief Executive of HESA, and with representation from GTCE and TDA and with four institutional representatives, has been set up

Support The collection system will open early to give institutions an opportunity to get a feel for the collection process More information and further updates will be published on our website: