Support issue raised 31 May

27 Jun 2024

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;

1. The use of bucket positions, where multiple individuals are assigned to a single position (it appears that all GP trainees in a particular area are assigned to one position). This is contrary to the guidance that we give that “bucket” positions must not be used.

2. Cases where the file contains multiple applicant records for the same applicant to the same position.

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.

07 Jun 2024

• No other files have gone into quarantine

• Trusts do indeed have account managers, however their role is in ensuring that Trusts make the best possible use of ESR, and assisting them to implement functionality that they don’t currently use. Account Managers don’t become involved in support issues, and where a trust attempts to involve them, they are redirected back to the SR process.

• I attach the current version of the document, which has been uplifted by a couple of versions following periodic reviews, but has had no substantial changes since TIS went live./

06 Jun 2024

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.

05 Jun 2024

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/RJZ01/030/STR(H)/001 – not actually a cause of rejection, but there are 27 applicant records from only 3 individuals

• LDN/BARNET/800/LT/001 – again, not a cause of rejection, but clearly a bucket position with 26 distinct applicants

• LDN/BDH/800/LT/001 – caused the file to be rejected, 42 applications from 41 individuals

• LDN/BEXLEY/800/LT/001 – not a cause of rejection, but clearly a bucket position with 24 applicants

• LDN/BROMLEY/800/LT/001 – not a cause of rejection, but clearly a bucket position with 15 applicants

• LDN/CMIDDLE/800/LT/001 – not a cause of rejection, but clearly a bucket position with 28 applicants

• LDN/CROYDON/800/LT/001 – not a cause of rejection, but clearly a bucket position with 31 applicants

• LDN/ENFIELD/800/LT/001 – not a cause of rejection, but clearly a bucket position with 39 applicants

• LDN/R1HNH/IMT/LT/004 – not a cause of rejection, but the same applicant 6 times

• LDN/R1K01/017/HTP/001 – not a cause of rejection, but 6 applications from 2 candidates

• LDN/RFREE/800/LT/001 – not a cause of rejection, but clearly a bucket position with 38 applicants

• LDN/RJZ01/030/F2/005 - Not a cause of rejection, but same applicant 14 times

• LDN/WHIPPS/800/LT/001- caused the file to be rejected, 44 applicants

• There are dozens of other similar examples in the file

KSS File;

• KSS/CHICH/800/GPSTR/001 – caused the file to be rejected, Bucket position with 2 applications each from 27 individuals, 54 applicants in total.

• Again, there are many similar cases in the file that are not over the limit

PEN File;

• PEN/GP-EXET/921/GPST/001 – caused the file to be rejected, bucket position with 48 distinct applicants.

• Again, there are many similar cases that aren’t actually over the limit. 

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

Copy of response from ESR Support to a Trust on them raising an SR around missing date

We are aware that there have been issues with the Junior Doctors interface and a number of applicants not loading.

This was raised with us by HEE on 4th June. It has been investigated, and HEE were advised on 5th June that the data sent to ESR was incorrect and could not be processed.

We have advised HEE of what needs to be corrected to ensure that applicants can be loaded.

As the interface is working correctly, this isn't something that we can fix