Data Processing Agreement

This Data Processing Agreement ("DPA") is part of the Terms of Service between the Clinic (the "Controller") and Lessora sp. z o.o., ul. Stanisławowska 47, 54-611 Wrocław, Poland, KRS 0001273600, Sąd Rejonowy dla Wrocławia-Fabrycznej we Wrocławiu, VI Wydział Gospodarczy KRS (the "Processor"). It meets the requirements of Article 28 of the General Data Protection Regulation (EU) 2016/679 ("GDPR"). The owner accepts it on behalf of the Clinic when creating the account.

1. Subject and duration

1.1. The Processor provides Lessora Med, an online service for running the front office of clinics and medical practices, and processes personal data on behalf of the Controller to do so.

1.2. This DPA applies for as long as the Processor processes personal data for the Controller, including during deletion at the end of the service.

2. What is processed

Nature and purpose: storing, organising, displaying and sending data, so the Controller can manage its cabinets, services, practitioners and their shifts and absences, patients, the calendar of visits and their history, the waiting list, offers of freed times and plans for visits affected by an absence, confirm and cancel pages for patients, payments (including online payment links), packages of visits, invoices to patients and their sending to KSeF, practitioner settlements, consents, messages to patients (text messages and email), calendar feeds for practitioners, notifications to staff, reports and the patient access log; exchanging availability, bookings and patient details with an online booking platform the Controller connects; importing the Controller's data when it asks; supporting the Controller; keeping the service secure.

Categories of data subjects: the Controller's patients, their parents, legal guardians and other representatives, people who book a visit with the Controller through an online booking platform, buyers named on invoices, the Controller's owners, managers, reception staff and practitioners, and other people the Controller records.

Categories of personal data:

• patients: names, national identification number (PESEL), identity document type and number, date of birth, sex, phone numbers, email addresses, postal addresses, language, guardian or representative details, tags, administrative notes, where the patient came from, number of missed visits, invoice details (a person's or a company's), consents and their source, time and who recorded them;
• visits: date, time, practitioner, service, cabinet, price, status and history (moves, cancellations, late cancellations, missed visits and who made each change), where the booking came from, administrative notes, waiting list entries, offers of freed times and plans after an absence with the patient's answers;
• money: payments and refunds, payment status, packages of visits and their balances, payment confirmations, invoices and corrections with their lines, KSeF status and number;
• messages: text messages and emails sent, their recipient and delivery status (the text of a text message is not kept after delivery);
• staff: memberships, roles, contract type, title, the profile shown to patients, services offered, shifts, absences, settlement rules, settlement statements and the deductions in them;
• technical: sign-in and security data, the patient access log (who opened or exported which patient, when and from which IP address), audit log entries, booking platform messages as received (kept encrypted for 30 days), files sent for a data import, and any other data the Controller chooses to enter.

Special categories of data: the data above includes data concerning health (Art. 9(1) GDPR). Even without medical records, the fact that a person is a patient of the Controller, the services, specialities and practitioners they book, the dates of their visits and whether they came, their waiting list entries, packages and payments, and invoice lines naming a service can reveal information about their health. The Processor treats all patient data as data concerning health. The Controller is responsible for its legal basis under Art. 9(2) GDPR and the Polish law on healthcare. The service is not meant for medical documentation: administrative notes must not contain diagnoses, test results, treatment or other clinical information, and the Controller must not enter data about criminal offences (Art. 10 GDPR).

3. Instructions

3.1. The Processor processes personal data only on documented instructions from the Controller. These Terms, this DPA and the Controller's use and settings of the service are the Controller's instructions. Sending an invoice to KSeF when the Controller has turned this on, exchanging data with an online booking platform the Controller has connected, and sending a text message or email the Controller has set up, are processing on the Controller's instructions. Further instructions must be given in writing (email is enough).

3.2. The Processor tells the Controller if it thinks an instruction breaks data protection law.

3.3. If EU or member state law requires other processing, the Processor tells the Controller first, unless that law forbids it.

4. Confidentiality and professional secrecy

4.1. Everyone at the Processor who can access the personal data is bound to confidentiality in writing, also after their work for the Processor ends, and has access only as far as their work needs it.

4.2. The Processor knows that patient data may be covered by medical confidentiality and other professional secrecy of the Controller and its practitioners. It uses such data only to provide the service and never discloses it, except to sub-processors under section 6 or where the law requires it. Keeping medical confidentiality towards patients, observing patients' rights and keeping medical records remain the Controller's duties; Lessora Med is not a medical records system.

5. Security

5.1. The Processor takes the technical and organisational measures in the Annex to protect the personal data, taking into account the state of the art, costs and the high risk that data concerning health poses to data subjects (Art. 32 GDPR).

5.2. The Processor may update these measures, provided the level of protection doesn't go down.

6. Sub-processors

6.1. The Controller gives general authorisation for the Processor to use sub-processors. The current sub-processors are:

Company	What for	Where
Webdock	Servers, database and backups	European Union
Hetzner Online GmbH	Encrypted off-site copy of the backups	European Union
Cloudflare	DNS, encryption in transit and protection from attacks	Worldwide network
Stripe	Subscriptions and online payments	European Union and United States
ImprovMX	Sending email	European Union and United States
LINK Mobility Poland (SMSAPI)	Sending text messages to clinics' patients	European Union
Sentry	Error reports from the web app	European Union

6.2. The Processor tells the Controller (by email to the owner or in the app) at least 30 days before adding or replacing a sub-processor. The Controller may object on reasonable data protection grounds within that time. If the parties can't resolve the objection, the Controller may end the affected service before the change, with a pro-rata refund of prepaid fees.

