[1] F1 Doctor

[2] Military Doctor

[3] Update made via GMC Connect

Doctor is Connected to a DBC (Add connection)

Doctor changed from disconnected → connected in GMC-Connect

Change in GMC Designated Body code is picked up by Reval system during the overnight sync. If doctor was previously disconnected, “existsInGmc” field will be changed from false to true

Current Connections:
WHERE existsInGmc = true

Discrepancies
WHERE existsInGmc == true && connectionStatus== No

or

WHERE TIS DBC != to DoctorsForDB (GMC) DBC

If a doctor is connected to a DBC via GMC connect, this change will come through to our Revalidation system via the GMC sync.

The discrepancy occurs because the TIS system is not updated accordingly

We need to be able to:

1. Flag where the TIS DBC is different from the GMC DBC when a new change is made

2. Flag where the TIS DBC is different from the GMC DBC for historic/existing data in our system

✅

if using WHERE existsInGmc == true && connectionStatus== No

if using TIS DBC != GMC DBC

[4] Update made via GMC Connect

Doctor is disconnected from a DBC (Remove connection)

Doctor changed from disconnected → connected in GMC-Connect

Change in GMC Designated Body code is picked up by Reval system during the overnight sync. If doctor was previously disconnected, “existsInGmc” field will be changed from false to true

Current Connections:
Not shown (i.e. won’t show up WHERE existsInGmc = true)

Discrepancies
WHERE existsInGmc == false && connectionStatus == Yes

or

WHERE TIS DBC != to DoctorsForDB (GMC) DBC

If a doctor is disconnected from a DBC via GMC connect, this change will come through to our Revalidation system via the GMC sync.

The discrepancy occurs because the TIS system is not updated accordingly

We need to be able to:

1. Flag where the TIS DBC is different from the GMC DBC when a new change is made

2. Flag where the TIS DBC is different from the GMC DBC for historic/existing data in our system

✅

if using WHERE existsInGmc == false && connectionStatus== Yes

if using TIS DBC != GMC DBC

[5] DBC removed/remove connection

TIS shows Current Programme Membership && No DB

The connectionStatus field essentially contains the answer to the question “does this doctor have a current programme”, so:

Current Connections

WHERE existsInGmc = true

Discrepancies
WHERE existsInGmc == true && connectionStatus== No

This scenario can be covered by the same test as “Doctor is Connected to a DBC (Add connection)”

Probably applies to a lot of older data?

✅

if using WHERE existsInGmc == true && connectionStatus== No

if using TIS DBC != GMC DBC

[6] DBC not matching for both TIS and GMC

Doctor’s DBC is changed in GMC connect

When the DBC is changed in GMC connect, it comes through to our REVAL system during the overnight sync, but TIS is not updated, this means they will not match

Current Connections:

WHERE existsInGmc = true

Discrepancies
WHERE TIS DBC != to DoctorsForDB (GMC) DBC

Would have to calculate TIS DBC != GMC DBC at update time

[7] Programme membership not matching

Once again, rephrasing of TIS DBC != GMC DBC

Would have to calculate TIS DBC != GMC DBC at update time

[8] GMC number not matching

Not sure how why this happens, data entry error in TIS?

How do we test this? If the GMC numbers don’t match how else? by name?

Would have to test number from GMC with number from TIS at update time

[9] No GMC number in TIS

GMC send a GMC number for a doctor who had no GMC number in TIS

Not sure how why this happens, data entry error in TIS?

Would have to be done at update time (“IF data update is coming from TIS AND gmc Number is null) unless we create a new field “tisGmcNumber” (“IF tisGMCNumber = null”)

Would have to test number from TIS at update time

[10] GMC provide doctor not in TIS

Rephrasing of the above?

[11] Doctor has current programme membership in TIS, not connected to DBC & programme end date is today or in the future

Elastic Search Rebuild Sync Job
And/Or
TIS Change Data Capture

This logic is contained within the connectionStatus field (see fields table at top of this document for details)

Current Connections:
WHERE existsInGmc = true

Discrepancies
WHERE existsInGmc == false && connectionStatus== Yes

or

WHERE TIS DBC != to DoctorsForDB (GMC) DBC

✅

if using WHERE existsInGmc == false && connectionStatus== Yes

if using TIS DBC != GMC DBC

[12] Doctor Connected to a DBC and Programme Membership not expired

Elastic Search Rebuild Sync Job
And/Or
TIS Change Data Capture

This logic is contained within the connectionStatus field (see fields table at top of this document for details)

Current Connections:
WHERE existsInGmc = true

Discrepancies
WHERE existsInGmc == false && connectionStatus== Yes

or

WHERE TIS DBC != to DoctorsForDB (GMC) DBC

✅

if using WHERE existsInGmc == false && connectionStatus== Yes

if using TIS DBC != GMC DBC

[13] Doctor Connected to a DBC and Programme membership Expired

Elastic Search Rebuild Sync Job
And/Or
TIS Change Data Capture

This logic is contained within the connectionStatus field (see fields table at top of this document for details)

Current Connections:
WHERE existsInGmc = true

Discrepancies
WHERE existsInGmc == false && connectionStatus== Yes

or

WHERE TIS DBC != to DoctorsForDB (GMC) DBC

✅

if using WHERE existsInGmc == false && connectionStatus== Yes

if using TIS DBC != GMC DBC

[14] TIS to GMC API failure

[15] Overlapping programmes in 2 regions

TIS Data Entry Error?Does the current implementation for multiple programmes being sent to reval cover this?

Where programmeName contains “|” ?

[16] INACTIVE Doctors in TIS

We don’t currently get this information in reval, will probably need a bigger ticket

[17] Hide doctor with current connection

[18] NEW: License to Practice removed due to suspension

[19]Sanity check data on Prod