Page Comparison

Data leads:

Discussion/Action

Many thanks for previously organising the email addresses to come to us out of TIS from the regions. The launch went well. We need to be able to identify the training programmes the trainees are on that were sent to us to help us calculate response rates. We have this for the London region but is it possible to request this for the South, North and Midlands and East regions? As I say, it is only the training programme – e.g. Foundation, GP, General Surgery etc. - Richard Higgins

26/11: Alistair Pringle (Unlicensed) get a list of names for each region and post on DQ channel.

03/12: Awaiting for the list.

14/01: James Harris will try and do a national pull. Andy has done for the South.

Missing applicants from the South.

Familiarisation of the ESR error reports.

DPNs successfully processed at ESR would exist with an esrLoadStatus of ‘SUCCESS’ in table EsrOutboundApplicantConfirmationRecord. e.g. https://www.useloom.com/share/f5044aa222084b4d98515c5c3d45a033

DPNs successfully received from ESR Outbound Interface as Position Records would exist in tables EsrOutboundPositionInformationRecord or EsrOutboundPositionReconciliationRecord

DPNs ‘EXPORTED’ from Hicom would exist with a TISstatus of ‘IMPORTED_AND_EXCLUDED’ in tables EsrOutboundPositionInformationRecord or EsrOutboundPositionReconciliationRecord

DPNs successfully exported from TIS to ESR with Placement information would exist with a status of ‘EXPORTED’ in EsrInboundApplicantDetailsRecord

And any other reports deemed necessary to investigate support issues.

03/12: Andy Horton (Unlicensed) - Examples of notifications where the next post holders are empty to be provided for further investigation.

08/01: More examples sent through Naz. Comms to be sent trust regarding support.

14/01: Investigation carried out and sent to Mike. Discussed on the ESR call last week. The outcome falls into 3 categories which Mike can explain.

Posts not set up on ESR
Trainees have flowed from TIS to ESR and confirmed from ESR received.
Not a full trail in the logs.

Decision support tree being put in place (Craig Elton from ESR and Mike supporting this)

A demo of how to investigate ESR issues raised by trusts has been scheduled for this Friday. - Intended for HEE staff with access to Metabase.(record the session)

21/01: Session was done on Friday 18/01 on how to investigate ESR issues. Note: This is not to be shared with Trusts or anyone outside HEE due to IG. Link to recording:

https://healtheducationengland.sharepoint.com/:v:/r/TIS/ESR%20Project%20Documents/TIS-ESR%20interface%20issue%20investigation.%20.%20.%20-%2018%20January%202019%2014.04.33.mp4?csf=1

04/02: only outstanding piece of work related to this is to get the data our of Metabase and into NDW and then Tableau for wider investigation

04/03: The ticket is being worked on in this Sprint. TISNEW-1926

This was reported around Christmas period and was resolved, however there are some outstanding actions either between TIS/NDW

TIS-NDW External Flows diagram review?

Impact Assessment when changes made on a particular flow/code

Dashboard for data quality checks.

ETL changes if Hicom products are not re-procured at the end of March 2019.

04/02: Is there an update to this? John Thompson has this been rectified?

JH 31/01/2019:

From a conversation around the Placement Planner Tool, it was brought up that there were current Programmes that didn't have any People or Posts attached. It seemed like this should be something we discuss on the data leads call. From first thought it would seem we should inactivate the programmes.

This spreadsheet lists those Programmes. There is a tab for programmes with both no people or posts attached, one for just no posts and one for just no people.

AR 25/01: Whilst discussing the Bulk Post Upload requirements, it became apparent that 'Programme name' when creating Posts is not a mandatory field on TIS. There are Posts with no programmes at the moment. The consensus was to make this field mandatory when creating posts, however, there will need to be a tidying up exercise by the data leads regarding those posts.

Tableau - Alice and James (Intrepid/TIS views for data audit will show posts with no programme attached)

04/02: Data leads/local offices to de-activate those that can be de-activated and remainder to be left. Not an urgent piece of work.

04/02: Data leads to check the report JH sent showing the placements with no start or end date or both approx. 530

TISNEW-2378 suggests that some Trust users may be attached to inactive trusts.

10

13/08:

