Integration

Martyn Loughran
by Martyn Loughran, CTO

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.

Contents:


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.

  • 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 IDAM / single sign on (optional)

    Allows clinicians to log in to Concentric using their existing accounts.

    Where this integration is not in place Concentric user accounts are used and can be managed via an admin interface.


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,

Concentric patient bar

or a notice that that patient could not be found.

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 with integration error

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.

A full specification for demographic API requirements is 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)

To consider:

  • Are existing browser sessions used on launch? (otherwise, unless a SSO integration is in place, the user may be prompted to log in each time)

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 send to other systems.

In additional 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.

Clinician IDAM / single sign on

Concentric supports the OpenID Connect (OIDC) authentication protocol. This is supported by, for example:


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.

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 integration approaches which we have previously taken:


FHIR API

Our preferred integration option is via an internet accessible FHIR API, which offers a modern and standards-based approach, and limits (or eliminates completely) custom development work.

  • Patient demographic lookup

    Supported via a GET query 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.

  • Clinician authentication

    Staff authentication via SMART on FHIR may also be supported depending on your FHIR implementation.


Cloud connector

When it is not possible to integrate via a public-cloud accessible API (FHIR or otherwise), a cloud connector can be deployed on-premise. This approach 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 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.

See Concentric cloud connector for more details.


Back to information governance and technical resource