Data Processing Addendum

Version 1.0 Effective date: [to be completed]

The short version

• You decide what Patient information goes into PerioSync and why. For that information you are the "controller". We store and process it only to run the Service for you. We are your "processor".
• We use Patient Data only on your instructions. We do not sell it, advertise with it or use it to train artificial intelligence.
• We protect it with the measures in Annex 2. Annex 2 also says plainly what the Service does not have, such as two-factor sign-in.
• We use the providers listed in Annex 3. We give you at least 14 days' notice before we add or replace one, and you can object.
• Voice dictation uses your browser's own speech recognition. Your browser's maker may process the audio under its own terms, not ours. You can always enter values by hand instead.
• We tell you about a breach affecting Patient Data without undue delay, and within 48 hours where feasible.
• You must have a lawful basis, tell your Patients how their data is handled, keep your password to yourself, keep identifying details out of share links and diagnosis notes, and check that your local law allows the storage locations in Annex 3. Do not use PerioSync for HIPAA-protected health information.
• When your Account ends, we delete Patient Data as section 13 describes. Ask us for an export first.

This summary is for convenience only. It is not part of the DPA. The full text below is what applies.

1. About this DPA

1.1 This Data Processing Addendum (the "DPA") is an agreement between:

(a) you, the person or organisation that holds a PerioSync account ("you", "your"); and

(b) [to be completed], an individual trading as "PerioSync", of [to be completed], commercial registration / tax number [to be completed] ("PerioSync", "we", "us", "our").

1.2 This DPA is published at /dpa. Other PerioSync documents refer to it as the "Data Processing Addendum" or the "DPA".

1.3 This DPA forms part of the PerioSync Terms of Service at /terms (the "Terms"). You accept it when you accept the Terms, either at sign-up or when we ask you to accept an updated version. We record your acceptance electronically, with the version of this DPA, the date, time and IP address (Terms, section 2.5). Whenever we publish a new version of this DPA, other than an update to Annex 3 under section 8, we also publish a new version of the Terms. Our record of the version of the Terms you accepted therefore also identifies the version of this DPA you accepted. No separate signature is needed for this DPA to bind you and us.

1.4 If you would like a copy of this DPA signed by us for your records, contact us (section 20). A signed copy has exactly the same terms as this text.

1.5 If you accept the Terms on behalf of a clinic, practice, university or other organisation, you confirm that you have authority to bind it. "You" then means that organisation. You must make sure that everyone who uses the Account for it follows this DPA.

1.6 This DPA covers Patient Data only. We also process personal data about you as an Account holder, such as your name, mobile number, payments and sign-in records. For that data we are the controller. Our Privacy Policy at /privacy explains how we handle it. Our use of cookies and browser storage is described at /cookies.

1.7 Accounts opened before this DPA was published. If your Account was opened before this DPA was first published, we will ask you to accept it the next time you open the app, even if you are still signed in. Until you accept it, we process the Patient Data in your Account only to store it, keep it secure, and export or delete it at your request. In the meantime, we apply sections 3.4, 4.6, 6, 7, 8.3, 9, 12 and 13 of this DPA to that Patient Data as if you had accepted it.

2. Definitions

2.1 In this DPA:

• "Account" means a PerioSync user account.

• "Content" means anything that you, or anyone using your Account, enters, dictates, imports or otherwise puts into the Service.

• "Credits" has the meaning given in the Terms.

• "Data Protection Law" means every law on the protection of personal data that applies to the processing of Patient Data under this DPA. Depending on where you and your Patients are, this may include:

  • Egypt's Personal Data Protection Law No. 151 of 2020 and its Executive Regulations (the "Egyptian PDPL");
  • Regulation (EU) 2016/679, the General Data Protection Regulation (the "GDPR");
  • the GDPR as it forms part of the law of the United Kingdom, and the UK Data Protection Act 2018 (the "UK GDPR");
  • the Swiss Federal Act on Data Protection (the "FADP"); and
  • the data protection law of the country where you practise.

• "Instructions" has the meaning given in section 5.2.

• "Patient" means an individual about whom information is recorded in the Service, usually a patient of yours.

• "Patient Data" means personal data that we process on your behalf as your processor. It includes:

  • (a) Patient records and charts in your Account;
  • (b) the name of any clinician or other person recorded in them;
  • (c) the text of voice phrases sent for interpretation under section 9.5;
  • (d) chart data carried in a share link when the link is opened in your Account; and
  • (e) any information about a Patient that you include in a message to us or in a credit-request note.

  Annex 1 describes Patient Data in more detail.

• "PDPC" means Egypt's Personal Data Protection Centre.

• "Personal Data Breach" means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, Patient Data while it is on systems controlled by us or our Sub-processors. It does not include:

  • (a) unsuccessful attempts or activities that do not compromise the security of Patient Data, such as failed sign-in attempts, pings, port scans or blocked attacks; or
  • (b) an event that happens only on your own devices or through your own choices, such as losing an unlocked device or sending a share link or an export to the wrong person.

  Unauthorised access to your Account through our systems is a Personal Data Breach under this DPA, even where it happened because a password was shared, reused or guessed. Sections 12.7 and 12.8 explain who is responsible and how we help.

• "SCCs" means the standard contractual clauses for the transfer of personal data to third countries approved by European Commission Implementing Decision (EU) 2021/914 of 4 June 2021.

• "Service" means the PerioSync web application at https://periosync.com, including www.periosync.com and any other address at which we run it (such as periosync.vercel.app), its installable version, and the support we provide for it.

• "Sub-processor" means a third party that we engage to process Patient Data on our behalf. The current Sub-processors are listed in Annex 3, Part A.

• "UK Addendum" means the International Data Transfer Addendum to the EU Commission Standard Contractual Clauses issued by the UK Information Commissioner under section 119A of the Data Protection Act 2018 (version B1.0, in force from 21 March 2022), as amended or replaced.

• "Working Day" means Sunday to Thursday, except public holidays in Egypt.

2.2 The words "controller", "processor", "data subject", "personal data", "processing", "special categories of personal data" and "supervisory authority" have the meanings given in the GDPR. Where another Data Protection Law applies, they include the equivalent terms in that law. For example, "special categories of personal data" includes "sensitive data" under the Egyptian PDPL, and "supervisory authority" includes the PDPC.

2.3 Other capitalised words have the meanings given in the Terms. Headings and the short version do not affect how this DPA is read. "Including" and "for example" introduce examples. They do not limit the general words before them. "In writing" includes email and WhatsApp messages.

3. Roles

3.1 For Patient Data, you are the controller and we are your processor.

