The UK GDPR starting point
Under UK GDPR, the starting point is practical rather than contractual. The key question is not what the contract says, but who determines the purposes and means of the processing. In broad terms, “purposes” means why the personal data is processed; “means” refers to essential decisions about how that processing takes place, such as what data is collected, who it relates to and how long it is retained. A contract may label a supplier as a processor, but if that supplier is deciding why or how personal data is used, the contractual label will not be decisive.
Split roles in digital health platforms
In some cases, the position is clear. A healthcare provider may select a platform to simply host patient records, and the healthcare provider independently decide what data is collected and set the purposes for which that data is used. If the platform provider simply hosts, stores or transmits the data on the healthcare provider’s documented instructions, it is likely to be acting as a processor. The healthcare provider remains the controller.
The position becomes more nuanced where the platform does more than provide infrastructure. Many digital health products now include analytics, product improvement tools, patient engagement features, AI functionality or performance dashboards. These features may involve the platform provider making its own decisions about the use of personal data, particularly where the provider wishes to use customer data to improve its service or develop new functionality.
For example, a provider may be a processor when it hosts appointment records for a healthcare customer, but a controller when it analyses usage patterns across customers to improve its triage tool or decides what data should be used to train or validate a model. The same organisation can therefore have different roles for different processing activities. This is why blanket role allocations often fail to reflect how digital health platforms actually operate.
AI, analytics and secondary use
AI-enabled tools require particular care. Contracts and data maps should identify whether personal data is used only to deliver the customer’s service, or also for product improvement, model training, model evaluation, safety monitoring, benchmarking or research. Claims that data is anonymised or de-identified should also be tested carefully, because the role analysis may change if the provider still has access to identifiable data or can influence how data is transformed and reused.
When joint controllership may arise
Joint controllership may arise where a healthcare organisation and platform provider jointly design a care pathway, patient engagement programme, population health project or research initiative and both meaningfully influence the relevant purposes and means of processing. However, it should not be assumed simply because the parties collaborate that they are joint controllers. Mere technical integration, ordinary supplier cooperation, or a platform provider following a customer’s specifications will not, by itself, normally be enough.
What this means for contracts
Once the roles are understood, the contract should reflect that analysis. A practical agreement should avoid treating the platform as one thing for all purposes and instead describe the relevant processing activities role by role. In particular, parties should consider including:
a role-by-role processing schedule;
clear documented instructions for processor activities;
controller-to-controller sharing terms where each party acts independently;
a transparent allocation of responsibilities for any joint controller activities;
privacy notice and transparency obligations;
security, audit and sub-processor provisions;
rules on product improvement, analytics, benchmarking and AI training; and
specific treatment of special category health data, including lawful bases, Article 9 conditions and confidentiality obligations.
Key takeaway
For digital health businesses, the strongest position is rarely to insist that they are “only a processor” across the board. A more defensible approach is to recognise that different parts of the service may involve different roles, and to document those roles clearly. The aim is not to choose the most convenient label, but to build a role structure that matches the product, the data flows and the decisions each party actually makes. Done properly, that gives customers greater transparency, supports better contracting and reduces regulatory risk.
Join our upcoming event
As part of Glasgow Tech Week 2026, MFMac will host a panel discussion exploring the legal, regulatory and commercial issues arising from wearable devices and real-time health monitoring technologies.
Chaired by David Gourlay and featuring contributions from Jude McCorry (CEO, Cyber Fraud Centre Scotland), Melissa Hall and Michael Vaughan, the discussion will examine issues including data ownership, cyber security, liability and governance.
Find out more and register here.
This article has been co-authored by Nina Wright, Trainee Solicitor at MFMac.
