Connections Logic Implementation
- Cai Willis
NOTE: This documentation currently pertains to the early implementations of the “new” connections application and is subject to change
A Note on general architecture
Recommended Reading: Elasticsearch
The data shown in the connections tabs are the result of a combination of an overnight sync job and continuous Change Data Capture (CDC) from TIS.
The logic for which tab a given doctor should appear under is determined when a change in data occurs.
i.e. If something changes about a doctor or an associated programme, this is picked up by the connection microservice and the doctor’s status is re-evaluated.
Connection Logic Flow
Check Connection Status (see below)
Check for Exceptions (see below)
If Connected, remove from Disconnected and vice versa
Connected/Disconnected status
Recommended reading: Connections - how is current status determined?
The following logic is currently implemented (as of 23/08/2022):
If curriculum membership is null - disconnected
if programme membership is null (or pm dates are null) - disconnected
if programme start date is after now- disconnected
if programme end date is before now- disconnected
Otherwise - connected
Source (note that this logic is implemented in TCS, not connection service):
Exception status
The following logic is currently implemented (as of 23/08/2022):
programme membership type = visitor - exception
doctor is connected AND programme membership end date is before now - exception
[GMC] exception reason is present - exception
Slack: https://hee-nhs-tis.slack.com/
Jira issues: https://hee-tis.atlassian.net/issues/?filter=14213