1 / 42

Updates on the Student Record 2007/08 & ITT In-year Record 2008/09

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.

nhi
Download Presentation

Updates on the Student Record 2007/08 & ITT In-year Record 2008/09

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. 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

  3. Potential issues of the new structure…

  4. 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

  5. Student <HUSID>0000973335211</HUSID> <BIRTHDTE>1988-10-25</BIRTHDTE> <GENDER>1</GENDER> Instance <NUMHUS>1</NUMHUS> <COURSEID>BAHIS</COURSEID> Student <HUSID>0000973335211</HUSID> <BIRTHDTE>1988-10-25</BIRTHDTE> <GENDER>1</GENDER> Instance <NUMHUS>2</NUMHUS> <COURSEID>FOUND</COURSEID> HESA Data Collection System Student <HUSID>0000973335211</HUSID> <BIRTHDTE>1988-10-25</BIRTHDTE> <GENDER>1</GENDER> Instance <NUMHUS>1</NUMHUS> <COURSEID>BAHIS</COURSEID> Instance <NUMHUS>2</NUMHUS> <COURSEID>FOUND</COURSEID>

  6. Student <HUSID>0000973335211</HUSID> <BIRTHDTE>1988-10-25</BIRTHDTE> <GENDER>1</GENDER> Instance <NUMHUS>1</NUMHUS> <COURSEID>BAHIS</COURSEID> Student <HUSID>0000973335211</HUSID> <BIRTHDTE>1988-10-26</BIRTHDTE> <GENDER>1</GENDER> Instance <NUMHUS>2</NUMHUS> <COURSEID>FOUND</COURSEID> HESA Data Collection System Student <HUSID>0000973335211</HUSID> <BIRTHDTE>1988-10-25</BIRTHDTE> <GENDER>1</GENDER> Instance <NUMHUS>1</NUMHUS> <COURSEID>BAHIS</COURSEID> Student <HUSID>0000973335211</HUSID> <BIRTHDTE>1988-10-26</BIRTHDTE> <GENDER>1</GENDER> Instance <NUMHUS>2</NUMHUS> <COURSEID>FOUND</COURSEID> Exception Error: HUSID Must be Unique

  7. 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…

  8. 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

  9. (Re)Introducing Validation

  10. 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

  11. 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

  12. 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

  13. 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 • www.hesa.ac.uk/C07051/validationkit

  14. Demonstration of the kit…

  15. 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…

  16. 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

  17. 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

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

  19. 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

  20. 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

  21. 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)

  22. Other Updates

  23. 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

  24. 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

  25. 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…

  26. 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

  27. 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

  28. 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

  29. Update: the ITT in-year record

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

  31. 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

  32. 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

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

  34. 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

  35. Summary of process

  36. Coverage

  37. ITT in-year record fields 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) 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)

  38. 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

  39. 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: http://www.hesa.ac.uk • liaison@hesa.ac.uk

More Related