Care MCP

Health data in an AI fitness product: GDPR for builders

, Organisations

If your AI fitness or nutrition product asks users about injuries, conditions, medication, pregnancy or eating habits, you are processing health data under the GDPR. Health data is a special category under Article 9, which forbids processing it unless one of a short list of conditions applies. For a consumer wellness product the usual one is the user's explicit consent. On top of that come the everyday GDPR duties: know whether you are controller or processor, collect only what you need, sign a data processing agreement with every processor, and be able to erase a user's data when asked. This guide walks through each with a builder's eye. It is general information, not legal advice; your own counsel should confirm what applies to your product.

Why fitness data becomes health data

The GDPR defines data concerning health broadly: personal data about a person's physical or mental health that reveals something about their health status. A step count on its own may not be. A brief that says "knee surgery last year, on blood pressure medication, answered yes to chest pain" clearly is.

Any product that writes a responsible training or eating plan needs some of this. A trainer cannot plan around a problem they have not been told about. The standard tool here is a health declaration such as the PAR-Q+, whose seven questions are all about health. So the question for most builders is how to handle health data properly, since avoiding it entirely would make the plans worse and less safe.

Article 9 and explicit consent

Article 9 starts by prohibiting the processing of special category data, then lists exceptions. The first, Article 9(2)(a), is that the person has given explicit consent for one or more specified purposes.

Explicit consent is a higher bar than ordinary consent. In practice builders usually aim for:

Controller or processor

The controller decides why and how personal data is processed. The processor processes it on the controller's behalf and under its instructions. The distinction decides who carries which duties.

When your product orders plans from us through the API, you are the controller for your users' data and we are your processor. That means you choose the legal basis and obtain the consent. When you create a client through our API you pass healthConsent: true, which states that you have obtained the user's explicit consent to our health data notice and hold the record. A client cannot be created without it.

Article 28 requires a written contract between controller and processor. Ours is the standard data processing agreement, which is part of the organisation terms and takes effect with them. A signed copy is available on request. It covers instructions, confidentiality, security measures, sub-processors, assistance with user requests, breach notice within 48 hours, deletion and audits.

Data minimisation, in practice

Article 5 asks that personal data be adequate, relevant and limited to what is necessary. The cleanest way to meet it is to never receive what you do not need.

We designed the organisation API around that. For each of your users we take your own reference, a birth date, a country and a language. There is no name and no email. The birth date is there because the service is for adults only; the country, because some orders are closed in some countries; the language, so the document is written in it.

The professional who takes an order sees the brief with the user's age and language only, never your reference or anything that identifies the person. On your side you see each user's orders, their status and their price, and never the brief. Our own staff tools do not show briefs or documents either. The full picture is on our security page.

Sub-processors and transfers

A processor may use sub-processors only with the controller's authorisation. Ours is a general authorisation in the DPA, with the current list on our sub-processors page. We tell organisations by email at least 30 days before adding or replacing one, and you may object.

Everything is stored in the EU, with our host in Amsterdam. Briefs, drafts and documents are encrypted in the database with a key kept outside it. The DPA commits us to transfer personal data outside the European Economic Area only under the safeguards of GDPR chapter V, such as an adequacy decision or the Standard Contractual Clauses.

Erasure and withdrawal

When a user withdraws consent or asks to be forgotten, you need to act across every system that holds their data, including your processors.

With us, one call does it: deleting a client through the API erases their reference, birth date and every brief and document, and refuses any open order. The DPA sets 30 days as the outer limit. What stays is what bookkeeping law requires: order records without the reference, brief or document, and payment records, kept for seven years under Swedish law.

The same holds for our own consumer users. Delete the account and every brief and document is erased. Our privacy policy has the details.

A short checklist for builders

  1. Map where health data enters your product and where it goes.
  2. Write a clear health data notice and collect explicit, recorded consent to it.
  3. Decide your role for each flow, and sign a DPA with every processor.
  4. Send each processor only what the task needs.
  5. Keep a current list of sub-processors, and check where data is stored.
  6. Make erasure one action that reaches every processor.
  7. Consider a data protection impact assessment. Article 35 names large-scale processing of special category data as a case that requires one.

Your next step

If you want certified trainers and nutrition coaches in your product without holding more personal data than you do now, read the API reference and the organisations page, then the data processing agreement with your counsel.