Data Processing Agreement

Version DPA-1.3 · 9 October 2026

Published at https://www.optiswift.ro/abonament/contract-imputernicire. Annex I is also published as a separate document, at https://www.optiswift.ro/abonament/anexa-i, and Annex IV at https://www.optiswift.ro/abonament/subimputerniciti.

---

This agreement is the contract required by Article 28(3) of Regulation (EU) 2016/679 (GDPR) for the processing that the Provider carries out on behalf of the Practice. Clauses 1–10 reproduce the standard contractual clauses adopted by the European Commission by Implementing Decision (EU) 2021/915, with the options chosen in the text; the official text is published at https://eur-lex.europa.eu/eli/dec_impl/2021/915/oj. Under Clause 2(a), the parties do not modify these clauses; they only supplement and update the annexes. The clauses specific to this agreement are grouped in § 11 and § 12 and in the notes and tables that accompany certain clauses, as Clause 2(b) permits; they do not contradict the standard clauses, and in case of doubt Clauses 1–10 prevail (§ 11.0). The notes that accompany certain clauses show how the Provider performs them and form part of the agreement.

The parties

The Controller	the medical optics or optometry practice identified in Annex I, hereinafter the Controller or the Practice
The Processor	OPTISWIFT S.R.L., a limited liability company, with its registered office in București, Sectorul 3, Str. Nerva Traian nr. 27-33, Scara B, Etaj 1, Birou 6, registered in the Trade Register under no. J2026055914008 (EUID ROONRC.J2026055914008), CUI 55636472, subscribed and paid-up share capital of 500 lei, e-mail contact@optiswift.ro, also identified in Annex I, hereinafter the Processor or the Provider

The Practice is the controller, within the meaning of Article 4(7) GDPR, for the data of its patients and of the other data subjects listed in Annex II. The Provider is a processor within the meaning of Article 4(8) GDPR.

In this agreement:

• “the Program” is the OptiSwift application, which the Practice installs on its computers;
• “the Service” is the infrastructure and the server functions through which the Program operates, including the hosting of the Practice’s data, transactional e-mail and the in-app assistant; “the product” means the Program and the Service together;
• “the Subscription Terms” are the terms of the subscription contract between the Provider and the Practice, published at https://www.optiswift.ro/abonament/termeni, of which this agreement forms part.

This agreement is concluded before the Practice’s first item of personal data is entered into the Program, because Article 28(3) GDPR requires a written contract governing the processing from the outset. When it activates the subscription from within the product, the Practice accepts the agreement before it receives the account into which it enters its data (§ 11.7).

Clauses 1–10 and their terms. Clauses 1–10 below reproduce the standard contractual clauses in the Annex to Commission Implementing Decision (EU) 2021/915, as published in the Official Journal of the European Union, with the options chosen by the parties (Clause 1: Regulation (EU) 2016/679; Clause 7.7: Option 2, with 30 calendar days’ prior notice; Clause 5 included). In these clauses, “the controller” is the Practice (the Controller), “the processor” is the Provider (the Processor), and “sub-processor” means another processor engaged by the Processor (Article 28(2) and (4) GDPR). The notes and tables that follow a clause are additional clauses within the meaning of Clause 2(b) and do not modify the text of the clause.

---

SECTION I

Clause 1 — Purpose and scope

(a) The purpose of these standard contractual clauses (“the clauses”) is to ensure compliance with Article 28(3) and (4) of Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation).

(b) The controllers and processors listed in Annex I have agreed to these clauses in order to ensure compliance with Article 28(3) and (4) of Regulation (EU) 2016/679 and with Article 29(3) and (4) of Regulation (EU) 2018/1725.

(c) These clauses apply to the processing of personal data as specified in Annex II.

(d) Annexes I-IV form an integral part of the clauses.

(e) These clauses are without prejudice to the obligations to which the controller is subject under Regulation (EU) 2016/679 and/or Regulation (EU) 2018/1725.

(f) These clauses do not, by themselves, ensure compliance with the obligations relating to international transfers in accordance with Chapter V of Regulation (EU) 2016/679 and/or Regulation (EU) 2018/1725.

Clause 2 — Invariability of the clauses

(a) The parties undertake not to modify the clauses, except where they need to supplement or update the information specified in the annexes.

(b) This does not prevent the parties from including the standard contractual clauses laid down in these clauses in a broader contract, or from adding other clauses or additional safeguards, provided that these do not contradict the clauses, directly or indirectly, or prejudice the fundamental rights or freedoms of data subjects.

Clause 3 — Interpretation

(a) Where these clauses use terms defined in Regulation (EU) 2016/679 or in Regulation (EU) 2018/1725, those terms have the same meaning as in that Regulation.

(b) These clauses are to be read and interpreted in the light of the provisions of Regulation (EU) 2016/679 or of Regulation (EU) 2018/1725.

(c) These clauses must not be interpreted in a way that runs counter to the rights and obligations provided for in Regulation (EU) 2016/679, or in a way that prejudices the fundamental rights or freedoms of data subjects.

Clause 4 — Hierarchy

In the event of a contradiction between these clauses and the provisions of related agreements between the parties, whether existing at the time these clauses are agreed or concluded afterwards, these clauses prevail.

Clause 5 — Accession of new parties (optional)

(a) An entity that is not a party to these clauses may, with the agreement of all the parties, accede to these clauses at any time, as a controller or as a processor, by completing the annexes and signing Annex I.

(b) Once the annexes referred to in paragraph (a) have been completed and signed, the acceding entity is treated as a party to these clauses and has the rights and obligations of a controller or of a processor, in accordance with its designation in Annex I.

(c) The acceding entity has no rights or obligations arising under these clauses for the period before it became a party.

Practical note. Clause 5 is relevant to a practice that operates through several companies (for example, one company per location) and wants a single agreement. A practice with a single company may leave it unused.

---

SECTION II — OBLIGATIONS OF THE PARTIES

Clause 6 — Description of the processing (processing operations)

The processing operations, in particular the categories of personal data and the purposes for which personal data are processed on behalf of the controller, are specified in detail in Annex II.

Clause 7 — Obligations of the parties

7.1 · Instructions

(a) The processor processes personal data only on documented instructions from the controller, unless the processor is required to do so by Union law or by the Member State law to which it is subject. In that case, the processor informs the controller of that legal requirement before processing, unless the law prohibits such information on important grounds of public interest. The controller may also give subsequent instructions throughout the duration of the processing of personal data. These instructions must always be documented.

(b) The processor immediately informs the controller if, in the processor’s opinion, instructions given by the controller infringe Regulation (EU) 2016/679 or the applicable Union or Member State data protection provisions.

⚠ The wording is the Regulation’s, deliberately. In Opinion 22/2024 (adopted on 7 October 2024), the European Data Protection Board found that the broader formula “unless required to do so by law or binding order of a governmental body” — although it does not in itself infringe Article 28(3)(a) — cannot be interpreted as a documented instruction of the controller (paragraphs 126–132, with the conclusion at § 132), and that, for data transferred outside the EEA, it is unlikely that this formula would, by itself, be sufficient to comply with Article 28(3)(a) read together with Chapter V (summary, pp. 3–4). Since this service transfers data outside the EEA (Clause 7.8), the broad wording is not used anywhere in this agreement. Source: https://www.edpb.europa.eu/system/files/2024-10/edpb_opinion_202422_relianceonprocessors-sub-processors_en.pdf

The Controller’s documented instructions at the date this agreement is concluded are the following, and only these:

#	Instruction	Where it is carried out
I-1	Hosting, storing and making available, through the Program, the data entered by the Practice, including uploaded files (clinical images, documents, photographs, the e-Factura archive)	Supabase Pte. Ltd., project wcpnezrmfnfrclahqnfe, region eu-west-1 (AWS, Ireland)
I-2	Sending the Program’s transactional e-mails (the daily report and the messages by which its recipients are confirmed) to the addresses specified by the Practice	Plus Five Five, Inc. (Resend), United States
I-3	Sending SMS and WhatsApp messages to patients, through the Practice’s own account and credit with the messaging provider it has chosen	the provider chosen by the Practice (Infobip, Twilio or an HTTP endpoint specified by the Practice); see Annex IV § 2
I-4	Answering questions about the Program put to the in-app assistant, by sending to a language model the text of the typed question, at most three previous questions from the same conversation, the title of the manual article that corresponds to the open screen and excerpts from the product manual — only for practices that have not switched the assistant off (§ 11.3)	OpenAI Ireland Ltd., the Responses API, at api.openai.com (the global configuration) — processing outside the European Union
I-5	Receiving the fault reports that the Program generates automatically, after the filtering described in Annex III § A.7, retaining them and sending a summary to the Provider’s e-mail inbox	the project in I-1; the summary: via Resend, to the Provider’s inbox hosted by Proton AG (Switzerland)
I-6	Delivering updates to the Program	the update manifest hosted on GitHub; no Practice data travels over this channel: the Program downloads, it does not upload
I-7	Receiving the issue reports that the Practice’s staff send from Settings → “Issues and suggestions”, and the correspondence that the Practice sends to the Provider	the text of the issue report: via Resend, to the Provider’s support inbox, hosted by Proton AG (Switzerland); screenshots: the private feedback storage bucket in the project in I-1; correspondence: the contact@optiswift.ro inbox, hosted by Proton AG
I-8	Remote assistance by screen sharing, only in a session that the Practice starts and for which it gives the Provider’s staff the code displayed by TeamViewer; for the duration of the session, the Provider’s staff see the Practice’s screen, including any patient data displayed on it	TeamViewer (the contracting entity and the places of processing: Annex IV)
I-9	Checking a tax identification code in the public register of ANAF (the Romanian tax authority), at the user’s request (for example when issuing an invoice or filling in the company’s details)	ANAF’s public service (webservicesp.anaf.ro); only the code and the date are sent; the response is kept for no more than 10 minutes in the server function’s memory, and the Service does not record it beyond the data the user saves
I-10	Service administration operations performed on the Practice’s data by the Provider’s authorised persons — updating the database structure, diagnosing and correcting a fault, the full export, erasure and the assistance under Clause 8 — only at the Practice’s request or to the extent necessary for the operation and security of the Service	the project in I-1, through the Provider’s administrative access (Annex III § A.11) and the tools in § 11.1; delivery of the full export: the encrypted archive, through the Provider’s Proton Drive space, hosted by Proton AG (Switzerland), where the Practice has not agreed to a physical medium
I-11	Migrating the data from the program the Practice used previously, at its written request: receiving the copy of the database, keeping it on an encrypted volume of the Provider’s, transforming it and loading it into the project in I-1, and deleting the copy no later than 30 days after loading	the project in I-1; the Provider’s encrypted volume; the tools in § 11.1

