Further Guidance on PGR Collaborative Supervision Arrangements

The purpose is to capture all cases where there is a formal collaborative arrangement to provide doctoral research training for a student or students. This could include anything from a large Doctoral Training Partnership or Centre for Doctoral Training, to a student on a Knowledge transfer Partnership, or a co-tutelle de thèse or other joint supervision agreements for a single student. These collaborative arrangements only need to be returned where there is a formal agreement and there would usually be an exchange of funds in recognition of the supervisory effort taking place.

Two scenarios have been identified which could include formal joint supervision:

1) Concurrent collaboration or joint supervision

This is where a student is being supervised by supervisors at more than one provider during the same academic session. Only the lead provider should be returning the student's data.

2) Sequential collaboration

This is where a student commences studies with one provider and subsequently moves to a different provider to continue their studies as part of the same programme. For examples these could be students who study for a one-year MRes followed by a PhD, or those who join a collaborative PhD programme where the lead provider is not determined until after year one.

Concurrent and sequential collaboration have different approaches to reporting within the HESA Student Record.

This document is split into two sections to first show how these arrangements would be reflected in the curriculum data and then how this would be reflected in the student data.

Flow diagrams have been drawn up to help with decision making and reporting of collaborative provision. This includes details on whether or not you are the right provider to return a student and the 'hand-over' procedure for sequential collaborations.

Diagram 1: Are you the correct provider to return the student?

You must meet all three conditions listed below to include a concurrent supervision arrangement in the SupervisorAllocation.SUPALLID field:

1. It is a formal arrangement.
2. You are the lead partner.
3. There is supervision by yourselves with another provider / overseas provider / partner in industry.

If you only meet one or two of the above conditions, do not return the student to HESA.

Diagram 2: Hand-over procedure for sequential collaborations

RECORDING THE CURRICULUM DATA

Concurrent and sequential collaboration

Where there is a formal collaborative arrangement to provide doctoral research training, this should be reflected in the CourseRole entity to show the providers that are involved in this collaboration.

Where CourseRole.ROLETYPE = 202 ‘Delivery organisation’, this records the providers that are involved in the supervising the students.

For sequential collaborative arrangements, the delivery organisations returned should reflect the breakdown for just the time at the reporting providers, rather than the breakdown for the full programme. The Qualification.QUALCAT returned would reflect the student's overall aim, rather than the aim at the first provider.

Examples

Example 1- concurrent supervision

A concurrent collaborative arrangement is in place between Poppleton University (UKPRN: 11111111) and Poppleton College (UKPRN: 22222222) where Poppleton University is the lead provider and delivers 75% of the supervision. Poppleton University would return the data to HESA as the lead provider and would record the collaboration in the CourseRole entity.

The University of Poppleton is recorded as a delivery organisation with a proportion of 75% and Poppleton College is also recorded as a delivery organisation with the proportion of 25%.

Example 2- sequential collaboration

Poppleton College and Poppleton University run a collaborative course where students complete an MRes at Poppleton College before transferring to Poppleton University to complete their PhD.

Poppleton College would return the student for the first year and so would return the following CourseRole information.

The CourseRoles reflect the proportions only for the time at Poppleton College.

The Qualification.QUALCAT would be M0004 ‘Taught masters degree designed specifically as a training in research methods and intended as a preparation for a research-based higher degree’ as this is the aim of the course at Poppleton College.

Once the students transfer, they would be returned by the University of Poppleton who would return CourseRole information and Qualification.QUALCAT only reflect the time spent at the University of Poppleton.

RECORDING THE STUDENT DATA

Concurrent collaboration

Where a student is being supervised by more than one organisation, only one provider should return the student in order to prevent double counting.

In the majority of cases, there would be the concept of a ‘lead provider’ for individual students. Where a lead provider exists, they must return the student. Where no such concept exists, a single provider should be nominated for this purpose.

Joint supervision is recorded in the SupervisorAllocation entity, which is associated with the StudentCourseSession.

