Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Reconcile the Inbound Positions from ESR against Posts in TIS to make sure that both systems match.
  • Send Placements from TIS to ESR for future posts, this includes sending new starters who have never been placed before.
  • Receive Trainee profile updates from ESR to TIS,
  • Send Placements updates from TIS to ESR where changes occur after they've been sent to ESR.
Infonote
[Ashley - something about system age – venerable, given NHS great benefits but…..

...

Whilst the benefits derived from the integration have been extensive to the NHS Employer organisations, it is limited to what it can provide when compared to modern interfaces in many respects. We recognise that the historic framework contracts ESR has had are ineffable and makes it difficult to react into current practice.  


false
Info
icon
Note

Recognise that historic framework contracts are ineffable which makes it difficult for ESR to react/move into current practice }

[Ashley – could you add a para about work to date – replacement of Intrepid interface}

...

  • As part of the TIS solution, a replacement for the Intrepid-ESR interface was developed to carry on the automatic transfer of junior doctor placement between TIS and ESR to avoid a downgrade in the service when switching to TIS. The Minimum Viable Product (MVP) included exchanging trainee placements, changes to their placements by way of notifications to ESR and data quality reports generated where gaps in the data are identified. This is also known as the one-directional flow. The TIS-ESR interface involves exchanging of files generated by either parties in a sequential order every evening via scheduled jobs similar to the Intrepid-ESR interface. The specification provided to TIS to integrate with ESR was largely one that was developed between Hicom, ESR and IBM. This method is known to have several issues.


Infonote
iconfalse
Need a sentence or so on uni- to bi-directional flow – which has prompted this doc)

...

  • Deanery Update Interface/Deanery Reconciliation and Medical Trainee Outbound Interface
  • Deanery Inbound Recruitment Interface
  • Generic Inbound Notification Interface


Infonote

The diagram in attachment 1 illustrates these interfaces points and associated data flows. (attach from confluence}]


...

The current “interface” between TIS and ESR is essentially and file transfer and import into the various data storage arrangements. It is this approach which generates issues in two key areas:

Data transfer approach

false
Info
icon
Note

the use of ftp within N3 (Chris expand please) has a number of inherent issues:

  • Security – ftp not secure, N3 not secure (Chris please expand)
  • N3 ending – NHSD are replacing N3 (expand and reference)

Associated risks – data loss, etc (Ashley please expand)

...

The current approach requires the import of data from a delimited file. This is essentially a text file with a record per line with the end of record indicated by a marker (a comma or pipe symbol).

Infonote
iconfalse
This traditional approach contains many points for potential error – markers missing, etc etc (Ashley/Chris please expand on tech and bus process issues)

...

  • Issues where markers are either missing or use of other special characters in the file rendering the whole of it invalid and therefore not processed
  • National Post Numbers not matching the format that TIS expects and use of special characters breaking the processing of the file
  • Limitation of ESR to handle retrospective reference data that would have been correct at the time of recording on TIS but not acceptable to ESR as they only expect a specific version of the reference data.
  • Limitation of ESR to handle trainee placements information beyond 3 months future time projected hire date
  • The exchange of notifications,e. changes to placements subsequent to them being transferred to ESR being inadequate. The changes to placements are not exchanged in real time but relies on changes audited for the day to be built and sent in a file at the end of the day. The changes are limited to only 5 different types of notifications that ESR can infer. E.g. a medical rotation is due to take place against a post, an applicant has withdrawn/replaced from a post etc.
  • If for some reason, there is an outage, it involves a lot of manual work by an experienced individual to process the backlog of files to bring the interface back up and sync the data
  • The time at which the files are currently exchanged are out of normal working hours, which means if there are issues, they are not noticed until the next day
Infonote
Associated risks – data accuracy, (Ashley please expand), the implications of the above issues are detrimental to data quality in many ways;

...

Timeliness – the current approach is essentially a “bulk” import and export of data this means that data are processed on a daily/weekly basis, with an inherent “lag” in the systems (the time taken to export and import data) of 24 hours plus, this carries a clear number of usage risks.


Infonote
Associated Risks – delay in record update – payroll etc (Ashley please expand I think I have covered this above)

...

The team can increase the levels of data validation (filtering/checking), however the underlying issues will remain.

Infonote
[this needs tidying and expanding – I’ll do it after you’ve contributed]

...

As the team are unaware of the future development program for ESR the above question is one that the TIS team cannot address.

Infonote
[this needs tidying and expanding – I’ll do it after you’ve contributed]

...