Discovery & Consolidation

Background

Revalidation is the process by which all licensed doctors are required to demonstrate on a regular basis that they are up to date and fit to practise in their chosen field and able to provide a good level of care. This means that holding a licence to practise is becoming an indicator that the doctor continues to meet the professional standards set by the GMC and the specialists standard set by the medical Royal Colleges and Faculties.

Revalidation aims to give extra confidence to patients that their doctor is being regularly checked by their employer and the GMC.

Licensed doctors have to revalidate usually every five years, by having annual appraisal based on our core guidance for doctors.

GMC what is revalidation

The requirement for Revalidation in TIS is to provide a platform to support the Revalidation journey for HEE administrators in a way that is seamlessly integrated with the trainee information system and

This page summarises what has been developed so far, and points to other resources previously researched.

Further background information can be found on the following pages:

 

Page Name

Description

Comments

Page Name

Description

Comments

Revalidation description

Initial description of the Revalidation process & requirement

 

Detailed overview

Overview of the end to end process as it functions today

 

Current usability issues

User issues summarised from discussions with Reval Admins in December 2019

 

Recommendations

Recommended feature enhancements from users

 

WCAG Assessment outcome

WCAG assessment outcomes from December 2019

 

Initial user research

User research conducted by Transform c2016

 

Initial user journey / helicopter view

User journey identified by Transform c2016

 

Site map & screen flow

Site map for current iteration of Reval, developed c2016

 

Breakdown of initial user journey

Breakdown of user journey as identified by Transform c2016

 

Reporting

Overview of reporting requirement

 

 

Answers to questions relating to the background of Revalidation can be found here

Revalidation Workflow

A review of the current Revalidation application architecture was carried in order to understand the As-Is flows within the Revalidation application. This will potentially help us in the TIS team identify gaps in user journeys and help build shared understanding on how the Revalidation application hangs together alongside TIS with a view of improving/refactoring or rebuilding the application.

Detailed Process Flow - As-Is

The following process is to be validated with TIS Reval Administrators, with a view to:

  1. Simplifying where possible

  2. Understanding whether the existing page flow meets their current needs

  3. Developing the requirements based on their needs

Revalidation Application Video Demo

Revalidation, Concerns, Connection Discrepancies - As-Is Architecture (Draft)

 

 

Key Steps (to be reviewed with devs)

 

Data Model

 

Additional information re GMC Connect

 

Changes to information about deferral recommendations

 

In the most recent RO bulletin, we told you about our plans to collect additional information about recommendations to defer doctors’ revalidation.  We’re now asking you to forward this email to your technical lead for the system that you use to send recommendations to us. It would be really helpful if you could let us know their contact details so we can communicate with them directly in the future.

 

From 25 March 2019 we will collect additional information about recommendations to defer doctors’ revalidation. To recap, we will collect further information where the reason for the deferral is ‘insufficient information to revalidate’. To submit recommendations designated bodies (‘DBs’) must select the categories that best describe the reasons for the recommendation, from the following pre-populated list:

 

  • Appraisal activity

  • Colleague feedback

  • Compliments and Complaints

  • CPD

  • Interruption to practice

  • Patient feedback

  • QIA

  • Significant events

 

The changes will automatically come into effect for recommendations submitted through GMC Connect. However our records show that your organisation has submitted revalidation recommendations via our API. If you wish to continue submitting recommendations via our API system you will need to test and implement the necessary changes.

 

Our new API version will be available from 25 March 2019.  We understand that you will need time to make the necessary system changes.   We therefore ask that have adopted our new API version by April 2020.  This provides you with an additional 13 months to provide this information when compared to GMC Connect users.

 

We plan to retire the v1 API from April 2020, at which point submissions made via v1 will be rejected. We have attached our updated API user guide.

 

We are writing to ROs separately to confirm the changes. Here we will confirm that API user organisations have been given notice of the changes and deadlines.

We strongly encourage you to contact us at the earliest opportunity if you think there may be challenges in meeting this deadline. It is important that we are able to collect this information from all DBs, so that our approach to recommendations is fair and transparent.

 

 

We are retiring the legacy TryRecommendation API method

 

Collecting information about revalidation deferrals is important to us, which is why we are planning to retire the previous API method TryRecommendation method in April.   From this time, designated bodies who have not adopted the new method (TryRecommendationV2) will be required to submit their recommendations “manually” through our GMC Connect portal.

 

What do you need to do?

 

If you have any concerns about adopting TryRecommendationV2 by April 2020, please reply to this email to let us know.   We want to encourage the usage of our Revalidation API, so we’d like to know more about how changing our systems impacts users.

 

If you are planning to move to TryRecommendationV2, we’ll be happy to support you while testing the new method on our test environment.