Page Comparison

• Programme names/numbers aren’t provided for Dental trainees, they’re created by Admins

John to schedule time to review it

05/03 Claire to prod on what the progress is on this  

05/03 JT to chase up when he's back in London on 06/03

12/03 Demo to be arranged, check if JH is back. Chris Norman to share SQl script. 

26/03 JT to setup doodle poll to arrange date for demo.

09/04: To chase JT for this to be done.

16/04 - Taking place in the next few days.

30/04 - Done, closing. 

Place holder

AP/JH/IO: IO To update with ticket numnber numbers and post on DQ channel.

Update on the missing placements (James/Claire) flagged on DQ channel - Data not pulling through rather than missing placements. 

IO to review the feedback from Claire

09/04: Claire Shared with other Data leads to test the UI and feedback - JH, AB & DS

15/04: Update?

19/04:  Go through BAU tickets

30/04: Check status of those tickets and review . IO to cite the tickets here for CL to review when ready.

Placement import template v.s. Placement manager?

Are these separate and are means to what end?

AP: Follow up with Rob - Extract from NDW and feed into ETL?

AR: 23/04: Rob has setup a slack channel to discuss #intrepid-placement-manager. TIS team meeting with JH this week to discuss solution design.

This channel is being set up to help resolve an efficient way to manage the Intrepid Placement Manager. This module is used by EOE to manage placements.
- The module enables placements to be managed in a "draft", or pre-published state.
- On publishing, the placements are fed into Intrepid.
- The data is available in DR2.
Data flows from TIS to Intrepid and will replace Intrepid placement data. Therefore, on publishing the data also needs to be extracted from DR2 and uploaded into TIS, so that it can be passed back into Intrepid. This needs to happen daily and will require controls.
- The process to manually extract from Intrepid and upload to TIS may be burdensome
- There is a need to make sure data extracted from DR conforms to the placement upload (this is probably the first task) to do...
- Consideration around automation and so on can follow.

Bulk Assessment template to be reviewed.

Assessment - Bulk Upload (DRAFT)

Assessment - Bulk Upload (DRAFT)#BulkUpload(DRAFT)-TISBulkAssessmentUploadTemplate(DRAFT)

Data leads

CL/JH/AB/DS

AR: Share on DQ Slack channel

AR 23/04: Alice has added her recommendations and shared on DQ channel, can other data leads review and confirm?

AR: 30/04: TO review comments from Alice and James

Bulk People Import - Feedback

Check if the Expectations are correct on the Jira tickets

Check progress end of week on bug fixes.

Release to users for testing. 

AR 23/04: Demo on people bulk upload was done on last Show & Tell. User guides being updated with to include bulk upload. 

Programme membership rules discussed and agreed to be made consistent on both FE and FE, i.e. where a Programme membership exist against a person where Programme name, number, membership type , start and end dates match exactly to those on the template, it will be flagged as an error. If any of those differ, multiple memberhships of the Programe anem name + Number allowed. 

30/04: IO/Reubs: Review in progress, not ready to test. 

Telephone and Mobile numbers validation in TIS. Currently the bulk People upload does not allow a row on the template to be uploaded where there is an existing person in TIS with a Mobile/Telephone number that is not in the TIS accepted format and has been left blank on the template. 

TIS field validation:

• numerical values 
• allow ( + ) and ( - ) 
• allow spaces 
• no min/max length 

There re currently over ~7000 records on TIS that do not meet the above. i.e. contains letters, special charaterers other than the above.

https://build.tis.nhs.uk/metabase/question/179

Should there be a softer rule for telephone/mobile numbers?

AR: Share the conversation on DQ

IO: Separate discussion taking place with Reuben to discuss the solution design. There is not currently a way of identifying legacy created or TIS created data. 

Reubs: the initial underlying principle in TIS was that we wouldn't force users to update legacy data in order to edit a record in TIS.

InterDeanery Transfer (IDT) process and potential issues raised:

1. for trainees moving from the NE or Yorks and Humber to non TIS local offices
2. for trainees moving from non TIS offices to the NE or Yorks and Humber

(Trainees NE to Yorks and Humber or vice versa - no issue and trainees moving from non TIS local office to non TIS local office no perceived issues)

Assessment of the impact and understand implications. 

IDT - covered by codes of practice

Understand Rebase - Speak to Reuben. 

CL: Given the small numbers, suggestion is to update on both Intrepid and TIS. Make the updates just before going live - Data leads to coordinate. 

2) - Non-issue.

CL: To send comms on the process. 

JH: ETL flow from Datawarehouse to Intrepid with TIS updates.