General Architecture

We do not explicitly store what one might consider the “state” of connections as GMC does, rather we hold audit logs for actions taken by admins regarding connections

There are currently two forms of data storage used by the connections application

1. MongoDB (DocumentDB)

   1. This is for the storage of request logs for connections, exceptions and hidden doctors

   2. This is the “source of truth” for TIS-held data about connections - all actions involving interaction with the GMC must ultimately base their data on these repositories

2. Elasticsearch

   1. This is used as a searchable, filterable “cache” for the front end

   2. Essentially a snapshot of “TIS state”, providing context to the data in the front end list views

   3. This data should be considered “volatile” - it is non-critical and should not be used as any kind of “source of truth”

MongoDB

Connection Request Logs

Exception Logs

Note: This does not go to GMC and exists purely in our system

Hidden Connection Logs

Note: This does not go to GMC and exists purely in our system

DoctorsForDB

The service tis-revalidation-connection currently breaks microservice architecture by accessing the doctorsfordb repository directly (currently should be held and maintained by tis-revalidation-recommendations)

It appears to only have one repository method which is currently unused

Elasticsearch

See existing documentation for implementation details:
Elasticsearch

The intention is to maintain an Elasticsearch index for each “tab” in the connections application, i.e:

• Current Connections (implemented)

• Historic Connections (implemented)

• Discrepancies (implemented)

• Hidden (not implemented)

These indexes consist of subsets of the following fields: Elastic Search Index Fields

The specifics of these subsets are currently under discussion