ESR Integration (2018 ETL version)

Victoria confirmed that ESR is built to accommodate this scenario, as long as the post setup has been completed and a post is set to ‘shared’ or the field is left null. Victoria highlighted that the setting for single incumbents, (which would prevent the creation of multiple post holders in ESR) is rarely used.
Could you explain if this is normally current practice by Trusts?

WB:

Setting of 'shared' enabled on the Position created by the Lead Employer.

Per trust you can have multiple person in the same posts. The 'shared' setting is per Trust. Each Trust if using the same Deanery Post Number has to enable the setting for the Trust the position information record is being created against.

VPD - Some trusts set up multiple VPD's e.g. CCGS's they might want that held on separate VPD. Separate ESR accounts can be setup per Trust. E.g. 4 separate accounts to do different things by the same Trust.

Victoria briefly explained that a single DPN could exist within two ESR VPDs at one time, but the DPNs should always have an ESR Position Number and Position ID on the outbound file, which would make each post record unique. This is particularly common where there is a lead and host employer situation.
Could you explain the current process in practice by trust?

WB:

Sometimes they are in Error.

Sometimes they have to be duplicate. Each one will get created with a unique Position Number on ESR regardless it is per Trust or across different Trusts.

Lead Employer Trust - Set up all posts on ESR when they receive notification from HENE.

Host Employer - Also setup their posts there as Hosts rather than leads.

When Hosts create their posts numbers, then the identification is whether it is a L/H posts.

Different ESR Position numbers on although DPN/NPN may be the same.

Does Intrepid knows the distinction between Lead and Hosts posts?

When posts created on Intrepid, this information would have been keyed in?

All posts created on ESR 72 hours at least

DPN already on Intrepid ahead of them being on ESR.

WB:

Yes.

• Position Number (Unique to ESR? - Yes,

Is this the actual Post Number entered on Intrepid? - No)

• NPN/DRN - L/H entered to denote if Lead or host type post.
• ODS Code - It is where the post belongs to for Workforce Statistics, Reporting purposes only.
• Is this used to identify unique NPN on Intrepid so that the correct trainees are matched to placements against the correct Trust? - No

What do employers (Lead/Host) do with Oriel access?

WB:

Wendy took an action to find out how/what trusts do with Oriel Access? E.g. there are documents that can be accessed/downloaded how are these used.

Gwilym Williams - We make the changes in Intrepid but I'm not sure how ESR is updated based on those changes. I believe they only get the person data up until the start date of the placement in that Trust

WB NE:

Changes automatically accepted in Intrepid from ESR for personal details changes.

Placement changes should be done in intrepid then fed to ESR.

Personal details changes should be done on ESR then fed to intrepid.

Tom de Salis (WM): 
We would not pull placement data from ESR, we would only send it the other way. SLA is to have the placements on Intrepid by 12 weeks before the start date, ESR's limit is 2 days prior to start date.

Dale Gilbert (NW):
In HENW we put the placements onto Intrepid and then run reports for our Lead Employer so they can then add them to ESR. We used to use the ESR / Intrepid interface for one of our Lead Employers ( and were planning on setting up the other ) but it was switched off due to a request from the Lead Employer.  The Trusts have minimal access to Intrepid here - mostly for Foundation.

Mairi Hills (HETV)
In HEETV, HEE admin inputs placements into Intrepid and the trusts do use the ESR/Intrepid Interface

WB NE:

Placements should be imported from Intrepid to ESR.

SLA is common for everyone. If the placement changes has not been made on Intrepid within the SLA, then it has to be done manually to ESR and Intrepid.

PH not brought across from the Interface because of the difference in type of contract. PH are 37.5 (Agenda for Change) Hours a week whist others are 40 Hours a week. PH trainees/rotations keyed in directly onto ESR and rotated on ESR and no interface.

Cannot currently have duplicate contract types on ESR. Cannot have 37.5 and 40 hours types contract.

WB:

Positions created on ESR - they get a report, Establishment form from Information team which is used as a basis to enter the Posts onto Intrepid then ESR.

Positions are actual Posts with DPN's

Assignments - A person assigned to the Post.

WB

MSO will always be assigned to each individual per VPD.

