What do we want to bring up with ESR?
SR requests and language.
COP reliance.
Do we disagree with the reason for the failure?
Bucket posts - 40 is “temp” limit set by ESR, based on the volume of duplicates in V1 of our interface. Three were conversations around raising this, but not concluded. Back to 2020. The old situation is not longer relevant.
Question whether ESR can cope with processing more than 40 applicants.
We were not able to match the numbers from DM, so why is this the case - are we looking at different things, so can not understand the real issue of 40+? Cannot check over 40 if not over 40.
Victoria and Craig involved.
Note terminology. “bucket post” is define differently. What do ESR mean as a bucket post?
In TIS a bucket post is multiple trainees attached to a post(?)
In ESR ?
Alerting us when there is a problem e.g. when files are quarantined? Either to us and Trusts.
What needs to change on TIS e.g. the use of bucket posts?
What improvement tickets are in play?
________________
Timeline
31st May - Received an email alerting
The current interface guide
ESR-NHS0111 - Streamlined ESR and Doctors in Training Interface Guide v5.0.docx
Digest of ESR feedback - latest date, first
Date | Content |
|---|---|
| The interface cannot load more than one applicant to a single position from a single file. Whilst we would not, in general, expect to receive more than one applicant, we recognise that there are cases where there may be a job share situation, so the system is designed to cope with this. It does so by splitting the file received from TIS into multiple files. The decision as to which file each applicant is assigned to being determined by how many times a TPN has been seen in a file, so all second occurrences of a TPN are placed in file 2 and so on. The APC files from these multiple files are then re-assembled before being passed back. There is a limit of 40 output files. This is because a single process holding multiple open files is very resource intensive. 40 duplicate TPNs is far beyond what should reasonably be in a single file, and it also represents a point beyond which processing the deanery file will start to have an impact on other processing. The underlying causes are twofold;
The first is an issue that the trusts must fix. If they choose not to follow the instructions, it is to be expected that the interface will not work. The second is an issue for TIS to fix. If TIS is sending the same record to the file multiple times, this is clearly a defect that needs to be fixed. |
|
|
| In terms of the 40 applicant limit, this isn’t something that we are in a position to change. In order to avoid problems with deadlocking on load, it is not possible for a single file submitted to ESR to contain multiple applications for a single position. In order to work round this issue, we read the files, and rewrite them into multiple files. The current limit of 40 means that the process could have 1 input file and 40 output files open at the same time. Having this many files open means that the processing is already very resource intensive, and increasing the number makes it more so. This then impacts on the performance of other interfaces. Given that the only reason that a file is going to exceed 40 records is either that there is a defect that is sending the same applicant multiple times (and creating multiple applicants for a single person isn’t something that we want to facilitate), or that Trusts have ignored the clear instructions that bucket positions must not be used (From ESR-NHS0111 section 5.1.3; “Note,it is essential that each DPN is established within ESR against an individual ESR position so positions are not used as ‘bucket’ posts to receive multiple applicants.”) , we wouldn’t look to implement changes that could potentially impact on payroll affecting interfaces simply to allow Trusts to disregard those instructions. |
| As has been mentioned on the SR, the three files have been quarantined. That means that the processing has found a defect in the file and rejected the whole file as a result. Where a file is quarantined, it is not processed further, none of the content is loaded, and there is no APC file that we can supply. As noted on the initial response, the issue here is that we found the same TPN more than 40 times in a single file. It is a fundamental of the interface that “Bucket” positions should not be used. There should be single occupancy positions. The process allows for multiple applicants to handle job-shares etc, but if there are 40 applicants being loaded for a single position, something is clearly wrong. Looking at the three rejected files, I can see two distinct problems. One is that there is clearly use of Bucket Positions with multiple applicants to each. The other is that in some cases the files contain the same applicant for the same position multiple times, clearly an error in the data coming from TIS. Some of the Positions that are affected are; LDN file;
KSS File;
PEN File;
If your developer reviews the files that were sent to ESR, they will be able to see these examples, and many others (I simply imported them into Excel, sorted and did a count). |
Other information
What | |
|---|---|
Copy of response from ESR Support to a Trust on them raising an SR around missing date |
|