3.2 You may yourself be a processor for someone else, for example a clinic that employs you or a colleague you chart for. In that case:

(a) you confirm that the controller has authorised you to use the Service and to appoint us as a further processor on the terms of this DPA;

(b) you are responsible for making sure your Instructions reflect the controller's instructions, and for passing on to the controller any information or notice we give you under this DPA; and

(c) you remain our only point of contact, and we act on your Instructions.

3.3 Each of us will comply with the duties that Data Protection Law places on it in its own role. Our duties as processor are those set out in this DPA and those that Data Protection Law imposes on us directly. We do not promise that the Service meets any requirement of your local law that this DPA does not describe, such as keeping data in your country, using a locally licensed or certified provider, or signing a particular form of contract. Checking this is your responsibility (sections 16.6 and 16.8).

3.4 Because we operate from Egypt, the Egyptian PDPL applies to our processing of Patient Data. We will:

(a) process Patient Data lawfully, and only for the purposes and the period set by your Instructions;

(b) keep it secure;

(c) keep a record of our processing;

(d) not process it in a way that causes harm to Patients;

(e) delete it, or hand it back to you, when the processing ends (section 13);

(f) notify the PDPC of a Personal Data Breach where that law requires us to (section 12.5); and

(g) hold any licence or permit that the Egyptian PDPL requires of us as a processor of sensitive data and for the transfers described in section 15.1. Status: [to be completed].

4. What we process and why

4.1 Subject matter. Hosting and processing Patient Data so that we can provide the Service to you.

4.2 Duration. From the time Patient Data is first entered into your Account until it is deleted under section 13.

4.3 Nature. Collecting Patient Data through the Service; storing, retrieving and displaying it; calculating and comparing values from it (for example clinical attachment level, percentages, indices and changes between visits); proposing a diagnosis from the recorded measurements, where that feature is enabled; interpreting voice phrases, where that feature is enabled (section 9.5); reading share links; any backup copies kept by our database provider (section 13.5); and exporting, correcting and deleting it.

4.4 Purpose. To provide the Service to you under the Terms. This includes giving support you ask for, keeping the Service secure and working, and following your Instructions.

4.5 Data subjects, data and locations. Annex 1 lists the categories of data subjects and of Patient Data. Annex 3 lists who processes Patient Data for us and where.

4.6 No other use. We will not use Patient Data for any purpose of our own. In particular, we will not sell it, rent it, use it for advertising or marketing, use it to train artificial intelligence models, combine it with data from other Accounts, or try to identify a Patient. We may count records (for example, the number of Patients or charts in an Account) to apply usage limits and to run our administration. These counts contain no information about any Patient.

5. Your Instructions

5.1 We will process Patient Data only on your documented Instructions, including for transfers to other countries. The only exception is where the law requires us to do otherwise (section 5.6).

5.2 Your "Instructions" are:

(a) the Terms and this DPA;

(b) your use of the Service, meaning everything you or anyone using your Account does in it, such as creating Patient records and charts, dictating, sharing a chart as a link, importing a link, exporting and asking for support;

(c) your requests for export, correction or deletion under sections 10 and 13; and

(d) any other instruction you give us in writing that we agree to in writing.

5.3 Your Instructions include the processing needed to run the Service for you: hosting and backups, keeping the Service secure, preventing abuse, applying usage limits, and finding and fixing faults.

5.4 Any further Instruction must be consistent with the Terms and with how the Service works. We may decline an Instruction that would require us to change the Service or that is not technically possible. If we do, you may stop using the Service and ask for export and deletion under section 13.

5.5 We will immediately tell you if, in our opinion, an Instruction infringes Data Protection Law. We may decline to carry out that Instruction until you confirm or change it. This does not mean that we check every Instruction for legal compliance. That remains your responsibility (section 16.9).

5.6 A law, court or public authority may require us to process or disclose Patient Data other than on your Instructions. If so, we will tell you before we do it, unless the law forbids us to tell you on important grounds of public interest. Where it is reasonable, we will ask the authority to obtain the data from you directly. We will disclose only what we are required to disclose.

6. Our people

6.1 We give access to Patient Data only to people who need it to provide, support or secure the Service, or to carry out your Instructions. They may process Patient Data only on your Instructions.

6.2 We will make sure that everyone we allow to access Patient Data has committed in writing to keep it confidential, or is under a legal duty of confidentiality. [to be completed]

6.3 Our administration screens show Account details, counts, credit requests (including any note written in them) and the text of support messages sent through the app. They also let an administrator open a chart, read only, for one of the purposes listed below; every opening is recorded in the administrator audit log, and Patient Data cannot be changed through those screens. A support message or credit-request note will show any Patient information written in it, contrary to section 16.3(d). Direct access to the database is limited to us and to people acting for us under sections 6.2 and 6.4. We will look at the content of Patient Data only where this is needed:

(a) to give support you ask for;

(b) to carry out your request for export, correction or deletion;

(c) to investigate or fix a security incident or a technical fault; or

(d) to comply with the law.

6.4 People who build and maintain the Service for us, such as our developer, act only under our authority and on our written instructions, are bound by section 6.2, and may access Patient Data only for the purposes in section 6.3. If our developer is an independent business rather than a person working under our direction, it is also a Sub-processor, is listed in Annex 3, Part A, and section 8 applies to it.

6.5 We do not give any artificial-intelligence service, coding assistant, analytics, error-tracking or other third-party tool access to Patient Data, apart from the Sub-processors in Annex 3. When we investigate a fault, we use test data or remove Patient Data first. [to be completed]

7. Security

7.1 We will put in place and maintain the technical and organisational measures described in Annex 2. They take into account the state of the art, the costs of implementation, the nature, scope, context and purposes of the processing, and the risks to Patients.

7.2 Annex 2 also lists measures that the Service does not have. Before you enter Patient Data, you must read Annex 2 and decide whether these measures, together with your own, are appropriate for the risks of your processing. By entering Patient Data, you confirm that you have done so.

7.3 We may change the measures in Annex 2 over time. We will not reduce the overall level of protection they give to Patient Data.

7.4 Security also depends on how you and the people using your Account use the Service. Your responsibilities are set out in section 16.

7.5 No system is completely secure. We do not promise that Patient Data can never be accessed without authorisation. We do promise to meet our obligations under this section and under section 12.

8. Sub-processors

8.1 Authorisation. You give us general written authorisation to engage the Sub-processors listed in Annex 3, Part A, and to engage new or replacement Sub-processors under this section.