1 trusts can have multiple VPD's and therefore different MSO's for each VPD.

Various scenarios as detailed by VH:

The Medical Rotation Notification produces a spreadsheet with details of the organisation’s training post, the current incumbent and the next person to occupy the post.

The Applicant Withdrawn notification should only be generated for an applicant already sent from TIS to ESR with a start date in the future.

The Replacement Applicant should only be generated in the same circumstances as the App Withdrawn notification.

The Change to Projected Start/End Date notification should only be generated for an applicant already sent to ESR with either their hire OR end date in the future.

Notification types:

‘1’ - “Medical Rotation Notification”
‘2’ - “Update to Medical Rotations – Applicant Withdrawn”
‘3’ – “Update to Medical Rotations – Replacement Application””
‘4’ – “Change to Project Hire/End Date”
‘5’ – “New Training Position Created within LETB System”

Mandatory/Conditionally Mandatory Fields Expected in the Notifications Export File:

• Record Type
• Notification VPD
• Notification Title Code
• Deanery Post Number (1,2,3,5)
• ESR Position Title (1,2,3,4)
• (Current) Trainee Last Name (1,4)
• (Current) Trainee First Name (1,4)
• (Next Appointment) Trainee Last Name (1)
• (Next Appointment) Trainee First Name (1)
• Withdrawn Trainee Last Name (2)
• Withdrawn Trainee First Name (2)
• Withdrawn Trainee GMC Number (2)
• Replacement Trainee Last Name (3)

A current picture, positions as at that date and people that are in their current positions as at that date - snapshot of.

No historical view sent.

It is a support mechanism rather than intended business as usual functionality added to Intrepid.

Not BAU.

What is the difference between an RMT, RMF and RMR file?

What does each of them consist of? Positions for all LO's? or for per Trust?

RMR is sent from Intrepid/TIS per Trust to ESR.

RMT - Generic name by the process.

RMF - Run in full mode - it is the full file request Outbound file.

RMC - Run in change mode

VH: The RMF Outbound files are produced in old Deanery Regions, so you will get one per organisation:

• WMD   West Midlands
• NTH   Northern
• KSS   South East Coast
• SEV   Severn
• PEN   South West
• WES   Wessex
• OXF   Oxford
• EMD   East Midlands
• NWN   North West
• MER   Mersey
• YHD   Yorkshire and the Humber
• EOE   East of England
• LDN   London

• Identify the changes automatically.
• Find trainees where Placement dateFrom is 13 weeks 3 months in future. (new post holder - next trainee)
• Find placement/trainee for the above post placement where Placement dateTo is 13 weeks 3 months. (current post holder - current trainee)

Current post holder above could be empty.

• This is also accompanied with a record in the APP file. 

• This is event driven and achieved by changing trainees’ placement details in TIS UI.
• When an admin assigns a new placement to a trainee, the changes are tracked on TIS.
• Here we are considering swapping as two independent placements changes taking place. Our understanding as confirmed with ESR is that TIS does not need to identify it as a swap but send them distinct changes taking place on each NPN.

• Post becomes vacant for current or next rotation. i.e. no trainees are due to occupy the post in the current or next rotation.
• Vacant Post: any post with placement ending 3 months in future from today minus 1 day without having any future (in the next 3 months) placement is vacant. 
• Restriction on ‘3 months in future today minus 1 day’ is important to avoid sending repetitively the same post as vacant to ESR.

The DNF (Full Notification) file provides a snapshot of current and next trainees with their placement details for all Posts/NPNs that exist on ESR and have previously been communicated to TIS. This full notification file is generated on a Local Office by Local Office basis where required.

• Deleting a placement on TIS from the UI

3 (achieved by technically coupling a 2 followed by a 1)

• This was not handled in the Intrepid-ESR interface.
• This is being handled differently in TIS following conversation with ESR. A replacement is a combination of Notification type 1 sent following a Type 2. The Type 1 being the latter notification informs ESR what is the current and next trainee following the withdrawal.
• On TIS, creating another placement with a DPN/NPN that has no future incumbent following a withdrawal is tracked as a replacement.

• When a placement is edited and project hire and/or end date are changed in TIS UI, this is tracked.

• This is sent in the notification file when new Posts are created within TIS.