This article is not legal advice. It is a description of how we think about UK GDPR obligations in the context of fertility clinic data, and what that has meant for how we have built Amilis. Clinics with specific compliance questions should seek advice from a qualified data protection practitioner or solicitor.
That said, the core regulatory framework here is not arcane. Fertility patient data is health data. Health data is special category data under Article 9 of the UK GDPR. Special category data has a higher bar for lawful processing than ordinary personal data. The practical implications of that are worth understanding for any clinic that uses software to process patient records.
What Article 9 actually says about health data
UK GDPR Article 9 prohibits the processing of special category data unless one of a specific set of conditions is met. For healthcare providers and clinical data platforms, the relevant conditions are typically Article 9(2)(h), which permits processing for the purposes of preventive or occupational medicine, medical diagnosis, the provision of health or social care or treatment, or the management of health or social care systems. This applies to processing carried out by a health professional or a person subject to obligations of professional secrecy.
For a fertility clinic, this provision covers the core clinical data processing the clinic undertakes in the course of treating patients. For a software platform that processes that data on behalf of the clinic, the position is as a data processor, and the legal basis for processing is derived from the clinic's position as the data controller.
The practical implications of this structure are: the clinic is responsible for ensuring that its processing of patient data has a valid legal basis; the software platform it uses must process data only in accordance with the clinic's documented instructions; and the relationship between the clinic and any third-party platform must be formalised in a Data Processing Agreement (DPA) that meets the requirements of UK GDPR Article 28.
The Data Processing Agreement requirement
Article 28 of UK GDPR requires that where a controller uses a processor, that processing is governed by a contract or other legal act that sets out the subject matter, duration, nature, and purpose of the processing, the type of personal data involved, the categories of data subjects, and the obligations and rights of the controller.
Specifically, the DPA must require the processor to: process data only on documented instructions from the controller; ensure that persons authorised to process the data are subject to confidentiality obligations; implement appropriate technical and organisational security measures; assist the controller in meeting its obligations under the data subject rights provisions of UK GDPR; delete or return data at the end of the contract; and make available all information necessary to demonstrate compliance.
A fertility clinic that uses any software platform to process patient records without a DPA in place is operating in breach of Article 28, regardless of whether the platform is technically secure. This is worth stating plainly because we occasionally encounter clinics that have not sought a DPA from their existing software vendors, either because the vendor has not offered one or because the clinic has not asked. Asking is straightforward; most legitimate clinical software vendors will have a standard DPA available.
Data residency and the question of where data is held
UK GDPR restricts the transfer of personal data to countries outside the UK unless certain conditions are met. This means that a clinical data platform hosted outside the UK (including in EU member states, which now require separate safeguards following Brexit) must have an appropriate transfer mechanism in place, such as the UK's International Data Transfer Agreement (IDTA) or an adequacy decision.
For fertility clinic data, the sensitivity of the information and the ICO's guidance on data minimisation and purpose limitation makes UK data residency a straightforward default preference. Amilis stores patient data in UK-based infrastructure. We consider this a basic expectation for a clinical platform in this domain, not a premium feature.
When evaluating any clinical software platform, clinics should confirm: where is the data stored, who can access it, under what conditions can the vendor access patient records, and what happens to the data if the contract is terminated? These questions should be answered in the DPA and in the vendor's published data governance documentation. Vague answers to these questions are a significant due diligence flag.
Purpose limitation in practice
UK GDPR's purpose limitation principle (Article 5(1)(b)) requires that personal data collected for a specific purpose is not subsequently processed in a manner incompatible with that purpose. For fertility clinic patient data, the purpose is clinical care: managing the patient's treatment, maintaining their records, enabling appropriate clinical decisions.
A software platform that processes fertility patient data for purposes beyond this, including using it to train machine learning models, sharing it with third parties for research purposes without appropriate consent, or aggregating it for commercial analytics, would require a separate and explicit legal basis for each additional purpose. The patient's data was collected in a clinical context; it cannot be repurposed without meeting the additional legal requirements.
Amilis processes patient data solely for the function described to the clinic: structuring the data onto a patient timeline for clinical reading. We do not use patient data to train models. We do not share it with third parties. We do not run secondary analytics on it. These are not exceptional commitments; they are what purpose limitation requires in this context.
Patient data access rights
Patients have rights under UK GDPR that apply to clinical records held in software platforms: the right to access their data (Article 15), the right to correct inaccurate data (Article 16), the right to erasure in certain circumstances (Article 17), and the right to data portability (Article 20). The clinic, as data controller, is responsible for enabling these rights. The software platform must be capable of supporting them.
A DPA-compliant platform should be able to export a patient's data in a structured, machine-readable format on request, delete a patient's records when required under Article 17, and provide an audit log of who has accessed which records. These are functional requirements, not just compliance checkboxes, and they are worth verifying in any platform evaluation.
The compliance picture for fertility clinic data management is not unusually complex compared to other areas of healthcare, but it does require that the operational and contractual structures are in place before patient data is processed by any external system. Getting those structures right at the start is considerably easier than retrofitting them after a platform is embedded in clinical operations.