8.2 Contracts. We will engage each Sub-processor under a written contract that requires it to protect Patient Data to at least the level required by Article 28(3) of the GDPR, as far as this is relevant to the service it provides. The contract may be the Sub-processor's standard data processing terms.

8.3 Responsibility. We remain responsible to you for the performance of each Sub-processor's obligations as if they were our own, subject to section 17.

8.4 Notice of changes. We will give you notice at least 14 days before a new or replacement Sub-processor starts to process Patient Data. We will give it in the app, or by WhatsApp or SMS to the mobile number registered to your Account, or both. We will also update Annex 3 at /dpa. The notice will say who the Sub-processor is, what it will do and where it will process Patient Data.

8.5 Your right to object. You may object to the change in writing within that 14-day period, on reasonable grounds relating to data protection. Your 14-day period to object runs from when you receive the notice under section 20.3.

(a) We will discuss your objection with you in good faith. Where it is feasible, we may offer a way to avoid the change for your Account, for example by your not using the feature that relies on the new Sub-processor.

(b) If we cannot resolve your objection, you may end the Terms and this DPA by telling us in writing, either before the change takes effect or within 30 days after it does. Section 13 then applies to export and deletion of your Patient Data.

(c) If you end the Terms under this section, we refund the Credits you bought and have not used, as section 7.5 of the Refund Policy at /refunds and section 12.2(e) of the Terms describe. No other refund is due, except where mandatory law requires one.

(d) If you do not object within the 14-day period, you accept the change.

8.6 Urgent changes. We may have to replace a Sub-processor urgently, for example because of a security risk, because the Sub-processor stops providing its service, or because the law requires it. In that case we may make the change on shorter notice. We will tell you as soon as reasonably possible, and your right to object under section 8.5 runs from that notice.

8.7 Services you choose. Some services that may handle Patient Data are chosen and used by you. They are not our Sub-processors. They include your web browser and its speech service, WhatsApp, and anyone you send a share link to. Section 9 and Annex 3, Part B explain them. When we use WhatsApp to reply to you, to send you notices or to deliver an export you asked for, we do so as sections 9.10 and 13.2 describe.

9. Voice dictation and other services you choose

Voice dictation

9.1 Voice dictation is optional. It runs only after you start it, and you can stop it at any time. You can also refuse or withdraw your browser's permission to use the microphone. Every value can be entered by hand instead.

9.2 Speech recognition is provided by your web browser, not by us. Depending on the browser and its settings, the browser may send the microphone audio to its maker's servers to turn speech into text. For example, Chrome sends it to Google, Edge sends it to Microsoft, and Safari may send it to Apple. That processing is carried out by the browser maker under its own terms and privacy policy. We never receive, record or store audio. We have no contract with the browser maker for this processing and no control over it. The browser maker is not our Sub-processor.

9.3 Dictation stays off until you choose to use it. Before your first dictation, the Service shows the notice described in section 9.4. By starting dictation after that notice, you choose to use your browser's speech recognition. You also choose which browser to use. The browser maker provides speech recognition to you under its own terms. We have no contract with it, and it is not our Sub-processor. You must decide whether its terms are acceptable for Patients' voices under the law that applies to you, and tell your Patients about it (section 16.2). If its terms are not acceptable, do not use dictation.

9.4 The microphone picks up any voice in the room, including Patients, people with them and staff. Only words that the browser recognises as text reach the Service. Before your first dictation, the Service shows a notice explaining sections 9.2 to 9.5.

9.5 Most phrases are interpreted inside your browser. An AI voice fallback may be enabled for your Account. When it is enabled, and our in-browser interpreter cannot read a phrase of 16 words or fewer that contains a number, we send the following to Groq, Inc. (a Sub-processor, see Annex 3) to interpret it:

(a) the text of the phrase (up to 500 characters);

(b) up to five alternative readings of the phrase from your browser; and

(c) the tooth, side and measurement currently being charted.

We do not send Groq the Patient's name, reference or date of birth, the chart's identifier or your Account details. However, every word recognised in the phrase is sent. If a name or other personal detail was spoken in that phrase, it will be sent too. We do not save the phrase text in our database. Groq interprets the text with a language model that does not call outside tools or services, such as web search. [to be completed]

Whether the AI voice fallback is enabled is set by us for the Service, not by you. You can ask us at any time whether it is enabled for your Account, and we will tell you. While it is not enabled for your Account, we will give you at least 14 days' notice, in the way described in section 8.4, before we enable it. This lets you update the information you give your Patients. You may object as described in section 8.5.

9.6 If you switch on "Say teeth", the Service reads the current tooth position aloud using your browser's speech synthesis. Depending on the voice your browser uses, the browser maker may process the words read aloud.

Share links

9.7 When you press Share, the Service copies a link that contains the chart's readings and its diagnosis, including the free-text diagnosis note. The link does not contain the Patient's name, reference, date of birth or tooth notes. The chart data is encoded in the link, not encrypted, so anyone who has the link can read it. We do not save share links in our database. When a link is opened, its contents pass through our servers to be read, and the full link may be recorded in our hosting provider's request logs.

9.8 Anyone who is signed in to PerioSync and has the link can import the chart into their own Account. Links cannot be withdrawn and do not expire. Sending a link is a disclosure by you to the person you send it to. Once they import it, they are the controller of their copy, and we process that copy on their instructions, not yours. You must send links only to people entitled to receive the information, through a channel you trust.

Exports, printing and support channels

9.9 PDF files, PNG images and printouts of charts are created in your browser and saved or printed on your device. We do not receive a copy. Once an export leaves the Service, it is your responsibility.

9.10 WhatsApp, email and the support form. WhatsApp is operated by Meta under its own terms. Email to our address is handled by our email provider, and email is not a secure channel for Patient Data. Please do not send Patient Data to us by WhatsApp, email, the in-app support form or a credit-request note. If you do, we will treat it as Patient Data under this DPA and use it only to deal with your request. In addition:

(a) we reply to support messages, and send notices under this DPA, by WhatsApp. Our replies and notices will not repeat Patient information;

(b) messages and files you send us by WhatsApp or email are kept in our WhatsApp and email accounts. We delete those that contain Patient Data within [to be completed] days after we have dealt with the request they relate to. If you ask us to delete them sooner, we will do so within 7 days;

(c) if you ask, we will delete Patient Data from a support message or credit-request note stored in the Service within 30 days after we verify your request;

(d) our WhatsApp chats are not backed up to cloud storage unless that backup is end-to-end encrypted. [to be completed]; and

(e) copies held by Meta, by your email provider or on your own devices are outside our control.

