Clínica Digital Software SOFTWARE
Demo
← Back to the blog
Regulation and GDPR 8 September 2026 · 13 min read

GDPR in the patient record: what to keep and for how long

Find out which data may appear in the patient record, the lawful basis and how to set retention and access periods under GDPR and the LOPDGDD.

Key conclusions

  • The patient record may include special-category health data only if it is necessary for care and there is an appropriate legal basis, normally because of healthcare obligations.
  • The retention period for the clinical record is not set by the GDPR as a single figure: it depends on applicable healthcare regulations and on documented clinic criteria.
  • The patient’s right of access requires responding with copies and clear explanations, but does not mean handing over internal credentials, non-clinical notes or third‑party data.
  • The safest approach is to separate clinical data from administrative data, control role‑based permissions and log who accesses or modifies records.

The patient record is the clinic’s operational hub: what is entered at the front desk, what the clinician sees and what is used for billing. Under the GDPR, the aim is not to “keep less out of fear” but to keep what is necessary, for a justified time and with access controls.

What “patient record” means for the GDPR

In private practice, a “patient record” typically mixes three things that should be distinguished, because they have different legal fits and uses:

Administrative and contact details

These are the data that allow identification and coordination of care: name, DNI/NIE, telephone, email, address, emergency contact, payment method, insurer, etc. They are not health data, but they are personal data and must be handled properly.

Action to take (today): review your registration form and mark in two colours which fields are “administrative” and which are “clinical”; if they are mixed, separate them.

Clinical data (clinical record)

This includes the information the clinician needs to provide care: reason for the appointment, relevant history, examinations, progress notes, tests, reports, diagnoses, treatments, clinical informed consents, etc. Under the GDPR these are special-category health data.

According to the GDPR, health data are a special category and require a reinforced legal basis for processing.

Action to take: define in writing which documents form part of the clinical record at your centre (for example: anamnesis, session notes, issued reports, consents).

Internal management data (schedule, billing, incidents)

The schedule, reminders, payments, refunds, no-shows, front desk messages or an incident (“arrived late, reschedule”) are often in the same system. Not all of that is clinical record, but it can contain sensitive information if written carelessly.

Realistic front-desk example: instead of “comes for anxiety and medication”, in the schedule “review” or “follow-up appointment” is sufficient. Clinical detail should remain in the clinical section.

Action to take: review 20 random appointments in the schedule and check whether there are unnecessary clinical details in titles or notes visible to the whole team.

What data you may keep: the necessity test

The useful question is not “Can I keep X?” but “Is it necessary to provide care, meet obligations or manage the patient relationship?”. The GDPR requires minimisation: keep what is adequate, relevant and limited.

Fields that are commonly necessary

  • Identification: name and surname, identity document if you need it for billing/insurers.
  • Contact: telephone and/or email to confirm appointments and send documentation.
  • Billing data: tax details when you issue an invoice.
  • Relevant clinical information: what the clinician needs to treat and ensure continuity of care.

Action to take: add an internal note to each field on the registration form stating “why we ask this”. If you cannot justify it in one sentence, remove it or make it optional.

Fields that commonly cause problems

  • Open “observations” fields without control: they become a catch‑all.
  • Third‑party data (partner, relatives) entered as free text.
  • Photos or documents uploaded without label or purpose.
  • Copies of documents kept unnecessarily (for example, storing a scanned DNI in the system when not required).

Operational practice: if you need authorisation from a family member to accompany or act on behalf of a patient, create a specific document; do not store it as a “note” in the patient record.

How to write notes safely

Most internal privacy breaches do not come from hackers but from overly descriptive notes in fields visible to non‑clinical staff.

  • Front desk: record what is necessary to manage the appointment (“prefers afternoons”, “needs access”), not the clinical reason.
  • Clinician: keep clinical detail in the clinical section with restricted access.

Action to take: set an internal rule: “If the front desk can read it, it must not contain diagnosis or medication.”

