Privacy

Forms that collect patient data need the clinic's information clause, not a consent checkbox. This page shows what to display under a form and what to send with it, so that your frontend handles personal data the way the clinic's own site does.

The legal basis in one paragraph

A booking and an enquiry rest on art. 6(1)(b) GDPR (steps before a contract, at the patient's request) and art. 9(2)(h) GDPR (health care). The form therefore shows the clinic's information clause (art. 13 GDPR) with a link to its privacy policy, and no required consent to processing. Marketing is separate: one optional box, unticked by default.

What to show

GET /privacy returns the clinic's policy and clause, generated from the clinic profile (the controller, its address and registry numbers, the contact for data requests, the data protection officer):

• clause.text, followed by a link clause.linkLabel to clause.href: under every form;
• marketingText: the label of one optional, unticked checkbox;
• sections: the policy itself, for your page at path (link it from your footer too). body is plain text: a blank line starts a paragraph and lines starting with "- " form a list;
• missing: profile fields the clinic has not filled in yet. The policy is served anyway; tell the clinic when the list is not empty.

What to send

Send the clause's version back as privacyNoticeVersion with POST /leads and POST /booking/appointments, and marketingConsent: true when the patient ticked the box. The lead or the visit stores the clause version and the time it was sent.

{
  "name": "Anna Kowalska",
  "phone": "+48 600 100 200",
  "privacyNoticeVersion": "2026-09-30.f0683640",
  "marketingConsent": true
}

• marketingConsent without a valid privacyNoticeVersion is not recorded as consent: there is no proof of what the patient saw. The lead gets a note instead, and an earlier opt-out stays.
• The version changes with every word of the policy and the clause, so fetch it when you render the form (the response may be cached for a minute) rather than hard-coding it.
• For a returning patient who books an appointment, the e-mail consent covers only the address stored with their lead (or the address they gave, when the lead had none).

Patient data in the API

The API carries only contact data: names, phone numbers, e-mail addresses and the text of enquiries and bookings. It is not a medical records system. GET /booking/appointments returns patients' names and phone numbers: call it from your server and never expose it in a browser. POST /feedback is for remarks about the site and removes e-mail addresses, phone numbers and PESEL-like numbers before storing, but never send patient data to it.