WhatsApp is a channel you choose, not our Sub-processor.

10. Helping you with Patients' requests

10.1 Patients and other data subjects have rights under Data Protection Law, such as access, correction, deletion, restriction, portability and objection. Responding to them is your responsibility as controller. Taking into account the nature of the processing, we will help you do so with appropriate technical and organisational measures, as far as possible.

10.2 You can view your Patient list and charts in the Service, correct charts, and create PDF and PNG exports of charts. Patient records (reference, name, date of birth and note) cannot be edited or deleted in the Service. Where the Service does not let you do something yourself, send us a request (section 20). This includes correcting a Patient record, deleting a Patient, a chart or your Account, and obtaining a full copy of your charts and Patient records in JSON or PDF format. We verify requests as section 5.9 of the Terms describes. We will acknowledge a request, and start checking it, within 2 Working Days of receiving it. We will act on it within 30 days after we verify it. If you tell us that a request comes from a Patient and has a legal deadline, we will give it priority and tell you at once if we cannot meet that deadline.

10.3 If a Patient or anyone else contacts us about Patient Data, we will not answer the request ourselves, and we will not confirm whether that person is a Patient in any Account. We will not search Patient Data to find out. We will tell the person to contact their dentist or clinic. If the person names their dentist or clinic, and we can match that name to an Account holder using Account details only, we will forward the request to that Account holder without undue delay. We act on the request only on your Instructions, or where the law requires us to.

10.4 We do not charge for requests under this section.

11. Helping you with security, assessments and regulators

11.1 Taking into account the nature of the processing and the information available to us, we will give you reasonable help to meet your obligations under Articles 32 to 36 of the GDPR and the equivalent duties in other Data Protection Law. Those articles cover security, breach notification, data protection impact assessments and prior consultation with a supervisory authority. We will help mainly by making this DPA and its Annexes available and by answering reasonable written questions about the Service.

11.2 If you need further help that takes significant time, we may charge a reasonable fee. We will tell you the fee before we start. We will not charge where the help is needed because we have breached this DPA.

11.3 On request, we will cooperate with a supervisory authority, including the PDPC, in the performance of its tasks.

11.4 We will keep a record of our processing of Patient Data, as Data Protection Law requires processors to do.

12. Personal Data Breaches

12.1 We will notify you without undue delay after we become aware of a Personal Data Breach affecting your Patient Data and, where feasible, within 48 hours.

12.2 We will notify you by WhatsApp or SMS to the mobile number registered to your Account, and in the app where possible. We will also email you if you have given us an email address. A WhatsApp message, SMS or email about a breach will only tell you that there is a security matter concerning your Account and ask you to sign in or contact us. We give you the details of the breach only after we have confirmed that we are speaking to you, or in the app where the Service allows it. Your registered mobile number cannot be changed in the app. If it changes, tell us (section 20) and we will update it after verifying the request. Until then, notices go to the number registered to your Account.

12.3 As far as we know them at the time, our notice will describe:

(a) the nature of the breach, including the categories and approximate number of Patients and records concerned;

(b) its likely consequences;

(c) the measures we have taken, or propose to take, to deal with the breach and reduce its effects; and

(d) who you can contact for more information.

If we do not have all of this information at once, we will give it in stages without further undue delay.

12.4 We will take reasonable steps to contain and investigate the breach and to reduce its effects. We will keep you informed of material developments.

12.5 As controller, you decide whether to notify a supervisory authority or your Patients. We will give you the information you reasonably need to decide and to make any notification. We will not notify your Patients, or a supervisory authority, about a breach affecting your Patient Data unless you agree or the law requires us to. For example, the Egyptian PDPL may require us to notify the PDPC within 72 hours. If we have to notify an authority, we will tell you.

12.6 Our notice of a breach is not an admission of fault or liability.

12.7 Tell us promptly if you suspect that someone else has access to your Account, for example because a password was shared or a device was lost. After verifying your request, we will help you secure the Account, for example by setting a temporary password and signing out its other devices (Annex 2, Part 3). Change your password in the app as soon as you can. This signs out your other devices.

12.8 Where a Personal Data Breach, or an event in part (b) of its definition, was caused by you (including by your breach of section 16.4) or by someone you allowed to use your Account, it is your responsibility and section 16.11 applies. If we become aware of it, we will still notify you under section 12.1 and give you reasonable help.

13. Deletion and return of Patient Data

13.1 During the term. You may ask us at any time to delete specific Patients or charts, or your whole Account (section 10.2). We will delete them within 30 days after we verify your request, giving priority to a request with a legal deadline (section 10.2). Once deleted, data cannot be restored for you. Copies may remain in backups for a limited time, as described in section 13.5.

13.2 Export. You may ask us at any time for a copy of your Patient Data. Within 30 days after we verify your request, we will send your charts and Patient records, in JSON or PDF format, as an encrypted, password-protected file to the WhatsApp number registered to your Account, and send the password in a separate message. We send an export by email only if you ask for this from your registered number and accept that email is less secure. We delete our own working copies of an export within 7 days after we deliver it.

13.3 When your Account ends.

(a) If you close your Account, we delete all Patient Data in it within 30 days after we verify your request. Ask for an export first or with your request. We deliver the export before we delete.

(b) If we terminate your Account, or the Service ends, you may ask for an export within 30 days after that date. We delete all Patient Data no later than 30 days after that export period ends or, if you asked for an export, within 14 days after we deliver it, whichever is later.

13.4 Suspension. If we suspend your Account under the Terms, your Patient Data stays protected under this DPA. During the suspension, we will provide an export on request, unless the law prevents us.

13.5 Backups. Our database provider may keep backup copies of the database: [to be completed]. Copies of deleted Patient Data may remain in those backups until they are overwritten on the provider's rolling schedule. Until then, the backups remain protected under this DPA and are used only to restore the Service. If we ever restore a backup, we will delete again any Patient Data that you had asked us to delete. To do this, we keep a record of the identifiers (never the content) of deleted Patients, charts and Accounts until the backups that held them have been overwritten.

13.6 Legal retention. We may keep Patient Data for longer only where a law that applies to us requires it. We will then keep it protected under this DPA and use it only for the purpose that law requires. Section 15.10 describes our assessment of Egyptian retention law.

13.7 Your own records. Laws on clinical records often require dental professionals to keep records for a set period. You are responsible for keeping your own copies for as long as the law that applies to you requires. The Service is not a records archive. Ask for an export before you ask for deletion or close your Account.

13.8 What deletion covers. Deletion removes Patient Data from our database. It does not immediately reach:

(a) backup copies, which are handled under section 13.5;

