Page Comparison

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 

RP - is the purpose of Connections:

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.

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.

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

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>?

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>

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

First name

 Y

 To identify trainee

Y

Last name

 Y

 To identify trainee

Y

GMC No

 Y

 To identify trainee

Y

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

GMC Submission date

 Y

So they are revalidated in time

 Y

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

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

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

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

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

End date

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

 N

First name

 Y

 Y

Last name

 Y

 Y

GMC No

 Y

 Y

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

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

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

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

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

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

Start date

 Y

 Start date of connection with DB

End date

 Y

 End date of connection with DB