Go-live integration requirements
When planning a Concentric deployment, one factor determining the time to first clinical use is the time required for integration. This page summarises the integration options and provides a way to think about whether they are required before going live.
This page is written for the project implementation team. For technical details regarding integration go to our integration page.
The integrations that are generally discussed as part of implementation are:
Patient demographic integration allows clinicians to search for a patient in Concentric and instantly return basic patient demographic details without manual entry.
Without demographics integration, the first time a Concentric consent episode is created for that patient the patient record needs to be created. This is done via a new patient form:
The form includes the following fields, of which some are optional: title, given name, family name, preferred name, local identifier, national identifier, date of birth, gender, email address, and mobile phone number.
Whilst a number of our clinic users use Concentric without patient demographics, for any large organisation deployment we would advise that patient demographics integration is in place before go-live.
Benefits of patient demographics integration:
- Improved ease of use - needing to add patient demographics becomes the lengthiest part of the Concentric process (excluding consent conversation time) when patient demographics integration is not in place.
- Reduced errors and clinical risk - there is an expected error rate with manual form entry, especially when this is done in busy clinics and with data being completed regarding another individual. These errors can cause issues later in the consent pathway when consent is being checked, and errors with contact details can lead to the patient not receiving a copy of their information.
We are sometimes asked about going live without patient demographics and subsequently adding the integration. The challenge with this approach is that given the expected error rate described above, this creates a manual data correction exercise when switching to integration. The size of this data correction exercise increases the longer a non-integrated approach is taken to demographics.
Consent document integration is where consent PDFs are sent from Concentric so that they can be viewed in another location - usually either an Electronic Health Record (EHR) or electronic document management system (EDMS).
The information contained in these documents remains visible within Concentric, and therefore, these documents that are sent can be considered a duplicate.
The main reason for having consent document integration in place is:
- Where an EHR or EDMS is widely used for viewing documents, these become a natural place for a consent document to be stored and viewed by those who need to see the completed consent information but do not need to complete anything within Concentric. This is usually the case for those checking the consent information along the pathway from ward to operating room - ward nurses, ODP/Anaesthetist, theatre staff - and removes the need to train these individuals to use Concentric.
Some organisations are keen to have all completed documents within a single EHR or EDMS as a single canonical record of documents.
Where there is no established EHR or EDMS, organisations will often choose not to undertake a consent document integration but rather have the end-to-end process completed within Concentric, including bringing the consent information up in Concentric as part of the WHO checklist in theatre.
See example consent form PDFs here.
If document integration is added after go-live, it is possible to send through all consent documents created prior to the integration being in place.
Active directory / Single Sign-On
Active directory or single sign-on (SSO) integration allows clinicians to use their existing authentication credentials to log in to Concentric. Commonly this is done by using Azure active directory.
Concentric accounts require some details that are not held within active directories. For this reason, accounts are still created within Concentric by an administrator. Active directory integration, therefore, does not reduce the onboarding burden for administrators but improves the onboarding and ongoing experience for clinicians and reduces the ongoing support burden for authentication issues (password reset issues etc.).
There are no issues with transitioning from Concentric username/password authentication to active directory authentication post go-live.
EPR launch in context
An EPR launch in context integration is where a button within the EPR (or similar) opens Concentric in a browser on the appropriate patient’s record. This is simply a quicker way to get to the patient record in Concentric rather than going to the Concentric login page and entering the patient’s identification number. This integration is usually straightforward to put in place.
Where there is no mechanism to add patient-specific details into a hyperlink within the EPR, organisations usually place a shortcut button to the standard Concentric login page within the EPR or on the desktop/home screen.
There are no issues with introducing an EPR launch in context link post go-live.