(b) our Sub-processors' logs, such as Vercel's request logs (which may contain the address of a share link that was opened) and any phrase text kept by Groq. We cannot delete individual entries in those logs. They are removed when the Sub-processor's own retention period ends: for Vercel and Supabase, [to be completed]; for Groq, [to be completed]; or

(c) exports on your devices, links you have shared, the addresses of share links kept in browser histories, or charts that other users have imported from your links into their own Accounts.

Messages and files sent to us by WhatsApp or email are deleted as section 9.10 describes.

13.9 Confirmation. On request, we will confirm in writing that deletion is complete.

14. Information and audits

14.1 Information first. We will make available to you the information necessary to demonstrate our compliance with this DPA and with Article 28 of the GDPR. This consists of this DPA and its Annexes, and our written answers to a reasonable questionnaire about our processing of Patient Data. You may send us a questionnaire once in any 12-month period. You may also send one after a Personal Data Breach affecting your Patient Data, or when a supervisory authority asks you for the information.

14.2 Audits. You may audit our processing of your Patient Data, including by inspection, if:

(a) the information under section 14.1 is not enough to demonstrate our compliance;

(b) a supervisory authority requires the audit; or

(c) a Personal Data Breach has affected your Patient Data.

You may carry out the audit yourself or through an independent auditor who is bound by confidentiality and is not our competitor.

14.3 Conditions. Audits are subject to these conditions:

(a) you give us at least 30 days' notice in writing, or shorter notice if a supervisory authority requires it;

(b) we agree the scope, timing and method in advance, and the audit is carried out remotely where that is enough;

(c) any on-site part takes place during normal working hours in Egypt and avoids disrupting the Service;

(d) there is no more than one audit in any 12-month period, unless a supervisory authority requires another or a Personal Data Breach has affected your Patient Data;

(e) the audit does not give access to other customers' data, or to security details whose disclosure would put the Service or other customers at risk;

(f) the audit does not extend to our Sub-processors' premises or systems. For those, we will provide the information and reports that the Sub-processor makes available to us; and

(g) you bear the cost of the audit, including your auditor's fees and our reasonable costs of supporting it. We will estimate our costs for you in advance.

14.4 Results. You will keep the audit results confidential, except where you must share them with a supervisory authority. You will give us a copy of any audit report. We will remedy any failure to comply with this DPA that the audit identifies.

14.5 Authorities and SCCs. This section does not limit any power of a supervisory authority. Where the SCCs apply, their audit clause applies, and this section describes how audits under it are carried out.

15. International transfers

15.1 Where Patient Data goes.

(a) Patient Data is stored by Supabase, Inc. in [to be completed].

(b) It is processed by our server functions, which Vercel Inc. runs in the United States.

(c) We operate the Service from Egypt and may access Patient Data from there to run and support the Service.

(d) When the AI voice fallback is enabled, phrase text is sent to Groq, Inc., which is based in the United States, to be interpreted (section 9.5). Annex 3 says where Groq processes it.

(e) If Annex 3 lists a developer or contractor who builds and maintains the Service as an independent business, that developer or contractor may access Patient Data from the country shown there, only for that work (section 6.4).

Annex 3 gives the details. You authorise these transfers.

15.2 Transfers from the European Economic Area. This section applies where Patient Data subject to the GDPR is transferred to us in a country without an adequacy decision, and Data Protection Law requires a transfer mechanism. The SCCs are then incorporated into this DPA by reference and apply as follows:

(a) Module Two (controller to processor) applies where you are a controller. Module Three (processor to processor) applies where you are a processor;

(b) you are the data exporter and we are the data importer;

(c) Clause 7 (docking clause) does not apply;

(d) in Clause 9(a), Option 2 (general written authorisation) applies, with the notice period in section 8.4;

(e) the optional wording in Clause 11(a) does not apply;

(f) in Clause 13, the competent supervisory authority is the one competent for you as data exporter. If you are not established in the EEA but the GDPR applies to you, it is the authority of the Member State where your representative under Article 27 of the GDPR is established. If you do not need such a representative, it is the authority of a Member State where the Patients concerned are located;

(g) in Clause 17, the SCCs are governed by the law of the EU Member State where you are established. If you are not established in the EEA, or that law does not allow for third-party beneficiary rights, they are governed by the law of Ireland;

(h) in Clause 18(b), disputes are resolved by the courts of the Member State whose law governs under paragraph (g); and

(i) Annex I of the SCCs is completed by Annex 1 of this DPA, Annex II by Annex 2, and Annex III by Annex 3.

Where the SCCs apply, you must give us your organisation's name, address and contact details, and those of your data protection officer if you have one. They complete Annex 1, Part A.

15.3 Onward transfers. Where a transfer of Patient Data by us to a Sub-processor in another country requires a transfer mechanism under Data Protection Law, we will make sure one is in place, such as the SCCs in the Sub-processor's data processing terms.

15.4 Switzerland. For transfers subject to the FADP, the SCCs apply as described in section 15.2 with these changes:

(a) references to the GDPR are read as references to the FADP, as far as the transfer is subject to it;

(b) the Swiss Federal Data Protection and Information Commissioner is the competent supervisory authority for those transfers; and

(c) "Member State" in Clause 18(c) includes Switzerland, so that data subjects in Switzerland can bring claims where they habitually reside.

15.5 United Kingdom. For transfers subject to the UK GDPR, the UK Addendum is incorporated into this DPA by reference. Its tables are completed as follows:

(a) Table 1: the parties' details in Annex 1;

(b) Table 2: the modules and options in section 15.2;

(c) Table 3: Annexes 1 to 3 of this DPA; and

(d) Table 4: neither party may end the UK Addendum under its Section 19.

15.6 Egypt. We hold any licence or permit that the Egyptian PDPL requires of us for the transfers we make (section 3.4(g)). You are responsible for any consent, licence or permit that your own processing requires.

15.7 Other countries. Other countries may also restrict sending health data abroad. You are responsible for checking that the law that applies to you allows the transfers described in section 15.1 (section 16.8).

15.8 If a mechanism stops working. If a transfer mechanism stops being valid, we will work with you to put a valid alternative in place. If that is not possible, either of us may end this DPA and the Terms for the affected processing, and section 13 applies.

15.9 Precedence. If the SCCs or the UK Addendum conflict with this DPA, the SCCs or the UK Addendum prevail.

15.10 Transfer assessment. We have assessed the laws and practices of Egypt and the United States that apply to the transfers in section 15.1, including Egypt's Law No. 175 of 2018 on Anti-Cyber and Information Technology Crimes, as Clause 14 of the SCCs requires. [to be completed]. We will give you or a supervisory authority a copy on request.

