...
Build out a high level description of each service to complement the Application Architecture diagram
Revalidation (UI + Service)
Summary
A doctor's licence to practice with the GMC must be renewed every 5 years, this includes trainee doctors with HEE who receive their full GMC licence after their first (Foundation) year of training. This renewal is known as Revalidation and is achieved by HEE submitting a recommendation to the GMC for those trainees who are nearing renewal (under notice). The GMC treats HEE as 13 discrete entities or Designated Bodies, each with a single Responsible Officer (RO), the individual responsible for the trainee's recommendation. In practice the RO delegates all or most of these to HEE Admins and sometimes reviews before submission. The Revalidation application within TIS enables HEE to review the data on Trainee Doctors due to be Revalidated, make a recommendation, review these and then submit to the GMC.
Revalidation is made up of an Angular 1.x UI app and a springboot application presenting a RESTful API to support the Revalidation UI. The Revalidation service uses Elastic Search indexes to hold a daily refreshed cache of trainee data and a MySQL database for the data that is persisted. The Elastic Search data is refreshed each evening by a combination of GMC Sync and the Revalidation ETL
What it does
- Revalidation allows HEE Admins to review lists of HEE's trainee doctors, constrained to only trainees within the Designated Body the Admin has access to
- The lists of Trainees are presented as tabs - each one shows trainees within one (or more) status within the Revalidation workflow, these are: All Doctors | Under Notice | Review | Ready to Submit | Submitted
- The data to populate these lists in the UI is retrieved from the Revalidation service - which holds it either in read only cache in the ES indexes, or the persistent data within the service's MySQL database
- Selecting a Trainee takes the admin through to a series of screens displaying further trainee detail held by HEE
- The Revalidation service provides this data from its Elastic Search cache (updated nightly), it includes programmes/revalidation history/assessments/placements/contact details
- Once the Admin has reviewed a trainee's data they can make a recommendation to the GMC (whether the Trainee should have their licence to practice extended for another 5 years)
- The recommendation is a simple form which gathers the required fields and saves this as a 'revalidation episode' to the Revalidation service (stored in the MySQL database)
- The recommendation can be placed in a review status or directly submitted to the GMC (by invoking the TryRecommendation method on the GMC Revalidation API - a SOAP based API provided by the GMC.)
- The UI allows the submission of multiple recommendations using one action in the UI, the service makes multiple called to TryRecommendation - users particularly like this time saving aspect compared to their alternative processes.
- The submission to the GMC is an synchronous process within the GMC, so Revalidation calls the CheckRecommendationStatus on the GMC Revalidation API at regular intervals for each submitted Revalidation until its status is confirmed by the GMC - this is displayed in the 'submitted' tab
- As the submission is accepted Revalidation takes a 'snapshot' of the data for that trainee and persists it through the Revalidation service into the MySQL database as a permanent audit record of the trainee record at the time the recommendation was made.
| Anchor | ||||
|---|---|---|---|---|
|
Summary
A springboot application which runs nightly to retrieve a basic Doctor dataset from the GMC to refresh the Revalidation service.
...
- GMC Sync first truncates the Revalidation Elastic Search (ES) indexes (removing the visibility of all Revalidation data from the Revalidation UI)
- It then executes the following logic for each Designated Body in turn:
| Info | ||
|---|---|---|
| ||
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.) (we ignore the GMC's Firstname and Surname in preference to the TIS one) - 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.
(Sunil checking - we suspect it might go directly to the Profile service to get a current TISId or create one if the GMC ID isn't present in the Traineeprofile table) - 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 called GMC Connect, serving up SOAP responses for pre-live environments (https://github.com/Health-Education-England/TIS-GMC-CONNECT) Note: this is the same name as the GMC provided user interface, also called GMC Connect, which could cause confusion
| Anchor | ||||
|---|---|---|---|---|
|
Summary
A springboot application which runs nightly to enrich the Revalidation ES indexes recreated by GMC Sync, with data from the TCS and Assessments services
...
The application is run from a Jenkins cron (01.00 UTC 7 days a week) - here : https://build.tis.nhs.uk/jenkins/view/Prod/job/intrepid-reval-etl-all-prod/
What it does
Revalidation ETL works through each Trainee provided by the GMC through GMC Sync, by their GMC ID.
...
Note: Revalidation was developed before TCS and wasn't refactored as part of TCS, which is why it identifies Trainees by GMC ID and a Trainee.TISid in the Profile service but isn't more cleanly integrated into TCS.Person. This is a clear area to refactor as apart of a wider Revalidation service rework.
Revalidation (UI + Service)
Summary
A doctor's licence to practice with the GMC must be renewed every 5 years, this includes trainee doctors with HEE who receive their full licence after their first (Foundation) year of training. This renewal is known as Revalidation and is achieved by HEE submitting a recommendation to the GMC for those trainees who are nearing renewal (under notice). The GMC treats HEE as 13 discrete entities or Designated Bodies, each with a single Responsible Officer (RO), the individual responsible for the trainee's recommendation. In practice the RO delegates all or most of these to HEE Admins and sometimes reviews before submission.
Revalidation is made up of an Angular 1.x UI app and a springboot application presenting a RESTful API to support the Revalidation UI. Combined they enable HEE to review the data on Trainee Doctors due to be Revalidated, make a recommendation, review these and then submit to the GMC.
What it does
...
.