RO Responsible Officer for recommendation

Who are they?

Different Responsible Officers (or Deans) delegate different levels of responsibility to their teams in different Local offices/Designated Bodies. How hands-on they are, varies from person to person. The aim is the bring the trust down to the people below them who are all “perfectly capable of doing the role”.

In our system we call them RO, RVOfficer, Revalidation officers or Responsible officers.

When a recommendation is submitted to the GMC, corresponding DB’s Responsible Officer’s surname, gmc id, designated body code are also submitted to GMC along with the doctor’s detail. The RO details are cross checked in the GMC’s database. If the details are correct only then recommendation is allowed to be submitted.

Prod ROs

Below is the link of the correct details of RO for production environment after necessary changes on different fields

https://build.tis.nhs.uk/metabase/question/464 (updated on: 06 October 2022)

Pre prod ROs

In stage/preprod we have the following Responsible officers in different Dbs. The following metabase link will provide the comprehensive list.

https://build.tis.nhs.uk/metabase/question/463 (updated on: 06 October 2022)

How is it implemented in our systems?

In terms of implementation (refer to the GMC Web service user guide version 2.6, as attached) when Revalidation sends request to GMC using TryRecommendationV2 in the request parameter we need to supply RO surname, RO GMC Reference No, RO Designated Body Code.

In the response message GMC provides error code 84 (Missing / Invalid Responsible Officer GMC reference number) if we do not supply the correct RO GMC reference no, error code 85 (Missing Responsible Officer’s surname) if we don’t include RO’s surname, error code 96 for missing responsible officer.

In the stage environment GMC only validates RO GMC reference number, nothing else. In Prod they are all validated.

What if a responsible officer changes?

As stated above, GMC will reject submissions with mismatched/incorrect RO references, so it’s crucial that RO changes are handled quickly.

If the user already has the RO role - (e.g. re-assigning an RO to a different DB) simply update the designated body in user management

If the email associated with the RO role is generic - (e.g. tv@revalidation.nhs.uk for thames valley) update the user details (name, gmc number)

If the new RO user does not exist/does not have the RO role - use the “HTML hack” method:

1. Using the metabase link shown earlier on this page

   1. verify the RO officers match the request

   2. determine whether the previous RO should be deleted or needs different access

2. In User Management, create the new RO:

   1. Go to their record if they already exist or enter their details on the “Create” page if not.

   2. Inspect HTML of roles selection box

   3. Choose an unselected role and update the value of the option to RO role (shown in metabase)

   4. Ctrl_select the new role and submit the form (to send a properly authorised HTTP POST)

(Old way) RO role cannot be given via user management and must be updated via either, a) a flyway script or b) crafting a properly authorised HTTP POST to user management (see the request sent to save any user's roles).