Need to ID those Consultants who aren't on TIS as trainers and remove them
Those who are on a trainers we need to understand what information we should surface on their records e.g. Assessment information perhaps isn't required.
All open for discussion and agreement - Ben to set the scene
Other regions to review Alice's scripts.
How were consultants recorded on intrepid? - Simply, not in a consistent way. Some Trusts might have used the consultant role to define these records, others may have applied a training/non-training grade to a record.
~~Benjamin Witton to update with some bullet points of what's been discussed. (not about the mulberry bushes)~~

We have been asked to remove consultant/non-trainee data from the system. The focus is those records where there is noinvolvement in the management of a trainee.
There are four parts involved in this work:
1. Define the rules/cases to identify the records which should be removed from the system. We want to achieve this incrementally, so we should start with easy win's and then work our way to the more difficult cases.
2. Create the SQL scripts, run the SQL scripts and verify the results and that those records should be removed from the system.
3. Introduce a process where the TIS Development Team are able to take the results and simply and efficiently remove the records from the system (without too much back and forth).
4. Confirm with the owner the data to be removed if they want a copy of the data.
Senior colleagues want to see progress by 22nd August. We can satisfy this if we can show our approach and even any preliminary results.

Additional note - during my catch up with Hicom, a proposed solution from Hicom included looking at the role which a record is associated with (i.e. does the record have a role of 'DR in training' or 'GP Tutor' etc.). I am seeking assistance from the NDW Team to produce an output which shows all records and with what role they have (e.g. clinical supervisor, medical director, leave manager etc.). There is an option to work with Regional Data Quality Leads/Local Teams to confirm which roles are they actively using in TIS.

Actions from the meeting:

Alice Brindle to share SQL script with Chris Norman.
Alice Brindle to effectively provide Chris Norman a handover of the SQL.
Benjamin Witton to provide an update to both James Harris and David Short.
Benjamin Witton to catch up with Chris Norman and Adrian Ashley to identify potential case/rules.

Additional actions:

Define with Joanne the roles which should be in TIS.
14/01 - Roles have been defined and documented on Confluence. Next step is to verify those

04/02: Joanne has reviewed the roles and Ola has done the work on making sure each role has the correct permissions.

20/08: CN: ~20000 records potentially identified. Approx. half from KSS and NW.

Removal of non-training grades to follow after removal of consultants - Create Jira ticket to be prioritised.

03/09: Validate 'survivor Ids' on TIS against Intrepid Ids for Leave manager and CPPS

10/09: BW: Waiting on duplication work to be done, then look at.

Dental role approval and accreditation process - piece of work required to align the process. e.g. YH prefixed roles.

Benjamin Witton: Publish on DQ channel for data leads to review or pass to colleagues/quality team to review.e.g. definitions against the roles.

17/09 - (Regarding Roles) - BW update (by BW) - Starter for ten published to Data Quality Leads to review in their respective Regions and Local Teams. Return asked for by Monday 24th September. Link to access the starter is below:

https://healtheducationengland.sharepoint.com/:x:/g/TIS/EY1dIsn6lNFPtpRL9Jz8ncgBLTbJhw1Py3cg2DcYPHREVg?e=Lc1zgK

24/09: Jira Tickets to be created. Benjamin Witton to share work re Roles on DQ channel and follow up.

01/10: TISNEW-2083

22/10: Dependency on the De-dupe work. Follow up with Chris after the de-dupe work has taken place. This is to identify which Consultant data belongs to which Trust so that they can have this if the trust wants.

29/10: Linked to the removal of the consultant information from TIS we also need to address the issue of the non-trainee posts. So a further piece of work needs to take place to identify and hard delete these posts. Will need to take a copy of this so that (like with the non-trainee records) we can pass this to the trusts if needed.JW to create ticket related to the deletion of posts.

19/11 - Once de-dupe is done, check the full list of People from Chris. Please review against the surviving records (IDs) on TISNEW-2057.

14/01: Wait until the testing of the de-dupe has been done on stage then carry on.- Chris Norman (Unlicensed)

04/02: Chris Norman (Unlicensed), David Short (Unlicensed): Awaiting on DS on testing outcome for TISNEW-2057 to prioritise TISNEW-2083. Does the script attached to 2083 has everything?