6.3. The Processor imposes the same data protection obligations on each sub-processor by contract and remains responsible to the Controller for them.

6.4. The following are not sub-processors: the National e-Invoicing System (KSeF), run by the Polish tax administration, because invoices sent there go to a public authority under the Controller's own legal obligation; Stripe, for payments between the Controller and its patients, which it processes under the Controller's own agreement with Stripe; and any online booking platform the Controller connects, which acts under the Controller's own agreement with it.

6.5. The AI assistant is off. It is not used on the Controller's data until its provider has been added as a sub-processor under section 6.2.

7. Transfers outside the EEA

The Processor hosts the service in the European Union. A transfer to a third country happens only through sub-processors listed in section 6 and only with appropriate safeguards under Chapter V GDPR, such as an adequacy decision or the European Commission's Standard Contractual Clauses.

8. Helping the Controller

8.1. Data subject requests. The service lets the Controller access, correct, export and erase patients' personal data itself, including the history of who opened a patient's record. If the Processor receives a request directly, it passes it to the Controller without answering it, unless the Controller agrees otherwise.

8.2. The Processor helps the Controller, as far as reasonable, with security, breach notifications, data protection impact assessments and consultations with authorities (Art. 32 to 36 GDPR), and gives the Controller the information it needs for its own impact assessment of the processing of data concerning health.

9. Personal data breaches

The Processor tells the Controller without undue delay, and where possible within 48 hours, after becoming aware of a personal data breach affecting the Controller's data. The notice describes, as far as known, what happened, the data and people concerned, the likely consequences and the measures taken or proposed.

10. Deletion and return

10.1. During the service the Controller can export all its data at any time.

10.2. The service deletes some data on its own: uploaded import files after 30 days, data export files after 7 days, and booking platform messages after 30 days.

10.3. When the Controller deletes its Clinic, the data can be restored for 30 days and is then deleted. A Clinic closed for non-payment is deleted as described in section 7.2 of the Terms. Copies in encrypted backups are deleted when those backups expire, within 30 days. Data the Processor must keep by law (for example its own invoices to the Controller) is kept only for that purpose. The Controller keeps its own copies of records it must keep by law, such as its invoices and visit history.

10.4. The accounts of the Controller's staff are not Clinic Data and are not deleted with the Clinic; the Clinic's records keep the name of the person who made each entry.

11. Audits

The Processor makes available the information needed to show compliance with this DPA. The Controller may audit compliance, including inspections, by itself or an independent auditor bound to confidentiality, with at least 30 days' notice, during business hours, and not more than once a year unless a breach or an authority requires it. Each party bears its own costs.

12. Access by the Processor's staff

Support staff can sign in to the Controller's account only with a stated reason, for support or security. Each such access is recorded in the Clinic's audit log, and staff can't change passwords, two-factor settings or billing while signed in this way. Opening a patient's record during such access is recorded in the patient access log like any other.

When the Controller asks the Processor to import its data (a data migration), it attaches the files to a support request in the app. The files stay on the Processor's servers, are not sent by email, can be opened only by support staff, and each download is recorded in the Clinic's audit log. They are used only for that import and deleted once it is done: at the latest 30 days after they were sent, or 7 days after the request is closed. The Controller can delete them earlier in the app.

13. Liability and order of precedence

Liability under this DPA follows the Terms and Article 82 GDPR. If this DPA and the Terms conflict on data protection, this DPA applies.

Annex: technical and organisational measures

• Hosting: servers and database in the European Union.
• Encryption: HTTPS (TLS) for all traffic with HSTS; the PESEL number, identity document number, date of birth, patient and visit notes, invoice details and booking platform messages encrypted in the database with a separate key, and the PESEL number searchable only through a keyed hash; daily backups encrypted with a key kept off the server and kept for 30 days, with an encrypted copy in a second EU location; passwords stored only as strong hashes; the Clinic's KSeF token stored encrypted and never shown again.
• Separation: each Clinic's data is kept apart in the application; every query is limited to the current Clinic, and access to another Clinic's records is refused. A practitioner working for several Clinics sees each Clinic's data only inside that Clinic; the personal page across Clinics shows busy times without patient data.
• Patient links: visit, payment and offer pages sent to patients use long random links that open only that visit, payment or offer, and show no more than the time, place and practitioner; payment links expire. Text messages and emails don't name the service unless the Clinic turns this on, and practitioners' calendar feeds show patient initials only.
• Access control: roles and permissions inside each Clinic (owner, manager, reception, practitioner); two-factor authentication or a passkey required for the Clinic's owner and managers and available to all other users; sessions end after a period of inactivity set by the Clinic (30 minutes by default) and after 12 hours at the latest; the platform admin requires an authenticator app for every staff account.
• Traceability: a patient access log of every opening of a patient's record and every export of patient data, kept for 5 years and available to owners and managers; an audit log of changes to roles, settings, money, invoices and settlements, and of every support sign-in, kept for 730 days.
• Data minimisation in operations: no patient data in application logs, error reports or background job data; error reports are sent to Sentry in the EU with personal data removed; patient data is never used for analytics.
• Application security: security headers and a content security policy, protection against cross-site request forgery, rate limits on sign-in, forms and patient links, dependencies kept up to date.
• Availability: monitoring of failed background jobs and errors; tested restore from backups.
• Data subject rights: built-in export of a patient's data (with their access history) and of a whole Clinic, and erasure of a patient's identity and contact details.
• Staff: written confidentiality obligations; access only as needed for the task.