This entity has the following fields:

• REF2021UNITOFASSESSMENT: records the Unit of Assessment for the supervisor. Where the supervising organisation is not eligible to submit to the REF, for example if they are an industry partner or non-UK provider, a UOA is not required.
• SUPALLID: records the supervising organisation. In most cases, a UKPRN would be returned. Where the organisation does not have a UKPRN, generic valid entries are available in the field.
• SUPALLPROP: records the proportion of the full StudentCourseSession's activity that the SupervisorAllocation relates to, rather than relating to a particular reference period.
• SUPALLID: identifier for the entity, defined by the provider.

The entity is repeated once for each unique combination of UOA and supervising organisation. 
The proportions for a given StudentCourseSession should add up to 100.

Sequential collaboration

In cases of sequential collaboration, reporting responsibilities can be passed from one provider to another where the student transfers. A typical example would be where a student is taking a one-year MRes followed by a PhD.

Where a transfer occurs, the Engagements returned by each provider need to be linked and so a number of data items need to be returned to enable this linking.

If the student is returned by one provider and then transfers to a provider that is not in the HESA constituency, the first provider must continue to return the student using the SupervisorAllocation entity to record the supervision (see concurrent collaboration above).

The reporting required for transferring reporting responsibilities differs between the first and second provider.

Reporting for the first provider

When the student leaves the first provider, the Engagement must be closed by returning the Leaver entity with the following data:

• Leaver.RSNENGEND: The reason for Engagement ending must be returned as 12 ‘transferred out as part of collaborative supervision arrangement’.
• Leaver.ENGENDDATE: The end date must be recorded as the date that the reporting responsibilities transfer to the second provider.
• Leaver.INTENDEDDESTINATION: the UKPRN of the second provider must be returned. 
  This must be the UKPRN of a provider in the HESA constituency as they will need to return the Student to HESA from this point.

If there are any interim awards, a QualificationAwarded entity is returned to record this.

Reporting for the second provider

Where reporting responsibilities for a student on a collaborative supervision arrangement changes, the second provider must return information in the CollaborativeProvision entity to link to the previous provider's data.

• CollaborativeProvision.PARTNERUKPRN: The UKPRN of the provider the student has transferred from
• CollaborativeProvision.PARTNERSID: The Student.SID returned for the student by the previous provider
• CollaborativeProvsion.PARTNERNUMHUS: The Engagement.NUMHUS returned for the Engagement by the previous provider.

In addition, the Engagement.ENGSTARTDATE must be returned as the date that reporting responsibility transferred to the second provider and so should align with the Leaver.ENGENDDATE returned by the first provider.

The second provider must return an EntryProfile but the information should not be updated to reflect the student's study at the first provider. For example, the highest qualification on entry should not be updated to reflect an interim award from the first provider.

Impact on the Graduate Outcomes survey

Where Leaver.RSNENGEND = 12, students are excluded from the Graduate Outcomes population. This means that if a student is awarded an interim award when they transfer to the second provider, they will not be included within the Graduate Outcomes survey.

Examples

Example 1- concurrent supervision

A student studies in a formal collaborative arrangement where there is concurrent supervision:

• Poppleton University provide 70% of the supervision
• Poppleton College (UKPRN: 22222222) provide 30% of the supervision

The supervision responsibilities change in the second StudentCourseSession with Poppleton College increasing their share. As the example is illustrative only the two StudentCourseSessions are included.

StudentCourseSession 1:

 StudentCourseSession 2:

 Poppleton University is the lead provider and is responsible for reporting the student to HESA. Poppleton College would not return the student.

The SUPALLID field is left blank for the portion of the supervision that is undertaken by the reporting provider as it is not necessary to report your own UKPRN. The UKPRN of Poppleton College is reported in the second occurrence of the SUPALLID field.

Example 2- concurrent supervision

A student is studying on a PGR programme that will have joint supervision however in the first year all supervision is through Poppleton University. In the second year there is concurrent supervision and a formal arrangement between Poppleton University and Poppleton College (UKPRN: 22222222) to share supervision. As the example is illustrative only the first two years of the programme are included. Poppleton University would return the following:

StudentCourseSession 1:

In StudentCourseSession 1, only 1 provider is supervising the student (and in only 1 Unit of Assessment) so one SupervisorAllocation is returned with a proportion of 100.

StudentCourseSession 2:

In StudentCourseSession 2, 2 providers are supervising the student and so an additional SupervisorAllocation entity is returned.

Example 3- concurrent supervision with a partner in industry

A student is studying on a PGR programme with Poppleton University where there is concurrent supervision with a private partner in industry (SUPALLID = 5043) for the second year. As the example is illustrative only the first two StudentCourseSessions are included.

Poppleton University would return the following:

StudentCourseSession 1:

In StudentCourseSession 1, only 1 provider is supervising the student (and in only 1 Unit of Assessment) so one SupervisorAllocation is returned with a proportion of 100.

StudentCourseSession 2:

In StudentCourseSession 2, 2 organisations are supervising the student and so an additional SupervisorAllocation entity is returned.

The Unit of Assessment field is not required for the partner in industry as they are not eligible to submit to the REF.

Example 4- sequential collaboration

A student studies their first year of a 1+3 course at Poppleton College (UKPRN: 22222222) before transferring to Poppleton University (UKPRN: 11111111) for the final three years to complete their PhD. Reporting responsibilities transferred on 2020-08-01.

Poppleton College would return:

This indicates that the student has left Poppleton College due to transferring to Poppleton University as part of a collaborative supervision arrangement:

• Leaver.RSNENGEND: the reason for ending is transferring as part of a collaborative supervision arrangement
• Leaver.ENGENDDATE: the end date records the date that reporting responsibility transfer to Poppleton University
• Leaver.INTENDEDDESTINATION: the intended destination records Poppleton University's UKPRN as that is where the student is transferring.

The Engagement expected end date reflects the end date for the full Engagement and so shows that the student is intending to finish in four years.

Poppleton University would return:

Poppleton University assigns its own Student.SID and Engagement.NUMHUS.

The UKPRN, SID and NUMHUS from Poppleton College are then returned in the CollaborativeProvision entity in order to link the two Engagements.

The Engagement start date is the date that reporting responsibilities transferred to Poppleton University and so should align with the Leaver.ENGENDDATE returned by Poppleton College.

Poppleton University would also need to return an EntryProfile which would not be updated from the information originally returned by Poppleton College.

Example 5- concurrent and sequential supervision with a non-UK provider

Poppleton University have a collaborative course with a non-UK provider where students transfer to the non-UK provider part way through their studies to complete the joint qualification.

In the first year there is joint supervision between Poppleton University and the non-UK provider (SUPALLID = 5049).

Two SupervisorAllocation entities would be returned.

For the non-UK provider, a UOA is not required as they are not eligible for the REF.

After two years at Poppleton University, the student transfers to complete their studies being supervised wholly by the non-UK provider. As the non-UK provider does not submit data to HESA, the sequential method of reporting cannot be used i.e. Poppleton University have to continue to return the student rather than transfer reporting responsibilities.

One SupervisorAllocation entity would be returned for the subsequent StudentCourseSession:

As the student is being supervised by one organisation (in one Unit of Assessment), only one SupervisorAllocation is returned with a proportion of 100. As the organisation is not eligible to submit to the REF, there would be no UOA returned.

Throughout the student's Engagement, the CollaborativeProvision.COLPROVTYPEID field would be returned as the Engagement is part of a formal collaborative arrangement with a non-UK provider. The field would be retuned as 01 if the student studies mainly in the UK for the Engagement or 02 if the student studies mainly outside the UK for the Engagement.

In this scenario, the other fields in the CollaborativeProvision entity would not need to be returned as they are only returned where reporting responsibility transfer between providers.