User session on Connections 12/08/22

Why Connections?

• Doctors have to be connected to BD to work as a doctor.

• Part of terms and condition to start training;Though this will not stop them from training.

• Nothing to do with ARCP but doctors must be connected 

• Doctors are connected to their training programme

• GMC expect doctors to be connected to an employer/DB

• Legal obligation

• Current way of doing it is difficult. Reconciliation of connection with GMC connect

• Not many use the Discrepancy report which tries to reconcile who should/shouldn't be connected

• Joint obligation btw Admin/Doctor to ensure correct list of connection 

The Dean is the responsible officer (RO) for all trainees connected to their Designated Body. This is covered by GMC and statutory obligations.

Gold Guide - https://www.copmed.org.uk/images/docs/gold-guide-9th-edition/Gold-Guide-9th-Edition-August-2022.pdf

GMC - Revalidation for doctors in training

Statutory - Medical Profession (Responsible Officers) Regulations 2010/13 (see section 13) https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/144188/Annex-B-The-Medical-Profession-Responsible-Officers-Regulations-2010.pdf

No ticket/Action Required?

User Journey (Old Reval)

London not using Old Reval for Connection

• No action before login into TIS-Admin

• Login into old TIS- Reval via TIS Admin

• Go to Connection discrepancies to Remove connection or create connection (this contains the list of current connection)

• Every month, list of discrepancies is transferred into a spreadsheet to check for more details about individual doctor in TIS Admin.

Open

Pain Point:

• Info on TIS -misleading/inaccurate

Opportunity:

• Historic Connection in the new module/system: Might be useful for investigation. This is not available in both old TIS Reval and GMC Connect

Action: How do we minimise inaccuracy in TIS? Can we do that through logic?

RP - what info on TIS is misleading / inaccurate?

Meeting: Accept.

No ticket/Action Required?

User Journey (GMC Connect and TIS- Reval )

• (Before login into system) Users generate mega report via NDW on who’s is finishing/CCT- ARCP outcome 6 - Run report 3 months to finishing. Each Local specialty has its spreadsheet/report

• Check doctors under Notice in TIS-Reval