16. Your obligations as controller

16.1 Lawful basis. You are responsible for the lawfulness of the processing of Patient Data in the Service. Before you enter Patient Data, you must have a lawful basis for processing it. Because it is health data, you must also have a condition that allows the processing of special categories of personal data.

(a) Under the GDPR, this may be Article 9(2)(h) together with Article 9(3) (the provision of health care by a professional bound by a duty of secrecy), or the Patient's explicit consent.

(b) Under the Egyptian PDPL, processing health data generally requires the Patient's explicit written consent, unless the law provides otherwise. Children's data is treated as sensitive data.

(c) You must meet any rules of the law that applies to you on Patients who are children, such as consent from a parent or guardian.

16.2 Informing Patients. You must give your Patients the information that Data Protection Law requires. This includes telling them that you use PerioSync to record their periodontal information, and where it is stored and processed (Annex 3). If you use voice dictation, you must also tell them:

(a) that a microphone is used during the examination and may pick up voices in the room, including theirs;

(b) that your browser's maker may process the audio to turn it into text; and

(c) that, where the AI voice fallback is enabled for your Account, the text of some phrases may be sent to Groq, Inc., which is based in the United States, to be interpreted. You can ask us whether it is enabled (section 9.5).

16.3 Enter only what you need. You must limit the Patient Data you enter to what you need. In particular, you must:

(a) identify Patients by your own reference rather than by name wherever you can, and enter a name or date of birth only when you need it;

(b) not put names, phone numbers, identity numbers, addresses or other identifying details in the diagnosis note, because the note travels in share links, and not add them to any share link;

(c) avoid speaking a Patient's name or other identifying details while dictating;

(d) not send Patient Data to us by WhatsApp, email, the support form or a credit-request note; and

(e) not record information that is unrelated to the Patient's dental care.

16.4 People using your Account. Each Account is for one person (Terms, section 5.2). You must not share your password, including with colleagues. Staff or students may operate the Service for you only under your direct supervision while you are signed in. Anyone signed in to your Account can see all the Patient Data in it, and the Service does not offer separate staff logins or two-factor authentication. You must:

(a) let only people who are entitled to see the Patient Data, and who are bound by confidentiality, operate the Service under your supervision;

(b) keep your password secret, use a password you do not use anywhere else, and change it if you think someone else knows it;

(c) sign out of shared devices, and regularly review the list of signed-in devices in the app; and

(d) tell us promptly if you suspect misuse of your Account (section 12.7).

You are responsible for what anyone using your Account does, as if you had done it yourself.

16.5 Devices and copies. You are responsible for the security of the devices and browsers used to access the Service. You are also responsible for any export, printout or share link once it leaves the Service.

16.6 Your local law. You must comply with the law that applies to your practice. This includes professional secrecy, rules on clinical records and how long they must be kept, any registration, licence or permit you need as a controller, and any rules on using cloud services or artificial intelligence for health data.

16.7 HIPAA. We do not offer Business Associate Agreements, and nothing in this DPA or the Terms is one. If you are a covered entity or a business associate under the US Health Insurance Portability and Accountability Act (HIPAA), you must not use the Service to create, receive, maintain or transmit protected health information, unless we have signed a Business Associate Agreement with you in writing (Terms, section 4.6).

16.8 Data localisation. Some laws require health data to stay in the country, or restrict its transfer abroad. Examples are the UAE's Federal Law No. 2 of 2019 on the use of information and communications technology in health fields, and Saudi Arabia's Personal Data Protection Law. Before you enter Patient Data, you must confirm that the law that applies to you allows it to be stored and processed in the locations listed in Annex 3. If it does not, you must not use the Service for Patient Data.

16.9 Lawful Instructions. Your Instructions must comply with Data Protection Law.

16.10 Clinical responsibility. You are responsible for the accuracy of the Patient Data you enter and for every clinical decision. You must check calculated values and any suggested diagnosis, as the Terms explain.

16.11 Your responsibility for claims. You will reimburse us for reasonable losses and costs (including reasonable legal costs) and, to the extent the law allows them to be passed on, fines and penalties, that we incur because of a claim by a Patient or other third party, or action by a supervisory authority, to the extent it is caused by your breach of this section 16 or by an Instruction of yours that infringes Data Protection Law.

17. Liability

17.1 The exclusions and limits of liability in the Terms apply to all liability arising out of or in connection with this DPA. This includes liability between you and us under the SCCs or the UK Addendum, as far as they permit. The Terms and this DPA are one agreement for this purpose: the limits in the Terms, including the maximum amount in section 22.3 of the Terms, apply once, in total, across both.

17.2 Nothing in this DPA or the Terms limits or excludes:

(a) liability for fraud or gross fault, or any other liability that cannot be limited or excluded by law, including under Article 217 of the Egyptian Civil Code;

(b) the rights of a data subject under Data Protection Law, including Article 82 of the GDPR, or under the SCCs or the UK Addendum; or

(c) the powers of a supervisory authority.

17.3 Where both of us are responsible for damage caused to a data subject, then, as between you and us, each of us bears the part of the compensation that corresponds to its share of responsibility, as Article 82(5) of the GDPR provides. Any amount you claim from us under this section is subject to, and counts towards, the limits in section 17.1, except where the law does not allow this. This section does not affect any data subject's right to claim full compensation from either of us.

17.4 A fine imposed by a supervisory authority on one of us can be recovered from the other only to the extent the law allows and the fine was caused by the other's breach of this DPA.

18. Order of precedence

18.1 If these documents conflict, they apply in this order:

(a) the SCCs and the UK Addendum, where they apply;

(b) this DPA;

(c) the Terms; and

(d) our other policies, including the Privacy Policy and the Refund Policy.

18.2 This order applies only to the processing of Patient Data. On all other matters, the Terms prevail over this DPA. The Privacy Policy describes how we handle Account holders' personal data. It does not change your obligations or ours about Patient Data.

19. Term, termination and changes

19.1 Term. This DPA starts when you accept the Terms. It continues for as long as we process Patient Data for you, including in backups until they are overwritten, and then ends automatically.

19.2 No separate termination. You cannot end this DPA separately from the Terms while Patient Data remains in your Account. If the Terms end, this DPA continues until all Patient Data has been deleted under section 13.

19.3 Continuing duties. Our duties of confidentiality, security and deletion continue for as long as we hold any Patient Data.

19.4 Changes. We may update this DPA, for example to reflect changes in the law, in the Service or in guidance from supervisory authorities. Changes to the list of Sub-processors follow section 8 instead.

(a) We will give you at least 30 days' notice of a material change, in the app or by WhatsApp or SMS to your registered mobile number, as for the Terms (Terms, section 27). We will ask you to accept the new version the next time you open the app on or after the date it takes effect.

(b) We may give shorter notice where the law requires a change sooner.

(c) A change will not reduce the overall protection this DPA gives to Patient Data, unless the law requires it.

(d) If you do not agree to a change, you may stop using the Service for Patient Data and ask for export and deletion under section 13. If you close your Account for that reason within 30 days after the change takes effect, Credits are dealt with as stated in section 7.5 of the Refund Policy at /refunds and section 27.4 of the Terms.

(e) A new version applies to you once you accept it in the app. Until then, the version you last accepted continues to apply, except for changes that the law requires, which apply from the date stated in our notice.

19.5 Transfer of the Service. If the Service is transferred to another person or company, we may transfer this DPA to them, provided they agree in writing to be bound by it. We will tell you at least 30 days before the transfer. If you do not want the new operator to process your Patient Data, you may ask for export and deletion under section 13 before the transfer takes place.

19.6 If we cannot continue. If we become unable to run the Service, for example because of death, serious illness or incapacity, [to be completed] is authorised to act for us under this DPA. That person will keep Patient Data secure, offer every Account holder an export under section 13.2 for at least 30 days, and then delete the Patient Data under section 13.

20. Notices and contact

20.1 To us. Send requests, objections and notices under this DPA:

• by email to munyashraf99@gmail.com; or
• by WhatsApp to +20 112 569 2017 or +20 103 044 9593.

Our postal address is [to be completed].

20.2 Our representatives.

• Representative in the European Union under Article 27 of the GDPR: [to be completed]
• Representative in the United Kingdom under Article 27 of the UK GDPR: [to be completed]

20.3 To you. The Service does not send email. We will give you notices under this DPA in the app or by WhatsApp or SMS to the mobile number registered to your Account. We will also use email if you have given us an email address. A notice shown in the app is received when it is first shown to you. A WhatsApp message or SMS is received 24 hours after we send it, unless we learn that it was not delivered or that the number is no longer yours. An email is received 24 hours after we send it, unless we learn that it was not delivered.

21. General

21.1 Governing law. This DPA is governed by the law, and subject to the courts, named in the Terms: the law of Egypt and the courts of Cairo. There are two exceptions:

(a) the SCCs and the UK Addendum are governed by the law, and subject to the courts, set out in them and in section 15; and

(b) mandatory Data Protection Law applies wherever it cannot be excluded.

Nothing in this DPA prevents a data subject from complaining to a supervisory authority or going to court where Data Protection Law allows.

21.2 Severability. If a court or authority finds any part of this DPA invalid or unenforceable, that part applies to the greatest extent the law allows. The rest of this DPA continues to apply.

21.3 Language. This DPA is written in English. If it is translated, the English text governs.

21.4 Third parties. No one other than you and us has rights under this DPA, except data subjects as provided by the SCCs, the UK Addendum or Data Protection Law.

21.5 Entire agreement. This DPA, together with the Terms, is the whole agreement between you and us on the processing of Patient Data. It replaces any earlier terms on that subject.

Annex 1: Description of the processing

A. The parties

B. Categories of data subjects

• Patients of the data exporter, including children where the data exporter treats them.
• Clinicians and other staff named in a chart, including in its free-text notes.
• Any other person the data exporter mentions in a free-text field, such as a referring dentist or a family member.
• People whose words are picked up during dictation, as far as the text of their words is sent for interpretation under section 9.5.

C. Categories of personal data

