...
...
...
...
...
...
Summary:
Condensed logic for Connections
Simple, if GMC says it’s connected, put it here:
WHERE existsInGmc == true
Condensed logic for Discrepancies
There appear to be a number of logical groups of scenarios that can occur:
Programme Memberships (DBC) do not match - 3,4,5,6,7 (Condition: WHERE designatedBody != tcsDesignatedBody) 
OR
Programme Membership Issue (expired, none or concurrent) 11, 12, 13, 15 (Condition: WHERE connectionStatus == "NO" && existsInGmc == true) - included in above logic, but useful to distinguish, also WHERE multiple programme memberships
OR
GMC Numbers do not match 8,9,10 (Condition: WHERE gmcReferenceNumber = null , WHERE tisPersonId == null ← Also multiple Tis people assigned to one GMC number?
OR
Special Case 16 Where membershipType = INACTIVE && existsInGmc == true ← we don’t currently get placement type through
OR
Something went wrong with an attempt to connect/disconnect 14 (does this need to be shown in discrepancies or is this just an error box?) - WHERE exceptionReason != null?
17,18,19 are unclear or do not have any specific logic associated with them
- not currently possible to do this in an elasticsearch query on the version we’re on (needs “runtime fields”) - has to be calculated “ahead of time”
...
“Show Your Working”:
For Reference: Elasticsearch Fields
| Expand |
|---|
| title | For Reference: Elasticsearch Fields |
|---|
|
masterdoctorindex Fields | Source of Truth (which service has final say) | Required by Recommendations | Required by Connections |
|---|
id | Elasticsearch (Auto Id) | ✅ | ✅ | tcsPersonId | TCS | ✅ | ✅ | gmcReferenceNumber | GMC | ✅ | ✅ | doctorFirstName | GMC | ✅ | ✅ | doctorLastName | GMC | ✅ | ✅ | submissionDate | GMC | ✅ | ✅ | ProgrammeName | TIS | ✅ | ✅ | membershipType | TIS | ✅ | ✅ | designatedBody | GMC | ✅ | ✅ | gmcStatus | GMC | ✅ | | tisStatus | REVAL | ✅ | | admin | REVAL | ✅ | | lastupdatedDate | REVAL | ✅ | | underNotice | GMC | ✅ | | tcsDesignatedBody | TIS | | ✅ | programmeOwner | TIS | | ✅ | curriculumEndDate | TIS | ✅ | | connectionStatus NB: This field will be deleted as part of | Jira Legacy |
|---|
| server | System JIRA |
|---|
| serverId | 4c843cd5-e5a9-329d-ae88-66091fcfe3c7 |
|---|
| key | TIS21-4194 |
|---|
|
as it is only updated whenever a TIS person changes, so does not represent a “live” field*this should be renamed “tisConnectionStatus” and refers to TIS' “point of view” about the connection, and is set to “No” in the following circumstance:
Objects.isNull(curriculumMembership) ||
Objects.isNull(programmeMembership) || Objects.isNull(programmeMembership.getProgrammeStartDate()) || Objects.isNull(programmeMembership.getProgrammeEndDate()) || programmeMembership.getProgrammeStartDate().isAfter(currentDate) || programmeMembership.getProgrammeEndDate().isBefore(currentDate); | TIS | | ✅ | membershipStartDate | TIS | | ✅ | membershipEndDate | TIS | | ✅ | existsInGmc | GMC | ✅ | | exceptionReason* *this field is currently in the code in connections but doesn’t exist in masterdoctorindex, appears to have been overlooked | TIS/REVAL | | ✅ |
|
Implementation Notes
Condensed Logic
A number of the scenarios listed in the table below can be covered by the same logic, here is a collation of all the different logic required to cover all scenarios
Connections
WHERE existsInGMC = true
Discrepancies
WHERE designatedBody != tcsDesignatedBody
OR
WHERE gmcReferenceNumber != tisGmcReferenceNumber ← “tisGmcReferenceNumber” not currently an existing field!
Scenario implementation table
| Expand |
|---|
| title | Scenario implementation table |
|---|
|
Scenario description Cross Reference with priority: Connections Logic - Discussions with Users | Trigger/Action - Where does this data come from? What Services and methods are involved? Note - this column is for existing architecture only, not for architecture proposals! | How does this affect what’s shown in Connections and Discrepancies and how can we test for this? | Other Notes | Can be done at query time Is this scenario is trivial? e.g. equivalent to a SQL “WHERE” clause Or does this have to be done at “update time”, i.e. would need a calculation comparing two fields during ES sync job | Related tickets |
|---|
[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 | Drawio |
|---|
| mVer | 2 |
|---|
| zoom | 1 |
|---|
| simple | 0 |
|---|
| inComment | 0 |
|---|
| pageId | 3702784003 |
|---|
| custContentId | 3702587425 |
|---|
| lbox | 1 |
|---|
| diagramDisplayName | Untitled Diagram-1674721032202.drawio |
|---|
| contentVer | 3 |
|---|
| revision | 3 |
|---|
| baseUrl | https://hee-tis.atlassian.net/wiki |
|---|
| diagramName | Untitled Diagram-1674721032202.drawio |
|---|
| pCenter | 0 |
|---|
| width | 711 |
|---|
| links | |
|---|
| tbstyle | |
|---|
| height | 451.5 |
|---|
|
| 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: Flag where the TIS DBC is different from the GMC DBC when a new change is made 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 | Drawio |
|---|
| mVer | 2 |
|---|
| zoom | 1 |
|---|
| simple | 0 |
|---|
| inComment | 0 |
|---|
| pageId | 3702784003 |
|---|
| custContentId | 3702947916 |
|---|
| lbox | 1 |
|---|
| diagramDisplayName | Untitled Diagram-1674732488277.drawio |
|---|
| contentVer | 1 |
|---|
| revision | 1 |
|---|
| baseUrl | https://hee-tis.atlassian.net/wiki |
|---|
| diagramName | Untitled Diagram-1674732488277.drawio |
|---|
| pCenter | 0 |
|---|
| width | 711 |
|---|
| links | |
|---|
| tbstyle | |
|---|
| height | 451.5 |
|---|
|
| 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: Flag where the TIS DBC is different from the GMC DBC when a new change is made 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 | Drawio |
|---|
| mVer | 2 |
|---|
| zoom | 1 |
|---|
| simple | 0 |
|---|
| inComment | 0 |
|---|
| pageId | 3702784003 |
|---|
| custContentId | 3703865368 |
|---|
| lbox | 1 |
|---|
| diagramDisplayName | Untitled Diagram-1674766106839.drawio |
|---|
| contentVer | 1 |
|---|
| revision | 1 |
|---|
| baseUrl | https://hee-tis.atlassian.net/wiki |
|---|
| diagramName | Untitled Diagram-1674766106839.drawio |
|---|
| pCenter | 0 |
|---|
| width | 711 |
|---|
| links | |
|---|
| tbstyle | |
|---|
| height | 451.5 |
|---|
|
| 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 | | | | | |
|