DATA PROCESSING AGREEMENT (DPA)

pursuant to Art. 28 GDPR — DR. INFO Platform (DR. INFO Clinical / DR. INFO Workflow)

---

Version: 1.0
Language note: This is an English-language version for information. The executed customer version is concluded in German (AVV); the German text prevails.

---

Parties

This Agreement is concluded between:

Controller ("Customer"): the healthcare organization or healthcare professional that accepts this Agreement through its registered account. The Customer's identity, authorized representative and contact details are those held in the Customer's account and recorded in the Customer Configuration Record at the time of acceptance.

Processor:
Synduct GmbH, Bergmannstr. 58, 80339 München, Deutschland
HRB 298232, Amtsgericht München — USt-IdNr.: DE455696850
Managing Director: Valentine Emmanuel
Privacy Contact: regulatory@synduct.com

(each a "Party", together the "Parties")

---

Preamble

(A) The Controller is a healthcare organization or healthcare professional whose staff are subject to professional secrecy (§ 203 StGB), and which is subject to the GDPR and BDSG when processing patient data.

(B) The Processor provides the DR. INFO Platform, an AI-assisted healthcare workflow platform delivered through two product channels: DR. INFO Clinical (web application) and DR. INFO Workflow (installed software with practice-system integration). In providing the Platform, the Processor processes Personal Data — including health data (Art. 9 GDPR) — on behalf of the Controller.

(C) This Agreement implements Art. 28(3) GDPR for all such processing, regardless of product channel, Workflow Module or Deployment Profile. It is designed as a framework: the contract body below is stable; operational detail lives in versioned Annexes that may be updated only within the strict limits of § 16.

(D) Capitalised terms are used as defined in § 1 and in the Product Dictionary, which serves as an interpretation aid to this Agreement.

---

§ 1 Definitions

1.1 Terms defined in Art. 4 GDPR ("Personal Data", "Processing", "Controller", "Processor", "Personal Data Breach", "Pseudonymisation") have the meaning given there.

1.2 In addition:

• "Customer" — the Controller in its capacity as recipient of the Platform services;
• "Platform" — the DR. INFO Platform, comprising the product channels DR. INFO Clinical (web application) and DR. INFO Workflow (installed software including the PVS Agent);
• "Workflow Module" — a functional capability of the Platform as catalogued in Annex A;
• "Module Activation" — the logged enablement of a Workflow Module by the Controller's authorized administrator within the Platform, constituting a documented instruction (§ 4.2);
• "De-identification (Masking)" — removal or replacement of direct identifiers in Source Data prior to AI-assisted processing; legally a form of Pseudonymisation (Art. 4(5) GDPR) — masked data remains Personal Data;
• "Anonymisation" — irreversible transformation to the standard of Recital 26 GDPR (Article 29 Working Party Opinion 05/2014), applied only to the training-data programme under Annex G, meeting the irreversibility standard specified in Annex G. Account-retained service derivatives under Annex A (e.g. stored Scribe transcripts and generated reports) are De-identified (Masked), i.e. Pseudonymised Personal Data, and are not Anonymised data;
• "Zero Data Retention" — a configuration and contractual arrangement under which a Foundation-Model provider stores no prompts or outputs after inference and uses no Customer data for model training;
• "Customer Configuration Record" — the record per Annex B, Appendix B-1, documenting the Controller's product channel(s), Deployment Profile and activated Workflow Modules;
• "Annexes" — the documents listed in § 2.3, as amended from time to time in accordance with § 16.

§ 2 Subject matter; structure of this Agreement

2.1 The Processor processes Personal Data on behalf of the Controller exclusively for the provision of the Platform and the Workflow Modules activated by the Controller.

2.2 This Agreement governs all such processing in both product channels and all Deployment Profiles.

2.3 The following Annexes form an integral part of this Agreement:

