Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

Page Content:


TIS-ESR Interface - Inbound and Outbound Flows

This is a simplified version of the Business Process Model for the MVP implementation of the TIS-ESR Interface. Please note there is no bi-directional flow of applicants information from ESR to TIS, i.e. any changes made to trainees personal details on ESR does not currently update any fields on TIS from a downward flow. 




Key


Journeys and Expectations of the TIS-ESR Interface

Below is an outline the agreed system behaviours between TIS and ESR, when operating the Streamlined Doctors in Training interface. For further clarity, a number of Working Assumptions are documented following the discussion. This only came to light to TIS from ESR post implementation on the 02/01/2019 following a number of issues encountered.

No.ScenarioExpectation of the TIS-ESR Interface
1

Post record from ESR successfully matches in TIS. Does TIS automatically assign a new set of ESR position details to that post/DPN

TIS will match the ESR position data against the TPN already captured within TIS and subsequently release applicant data for relevant trainees.
2

Post in ESR (DPN) does not match a post in TIS (TPN) – i.e. post set up within ESR, but DPN incorrectly keyed

This will be classed as ‘unmatched pending’ status and will be included on the Exceptions Report.

3

Applicant appointed to a new post, which does not meet mandatory data standards – i.e. missing at least one mandatory field)

Applicant Details are included in the category ‘missing mandatory fields’ in the Exceptions Report and would not be sent to ESR.

4

Applicant appointed to a new post in TIS (meeting minimum data standards – i.e. contains all mandatory fields) , which has not been set up in ESR i.e. no position record passed from ESR to TIS?

No record can be passed to ESR as ESR has not provided details as to where the applicant should go, i.e. DPN is not set up against a position in ESR yet. Once the DPN has been set up in ESR and details passed through into TIS in the changes file, then the applicant will be automatically released on the same day.

5

Applicant appointed to a post (meeting minimum data standards – i.e. contains all mandatory fields) in TIS, which has a lead employer but no host (Lead Employer has correctly set up the DPN) If TIS has ESR position details for the Lead set up against this post then applicant will go wherever the attached ESR positions are, lead or host?

The Applicant record will go to the Lead Employer in this example.

6

Applicant appointed to a post (meeting minimum data standards – i.e. contains all mandatory fields), which has a host employer but no Lead (Host Employer has correctly set up the DPN) If TIS has ESR position details for the Host set up against this post then applicant will go wherever the attached ESR positions are, lead or host?

The Applicant will go to the Host Employer in this example.


7

Applicant appointed to a post (meeting minimum data standards – i.e. contains all mandatory fields) which has BOTH a lead and host employer (Both Trusts have the post correctly set up in ESR and position data matches) If TIS has ESR position details for the Host and Lead set up against this post then applicant will go wherever the attached ESR positions are, lead or host?

The applicant will go to both the Host and Lead employer in this example.

Note: Within the example issues currently under investigation evidence suggests that this is not necessarily the case.

8

Applicant appointed to a post (meeting minimum data standards – i.e. contains all mandatory fields) but fails processes in ESR. Can we assume that TIS will highlight the errors to the user so that they can address the issues and re-send? What happens when ESR sends the Error/rejection message sent back to TIS (APC file)?

The failed applicant record will be highlighted to the user via the Exceptions Reports. They should address the issues with the record, but it should be noted that they cannot ‘resend’ applications to ESR manually after correcting the issue. If there is an position or DPN that needs correcting in ESR, then the assumption is those changes are sent to TIS in the change file and this should generate the applicant export record for this post the next time it runs. If a position is closed and a new one created to replace it, then a delete indicator will be sent on the RMC and RMT file against the original Position record that has been closed.

9

Applicant previously sent successfully to ESR withdraws from their appointment to a placement because they are going Out of Programme (more than 2 days before their projected hire date).

The TIS notifications process will generate an update for the ESR user.

10

Applicant is a replacement to someone previously appointed to the same post for the same/similar start date at either the lead or host employer (Naturally this will create a notification in ESR too)

As above.
11

Applicant is a flexible trainee appointed to a post that the employer has already received an applicant for the same post with same/similar start date (ESR can handle multiple appointments to the same post).

TIS should send the relevant applicant records to ESR. ESR will then process both in terms of receiving applicants (as long as position is ‘shared’).

12

An Applicant previously sent to ESR has their projected hire date changes in TIS.

Medical Rotation Notification and the Update to Project Hire Date notification would be initiated by TIS and changes sent to ESR.

13

An Applicant previously sent to ESR has their projected end date changes in TIS.

Medical Rotation Notification and the Update to Projected End Date notification would be initiated by TIS and changes sent to ESR.

Working Assumptions (02/01/2019)

Following the discussion above the NHS ESR Teams working assumptions are as follows:

  • In line with the Code of Practice, Applicants are input into TIS at least 3 months before they are due to start their next training placement.
  • ESR becomes the master for Applicant data at the point a record is successfully created – no further changes to the application record can be made by TIS once it has been created within ESR. As such, changes to person details (such as Address) and projected hire and end dates will be dealt with manually within ESR.
  • The presence of a DPN is a condition of release for the Applicant Record provided this hasn’t been sent before, but should not be considered a trigger for subsequent transfer for the applicant record.
  • TIS always sends Applicant data to ESR, if the following conditions are met:
    • There  is a matching DPN between ESR and TIS
    • The Doctor in Training record is completed in TIS with ALL mandatory fields
    • There is between 3 months and 2 days before the Projected Hire Date
    • The post is a hosted OR lead employer position
  • TIS will never resend the Applicant data into ESR, even if the previous application failed to load successfully. It was noted during the meeting that this assumption will cause support issues and needs reviewing, as Intrepid had a function to ‘resend’ applications.
  • TIS does not accommodate a process where applicant data can be manually ‘resent’ by the user, so Applicants that fail to load within ESR may have to be manually keyed in via the Direct Hire process in ESR. See above point for concerns.



  • No labels