Understanding Data Controller Roles in UK Primary Care
In primary care data sharing, one of the most significant errors an organisation can make is incorrectly identifying the data controller. It is a common mistake to name a GP federation as the controller for data held within its member practices’ clinical systems. This often happens because the federation carries out the practical work of gathering and sharing the data.
However, under the UK General Data Protection Regulation (UK GDPR), legal responsibility does not follow the organisation that simply handles the data. It rests with the organisation that decides why and how personal data is processed. Misidentifying the data controller in primary care can shift legal duties to a party that never intended to accept them, creating confusion and risk.
This guide clarifies these roles, helps you understand the risks, and provides a practical framework for ensuring your data sharing agreements are accurate and compliant. It is designed to remove uncertainty and support lawful, safe data sharing that protects patients and organisations alike.
What is a Data Controller Under UK GDPR?
The UK GDPR defines a ‘controller’ as the organisation that determines the purposes and means of processing personal data. In simpler terms, the controller decides what the data will be used for and, broadly, how that will be done. They hold the primary responsibility for protecting individuals' information.
A ‘processor’, by contrast, is a separate organisation that processes data on behalf of the controller and follows their instructions. The distinction is fundamental because nearly all legal obligations under the UK GDPR, from transparency to handling data breaches, fall on the controller. The Information Commissioner’s Office (ICO) provides detailed guidance on the UK GDPR.
Controllership is a matter of fact, not a label you can choose. Naming an organisation as the ‘controller’ in an agreement does not make it so if, in reality, it is only acting on another’s instructions. This creates a dangerous gap between the documented arrangement and the legal facts, undermining the agreement's purpose.
The GP Practice: The Controller of the Patient Record
A GP practice holds a contract (GMS, PMS, or APMS) to provide primary medical services. As part of this, it creates and maintains the registered patient record. For this data, the individual GP practice is the data controller. It is registered with the ICO for this purpose and holds ultimate responsibility for that record.
This legal position does not change when a practice joins a federation or a Primary Care Network (PCN). The patient record remains under the control of the practice. Therefore, only the practice, acting through its established governance, can authorise the disclosure of its patient data.
This is the central point that a data sharing agreement must reflect. When data is extracted from a practice’s clinical system for a shared service or project, the disclosing controller is the practice. If the agreement fails to name the practice in this role, it is missing the very party whose lawful basis and confidentiality duties permit the sharing to happen.
A Federation’s Two Hats: Understanding Controller and Processor Roles
A GP federation is not always a processor, nor is it always a controller. Its role depends entirely on the specific data processing activity. It is crucial to distinguish between these two functions to ensure compliance and manage risk effectively.
When a Federation Acts as a Processor
When a federation extracts, hosts, or analyses data held in its member practices’ clinical systems, it does so on the instruction of those practices. In this scenario, the practices remain the data controllers, and the federation acts as their data processor. This relationship must be governed by a legally binding contract under Article 28 of the UK GDPR, which outlines the processor's responsibilities. Properly managing this relationship is key to effective UK GDPR processor risk management.
When a Federation Acts as a Controller
Conversely, a federation becomes a controller for data it creates in its own right. If a federation delivers a service under a contract held in its own name—such as an extended access hub or a commissioned neighbourhood service—it determines the purpose and means for processing the records generated by that service. For that specific dataset, the federation is the controller.
Keeping these two roles separate is essential. Membership in a federation does not automatically transfer controllership of practice records. The federation only becomes a controller for data it genuinely controls, protecting it from taking on duties that legally belong to its member practices.
Solving the Signing Dilemma for Data Sharing Agreements
If each practice is a controller, a practical challenge arises: how can a federation sign a multi-party data sharing agreement without requiring a signature from every single practice, every time? The process would be slow and inefficient. The solution is not for the federation to sign as the controller, but to act with formal authority.
A practice can provide its federation with a written, bounded authority to sign specific data sharing schedules on its behalf. This is similar to how the practice already trusts the federation to process its data. This authority must set clear limits, specifying:
- The categories of activity the federation may sign for.
- Any datasets or patient groups that are excluded.
- The notice period the practice must be given before signing.
With this mandate, the federation signs as the practice's ‘authorised representative’, while the practice remains the named controller. This approach keeps the legal position accurate and transparent. Using a structured data sharing framework is an excellent way to formalise this authority and streamline the process.
The Risks of Getting Controllership Wrong
Misstating the controller in an agreement is not a simple administrative error; it carries significant legal and operational risks. A federation that incorrectly signs as the controller for practice-held data inadvertently accepts legal responsibility for it.
These responsibilities include accountability, transparency duties, managing individual rights requests, and reporting data breaches. Furthermore, if the arrangement is wrongly treated as joint controllership, the federation could face shared liability for the entire processing activity, including the actions of other parties, as outlined in the ICO's guidance on controllers.
Most critically, the disclosure itself is authorised by an organisation that lacks the legal authority to do so. This undermines the lawfulness of the entire data sharing initiative. The federation takes on risk it cannot control while weakening the legal foundation of the arrangement.
A Practical Checklist for Reviewing Your Arrangements
To ensure your data sharing agreements accurately reflect reality, you can apply a simple, risk-based check. For each data flow your federation is involved in, ask the following questions:
- Origin: Whose patient record is this data being drawn from? (e.g., a specific GP practice).
- Purpose: Who decided why this data processing is necessary? (The controller).
- Role: Is our federation deciding the purpose itself, or are we handling the data on our practices' instructions? (Controller vs. Processor).
- Documentation: Does the signed agreement clearly and correctly name the parties in these roles?
If the answers to these questions do not align with what is written in your agreement, the document needs correcting to reflect the facts. This is a core part of applying a UK GDPR risk-based approach, focusing on what matters most: clarity and accountability.
Frequently Asked Questions
Can a federation and its practices be joint controllers?
Yes, but only if they genuinely determine the purposes and means of processing together. For example, if data from several practices is pooled into a shared system for a jointly agreed clinical purpose. Joint controllership, as defined in UK GDPR Article 26, requires a formal arrangement outlining each party's responsibilities. It should not be used as a default label for all multi-party sharing.
What should a 'written authority' for signing include?
It should be a formal document signed by the practice. It needs to clearly state that the federation is authorised to sign data sharing schedules on the practice's behalf, define the scope of this authority (e.g., for specific types of services), and outline any conditions or limitations. This ensures the federation acts within a defined mandate.
Does this guidance also apply to Primary Care Networks (PCNs)?
Yes, the principles are the same. Each member practice within a PCN remains the data controller for its own patient records. The PCN, or a lead practice acting on its behalf, may coordinate data sharing, but the underlying controllership of the individual records does not change unless a new legal entity is formed that holds the patient contract.
Correctly identifying the data controller in primary care is the foundation of lawful and trustworthy data sharing. By ensuring agreements reflect the factual reality—that GP practices control their patient records—federations can facilitate valuable collaboration without taking on inappropriate legal risk. A clear framework, based on written authority, allows for efficient processes while maintaining robust information governance that protects everyone involved.
If your organisation requires support in reviewing or establishing data sharing frameworks, Infinitic offers expert information governance consultancy to ensure your arrangements are clear, compliant, and effective.