How the Practice gives subsequent instructions. In writing, by e-mail to contact@optiswift.ro, or through the Program settings that implement an instruction: the assistant switch (I-4, § 11.3), the daily report with names (I-2, § 11.2), the purging of appointments (§ 11.6) and the connection to the messaging provider (I-3). Changing such a setting is a documented instruction.

⚠ Instruction I-4 expressly includes a transfer to a third country. The assistant uses OpenAI’s global configuration (api.openai.com), for which OpenAI does not guarantee processing in the European Union; requests to this address are not routed to Europe. OpenAI also offers a European configuration (eu.api.openai.com), with storage and processing in Europe, but only for an OpenAI project created with the Europe region, only once OpenAI has approved in advance a modified data retention arrangement (for example “zero data retention” or “modified abuse monitoring”), and only once the corresponding amendment has been concluded with OpenAI. The Provider has not applied for such approval; a move to the European configuration would be made only through a new version of this agreement. The assistant is switched on by default. The Practice gives instruction I-4 in full knowledge of these facts and may withdraw it at any time by switching the assistant off in Settings → Help (§ 11.3).

⚠ Instructions I-2, I-5 and I-7 may carry patient data, in the cases described in § 11.2.

⚠ Instruction I-8 shows the Practice’s screen to the Provider’s staff, with everything displayed on it, including patient data, for as long as the session is open. The Practice starts the session, by opening TeamViewer directly or from Settings → Help, and the session ends when the Practice closes the connection in the TeamViewer window. The Provider does not open sessions on its own initiative and does not use unattended access. Before starting a session, the Practice closes any records unrelated to the problem.

⚠ Any other processing is excluded. In particular, § 11.1 expressly prohibits any processing of the Practice’s data for the Provider’s own purposes.

7.2 · Purpose limitation

The processor processes the personal data only for the specific purpose(s) of the processing, as set out in Annex II, unless it receives further instructions from the controller.

7.3 · Duration of the processing of personal data

Processing by the processor takes place only for the duration specified in Annex II.

7.4 · Security of processing

(a) The processor implements at least the technical and organisational measures specified in Annex III to ensure the security of the personal data. These measures include protecting the data against a breach of security leading to the accidental or unlawful destruction, loss, alteration or unauthorised disclosure of, or access to, the personal data (personal data breach). In assessing the appropriate level of security, the parties take due account of the state of the art, the costs of implementation, the nature, scope, context and purposes of the processing, and the risks to which the data subjects are exposed.

(b) The processor grants members of its staff access to the personal data undergoing processing only to the extent strictly necessary for implementing, managing and monitoring the contract. The processor ensures that the persons authorised to process the personal data received have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality.

7.5 · Sensitive data

If the processing involves personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade union membership, genetic data or biometric data for the purpose of uniquely identifying a natural person, data concerning health or data concerning a natural person’s sex life or sexual orientation, or data relating to criminal convictions and offences (“sensitive data”), the processor applies specific restrictions and/or additional safeguards.

Application of Clause 7.5. The processing involves data concerning health within the meaning of Article 4(15) and Article 9(1) GDPR. The Processor applies the specific restrictions and additional safeguards described in Annex III § B: strict limitation of purpose to Annex II, isolation of each practice’s data through row-level security, access limited on the basis of named permissions, logging of changes, and restrictions on onward transfers.

7.6 · Documentation and compliance

(a) The parties must be able to demonstrate compliance with these clauses.

(b) The processor deals promptly and adequately with the controller’s requests for information about the processing of data in accordance with these clauses.

(c) The processor makes available to the controller all the information necessary to demonstrate compliance with the obligations that are set out in these clauses and stem directly from Regulation (EU) 2016/679 and/or Regulation (EU) 2018/1725. At the controller’s request, the processor must also allow for and contribute to audits of the processing activities covered by these clauses, at reasonable intervals or if there are indications of non-compliance with these clauses. In deciding on a review or an audit, the controller may take into account relevant certifications held by the processor.

(d) The controller may choose to conduct the audit itself or to mandate an independent auditor to do so. Audits may also include inspections at the premises or physical facilities of the processor and are carried out, where appropriate, with reasonable notice.

(e) On request, the parties make the information referred to in this clause, including the results of any audit, available to the competent supervisory authority/authorities.

What a practice can audit, in practice. The certifications on which the Provider relies are not its own but those of its sub-processors (Annex IV). What the Provider can show on its own side: the complete list of permissions and who holds them, the audit log of each record, the list of sub-processors and their contracts, and the code that performs the filtering in Annex III § A.7. What it cannot show: an independent audit report on its own organisation, because none exists.

7.7 · Use of sub-processors

(a) The processor has the controller’s general authorisation to engage sub-processors from an agreed list. The processor specifically informs the controller in writing of any intended changes to that list through the addition or replacement of sub-processors at least 30 calendar days in advance, thereby giving the controller sufficient time to object to such changes before the sub-processor(s) concerned are engaged. The processor provides the controller with the information the controller needs to exercise its right to object.

(b) Where the processor engages a sub-processor to carry out specific processing activities (on behalf of the controller), it must do so by way of a contract that imposes on the sub-processor, in substance, the same data protection obligations as those imposed on the processor under these clauses. The processor ensures that the sub-processor complies with the obligations to which the processor is subject under these clauses and under Regulation (EU) 2016/679 and/or Regulation (EU) 2018/1725.

(c) At the controller’s request, the processor provides the controller with a copy of such a sub-processor agreement and of any subsequent amendments to it. To the extent necessary to protect business secrets or other confidential information, including personal data, the processor may redact the text of the agreement before sharing the copy.

(d) The processor remains fully responsible to the controller for the performance of the sub-processor’s obligations in accordance with its contract with the processor. The processor notifies the controller of any failure by the sub-processor to fulfil its contractual obligations.

(e) The processor agrees a third-party beneficiary clause with the sub-processor whereby – in the event that the processor has factually disappeared, ceased to exist in law or become insolvent – the controller has the right to terminate the contract with the sub-processor and to instruct the sub-processor to erase or return the personal data.

The agreed list is Annex IV, in version SUBP-1.3, published at https://www.optiswift.ro/abonament/subimputerniciti, which forms an integral part of this agreement; the sub-processors on the list are also set out in the “Annex IV” section of this document. For each sub-processor, Annex IV refers to that sub-processor’s published list of its own sub-processors. The notification mechanism, the right to object and the consequences of an objection are described in Annex IV § 4.

⚠ The 30-day period applies to the sub-processors that the Provider engages itself (Annex IV § 1). Some sub-processors notify the Provider of changes to their own sub-processors with shorter notice (Resend, 14 days) or only with a right to object after the notice (OpenAI, 30 days from notification; Anthropic, 15 days from notification). In these cases, the Provider forwards the notice on the day it receives it and states the date of receipt, so that the Practice can see how much time it actually has left (Annex IV § 4.3).

Paragraph (e) and the sub-processors’ standard agreements. The Provider does not negotiate its contracts with its sub-processors individually: it accepts the standard processing agreements they publish (Annex IV § 1), which it cannot modify. If such an agreement does not contain a third-party beneficiary clause in favour of the Practice, the Provider cannot obtain one for that sub-processor. At the date of this version, the Provider has not obtained such a clause in favour of the Practice from any of the sub-processors in Annex IV. The standard contractual clauses in Decision (EU) 2021/914, which are incorporated into the agreements of the sub-processors that receive data outside the EEA, contain their own third-party beneficiary rights in favour of data subjects.

7.8 · International transfers

(a) Any transfer of data to a third country or an international organisation by the processor takes place on the basis of documented instructions from the controller or in order to fulfil a specific requirement under Union law or the Member State law to which the processor is subject, and is carried out in accordance with Chapter V of Regulation (EU) 2016/679 or of Regulation (EU) 2018/1725.

(b) The controller agrees that, where the processor engages a sub-processor in accordance with Clause 7.7 to carry out specific processing activities (on behalf of the controller) and those processing activities involve a transfer of personal data within the meaning of Chapter V of Regulation (EU) 2016/679, the processor and the sub-processor may ensure compliance with Chapter V of Regulation (EU) 2016/679 by using standard contractual clauses adopted by the Commission in accordance with Article 46(2) of Regulation (EU) 2016/679, provided that the conditions for the use of those standard contractual clauses are met.

The transfers made under this agreement, at the date of this version, are:

Recipient	Country	Instructions	Mechanism
Supabase Pte. Ltd. — the contracting entity for hosting	Singapore; the data are stored in eu-west-1 (Ireland)	I-1, I-5, I-7, I-10, I-11	Singapore does not benefit from an adequacy decision; the standard contractual clauses (Decision (EU) 2021/914, Modules 2 and 3), incorporated into the Supabase processing agreement
Supabase’s sub-processors outside the EEA, including Supabase, Inc. (support) and Amazon Web Services, Inc. (infrastructure)	the United States and the other countries on the list published by Supabase	I-1, I-5, I-7, I-10, I-11	the standard contractual clauses, through the Supabase processing agreement
OpenAI Ireland Ltd.	Ireland (the contracting entity); processing may take place outside the EEA, including in the United States, with no guaranteed region	I-4	OpenAI’s data processing agreement, incorporated into the OpenAI Services Agreement; for transfers outside the EEA to OpenAI’s affiliates or to third parties, the 2021 standard contractual clauses or an adequacy decision (Article 45 GDPR)
Plus Five Five, Inc. (Resend)	United States	I-2, I-5, I-7	the EU–US Data Privacy Framework (Implementing Decision (EU) 2023/1795; certified entity) and the standard contractual clauses (Decision (EU) 2021/914)
Proton AG	Switzerland	I-5, I-7, I-10	the European Commission’s adequacy decision for Switzerland (Decision 2000/518/EC)
TeamViewer	hosting: in the EEA, according to the TeamViewer processing agreement; TeamViewer’s own support may be provided by affiliated entities outside the EEA	I-8	the mechanisms provided for in the TeamViewer processing agreement
Anthropic Ireland, Limited	Ireland (the contracting entity); processing may take place outside the EEA, including in the United States	I-10, I-11	the standard contractual clauses (Decision (EU) 2021/914, Modules 2 and 3), incorporated into the Anthropic processing agreement

⚠ Where data are stored is not where the recipient is established. The Practice’s data are stored in Ireland, in a project in the eu-west-1 region. The entity with which the Provider contracts for hosting, however, is a Singapore company, and it and its sub-processors outside the EEA can access the data remotely. It is the second fact, not the first, that triggers Chapter V GDPR; that is why the Practice’s record of processing cannot state that “there is no transfer”.

