Background
...
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.
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:
Question
Responder
Comments
What’s the difference / interaction between revalidation and concerns?
GMC integration - what does this look like, what does it do and how is it maintained?
What specifically is reviewed by Reval Admin? What are the recommendations?
Does the GMC ever query a recommendation?
What is the snapshot of the
Is receiving trainees to be revalidated from GMC consistently an automated process? What happens if the integration fails, how is Admin notified, what’s the mitigation? (Also see 11)
What are the rules/parameters are in place in managing the Reval process? Deadlines, communications, other?
What does CDC refer to?
When does the requirement for Reval kick in?
1 year post Foundation year + full registration with GMC (payment made)
How are fully qualified doctors revalidated? Same process, managed by HEE and at what point does it stop being managed by HEE?
Is 3 month lead time still valid, is there a range, or is it always this period? What does the GMC pre-notification look like? How is the start date calculated - no of days + full registration date? What if no notification is received for someone who should be Reval’d imminently? (Also see 6)
Who assigns Reval Admin? Do they manage from end to end? Are there dual-duties? i.e. do they need access to the rest of TIS for other points/during the Reval process?
Whats “Ready to review” as a status, and how is it different to “Ready to submit”?
Is Reval status captured separately to Recommendation status, or are they part of a single flow?
Is the GMC outcome final, can it be updated within a timeframe for a particular Reval cycle? If so, how will TIS be notified this has happened?
Connection discrepancies? Remind me what these are…
How does HEE ARR (reporting) factor into this process?
What’s the difference between Deferral and Amending submission date?
Archiving - there’s a page on Confluence with no content - is this a valid requirement or has the page been created in error? https://hee-tis.atlassian.net/wiki/spaces/NTCS/pages/42500116/Revalidation+archiving
Are the roles involved in the process the same - TIS Admin, Reval Admin, RO & GMC? Any others? What are associated permissions?
How does RO participate in this process?
Whats the purpose of concerns log, how is it used and when? Breakdown of components of this?
What does the outcome determine for the doctor? i.e. what do the outcomes mean?
Page Name | Description | Comments |
|---|---|---|
Initial description of the Revalidation process & requirement | ||
Overview of the end to end process as it functions today | ||
User issues summarised from discussions with Reval Admins in December 2019 | ||
Recommended feature enhancements from users | ||
WCAG assessment outcomes from December 2019 | ||
User research conducted by Transform c2016 | ||
User journey identified by Transform c2016 | ||
Site map for current iteration of Reval, developed c2016 | ||
Breakdown of user journey as identified by Transform c2016 |
Outstanding questions
Outstanding questions for discussion with TIS team and SMEs
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:
Simplifying where possible
Understanding whether the existing page flow meets their current needs
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.
| View file | ||
|---|---|---|
|