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:
Designated Bodies
The GMC treats HEE as 13 discrete entities, in GMC terms known as Designated Bodies. Details: Designated Body and Revalidation Office (DB and RO) information
- 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)
Add Comment