Annex D (the Sub-processor List) is published at https://www.drinfo.ai/legal/sub-processors. The current versions of the other Annexes are provided to the Controller on request (regulatory@synduct.com), including before the Controller accepts this Agreement.

2.4 Order of precedence: (1) mandatory law; (2) the body of this Agreement; (3) Annexes A-G; (4) the Product Dictionary and referenced supporting documents. In case of conflict, the higher-ranking source prevails. Individually negotiated agreements take precedence over these standard terms (§ 305b BGB); the Parties intend amendments to the body of this Agreement to be made in the form of § 16.1.

§ 3 Nature and purpose of processing; duration; data categories; data subjects

3.1 Nature and purpose: receipt of Source Data — including, in the DR. INFO Workflow channel, agent-assisted export of chart data from the Controller's practice information system (e.g. CGM M1 Pro, tomedo) within the Controller's environment and only on an Authorized User's instruction —, validation, De-identification (Masking), structuring, extraction, summarisation, transcription (Scribe Module), drafting and return of Workflow Outputs for the administrative and documentation Workflows described in Annex A, and deletion thereafter.

3.2 Duration: the term of this Agreement corresponds to the term of the main services agreement (§ 15).

3.3 Categories of data subjects: patients of the Controller; Authorized Users; other Controller staff; where contained in Source Documents: third-party practitioners and relatives mentioned in records.

3.4 Categories of Personal Data: as specified per Workflow Module in Annex A, including Special Category Data (health data, Art. 9(1) GDPR) such as diagnoses, medication, treatment records, sick-leave data and — for the Scribe Module only — voice recordings of consultations. Data categories not listed in Annex A for a Module activated by the Controller are not processed, except for the platform-level categories described in Annex A (user account data, identifier-masked user queries, pseudonymised telemetry), which are processed for every Customer.

3.5 Place of processing: exclusively within the EU/EEA, subject to § 9.

3.6 Role allocation: for contract administration, user account management, billing, and aggregate service improvement based on identifier-masked usage data, the Processor acts as an independent controller within the meaning of Art. 4(7) GDPR, on the legal bases of Art. 6(1)(b) and (f) GDPR; the Processor's privacy notice applies to such processing. This Agreement governs all other processing described in Annex A.

3.7 Legal basis for health data: As the Controller, the Customer bears sole responsibility for establishing a valid legal basis for the processing of special categories of personal data (health data) pursuant to Art. 9(2) GDPR. The Controller warrants that explicit patient consent or another valid exemption under Art. 9 GDPR has been legally secured before transmitting any health data to the Platform. The Processor processes the data strictly in reliance on this warranty and is under no legal obligation to verify the existence or validity of the Controller's legal basis.

§ 4 Processing on documented instructions

4.1 The Processor processes Personal Data only on documented instructions of the Controller (Art. 28(3)(a) GDPR), including with regard to transfers to third countries, unless required to do so by Union or Member State law; in such a case, the Processor shall inform the Controller of that legal requirement before processing, unless that law prohibits such information on important grounds of public interest.

4.2 Documented instructions are constituted by: (a) this Agreement including its Annexes; (b) the Customer Configuration Record; (c) logged Module Activations performed by the Controller's authorized administrator within the Platform (electronic form, Art. 28(9) GDPR); and (d) individual instructions in text form (e-mail) from the persons named by the Controller as authorized to instruct.

4.3 The Processor maintains an instruction log (including all Module Activations with user, timestamp, Module and Annex A version) and provides it to the Controller on request.

4.4 If the Processor considers an instruction to infringe the GDPR or other data protection provisions, it shall inform the Controller immediately (Art. 28(3) sentence 3 GDPR) and may suspend execution of that instruction until it is confirmed or changed by the Controller. The Processor may refuse instructions that are manifestly unlawful.

4.5 Instructions exceeding the contractually agreed service scope are treated as change requests; any additional cost is agreed before execution (§ 14.2).

§ 5 De-identification, AI processing, prohibition of training use

