Integration

Concentric can be used as a standalone system, or it can be integrated with other healthcare systems via one or more of the integration touchpoints described below. When fully integrated, clinicians can jump directly from an EHR to a patient’s record within Concentric, and consent information is visible in the EHR alongside the patient’s other information.

There are several technical approaches to integrating your systems that will be discussed during implementation, however an overview is described below.

Integration touchpoints

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 patient identifier) and access the patient’s latest details. 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.

• Open patient record in context (optional): Allows linking directly from an EHR to a patient record within Concentric, or embedding Concentric within an EHR window.

• Consent form document integration (optional): Allows consent form PDFs and associated metadata to be sent to your document store. Where this integration is not in place the consent form can be reviewed within Concentric, or manually imported into a document store/EHR.

• Clinician single sign-on (optional): Allows clinicians to log in to Concentric using their existing accounts. Where this integration is not in place clinicians sign-in using an email and password.

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. a hospital number and an NHS number) clinicians should ideally be able to search by either field, although this is configurable.

Searching for a patient calls the demographic lookup API. If successful the patient’s details are shown,

or a notice that that patient could not be 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.

As well as the demographic fields shown in the patient bar, contact details (email and mobile phone number) can optionally be provided. These are used to pre-fill fields when sharing episode information with a patient.

Within England it is possible to use Concentric with the NHS PDS API with zero integration work required. This allows lookup of patient records from the NHS Spine by NHS number (but not by local hospital number).

Detailed demographics integration documentation will be shared during phase 1 of delivery, and is also available on request.

Open patient record in context

Often it is helpful to link directly from your EHR to Concentric, avoiding the need for clinicians to search by identification number.

This is possible by linking to a URL with patient-specific parameters which we can discuss and configure with you. Clicking this link should launch a separate browser window and will:

1. Redirect the clinician to a Concentric log in page (unless they’re already logged in)
2. Fetch or update demographics via the demographic lookup
3. Open the patient page in Concentric (which includes a list of previous consent episodes)

Sometimes it is desirable to open Concentric within an EHR window. In these cases Concentric can be locked to a single patient to prevent the possibility of viewing different patients concurrently in the EHR and within the embedded Concentric view.

Consent form document integration

Concentric stores all information related to consent episodes in the cloud. At the point of consent, confirmation of consent, or revocation of consent, a consent form PDF (the legal consent document) is generated and stored. This is visible within Concentric to clinicians and patients.

Optionally this consent form PDF, along with associated metadata, can be sent to other systems.

In addition to patient demographic details, the consent PDF contains: 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.

Detailed document integration documentation will be shared during phase 1 of delivery, and is also available on request.

Clinician single sign-on (SSO)

Single sign on (SSO) is supported, which avoids the need for clinicians to use a separate password to login to Concentric, and allows organisations flexibility to authentication rules (for example MFA requirements) as appropriate.

The most common approach is to disable password-based authentication and configure one of the following SSO providers, which can be enabled within Concentric with no development effort:

• Microsoft Entra ID (formerly known as Azure Active Directory or Azure AD) can be a flexible option for organisations where Active Directory accounts are synchronised to the cloud and where this approach may be used to login to other cloud applications. Some minimal configuration is required within Azure but this is usually trivial.

• NHSmail can be a good option for organisations where clinicians already use NHSmail for their email. Historically this allowed less flexibility than Azure AD (in particular around MFA requirements and Windows login), but this is changing, and NHSmail is used by several organisations for access to Concentric.

The following authentication providers have been tested but are used less commonly:

• Windows AD FS (2016 and later) is an option but requires more extensive (and sometimes problematic) local configuration.
• Google workspace accounts.

Technically Concentric supports the OpenID Connect (OIDC) authentication protocol, and any spec-compliant OIDC provider can in principle be supported.

Technical approaches to integration

Concentric has been designed to be cloud-hosted rather than deployed on-premise, which may present integration challenges depending on the infrastructure currently in place.

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

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

• HTTP API (e.g. FHIR)
• Cloud connector (usually with HL7 or a direct database integration)

HTTP API (e.g. FHIR)

Our preferred integration option is via an appropriately secured internet accessible API.

FHIR offers a modern and standards-based approach, and is often the best option when it is included within an EHR product. This typically involves calls to 2 endpoints:

• Patient demographic lookup: supported via a GET against the Patient resource.

• Consent form document integration: supported via a POST to the DocumentReference resource with a binary (PDF) attachment. It is also possible to share structured data via the Consent resource.

FHIR can however be complex for teams to implement correctly; we therefore provide a simple JSON schema which may offer a simpler path, for example when using an integration engine which does not support FHIR natively.

Cloud connector

When it is not possible to integrate via a public-cloud accessible API (FHIR or otherwise), our cloud connector can be deployed on-prem. This approach offers security and flexibility, but requires hosting and maintaining an additional software component.

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.

The most common integration approach we see currently is a combination of our cloud connector and HL7 messaging to an integration engine. Please get in touch for a copy of our HL7 specification.

See also technical details regarding the connector.