Check with Rob about urgency of this re IG - JW to do this

Objective:

Gain understanding of what the local office requirements for trust access should be based on - NPN seems to be the incorrect basis as in TWS it is based on Training and/or Employing body

Email conversation excerpts:

07/09:
James:
- Having the logic based on NPN would require us to update thousands of posts numbers and the ESR positions in the trust.
- I was discussing this with Gwilym earlier and we think the logic should be an OR statement with EmployingBody and TrainingBody.
07/09:
- Joanne/Paul: Currently on TIS: Placement > Site > Trust determines the access

- JH: This is what was on Intrepid and works for me
10/09:
- Andy: concerns over placement > site > trust logic
Q - Site reference table - Is site attributed to only one parent trust

Q - So if we are using the Trust of the placement site – then we can still only grant access to a post & its occupant to that one trust

Q - e.g. a Severn GP trainee goes to Royal United Hospital (RD130) for a placement. The parent trust in the reference table for that site would be Royal United Hospitals Bath NHS Foundation Trust (RD1). We would also want however for Gloucestershire Hospitals NHS Foundation Trust (RTE) to have access as the lead employer. The only way I’d picture that happening would be through the ‘OR’ statement on Employing Body and Training Body that James mentioned below.

Q - small pockets of users that are trust based but have their data profiles restricted by Programme. We have done this for the new GP lead employer in Thames Valley as Pennine Acute Trust won the tender as well as some local trust based administrators that only look after GP. This allowed us to prevent them from seeing trainees that were not relevant to them at the trust they are based but also an easy way of seeing the trainees out in GP practices as they don’t really have a parent trust, we have the CCG in that field for GP practices. I suspect we may need to find a workaround to this in the short term perhaps using reporting.

Joanne Watson (Unlicensed) / Ashley Ransoo - Requirement for TIS: (Ticket to be created and get an estimate from Dev)

#

Discussion/Action

Responsible

Outcome

Status

1

Resolve Duplicates - TISDEV-4841: Resolve the duplicate invalid GMC numbers, such as 'Retired,' and make them 'UNKNOWN'

Data leads

5

NETs Data

CLOSE

6

ESR

CLOSE

7

Records Live on TIS but Deleted on Intrepid

JT/Adrian

Closed

8

Programmes with no Posts or People
Posts with no Programmes

View file

name	Current Programmes With No People or Posts Attached RUN 21-01-2019.xlsx
height	150

Data Leads

9

Is this an issue and who would like to take this piece of work on?

04/02: JH to create report showing the users who are attached to inactive trusts and share with group for decision on how to fix this if needed.

JH found 16 users who are attached to an inactive Trust - Scarborough & North East Yorkshire Healthcare NHS Trust, Rotherham Doncaster and South Humber Mental Health NHS Foundation Trust. Kay and Helan at Y&H to be asked if the users Current trust is the right trust by JW

Discussed First discussed on DQ on 04/06:

Agreement re changing '0', 'Retired', 'TBC' or 'u' to UNKNOWN in the GMC/GDC/PH number
Changing blank to UNKNOWN not recommended as it may legitimately be blank because they have a GDC or PH number
What we should do to those with blank/null in all 3?
JH: Among those none have programmes and very few have placements. There are Staff, Both, Contact, Admin.
JW:
- Admin and Contact = N/A ?
- Staff and Both = UNKNOWN ?
  is that the agreement?

04/06: The following has been agreed:

GMC for Contacts, Staff and Both = UNKNOWN
GMC for Admin = N/A

DS: List of persons with same GMC's, check the DW to see if some of those have been resolved?

TISDEV-4841 to be paused from releasing to Prod until David Short (Unlicensed) has done his investigation of the ones that could potentially be merged. Merge Rules to be shared. To create tickets following that.

11/06: Ongoing and will probably be ready mid-week.

18/06: On hold until the document uploads are available on People records? The idea being if de-duplicated before the documents have been added, we won't be able to attach the documents to the deduped person records.

Get an update from Ben/Anita regarding document management in a couple of weeks.

02/07: Benjamin Wittonare you able to give an update on this?

