Year of entry into provider (last 2 digits of year) Next 4 digits: HESA institution identifier

Transcription

1 DATA FUTURES APPROACH TO IDENTIFYING STUDENTS To support the collection of quality and usable data resulting in the collation of sector level datasets, HESA has a requirement to identify unique students and their engagements. Part of this requirement extends to identifying where people have multiple interactions with Higher Education, to ensure continuity of data over time. HESA has an obligation to minimise the burden resulting from this requirement, and where possible looks to avoid introducing artificial data into the system. Within the current student data collections there are two keys that exist to serve this requirement HESA Unique Student Identifier (HUSID) and the Student Instance Identifier (NUMHUS), and this paper sets out HESA s intended approach to replicating and enhancing this functionality as part of the Data Futures Platform. IDENTIFYING STUDENTS For the current Student, ITT, and AP records, HESA uses the HUSID to uniquely identify a student. This identifier is generated for all students, and the provider is responsible for returning a HUSID to HESA, being either one that has been previously allocated or by generating a new one. Given the need to make this globally unique, HESA currently requires HUSIDs to adhere to the structure below, which is taken from the current student coding manual: First 2 digits: Year of entry into provider (last 2 digits of year) Next 4 digits: HESA institution identifier Next 6 digits: Last digit: 6-digit reference number internally allocated by provider Check digit The resultant value is then used to enable linking of data across providers and through time. It is important to note that the Student entity in the Data Futures model serves a slightly different function to the current models, and is really representing an individual and their relationship with a specific provider. That is to say, all of their interactions over time with one provider would be associated with a single student entity within the database, whereas the same person at two different providers will be represented by two student entities within the same database. In practice this means that in the Data Futures model the HUSID becomes the primary key for students for a provider. As Data Futures is built on the principle of collecting data once, for all future interactions that provider would not need to return a new student entity, but simply link to the one already present. As HESA s requirement is primarily to link individuals to their relevant student identities over time, the focus of this activity becomes identifying the same person at different providers rather Page 1 of 5

2 than individuals who return to the same provider (as this simply extends the data already known about that student). As the HUSID is the primary key (PK) for a student at a provider, and the same person can interact with more than one provider, then the HUSID cannot be the mechanism for linking students across providers. This is because as a globally unique primary key the HUSID must be a different identifier for the individual at each provider they interact with. THE DATA FUTURES PROPOSAL To solve this issue, the first time a student is returned to HESA the HUSID supplied would become the persistent HUSID for that student. This is expected to be achieved through a derived field, to tie together current and all future HE interactions they may have. The persistent HUSID would then need to be returned by any provider with whom the student subsequently has an engagement. Note that an individual student could therefore have several HUSIDs assigned; one per provider with whom they have interacted, and these would be linked together through a single persistent HUSID. In the event of a student commencing studies at two or more providers around the same time, the one with the earliest Registration start date would be the one from which the persistent HUSID would be derived. In broad terms the current HUSID becomes the equivalent of the Persistent HUSID. The HUSID as it is currently known would be replaced by the Student Identifier (SID), which would be managed by the provider in much the same way as HUSID is now. The change of name for HUSID to SID here is to acknowledge the shift in purpose of this field, from global identifier to provider specific one. It is HESA s intention to no longer use the current HESA institution identifier but instead use the UK Provider Reference Number (UKPRN). The provider will need to supply the UKPRN as part of the SID to enable identification of the submitting provider. The Persistent HUSID itself cannot be used as a primary key by HESA as it is by definition not globally unique (given that a student would have the same number allocated at each provider they attend), and as it may not be possible for providers to always know if a student has received a persistent HUSID from another provider before they return registration details, not a viable option for providers to use this value as a primary key either. SID would therefore be comprised of: First 2 digits: Next 8 digits: Next 6 digits: Last digit: Year of entry into provider (last 2 digits of year) UKPRN 6-digit reference number internally allocated by provider Check digit Page 2 of 5

