NOTE: This documentation currently pertains to the early implementations of the “new” connections application and is subject to change

It’s worth keeping the following information on data models in mind when reading this document:
Connections Data Models

The following DTO is used for the API call in all cases:

Add Connection

1. The GMC endpoint TryAddDoctor is called, passing the following information:

   1. GMC Number

   2. Change Reason

   3. DB code

2. On receiving response from GMC save a new Connection Request Log, and depending on the response:

   1. If an error occurred, create an exception

   2. otherwise send a message to recommendation service to update the designated body code - this is poorly named as “removeDesignatedBodyCode”

3. This does not currently update the Elasticsearch index so this will not be reflected in the front end!

Remove Connection

1. The GMC endpoint TryRemoveDoctor is called, passing the following information:

   1. GMC Number

   2. Change Reason

   3. DB code

2. On receiving response from GMC save a new Connection Request Log, and depending on the response:

   1. If an error occurred, create an exception

   2. otherwise send a message to recommendation service to update the designated body code - this is poorly named as “removeDesignatedBodyCode”

3. This does not currently update the Elasticsearch index so this will not be reflected in the front end!

Hide Connection

1. A new Hide Connection Log is created

2. This does not currently update the Elasticsearch index so this will not be reflected in the front end!

Unhide Connection

1. An existing Hide Connection Log is deleted

2. This does not currently update the Elasticsearch index so this will not be reflected in the front end!

GMC Client Implementation

Architecture note: connections maintains it’s own interactions with the GMC API rather than going via the GMC Client Service, we might want to reconsider this.