09/07: Ben: We are expecting the document delta from Hicom this week. The next step will be to get them onto Azure and then apply the agreed meta tags. Do let me know if you need any other details/updates.

16/07: Delta received. Document work to continue in this sprint. Following which David can work his magic on the duplicates. David Short (Unlicensed) does your initial work need to be revisited? and will there be any dev requirement related to your dup work? We will need to include this in Planning so will need to know Complexity and volume - David may need to work with Dev in next sprint in order to prepare this. Prioritisation required.

23/07: Work in progress, script modified. (David Short (Unlicensed), bullet points of what's required to bring into the sprint as User Stories)

13/08: Document Management migration complete - when can work start on the duplicate records David Short (Unlicensed) ?

20/08: DS: Scripts being worked on. Next step to create the stories in Jira.

03/09: David: Looking at having the scenarios by end of the week.

10/09: DS confirmed this is a trainee on his list too -

Jira Legacy

server	System JIRA
serverId	4c843cd5-e5a9-329d-ae88-66091fcfe3c7
key	TISNEW-1894

10/09: DS demo'ed some 'strong match' scenarios that can be safely de-duped. Sue/ Joanne Watson (Unlicensed): impact on leave manager when de-duped.

Output of Round 1 of de-duplication:

https://healtheducationengland.sharepoint.com/:x:/r/sites/WPI-North/Shared Documents/TIS/North (all)/TIS Person De-Dup Project/Duplicates Output v1.xlsx?d=w70c77e6caa5b4cc1a2408663a1e77fd6&e=4%3a3feb8d869af74e61aeae63ea2a9baff4&at=9

17/09: Tickets for dev to start looking at. (AR and DS)

Considering other priorities in the next sprint, we are looking at mid to late October.

24/09:

Jira Legacy

server	System JIRA
serverId	4c843cd5-e5a9-329d-ae88-66091fcfe3c7
key	TISNEW-2057

- DS to send the rules to add to the ticket. (This has been added to Sprint 59 which is due to start on Thursday - do we have all the info we need?)

01/10: Methodology attached to the ticket. David Short (Unlicensed) to separate out only the records that need to be merged for Round 1 to attach to the ticket.

15/10: TISNEW-2057 has been pulled out of sprint due to impact on leave manager records. Merging on the TIS side would leave orphan records on the Intrepid/TWS side.

22/10: Awaiting confirmation on the above regarding the correct records out of the duplicates to get rid of.

29/10: List received from David - will add to the ticket and work with devs to get it into a forthcoming sprint.

05/11: Awaiting confirmation on the merge rules from Data leads, as the work involves merging data to the survivor person record then removing the duplicate.

DS: There are 2 main merge rules that need to be reviewed by other data leads and may require some tweaking.

Person Merge Rules (DRAFT) (David Short (Unlicensed), James Harris, Alice Thompson, Sue Barrand (Unlicensed))

1.All associated records (placements, programme/curriculum memberships, ARCPs, etc.) belonging to a duplicate person record need to be transferred to the surviving person record.

2.Where the surviving person record has a field containing a NULL or Zero-Length-Strings value but the same field in the duplicate person record contains a non-NULL/ZLS value, this value should be copied into the surviving person record. This should exclude address fields due to possible town/county/postcode mismatches.

Use the address that are against the survivor records. The script to be tested on UAT first with the data leads.
All associated records (placements, programme/curriculum memberships, ARCPs, etc.) regardless of whether they are different on the duplicate Person record, bring across to the Survivor records.
Data leads to specify the fields for which we do (2) and those to exclude e.g. Address. DS will provide this.
Documents: Pull all the docs from the Duplicate across to the Survivor records regardless of whether these are duplicates.
GMC/GDC/PH that should be kept on the survivor records to be confirmed. DS: Basically, after a person record merge, if a GMC/GDC/PH number is specified, that is the value that should be assigned to the GMC/GDC/PH field of the surviving record. In the case of blanks, the current value (whatever that they be) of the surviving record is retained.

12/11: The merge rules have been updated on the ticket and David has provided attachments for:
- what GMC/GDC/PH to use on the surviving record
- list of front end fields where values can be taken from duplicates to surviving where there is a blank in the surviving record
Could you all confirm please?

Jira Legacy

server	System JIRA
serverId	4c843cd5-e5a9-329d-ae88-66091fcfe3c7
key	TISNEW-2057

Added rule for Sensitive data - All rules confirmed by data leads.

26/11:

The devs have done a spike on this and came up with the following approach,

Proposed Solution: With regard to the attached template "TIS People Upload Template - Duplicated records.xlsx", we propose to do a series of 'updates to' and 'insert into' the surviving record. Once this gets completed, we will proceed to delete the duplicate records.

Updates:
1) We will be implementing merge rule 3 on the following fields for the surviving record:
Title
Initials
Known As
Forename
Surname
Maiden Name
Legal Forenames
Legal Surname
Telephone Number
Mobile Number
Email Address