In a clinic, the legal basis is not a phrase for a privacy poster; it is the reason you can collect, use and retain data. For health data, in addition to the general basis under Article 6 GDPR, you need an exception under Article 9 GDPR.

For healthcare processing, the usual basis is healthcare obligations and purposes, not asking for GDPR consent for everything. GDPR consent must be free and revocable; if you rely on it for care, you create a problem: what happens if it is withdrawn?

Healthcare regulation (regional and national) and the GDPR fit clinical processing into the specific conditions for health data. For the Spanish framework, the LOPDGDD (the LOPDGDD (Spanish Organic Law on Data Protection and Guarantee of Digital Rights)) complements the GDPR.

Action to take: review your “data protection consent” text in the registration form. If it mixes healthcare processing with commercial communications or reminders, separate it into distinct checkboxes and purposes.

  • Billing and accounting: typically rely on legal obligations and the contractual relationship.
  • Appointments and reminders: usually fit within the service relationship and can be based on legitimate interest after proper balancing, depending on the channel. If you send reminders via WhatsApp or SMS, document the channel and the patient’s preference.

Action to take: define a communications policy: what you send (confirmation, changes, receipts), via which channel and with what standard text that contains no clinical data.

Research, teaching, marketing: different purposes

If you want to reuse data for research, internal teaching, publications, testimonials or marketing, that is a different matter. You need legal bases, safeguards and often anonymisation or specific consent. Do not mix that with the operational patient record.

Action to take: create a separate “authorisations” field with date, purpose and how it was obtained; avoid free‑text notes like “ok for everything”.

Screen showing patient record and permissions

Retention period for the clinical record: how long and why

The GDPR does not provide a single retention period for clinical records; it requires that you retain them for as long as necessary for the purpose and justify it. In Spain, the retention period for the clinical record is supported by healthcare regulation and by clinical and legal criteria.

Don’t confuse “blocking” with “deletion”

In Spain, the LOPDGDD introduces the concept of blocking: when you no longer need to process data actively, you may keep it blocked to address legal liabilities or claims, limiting access.

Action to take: ask your advisor or DPO whether your procedure distinguishes “active” vs “blocked” and how it is implemented in your system (permissions, export, audit).

What to keep longer and what to purge sooner

  • Clinical documentation relevant to continuity of care: typically needs longer retention.
  • Duplicates and drafts: should not become an “eternal archive”.
  • Documents supplied by the patient: keep what is relevant; purge the rest with criteria.

Example of a monthly purge: duplicate PDFs (same report uploaded twice), unlabelled photos, documents uploaded for the wrong patient (the latter is also a security incident).

Action to take: create a monthly review of “unclassified attachments” and a rule: every attachment must have a type (report, consent, test, invoice) and a date.

Practical criteria to set your retention policy

Action to take: if you don’t have an internal retention table, create a first version in a sheet: five categories, one sentence of purpose and the person responsible for review.

Patient’s right of access: what to provide and how

The patient’s right of access means that, on request, you must confirm whether you process their data and grant access to it, with supplementary information. In healthcare settings, there is also the right to access clinical documentation under healthcare regulations.

What a correct response usually includes

  • A copy of the patient’s personal data in your system (administrative and the clinical data that apply).
  • Information on purposes, data categories, recipients, expected retention periods or criteria, and rights.
  • If your clinic has issued reports, provide them in an understandable format.

Action to take: prepare an internal response template for rights requests: who handles it, how identity is verified, how information is exported and who reviews it before sending.

Common limits: third parties and internal notes

  • If the record contains third‑party data (for example, a relative), those parts must be protected.
  • Internal non‑clinical notes or management comments may need review to avoid disclosing employee or other patients’ information.

Operational practice: avoid writing things in the record that you would not defend if the patient requested them tomorrow. If it is a staff incident (for example, “patient aggressive”), handle the risk with an internal procedure, but record facts and avoid judgments.

How to handle requests at the front desk without blocking the schedule

