...
Build out a high level description of each service to complement the Application Architecture diagram
| Anchor | ||||
|---|---|---|---|---|
|
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 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 asynchronous 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)
...
- 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:
- 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 Profile 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)is already known and if not creates a TISId in the Profile service's Traineeprofile table. - It then writes the basic record for all doctors to the Revalidation ES index (directly or via the Revalidation service - think directlyand in parallel to the Concerns ES index (Sunil Rochani (Unlicensed) to double check this element)
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
...
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.
- It uses the GMC ID stored in the Trainee ES index to identify the Person record (Person.Id) in TCS
- It then retrieves the Person, and
...
- associated Contact, Programme, Placement and Assessment data from the TCS and Assessment services and directly updates the appropriate Revalidation ES indexes
- It also writes a subset of this data to the Connection Discrepancies ES index
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.
| Anchor | ||||
|---|---|---|---|---|
|
Summary
To support the Revalidation service HEE can track concerns about trainee doctors. A trainee can have multiple concerns records, each record consists of metadata like such as incident date, type, employer, site etc, a rich text description and the ability to upload files.
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 by GMC Sync and the Revalidation ETL. - see question below. Each added/amended concern once saved to the MySQL db by the service is also refreshed into the ES Index.
Q. Sunil Rochani (Unlicensed) - I'm assuming the Concerns list gets its data from the Concerns ES index via the concerns service - You said that the concerns ES index is wiped and rebuild each evening with the base record coming from GMC Sync? If so does something caches the MySQL concerns data into ES?
Cache is updated with every concern update
Where
The Concerns Angular 1.x UI App and the Springboot microservice can both be found in the same repository: https://github.com/Health-Education-England/TIS-CONCERNS
...
- 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)?)Concerns service
- The UI provides a form create/edit a concern record. The UI uses endpoints on the Reference service to allow the user to search and select a Site, Trust and Grade for the Trainee.
- Aside from the external calls outlined above, the Concerns service also authenticates with Keycloak to obtain a JWT token and authorises its permission levels with the Profile service
- The Concerns UI uses the Reference service, the Concerns service doesn't make external calls to Reference though.
...
- An 'new notifications' icon in the Angular 1.x UI App menu bar informs the user of unread notifications, clicking provides a 'slide in' list of unread notifications.
- Clicking a notification or the Notifications tab, the user is presented with a simple 'inbox' of notifications - these can be marked as read and deleted
- Users with TIS Admin permissions can create notifications via a simple form
- The Notifications UI retrieves and stores all its data within the Notifications service
- Aside from the external calls outlined above, the Notifications service also authenticates with Keycloak to obtain a JWT token and authorises its permission levels with the Profile service
Connection Discrepancies
...
Summary
What it does
Admin UI
(Service and UI (within Admin UI))
Summary
As outlined in Revalidation - The GMC treats HEE as 13 discrete entities or Designated Bodies and requires every trainee with a GMC licence to be assigned to one of these bodies. Whilst the trainees themselves are expected to self-manage their relationship with the GMC and inform them when they move locations to a new designated body, in practice HEE also needs to update the GMC's records - this is the Connection Discrepancies function.
Connection Discrepancies is a springboot application presenting a RESTful API to support the user interface which is found within the Admin UI
Where
The Connection Discrepancies Springboot microservice can both be found in the repository: https://github.com/Health-Education-England/TIS-CONNECTION-DISCREPANCIES. The UI is part of the Admin UI at: https://github.com/Health-Education-England/TIS-ADMINS-UI
What it does
- The UI within Admin UI provides two lists, 'Create Connection' and 'Remove Connection' which provides constrained lists of trainees within the Designated Body the Admin has access to (retrieved from the Profile Service)
- The data to populate these lists is retrieved from the Connection Discrepancies service.
- Create Connection highlights Trainees within the HEE Admin's local office(s) which are in a different GMC Designated Body. It allows the multi-select of these trainees and invokes the TryAddDoctor method on the GMC Revalidation API (a SOAP based API provided by the GMC) to re-associate the trainee with its correct Designated Body within the GMC.
- Remove Connection highlights Trainees within the Designated Body(s) for the HEE Admin who are not on a programme within the corresponding Local Office. It allows the multi-select of these trainees and invokes the TryAddDoctor method on the GMC Revalidation API (a SOAP based API provided by the GMC) to re-associate the trainee with its correct Designated Body within the GMC or the TryRemoveDoctor to remove the association if one isn't appropriate << check this with Sunil Rochani (Unlicensed) - I'm sure this isn't quite correct>>
More details can be found on the https://hee-tis.atlassian.net/wiki/spaces/TISDEV/pages/49217537/Manage+connections
| Anchor | ||||
|---|---|---|---|---|
|
Summary
What it does
TIS Core Services (TCS)
...
What it does
Generic Upload
Summary
Generic Upload (also known as Bulk Upload to users) allows HEE Admins to upload Excel spreadsheets contain multiple People and Placement records, (initially), for these to be validated, imported into TIS if acceptable, or returned to the user in a downloadable spreadsheet if not (on a row by row basis)
Generic Upload is a springboot application presenting a RESTful API to support the user interface which is found within the Admin UI
Where
The Generic Upload springboot microservice can both be found in the repository: https://github.com/Health-Education-England/TIS-GENERIC-UPLOAD. The UI is part of the Admin UI at: https://github.com/Health-Education-England/TIS-ADMINS-UI
What it does
| Anchor | ||||
|---|---|---|---|---|
|
...