i.e. if a value is present on the duplicate record for the above but null on the surviving, we will be copying them onto the surviving record.

2) We will be directly updating the surviving records with the presented GmcDetail or GdcDetail. https://hee-tis.atlassian.net/secure/attachment/21793/DeDup_NoLeave_GMC_GDC_PH.xlsx

3) Insert:
We will be inserting all the following records of the duplicate into the surviving record
- Programme Membership
- Qualifications
- Documents
- Placements
- Assessment

https://hee-tis.atlassian.net/secure/attachment/21842/TIS%20People%20Upload%20Template%20-%20Duplicated%20records%20_AR.xlsx

26/11: Deleting records on Intrepid - will the ETL take care of this? - follow up with the devs/hicom/Adrian Ashley - The expectation is to get them deleted on Intrepid as well.

03/12:

Template was sent by David, thank you!
- a further question raised by the dev on the de-duplication work.
- Where there are more than 1 duplicate person records being merged to a surviving record, which of the 'DuplicateRecordID' should we apply rule 3 to? - David has provided a sequence, the devs are investigating and may come back with more details.
Once we've done the merging on TIS and deleted the duplicates, the survivor records will feed into the Intrepid with the updates. The Deleted records will not be sent to Intrepid. They will need to be deleted on Intrepid.

08/01:

Data leads/local offices to check and confirm all is good before changes can be pushed to Prod
Currently holding up any release to Assessments - any future data updates/corrections like this wil need to have the testing window agreed with the local offices/testers so that the TIS team know and can make users aware of any restrictions to releases due to data being checked.

DS: Has done some testing.

SB: leave manager tests carried out.

JH/DS/AH: re-use some of the scripts that were used during consolidation for testing on metabase for next week.

DS: Prog membership, placements and assessments - Looks good so far.

How long more this would need? - conclude by Wed 16/01.(Sue Barrand (Unlicensed), David Short (Unlicensed) and James Harris are going to test this on Wednesday afternoon)

21/09: The scripts have been run on Prod over the weekend. David Short (Unlicensed) has taken extracts of the data on Friday afternoon ahead of the scripts being run.

4/02: Round two will be needed. LaSE still to advise DS on what to do with the records that weren't an easy match. Chris picking this up - London may be ok but KSS need more attention

