To assist with the understanding of how and why Entry Profile coverage rules will trigger, this is the methodology used by Data Quality analysts when creating the rules. Information has been included about how rules may over trigger, which may require a tolerance.
Entry Profile coverage rules principles
The following three principles are used when developing Entry Profile coverage rules:
- An EntryProfile field must be returned where the earliest child entity falls in to coverage as EntryProfile relates to information on entry to an engagement.
- An EntryProfile field must not be returned where the earliest child entity falls outside of coverage as EntryProfile relates to information on entry to an engagement.
- EntryProfile coverage validation rules will only run where the EntryProfile has been submitted in the file (not pulled forward from previously returned data).
Note: ‘earliest’ means we aim to look at the position in the first reference period that the Engagement was returned, as the data is on entry to the engagement.
For example, the CARELEAVER coverage for Wales states “All EntryProfile entities at providers in Wales where EntryProfile.UCASSCHEMECODE exists and (Qualification.QUALCAT starts with H, I, J or C or is M0002, M0016 or M0018) and Engagement.ENGSTARTDATE is after 2013-07-31 and before 2014-08-01, except where Engagement.INCOMINGEXCHANGE exists or (Leaver.ENGENDDATE - Engagement.ENGSTARTDATE <= 14 days and RSNENGEND = 03, 05, 11, 12).”
In this case, the QUALCAT code from the first (earliest) StudentCourseSession associated with the Engagement will be used (Z_QUALCATORIG) in the coverage validation.
Use of historic data
Following principle 1, the aim is to look at the position of the Entry Profile data on entry to the engagement. However as the history data only looks back up to 4 years, this might not always be possible. There could be a scenario where an engagement is 5 years or longer in length. If the Entry Profile data is re-returned in the fifth year or later, then the Entry Profile coverage rules may trigger against a subsequent year (not the on-entry year). In these cases, a tolerance override will need to be requested.
In scenario 1, when EntryProfile.PARED data is re-returned in year 5, reference period 1 (Y5 RP1), the ‘earliest’ StudentCourseSession.INTERCALATION that the history data can ‘see’ is from Y2 RP1 which would mean that EntryProfile.PARED data appears to fall outside of coverage. In this case, validation would trigger to say that EntryProfile.PARED data has been returned outside of coverage and that it should be removed. A tolerance override request would be required as EntryProfile.PARED data was in coverage on entry to the engagement (Y1 RP1).
There is an exception, where the rule needs to consider Qualification.QUALCAT, Z_QUALCATORIG will be used instead. Therefore, it will always refer to the earliest QUALCAT regardless of how long the course is.
Correcting Entry profile data
Following principle 3, entry profile coverage validation is run on submitted EntryProfile data. However, it is not known if the re-returned EntryProfile data is being submitted as a correction or due to a course transfer within the same StudentCourseSession.
In scenarios 2a and 2b, earliest Qualification.QUALCAT will be established by using Z_QUALCATORIG, which looks at the original returned Qualification.QUALCAT code.
In Scenario 2a, regardless of whether this was a correction to the original SCS1 Qualification.QUALCAT value or a transfer to a different course, the validation rules would not trigger to require the removal of the EntryProfile.CARELEAVER value. Using Z_QUALCATORIG, validation would consider Qualification.QUALCAT = H0003.
In scenario 2b, even if this was a correction to the original SCS1 QUALCAT value the validation rules would not trigger to require the addition of the EntryProfile.CARELEAVER value. In this case, validation would consider Qualification.QUALCAT = H0009
These scenarios will impact the EntryProfile fields that use fields from sub-entities such as Qualification.QUALCAT, StudentCourseSession.INTERCALATION, CourseInitiative.COURSEINTID and SessionStatus.STATUSCHANGEDTO in the coverage statement.