If the adequacy decision on the EU–US framework ceases to apply, transfers to Resend continue on the basis of the standard contractual clauses.

Clause 8 — Assistance to the controller

(a) The processor immediately notifies the controller of any request it has received from a data subject. The processor responds to that request only if the controller has authorised it to do so.

(b) The processor must assist the controller in fulfilling its obligations to respond to data subjects’ requests to exercise their rights, taking into account the nature of the processing. In fulfilling its obligations under paragraphs (a) and (b), the processor complies with the controller’s instructions.

(c) In addition to the processor’s obligation to assist the controller under Clause 8(b), the processor also assists the controller in ensuring compliance with the following obligations, taking into account the nature of the data processing and the information available to the processor:

1. the obligation to carry out an assessment of the impact of the envisaged processing operations on the protection of personal data (a “data protection impact assessment”) where a type of processing is likely to result in a high risk to the rights and freedoms of natural persons;

2. the obligation to consult the competent supervisory authority/authorities prior to processing where a data protection impact assessment indicates that the processing would result in a high risk in the absence of measures taken by the controller to mitigate the risk;

3. the obligation to ensure that personal data are accurate and up to date, by informing the controller without delay if the processor becomes aware that the personal data it is processing are inaccurate or have become outdated;

4. the obligations in Article 32 of Regulation (EU) 2016/679.

(d) The parties set out in Annex III the appropriate technical and organisational measures by which the processor is required to assist the controller in the application of this clause, as well as the scope and extent of the assistance required.

How this assistance is provided in practice — and what exactly each tool does:

Right	Tool in the product	What it produces
Art. 15 — access	“Clinical record — printed”, from the ⋯ menu of the patient record	a readable copy of the record, on A4: the patient’s details, consents and consultations, with the list of documents and images; printing leaves a PRINT row in the audit log
Arts. 15 and 20 — access and portability	“Clinical record”, from the patient record	the patient’s clinical record in a JSON file — a structured, commonly used and machine-readable format; the export leaves an EXPORT row in the audit log
Art. 15 — what happened to the record	the record’s history	which fields were changed and when, from the audit log
Art. 16 — rectification	ordinary editing of the record	the change, with a trail in the audit log
Art. 17 — erasure	anonymising the patient	what it erases, what it keeps and why: § 11.4
Art. 18 — restriction	“Restriction of processing”, from the patient record (the permission to delete entries)	the record is kept in full and can be read, printed and exported; until the restriction is lifted, the server refuses appointments, consultations, documents, images, sales, messages and changes in the patient’s name, and any messages scheduled for the patient are cancelled
all patients (for example when the contract ends)	Patients → Excel exports → “Clinical records (all patients)”	each patient’s record, in a separate JSON file
Art. 13 — information	the “Data processing notice” template, in Documents	the information notice that the Practice hands to the patient; its content is decided by the Practice (§ 11.6)

⚠ Before responding to a request. A copy is complete only if it is produced by a person who has permission to view the patient’s identifiers and access to all locations; otherwise the CNP (personal numeric code), the content of issued documents or consultations at other locations are missing from it. Images and scanned documents appear in the record as a list; their files are downloaded separately, from the Program. The first copy is provided free of charge (Article 15(3) GDPR). If the implementing rules of Law No 46/2003 apply to the Practice (Order of the Minister of Health No 1410/2016, Article 9(3)), copies of medical documents are issued no later than 48 hours after the request is registered; the tools above produce the copy on the spot. The tool for Article 17 cannot guarantee complete erasure: read § 11.4 before responding to the patient.

The product’s exports remain available to the Practice even when its use of the Program is restricted for non-payment (the “export only” mode in the Subscription Terms), and also during the 30-day export window after the subscription ends (Clause 10(d)). In “export only” mode, the Program offers the exports it displays in that mode; uploaded files that it does not offer there (images, documents) are delivered by the Provider on request, through the full export.

Clause 9 — Notification of a personal data breach

In the event of a personal data breach, the processor cooperates with the controller and gives it the assistance it needs to comply with its obligations under Articles 33 and 34 of Regulation (EU) 2016/679 or under Articles 34 and 35 of Regulation (EU) 2018/1725, where applicable, taking into account the nature of the processing and the information available to the processor.

9.1 · Data breach concerning data processed by the controller

In the event of a personal data breach concerning data processed by the controller, the processor assists the controller:

(a) in notifying the personal data breach to the competent supervisory authority/authorities, without undue delay after the controller has become aware of it, where relevant / (unless the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons);

(b) in obtaining the following information which, pursuant to Article 33(3) of Regulation (EU) 2016/679, must be stated in the controller’s notification and must include at least:

1. the nature of the personal data, including, where possible, the categories and approximate number of data subjects concerned and the categories and approximate number of personal data records concerned;

2. the likely consequences of the personal data breach;

3. the measures taken or proposed to be taken by the controller to address the personal data breach, including, where appropriate, measures to mitigate its possible adverse effects.

Where, and insofar as, it is not possible to provide all this information at the same time, the initial notification must contain the information then available, and further information is to be provided subsequently, without undue delay, as it becomes available.

(c) in complying, pursuant to Article 34 of Regulation (EU) 2016/679, with the obligation to communicate the personal data breach to the data subject without undue delay, where the personal data breach is likely to result in a high risk to the rights and freedoms of natural persons.

9.2 · Data breach concerning data processed by the processor

In the event of a personal data breach concerning data processed by the processor, the processor, after becoming aware of the breach, notifies the controller without undue delay. That notification must contain at least:

(a) a description of the nature of the data breach (including, where possible, the categories of data subjects concerned, and the approximate number of data subjects and of data records concerned);

(b) the details of a contact point from which more information about the personal data breach can be obtained;

(c) the likely consequences of the data breach and the measures taken or proposed to be taken to address the data breach, including to mitigate its possible adverse effects.

Where, and insofar as, it is not possible to provide all this information at the same time, the initial notification must contain the information then available, and further information is to be provided subsequently, without undue delay, as it becomes available.

The parties set out in Annex III all the other elements that the processor must provide when assisting the controller in complying with its obligations under Articles 33 and 34 of Regulation (EU) 2016/679.

Additional deadline (Clause 2(b)). The Processor sends the notification provided for in Clause 9.2 without undue delay and, in any event, no later than 48 hours after becoming aware of the breach.

The 48-hour window: what it means and what it does not

The period runs from the moment the Provider becomes aware of the breach, including through a notification received from a sub-processor, not from the moment the breach occurred. This is the wording of Article 33(2) GDPR (“without undue delay after becoming aware”). Sub-processors notify the Provider within the periods set in their agreements; Supabase, which hosts the data, undertakes to do so no later than 48 hours after it becomes aware itself.

Why 48 hours. The Provider does not have a permanent on-call team. The 48-hour period leaves the Practice part of its own 72-hour period under Article 33(1) GDPR; the Provider notifies sooner whenever it can.

How notification is made. By e-mail, from contact@optiswift.ro, to the Practice’s addresses in Annex I; the contact point under paragraph (b) is the same address. As they become known, the notification includes the information under paragraphs (a)–(c) and the information the Practice needs for the notification form approved by Decision No 128/2018 of ANSPDCP (the Romanian data protection authority). The Provider does not notify ANSPDCP or inform patients on the Practice’s behalf except on the Practice’s written instruction. The Provider keeps a record of the breaches concerning the Practice’s data and of the measures taken.

What is not promised: the speed of detection. The detection mechanisms are listed in Annex III § D. None of them is continuous monitoring by a person, and the “has the monitor stopped?” check runs inside the very task it monitors (app.fault_channel_findings, the tick-stale verdict, called by app.fault_watch_tick). If that task stops running altogether, nothing outside the database notices. The Practice takes this limitation into account in its own risk assessment.

---

SECTION III — FINAL PROVISIONS

Clause 10 — Non-compliance with the clauses and termination

(a) Without prejudice to any provisions of Regulation (EU) 2016/679 and/or Regulation (EU) 2018/1725, in the event that the processor is in breach of its obligations under these clauses, the controller may instruct the processor to suspend the processing of personal data until the latter complies with these clauses or the contract is terminated. The processor promptly informs the controller if it is unable to comply with these clauses, for whatever reason.

(b) The controller is entitled to terminate the contract insofar as it concerns the processing of personal data in accordance with these clauses if:

1. the processing of personal data by the processor has been suspended by the controller pursuant to paragraph (a) and compliance with these clauses is not restored within a reasonable time and, in any event, within one month of the suspension;

2. the processor has substantially or repeatedly breached these clauses or its obligations under Regulation (EU) 2016/679 and/or Regulation (EU) 2018/1725;

3. the processor fails to comply with a binding decision of a competent court or of the competent supervisory authority/authorities concerning its obligations under these clauses or under Regulation (EU) 2016/679 and/or Regulation (EU) 2018/1725.

(c) The processor is entitled to terminate the contract insofar as it concerns the processing of personal data under these clauses where, after the processor has informed the controller that its instructions infringe applicable legal requirements in accordance with Clause 7.1(b), the controller insists on compliance with the instructions.

(d) Following termination of the contract, the processor, at the controller’s choice, either erases all personal data processed on behalf of the controller and provides the controller with proof that it has done so, or returns all the personal data to the controller and deletes existing copies, unless Union or Member State law requires storage of the personal data. Until the data are erased or returned, the controller must continue to ensure compliance with these clauses.

Clause 10(c) is listed in the Declaration of Express Acceptance at the end of the document (clause expressly accepted under Article 1203 of the Civil Code).

How paragraph (d) is carried out in practice:

The export window. After the subscription ends, for whatever reason, the Practice may sign in to the Program and export its data, using the tools in Clause 8, for 30 calendar days; the export window is the Data Recovery Period under Article 25 of the Subscription Terms. Within the same period, the Practice states its choice in writing — return or erasure — and may request the full export described below. Three days before the export window closes, the Provider reminds the Practice by e-mail of the date on which it closes.

The Practice’s choice	What the Provider does	Deadline
Return	delivers, free of charge, the full export of the Practice’s data: one file per table (JSON Lines), a description of the data structure, a manifest with the number of rows and the SHA-256 hash of each file, and all of the Practice’s files in storage buckets, in an encrypted archive whose password is sent through a different channel from the archive; after the return, erases the data, as in the next row	the export: no later than 10 working days after the request
Erasure	erases the Practice’s rows and files from the project, the user accounts of the Practice’s staff, and the Practice’s issue reports and fault reports in the Provider’s e-mail inbox, then sends a written certification, dated and signed, stating what was erased, what was kept and why	no later than 30 days after the export window expires; sooner at the Practice’s written request