4/02: Leave manager - need to do checks for the circa 500 records to make sure that the round 2 de-duping would not leave orphaned records (as per the procedure for Round 1

2

Identification and removal of Consultant data on TIS

All

3

Trust access - role logic

All / Andy Horton (Unlicensed) / James Harris

Jira Legacy

server	System JIRA
serverId	4c843cd5-e5a9-329d-ae88-66091fcfe3c7
key	TISNEW-1987

People - If either the trainnee's EmployingBody OR TrainingBody for their Current Placement Post match the Trust, then make available to the Trust.

Posts - If either the User is at a trust which is the EmployingBody OR TrainingBody of the Post, then make available to the Trust.

17/09:

JW:

...very rough guideline of the complexity of amending the current logic on the trust role was given an 8 (out of a possible 10). This is rather large and I have concerns that we might not make the deadline of the end of next week for the role to be amended, tested and users issued with their login details.

So, with the above in mind I considered what else we could do if we approach this from another angle. Please could I ask you to consider the following - instead of changing the trust role we leave it as it currently is - so placement>post>site>trust but for those users who are lead employers or who just need to see the trainees and posts from a number of trusts we give them the access to that range of trusts so they can see the entire trainee landscape they should. We would obviously need this info from yourselves but it would save us a lot of dev time.

This isn't elegant but should get us across the line for the 1st October. I then suggest that I ask Ashley to speak to you all asap and get full understanding of the different roles in trust-land so that we can correctly create roles that are needed e.g. the one to allow users to only see trainees based on programme etc. We can then get these roles created and rolled out.

GW/AH: There might be an IG Issue as they would be able to see trainees that they should not be able to see.

JW: Will be discussed at pre-planning. This will be taken into the next sprint. Review progress on next call.

24/09: Being worked on in Current Sprint. Joanne Watson (Unlicensed)/ Alistair Pringle (Unlicensed) - To get an update from dev

01/10: Trust role on Prod. Need to create the trust access role based on Programme next.

22/10: Andy will confirm the details ahead of next sprint planning.

29/10: Andy confirmed that the logic was acceptable for the South. Forwarded to LaSE and North for info. Ticket will go into Sprint 61. JW to speak to Simon/Paul about a bulk addition of these users/

05/11: In progress in current sprint

12/11: How many different user roles are we eventually going to have for Trusts access? - To review with the devs/ UM

19/11: Yes, if there is a requirement to, would need to be ticketed up as and when.

26/10: Programme based access, released on Friday. James testing it at the moment.

03/10: This has been released as part of last sprint. Can this be closed?

some of the issues could not be replicated.
Trust level access v/s Programme level access - understanding the interactions between the two? - Alistair Pringle (Unlicensed)
Roles: Definition (review confluence and update with the devs on what each of them gives access to)
Report of Roles against individuals (check with NDW)

14/01: Andy Horton (Unlicensed) to test with future programme membership. Provide some examples.

04/02: Paul has applied the fix - will be on Prod on the 5th. JW to test before alerting users

4Rob - New approach with data leads/data group:Rob/Data Leads

To discuss with the existing data leads...

Data Group
• X4 Regional Data Leads; NDW link; Service Manager
• Self-ordering team
• Transparency
o One action list
o MS Teams
o Slack

• Ownership of the data model in TIS inc. multi-professional
• Manage business-facing reference tables and have a change control process
• Simplify reference data and standardise to HEE / DH / ESR standards
• Management of data issues as and when
• Develop Dashboards
o Data Quality
o Management information
• Participate as data experts in any process alignment, research or development work
• Help identify, rationalise and simplify data flows and data handling e.g. bulk uploads, ESR etc
• Prioritise data activity
• Work with NDW to ensure data relevance
• Develop and support national reports and extracts
• Undertake testing where there is a data

05/11: BW when is this going to get formalised and therefore move this call entirely to the new 'TIS Data Group'.

12/11: Data quality dashboard? Alistair Pringle (Unlicensed) to speak to Rob.

CLOSE

08/01:

Jira Legacy

server	System JIRA
serverId	4c843cd5-e5a9-329d-ae88-66091fcfe3c7
key	TISNEW-2364

- Work completed for Round 1 on Stage and testing began. Since this was a flyway script, the importance was stressed on completion of the testing on stage as this would block anything else from being released to Production in out release pipeline

DS: Has done some testing. SB: leave manager tests carried out. JH/DS/AH: re-use some of the scripts that were used during consolidation for testing on metabase for next week.

DS: Prog membership, placements and assessments - Looks good so far.

How long more this would need? - conclude by Wed 16/01.(Sue Barrand (Unlicensed), David Short (Unlicensed) and James Harris are going to test this on Wednesday afternoon)

21/09: The scripts have been run on Prod over the weekend. David Short (Unlicensed) has taken extracts of the data on Friday afternoon ahead of the scripts being run.

4/02: Round two will be needed. LaSE still to advise DS on what to do with the records that weren't an easy match. Chris picking this up - London may be ok but KSS need more attention

4/02: Leave manager - need to do checks for the circa 500 records to make sure that the round 2 de-duping would not leave orphaned records (as per the procedure for Round 1

2Identification and removal of Consultant data on TISAll

Removal of consultant data has a dependency on De-duplication work.

22/10: Dependency on the De-dupe work. Follow up with Chris after the de-dupe work has taken place. This is to identify which Consultant data belongs to which Trust so that they can have this if the trust wants.

29/10: Linked to the removal of the consultant information from TIS we also need to address the issue of the non-trainee posts. So a further piece of work needs to take place to identify and hard delete these posts. Will need to take a copy of this so that (like with the non-trainee records) we can pass this to the trusts if needed. JW to create ticket related to the deletion of posts.

19/11 - Once de-dupe is done, check the full list of People from Chris. Please review against the surviving records (IDs) on TISNEW-2057.

14/01: Wait until the testing of the de-dupe has been done on stage then carry on.- Chris Norman (Unlicensed)

04/02: Chris Norman (Unlicensed), David Short (Unlicensed): Awaiting on DS on testing outcome for TISNEW-2057 to prioritise TISNEW-2083. Does the script attached to 2083 has everything?

Check with Rob about urgency of this re IG - JW to do this

4

Programmes with no Posts or People
Posts with no Programmes

View file

name	Current Programmes With No People or Posts Attached RUN 21-01-2019.xlsx
height	150

Data Leads

JH 31/01/2019:

From a conversation around the Placement Planner Tool, it was brought up that there were current Programmes that didn't have any People or Posts attached. It seemed like this should be something we discuss on the data leads call. From first thought it would seem we should inactivate the programmes.

This spreadsheet lists those Programmes. There is a tab for programmes with both no people or posts attached, one for just no posts and one for just no people.

AR 25/01: Whilst discussing the Bulk Post Upload requirements, it became apparent that 'Programme name' when creating Posts is not a mandatory field on TIS. There are Posts with no programmes at the moment. The consensus was to make this field mandatory when creating posts, however, there will need to be a tidying up exercise by the data leads regarding those posts.

Tableau - Alice and James (Intrepid/TIS views for data audit will show posts with no programme attached)

04/02: Data leads/local offices to de-activate those that can be de-activated and remainder to be left. Not an urgent piece of work.

04/02: Data leads to check the report JH sent showing the placements with no start or end date or both approx. 530

5

TISNEW-2378 suggests that some Trust users may be attached to inactive trusts.

Is this an issue and who would like to take this piece of work on?

04/02: JH to create report showing the users who are attached to inactive trusts and share with group for decision on how to fix this if needed.

JH found 16 users who are attached to an inactive Trust - Scarborough & North East Yorkshire Healthcare NHS Trust, Rotherham Doncaster and South Humber Mental Health NHS Foundation Trust. Kay and Helan at Y&H to be asked if the users Current trust is the right trust by JW

6Trust Users creation for LaSEMaria Kist (Unlicensed)/ Chris Norman (Unlicensed)

01/04/2019: LaSE- Creation of Trust Users. What is the priority on this? The last we had was this would be required for beginning of May, which has therefore made the IMT posts ticket a higher priority than this.

Jira Legacy

server	System JIRA
serverId	4c843cd5-e5a9-329d-ae88-66091fcfe3c7
key	TISNEW-2782

7Internal Medicine Training (IMT) Posts Upload for LaSEMaria Kist (Unlicensed)/ Chris Norman (Unlicensed)

01/04/2019: The following ticket has been taken into our current sprint due to the urgency LaSE requires the IMT posts to be on TIS (by mid-April). However we are still awaiting for the template to be completed and sent over to the TIS development team.

Jira Legacy

server	System JIRA
serverId	4c843cd5-e5a9-329d-ae88-66091fcfe3c7
key	TISNEW-2829

8Sites created with Trust code. Trust codes are not unique.

01/03/2019: Tom De Salis:

Cleansing the NTS data revealed the fact that 3 of our CCGs merged into a super-CCG last year, which means their sites have the wrong Trust/Trust code on TIS. This is an issue on both the Site reference table and on all the posts related to these sites. It affects around 100 sites.

Do we know when the post update tool might be available to update the posts? Is it worth waiting?
Would we be able to do an update on the back-end to the site reference table?

AR:

Site is linked to Trust via the TrustId. When creating a Site, a valid Trust Code is entered and the Trust ID is fetched from the Trust reference table to attach to the Site.

However, since the Trust Code is not currently unique in the Trust reference table, the site might be linked to incorrect Trusts.

E.g.

Trust Code RQ3: