For organisations undertaking an integration with PKB, it is important to start by identifying the stakeholders in your organisation required to support the integration. Whilst this can differ from organisation to organisation, the following should help with your planning and engaging the necessary people at an early stage of the process.

To aid with scoping requirements and planning conversations, answering the questions on the Integration starter form should be done at an early stage. Your PKB Success project manager will review the answer within 5 days and get back to you with follow up questions.

Org clinical engagement lead

Most people agree that sharing data with patients should be standard practice in the future, however, they need a concrete example of why they should do something today. The clinical engagement lead can support and be a voice for the clinicians in the organisation who has a specific need to share data with patients will help drive the integration process from a clinical and patient perspective.

A pathologist (pathology lead)

Needs to be engaged to support the sending of pathology data and ultimately agree to:

• Which pathology test results are sent to PKB

• What (if any) delays in showing patients the results of specific tests are desired

• Which (if any) test results need to be sent with a specific privacy setting (e.g. Sexual Health)

• That the pathology data being sent to be PKB is correct

It is common for a pathology lead to have a number of questions about how PKB supports the display of pathology data. This pathology FAQ section will help with answering many of the more common queries that are raised.

Information Governance

The information governance team will have questions about data security and privacy, as well as formal documentation that needs to be completed. It is important that all IG related matters are resolved before formally starting the integration development. Information relating to IG can be found here. The information technology department may have questions on data security and the required integration team effort.

Integration team

When the integration team (potentially a 3rd party partner) has questions about scoping and integration requirements, as well as about how to functionally integrate with PKB.

• The developer wiki will provide them with details on how to integrate with PKB at a technical level

• The Project Initiation Documentation (PID) completed in conjunction with the PKB Success project manager will clarify the scope and nature of the required integration.

• It is recommended that the customer integration team and the PKB integration team are engaged in this process. Once the PID has been "signed off" it will provide the context within which integration activity takes place, clearly setting out the required outcomes

• There should be an internal clarification of understanding on what data can potentially be sent to PKB via the APIs we provide and how (usually it happens via an integration engine aka TIE), where any data gaps or challenges exist and what if any blockers exist (e.g. capacity, knowledge, local system integration issues, data exclusions).

Comms Team

• The communications team will need to be aware of the project and related timescales to ensure messaging to patients, professionals and other stakeholders is managed effectively.

Guidance for integration planning

Planning an integration ordinarily starts with deciding on which patients to create records in PKB for and how they should then be supported to "register" and claim their PKB record.

• We recommend creating a PKB record for all patients that have engaged with a customer "recently"

• Recently is interpreted by customers in different ways, for example, they have been treated in the last 4 years

• Patient records are created with a spine checked NHS number, their name and date of birth (as a minimum)

• Data sent to a record can only be seen once a patient has registered

• In order for a patient to receive a registration notification (email) then their email address must be provided

• An email address can only ever be linked to a single PKB patient record

• An early activity for customers is to collect and validate patient email addresses

• When an email address can't be provided via integration, alternatives for patient registration do exist

The next stage

Is confirming what patient data to send. Typically one of the best clinical reasons and most impactful from a patient engagement perspective is to provide patients with their test results. Providing patients with their pathology data has been shown to save clinical time and improve patient satisfaction: appointments, phone calls and emails can be avoided when the patient can get their test results in their PKB record.

The next "quick win"

Sending appointments to PKB can generate cash savings by avoiding sending appointment letters. Closely followed by the sending of documents such as discharge letters and letters summarising what happened in clinic, as this generates clinical improvements and increases safety because the patient and all their providers see the latest information about the patient.

Time

We are often asked for guidance on how long an integration may take and what development capacity is needed. Whilst it is difficult to generalise as all customers have their own specific considerations, we hope the below provides some help:

• The integration work is about 1 full-time equivalent (FTE) month of work for each integration stream. This includes aspects such as opening network firewalls to connect to PKB's servers; sending data in HL7 format; testing on the PKB test server and then the PKB production server; clinical sign-off on the appearance of the test messages.

• Dedicating time to the integration is much more efficient than working part-time along with other tasks. Customers have found they can complete within one month if focusing full-time, but typically take much more than four months if they only dedicate 1/4 time. We were surprised to discover this but now know it is important to highlight. There are several reasons for such delays, integration specialists forgetting what they learned, too long a gap between calls, staff moving jobs and retraining requirement

• Integrating is well worth the investment. Once the integration is completed it works for the whole organisation. In other words, although your organisation may begin integration for a single team, it will also be used by every other team and department that rolls out after that.

• No further integration work is necessary so the investment is highly scalable.