In the absence of a choice (clause expressly accepted under Article 1203 of the Civil Code): if, by the time the export window expires, the Practice has not requested the return of its data, the Provider erases the Practice’s data, as in the “Erasure” row, and sends it the certification. Data not exported by then can no longer be recovered.

What the Provider keeps after erasure, and why. The erasure register — the Practice’s name, the number of rows erased from each table and the list of erased files — as proof of the erasure; at the Practice’s request, the Provider removes the Practice’s name from the register. Fault reports and operating signals received from the Practice’s computers, not linked to the Practice, until they are deleted automatically (§ 11.6). The data that the Provider processes as a controller — subscription billing and proof of acceptance of the contracts — are not covered by this agreement; they are described in the Provider’s privacy policy, published at https://www.optiswift.ro/confidentialitate.

The documents that the law requires the Practice to keep — tax documents and medical records — are kept by the Practice, from the export it received or made itself; after erasure, the Provider no longer holds them.

⚠ Backups. Erasure does not affect database backups that have already been created: they expire on their own within 7 days at most (Annex III § E), and until then the erased data may exist in such a backup. If the project has to be restored from a backup during this interval, the Provider repeats the erasure before the Service is made available to practices again. The certification states the date after which no backup contains the Practice’s data any longer. Files in storage buckets are not included in backups: once erased, they no longer exist on the hosting platform. Temporary copies of the export, created by the Provider for delivery, are kept on an encrypted volume, and the archive uploaded to Proton Drive for download (Annex IV § 1.4) is encrypted with a password sent to the Practice through a different channel; all of these are deleted after the Practice confirms that it has opened the archive, and the archive in Proton Drive no later than when the download link expires.

---

§ 11 · ADDITIONAL CLAUSES (Clause 2(b))

11.0 · Relationship with the Standard Clauses and the Subscription Terms

The provisions of § 11 and § 12, like the notes and tables accompanying Clauses 1–10, add obligations for the Processor and transparency for the Controller; § 11.8 also governs liability between the parties, the governing law and the competent court. None of these provisions restricts any right or obligation under Clauses 1–10. In case of doubt, Clauses 1–10 prevail, in accordance with Clause 4.

As regards the data the Practice entrusts to the Provider, this agreement prevails over the Subscription Terms. It applies for the whole term of the subscription and, after the subscription ends, until Clause 10(d) has been carried out. If this agreement terminates under Clause 10, the subscription terminates on the same date, because the Service cannot be provided without it; termination by the Practice under Clause 10(b) incurs no penalty for the Practice, and the Provider refunds the unused part of the price paid, calculated pro rata to the remaining days (Article 35(4) of the Subscription Terms).

11.1 · Prohibition on processing for the Processor’s own purposes (Article 28(10) GDPR)

The Processor does not process the Practice’s data for any purpose of its own. The following are expressly prohibited, without limitation:

• training, fine-tuning or evaluating any artificial intelligence or machine learning model, whether its own or a third party’s;
• product analytics, usage measurement or market research based on the content of the Practice’s data;
• comparison between practices (“benchmarking”), whether aggregated or not;
• building datasets, test samples or demo data;
• enriching or reselling the data, or making it available to a third party in any capacity other than that of a sub-processor listed in Annex IV.

The following are not processing of the Practice’s data for the Provider’s own purposes: the technical data of automatic fault reports and of feedback reports, and the assistant’s text-free metrics, which the Provider processes as controller for the operation and security of the Software, in accordance with its privacy policy. Any of the Practice’s data that ends up in them — a typed name, a patient record identifier in a screen’s address, a screenshot — is processed only on the Practice’s behalf, under instructions I-5 and I-7, and is not used for any purpose of the Provider’s.

⚠ Why this clause matters most. Article 28(10) GDPR provides that a processor which infringes the Regulation by determining the purposes and means of processing becomes a controller itself in respect of that processing. A provider that used patient data to train a model would, by that fact alone, become the controller of a processing of health data that it has no legal basis to carry out.

Development and maintenance tools. The Provider’s development and maintenance tools, including AI-assisted tools, receive the Practice’s data only: (a) through Anthropic services used under the commercial terms and the data processing agreement concluded by the Provider (Annex IV § 1.6), never through a consumer or personal account; (b) to carry out instructions I-10 and I-11, to the extent strictly necessary; (c) in sessions led by an authorised person of the Provider who is bound under § 12.4. Wherever possible, queries return only counts and technical identifiers. The Provider’s access to the Practice’s data in the database and in the storage buckets is reserved to the Provider’s authorised persons, through the hosting platform’s administration tools, and only for the instructions in Clause 7.1 (Annex III § A.11).

Checking the configuration. A prohibition that the configuration contradicts is worse than no prohibition at all. The Provider has therefore checked what the model provider’s public terms actually say, for the route this product uses:

OpenAI Services Agreement (updated 1 December 2025, effective 1 January 2026), § 4.2: OpenAI will only use Customer Content as necessary to provide Customer with the Services, comply with applicable law, enforce the OpenAI Policies, and prevent abuse. OpenAI will not use Customer Content to develop or improve the Services, unless Customer explicitly agrees to such use. https://openai.com/policies/services-agreement/

OpenAI’s documentation on data sent through the API says, more directly: As of March 1, 2023, data sent to the OpenAI API is not used to train or improve OpenAI models (unless you explicitly opt in to share data with us) (https://developers.openai.com/api/docs/guides/your-data). The explicit agreement referred to in § 4.2 and the opt-in referred to in the documentation are both prohibited to the Provider by the first bullet of this § 11.1. The prohibition in § 11.1 is not contradicted by OpenAI’s terms.

⚠ What the configuration does still allow, and must be said. The commitment concerns training. It does not mean that the text of questions is never retained:

What happens	Condition	Duration	Can it be turned off?
logging of requests, with their content, for abuse monitoring	⚠ all requests: logs are generated for any use of the API	up to 30 days, unless the law requires longer retention	yes, through “zero data retention” or “modified abuse monitoring”, both only with OpenAI’s prior approval — not requested
storage of the response by the Responses service (/v1/responses)	by default, unless the request carries store: false	at least 30 days	yes, per request — ⚠ every assistant request carries store: false, so this storage does not take place
prompt caching	by default, for any request: OpenAI temporarily keeps not the text itself but intermediate computation states (key–value tensors) derived from the request content, which may include the question, in order to reuse them for a request that begins identically; they are not shared between different OpenAI organisations, so they serve only the requests of the Provider’s OpenAI organisation	at least 30 minutes from the last write or reuse; OpenAI’s documentation states that entries are not kept indefinitely, without publishing a maximum duration	the documentation cited does not describe a way to turn it off; the assistant does not ask for longer retention than the default and does not send a cache key (prompt_cache_key)

The API documentation cited above (“data sent to the OpenAI API is not used to train or improve OpenAI models”) covers all data sent through the API, and therefore also the content of these logs. Sources: https://developers.openai.com/api/docs/guides/your-data · https://developers.openai.com/api/docs/guides/prompt-caching · https://openai.com/policies/services-agreement/

⚠ The Provider has not requested OpenAI’s approval for “zero data retention” or for “modified abuse monitoring”. This is a choice, declared so that the Practice can assess it; it explains why § 11.3 places the controls where it does. Such an approval, or approval of another modified data retention arrangement, together with the corresponding amendment, is the condition for OpenAI’s European configuration (Clause 7.1, the note to instruction I-4).

11.2 · The routes by which patient data can reach email

The product does not send clinical data by email. Data that can identify a patient may nevertheless reach an email processor by three routes, described here in full.

a) The daily report (instruction I-2). The report sent by email may contain patients’ names in one section only, and only if the Practice has explicitly enabled this:

• the section is called “Tomorrow’s appointments, with patient names” (maine_nominal);
• it depends on the include_personal_data setting, which is off by default;
• for each of the next day’s appointments, it contains the time, the patient’s name and the doctor’s name;
• no other section of the report contains patient identification data.

A practice that enables the section sends patient names, through Resend, to a processor in the United States (Clause 7.8), to the recipients it has chosen, and records this in its own record of processing activities.

b) Feedback reports from Settings → “Feedback and suggestions” (instruction I-7). The text that staff type is sent through Resend to the Provider’s support mailbox, hosted by Proton AG (Switzerland). The form expressly asks users not to write names, personal numeric codes (CNPs) or prescriptions and not to attach screenshots showing patient data, but no rule can stop a typed name. Screenshots do not travel by email: they are kept in the private feedback storage bucket of the project hosted in Ireland, which only the Provider can open, through the service role; the email names only their folder and the file names, derived from the names the attached files had. Screenshots are kept until the agreement ends and are deleted together with the Practice’s data (Clause 10(d)). Patient data in emails that the Practice itself sends to contact@optiswift.ro are deleted from the Provider’s mailbox once the request has been resolved.

c) Fault reports (instruction I-5). The summary the Service sends to the Provider through Resend, to the mailbox hosted by Proton AG, contains, for a sample report: the error message and stack trace, the screen on which it occurred (its internal address, which may contain the technical identifier of a record), the latest actions in the Software and the description the user typed, if they typed one. All of these first pass through the filter in Annex III § A.7, which cannot catch a name written in a description.

Outside these three routes and the messages the Practice itself sends to the Provider, the product does not send patient data by email. The Practice’s feedback reports and fault reports in the Provider’s mailbox are deleted in accordance with Clause 10(d); business correspondence with the Practice, which contains no patient data, is kept in accordance with the Provider’s privacy policy. A feedback report or an email to the Provider does not need the patient’s name: a description of the screen and the steps is enough.

11.3 · The in-app assistant: what it is and what it is not

The assistant is an artificial intelligence system that answers questions about the Software from the product manual: how to use it, what a term means as the Software uses it, and the Software as a whole — what it is, who it is for, what it does and what it does not do. A greeting or a thank-you that the Service recognises as such is answered by the Service itself, with a fixed sentence, without calling the model, and these are not sent along with later questions either. The assistant is instructed not to answer questions unrelated to the Software, not to give medical, optometric, legal, tax or accounting advice, and not to answer questions about the Practice’s own data. ⚠ Except for questions that match no article in the manual, it is the model that decides to refuse: a refused question has therefore been sent to the provider, under instruction I-4. Above the input box, the Software states that the question is sent to an external artificial intelligence provider and is processed outside the European Union.

What can be stated, architecturally, and can be verified in the code:

• the assistant has no tool declared to the model — the model is offered no function it could call;
• it does not read any table in the Practice’s database;
• it does not hold the project’s service key; it runs with a single client, using the token of the user who asked the question;
• the daily quota is consumed before the model is called;
• all of the above are verified by automated code checks, each tested against the defect it exists to catch.

What the model receives, for each question sent to it: a fixed system instruction (the assistant’s rules and the manual’s table of contents), the text of a few manual articles supplied by the server, the title of the manual article that corresponds to the open screen, the typed question, after the filtering described below, and at most three previous questions from the same conversation. None of this comes from the Practice’s database. Every request carries store: false, so OpenAI does not store the response (abuse monitoring logs are a separate matter, § 11.1), and carries no field that identifies the Practice or the person asking. ⚠ Because previous questions are sent along with the new one, a name typed once may be sent again with up to three subsequent questions in the same conversation.

⚠ What CANNOT be stated, and is stated nowhere in this agreement. It cannot be said that “the assistant cannot reach patient data”. The Practice’s staff can type patient data into the box — that is the whole reason the warning above the box exists. The real controls are:

1. the warning above the box, which asks the Practice’s staff not to write patient data and states that the question is sent to an external artificial intelligence provider and is processed outside the European Union;
2. the filter which, before sending, removes the CNP, IBAN, email address, phone number, tax code written with the “RO” prefix and credentials — and the server rejects a question that still contains any of these;
3. ⚠ the filter cannot catch a name. No regular expression recognises “Ion-Cristian Popescu”. Nor is a tax code written without the “RO” prefix recognised. The warning is the control; the filter is the safety net.

The switches. The Practice’s switch: the assistant is on by default for every practice. The Practice’s administrator, and only the administrator, turns it off or on from Settings → Help, in the “Assistant” block (“Assistant on for the whole practice”); the change is recorded in the audit log. While the assistant is off, nobody at the Practice can ask it questions, from any computer: the server rejects the question before counting it or sending it anywhere, and instruction I-4 is no longer carried out. A practice that does not want text typed by its staff to reach OpenAI turns the assistant off before staff start working in the Software. The Provider’s switch: a separate switch turns the assistant off for all practices at once; the Provider uses it in the event of an incident. Without the Provider’s server-side configuration (its OpenAI project key, the chosen configuration and authorisation for outbound traffic from the product’s project only), no request goes to OpenAI.

11.4 · What the erasure tool does and what it cannot do

The patient anonymisation function (public.anonymise_patient), which only a person with the permission to delete records can use:

• erases the identification data from the patient record — the name, CNP, identity document, contact details and legal representative — as well as from the patient’s appointments, the call log, messaging, the contact log and the lab job fields of orders;
• replaces with “(deleted)” the patient’s name, CNP, phone number, email address and representative, where written exactly and as whole words, in the title, body and file name of clinical documents, in the title and note of clinical images and in consultation observations; the clinical content remains;
• clears the note of collected or cancelled orders and removes the identity from the note of an order that is still open;
• clears the notes of recalls;
• withdraws contact consents; their rows remain, as dated evidence of what was granted and when;
• returns a manifest of what it erased, what it kept and until when.

Before anonymisation, if the patient has consultations, documents or images, the window asks whether the record is still within the Practice’s retention period. The Practice may choose to keep the whole record and restrict processing (Article 18 GDPR; Clause 8) instead of anonymising it.

⚠ What remains:

What remains	Why
invoices and other fiscal documents, with the date on which their retention period ends, shown in the manifest	Article 17(3)(b) GDPR; Article 25 of Law no. 82/1991
stored files (scans, PDFs, photographs), counted in the manifest	a file cannot be cleaned of names
clinical content, linked to an anonymised patient	the record of services provided
a name written differently from the patient record, a nickname, a CNP written with spaces	a database finds only exact strings
values written to the audit log before anonymisation	the log is append-only; these values are hidden when it is read
the rows of contact consents, withdrawn	dated evidence of the consents (Article 17(3)(e) GDPR)
complaints about the patient’s orders, with the reason and the request recorded when they were received	evidence in the event of claims (Article 17(3)(e) GDPR)

The Provider assists the Practice, on request, with what the tool cannot reach (Clause 8; Annex III § C).

⚠ Erasure and the retention obligation pull in opposite directions, and the decision is the Practice’s. If the Practice must keep the record (§ 12.5), Article 17(3)(b) GDPR exempts it from erasure. A record from which the identity has been removed can no longer serve the patient’s right of access to their medical data (Article 24 of Law no. 46/2003), nor serve as evidence. Before using the tool, the Practice determines whether the request concerns data it must keep; for such data, it may restrict processing instead of erasing them.

11.5 · What is not logged: on-screen reads

The audit log records the creation, modification and deletion of data (triggers on INSERT, UPDATE and DELETE) and, written explicitly by named procedures, EXPORT and PRINT rows: the “Clinical file” export (one row per patient and, when all patients are exported, a summary row), the “Clinical file — printed” printout (written after the print job has completed without error; the row shows that printing was ordered, not that the paper came out), list exports, the audit log export and the consent history export.

There is no log of on-screen reads. PostgreSQL cannot fire a trigger on a SELECT statement. The product can answer the question “who modified, exported or printed this patient’s file, and when?”. It cannot answer “who opened and read this record on screen?”. A practice that needs traceability of reads — for example following a request from ANSPDCP — must know from the outset that the product cannot provide it.

11.6 · Retention and erasure: what the product does and what it does not do

What the product calculates. For each invoiced party, the product calculates a retention period (app.invoice_retention_until) ending on 1 July of the year following the end of the financial year, plus five years — the period laid down in Article 25 of Accounting Law no. 82/1991, as amended by Law no. 36/2023. The period appears in the anonymisation manifest (§ 11.4); when it expires, the product deletes nothing.

What the product deletes automatically from the Practice’s data:

Mechanism	What it deletes	When
appointment purge	appointments marked arrived, completed, no-show or cancelled that are older than the threshold chosen by the Practice (default 365 days; at least 30, at most 3,650), except the appointments of a patient whose processing is restricted	optional, off by default; runs every night, only while the Practice’s account is active
fault report retention	the description typed by the user, after 30 days; the report, after 90 days	automatic
fault report retention	installations’ health signals (the installation identifier, version, platform), 180 days after receipt	automatic
clean-up of licence account address change requests	the old and new email addresses of the licence account, 30 days after the request is applied or cancelled or, for an unconfirmed request, after it expires	automatic

⚠ Nothing else is deleted automatically. Clinical and fiscal data, the audit log, the message log and the screenshots from feedback reports remain in the Service until the Practice deletes or anonymises them from the Software, where the Software allows this, or until Clause 10(d) is carried out. Deleting clinical and fiscal data after the statutory periods expire is an operation the Practice initiates, not an automatic one. The Provider carries it out, at the Practice’s written request, as assistance under Clause 8.

⚠ The privacy notice for patients. If the Practice’s privacy notice says that, after the statutory periods expire, the data “are deleted or anonymised” — as the “Data processing notice” template supplied with the Software says — no mechanism in the product fulfils that promise automatically. The Practice either carries out the deletion periodically or adapts the wording of the notice. This agreement does not repeat the promise.

The account the Practice receives when the subscription is activated starts empty; data from the trial account is not moved into it.

11.7 · Form of the agreement and proof of acceptance (Article 28(9) GDPR)

Article 28(9) GDPR requires this agreement to be in writing, including in electronic form. The parties agree to conclude it by electronic means, under Law no. 365/2002 on electronic commerce; the records described below serve as evidence of acceptance, under Regulation (EU) No 910/2014 and Law no. 214/2024.

Acceptance in the product. When the subscription is activated, set up for online payment or resumed from the Software or from www.optiswift.ro/cont, and when the Practice accepts a new version (§ 11.9; for a new version, only the amended documents), the Practice’s representative accepts, at the “Contract” step and on behalf of the company they represent, the Subscription Terms, this agreement and Annex I; the Provider’s privacy policy is presented to them at the same step. The clauses listed in the Statement of Express Acceptance at the end of the document are accepted separately, through a distinct checkbox, not ticked in advance, that reproduces their list. For each document accepted, the product records:

Item	What is recorded
Version	the identifier in the document’s header (for this agreement, DPA-1.3); a published version is never amended, but replaced by a new version with a different identifier; earlier versions are listed in the version history
Accepted text	the full text of the version, kept by the Provider together with its SHA-256 fingerprint
Time of acceptance	the date and time
Person accepting	the name and position declared by the representative on acceptance, and the identifier and email address of the account used to accept
Technical data of the acceptance	the IP address and the identifier of the browser or application (user agent) from which the acceptance came

The acceptance records cannot be modified or deleted from the product; the signatory’s data are deleted at the time set out in the privacy policy. Without delay after each acceptance, the Provider confirms the acceptance by email, to the licence account’s email address and to the billing email address declared by the Practice, and shows, for each document accepted, its title, its version, the address at which it is published and the SHA-256 fingerprint of the accepted text. At any time, on request, the Provider makes available to the Practice the version the Practice accepted. The Provider’s assent follows from the publication of the version and from this confirmation. By accepting, the representative declares that they are entitled to bind the Practice.

Acceptance in writing. A Practice that does not accept the documents in the product signs this agreement, Annex I and the Statement of Express Acceptance by hand or with a qualified electronic signature. A Practice that has accepted in the product may also sign them in this way; in that case, the signed copy prevails.

11.8 · Liability, governing law and competent court (clause expressly accepted under Article 1203 of the Civil Code)

The Provider’s total liability to the Practice, for all events arising out of or in connection with this agreement and the Subscription Terms, is limited to the sum of the prices actually paid by the Practice in the 12 months preceding the event giving rise to liability, but not less than the price of one annual Subscription Period for one location. The limitation does not apply to damage caused intentionally or through gross negligence, to harm to a person’s life, physical or mental integrity or health, or in other cases where the law does not permit limitation. It does not restrict the rights of data subjects under Article 82 GDPR.

This agreement is governed by Romanian law. Disputes between the parties are settled by the court with subject-matter jurisdiction for Sector 3 of the Municipality of Bucharest, where the Provider’s registered office is located. A change of the Provider’s registered office does not change the chosen court.

This § 11.8 is listed in the Statement of Express Acceptance at the end of the document.

11.9 · New versions of the agreement

The Provider may propose a new version of this agreement, with a new identifier, which it sends to the Practice by email. The new version applies to the Practice only after the Practice expressly accepts it, either in the product, with the checkboxes and evidence described in § 11.7 (“Acceptance in the product”), or in writing, by hand or with a qualified electronic signature (§ 11.7, “Acceptance in writing”); until then, the previously accepted version applies.

The following are not new versions of the agreement, but updates to the annexes permitted by Clause 2(a):

• changes to the list of sub-processors, which follow exclusively the mechanism in Clause 7.7(a) and Annex IV § 4;
• updates to a party’s contact details in Annex I, which that party communicates to the other by email.

11.10 · Communications between the parties

