Integration

Martyn Loughran
by Martyn Loughran, CTO
August 2021

Contents:


Types of integration

Concentric delivers the best user experience in the presence of the following integrations:

  • Patient demographic lookup (recommended)

    • Allows clinical staff to search for a patient (by your preferred record identifier) and access the patient’s latest details. See more details below.
    • Where this integration is not in place patient details need to be entered manually by a member of the healthcare organisation prior to a consent episode being created.
  • Store consent PDF (optional)

    • Allows consent form PDFs and associated metadata to be sent to your document store. See more details below.
    • Concentric always stores a copy of the consent PDF and provides access to patients and clinicians within the app.
    • Where this integration is not in place the consent form can be reviewed in Concentric, or manually imported into a document store/EHR.
  • Clinician user account integration and single sign on (optional)


Patient demographic lookup

When using Concentric, clinicians use the search bar to find a patient by identification number. In cases where patients have multiple identification numbers (e.g. an internal medical record number and an NHS number) clinicians should ideally be able to search by either field, although this is configurable.

Searching for a patient triggers the demographic lookup API, and if successful the patient’s details are shown:

Concentric patient bar

If a patient is not found an error is shown:

Concentric patient not found

To keep the interface fast and to avoid unnecessary load on the lookup API, patient details are cached within Concentric’s cloud environment, and refreshed if at least 10 minutes have elapsed since the last successful retrieval.

If an error occurs on refresh a message is shown to the clinician informing them that the demographic information may be outdated. This allows clinicians to continue using concentric with existing patients in the case of a temporary integration failure.

Concentric patient not found

Request data

Called with a single parameter:

Parameter Type Example Notes
IdentificationNumber String 123456 Patient national and/or local identifier, as entered by the clinician, downcased, and stripped of whitespace.
Response data fields

Lookup should return 0 or 1 patient records, with the following fields:

Field Type Example
Title String (nullable) Miss
First name String Mary
Middle name(s) String (nullable) Edith
Family name String Biscuit
Date of birth Date String 1924-03-21
Gender String Female
Local identifier (e.g. hospital number) String 123456
National identifier (e.g. NHS number) String (nullable) 1234567890
Email String (nullable) mary@example.com
Mobile String (nullable) 07700 900077 / +44 7700 900077
Test patient (optional) Boolean True
Response data notes
Field(s) Notes
Title Defaults to “Mx” if null
First / Middle / Family name Patient names should be returned in Title Case if stored as such, and will then be used unchanged in the interface. If names are stored in UPPERCASE they can be converted to Title Case by Concentric for display on a best-effort basis.
Gender Valid values: male, female, other, unknown. As defined by http://hl7.org/fhir/administrative-gender
Local / National identifier Either or both identifier can be set as being required.
Email and Mobile Used to prefill fields when sharing episode information with a patient. Fields can be edited before sharing, but edits are not pushed back to integration. If not available the patient will be asked for these details if they wish to receive a copy of the information discussed.
Test patient (optional) Recommended in cases where an EHR contains both real and test patient records.

Performance requirements: Users will directly experience the response time of demographic lookup queries so efficient querying is critical. A good target is < 100ms, while anything above 1s becomes increasingly unacceptable.

The consent PDF returned by Store consent form contains the patient details above, and additionally:

  • Name of proposed procedure
  • Side (if applicable)
  • Anaesthetic options discussed
  • Risks discussed
  • Name of the responsible clinician
  • Name and job title of clinician who took the patient’s consent
  • Name and job title of the clinician who confirmed consent
  • The patient’s signature
  • Time of consent and confirmation of consent

This mirrors the content of a completed consent form as per the Department of Health template.

Technical approaches to integration

Concentric has been designed to be cloud-hosted rather than deployed on a private network, and therefore this may present integration challenges depending on the infrastructure currently in place.

Internally our integration approach allows significant flexibility depending on your specific requirements, however a standards based approach is preferred since this is likely to result in significant time / cost savings on both sides, and simpler long-term maintenance.

The following outlines 2 ‘standard’ integration approaches which we have previously taken:


FHIR API approach

Our preferred integration option is via an internet accessible FHIR API, which offers a modern and standardised approach, and limits (or eliminates completely) custom development work. It also supports the option of adding staff authentication via SMART on FHIR.

  1. Patient demographic lookup – FHIR

    • Via an identifier search against the FHIR Patient resource, e.g.
      GET /[base]/Patient?identifier=123456
  2. Store consent form – FHIR

It is also possible to share structured data via the FHIR Consent resource.

Connector approach

When it is not possible to integrate via a public-cloud accessible API (FHIR or otherwise), we support running a (bespoke) connector process within the internal network. We have used this approach successfully multiple times and it offers flexibility at the expense of custom development effort and the need to host and maintain an additional software component within the network.

Running within the internal network, the Connector can provide secure access to internal systems that are not otherwise available from the public internet, for example database servers, internal APIs, or network filesystems.

Concentric connector

It 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.

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.

Environments

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

The Connector establishes a long lived connection over which very little data is transmitted when there is no activity (lightweight WebSocket ping-pong messages are used to monitor latency and detect potential issues).

The bandwidth requirement is primarily a function of the integrations in place and the volume of episodes. Bandwidth estimates are based on:

  • Patient demographic lookup: 1KB
  • Consent PDF: 200KB (a typical consent form PDF is 100KB, which is encoded as base64 for transmission, packed in JSON, and encrypted via TLS)

Episode volumes for calculation purposes:

  • Concentric episodes per year: 100,000
  • Demographic lookups per episode: 10
  • Consent PDFs generated per episode: 2

To calculate a conservative peak bandwidth requirements we assume that all traffic occurs during weekdays during a 1 hour period (i.e. during 250 days * 60 min * 60 sec = 900,000s ≈ 106 seconds per year).

Peak mean bandwidth during busiest hour:
(10 * 1KB) + (2 * 200KB) * 100,000 episodes ≈ 40 GB
40GB / 10^6s = 40 KB/s



Back to information governance and technical resource