EPR & Clinical Systems Integration Policy

Some Clinics run their own Electronic Patient Record or practice management system (“EPR”) to hold clinical notes and manage their appointment diary. Where a Clinic chooses to connect its EPR to the Platform (an “Integration”) — for example, to sync live availability or push confirmed Bookings automatically into its diary — this policy sets out the data protection and security terms that apply.

This policy supplements the Clinic Partner Agreement and applies only to Clinics that enable an Integration; it does not apply to Clinics managing bookings solely through the EveryClinic dashboard.

Status as a data processing agreement. Where EveryClinic acts as a processor under section 3, this policy constitutes the separate written processing agreement contemplated by clause 10.3 and Schedule 2 of the Clinic Partner Agreement, and sets out the terms required by Article 28(3) of the UK GDPR.

By default, an Integration is scoped to scheduling data only, in two possible directions: (a) Availability, in — the EPR tells the Platform which slots are free/booked, so Patients see accurate live availability; and (b) Bookings, out — once a Patient confirms a Booking on the Platform, the appointment is pushed into the EPR’s diary, to avoid double-entry by Clinic staff.

The Integration does not extract clinical notes, diagnoses, test results, treatment history or any other clinical content from the EPR, and does not require read access to a Patient’s existing medical record. It is a scheduling integration, not a clinical records integration.

Any request from a Clinic for a broader integration is out of scope of this policy and would require a separate data protection impact assessment and data sharing agreement before development begins.

For the Platform’s own account and booking data, EveryClinic and the Clinic each remain independent controllers, as set out in the Clinic Partner Agreement and Privacy Policy.

For the specific, limited act of transmitting Booking data into the Clinic’s EPR at the Clinic’s request and configuration, EveryClinic acts as a processor on the Clinic’s behalf, strictly for that scheduling purpose. Insofar as this processor role applies, EveryClinic will: (a) act only on the Clinic’s documented instructions (i.e. the fields and direction the Clinic has configured); (b) ensure staff/systems handling this data are subject to confidentiality; (c) implement the security measures in section 4; (d) assist the Clinic in responding to data subject requests concerning data transmitted via the Integration; (e) not engage a new sub-processor for this function without giving the Clinic prior notice and a reasonable opportunity to object on legitimate grounds (section 5); (f) make available to the Clinic all information reasonably necessary to demonstrate compliance with this section and Article 28, and allow for and contribute to audits or inspections by the Clinic or its mandated auditor on reasonable notice and no more than once a year (or following an incident); and (g) at the end of the Integration, at the Clinic’s choice, delete or return the Booking data transmitted via the Integration, save where retention is required by law.

Once Booking data lands inside the Clinic’s own EPR, the Clinic is the sole controller of that system and its contents, including any clinical data subsequently added by Clinic staff.

The Clinic is responsible for ensuring its own contract with its EPR vendor permits this Integration and any associated data flows.

Where the Integration is built through a middleware/integration-platform vendor, that vendor is a sub-processor of EveryClinic for this function. EveryClinic will maintain a current list of such sub-processors and give the Clinic prior notice of any material change, with a reasonable opportunity to object on legitimate grounds before the change takes effect.

The EPR vendor itself is engaged and contracted by the Clinic, not by EveryClinic; EveryClinic is not responsible for the EPR vendor’s own security or compliance posture beyond the integration endpoint it connects to.

Where a Clinic’s own systems fall within scope of the NHS Data Security and Protection Toolkit (“DSPT”) or equivalent NHS Digital interoperability standards, the Integration should be built to align with those standards where reasonably practicable, even for private-only Clinics, as a mark of good practice.

EveryClinic will maintain (or work toward) recognised security benchmarks such as Cyber Essentials and, as the Integration scales, alignment with ISO 27001 principles for the systems handling the Integration.

EveryClinic will notify the affected Clinic of any security incident affecting data transmitted via the Integration without undue delay after becoming aware of it, and in any event within 72 hours — the 72 hours being a maximum, not a waiting period — providing available details to help the Clinic meet its own regulatory notification duties.

A Clinic must notify EveryClinic before changing its EPR system or vendor, so the Integration can be re-tested and re-authenticated before go-live, avoiding silent data loss or misdirected Bookings.

EveryClinic will give reasonable notice of any material change to the Integration’s data fields, security architecture, or sub-processors.

On termination of the Clinic Partner Agreement, or if a Clinic disables the Integration, EveryClinic will revoke Integration credentials and, at the Clinic’s choice under clause 3.2(g), delete or return any cached synchronisation data held outside normal Booking records within 30 days, save where retention is required by law.

This policy is owned by Lakhbir Dhillon (Data Protection Officer), who is responsible for maintaining the sub-processor list, the field-mapping documentation per Integration, and for commissioning a data protection impact assessment before any Integration scope broadens beyond scheduling data.

This policy is reviewed at least annually, and before onboarding any new class of EPR/middleware vendor.