Notices, instructions, objections and requests under this agreement are made in writing. Email counts as written form for both parties: to the Provider, at contact@optiswift.ro; to the Practice, at the addresses in Annex I. The Provider also accepts post at its registered office. A communication by email takes effect when it is received in the recipient’s mailbox.

---

§ 12 · INTERPLAY WITH ROMANIAN LAW

§ 12 shows how this agreement applies together with Romanian law. The legal bases for processing and the retention periods remain the Practice’s decision, as controller; here the Provider describes what the Software does and what follows from the law, to the best of its knowledge.

12.1 · The CNP and the identity document series

Law no. 190/2018, Article 2(1)(b) defines the “national identification number” broadly: the personal numeric code, the series and number of the identity document, the passport number, the driving licence number and the health insurance number. The Software has fields for two of these: the CNP (patients.cnp) and the series and number of the identity document (patients.id_card_series, patients.id_card_number).

In the Software, both fields are optional. The patient record requires only the surname, the phone number and the date of birth, and the date of birth can be replaced by a note that it is not known. A typed CNP is validated before saving; an empty field blocks no operation. On an invoice to an individual, the identification code is optional; where it is missing, the Service fills in the code made up of thirteen zeros in the e-Factura file.

The rule the Provider recommends. The Provider recommends that the Practice collect the CNP and the series and number of the identity document only when a document it issues requires them by law; the legal basis is then Article 6(1)(c) GDPR — the legal obligation that the document implements. The Provider is not aware of any rule requiring them for the clinical record, for appointments or for orders.

The consequence of the legal basis. Article 4(1) of Law no. 190/2018 permits the processing of the national identification number in the situations provided for in Article 6(1) GDPR. Article 4(2) attaches four safeguards — appropriate technical and organisational measures; the designation of a data protection officer; storage periods and periods for erasure or review; periodic training of the persons who process the data under the direct authority of the controller or of the processor — but attaches them only to processing based on Article 6(1)(f) GDPR, that is, on legitimate interest. A Practice that collects these data under a legal obligation does not fall under Article 4(2). ⚠ A Practice that processed them on the basis of legitimate interest — including in connection with marketing communications — applies all four safeguards.

What the Software does with these data. The CNP and the identity document in the patient record can be read only with the view_patient_identifiers permission (Annex III § A.2), and the “Clinical file” export omits them, together with the content of issued documents, for anyone who does not have it. A CNP or identity document entered on an issued document or on an invoice is visible with that document, to anyone who has access to it. Anonymisation erases the CNP and the identity document from the patient record and replaces the CNP where it is written exactly in clinical documents; invoices still within their retention period keep it (§ 11.4).

12.2 · The data protection officer

The Practice. Article 37(1)(c) GDPR requires a data protection officer to be designated where the core activities consist of processing on a large scale of data concerning health. Recital 91 GDPR states, in express terms:

“The processing of personal data should not be considered to be on a large scale if the processing concerns personal data from patients or clients by an individual physician, other health care professional or lawyer.”

The Article 29 Working Party’s guidelines WP243 rev.01, endorsed by the European Data Protection Board, give the data of the patients of an individual physician as an example of processing that is not on a large scale, and the data of a hospital’s patients as an example of processing on a large scale. A practice with several locations and a large volume of patients carries out its own analysis and documents it. The Provider cannot decide this on the Practice’s behalf.

The Provider. The Provider has not designated a data protection officer. For any matter concerning personal data, the Provider’s contact is contact@optiswift.ro. If the Provider designates a data protection officer, it will send the Practice the officer’s contact details by email and update Annex I.

12.3 · Record of processing activities — the exemption in Article 30(5) does NOT apply

Article 30(5) GDPR exempts an enterprise with fewer than 250 employees from the obligation to maintain a record of processing activities, but only if none of the following conditions is met: the processing is likely to result in a risk to the rights of data subjects; the processing is not occasional; the processing includes special categories of data within the meaning of Article 9(1).

⚠ An optical practice meets all three: it processes data concerning health, routinely, not occasionally. Therefore:

• the Practice, as controller, maintains the record required by Article 30(1), regardless of how many employees it has;
• the Provider, as processor, maintains the record required by Article 30(2) for the processing carried out on the Practice’s behalf and makes it available to ANSPDCP (Romania’s data protection authority) on request.

Annex II and Annex IV contain the information the Practice needs for the entries in its record that concern the Provider. They do not replace the record.

12.4 · Professional secrecy (Article 9(3) GDPR) applied to a processor

Article 9(3) GDPR provides that data concerning health may be processed for the purposes referred to in Article 9(2)(h) when they are processed by or under the responsibility of a professional subject to the obligation of professional secrecy under Union or Member State law or rules established by national competent bodies, or by another person also subject to an obligation of secrecy under the same rules.

⚠ It is the second limb that applies to the Provider. The Provider is not a healthcare professional and is not subject to the professional rules that govern them. It falls within Article 9(3) through the second limb — “another person also subject to an obligation of secrecy” — and that obligation must actually exist, not be presumed.

The Provider therefore expressly undertakes, beyond Clause 7.4(b), that:

1. every person who, under the Provider’s authority, can access the Practice’s data signs a written confidentiality undertaking that survives the end of their employment or engagement;
2. the undertaking expressly names data concerning health and the fact that they arise from the relationship between the Practice and its patients;
3. the Provider keeps a record of these undertakings and makes it available to the Practice on request, in accordance with Clause 7.6(c);
4. the Provider ensures periodic training of these persons on their obligations — a safeguard that Article 4(2)(d) of Law no. 190/2018 provides for, in express terms, for persons processing data under the direct authority of the processor as well, and which the Provider assumes here regardless of the legal basis of the processing.

12.5 · Retention period for clinical records

What follows from the law, to the Provider’s knowledge:

1. National Archives Law no. 16/1996, Article 8: documents are grouped according to the retention periods set in the records retention schedule that each creator draws up for its own documents and has approved by the county service of the National Archives. The retention period for the patient record is therefore the one in the Practice’s own records retention schedule.
2. Article 27¹ of the same law, introduced by Law no. 201/2024, requires electronic documents to be managed so as to ensure their integrity, authenticity and usability, with controlled, identifiable and dated access and changes.
3. The rules approved by Order of the Minister of Health no. 1992/2023 require an optics and optometry practice to keep a record of the services provided, without setting a retention period.
4. The patient has access to their medical data (Article 24 of Law no. 46/2003).

What does not follow. The Provider has not identified any legislation in force that sets a retention period for the records of a private optics and optometry practice. The 30-year figure, widely cited for the general clinical observation sheet, concerns other healthcare units and could not be traced to a rule applicable to such a practice.

What the product does. The product neither imposes nor applies any retention period to clinical data; the only period it calculates concerns billing documents (§ 11.6). The period is set by the Practice and its archivist. Until then, the Provider recommends keeping the record in full and not using the erasure tool on a record that is still within its retention period (§ 11.4).

---

ANNEX I — LIST OF PARTIES

On acceptance in the product, Annex I is the separate document published at https://www.optiswift.ro/abonament/anexa-i, in the version accepted together with this agreement: the Controller’s details are those declared on activation or on acceptance of the documents and recorded with the acceptance, and the Processor’s details are those below (§ 11.7). The tables below are completed and signed when the agreement is concluded on paper or with a qualified electronic signature.

Controller

Name	………………………………………………………………
Registered office	………………………………………………………………
CUI (Romanian company tax ID) and Trade Register number	………………………………………………………………
Contact person’s name, position and contact details	………………………………………………………………
Email addresses for communications under the agreement	………………………………………………………………
Data protection officer, if designated	………………………………………………………………
Activities relevant to the data processed	the Practice’s optical and optometry activity, for which it uses the OptiSwift Software and Service
Role	controller
Signature and date of signing or of acceptance in the product	………………………………………………………………

Processor

Name	OPTISWIFT S.R.L.
Legal form	limited liability company
Registered office	București, Sectorul 3, Str. Nerva Traian nr. 27-33, Scara B, Etaj 1, Birou 6, România
Trade Register number	J2026055914008
European unique identifier (EUID)	ROONRC.J2026055914008
Unique registration code (CUI)	55636472
Share capital	500 lei, subscribed and fully paid up
Contact person’s name, position and contact details	Eduard ZAMFIR, director · email: contact@optiswift.ro · post: at the registered office
Data protection officer	the Provider has not designated a data protection officer; for any matter concerning personal data: contact@optiswift.ro (§ 12.2)
Activities relevant to the data processed	provision of the OptiSwift Software and Service, described in Annex II
Role	processor
Signature and date	for OPTISWIFT S.R.L.: Eduard ZAMFIR, director · signature: ……………………… · date: ………………………

Each party updates its contact details in this annex by a communication sent to the other by email (§ 11.9, § 11.10).

---

ANNEX II — DESCRIPTION OF THE PROCESSING

Categories of data subjects whose personal data is processed

1. The Practice’s patients, including minors — a clinical record may be opened in a child’s name.
2. Legal representatives of minor patients — a parent, guardian or relative, with their name, phone number and relationship to the patient.
3. The Practice’s own staff — user accounts, permissions, the locations they have access to, the names that appear on issued documents and in the audit log, the contact person for the licence account and, where the Practice uses the daily report, its recipients.
4. Doctors and associates entered in the list of doctors, including those who are not employees.
5. The Practice’s corporate clients and their representatives, insofar as they are natural persons.
6. Third parties named in free-text fields — a specialist doctor to whom the patient is referred, a relative, an employer mentioned in a recommendation for screen work. ⚠ This category cannot be listed in advance, because it depends on what the user writes; it is real, and that is why it is declared.

Categories of personal data processed

Group	What it contains
Identification	surname, first name, date of birth, sex; the CNP and the series and number of the identity document — optional fields (§ 12.1)
Contact	phone number, email address, address, county, town
Legal representative	the name, phone number and relationship of a minor patient’s representative (mother, father, guardian, relative)
Socio-professional	workplace and occupation — optional fields, used for recommendations on screen work
Refraction and prescription	refraction values for each eye (sphere, cylinder, axis, addition, prism), interpupillary distance, contact lens parameters, prescriptions issued
Eye examination	diagnoses, the doctor’s observations, the recommendations and instructions in the consultation record
Clinical images and documents	photographs and captures from examination equipment, with their notes; clinical documents issued or uploaded
Patient photograph	if taken, for trying on frames
Appointments	appointment history, the appointments’ status and notes, scheduled recalls
Orders and invoicing	orders, items, prices, payments, fiscal documents, the details of the invoiced party
Consents and restrictions	the consents recorded, by channel and by purpose; restrictions of processing and their lifting
Messaging	the recipient, the delivery status, a preview of the message sent, suppressions
The Practice’s staff	name, role, permissions, the locations they have access to; the email address of the Practice’s licence account
Traceability	who created, modified, exported or printed, when, and which fields changed
Feedback reports	the text and screenshots sent by staff from Settings → “Feedback and suggestions”; they may contain patient data by mistake
Questions asked of the assistant	the text typed by staff in the assistant box and at most three previous questions from the same conversation, sent to the language model under instruction I-4; they may contain patient data by mistake (§ 11.3)
Fault reports	the installation and session identifiers, the Software version and platform, the error message and stack trace, the open screen, the latest actions in the Software and the description optionally typed by the user, after the filtering in Annex III § A.7
The screen, during remote support	everything the Practice’s computer displays during a session started by the Practice (I-8)

