Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

  • 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.

...

EPIC Link:

Jira Legacy
serverSystem JIRA
serverId4c843cd5-e5a9-329d-ae88-66091fcfe3c7
keyTIS21-4233

Revalidation
  • 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

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

  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.

Service

Tasks

Ticket(s)

TIS

Before 27th:

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

Jira Legacy
serverSystem JIRA
serverId4c843cd5-e5a9-329d-ae88-66091fcfe3c7
keyTIS21-4240

Jira Legacy
serverSystem JIRA
serverId4c843cd5-e5a9-329d-ae88-66091fcfe3c7
keyTIS21-4234

Jira Legacy
serverSystem JIRA
serverId4c843cd5-e5a9-329d-ae88-66091fcfe3c7
keyTIS21-4290

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

jiraWith 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 (programme create) is the one that definitely has restrictions

Jira Legacy
serverSystem JIRA
serverId4c843cd5-e5a9-329d-ae88-66091fcfe3c7
keyTIS21-4289

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 *merge PR. N.B. This will break some functionality in the stage environment

  3. Update DesignatedBodyMapper and similar classes to have new codes {in addition to|instead of} existing ones, using (e.g. environment to use new DBC values

    1. TIS-TCS

    2. TIS-REFERENCE although, this doesn’t appear critical for the admin functionality tested

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

  5. ?Invalidate Sessions in a way that allows Bulk Upload, ESR and other App users to compensate?

Jira Legacy
serverSystem JIRA
serverId4c843cd5-e5a9-329d-ae88-66091fcfe3c7
keyTIS21-4236

Jira Legacy
serverSystem JIRA
serverId4c843cd5-e5a9-329d-ae88-66091fcfe3c7
keyTIS21-4235

Jira Legacy
serverSystem JIRA
serverId4c843cd5-e5a9-329d-ae88-66091fcfe3c7
keyTIS21-4239

“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:

Jira Legacy
serverSystem JIRA
serverId4c843cd5-e5a9-329d-ae88-66091fcfe3c7
keyTIS21-4289

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.

Jira Legacy
serverSystem JIRA
4246

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.

Revalidation

Before 27th:

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

Jira Legacy
serverSystem JIRA
serverId4c843cd5-e5a9-329d-ae88-66091fcfe3c7
keyTIS21-4240

Jira Legacy
serverSystem JIRA
serverId4c843cd5-e5a9-329d-ae88-66091fcfe3c7
keyTIS21-4234

  • 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

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

Jira Legacy
serverSystem JIRA
serverId4c843cd5-e5a9-329d-ae88-66091fcfe3c7
keyTIS21-4236

Jira Legacy
serverSystem JIRA
serverId4c843cd5-e5a9-329d-ae88-66091fcfe3c7
keyTIS21-4246

Later (or never?):

4290

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 used by Recommendation & GMC Client. --force-new-deployment update of the services to apply the configuration

  • 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 and deploy it *E2E tests will need to rely on old codes or be updated.

  • 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

Jira Legacy
serverSystem JIRA
serverId4c843cd5-e5a9-329d-ae88-66091fcfe3c7
keyTIS21-4235

Jira Legacy
serverSystem JIRA
serverId4c843cd5-e5a9-329d-ae88-66091fcfe3c7
keyTIS21-4239

“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

Jira Legacy
serverSystem JIRA
serverId4c843cd5-e5a9-329d-ae88-66091fcfe3c7
keyTIS21-4241

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

Jira Legacy
serverId
serverSystem JIRA
4289

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. Update DesignatedBodyMapper and similar classes to have new codes {in addition to|instead of} existing ones, using (e.g. environment to use new DBC values

    1. TIS-TCS

    2. TIS-REFERENCE although, this doesn’t appear critical for the admin functionality tested

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

Jira Legacy
serverSystem JIRA
serverId4c843cd5-e5a9-329d-ae88-66091fcfe3c7
keyTIS21-42424236

Jira Legacy
serverSystem JIRA
serverId4c843cd5-e5a9-329d-ae88-66091fcfe3c7
keyTIS21-4243

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 )

...

4246

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

Jira Legacy
serverSystem JIRA
serverId4c843cd5-e5a9-329d-ae88-66091fcfe3c7
keyTIS21-4241

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

Jira Legacy
serverSystem JIRA
serverId4c843cd5-e5a9-329d-ae88-66091fcfe3c7
keyTIS21-4242

Jira Legacy
serverSystem JIRA
serverId4c843cd5-e5a9-329d-ae88-66091fcfe3c7
keyTIS21-4243

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 )

Drawio
mVer2
zoom1
simple0
inComment0
pageId3718774801
custContentId3726573630
lbox1
diagramDisplayNameGMC-DBC-timeline
contentVer3
revision3
baseUrlhttps://hee-tis.atlassian.net/wiki
diagramNameGMC-DBC-timeline
pCenter0
width2995
links
tbstyle
height639

Meeting 17 April (Pepe, James, Catherine and Rob)

Objective to work out what needs to be done for the changing the names of designated body, so that TIS is up to date with the new local office names AND any risk of trainees getting confused by “old” designated body names is mitigated.

  1. The names of the offices need to be concluded. These could be names used by the GMC e.g. “NHSE Thames Valley”, or a new organisation agnostic name e.g. “Thames Valley. Rob to find out preferences.

  2. The main impact of name changes is on data and BI teams who use the name in filtering on the NDW. Teams can be prompted to make changes to their queries using an OR statement, but this is dependent on the new name being circulated in advance. James will manage with leads and the NDW.

  3. Hicom will need to make and test changes as they consume data from TIS as part of the existing EST process. When new names are known James to manage with Hicom.

  4. Wider implications and approach to changing TIS and other planning needs to be concluded. This will be done as part of a High Level Estimation session.

Potted plan.

  1. Agree new office names

  2. Circulate office names with a “date to happen”

  3. Teams make changes

  4. On date, new names are updated on TIS (whatever that will be TBD)