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: 29 July 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

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 user does not exist/Does not have the RO role - The 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).