...

• 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/wiki/spaces/TISDEV/pages/16613389 - 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 asynchronous process within the GMC, so Revalidation calls the CheckRecommendationStatus on the GMC Revalidation API /wiki/spaces/TISDEV/pages/16613389 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
• 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

...

• 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/wiki/spaces/TISDEV/pages/16613389 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 Profile service to check whether the GMC ID 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 and in parallel to the Concerns ES index (Sunil Rochani (Unlicensed) to double check this element)

...

• 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/wiki/spaces/TISDEV/pages/16613389 (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/wiki/spaces/TISDEV/pages/16613389 (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>>

...

• Provides a top menu (L1 menu) with access to People, Posts, Programmes, Concerns, Assessments and Admin sections (based on the users Role)
• Within each L1 menu dropdown, L2 items provide links to pages within each L1 section.
• Typically these consist of a 'Search' (effectively a filterable, searchable List page of records of the object in question, e.g. People) and a CRUD (Create, Read, Update, Delete) - effectively a form allowing the CRUD of an individual record of an object - e.g. a Person record.
• The List and CRUD pages will typically invoke the TCS or Assessment microservices to read, create and update data and use the Reference microservice to populate individual fields within the pages that display / search reference data
• For the more complex People and Assessment objects, a Level 3 (L3) navigation is provided - e.g. tabs within an individual Person record provide access to different data or objects directly related to that Person record (e.g. their contact details, or a list of their Programme Memberships, Placements or Assessments.) Where a list is provided within a tab, the records (e.g. Placements) are editable via an inline expanding form rather than a navigation to a full page.
• The Admin UI implements view/edit constraints for 5 Roles initially, the base HEE Admin, extensions to provide access to both Sensitive Data and Revalidation/Concerns, a full TIS Admin with access to reference data, and a Trust Admin with data access constrained to Trainees and Posts related to their Trust. Full details can be found on the Admin User Management (roles and permissions) page.
• The Admin UI was initially built using a JHipster autogeneration model and has been incrementally improved. Some elements such as the Admin sections List and CRUD pages are early versions and lacking functionality, whereas the more widely used objects such as Person/Post/Programmes have a richer interface. A full rewrite of the List functionality is currently 24 Jul 2018 in development initially for People which removes the last remnants of the JHipster 'scaffold'.
• The Admin UI also provides the user interface to the Document Management feature within TCS, allowing documents to be stored against a Person record with limited editable metadata.
• The Admin UI also provides the user interface to the Generic Upload microservice, more details can be found Generic Upload section
• For a user to access the Admin UI, they must authenticate via Keycloak and the Admin UI establishes their Roles and Permissions via the Profile service

...

Anchor
tcs tcs

TIS Core Services (TCS)

Summary

The TIS Core Services (TCS) microservice provides the endpoints to allow the core TIS objects to be managed, People, Programmes, Posts, Placements (4xP) with supporting objects Curricula, Specialty and Rotations. It also contains the endpoints to support Document Management against People.

...

• Provides endpoints for the List/CRUD on People, Programmes, Posts, Placements (4xP) as core objects.
• Note that People in particular is subdivided into a primary and multiple secondary database tables and corresponding endpoints, so People has a primary Person table but 'secondary tables' of ContactDetails, PersonalDetails, GMCDetails, GDCDetails, RightToWork and Qualification - all keyed off the same Person ID, i.e. 1:1 relationship
• The relationships between the 4P Core objects are relatively complex and will be more fully documented on Entity Relationship Diagrams, the endpoints also support the creation and maintenance of these relationships
• An example would be Placements can have many Supervisors (a subset of Person records), of two types, Clinical and Educational. These have a separate PlacementSupervisor table outlined Placement Supervisors - Solution Design.
• Also provides endpoints for the List/CRUD on supporting objects, Curricula, Specialty and Rotations
• Supports the relationships between Specialties & Sub-Specialties as outlined on this page - Note: unfinished relationships are highlighted here as Jira tickets still to do
• Supports the relationships between Rotations and Programs/Posts/People, as outlined here: Programmes - Rotations - Solution Design, Field Validation & Scenarios
• Provides the endpoints to support Document Management - the storage /metadata management of externally created documents against Person records (initially). 
• As other services, the TCS service also authenticates with Keycloak to obtain a JWT token and authorises its permission levels with the Profile service

Anchor
assessments assessments

Assessments

Summary

...

The Assessments microservice provides the endpoints to allow Assessments to be managed in TIS. The UI subdivides Assessments into the event, pre-event detail, post-event detail and revalidation through Level 3 tabs. It is worth noting that some data items within Assessments are a static copy of the data item from elsewhere in TIS at the time the assessment was undertaken.

The microservice and the database tables subdivide into Assessments, 1:1 extension tables AssessmentDetail, AssessmentOutcome and Revalidation and a 1:many relationship AssessmentOutcomeReasons. Reference data for Outcome and Reason codes are also found within the service.

Assessments is a springboot application presenting a RESTful API to support the user interface which is found within the Admin UI

Where

The Assessments microservice can be found in the repository: https://github.com/Health-Education-England/TIS-ASSESSMENTS

What it does

• Provides endpoints for the List/CRUD on Assessments - Assessments Swagger
• The Assessment database tables and corresponding endpoints are subdivided into a primary Assessments table/endpoints and secondary AssessmentDetail, AssessmentOutcome and Revalidation tables/endpoints - all 1:1 tables keyed off the same Assessment ID. 
• The service also supports multiple Reasons for an AssessmentOutcome, via the AssessmentOutcomeReason table/endpoint.
• Outcome codes and Reason codes are also held with the Assessment service with discrete tables and endpoints

•  Paul Hoang (Unlicensed) - would you mind reviewing this assessment section please for accuracy and ommission?

Anchor
generic_upload generic_upload

Generic Upload

...

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

...