5.1 Direct identifiers in Source Data are removed or replaced (De-identification/Masking) before transmission to the Foundation-Model provider. In Deployment Profile B (installed software), Masking is performed entirely within the Controller's environment; in Deployment Profile A (web application), Masking is performed within the Processor's EU environment prior to the AI-service call. This § 5.1 does not apply to Scribe audio, which cannot technically be masked prior to transcription and is processed on the basis of explicit patient consent (Annex A-4).

5.2 Foundation-Model processing is performed via Google Cloud Vertex AI (Gemini), EU region, under Zero Data Retention: no storage of prompts or outputs after inference, no abuse-monitoring prompt logging, no use for model training. For the Scribe Module, speech-to-text transcription is additionally performed by Speechmatics Ltd. (Annex D) under equivalent conditions: transient processing only, deletion per the Scribe deletion clocks (Annex A-4), and no use of Controller data for model training. These commitments reflect the providers' terms and configurations current at execution; provider-side changes are handled per §§ 8.2 and 16.

5.3 Prohibition of training use: the Processor shall not use identifiable or pseudonymised Personal Data of the Controller for the training, fine-tuning or evaluation of AI models. The use of irreversibly Anonymised data for such purposes occurs only where separately agreed with the Controller and exclusively in accordance with Annex G; participation is voluntary, recorded in the Customer Configuration Record, and may be ended by the Controller at any time with effect for the future. Data originating from the Scribe Module — recordings, transcripts and chart entries derived from them — is excluded from any such provision.

5.4 Every Workflow Output is a draft requiring review by an Authorized User; the Platform has no capability to dispatch documents to third parties autonomously.

§ 6 Confidentiality; personnel; § 203 StGB

6.1 The Processor ensures that all persons authorised to process Personal Data have committed themselves to confidentiality, unless they are under an appropriate statutory obligation of confidentiality (Art. 28(3)(b) GDPR), and that they process Personal Data only on instructions (Art. 29, Art. 32(4) GDPR).

6.2 All such persons — including freelancers and contractors, and expressly including remote staff participating in screen-sharing sessions with the Controller — are additionally bound in writing as mitwirkende Personen within the meaning of § 203 Abs. 3, 4 StGB and instructed on the criminal consequences of unauthorised disclosure. These obligations survive the end of their engagement. This regime also satisfies Art. 9(3) GDPR: health data is processed under the responsibility of persons bound by professional-secrecy obligations.

6.3 Access to Personal Data is granted on a need-to-know basis under a role-based access model (Annex E); access authorisations are reviewed regularly and revoked without undue delay upon role change or departure.

6.4 The Processor's personnel receive data protection training before first access to Controller data and refresher training at appropriate intervals; training records are maintained.

§ 7 Security of processing (Art. 32 GDPR)

7.1 The Processor implements and maintains the technical and organisational measures set out in Annex E (TOM), taking into account the state of the art, implementation costs and the nature, scope, context and purposes of processing as well as the risks for data subjects — including, as appropriate: encryption of Personal Data in transit (TLS 1.2+) and at rest; Pseudonymisation; measures to ensure ongoing confidentiality, integrity, availability and resilience; the ability to restore availability after an incident; and a process for regularly testing, assessing and evaluating effectiveness.

7.2 The TOM may be developed further in line with technical progress; the level of protection may never be reduced (§ 16.2). Material changes are notified per § 16.

7.3 On request, the Processor demonstrates compliance with Annex E by providing suitable evidence (configuration extracts, audit reports, certifications where available, test records).

§ 8 Sub-processors

8.1 The Controller grants general authorisation for the engagement of the Sub-processors listed in Annex D for the services described there.

8.2 The Processor notifies the Controller in text form at least 30 days before the intended addition or replacement of a Sub-processor. The Controller may object within this period on reasonable data-protection grounds. The Parties will seek an amicable solution (e.g. alternative measures or providers); failing that, the Controller may terminate the affected services — or, if partial termination is unreasonable, this Agreement together with the main services agreement — without penalty as of the date the change takes effect; prepaid remuneration for periods after the effective date of termination is refunded pro rata.