• Compare the two reports (Under Notice from TIS- Reval and the Local specialty spreadsheet so see who needs connected or disconnected

• Login into GMC connect to do the disconnection or bring forward doctor already connected to appear under Notice

• No action after using the system

Open

Pain Point:

• People connected to wrong RO/Trust (To be considered in discrepancies)

• Doctor not disconnecting themselves when they finish (To be considered in discrepancies)

• Doctors not connecting themselves (To be considered in discrepancies). If a doctor connect himself 2 weeks or more than the programme start date - they are disconnected by Admin

• No way of knowing if a doctor has connected himself somewhere else (To be considered in discrepancies).

Opportunity:

If people connected correctly we don't miss them.

To add connection

• No action before login

• Login into GMC connect

• the default page is under notice doctors' list

• Select Add doctor on the LHS

• put the doctor GMC number to search doctor

• Select reason for adding connection

• Submit

To Remove connection

• No action before login

• Login into GMC connect

• the default page is under notice doctors' list

• Select All doctor on the LHS

• Click remove doctor towards the end of the individual doctor’s row

Note: Good thing about using GMC is that some doctors are not on TIS but in GMC - GMC connect is used to add connection for such doctor.

Pain Point:

• Only displaying All doctors and can only add or remove doctor's connection 

• Only displaying All doctors and can only add or remove doctor's connection 

• Can't view list of historic connection except by individual search

Opportunity:

• Historic Connection Tab in new TIS Reval

• Bulk add/remove connection

• Able to hide doctor from list 

Action: To be considered for discrepancies

• People connected to wrong RO/Trust <what do we send to the GMC. Could the doctor connect themselves to the wrong RO/Trust – Should doc be moved to discrepancy? GMC web service user guide? How does a LO resolve GMC send wrong>

• 25/08/2022 Not possible to be connected to the wrong RO if the DB is correct because RO are associated to DB. The only possibility is for doctors to connect to wrong DB or trust (as a DB). This scenario is already covered in the connection logic - Discrepancies
  
  

• Doctor not disconnecting themselves when they finish
  <the programme end should send doctor to discrepancy for action>
  
  

• Doctors not connecting themselves but If a doctor connect himself 2 weeks or more than the programme start date - they are disconnected by Admin <discrepancy>
  
  

• No way of knowing if a doctor has connected himself somewhere else ????? is there any other system doctors uses to do connection apart from GMC connect? <we don’t think so>

< Users is there any circumstance where a trainee is not on TIS>?

No ticket/Action Required? This part is covered in the connection discrepancies

What Admin will be able to do in connection tabs

Current Connections: Just see doctors connected to the DB

Historic Connections: Not adding any Value

Discrepancies: Add/Remove connections

Hidden: Can't think of anything why we need it

Current Connections: See list and Disconnect

Historic Connections: Just view

Discrepancies: Connect disconnect, Hide and add Note- Reason for Hidden?

Hidden: Unhide and add Note- Reason for Hidden

Action: Redesign of update connection (MVP) and bulk connection (Post MVP?)

Priority: Current connection and Discrepancies tabs (MVP?). Hidden and Historic Post MVP?

<Incline towards TV/NW – features already developed>

Previous tickets completed looked into what data comes from GMC and what comes from TIS, and how that combined data then populates Current Connections and Discrepancies. Then to understand where Reval admins manually effect changes to this base data coming in. Could really use a diagram here!

Easier to enable functionality across the board than to limit on one place or another.

Need to create ticket

UI Design - Doctor detail page

Programme History: No value added

Connection History : Yes want to see

Update Connection : Yes want to see

Programme History: No value added

Connection History : Yes want to see

Update Connection : Yes want to see

Action: To remove the programme History from the new design

Need to create ticket

First name

 Y

 To identify trainee

Y

No ticket/Action Required?

Last name

 Y

 To identify trainee

Y

No ticket/Action Required?

GMC No

 Y

 To identify trainee

Y

No ticket/Action Required?

Programme

 Y

To identify where they are placed

 Y

Should this be renamed ‘Current Programme’?

Should this be renamed ‘Current Programme’?

that would be helpful

No ticket/Action Required?

GMC Submission date

 Y

So they are revalidated in time

 Y

No ticket/Action Required?

Designated body

 Y

 So you know which DB they fall under

 Y

This field only appears for London but other DBs will not see the field in their summary page

This field only appears for London but other DBs will not see the field in their summary page thank you

No ticket/Action Required?

Programme Owner

 N

Can’t see what it would be used for.  However we would need PROGRAMME NAME to identify the specialty.

 Y

Is it possible for the programme owner to be different from the DB? If no, is the field required because the doctor is currently connected to the DB
Note: It might be required for London because of the 4 DBs

Is it possible for the programme owner to be different from the DB? If no, is the field required because the doctor is currently connected to the DB
Note: It might be required for London because of the 4 DBs yes in some circumstances for example where a trainee has a conflict of interest with the RO this is very unusual in the NW but could be more common in other areas – this could also apply to national grid trainees in some areas

No ticket/Action Required?

Programme Membership

 Y

 Not one I use but guess useful given other categories other than substantive.

 Y

This is mostly Substantive. Other categories are Military, Visitor or LAT

This is mostly Substantive. Other categories are Military, Visitor or LAT

If they are connected then they should be substantive – the military, visitor etc wouldn’t be connected to the DB so wouldn’t be needed on this list

No ticket/Action Required?

Current Connection

 N

Don’t think this is required because the 'Current Connection' Tab is reflecting current connected doctors

Don’t think this is required because the 'Current Connection' Tab is reflecting current connected doctors  correct they would all be connected as on the list

Need to create ticket to remove column

Start date

 N

Is this start date in post. Not sure it is needed as if not yet started but they do connect would be picked up in discrepancies.

 ?

 I think that if anything date first connected would be useful rather than their start date in TIS but is not necessary

Need to create ticket to remove column

End date

 Again not sure it’s used but no problem if others use it.

 N

Need to create ticket to remove column

First name

 Y

 Y

No ticket/Action Required?

Last name

 Y

 Y

No ticket/Action Required?

GMC No

 Y

 Y

No ticket/Action Required?

Programme

 The last one only?

 Y

What should be displayed here?
Should it be the latest past programme connection with the DB only or multiple programme list with other DBs?

What should be displayed here?
Should it be the latest past programme connection with the DB only or multiple programme list with other DBs? If possible it would be ideal to see a full history but as this is in TIS then the latest past programme would suffice

No ticket/Action Required?

GMC Submission date

 Y

 So can see when put through?

 N

Should this be empty? If yes, why the need to display?

Should this be empty? If yes, why the need to display? This wouldn’t be needed as would be inaccurate as there would be no way to be updated via TIS API if not connected

No ticket/Action Required?

Designated body

 Y

 See which RP they fell under?

 N

This field only appears for London but other DBs will not see the field

Should this be empty? If yes, why the need to display?

This field only appears for London but other DBs will not see the field

Should this be empty? If yes, why the need to display? I wouldn’t think be needed

No ticket/Action Required?

Programme Owner

 Y

Should it be the latest past Programme Owner?

Is it possible for the programme owner to be different from the DB? If no, is the field required because the doctor is currently connected to the DB
Note: It might be required for London because of the 4 DBs

Should it be the latest past Programme Owner? I think so

Is it possible for the programme owner to be different from the DB? If no, is the field required because the doctor is currently connected to the DB
Note: It might be required for London because of the 4 DBs

No ticket/Action Required?

Programme Membership

 Y

This is mostly Substantive. Other categories are Military, Visitor or LAT

This is mostly Substantive. Other categories are Military, Visitor or LAT

No ticket/Action Required?

Current Connection

 N

Don’t think this is required because the 'Historic Connection' Tab is reflecting disconnected doctors

Don’t think this is required because the 'Historic Connection' Tab is reflecting disconnected doctors Not required as be inaccurate as not available via TIS API as not longer connected

Need to create ticket to remove column

Start date

 Y

 Start date of connection with DB

No ticket/Action Required?

End date

 Y

 End date of connection with DB

No ticket/Action Required?