...
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
Where
The Revalidation Angular 1.x UI App and the Sprintboot microservice can both be found in the same repository: https://github.com/Health-Education-England/TIS-REVALIDATION
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 (retrieved from the Profile Service)
- 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 as XML through the Revalidation service into the MySQL database as a permanent audit of the trainee record at the time the recommendation was made.
- Aside from the external calls outlined above, the Revalidation service also authenticates with Keycloak to obtain a JWT token and authorises its permission levels with the Profile service (Sunil Rochani (Unlicensed)?)
- The Revalidation UI uses the Reference service, the Revalidation service doesn't make external calls to Reference though.
- Note: if Revalidation is unavailable, Doctors can be revalidated manually via the GMC web user interface, GMC Connect, https://hee-tis.atlassian.net/wiki/spaces/TISDEV/pages/13402263/GMC+Connect, however the data in Revalidation then becomes out of sync and needs manually updating
- Check above for technical accuracy and extend if missing anything please - Sunil Rochani (Unlicensed)
- Check above for functional accuracy - Alistair Pringle (Unlicensed)
...
Concerns is made up of an Angular 1.x UI app and a springboot application presenting a RESTful API to support the Concerns UI. The Concerns 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
Where
The Concerns Angular 1.x UI App and the Sprintboot microservice can both be found in the same repository: https://github.com/Health-Education-England/TIS-CONCERNS
What it does
- The UI is similar to revalidation in that it presents a list of Trainees that have a concern logged against them, constrained to only trainees within the Designated Body the Admin has access to (retrieved from the Profile Service)
- Note this is a list of concerns rather than Trainees. It obtains this data from the Concerns service which caches this nightly in the Elastic Search index. (Sunil Rochani (Unlicensed) is the concerns index rebuilt by the Revalidation ETL?)
- The UI allows a very basic Trainee search in order to create a new concern log, using the cached Trainees in the Revalidation service (correct Sunil Rochani (Unlicensed)?)
- The UI provides a
The Concerns UI makes calls to the Reference service - to populate Site/Trust/Grade dropdowns at least. ....... tbcThe Concerns service doesn't make cross service calls to Reference though.
Notifications - (UI + Service)
...
Connection Discrepancies - (UI + Service)
Summary
What it does
Admin UI
Summary
What it does
TIS Core Services (TCS)
Summary
What it does
Assessments
Summary
What it does
Generic Upload
Summary
What it does
Document Manager
Summary
What it does
TIS-NDW ETL
Summary
A springboot application which runs nightly to extract data from TIS, denormalise to the National Data Warehouse (NDW) schema, and write to an interim database for the NDW to import from.
Where and When
The application has its own github repository: https://github.com/Health-Education-England/TIS-NDW-ETL
The application is run from a Jenkins cron (00.20 UTC 7 days a week) - here : https://build.tis.nhs.uk/jenkins/view/Prod/job/tis-ndw-etl-cron-prod/
What it does
- The application uses Springbatch to work through a series of extract and mapping tasks in discrete chunks.
- It works through each table in the destination database (TIS-Interim, an Microsoft SQL Server DB) in turn and batches the ETL into each table
- When starting on the next table it firsts truncates the table contents in the TIS-Interim
- It extracts data from TIS via direct database calls to the MySQL service databases (as opposed to going through the REST service layer - in order to provide adequate performance)
- It writes data to TIS-Interim using (@luis - SQL batch insert or something like that?)
- It accesses TCS, Assessments and Reference services to assemble the required data
- The mapping is contained in discrete SQL mapping files in https://github.com/Health-Education-England/TIS-NDW-ETL/tree/master/src/main/resources/queries which the application uses to extract data from TIS and normalise it to the single table in the NDW schema
- Note: The destination schema is held in the repository for each destination table but these need to be dropped and recreated manually if they are changed, its not flyway enabled.
- The service through Springbatch has instrumentation on its progress which it writes to the TIS-Interim database - tables Batch Job Execution and Batch Step Execution can be used to review or debug the application progress through tables and batches.