...
- Ad hoc when a trainee transfers to the DB or has/has been disconnected inappropriately (usually too early at end of training)
Status colour Yellow title Draft
- Ad hoc when a trainee transfers to the DB or has/has been disconnected inappropriately (usually too early at end of training)
On-boarding process for new foundation trainees (WIP)
| Status | |
|---|---|
|
|
" In theory, once (a trainee has) full GMC registration (i.e. following their F1 ARCP and before they start their F2 year), they will be prompted by the GMC to connect to a Designated Body; they would then connect to the Deanery/HEE local team through their GMC Online account.
In practice, we get a few connections this way (I emailed all of the F1 trainees progressing to F2 last year with some guidance and contacts regarding revalidation here, and that seemed to work fairly well), but most of them have been picked up when the GMC do a bulk refresh of our connections in October each year." - Andy Petheridge
- Disconnections
- When trainees have completed their programme (CCT or CCT + Grace Period for higher specialty) - either managed by programme team or revalidation administrator
- When trainees resign from the training programme for another reason (or are released from the programme - ARCP Outcome 4)
- Ad hoc when a trainee is noted to be wrongly connected to the DB (usually too soon at start of training)
- Connection to another DB because of a conflict of interest (with agreement)
...
Trainees are usually connected and disconnected directly on GMC Connect (and trainees always use the trainee version of this channel to connect/disconnect themselves). HEE administrators must connect/disconnect trainees one by one - there is no bulk functionality on GMC Connect, although GMC request an annual spreadsheet of trainees to 'refresh' the connections (annual reconciliation) - this was supposed to have been superseded by new Intrepid functionality (see note Intrepid functionality below).
Data mismatch scenarios and related business decision Status colour Yellow title Draft
| Data issue | Scenario | Business Decision | |
|---|---|---|---|
| 1 | No Designated Body (DB) |
These doctors will have records and assigned to programmes to commence in the future | Connect to relevant DB |
| 2 | No Programme Record | Non-trainee doctors - these are usually Deans / Programme Managers. These are doctors with no Programme record. | Connect to relevant DB |
| 3 | Designated Body Mismatch |
These doctors are classed as being outside the flow of training - whilst an OOP doctor is on absence from a programme, they retain the DB of their last programme. A doctor on a visiting placement will also retain the DB and of their 'home' DB. | Flag up these records to the Revalidation Administrator however ; this is an exception that should not be connected |
| 4 | Designated Body Mismatch | Defence trainees are managed by the Defence Deanery and not HEE | Flag up these records to the Revalidation Administrator however ; this is an exception that should not be connected |
| 5 | No Designated Body | Provisionally registered doctors - F1 placements | Flag up these records to the Revalidation Administrator however ; this is an exception that should not be connected |
User needs |
|---|
| Functionality in TIS to enable connection or disconnection of a Revalidation Administrator to connect or disconnect individual trainees from the designated body** |
| Functionality in TIS to enable a Revalidation Administrator to bulk connection connect or disconnection of disconnect trainees |
Functionality to flag up to a Revalidation Administrator where a trainee is joining a training programme and needs to be connected:
|
Functionality to flag up to a Revalidation Administrator where trainees are not on a training programme with the DB:
|
| Functionality to flag up to a Revalidation Administrator discrepancies between the GMC Connect list and HEE's database of who should be connected to the local team |
| ** As we develop the new core there could/should be functionality to transfer trainees between designated bodies in a single step i.e. not require one local team to disconnect and another team to connect separately. Will need to be built with appropriate approval workflow based on agreed policy and business rules - e.g. which local office (outgoing or incoming) responsible for changing connection NB: IDT's require approval from Postgraduate Deans (Responsible Officers) from both local teams |
...