3 The SID would be returned by the provider and remains with the student throughout any interactions with the provider; effectively acting as the primary key for a provider to interact with HESA about a specific person. As the primary key for the student table the SID would be a globally unique value, allowing multiple providers to submit data about the same person, without HESA experiencing potential data protection or integrity issues. A lookup service would be available to aid providers in identifying any previous SID that the student has been allocated, which would then be submitted as part of their return as a personal identifier of type <persistent HUSID>. The provision of this data enables HESA to link people across providers more accurately whilst allowing providers freedom to engage with HESA using an identifier they have generated. A student that is returned to HESA would be expected to contain the following: - SID, calculated by provider based on HESA specified rules. Acts a primary key for that student for both the provider and for HESA - Provider s own identifier for student (OWNSTU), optionally to allow improved data integration back to the Providers own systems - Persistent HUSID = previous <PK> supplied by another provider where applicable - Any other student identifiers that are relevant / known by the provider for the purposes of identification and data linking Note that OWNSTU cannot reliably be used as part of this unique identifier; as current behaviour leads to changes within OWNSTU across years within an engagement, as well as duplication across students. It is therefore necessary to adopt a HESA-defined key. DATA MIGRATION AND CONTINUING STUDENTS For the migration of legacy data into the HESA data platform, it will be necessary to populate all completed and continuing students current <legacy> HUSID values, as the new SID in order to maintain continuity of these students as they pass through the system (however, it is not expected that any new legacy HUSIDs would be minted once this platform is live). Ideally all linking would be done through the supply of Persistent HUSIDs, however it may be necessary as a transition step to allow providers to submit legacy HUSIDs as part of their submissions, for students who have been allocated a HUSID with that provider. The full details of how to manage the migration of this data, and the transition period will be defined by HESA with input from stakeholders through the Alpha and Beta pilots. There is a question around how students with a HUSID but interactions with more than one provider will be catered for, and this will be considered as part of the Alpha and Beta pilot phases. When returning a student, the provider must supply HESA with the SID, and where it exists and can be identified the persistent HUSID. Page 3 of 5

4 The first provider to return this person would not need to return the same identifier as both the SID and the Persistent HUSID within the file, but would just need to supply the SID Where a provider latterly becomes aware that a student has a persistent HUSID, this can be submitted as new personal identifier data for the existing student. Where a SID is used in error the recourse would be to delete that student record and resubmit with the correct SID, as this is the primary key and cannot be changed. THE ENGAGEMENT ENTITY The current approximation within the existing collections is NUMHUS. There is a need to uniquely identify a specific engagement within the system. NUMHUS is unique for each Student (meaning a student can only use a given NUMHUS once, irrespective of how many engagements they have whilst several students can share the same NUMHUS). This is a 20-character identifier specified by the provider. The creation and population of these identifiers can continue to be generated in the same way and will continue to be called NUMHUS. HESA will take this supplied value and concatenate this with the SID of the relevant student to generate the primary key (EngagementID). This value will also be used to validate the collection of collaborative provision, where the receiving partner will need to return the EngagmentID that has been created to identify the relevant engagement at the other partner. MIGRATED DATA AND CONTINUING STUDENTS It will be necessary to carry over any allocated NUMHUS and assign them to the relevant engagements / and or registrations for both continuing students and those who have completed, as well as using them to pre-populate the EngagementID value by combining it with the SID (although it may be prudent to prefix them to ensure future uniqueness). It would be expected that any new engagements for existing students would need to have a new NUMHUS supplied, although it will be necessary to allow already allocated NUMHUS to be supplied for continuing students where necessary. The migration activity, and future allocations will need to take care to avoid issuing previously allocated NUMHUS values. When returning an engagement to HESA the provider will have to return the NUMHS and the SID. THE STUDENT REGISTRATION ENTITY This will need to be unique within an engagement and does not have an analogous value in the current student returns. HESA proposes to adopt a provider specified field, called NUMREG that is a 4-character field and unique to that specific engagement. Page 4 of 5

5 The globally unique identifier for a particular registration is comprised of the NUMREG, the NUMHUS and the SID. MIGRATED DATA AND CONTINUING STUDENTS As there is no equivalent in the existing data the options HESA has are to either default registrations to a value (which will then need to be known by the provider), or to ask providers to submit appropriate values to be used. These options will be discussed and tested through the alpha and Beta pilot phases. Whilst it expected that in general migration will result in one registration per engagement, there may some specific cases that require attention as result of the NUMHUS mapping question above. When returning a Registration; or any of its child entities such as Student Course Session, the provider will need to return the NUMREG, the NUMHUS, and the SID. Where a NUMREG is returned in error the appropriate response would be to delete that registration record and all its child records, and resubmit with the correct NUMREG. QUESTIONS AND FEEDBACK This document outlines the intended approach to be taken by Data Futures, however there are a number of questions to which HESA would like to hear stakeholder's opinions, so that this approach can be refined and improved through delivery. Specifically: - Should this identifier be called the SID, or retain the title of HUSID? - HESA has a preference for allowing providers to supply their own keys where practical, and would welcome conversation about whether use of a provider-defined SID could be generated instead of using the HESA specified structure above. - Under what conditions (if any) could there be an issue in retaining the SID over time for an individual across multiple (non-contiguous) engagements? This does not change system behaviour, but is important in consistent application and student counts - What services would providers like to see in supporting provision of persistent HUSIDs? For example, reports that flag up students who are likely to have a persistent HUSID. - HESA would also like feedback on the benefits or otherwise of not supplying the UKPRN as part of the Student identifier. Would it be preferable for providers to return a SID incorporating the UKPRN, in effect replicating the structure of the current HUSID? Any further questions or feedback on the viability of this approach, and the implications for providers is welcomed at liaison@hesa.ac.uk please specify Data Futures approach to identifying students: feedback in the subject line, as this will help the team filing the feedback. Page 5 of 5