8.3 The Processor imposes on every Sub-processor, by contract, data-protection obligations materially equivalent to those in this Agreement — in particular sufficient guarantees under Art. 28(1) and (4) GDPR, confidentiality, Art. 32 security, transparency and audit support, and deletion/return. Where a Sub-processor acts as a mitwirkende Person within the meaning of § 203 Abs. 3 StGB, the Processor ensures corresponding confidentiality obligations; for infrastructure and AI-service providers without intended access to patient secrets in identifiable form, the confidentiality commitments under Art. 28(3)(b) GDPR suffice.

8.4 The Processor remains fully liable to the Controller for the performance of each Sub-processor's obligations (Art. 28(4) sentence 2 GDPR).

8.5 Engagement of a Sub-processor outside the EU/EEA additionally requires compliance with § 9.

§ 9 Transfers to third countries

9.1 Processing takes place in the EU/EEA. A transfer of Personal Data to a third country occurs only (a) on documented instruction of the Controller, or (b) where required for the service and safeguarded per Chapter V GDPR.

9.2 Where a Sub-processor is subject to third-country jurisdiction, the applicable transfer mechanism is documented in Annex D per Sub-processor — currently: the EU-U.S. Data Privacy Framework (Adequacy Decision under Art. 45 GDPR) for certified US entities such as Google LLC, and the EU–UK Adequacy Decision (Art. 45 GDPR, in force until 27 December 2026) for UK-based Sub-processors such as Speechmatics Ltd.; in each case with EU Standard Contractual Clauses (2021) under Art. 46(2)(c) GDPR as a contractual fallback.

9.3 Where a transfer is based on an adequacy decision pursuant to Art. 45 GDPR (such as the EU-U.S. DPF), no Transfer Impact Assessment (TIA) or further authorisation is required. The Processor maintains a Transfer Impact Assessment strictly for transfers relying on appropriate safeguards under Art. 46 GDPR (e.g., SCCs as a fallback mechanism). Where applicable under Art. 46 GDPR, this assessment documents supplementary measures (De-identification before transfer, Zero Data Retention, EU-region pinning, encryption) and is available to the Controller on request.

§ 10 Assistance to the Controller

10.1 Data subject rights (Art. 28(3)(e)): taking into account the nature of the processing, the Processor assists the Controller with appropriate technical and organisational measures in fulfilling the Controller's obligations under Arts. 12-23 GDPR. Any data subject request received directly by the Processor is forwarded to the Controller without undue delay; the Processor does not respond substantively to data subjects of the Controller. For the Scribe Module, consent withdrawals forwarded by the Controller are executed within 24 hours (Annex A-4).

10.2 Arts. 32-36 (Art. 28(3)(f)): the Processor assists the Controller in ensuring compliance with security, breach-notification, data-protection-impact-assessment and prior-consultation obligations, in particular by providing its DPIA, the Data Protection Architecture, and the information required under Art. 33(3) GDPR in the event of a Personal Data Breach.

10.3 Assistance under §§ 10.1-10.2 is provided free of charge to the extent it is legally required and arises in the ordinary course; for requests exceeding this, § 14.2 applies.

§ 11 Personal Data Breaches

11.1 The Processor notifies the Controller without undue delay after becoming aware of a Personal Data Breach affecting Personal Data processed for the Controller — as a non-binding operational target: within 24 hours of awareness — and in any event early enough to enable the Controller to meet its own 72-hour obligation under Art. 33(1) GDPR.

11.2 The notification contains at least the information under Art. 33(3) GDPR (nature of the breach; categories and approximate numbers of data subjects and records; likely consequences; measures taken or proposed; contact point). Information may be provided in phases where and insofar as it is not available at the same time.