Sensitive data processed and safeguards applied

The processing includes data concerning health within the meaning of Article 4(15) GDPR: the results of eye examinations, refraction values and prescriptions, diagnoses and clinical observations, clinical images and documents. The specific safeguards applied are those in Annex III § B.

⚠ The CNP and the identity document series are not special categories within the meaning of Article 9 GDPR, but they are subject to the special regime of Article 4 of Law no. 190/2018. See § 12.1.

Nature of the processing

Collection, recording, organisation, structuring, storage, adaptation, retrieval, consultation, use, disclosure to the recipients indicated by the Controller, making available, alignment, restriction, erasure and destruction — through the Software and the Service, on the infrastructure described in Annex IV — as well as viewing the Practice’s screen, in remote support sessions started by the Practice (I-8).

Purposes for which the personal data is processed on behalf of the Controller

Provision of the Software and the Service for managing an optical practice — and only that: keeping the patient record, appointments, orders and their delivery, issuing fiscal documents, communicating with patients through the channels chosen by the Practice, the Practice’s management reports, the in-app assistant’s answers, technical support (including remote support, in sessions started by the Practice), fault diagnosis, and the security and continued operation of the Service.

⚠ No processing for the Provider’s purposes. See § 11.1.

Duration of the processing

The processing begins when the Practice receives the account into which it enters its data and lasts as long as the subscription, plus the 30-day export window and the time needed to carry out Clause 10(d) (return or deletion). Database backups that may contain the Practice’s data expire within 7 days of deletion (Annex III § E). Fault reports, which are not linked to the Practice, are deleted in accordance with § 11.6.

Retention periods for data within the Service are those set by the Controller, except for the automatic deletions described in § 11.6. The product calculates a single period, for billing data, and deletes nothing when it expires (§ 11.6).

For processing by sub-processors: subject matter, nature and duration of the processing

Specified individually, for each sub-processor, in Annex IV.

---

ANNEX III — TECHNICAL AND ORGANISATIONAL MEASURES

Explanatory note to Decision (EU) 2021/915: the technical and organisational measures need to be described concretely and not in a generic manner. This annex follows that requirement: each measure says what the mechanism does, not which category of good practice it represents. The measures that are missing are declared in § F.

§ A · Measures applied by the Provider

A.1 · Isolation of each practice’s data. Every table in the database’s public schema has row-level security enabled, without exception. Every policy on a table holding practices’ data ties the row to the practice that owns it; a session authenticated for one practice cannot read another practice’s rows. The tables the Provider uses for subscription billing have no policy for users: only the Provider’s service role reads them.

A.2 · Rights based on named permissions, not broad roles. Access to each category of data depends on a named permission, checked inside the security policy or the procedure that serves the data — for example view_clinical for reading clinical data, edit_clinical for creating it, delete_records for deletion, anonymisation and restriction of processing. Permissions and access to locations are granted to each person, and the Practice’s administrator can withdraw them. The CNP and the series and number of the identity document cannot be read directly from the patients table; they can be obtained only through procedures that require the view_patient_identifiers permission.

A.3 · What the Software can contact. The Software’s content security policy allows data connections only to the product’s Supabase project, and only over https: and wss:. Beyond these, the Software: downloads the update manifest from GitHub and verifies it cryptographically with a public key included in the Software (I-6); opens in the computer’s browser only TeamViewer pages, pages on optiswift.ro and, from the payment window, Stripe pages with terms, payment receipts and payment documents (on stripe.com, pay.stripe.com and invoice.stripe.com); starts TeamViewer, if it is installed on a Windows computer, at the user’s request (I-8); for subscription payment, can open a separate window, which loads Stripe’s payment pages and the pages they send the user to for payment confirmation, for example the bank’s page, and which cannot call the Software’s functions. Outside a remote support session, none of these routes transmits the data the Practice has entered in the Software. All other calls to third parties — to the language model, email, the Practice’s messaging provider, Stripe and the register of ANAF (Romania’s tax authority) — are made from the server, through an egress gate: calls that send questions, emails, messages or payment operations work only if the deployment names the project from which they are allowed to send, and the ANAF lookup can reach only ANAF’s public register.

A.4 · Storage buckets are private and separated per practice by their path. The five storage buckets — clinical-images, documents, efactura, patient-photos and feedback — are all private; none of them serves public content. Files are read through the user’s authenticated session, and the buckets’ access rules require the first segment of the file path to be the identifier of the session’s practice and, for each bucket, the corresponding named permission; a user of one practice cannot read a file in another practice’s folder. In documents, patients’ scans and documents can be read only with view_clinical, while the compliance documents for stock items sit under a prefix of their own and are read with view_stock. The efactura bucket can be read and written with the corresponding permission, but cannot be modified or deleted from the Software. The feedback bucket, which holds the screenshots from feedback reports, has no access rule for users: only the Provider opens it, through the service role.

