Introduction

Build out a high level description of each service to complement the Application Architecture diagram

GMC Sync

Summary

A springboot application which runs nightly to retrieve a basic Doctor dataset from the GMC to refresh the Revalidation service.

Where and When

The application has its own github repository: https://github.com/Health-Education-England/TIS-GMC-SYNC

The application is run from a Jenkins cron (12.05am Mon-Fri) - here : https://build.tis.nhs.uk/jenkins/view/Prod/job/gmc-sync-prod/

What is does

• GMC Sync first truncates the Revalidation Elastic Search (ES) index (removing the visibility of all Revalidation data from the Revalidation UI)
• It then executes the following logic for each Designated Body in turn:

• Calls the GetDoctorsForDB method on the GMC API to retrieve basic Doctor records. (GMC Revalidation API is a SOAP API provided by the GMC.)
• The basic record includes GMC ID, Firstname, Surname, various GMC specific dates and status (including Sanction - a flag to highlight a doctor's licence has a sanction against it.)
• It uses the Revalidation service (Swagger definition of the Revalidation Service) to check whether the GMC ID exists in TIS which uses the Profile service to create a TISId in its Traineeprofile table if not.
• It then writes the basic record for all doctors to the Revalidation ES index (directly or via the Revalidation service - think directly)

For pre-live environments TIS can't use live GMC data, so a GMC Sync is mocked with a Springboot application serving up SOAP responses for pre-live environments (https://github.com/Health-Education-England/TIS-GMC-CONNECT)