Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 46 Next »

  • Every existing DB will be mapped to a brand new DB, and doctors will be "lifted and shifted" to new DBCs -meaning old DBCs will be invalid/return no doctors.

  • That API we use will remain the same including the authentication credentials we pass in the requests. We will need to use the new Designated Body Codes though.

Stuff we might need to change for production:

  1. In reval services, we have a hard-coded list of DBCs, we need to make a new list (I suggest we keep the old list rather than replace it for historical reasons)

  2. In user management we need to create new roles/DBC codes for admins to be assigned to and ensure they are all assigned the correct new one

  3. In TIS we need to bulk update all DBCs -> new DBCS and new names etc

In terms of performing a quick test on stage, we can just use the DoctorsForDB template that lives on STAGE-GREEN(?) and pass it one of the "test" New DBCs they'll provide, then do whatever validation on the list that's returned that we need.

Background : The merger of the HEE and NHS England requires changes to the Designated Bodies that are responsible for the revalidation of doctors.

Discussion: essentially what we need in generic terms isGiven we have a mapping of oldDBC -> newDBC, where does this mapping apply, and can we maintain the oldDBC where necessary (e.g. history)My optimistic brain tells me that even though we don't have the old -> new mapping, as long as we know where it's effects will be felt, we can write migration scripts or whatever, and when the time comes just plug in the DBC mappingFor Reval it's:

  • The list of DBCs we use to call GetDoctorsForDB

  • The DBC role given to each admin in usermanagement

  • The RO name we send along with requests that's used for authentication

And I think that's it?So we need the same kind of list for the other areas - TIS, user management etc.

Meeting with the operation manager from the GMC hoping we can get to a position where we can do/have testing environment.

Aim: Migration system -27 March and go live day to be 1st April 2023

This is the follow-up from the GMC (16 February) – Holly Chadwick holly.chadwick@gmc-uk.org → GMC Operations Manager for Revalidation

  • Test at least two mergers as soon as possible (hopefully next week if that’s good for you).

  • We want to make the changes on the live environment on Monday 27 March.

  • We estimate minimal system outage. I’m meeting with team who will be updating the systems next week to get an estimation of how long it will take to get the new codes for you.

Excel sheet from GMC of proposed changes. Note that the DB codes are generated at the time, so these will be given for the test and the final ones will be given (we assume) on 27th March (TBC)

Planning: To make GMC aware that London has changes office address(Please raise a ticket-done)

Impact : ?Tis , revalidation(both 1 and 2), we currently do not have a DB code-

  • To inform our users of changes and possible impact

  • Ensure we are managing expectation of our users

  • ?How we manage change and the NDW?-

Requirement : Test code to be made available by the GMC for our testing , Investigation ticket? to establish whether the Trainee product team would need to be involve?

Concerns: Change in name likely would impact our tis service , The need for notification on name change.

  • How much knowledge of the change is Daniel Smith (GMC Data lead)

Stakeholders involvement : ?users of the Reval service

Process map:

Principles of the change of ‘Owner’ on TIS for the NHSE Merger

  • The concept of ‘Owner’ on TIS is defined as the organisational body which has current ownership of a data item and its associated records whether that record is past, current or future. The values of ‘Owner’ are defined by the Designated Body reference table on TIS.

  • With the merger into NHSE on the first of April, the Designated Bodies which are in Health Education England will be replaced by NHSE Education and there is a one-to-one correlating organisation from Health Education England to NHSE Education, e.g. NHSE Education East of England directly correlated to what was Health Education England East of England.

  • Given the above, when the NHSE merger takes place on the 1st of April, the ‘Owner’ of the records associated with a Health Education England body will have the new ‘Owner’ of the correlating NHSE Education body, e.g. a record with the ‘Owner’ of Health Education England East of England will now have the ‘Owner’ of NHSE Education East of England. This will apply to all associated records relating to that Health Education England body whether past, current or future.

  • The above principle represents the definition of a data ‘Owner’. Furthermore, it is not possible for Health Education England, its related bodies and its users to be the owner of data items or records on TIS whether past, current or future after the 1st of April as Health Education England as an organisation will no longer exist as an organisation. It also allows the transition to be enacted with the least amount of risk and complication.

EPIC Link: TIS21-4233 - Getting issue details... STATUS

Service

Tasks

Ticket(s)

Revalidation

Before 27th:

  • Test new DBC by CURLing from STAGE-GREEN/BLUE

TIS21-4240 - Getting issue details... STATUS

TIS21-4234 - Getting issue details... STATUS

  • Test new DBCs by running through steps for w/c 27th:

    • TIS Stuff [Prerequisite, not in this estimate]

    • Add the new DBCs to parameter store:

      • the Recommendation

      • tis-revalidation-connection service (probably parameter store like recommendations)

    • Add the new DBCs to TIS-GMC-Client service

    • Add the DBCs to the reval FE

    • The GMC

N.B. More PRs/things to review and co-ordination with GMC compared to the change in TIS

Outcome: Warm fuzzy feeling that when a user is assigned new DBCs they can:

  • still see the information associated with the HEE names.

  • submit recommendations against new DBCs even if drafted against HEE DBCs

Hypothesis: Changing the DBC does not affect what I see in . The data from TIS does not need to be resent with the new DBCs.