• Patient record: the data exporter's own reference for the Patient (required); and, optionally, full name, date of birth and a note of up to 500 characters.
• Chart:
  • the date and time the chart was started (recorded automatically), and the name of a clinician on charts that have one (printed charts show the Account holder's name);
  • periodontal measurements and findings: probing depth, gingival margin, bleeding on probing, plaque, suppuration, calculus, keratinised gingiva width, mobility, furcation, implants, missing teeth, and other optional measurements and indices offered in the Service;
  • tooth notes of up to 500 characters each;
  • diagnosis: status, stage, grade, extent and a note of up to 300 characters, which may describe systemic factors; and
  • values calculated by the Service, such as clinical attachment level, percentages, summary indices and comparisons between visits.
• Voice phrase text (only when the AI voice fallback is enabled): the text of a phrase (up to 500 characters), up to five alternative readings, and the tooth, side and measurement being charted.
• Share link content, when a link is opened in the Account: chart readings and the diagnosis, including the diagnosis note. Never the Patient's name, reference, date of birth or tooth notes.
• Support messages and credit-request notes: any information about a Patient that the data exporter includes in a message to us or in a credit-request note, contrary to section 16.3(d).

D. Special categories of data (sensitive data) and safeguards

Patient Data is health data. It is a special category of personal data under Article 9 of the GDPR and the UK GDPR, and sensitive data under the Egyptian PDPL. Notes and diagnoses may also reveal other health conditions.

Safeguards applied:

• the measures in Annex 2;
• access limited to people who need it and are bound by confidentiality (section 6);
• no use of Patient Data for any purpose of our own (section 4.6);
• administration screens that open a chart only read only, only for the purposes in section 6.3, and record every opening in the audit log;
• share links that never carry the Patient's name, reference, date of birth or tooth notes;
• no receipt of audio by us; and
• deletion on request and at the end of the Account (section 13).

E. Frequency of the transfer

Continuous, for as long as the data exporter uses the Service.

F. Nature of the processing

As described in section 4.3.

G. Purposes of the processing

As described in section 4.4.

H. Retention

Patient Data is kept for as long as the Account exists, unless the data exporter asks us to delete it sooner. It is deleted as described in section 13. Backup copies are overwritten as described in section 13.5. Phrase text sent for interpretation is not saved in our database. Copies in our Sub-processors' logs, and any phrase text kept by Groq, are removed when the Sub-processor's own retention period ends (section 13.8).

I. Transfers to Sub-processors

The subject matter, nature and duration of each Sub-processor's processing are as described in Annex 3, Part A, for as long as the data exporter uses the Service.

J. Competent supervisory authority

• For transfers under the GDPR: as set out in section 15.2(f).
• For transfers under the FADP: the Swiss Federal Data Protection and Information Commissioner.
• For transfers under the UK GDPR: the UK Information Commissioner.
• Under the Egyptian PDPL: the PDPC.

Annex 2: Technical and organisational measures

These are the measures in place for the Service. Part 11 lists measures the Service does not have.

1. Encryption in transit

• Every connection to the Service uses HTTPS.
• HTTP Strict Transport Security instructs browsers to connect to the Service only over HTTPS.

2. Encryption at rest

• Patient Data is stored in our database provider's database. The provider encrypts its disks at rest using its standard encryption.
• We do not add a further layer of encryption to individual fields of Patient Data (see Part 11).

3. Sign-in and sessions

• Passwords are stored only in hashed form by our authentication provider, Supabase Auth. When you sign up, sign in or change your password, the password passes through our server only to be handed to Supabase Auth. We do not store or log it.
• If you cannot sign in, an administrator can set a temporary password after checking your request over WhatsApp (section 12.7). The administrator sees that password and sends it to you by WhatsApp. Setting it does not sign out devices that are already signed in, and the Service does not force you to change it. Change it in the app as soon as you sign in. This signs out your other devices. Each temporary password set through our administration screens is recorded in the audit log. The password itself is not recorded.
• Sign-in cookies cannot be read by scripts on the page and are sent only over secure connections.
• The server checks the session on every request.
• You can see your signed-in devices and sign them out, and changing your password signs out your other devices. A signed-out device can no longer use the Service. Signing out does not cancel the sign-in tokens that our authentication provider issued to that device, but the Service refuses them. After verifying a request, we can also sign out an Account's devices by a manual operation on our database.
• Each Account may be signed in on a limited number of devices. Signing in on one device too many signs out the device used least recently.

4. Access to Patient Data

• Every request for Patient Data is checked against the Account that owns it. A request for another Account's chart is answered as if the chart did not exist.
• The Service's server reads and writes Patient Data with a privileged database key that is not subject to row-level security. The per-Account check described above is therefore the control that applies to every request made through the Service. Separately, row-level security rules and restricted table permissions stop anyone using a lower-privileged database key from reading another Account's rows or writing to any table.
• Our administration screens show Account details, counts, credit requests and support messages, and can open a chart read only for a purpose in section 6.3; every opening is logged. A support message or credit-request note shows any Patient information written in it (section 6.3).
• Direct database access is limited as described in section 6.

5. Protection against abuse

• Rate limits apply to repeated failed attempts to sign in, sign up or change a password, and to repeated payments, credit requests, support messages and AI voice requests.
• The Service applies usage limits, including a monthly allowance for AI voice interpretation.

6. Application security

• A strict Content Security Policy lets the Service load content only from our own website and our database provider.
• Other websites cannot display the Service inside a frame.
• The Service loads no third-party scripts and uses no analytics, advertising or social media cookies. Fonts are hosted by us.

7. Data minimisation in the design

• The Patient's reference is the only required identifier. Name and date of birth are optional.
• Share links never carry the Patient's name, reference, date of birth or tooth notes. We do not save share links in our database.
• PDF, PNG and printed charts are created in the user's browser. We do not receive a copy.
• The Service's own browser storage, listed at /cookies, holds no Patient Data.
• A share link carries chart readings and the diagnosis note in its address. A browser that opens one keeps that address in its history, like any other page. The Service cannot remove it.
• We never receive audio. Phrase text sent for AI interpretation is limited as described in section 9.5, carries no Patient or Account identifiers added by us, and is not saved in our database.

8. Administration and accountability

• Administrator actions taken through our administration screens, such as approving or declining credit requests, setting temporary passwords, resetting devices, granting plans and changing settings, are recorded in an audit log showing who acted, what they did and when. Part 11 says what the audit log does not record.
• Payment card details are entered on payment providers' hosted pages and never reach our servers.

9. People

• Confidentiality commitments and need-to-know access, as described in section 6.
• No third-party tools are given access to Patient Data, as described in section 6.5.

10. Availability, backups, incidents and review

• The Service runs on managed infrastructure provided by our Sub-processors (Annex 3).
• Backups: [to be completed].
• Personal Data Breaches are handled as described in section 12.
• Sub-processors are engaged as described in section 8.
• We review these measures when the Service changes significantly, and at least once a year. We keep a dated record of each review.

11. Measures the Service does not have

So that you can assess the risks properly (section 7.2), we state the following plainly:

• No field-level encryption. Patient Data is stored as readable data inside the provider's encrypted disks. Anyone with database-level access, including us, can read it.
• No two-factor authentication. Sign-in uses a mobile number and a password only. This applies to administrator accounts too.
• No mobile number verification. We do not verify that a mobile number belongs to the person who signs up with it.
• No verified account recovery. If you cannot sign in, recovery is handled by a person over WhatsApp. Control of the registered mobile number, which is never verified, is the main proof of identity.
• No forced change of temporary passwords. A temporary password set by an administrator stays valid until you change it. Setting it does not sign out devices that are already signed in.
• Administrator powers. An administrator can set a temporary password for any Account.
• No separate staff logins. Each Account has a single sign-in, and there are no per-user roles or permissions inside an Account.
• No self-service deletion or correction of Patient records. Patients, charts and Accounts are deleted, and Patient records are corrected, by us on request (sections 10.2 and 13).
• No edit-conflict detection. If the same chart is open on two devices or tabs, the last save replaces the other. Open each chart in one place at a time.
• No log of access to Patient Data. The audit log records administrator actions taken through our administration screens (Part 8). It does not record who viewed Patient Data. It also does not record actions taken directly in the database, such as exports, deletions or corrections we carry out on request (sections 10 and 13).
• No revocable share links. Share links cannot be withdrawn and do not expire.
• No independent certification. The Service has not been independently audited or certified to any security or data protection standard. It is not certified as compliant with HIPAA or any similar scheme.
• No guaranteed availability. There is no service level commitment. The Service needs an internet connection and does not keep Patient Data on your device for offline use.

Annex 3: Sub-processors and other recipients

Last updated: [to be completed]

Part A: Sub-processors

Contracts and transfer safeguards with these Sub-processors (sections 8.2 and 15.3): [to be completed]

Account holder for these services: [to be completed]

Part B: Services you choose (not our Sub-processors)

These services handle data because you choose to use them. They act under their own terms, not on our behalf.

Banks, payment apps and payment providers (InstaPay, Telda, mobile wallets and, where online payment is offered, Fawaterak and Paymob) receive payment details about Account holders. They receive no Patient Data and are not Sub-processors under this DPA. Our Privacy Policy at /privacy describes them.

Related documents:

• Terms of Service: /terms
• Privacy Policy: /privacy
• Cookie Policy: /cookies
• Refund Policy: /refunds