Cloud connector

Cloud connector

Martyn Loughran
by Martyn Loughran, CTO
October 2021

Running within the internal network, the connector provides secure access to internal systems that are not otherwise available from the public internet – for example database servers, internal APIs, HL7 endpoints, or network filesystems – without opening external firewall ports.

Concentric connector

The connector works by opening an outgoing WebSocket connection to Concentric’s public cloud environment. This connection is secure, authenticated, long-lived, and bidirectional. The connector registers RPC handlers on connect, and will receive and respond to RPC requests over this connection. If the connection drops the connector will automatically reconnect after a short delay.

Implementation & source code

The Go programming language is used which provides: simple compilation to Windows & Linux targets, zero-dependency static binaries, minimal resource consumption, type safety, and readable, auditable code.

The connector source code is forked for each Concentric deployment to implement the specific RPC methods required. The source code can be shared.

Authentication to Concentric

The connector initiates a TLS (version 1.2) WebSocket connection to Concentric’s GCP server. The server’s SSL certificate is validated; thereby authenticating the Concentric server.

The connector immediately sends an auth token over this connection. The server computes the SHA256 hash of this token and validates it, thereby authenticating the connector. On authentication failure the connection is closed immediately by the server.

If the connection closes for any reason the connector will periodically attempt to reconnect and re-authenticate over the new connection.

Host requirements

The connector runs as a Windows service or Linux process.

Resource requirements are minimal: ~ 30MB RAM, minimal CPU load, and some disk space to store log output.


Concentric runs separate demo and production environments. The demo environment is designed for testing purposes and must not be given access to real patient data. Separate auth tokens are used for each environment.

A separate connector process should run for each environment, but they can co-exist on the same host VM if desired with different configuration.

Maintenance and monitoring

Concentric’s cloud environment monitors the status of each connector process and will alert the team in the case that there is no active connector available to handle requests.

Scaling and redundancy

Each connector process can handle multiple concurrent RPC calls which are multiplexed over a single connection. As a result it is not necessary or recommended to run multiple connector processes for the same Concentric environment on the same host to achieve concurrency. A single connector process will easily support the anticipated request volume for a large trust.

Redundancy can be achieved by running separate connector processes on different VMs. The server will load balance requests to available connector processes.

Bandwidth requirements

Bandwidth requirements for the connector are modest. Here is a back-of-the-envelope calculation:

  • Ignore periodic WebSocket ping-pong messages of less than 100MB per year.

  • Assume 10 demographic lookups per consent episode,

    1KB (typical response) × 10 per episode = 10KB per episode

  • 2 consent PDFs pushed to document integration,

    100KB (typical PDF) × 2 (encoding overhead) × 2 per episode = 400KB per episode

  • and a total of 100,000 consent episodes per year.

    410KB per episode × 100,000 episodes = 41GB per year

  • To calculate a conservative peak bandwidth requirement, we assume that all traffic occurs during weekdays during a 1 ‘peak’ hour time period: 250 weekdays × 1 peak hour × 60 min × 60 sec = 900,000s ≈ 10^6 peak-seconds per year

    41GB ÷ 10^6s = 41 KB/s

Back to integration resource