Test:

  1. Record names/records visible before & after (Under Notice & All Doctors). The only difference should be the 10 doctors for each DBC which have already been transferred.

  2. Functionality:

    1. Draft recommendations (each) while assigned HEE DBCs

    2. Submit drafted recommendation and submit new recommendation

TIS21-4290 - Getting issue details... STATUS

Modify job schedules to only run up until 25th March & then from 1st (or 3rd?) April*

*Pepe thinks this is really only valuable if we are maintaining some Reval functionality, i.e. Creating drafts & viewing data.

w/c 27th:

  • Add the new DBCs to parameter store to map to the Recommendation

  • Add the new DBCs to TIS-GMC-Client service

  • Add the new DBCs to tis-revalidation-connection service (probably parameter store like recommendations)

  • Add the DBCs to the reval FE

  • ALSO (see “TIS” section) For Revalidation API calls to work:

    • the admin needs to have the correct DBC assigned in usermanagement/profile service

    • And the RO for that DBC needs to be correct (in User Management)

    • Modify/Add reference “DBC” data

TIS21-4235 - Getting issue details... STATUS

TIS21-4239 - Getting issue details... STATUS

“Later”:

Never?:

Legacy Revalidation

  • Find the location where we need to accommodate the new DBC changes

  • Can we use this as an opportunity to close down old reval? need to ask users

TIS

Before 27th:

With new test codes (1-1P9Y9QH = “NHSE Education Yorkshire and The Humber”, 1-1P9Y9R1 = “NHSE Education North West”):

  1. TIS-Reference: update reference.DBC in STAGE only, inactivating one DBC and creating a similar-name replacement, for the other updating the dbc field.

  2. TIS-Profile: create/modify test users with the updated DBCs in the UserDesignatedBody table in STAGE only

  3. TIS-TCS: update class DesignatedBodyMapper to have new codes in addition to existing ones, using (e.g. environment to use new DBC values

Outcome: Warm fuzzy feeling that if a user is assigned new DBCs they still see the information associated with the HEE names.

Hypothesis: Changing the DBC does not affect what I see in TIS.

Test:

  1. Record names/records visible before & after. We should see no difference.

  2. Functionality: Create Programme*, Posts, Placements, People still work for Local Office

* This is the one that definitely has restrictions

TIS21-4289 - Getting issue details... STATUS

w/c 27th:

  1. TIS-Reference: update reference.DBC , either inactivating existing DBCs and creating new ones or updating the dbc field.

  2. TIS-Profile: update UserDesignatedBody table

  3. TIS-TCS: update class DesignatedBodyMapper

  4. List the changes on TIS, UserManagement and Bulk upload and inform admin users.

TIS21-4236 - Getting issue details... STATUS

TIS21-4246 - Getting issue details... STATUS

Later (or never?):

  1. TIS-Reference: update reference.DBC.name and ???reference.DBC.abbr???, reference.LocalOffice , reference.trusttable

  2. TIS-Profile: update UserDesignatedBody table

  3. TIS-TCS:

    1. update tcs.Programme , tcs.Post table

    2. update tcs.PersonOwner table by PersonOwnerRebuildJob in Sync service

  4. List the changes on TIS, UserManagement and Bulk upload and inform admin users.

User Management

Should be okay when db tables of reference and profile are updated.: We need to update the “UserDesignatedBody”

Needs verification and investigation to see the DBCs reference elsewhere.

TSS

  • Not expecting there to be any impact from Code-only changes

NDW

  • Speak to the NDW Team about potential impact

    • Initial conversation with John Thompson on 17/02/23. A wider meeting with NDW Team taking place 20/02/2023.

    • Discussion on 20/02/2023 and 21/02/2023. Impact on NDW and Tableau users too great within the timescale. Agreed to attempt to delay the update to Programme.Owner and Post.Owner fields post 1st April through by only changing the DBCs in the reference table and mapping script. Also, the new Local Office names are not officially confirmed. Once the above TIS approach is confirmed will send comms to NDW and Tableau users/stakeholders.

  • Coordinate with NDW of potential comms to regions and other downstream users of TIS data

TIS21-4241 - Getting issue details... STATUS

ESR

Further investigation on how ESR communicate across the ?changes

Hicom Leave Manager

  • Update TIS-Accent ETL to use or include the new Owner names

  • Confirm with Hicom the impact on their ETL and Accent Leave Manager system changing DBCs/Owners would have and identify mitigating actions

    • 21/02/2023 email: Hicom are conducting their own impact assessment and communicate back once complete. To note, Hicom only use Programme.Owner

NDW-Tableau

  • Identify scripts in the NDW which are or are a dependency for Tableau data sources which use DBC/Owner to extract relevant data

  • Identify Tableau workbooks which use DBC/Owner to group, filter, etc

TIS21-4242 - Getting issue details... STATUS

TIS21-4243 - Getting issue details... STATUS

GMC - Educational Branch

  • Met with Danial Smith, Jennifer Redman-Tootell and Andy Knapton at the GMC on 21/02/2023. No mitigation necessary for 2023 GMC NTS and no other pending impact from TIS. Agreed to share new organisation names and relating ODS codes when known.

Other Docs:

GOAL: Prevent things* falling apart from 1st April

*

Timeline of changes (as of what we know )

  • No labels

0 Comments

You are not logged in. Any changes you make will be marked as anonymous. You may want to Log In if you already have an account.