An access request usually arrives by email or at reception. The typical mistake is to improvise: “I’ll send it this afternoon” and then there is no traceability.

Simple flow:

  1. Front desk logs the request (date, channel).
  2. Identity verification (in person with ID or via a secure channel).
  3. Responsible person (management/DPO) validates scope.
  4. Export from the system and review for third‑party data.
  5. Delivery by agreed channel and record of delivery.

Action to take: establish a single mailbox (for example, privacy@yourdomain) and prohibit handling rights requests via WhatsApp.

Access, permissions and audit trails inside the clinic

The GDPR is not only about “what you keep” but about who sees it and who can change it. In a clinic, this is decided by roles and circuits.

Typical roles and what they should see

  • Front desk/administration: contact, schedule, billing, administrative consents; no clinical detail.
  • Healthcare professionals: full clinical record for their patients and, where appropriate, shared access within the care team.
  • Management: aggregated data and billing; clinical access only if justified and documented.
  • External providers: minimal access under a data processor agreement.

This links to the “need to know” principle.

Action to take: list your team and assign an access role per person (not per “department”). Review hires and leavers: when someone leaves, revoke access the same day.

Access logs and change history

In an audit or incident, the simple question is: “Can you show who accessed it?”. A system with traceability helps, but you also need procedures.

Action to take: review weekly (10 minutes) whether there are accesses from generic or shared accounts. If so, create a removal plan: every user needs their own account.

Data processors: accounting firms, labs, hosting, couriers

If a provider processes data on your behalf, there must be a processor contract and appropriate measures. This applies to email services, couriers, storage and IT support.

Action to take: ask every provider that touches personal data for a processor contract, data location, subprocessors and incident procedures.

How to implement this in your clinic

  1. Management: this week, call a 30‑minute meeting and define three information categories in your system: administrative, clinical and management; write one example of each.
    Check: any team member can classify 10 fields without hesitation.

  2. Front desk/administration: review the registration form and remove or make optional fields without an operational justification.
    Check: the registration can be completed without writing free text in “observations”.

  3. Medical director or clinical lead: define which documents form part of the clinical record and where they are recorded (not in the schedule).
    Check: in an internal audit of 5 records, clinical notes are in the clinical section, not in appointments.

  4. Data protection officer/advisor (or management if you have no DPO): draft a simple retention table by category and decide what is blocked and what is deleted.
    Check: there is a versioned internal document with a date and person responsible, even if it is a first draft.

  5. Head of IT or IT provider: configure role‑based permissions and forbid shared accounts; define the user offboarding circuit.
    Check: you can list active users and their roles; staff leavers are reflected in access revocations the same day.

  6. Whole team: prepare a template for responding to access requests and a single channel for requests.
    Check: the front desk knows where to log the request and what not to promise; the clinic can export the information without improvisation.

Frequently Asked Questions

That is not usual for healthcare. The legal basis is generally the provision of healthcare and applicable obligations, and consent is reserved for separate purposes. If you rely on consent for everything, withdrawal would leave you without a basis to continue processing data necessary for care.

What if a patient requests a copy of everything?

You must comply with the patient’s right of access and provide their data and relevant documentation, with review for third parties. You do not have to disclose information that affects other patients or internal data that does not apply. Define an identity verification and secure delivery procedure.

Can the front desk see clinical notes in the system?

Only if justified by specific, documented duties, and even then it is advisable to limit it. The safest practice is for the front desk to see administrative and schedule information, not clinical detail. Adjust permissions by role and avoid writing clinical information in fields visible there.

How do I set the retention period without getting it wrong?

Document criteria by document type and rely on applicable healthcare regulation and the LOPDGDD to decide on blocking. Don’t look for a single “one size fits all” number; define categories and review the policy periodically. If in doubt, validate the criteria with your advisor or DPO.

This article is informative and does not constitute legal or tax advice. Consult your advisor before making a decision.

Tags GDPR patient record clinical record the AEPD (Spain's data protection authority)

Keep reading