11.3 The Processor documents all breaches, including non-notifiable ones, in an incident register (Art. 33(5) GDPR) and handles incidents per its Incident Response Plan. The Processor supports the Controller's notifications to supervisory authorities and data subjects.

11.4 A notification under this § 11 is not an acknowledgement of fault or liability.

§ 12 Documentation, information and audit rights (Art. 28(3)(h))

12.1 The Processor makes available to the Controller all information necessary to demonstrate compliance with the obligations laid down in Art. 28 GDPR.

12.2 The Controller (or an auditor mandated by it, who must not be a direct competitor of the Processor and must be bound to confidentiality) may conduct audits, including inspections, of the processing operations covered by this Agreement.

12.3 Modalities: audits require reasonable advance notice (normally 14 days; none in the event of a substantiated serious incident), take place during business hours, no more than once per calendar year unless there is a specific cause, must not endanger the confidentiality of other customers' data, and are conducted at the Controller's cost; where an audit reveals material non-compliance by the Processor with this Agreement, the Processor bears the reasonable costs of that audit. The Processor may first satisfy an audit request by providing meaningful, current evidence (audit reports, certifications, TOM evidence, the documentation package); where this reasonably resolves the request, an on-site inspection is not required.

12.4 Findings are documented; the Processor remedies substantiated deficiencies within a reasonable period and reports completion.

12.5 The Processor shall tolerate and reasonably cooperate with investigations by competent supervisory authorities concerning processing under this Agreement (Art. 31 GDPR) and shall inform the Controller without undue delay of any supervisory measure concerning that processing, unless such information is prohibited by law.

§ 13 Deletion and return of Personal Data (Art. 28(3)(g))

13.1 Upon termination of this Agreement — or earlier upon the Controller's instruction — the Processor shall, at the Controller's choice, return all Personal Data processed on the Controller's behalf in a common, machine-readable format and/or delete it including all copies, and shall confirm deletion to the Controller in text form (§ 126b BGB) within 30 days (deletion certificate).

13.2 Exceptions: (a) data the Processor must retain under Union or Member State law is blocked from any other use and deleted upon expiry of the retention obligation; (b) backup copies are deleted through expiry of the backup rotation (max. 90 days, Annex F) and are not restored other than for disaster recovery, in which case re-deletion is ensured; (c) irreversibly Anonymised data (Annex G) is not Personal Data; already-provided anonymised data completes its agreed retention cycle unless otherwise agreed.

13.3 During the term, deletion follows the retention periods and methods of Annex F, including the Scribe deletion clocks (Annex A-4) and the automated deletion of transient processing copies (max. 24 hours after task completion).

§ 14 Remuneration; costs

14.1 The remuneration for the Platform is governed by the main services agreement. Performance of the obligations under this Agreement is included, subject to § 14.2.

14.2 Support that goes beyond what Art. 28 GDPR requires in the ordinary course — in particular audits beyond the cadence of § 12.3, extensive bespoke analyses, or instruction changes under § 4.5 — may be charged at reasonable, documented cost, agreed in advance.

§ 15 Term; termination; survival

15.1 This Agreement enters into force upon signature (or upon documented electronic acceptance, § 17.2) and runs for the term of the main services agreement. It cannot be terminated separately for as long as the main services agreement requires processing of Personal Data.

15.2 Either Party may terminate for cause; for the Controller, cause includes the Processor's serious or persistent breach of this Agreement that is not remedied within a reasonable cure period.

15.3 §§ 6 (confidentiality/§ 203), 11.3 (documentation), 12 (to the extent required to verify compliance with § 13), 13 (deletion/return) and 18 survive termination.

§ 16 Change mechanism (Annex updates without re-signing)

16.1 Scope. Only the Annexes listed in § 2.3 may be updated under this § 16. Amendments to the body of this Agreement require written form signed by both Parties (Schriftform, § 126 BGB; a qualified electronic signature per § 126a BGB suffices).