A.5 · Encryption in transit and at rest. The hosting platform states publicly that “all customer data is encrypted at rest with AES-256 and in transit via TLS” (https://supabase.com/security). The Software cannot open an unencrypted connection to the project: the content security policy allows it only https: and wss: (§ A.3). The credentials of the Practice’s messaging providers are kept in the database’s encrypted vault, and the Software has no way to read them back in plain text.

A.5b · The certifications the chain relies on — the host’s, not the Provider’s. Clause 7.6(c) allows the Controller to take relevant certifications into account. Those that exist belong to the hosting platform, which publicly declares SOC 2 Type 2, ISO 27001 and HIPAA compliance. ⚠ The Provider itself holds no certification and has not been independently audited — see § F.5. The Provider does not present anyone else’s certifications as its own.

A.6 · Logging. Audit triggers record every creation, modification and deletion in the audited tables, with the author and the time. For clinical data, the old and new values are kept; for the tables holding the identification and contact data of patients and staff, only the names of the changed fields are kept, not the values. The log also contains the EXPORT and PRINT rows described in § 11.5. The log is append-only: it cannot be modified or deleted from the Software. ⚠ On-screen reads are not logged — see § 11.5 and § F.1.

A.7 · Filtering fault reports before they are sent. Fault reports pass through a filter of 14 ordered rules, the first two of which are structural (they rely on the shape of the text, not on a content pattern) and are the only ones that can catch a proper name quoted by the database in an error message. The rules remove: the value in a database error message, quoted text that is not a technical identifier, query strings, session and authorisation tokens, access keys, the account name on the workstation, the home directory path, email addresses, IBANs, CNPs, tax codes preceded by “RO”, phone numbers and any unbroken string of seven or more digits.

⚠ What the filter does NOT remove, declared deliberately:

• UUID technical identifiers are kept on purpose — without them, a fault report cannot be linked to the record that caused it;
• the SQL error code is carried untouched, as a separate field of the report, precisely so that it is not removed by the rule that strips values;
• ⚠ a person’s name written in free text cannot be caught by any rule. The structural rules catch it when it appears in the form in which the database quotes a value; they do not catch it when the user has typed it into a note or a description.

A.8 · Automatic lock on inactivity. Each computer’s session locks after a period of inactivity set by the Practice, between 5 and 480 minutes (default 30), and stays locked across a restart of the Software, so that a workstation left unattended at the front desk does not stay open.

A.9 · Two-step sign-in and passwords. Signing in to the Software first requires the Practice’s licence account and then the person, so that actions are attributed to a person, not to a workstation. The Software and the account portal require passwords of at least 10 characters. ⚠ There is no second authentication factor (§ F.9).

A.10 · Signing out all devices. From Settings → Users and permissions, the Practice’s administrator can sign all the Practice’s other computers out of the account — for example after one is lost or stolen; whatever was open on them closes within an hour at most.

A.11 · Access by the Provider’s staff. The Provider’s authorised persons have administrative access to the hosting project (the platform console and the service role) and use it only for the instructions in Clause 7.1 and for the assistance in Clause 8. Each of them is bound by the confidentiality undertaking in § 12.4. Exports made for a Practice are written only to an encrypted volume; the full export archive delivered through Proton Drive is encrypted by the Provider, and its password never reaches Proton (Annex IV § 1.4). In remote support, the Provider does not open sessions on its own initiative and does not use unattended access (I-8). The Provider’s development and maintenance tools, including AI-assisted tools, receive the Practice’s data only under the conditions of § 11.1.

§ B · Specific safeguards for data concerning health (Clause 7.5)

1. Strict purpose limitation to Annex II, reinforced by the prohibition in § 11.1.
2. Access restrictions: clinical data can be read only with view_clinical and created only with edit_clinical, and the same applies to patients’ scans and documents in the storage buckets; national identifiers in the patient record can be read only with view_patient_identifiers (§ A.2, § A.4; § 12.1).
3. Isolation between practices through row-level security (§ A.1).
4. A record of modifications, exports and printouts (§ A.6, § 11.5).
5. Restrictions on onward transfers. Apart from hosting (Annex IV § 1.1), the product does not transmit clinical data to any sub-processor; the Provider transmits them only in the encrypted archive of the full export, delivered through Proton Drive (I-10; Annex IV § 1.4), and in the operations under I-10 and I-11 carried out with the tools in § 11.1 (Annex IV § 1.6). Beyond these, patient data can leave the project only: through the daily report with patient names, if the Practice has enabled it (§ 11.2(a)); through text typed by staff in a feedback report, a fault description or the assistant box, and through the screen address in a fault report, which may contain the technical identifier of a patient record (§ 11.2, § 11.3); through the messages the Practice sends to patients through its own messaging provider (I-3); through the view of the screen in remote support started by the Practice (I-8).
6. Confidentiality undertakings that expressly name data concerning health (§ 12.4).
7. No automated decisions. The Software does not take decisions about patients based solely on automated processing that produce legal effects concerning them or similarly significantly affect them (Article 22 GDPR). The calculations and reference values shown in the patient record are for information only; the clinical decision belongs to the Practice’s professional.

§ C · Assistance to the Controller (Clause 8(d))

The Controller’s obligation	What the Provider delivers	Time limit
Articles 15 / 20 — access and portability	“Clinical file — printed”, “Clinical file” (JSON) and the export of all patients, from the product; on request, the full export of the Practice’s data	immediately, from the product; full export: 10 working days
Article 16 — rectification	editing in the product; on request, corrections that the Software does not expose	10 working days
Article 17 — erasure	anonymisation (§ 11.4), plus assistance with what the tool cannot reach: stored files and text written differently from the patient record	10 working days
Article 18 — restriction	restriction of processing, from the product (Clause 8)	immediately, from the product
Article 30(1) — the Controller’s record	Annex II and Annex IV, kept up to date	at every change
Article 32 — security	Annex III, kept up to date; answers to security questionnaires	15 working days
Articles 33–34 — personal data breaches	the notification under Clause 9.2, with the information the Practice needs for the form approved by ANSPDCP Decision no. 128/2018: the date and time of the breach and of its discovery, its nature, the categories of data and the approximate number of data subjects and records concerned, the likely consequences, the measures taken or proposed and the contact point; further assistance, including with informing data subjects (Article 34 GDPR)	the notification: without undue delay and no later than 48 hours after the Provider becomes aware of the breach (Clause 9.2); further information: as it becomes available
Article 35 — impact assessment	the technical description of the flows, recipients, transfers and measures; the Provider does not draft the assessment on the Practice’s behalf and does not decide whether it is mandatory	15 working days
Article 36 — prior consultation	the same information, in the form required by ANSPDCP	15 working days

Requests for assistance are sent to contact@optiswift.ro or from Settings → “Feedback and suggestions”; time limits run from receipt of the request. Exports from the product remain available even when use of the Software is restricted for non-payment, and during the export window after the subscription ends (Clause 8, Clause 10(d)).

§ D · Incident detection mechanisms — listed by name

Mechanism	What it observes	Frequency
app.fault_watch_tick	fault reports arriving from the Software and the error channel’s verdicts	every 5 minutes
app.fault_channel_findings	the state of the channel itself: sender not configured, sender stopped, monitor stopped (tick-stale), intake door overloaded	on every run of the mechanism above
the weekly summary	a recap, even if nothing has changed	Monday morning
the audit log	modifications, exports and printouts, retrospectively	when queried
sub-processors’ notifications	incidents at the hosting platform and at the other sub-processors	under their agreements (Clause 9.2)
the hosting platform’s tools	availability, infrastructure errors	continuously, by the hosting provider

⚠ The limitation stated in Clause 9.2 is repeated here because it matters: the tick-stale check — “has the monitor stopped?” — runs inside the job it monitors. If the job stops, the verdict is no longer produced, and nothing outside the database notices the silence. There is no availability monitor outside the database (§ F.6).

§ E · Backups and restoration — the actual position

What exists	daily backups of the database, made automatically by the hosting platform and kept for 7 days
What does NOT exist	⚠ point-in-time recovery, which is not enabled
What can be lost	⚠ up to 24 hours of work. A restoration brings back the state as at the last daily backup, not as at the time of the incident
What is not in the backups	⚠ the files in the storage buckets — clinical images, uploaded documents, patient photographs, the e-Factura archive and the screenshots from feedback reports. Database backups keep only their descriptive data; a deleted or damaged file cannot be recovered from a backup
Scope of a restoration	⚠ the whole project, for all practices at once. There is no restoration for a single practice; a restoration requested by one practice would also roll back the data of all the others, which is why it is not carried out at the request of a single practice. For an incident that has lost or corrupted a single practice’s data, the Provider may restore the latest daily backup into a separate project, accessible only to the Provider and deleted the same day, and may manually copy back that practice’s rows, as they stood in that backup; files in the storage buckets cannot be recovered in this way.
Restoration time	⚠ not measured. No recovery time objective is promised
The Provider’s own copies	the Provider keeps no copies of the Practice’s database or files outside the hosting platform; the exceptions are the exports under Clause 10(d) and § C, kept temporarily on an encrypted volume and, for delivery, as an encrypted archive in Proton Drive (Annex IV § 1.4), and deleted once the Practice confirms it has opened the archive, and from Proton Drive no later than when the download link expires; and the copy of the database of the previous software, received for the data import under instruction I-11, kept on an encrypted volume and deleted within 30 days of upload

What this means for the Practice, in plain terms: if the database is lost at 17:00, the state from the daily backup is recovered, and the work done after it is redone manually, from the documents issued. A file lost from the storage buckets cannot be recovered from the platform; the Practice keeps its own copies of the files it needs — for example, the e-Factura originals, which it downloads from Invoicing → Submissions with “Download originals”. The Practice takes these limits into account in its own risk assessment and its own continuity plan.

§ F · Measures that do NOT exist — declared

F.1 · There is no log of on-screen reads. Exports and printouts of the clinical file are logged (§ 11.5). The reason is structural: PostgreSQL cannot fire a trigger on SELECT.

F.2 · There is no point-in-time recovery. See § E.

F.3 · The files in the storage buckets have no backups. See § E.

F.4 · There is no automatic deletion when the statutory periods expire for the Practice’s clinical and fiscal data. See § 11.6.

F.5 · There is no independent audit of the Provider’s organisation. The certifications the chain relies on belong to the sub-processors, not to the Provider. See Clause 7.6 and § A.5b.

F.6 · There is no permanent human oversight and no availability monitor outside the database. See Clause 9.2 and § D.

F.7 · OpenAI’s approval for “zero data retention” or for “modified abuse monitoring” has not been requested. Abuse monitoring logs are therefore kept for up to 30 days, unless the law requires longer retention. See § 11.1.

F.8 · Erasure cannot be guaranteed to be complete. Stored files cannot be cleaned of names, and a name written differently from the patient record is not found. See § 11.4.

F.9 · The Practice’s users do not have two-factor authentication. Account protection relies on the password, the two-step sign-in (the licence account, then the person), the inactivity lock and signing out all devices (§ A.8–A.10).

F.10 · Restoration time has not been measured. See § E.

---

ANNEX IV — LIST OF SUB-PROCESSORS

Annex IV is the separate document published at https://www.optiswift.ro/abonament/subimputerniciti, in version SUBP-1.3, which forms an integral part of this agreement. For each sub-processor, it shows the name, address, contact person, description of the processing, place of processing, basis for the transfer and links to its processing agreement and to the list of its own sub-processors — the items required by Annex IV to Decision (EU) 2021/915 — as well as the change notification mechanism required by Clause 7.7(a), Option 2.

The agreed list, as at the date of this version:

Sub-processor	What it does	Country of establishment
Supabase Pte. Ltd.	hosting of the database and files, authentication and the product’s server functions; the data are stored in Ireland (AWS, eu-west-1)	Singapore
Plus Five Five, Inc. (Resend)	sending transactional email	United States
OpenAI Ireland Ltd.	the language model of the in-app assistant, only for practices that have not turned it off	Ireland; processing may take place outside the EEA
Proton AG	the Provider’s mailboxes: support, feedback reports and fault reports; the Proton Drive space through which the full export is delivered, encrypted	Switzerland
TeamViewer Germany GmbH	remote support, in sessions started by the Practice	Germany
Anthropic Ireland, Limited	the language model of the Provider’s development and maintenance tools, only under the conditions of § 11.1 (instructions I-10 and I-11)	Ireland; processing may take place outside the EEA, including in the United States

The list in force at any given time is the one in Annex IV, as amended under Clause 7.7(a) and Annex IV § 4. Annex IV § 4.4, the paragraph “Effect of an objection”, and § 4.5 (“Emergencies”) are listed in the Statement of Express Acceptance at the end of the document.

The following are not sub-processors of the Provider: the Practice’s messaging provider, with which the Practice contracts directly (Annex IV § 2), and the destinations described in Annex IV § 3, including Stripe, through which the Practice pays for the subscription, and Vercel Inc., which hosts the website and the account portal www.optiswift.ro/cont. Stripe receives the Practice’s billing data, and the licence account data pass through the account portal; the licence account’s email address may also be the billing address. The Provider transmits these data only for subscription billing and account administration, purposes for which it is the controller (Annex IV § 3.4, § 3.6 and § 3.8); their processing is described in the Provider’s privacy policy, at https://www.optiswift.ro/confidentialitate.

About the form of Annex IV. The explanatory note to Decision (EU) 2021/915 states that Annex IV “needs to be completed in case of specific authorisation of sub-processors (Clause 7.7(a), Option 1)”. This agreement uses Option 2, which requires the general authorisation to cover an agreed list. The Decision does not prescribe a form for that list; Annex IV uses the set of fields of the Decision’s annex, because it is the only one the Decision defines and because it provides exactly the information the Practice needs in order to exercise its right to object.

---

VERSION HISTORY

Version	Date	What changed
DPA-1.2	8 October 2026	the first version published by OPTISWIFT S.R.L.
DPA-1.3	9 October 2026	importing data from the previous software (I-11); AI-assisted development tools and their sub-processor (§ 11.1, Annex IV); confirmation of each acceptance; exports under the “export only” regime; a minimum for the liability cap (§ 11.8); the retention period for health signals; delivery of the full export through Proton Drive (I-10, Annex IV)

---

STATEMENT OF EXPRESS ACCEPTANCE OF UNUSUAL CLAUSES

Under Article 1203 of the Civil Code, the clauses below take effect only if they are expressly accepted in writing. The Practice declares that it has read and expressly accepts, in writing, the following clauses of this agreement:

1. Clause 10(c) — Termination by the Processor where the Controller insists on instructions that are contrary to law;
2. Clause 10(d), the note “How point (d) is carried out in practice”, the paragraph “If no choice is made” — Deletion of the data after the 30-day export window;
3. § 11.8 — Limitation of the Provider’s liability, governing law and competent court;
4. Annex IV § 4.5 (“Emergencies”) — Stopping the transmission of data to a sub-processor, and unavailability of the affected function until the 30-day notice period expires, without the Practice’s consent;
5. Annex IV § 4.4, the paragraph “Effect of an objection” — Unavailability to the Practice of the function provided by the sub-processor it has objected to, and termination of the subscription by the Provider after the resolution period.

How acceptance is given. In the product, through a distinct checkbox, not ticked in advance, that reproduces the list above and is ticked separately from acceptance of the agreement; the product records it with the items listed in § 11.7. On paper or with a qualified electronic signature, by the signature below. Using the Software or the Service does not take the place of this acceptance.

The Practice (name, CUI)	………………………………………………………………
Representative (name, position)	………………………………………………………………
Date	………………………………………………………………
Signature	………………………………………………………………

---

End of the agreement. Annexes I–IV form an integral part of it (Clause 1(d)).