16.2 Limits. An Annex update must never: (a) reduce the level of protection for data subjects; (b) expand the categories of Personal Data or purposes beyond the scope activated for the Controller, except through § 16.4; or (c) restrict the Controller's statutory or contractual rights.

16.3 Notice updates. Updates within the limits of § 16.2 — including TOM improvements, editorial changes, and new Workflow Modules that process only data categories and purposes already activated for the Controller — are notified to the Controller in text form at least 14 days before taking effect. Sub-processor changes follow § 8.2 (30 days + objection right). If the Controller objects to a § 16.3 update on reasonable data-protection grounds and no resolution is reached before the effective date, the update does not take effect for the Controller; where customer-specific continuation is not possible because the update is technically indivisible across the multi-tenant Platform, the Controller may instead terminate the affected services without penalty.

16.4 New data categories or purposes — Module Activation. A Workflow Module whose processing involves data categories or purposes not yet activated for the Controller becomes part of the instruction scope only upon Module Activation: an explicit, logged enablement by the Controller's authorized administrator, preceded by an in-Platform description of the Module's data categories, purposes, retention, Sub-processors and — where applicable — consent requirements (e.g. Scribe patient consent). The activation log is retained as the documented instruction (Art. 28(9) GDPR) and made available to the Controller.

16.5 Version control. Every Annex carries a version, effective date and change log; the Processor retains all historical versions and provides them on request. The Annex versions applicable to the Controller at any time are those recorded in the Customer Configuration Record, as updated per this § 16; the Processor provides the Controller with an updated copy of the Customer Configuration Record after every change.

§ 17 Liability; conclusion of this Agreement

17.1 The Parties' liability under Art. 82 GDPR (including the internal allocation per Art. 82(5)) remains unaffected. Fines imposed on a Party under Art. 83 GDPR are borne by that Party.

17.2 Conclusion in electronic form: this Agreement may be concluded by the Controller's documented electronic acceptance within the Platform (separate acceptance action, confirmation of representation authority, logging of identity, timestamp and accepted version, provision of a copy in durable format), satisfying Art. 28(9) GDPR. Hospitals and other institutions may instead require countersigned execution.

17.3 Contractual liability (other than under § 17.1) is governed by the main services agreement.

§ 18 Final provisions

18.1 This Agreement is governed by German law. Exclusive place of jurisdiction, where permissible, is München.

18.2 In the executed customer version, the German text prevails over any courtesy translation.

18.3 Should individual provisions of this Agreement be or become invalid, the validity of the remaining provisions remains unaffected; the Parties shall replace the invalid provision with a valid one that comes closest to its economic and data-protection purpose.

18.4 § 16 governs Annex updates; §§ 15 and 16.1 govern amendments to the body of this Agreement. Individually negotiated agreements take precedence (§ 305b BGB).

18.5 Notices: notices under this Agreement are given in text form (e-mail) to the contact addresses recorded in the Customer Configuration Record (Annex B, Appendix B-1); each Party shall keep its addresses current. Notices to the Processor: regulatory@synduct.com.

---

Acceptance

This Agreement is concluded by the Customer's documented electronic acceptance (Art. 28(9) GDPR); no handwritten signature is required.

• During onboarding, or on first use of a module that processes patient data (e.g. the Scribe or Reports / discharge-letter module), the Customer's authorized representative accepts this Agreement by an explicit acceptance action (e.g. clicking "Accept").
• The acceptance is logged with the accepting user's identity, timestamp and the accepted version. Enabling such a module also constitutes a Module Activation and documented instruction under §§ 4.2 and 16.4, including confirmation of any applicable consent requirements (e.g. Scribe patient consent).
• The Customer confirms that the person accepting is authorized to enter into this Agreement on the Customer's behalf.
• A copy of the accepted Agreement is made available to the Customer in durable form.

Hospitals and other institutions that require a countersigned paper or qualified-electronic-signature version may request one at regulatory@synduct.com.