Privacy Policy

PRIVACY POLICY

Transcribe Health Corporation

Effective Date: December 1, 2024 Last Updated: January 6, 2027

1. INTRODUCTION AND ACCEPTANCE

This Privacy Policy ("Policy") constitutes a legally binding agreement between you and Transcribe Health Corporation, a corporation incorporated under the federal laws of Canada ("Transcribe Health," "Company," "we," "us," or "our"), governing the collection, use, disclosure, and protection of information through our AI-powered medical transcription and clinical documentation platform, including all associated services, software, applications, APIs, and websites (collectively, the "Services").

BY ACCESSING OR USING THE SERVICES, YOU EXPRESSLY ACKNOWLEDGE THAT YOU HAVE READ, UNDERSTOOD, AND AGREE TO BE LEGALLY BOUND BY THIS POLICY. IF YOU DO NOT AGREE, YOU MUST IMMEDIATELY DISCONTINUE ALL USE OF THE SERVICES.

2. SCOPE, APPLICABILITY AND COVERED ENTITY RELATIONSHIPS

This Privacy Policy is NOT a Notice of Privacy Practices (NPP). When Transcribe Health processes Protected Health Information, it does so as a Business Associate on behalf of a healthcare provider (the Covered Entity). The HIPAA Notice of Privacy Practices that describes how medical information about a patient may be used and disclosed, and how a patient can access that information, is issued by the patient's own healthcare provider, not by Transcribe Health. Patients should obtain the NPP from their healthcare provider. This Policy explains how Transcribe Health, as a service provider to those providers, handles information.

2.1 Scope of Application

This Policy applies to all interactions with our Services by:

• Licensed healthcare providers and medical professionals
• Healthcare organizations, clinics, hospitals, and medical facilities
• Patients whose information is processed through our Services
• Business associates and third-party integrators
• Visitors to our websites and applications
• Employees and contractors of covered entities

2.2 HIPAA Business Associate Status

When we process Protected Health Information ("PHI") on behalf of Covered Entities or other Business Associates, we function as a Business Associate under HIPAA. We maintain executed Business Associate Agreements ("BAAs") with all applicable clients, which supersede this Policy to the extent of any conflict regarding PHI handling. For clinics in Ontario, Alberta and British Columbia, we act as the clinic's agent, information manager or service provider under Schedule D of our Data Processing Agreement, which replaces the BAA for those clinics.

2.3 Jurisdictional Coverage

This Policy applies globally, with specific provisions for:

• United States: HIPAA, HITECH Act, state medical privacy laws
• European Union/EEA: GDPR compliance
• Canada: PIPEDA and provincial privacy legislation
• Other jurisdictions: Local data protection laws as applicable

3. DEFINITIONS

For purposes of this Policy:

• "AI Systems" means our proprietary and licensed artificial intelligence, machine learning, and natural language processing technologies
• "Aggregate Data" means data that has been combined and analyzed in a way that individual patients cannot be identified
• "Business Associate" has the meaning defined under HIPAA
• "Clinical Documentation" means medical notes, transcriptions, summaries, and related healthcare records
• "Covered Entity" has the meaning defined under HIPAA
• "De-identified Data" means data that has been processed to remove all 18 HIPAA identifiers
• "PHI" or "Protected Health Information" has the meaning defined under HIPAA
• "Personal Information" means any information relating to an identified or identifiable natural person
• "Voice Data" means audio recordings, voice patterns, and acoustic characteristics

4. INFORMATION WE COLLECT

4.1 Healthcare Provider Information

• Professional credentials (NPI numbers, DEA numbers, medical licenses, board certifications)
• Practice information (specialty, affiliations, hospital privileges)
• Authentication credentials and security tokens
• Voice recordings for transcription
• Usage patterns and preferences
• Billing and payment information

4.2 Patient Health Information

• Demographic information (name, date of birth, contact details)
• Medical record numbers and identifiers
• Clinical encounter audio recordings
• Medical history, diagnoses, treatments, and medications
• Laboratory results and imaging reports
• Insurance and billing information
• Care plans and clinical notes

4.2.1 Online Appointment Booking (Collected Directly From Patients)

Where a healthcare practice enables online appointment booking, we collect a patient's first and last name, date of birth, and email address or phone number directly from the patient, through the practice's public booking page or a booking link the practice sends to the patient. We collect this information solely to schedule the requested appointment with that practice, and it becomes part of the patient record that practice controls; we process it only as the practice's service provider (and, where it constitutes PHI, as its HIPAA Business Associate). The booking surface is protected against abuse (per-visitor rate limits and per-practice booking caps), and contact details are hashed in our audit logs rather than recorded there in cleartext. Each practice controls whether online booking is available; the feature is disabled unless the practice enables it.

4.2.2 Patient Forms and Questionnaires (Collected Directly From Patients)

Where a healthcare practice uses our patient forms feature, the practice sends a patient a secure link so the patient can fill in intake forms, consent forms, screening questionnaires, or the practice's own forms before or outside a visit. The practice decides which forms to send and to whom, and it writes or chooses every question, including when it starts from one of our templates. We collect the answers directly from the patient on the practice's behalf, only as its service provider (and, where the answers are PHI, as its HIPAA Business Associate). The practice, not Transcribe Health, decides why the information is collected and is responsible for having a lawful basis to collect it.

What we collect through a form:

• Answers. These can include health history, symptoms, medications, allergies, answers to mental health screening questionnaires (for example the PHQ-9, PHQ-2 and GAD-7, which include questions about mood and, in the PHQ-9, about thoughts of self-harm), and anything else the practice's own questions ask for.
• Scores and flags. For standard screening questionnaires we calculate a total score and a severity band. We also flag answers that match rules built into a questionnaire or set by the practice. Any answer above zero to the PHQ-9 question about thoughts of self-harm is always flagged for the practice to review. Scoring is done on our servers when the form is submitted. See § 5.6.
• Consent and signature records. When a form asks for consent or a signature, we record the consent wording shown, the signer's name and drawn signature, the date and time, the version of the form, and one-way hashes (not the raw values) of the IP address and browser details used to sign.
• Completed PDFs. Where the practice uses its own PDF form, we fill the practice's PDF with the patient's answers and store the completed copy.
• Draft answers. Answers are saved automatically while the patient fills in a form, so the patient can close the page and finish later from the same link.
• Security records. We record when the link was opened, the result of each date-of-birth check that protects the link, and when each form was started and submitted. These records never contain the answers.

How it is protected. Before any form is shown, the patient must confirm their date of birth. Five wrong attempts lock the link until the practice reopens it. Answers, drafts, signer names, drawn signatures and completed PDFs are encrypted at rest with a key specific to the practice. The message that carries the link names only the practice; it never includes the patient's name, the names of the forms, or any health details, and answers are never sent by email or text message. Messages respect the patient's messaging consent, opt-outs and the practice's quiet hours; a link sent outside a booked visit requires the patient's express consent to be contacted on that channel. The forms page is not indexed by search engines, sets no tracking cookies, and does not store answers in the patient's browser. Once a form version is published it cannot be changed, so the exact wording a patient saw can be shown later.

How the answers are used. Submitted answers, scores, flags and completed PDFs go into the practice's patient record in the Services, where authorized staff of that practice can see them. Viewing and exporting a response are recorded in our audit log. Where a form is linked to a visit, its answers and scores are also included in the information our AI features use to draft the clinical note for that visit. That use follows the same AI processing, subprocessors and per-organization data-residency setting described in § 5 and § 8.2.1, and every AI-drafted note is reviewed by a clinician (§ 5.6). We do not use form answers to train AI models, for marketing, or for any purpose of our own, and we do not sell or share them.

Payment card information. The forms feature is not designed or secured for payment card information, and practices may not use it to collect card numbers, security codes or other payment card data.

Patient requests. Because the practice controls this information, a patient who wants to see, correct or delete their form answers, or to withdraw a consent given on a form, should contact the practice. See § 12.6. The practice's own Notice of Privacy Practices or privacy notice governs how it uses the information.

4.2.3 Phone Calls Answered by Dorvi (Collected Directly From Callers)

Where a healthcare practice forwards its phone line to Dorvi, Dorvi answers calls for the practice: it answers questions about the practice from the information the practice provides, takes messages for the practice's staff and, where the practice allows it, books, moves and cancels appointments. We collect the information below directly from callers on the practice's behalf. The practice is the organization responsible for it (the controller under GDPR, the covered entity under HIPAA, and the organization or enterprise responsible under PIPEDA, Quebec Law 25 and provincial law), and it decides why the information is collected; we process it only as the practice's service provider (and, where it is PHI, as its HIPAA Business Associate). Each practice decides whether Dorvi answers its line and whether callers can book by phone; both are off unless the practice turns them on.

Notice at the start of every call. Every call Dorvi answers opens with a notice, played before the caller is heard: an automated assistant is answering, what the caller says is transcribed so the assistant can answer and the practice can follow up, and the call is not recorded. Where the practice has a staff line, the notice also says the caller can ask for a person. A caller who does not want what they say kept can say so at any time; from then on nothing the caller says is kept, except a message for the practice if the caller chooses to leave one.

What we collect:

• What the caller says, as text. Speech is transcribed as the caller talks by speech models we run in our own Canadian infrastructure, and Dorvi's spoken answers are produced there too. The audio of the call is never recorded or stored. The text of the conversation is held only while the call lasts, and no transcript of the call is kept.
• The caller's phone number, in protected form. We do not store the number shown by caller ID. We keep a keyed one-way hash of it and its last four digits, which is all the practice sees of it. Where the carrier fully verifies the caller ID and it matches exactly one patient of the practice, we also link the call to that patient's record. The link helps the practice; it never proves who is calling.
• Identity check. Before Dorvi shares or changes anything about a patient, the caller gives their full name and date of birth, which our systems check against the patient record linked to the call. A caller has three failed attempts per call, and one number six failed attempts in 24 hours across the practice's calls. The answer is the same whether or not the number belongs to a patient, so a caller cannot learn who is a patient of the practice. A caller who speaks for someone else cannot be verified as that person; Dorvi takes a message instead.
• Messages. When a caller wants a callback, or asks for something Dorvi cannot do, Dorvi takes a message: the caller's name, a callback number, what the call is about, how urgent it is and the best time to call. Dorvi reads the message back and sends it only after the caller says yes. The message becomes a task for the practice's staff, and a one-line summary is kept on the call record.
• Appointments. Where the practice turns on booking by phone, a caller who has passed the identity check can hear their upcoming appointments and book, move or cancel their own appointment within the rules the practice sets. Dorvi reads each change back and makes it only after the caller says yes. A change the rules do not allow becomes a task for the practice's staff to call the caller back.
• Call record. When the call came in, how it was routed, its outcome (for example, a message, a booking or a transfer to staff), its length, whether the practice was open, which version of the notice the caller heard, and whether the call involved an emergency or an objection to the transcript.

New patients booking by phone. Where a practice lets new patients book by phone, Dorvi can book a first appointment for a caller who is not yet a patient of that practice. To do so we collect the caller's first and last name, date of birth and phone number directly from the caller, with the visit type and time they choose, and Dorvi reads the booking back and makes it only after the caller says yes. We collect this information solely to schedule the requested appointment with that practice, and it becomes a new patient record that the practice controls. Booking as a new patient gives the caller no access to any existing record. Each practice controls whether new patients can book by phone; it is off unless the practice turns it on.

Text messages. When a caller leaves a message, we text the callback number they gave a confirmation that names the practice and when to expect the call, never the reason for the call. That text is sent only to a number in the practice's country that can receive texts. After a booking, change or cancellation by phone, we text a confirmation to the phone number on the patient's record, with a link to manage the appointment when one was booked or moved. We send these texts because the caller asked for the callback or the appointment, and never to a number that has replied STOP to the practice or to us.

Emergencies. Everything a caller says is checked against a fixed list of emergency phrases (for example chest pain, trouble breathing, signs of a stroke, severe bleeding, an overdose, or thoughts of suicide or self-harm) before any AI processing. On a match, Dorvi gives a fixed instruction to call the emergency number of the practice's country (and, for suicide or self-harm in Canada and the United States, to call or text 988), which is always played in full. Where the practice has a staff line, Dorvi then offers to connect the caller to staff. Dorvi also files an urgent task for the practice.

No medical advice by phone. Dorvi is not intended to give callers medical advice, diagnoses, dosing instructions, test-result interpretations, urgency judgments or self-care advice. Its automated safeguards are designed to check responses and withhold this kind of advice, but they can miss it or make mistakes. Dorvi can offer to pass a medical question to the practice for a clinician to address. For medical advice, contact a qualified healthcare professional; in an emergency, contact emergency services.

Who receives it. The practice's staff, through the practice's calls inbox and task board, which only staff the practice allows to see calls can open; every view is recorded in our audit log. For an urgent message or a possible emergency, the practice's on-call staff member can also be texted that something urgent is waiting, with no caller details. What the caller says is processed by Dorvi as described in § 5.2, and our telephone carrier connects the call and delivers the texts (§ 8.2). Where the practice enables phone booking, Dorvi may book, move or cancel an appointment within the practice's rules after the caller confirms the change. Dorvi is not intended to make clinical decisions; it may offer to pass other requests to the practice's staff.

What we are responsible for. Transcribe Health is the controller only for the limited processing we carry out to protect the service and meet our own obligations: limits on how many calls and texts one number can make or receive (counted against the hashed number), the list of numbers that replied STOP, our security audit records (which hold identifiers and the hashed number, never the number itself or what was said), and the call minutes that measure the practice's use.

Practice staff numbers. A staff member can add their own mobile number to be texted about urgent calls. We first text a code to confirm the number is theirs, and we delete the number when they remove it or their account is deleted. It is handled like the rest of the staff member's account data.

Patient and caller requests. Because the practice controls this information, a caller who wants to see, correct or delete it should contact the practice. See § 12.6. How long each part is kept is set out in Section 10.1.

4.3 Voice and Audio Data

• Real-time audio streams from clinical encounters
• Recorded consultations and medical dictations
• Voice characteristics for speaker separation
• Acoustic metadata (quality, duration, timestamps)
• Environmental audio context (with consent)
• Browser-extension audio capture: where you install our Chrome extension, clinical-encounter audio is captured in the browser. When a recording finishes, the extension first saves it on your device, encrypted (AES-256) with a key that our servers derive for your account and that browser profile. The extension holds that key only in the browser's session memory, which is cleared whenever you sign out or the browser restarts. The extension then sends the recording to our Canadian backend over an encrypted (TLS) connection, and deletes the copy on your device once our backend confirms the upload. If a recording has not been uploaded when you sign out, you choose whether to keep it until you sign back in, upload it now, or delete it. If your session ends automatically, for example after a period of inactivity, the extension tries once to upload it and otherwise keeps it. A kept recording can be decrypted only after the same user signs in again in that browser profile. It is deleted no more than 72 hours after it was recorded; the extension applies this limit while the browser is running, so a recording that reaches 72 hours while the browser is closed is deleted the next time the browser runs.
• Chrome Web Store Limited Use: our use and transfer of information obtained through our Chrome extension comply with the Chrome Web Store User Data Policy, including the Limited Use requirements. We use that information only to provide the clinical documentation features described in this Policy and to keep them secure and reliable. We do not sell it, and we do not use or transfer it for personalized advertising or to determine creditworthiness or for lending purposes.
• On-device copy of visit audio (web and desktop apps): when you record a visit in the web app or the desktop app, the app keeps an encrypted copy of the visit audio on your device until our servers confirm they have received it, so that a dropped connection, a failed upload, or a browser tab that is closed or crashes does not lose the visit. If the upload has not finished, the app sends it, or asks whether you want to upload or discard the recording, the next time you open the app. The copy is encrypted on your device (AES-256) with a key that is kept in the app's storage on that device and cannot be exported from it. The copy is deleted as soon as the upload succeeds, when you discard the recording, and when you sign out (signing out also deletes the encryption keys). In any case, it is kept for no more than 7 days from the start of the recording: the app deletes older copies whenever it is open, so a copy that reaches 7 days while the app is closed is deleted the next time you open the app. In the desktop app, the copy is kept in memory only: it survives reloading the page or closing the window, but not quitting the app. The copy is not sent anywhere other than to our servers, as that upload. How long uploaded audio is kept is set out in Section 10.1.
• Global dictation: when you dictate into a text field in the web app, desktop app, or Chrome extension, we collect the audio of your dictation (up to 3 minutes), the text it produces, and a record of the dictation (for example, the app you dictated from and whether it succeeded). To make the transcription more accurate, we also collect up to 1,000 characters of the text already in that field around your cursor. That text may include patient information (PHI). We use it only to help our speech models transcribe your dictation correctly; we never keep it in your dictation history, and we delete it when transcription finishes (in all cases within about 20 minutes). Dictation is processed by speech models we run in our own Canadian infrastructure. How long each of these is kept is set out in Section 10.1.
• Voice commands to Dorvi: when your organization turns on voice and you hold the voice button to talk to Dorvi in the app, we collect the audio of your command, the text our speech models produce from it, Dorvi's answer and a record of the voice session (for example, when it started and ended, how many turns it had and whether an answer was interrupted). Dorvi answers in captions, and reads its answers aloud only if you turn spoken answers on. The audio is processed as you speak by speech models we run in our own Canadian infrastructure and is never stored. If you talk to Dorvi while a visit is recording, the visit records silence for as long as you hold the button, so your command does not become part of the visit's audio, transcript or note; the visit keeps a marker of when and for how long it was paused. Voice is off until your organization turns it on. How long each of these is kept is set out in Section 10.1.
• Phone calls answered by Dorvi: when a practice forwards its phone line to Dorvi, what we collect from callers is described in § 4.2.3.

4.4 AI Processing Data

• Transcription outputs and confidence scores
• Clinical insights and suggested diagnoses codes
• Natural language processing results
• Corrections and edits your users make to transcripts and AI-generated drafts (used only as described in § 5.1, never to train AI models)
• Quality assurance annotations
• Conversation data from Dorvi, our AI assistant: questions you submit through the standalone Dorvi chat (which may include patient context entered as free text and constituting PHI), the AI-generated responses returned to you, the public medical literature citations attached to those responses, conversation titles, timestamps, and the ordered message history within a conversation. Dorvi conversations are persistent and remain accessible to you across sessions until you delete them or they are deleted under Section 10.1.
• Dorvi data: the follow-up actions the AI suggests after a visit (such as patient instructions, referral, clinical and prior authorization letters, filled forms, staff tasks, booking invites and replies to patient messages), the drafts, the passages of the transcript or note each suggestion cites, the edits, approvals and dismissals your staff make and who made them, and delivery records (for example, fax status). It also includes faxes your practice receives through its own fax account, with the AI summary, document type and suggested patient match.
• Ask conversations: questions your users ask about a visit or a patient, the answers, the sources cited (the visit record, published literature and clinical guidelines, and documents in your organization's knowledge base), and any note edits the agent proposes.
• AI usage records: for each AI request, the organization, the user who made it (if any), the feature, the AI provider and model used, and our cost. These records contain no clinical content. We use them to count the AI credits your organization uses against your plan's included credits, to apply your organization's AI spend limit, to bill any extra credits, and to control our costs.

4.5 Technical and Usage Data

• Device identifiers and hardware information
• IP addresses and network information
• Browser type and operating system
• Session recordings (with consent)
• Feature usage and interaction patterns
• Performance metrics and error logs
• Integration logs with EHR/EMR systems
• How you found us: when you create an account or send us a contact request, we record the campaign tags in the link you followed to our website (such as utm_source, utm_medium and utm_campaign, and the Google Ads click identifier gclid), the name of the website that referred you (its host name only, never the full address), the page of our website where you started, and, if you choose to answer, how you heard about us. We read these from the web address and the referring site when you visit; we do not set a cookie or store anything in your browser to collect them. For a contact request we keep them without your name, email address or message.
• Chrome extension telemetry and audit metadata: where the extension is installed, we collect non-content metadata associated with each capture or insertion event, including a recording session identifier, the detected EHR system, the extension version, capture and insertion timestamps, inactivity-timeout events, and integrity hashes used to maintain a tamper-evident audit log. Audit-log entries are retained locally on your device for a limited rolling window and mirrored to our server-side audit log on the same retention basis as other PHI-access logs.

4.6 Third-Party Integration Data

• EHR/EMR system data from supported integrations
• Practice management system information
• Laboratory and imaging system interfaces
• Pharmacy and prescription data
• Insurance eligibility and claims data

5. AI-SPECIFIC DATA PROCESSING

5.1 How We Use AI Models, and No Model Training

We provide our AI features with pre-trained models, and we do not train them on your information:

• Third-Party AI Processing: We use established AI providers (Google Cloud Vertex AI and the Anthropic API from Anthropic PBC) under Business Associate Agreements for clinical note generation, Dorvi responses and drafts. Both are contractually barred from training their models on your data, and § 8.2.1 describes how each one handles a request. Speech-to-text transcription runs on our own infrastructure in Canada
• Data Minimization: Only the minimum necessary data is sent to AI providers for processing. Google Cloud Vertex AI does not write PHI to storage and deletes a copy it holds in memory to speed up responses within 24 hours; Anthropic deletes PHI within 30 days, except in the cases § 8.2.1 describes
• No Model Training: We do not use the content you and your organization put into the Services (including audio, transcripts, clinical notes, Dorvi and Ask conversations, patient form answers, and the corrections your users make), or any de-identified, anonymized, aggregated or synthetic data derived from it, to train, fine-tune or otherwise improve any artificial intelligence or machine learning model, whether ours or a third party's. Our AI providers are contractually bound not to use your data to train their models
• Features That Adapt to Your Organization: Some features learn from your own organization's use. Transcript correction suggestions draw on corrections your users have made before, and note template refinement suggestions draw on how a clinician has edited notes made from that template. These features look up your organization's own records, or include them in the request sent to the model, at the moment they run. They do not change any model, are not shared with other organizations, and are deleted with your organization's data
• Dorvi Conversation Context: To generate coherent multi-turn answers, the Dorvi feature transmits the current question together with prior messages from the same conversation (the conversation-history context window) to the third-party AI provider on each request. Conversation history is stored on our infrastructure in Canada and is sent to the AI provider only at the moment of processing. Google Cloud Vertex AI does not write it to storage; it may hold it in memory to answer the next turn of the same conversation faster and deletes it within 24 hours. Anthropic deletes it within 30 days, except in the cases § 8.2.1 describes (see § 8.2.1). Only the messages from the specific conversation you are currently using are included; we do not concatenate or share content across separate conversations, across users, or across organizations.
• Medical Literature Retrieval: To produce evidence-based citations alongside Dorvi answers, we maintain a local index of published medical literature inside our Canadian infrastructure, queried using your question, which does not leave our infrastructure for this purpose. We do not send your question to external research services.

5.2 Voice Processing

• Voice data is processed using advanced acoustic models for accurate transcription
• Speaker diarization to distinguish between multiple speakers
• Acoustic data retained only for the minimum necessary period
• Voice commands to Dorvi are transcribed, and spoken answers are produced, by speech models we run in our own Canadian infrastructure. No third party receives the audio. Dorvi then handles the text of your command exactly as it handles a typed question, with the same permissions, the same AI processing and providers, and the same provider retention terms (§ 5.1 and § 8.2.1). Dorvi prepares changes such as a booking only for you to confirm, and confirming one by voice goes through the same checks as clicking Confirm.
• Phone calls answered by Dorvi (§ 4.2.3) are transcribed, and Dorvi's spoken answers are produced, by the same speech models in our own Canadian infrastructure, and the audio is not stored. Dorvi processes the text of what a caller says with the same AI processing and providers as a typed Dorvi request, under the practice's AI residency setting and the same provider retention terms (§ 8.2.1). The safeguards for callers run in our own code, not in the AI: the emergency check runs before any AI processing, every sentence is checked for medical advice before it is spoken, the identity check is made by our systems, and nothing is booked, changed, cancelled or sent until the caller says yes to Dorvi's read-back.

5.3 Clinical Intelligence Generation

Our AI systems generate:

• Automated clinical documentation and SOAP notes
• ICD-10 diagnosis code and HCPCS Level II procedure/supply code suggestions
• Clinical decision support insights (not medical advice)
• Evidence-based Q&A with literature citations: through the standalone Dorvi chat, AI-generated answers to clinical questions, accompanied by citations to public medical literature sources. Citations are surfaced so you can independently verify the source material. As with all AI output we generate, these answers are informational, are not medical advice, and must be reviewed by a qualified healthcare professional before being relied upon in patient care.

5.4 De-identification and Anonymization

We do not de-identify, anonymize or aggregate the content your organization puts into the Services for our own purposes, and we do not use any such data to train or improve AI models (§ 5.1).

5.5 Model Transparency and Explainability

• Audit logs of all AI-generated content
• Drafts show the source passages they cite
• Human-in-the-loop review options
• Evaluation of AI features with synthetic or public test data (§ 7.2)

5.6 Automated Decision-Making and Artificial Intelligence (ADMT)

This section provides the information required by GDPR Article 13(2)(f), Quebec Law 25 § 12.1, and applicable California automated-decision-making rules. It describes how we use AI and automated processing, the logic involved, and the consequences for you.

Where we use AI. The Services use artificial intelligence and automated processing in these places:

• Speech-to-text transcription of clinical-encounter audio into text;
• Clinical-note and document generation, including structured SOAP-style notes from a transcript and, where a practice uses patient forms, the patient's submitted form answers and scores for that visit;
• Medical-coding suggestions (for example, suggested ICD-10 diagnosis codes and HCPCS Level II procedure/supply codes);
• The standalone Dorvi chat and Ask, which answer clinical questions (Ask can also answer questions about a visit or a patient and propose edits to the note for the user to accept or reject) and may surface citations to source material; and
• Dorvi, which suggests and drafts follow-up actions after a visit (for example patient instructions, letters, filled forms, staff tasks, booking invites and replies to patient messages), and reads and summarizes faxes the practice receives and suggests which patient each one belongs to.

The logic involved (plain-language). Audio is converted to text by automatic speech-recognition models. The resulting text is then processed by large language models, either models we host on our own infrastructure in Canada or models operated by our AI subprocessors under Business Associate Agreements (see § 5.1 and § 8.2), to draft notes, suggest codes, or answer Dorvi questions. Our AI providers process a request to produce the output and are contractually barred from training their models on it. Google Cloud Vertex AI does not write a request to storage and deletes a copy it holds in memory to speed up responses within 24 hours; Anthropic deletes a request and its output within 30 days, except in the cases § 8.2.1 describes (see § 8.2.1).

Significance and consequences for you. These features are clinical-documentation and decision-support aids; they do not make decisions about any individual and do not replace professional judgment. Every AI output (transcript, note, code suggestion, or Dorvi answer) is informational and must be reviewed and validated by a qualified healthcare professional before it is relied upon in patient care. Human review is a contractual requirement under our Business Associate Agreement (human-in-the-loop).

No solely-automated decisions with legal or similarly significant effect. We do not make decisions about you that produce legal effects or similarly significantly affect you (such as eligibility, denial of care, or pricing) based solely on automated processing without human involvement, within the meaning of GDPR Article 22. The AI features above are advisory and are always subject to professional human review.

Dorvi: a person approves every action. Dorvi only drafts. Nothing it suggests is sent, booked, faxed, filed in an EHR or posted to a patient until a member of the practice's staff has reviewed and approved it, and the reviewer can edit or dismiss any draft. There is no automatic sending mode in the Services. Where a practice enables Dorvi's phone line, Dorvi can book, reschedule or cancel a verified caller's appointment on the caller's request, within rules the practice sets. Drafts with clinical content (patient instructions, letters, forms and clinical replies to patients) can only be approved by a person the practice has marked as a licensed clinician. Drafts are labelled as AI-generated and show the passages of the visit record they came from. Risk flags (such as a medication change or advice about urgent care) are suggested by the AI, and the approver must confirm each one. Patient messages that may describe an emergency are detected by a fixed list of urgent phrases (and may also be flagged by the AI); the draft is then replaced by a standard reply telling the patient to call emergency services, and a person still sends it. The fax inbox never files a fax to a patient's chart on its own: staff confirm the patient. No decision about a patient is therefore based exclusively on automated processing within the meaning of Quebec Law 25 § 12.1, and none is a solely automated decision under GDPR Article 22.

Form scores and flags. Scores, severity bands and flags on patient forms (§ 4.2.2) are produced by fixed scoring rules, not by AI. They help a practice decide which responses to look at first. They do not diagnose and do not decide anything about the patient. A flagged response stays marked "Needs attention" until a member of the practice's staff reviews it, and who reviewed it and when is recorded. Patient forms are not monitored around the clock and are not an emergency or crisis service.

Your right to be informed and to submit observations (Quebec Law 25 § 12.1). Where a decision affecting you is based on automated processing of your personal information, you have the right to be informed of that fact, to be informed of the personal information used and the principal factors that led to the decision, and to submit observations to a member of our personnel who is able to review the decision. To exercise this right, or to request human review of any AI-assisted output that concerns you, contact our privacy contact using the details in § 23.

6. LEGAL BASIS AND LAWFUL PROCESSING

6.1 HIPAA Permitted Uses

We process PHI under HIPAA's permitted uses for:

• Treatment activities as directed by healthcare providers
• Healthcare operations including quality improvement
• Payment activities including claims processing
• As required by law or court order
• Public health activities as permitted
• Health oversight activities
• Research with appropriate authorization

6.2 GDPR Legal Bases

For EU/EEA residents, we process data based on:

• Performance of contract (service delivery)
• Legal obligations (regulatory compliance)
• Vital interests (emergency medical situations)
• Legitimate interests (security, fraud prevention, and knowing which of our marketing brings people to us)
• Explicit consent (marketing, optional features)
• Special category data processed under Article 9(2)(h) for healthcare

6.3 Consent and Authorization

• Informed consent obtained for voice recording
• HIPAA authorizations for uses beyond treatment, payment, and operations
• Granular consent for optional features
• Parental consent for minors where required
• Opt-in consent for marketing communications

7. USE OF INFORMATION

7.1 Primary Service Delivery

• Real-time medical transcription and documentation
• Clinical note generation and structuring
• Medical coding assistance and validation
• Integration with healthcare IT systems
• Provider workflow optimization
• Quality assurance of transcripts and AI output (without training AI models; see § 5.1)
• Standalone Dorvi chat: answering clinical questions you submit through the persistent Dorvi chat surface, retrieving relevant excerpts from public medical literature sources, returning AI-generated responses with literature citations, persisting the resulting conversations so you can list, resume, and review them later, and providing the conversation-history context required to generate coherent multi-turn answers within a conversation
• Dorvi: drafting follow-up actions from a visit for your staff to review, and carrying out only the actions your staff approve (saving documents to the visit, sending faxes through your practice's own fax account, filing documents in your EHR, sending booking links and secure messages to patients, and creating staff tasks)
• Inbound fax processing: reading faxes your practice receives through its own fax account, classifying and summarizing them, and suggesting a patient match for your staff to confirm
• Ask: answering questions about a visit or a patient, citing the visit record, published literature, clinical guidelines and your organization's knowledge base, and proposing note edits for the user to accept or reject

7.2 AI and Machine Learning

• Running the AI features you use (transcription, note drafting, coding suggestions, Dorvi and Ask) on pre-trained models
• Suggesting corrections and note template refinements to your organization from your own users' edits, as described in § 5.1
• Evaluating AI features for accuracy, bias and safety with synthetic or public test data
• We do not train, fine-tune or otherwise improve AI models with your content or with data derived from it (§ 5.1)

7.3 Security and Compliance

• Identity verification and authentication
• Fraud detection and prevention
• Security incident investigation
• HIPAA compliance auditing
• Regulatory reporting obligations
• Risk assessment and mitigation

7.4 Business Operations

• Billing and payment processing
• Counting AI credits used against your plan's included credits, applying your organization's AI spend limit, and billing extra credits (using the AI usage records in § 4.4)
• Customer support and service
• Product development and improvement (using operational telemetry and account information, not the content of clinical records)
• Analytics and performance monitoring (using operational telemetry and account information, not the content of clinical records)
• Measuring which campaigns, websites and channels bring people to sign up or contact us (using the information about how you found us in § 4.5)
• Legal compliance and dispute resolution
• Corporate transactions (with appropriate safeguards)

8. DISCLOSURE AND SHARING

8.1 Healthcare Ecosystem Sharing

We share information within the healthcare ecosystem solely as permitted by HIPAA and applicable law:

• Referring and consulting physicians
• Healthcare facilities and hospitals
• Laboratories and imaging centers
• Pharmacies (for medication-related information)
• Health information exchanges (HIEs)
• Accountable care organizations (ACOs)

8.1.1 Disclosures Your Practice Directs Through Dorvi

When your staff approve a Dorvi action, we disclose the approved document or message to the recipient they chose, on your practice's instructions and as your service provider or business associate:

• Fax: sent through the fax account your practice holds with its own fax provider (today, SRFax). Your practice contracts with that provider directly and is responsible for having its own Business Associate Agreement or equivalent privacy agreement with it. We send faxes and retrieve incoming faxes with your practice's account credentials, which we store encrypted. The fax provider acts for your practice and is not our subprocessor. Cover pages name the sender and the type of document, never clinical content.
• Your EHR: documents are filed in the patient's chart in the EHR your practice connects (today, OSCAR), under your practice's own agreement with its EHR provider.
• Patients: instructions, letters and replies are posted to the patient's secure conversation. Text messages to the patient carry the practice name and a secure link and, for appointment reminders, the appointment date and time, the clinician's name, the location and any wording the practice adds to its reminder template. Emails to the patient carry only the practice name and a secure link; they do not state the clinician, date, time or location of a visit, which are shown only after the patient follows the link. Neither ever carries clinical notes or secure-message content, and they are sent only where the patient's consent and contact preferences allow it.
• Recipients come from your practice's records. Letters can only be addressed to contacts in your practice's contacts directory; the agent cannot add a fax number, email address or phone number of its own.

A letter or form carries only the parts of the record the approving clinician includes, not the whole chart.

8.2 Service Provider Disclosures

We engage carefully vetted service providers under strict contractual obligations:

• Cloud infrastructure providers (Google Cloud Platform)
• AI/ML processing services (Google Cloud Vertex AI and the Anthropic API from Anthropic PBC, each under a BAA; § 8.2.1 describes how each handles a request)
• Content delivery and security services (Cloudflare)
• Payment processors (Stripe - PCI-DSS Level 1 compliant)
• Authentication and Sign-In Services: Google Identity Services / Google Sign-In (United States). When you visit our sign-in or sign-up pages, we may display a Google "One Tap" prompt if you are signed into a Google account in your browser. Loading this prompt involves loading code from accounts.google.com; Google receives your IP address, user-agent, and the fact that you visited our authentication page. We load Google Identity Services only on /signin and /signup — not on any other page of our site. The same applies if you click the "Sign in with Google" button. You can disable Google One Tap in your Google account settings or by signing out of your Google account in this browser.
• Transactional email delivery: Amazon Simple Email Service, provided by Amazon Web Services Canada, Inc. in its Canada (Central) region (Montréal, Quebec, Canada). Account emails, billing notices and messages to patients that the practice sends through the Services are delivered through this service. Messages to patients contain the patient's email address, the practice name and a secure link; they do not state the clinician, date, time or location of a visit and never contain clinical notes or secure-message content. Those details are shown only after the patient follows the link.
• Staff mailboxes: Purelymail (Add Rabbit LLC, United States) hosts our staff email accounts, including privacy@transcribe.health. When you email us, or send a message or demo request through our contact page, your message, your email address and the other details you enter (such as your name, organization, role and practice size) are stored there. The Services do not send email through Purelymail. Please do not send health information by email.
• Telephone calls and text messages: Twilio Inc. (United States), under a Business Associate Agreement. Where a practice forwards its phone line to Dorvi, Twilio connects each call to our infrastructure in Canada and carries its audio in transit; like any phone carrier, it receives the caller's number and the time and length of the call. We do not have Twilio record calls. Twilio also delivers the text messages described in § 4.2.3.
• Customer support and live chat: Chatwoot (open-source, self-hosted on Transcribe Health infrastructure in Canada).
• Security and monitoring services
• Professional service firms (under confidentiality)

8.2.1 Subprocessors

For the canonical, continuously-maintained list of our subprocessors under GDPR Art. 28(2) and the equivalent obligations under PIPEDA Principle 4.8 and HIPAA Business Associate arrangements, please refer to our public Trust Center:

trust.transcribe.health/subprocessors

The Trust Center is the source of truth; the list in § 8.2 is a non-exhaustive summary that may lag the Trust Center between policy revisions. Material changes (adding a new subprocessor that processes ePHI or personal data of EU/Canada/California residents) trigger an advance notice through the agreement-update process described in § 24.

AI-inference subprocessors and cross-border processing. Our clinical-note generation, coding suggestions and Dorvi features run either on models we host on our own infrastructure in Canada, with no subprocessor involved, or on one of two AI subprocessors, which receive content at the moment of processing: Google Cloud (Vertex AI) and Anthropic PBC (the Anthropic API, which serves the Claude models). Each processes Protected Health Information only under a Business Associate Agreement, and we send no content to a provider before that agreement is in place. Both are contractually barred from training their models on your data. Google Cloud Vertex AI processes a request to produce the output and may hold it briefly in memory to speed up later requests that share the same content, such as the next turn of a Dorvi conversation; it never writes the request to storage and deletes it within 24 hours. Anthropic processes requests under its standard commercial terms: it deletes a request and its output within 30 days, but may keep them longer where the law requires it or to enforce its usage policy (a request its automated safety systems flag may be kept for up to 2 years), and it may hold a processed form of a request in memory to speed up later responses, deleting it 5 minutes after the last request that used it. Google Cloud Vertex AI processes requests in its Montréal region (northamerica-northeast1) for organizations in Canada, and in its us-central1 region in the United States for organizations in the United States and for cross-border requests described below. Anthropic processes requests in the United States: we pin its inference to the United States. We use Anthropic for organizations located in the United States, and for organizations in Canada or the European Union only if the organization has enabled enhanced cross-border AI (below). Anthropic receives derived text (transcript text and the visit context a request needs, such as the note, the question asked or the draft being written), never raw audio. To the extent this AI-inference flow involves processing of Quebec residents' personal information outside Quebec, it is among the cross-border flows covered by the Privacy Impact Assessment we maintain under Quebec Law 25 (see § 8.2.2). This naming of the AI-inference flow is consistent with our Trust Center and with Schedule C of our Data Processing Agreement.

Per-organization AI residency (your choice). Cross-border AI inference is a per-organization setting, not an automatic default. By default, each organization's clinical AI inference stays in the country where the organization operates. For organizations in Canada, clinical AI runs on models hosted within Canada (Google Cloud Vertex AI in its Montréal region, or models we host on our own Canadian infrastructure), and content is not sent to a United States region. For organizations in the United States, clinical AI runs in the United States on the Anthropic API or Google Cloud Vertex AI (see § 11.1.1). An organization owner, administrator, or another user the organization has given organization-settings permission, may opt in to enhanced cross-border AI, which allows clinical inference to be served by an AI service in another country when the in-country service cannot serve a request: for a Canadian organization, Google Cloud Vertex AI or the Anthropic API in the United States; for a United States organization, Google Cloud Vertex AI in Canada; for a European Union organization, which has no in-region AI service today, Google Cloud Vertex AI in Canada or the United States, or the Anthropic API in the United States. Each of these transfers is made under the provider's Business Associate Agreement and Standard Contractual Clauses. This election is recorded (with the version of this disclosure that was accepted) and is reversible at any time; the transfer is governed by the Business Associate Agreement and Standard Contractual Clauses described above and is assessed under our Quebec Law 25 privacy-impact-assessment process (§ 8.2.2). Where a Canadian organization has not enabled cross-border AI, its clinical inference stays in Canada.

8.2.2 Cross-Border Data Transfers

Our primary infrastructure resides in Canada. Some of the service providers listed above process limited personal information in the United States — specifically Google Identity Services (authentication / Sign in with Google / One Tap) Purelymail (our staff mailboxes, which receive the messages you send to privacy@transcribe.health and our other staff addresses), and Cloudflare (network security), which decrypts and re-encrypts traffic at the Cloudflare location nearest the user, normally in Canada for users in Canada but occasionally outside Canada, holding it only transiently in memory and not caching or storing health information. Transactional email is delivered in Canada by Amazon Simple Email Service; its provider, Amazon Web Services Canada, Inc. For these transfers, we rely on the providers' published Data Processing Addenda and Standard Contractual Clauses where applicable. For Quebec residents, we maintain a Privacy Impact Assessment under Quebec Law 25 (§ 3.3 and § 17) covering these flows. You may request a summary by contacting our Security Officer.

AI inference outside Canada. For organizations that have enabled enhanced cross-border AI, derived transcript text and visit context may be processed in the United States by Google LLC (Vertex AI) or Anthropic PBC (the Anthropic API), as described in § 8.2.1. We have assessed both transfers in a privacy impact assessment under Quebec Law 25 (s. 17), which is pending final approval. We will not send any content to Anthropic until that assessment is approved and its Business Associate Agreement is signed.

Telephone calls. Calls Dorvi answers for a practice are connected by Twilio Inc., which processes the caller's number, the time and length of the call and its audio in transit in the United States (§ 8.2). The caller's speech is transcribed, and the call's records are kept, in Canada.

Notice for residents of British Columbia and Alberta. We use service providers outside Canada, mainly in the United States, to collect, use, disclose or store personal information for us, as listed in § 8.2 and § 8.2.1. These include Purelymail (Transcribe Health's own business mailboxes, United States) and Cloudflare (network security, transiently, at the location nearest the user, which may occasionally be outside Canada). For organizations that have enabled enhanced cross-border AI, they also include Google LLC (Vertex AI) and Anthropic PBC (the Anthropic API) for AI inference in the United States. Where a practice forwards its phone line to Dorvi, they also include Twilio Inc. for telephone calls and text messages. Information processed outside Canada may be accessible to courts and authorities of that country under its laws. You can get written information about our policies and practices for service providers outside Canada, and ask questions about how they handle personal information for us, by contacting our Privacy Officer (§ 23). This notice is given for the purposes of section 13.1 of Alberta's Personal Information Protection Act. We give the same notice to residents of British Columbia, where these service providers are covered by the reasonable security arrangements required by section 34 of British Columbia's Personal Information Protection Act.

8.3 Legal and Regulatory Disclosures

We may disclose information when required by:

• Court orders, subpoenas, or legal process
• Government investigations or audits
• Public health authorities
• Health oversight agencies
• Law enforcement (with appropriate legal basis)
• National security or intelligence agencies

8.4 Business Transfers

In connection with any merger, acquisition, or sale of assets:

• Due diligence under strict confidentiality
• Successor entities bound by this Policy
• Notice provided of any material changes
• Opportunity to request data deletion where permitted
• Continued protection under applicable BAAs

9. DATA SECURITY AND SAFEGUARDS

9.1 Technical Security Measures

We implement industry-leading security including:

• Encryption: stored files, patient form content and backup storage encrypted at rest; TLS 1.2 or higher in transit
• On-device encryption (Chrome extension): audio that our Chrome extension holds on your device while waiting to upload is encrypted on the device (AES-256), under a key held only in the browser's session memory; upload is protected by TLS.
• Tamper-evident audit log: extension-side audit log entries are integrity-protected so that local tampering with the audit trail is detectable on upload reconciliation.
• Multi-Factor Authentication: available to all users, and each organization can require it
• Network Security: network segmentation, firewall rules and DDoS protection
• Endpoint Protection: Company workstations are enrolled in device management with continuous security posture checks (full-disk encryption, screen lock, firewall, operating-system updates)
• Vulnerability Management: Continuous scanning and patching
• Secure Development: SAST, automated dynamic application security testing (OWASP ZAP), dependency scanning

9.2 Administrative Safeguards

• Security officer designation and responsibilities
• Security awareness training for all authorized personnel, scheduled in the compliance calendar
• Access management and least privilege principles
• Sanction policies for violations
• Regular risk assessments and audits
• Business continuity and disaster recovery plans
• Incident response procedures

9.3 Physical Security

• Production servers, owned by Transcribe Health or its owner, kept in a locked room or cabinet at a single site in Ontario, Canada, with physical access limited to the Security Officer
• Physical security and power-protection measures at the site
• Stored files and backup storage encrypted at rest
• Backups kept on a separate backup server at the same site, with 30-day write-once retention
• Google Cloud Vertex AI, used for AI inference only, relies on the physical safeguards of Google's data centers, which Google has independently audited (SOC 2 Type II, ISO 27001)
• Media disposal and sanitization procedures
• Workstation security policies

9.4 Compliance Program

Our compliance program includes:

• HIPAA Security Rule and Privacy Rule compliance (active)
• SOC 2 Trust Services Criteria (controls designed and operated to the criteria; preparing for a Type II examination, and once issued the report will be made available to customers under a non-disclosure agreement)
• PIPEDA and provincial health privacy legislation compliance (active)
• NIST Cybersecurity Framework alignment (active)
• ISO/IEC 27001 alignment (information security management practices)

10. DATA RETENTION AND DELETION

10.1 Retention Periods

The Services are not a system of record. We retain Personal Information only as long as needed to deliver the Services and meet our legal obligations. The table below states the retention period and the justification for each category. Healthcare providers remain responsible for retaining patient records in their own certified medical-record system per applicable law.

| Data category | Retention period | Basis / justification | |---|---|---| | Audio recordings (clinical-encounter audio) | Automatically and permanently deleted 90 days after transcription completes. Your organization may optionally enable earlier automatic deletion, with a window of 1 to 24 hours or 1 to 30 days (disabled by default). | Default setting applied platform-wide, not a period required by law; optional earlier window supports data-minimization (GDPR Art. 5(1)(e), PIPEDA Principle 4.5, Quebec Law 25). For clinics in Ontario, Alberta and British Columbia, Schedule D of our Data Processing Agreement governs. | | On-device copy of visit audio (encrypted copy the web and desktop apps keep on your device until the upload succeeds; see § 4.3) | Deleted when our servers confirm they have received the audio, when you discard the recording, or when you sign out, and in any case 7 days after the recording started. The 7-day limit is applied whenever the app is open; a copy that reaches 7 days while the app is closed is deleted the next time you open the app. In the desktop app, the copy is kept in memory only and does not outlast quitting the app. | Protects the visit against a lost connection or a failed upload; storage limitation and security of processing (GDPR Art. 5(1)(e) and 32, PIPEDA Principles 4.5 and 4.7, Quebec Law 25, HIPAA 45 CFR 164.312(a)(2)(iv)). Once uploaded, the audio follows the clinical-encounter audio period above. | | On-device copy of visit audio (Chrome extension) (encrypted copy the extension keeps until the upload succeeds; see § 4.3) | Deleted when our servers confirm they have received the audio, or when you delete it. In any case, deleted no more than 72 hours after the recording, a limit the extension applies while the browser is running; a recording that reaches 72 hours while the browser is closed is deleted the next time the browser runs. | Protects the visit against a lost connection or a failed upload; storage limitation and security of processing (GDPR Art. 5(1)(e) and 32, PIPEDA Principles 4.5 and 4.7, Quebec Law 25, HIPAA 45 CFR 164.312(a)(2)(iv)). Once uploaded, the audio follows the clinical-encounter audio period above. | | Transcriptions and session records (contain PHI) | Default: kept 7 years, then deleted. Your organization may enable earlier deletion as above. This is a default setting, not a period required by law. | Default setting that keeps recent records available to the practice; the practice keeps its own medical record in its record system. | | AI-generated clinical notes / documents (contain PHI) | Same as the transcript they derive from (7 years, optional earlier deletion as above). | Treated as part of the clinical record produced from the encounter. | | Dorvi conversations (questions, including the text of voice commands, AI responses, citations, history) | You can delete any of your conversations at any time. Conversations held in a visit are kept for as long as the visit and are deleted with it. General conversations and conversations about a patient are deleted 365 days after the conversation was last used, and a conversation about a patient is also deleted when that patient's record is deleted. A conversation in which Dorvi read a visit is also deleted when that visit is deleted. All of your conversations are deleted when your personal information is erased at your request (§ 12.5). | Service delivery (you can resume conversations); a conversation held in a visit is part of that visit's record of how AI shaped the note; storage limitation (GDPR Art. 5(1)(e), PIPEDA Principle 4.5). | | Voice commands to Dorvi (command audio, the text of each command, Dorvi's answers, session working state, recording pause markers) | Audio: never stored; it is processed as you speak and discarded. Command text and answers: saved in your Dorvi conversation and kept for the same period as a typed Dorvi conversation (row above); an answer you interrupt is kept only as far as it was spoken. Session working state (the recent turns Dorvi needs to follow the conversation): held in our session store in Canada for the session only, deleted at the latest 10 minutes after its last use and never kept longer than 2 hours. Recording pause markers (when and for how long a visit recording was paused while you talked to Dorvi; no audio or text): follow the retention of the visit. Voice session records (start, end, turn counts, interruptions; never what was said): kept as audit logs. | Service delivery, with audio never stored and working state limited to the live session (GDPR Art. 5(1)(c) and 5(1)(e), PIPEDA Principle 4.5, Quebec Law 25); audit logs under 45 CFR 164.312(b). Voice is transcribed by speech models we run in our own Canadian infrastructure. | | Phone calls answered by Dorvi (call audio, the live conversation, call records, messages and the tasks filed from them, confirmation texts, call and text limits, staff on-call numbers) | Audio: never recorded or stored. Live conversation (what the caller and Dorvi said, which Dorvi needs to follow the call): held in our session store in Canada for the call only, and never longer than 2 hours; once a caller objects, nothing they say is held except the message they choose to leave. Call record (time, routing, outcome, length, hashed number and last four digits, linked patient, message summary, appointment changed): deleted when the practice's visit records are deleted (7 years by default, never less than 6 years). Tasks Dorvi files (messages with the callback number, emergencies, callback requests): deleted with their call. When a patient's record is deleted, within minutes the patient's calls lose the patient link, the number and their content, and the tasks about them are erased; what remains shows only that a call took place. Confirmation texts: the text is deleted after 90 days and the delivery record after 4 years, by default. Call and text limits (counted against the hashed number): 1 hour for calls, 1 day for texts. Numbers that replied STOP: kept on the opt-out list (see the CASL suppression list below). Staff on-call numbers: kept until the staff member removes theirs or their account is deleted. Audit records (identifiers and the hashed number, never what was said): kept as audit logs. | A call is a patient's contact with the practice, so its record keeps the practice's visit-record period; audio is never stored and the live conversation is limited to the call (GDPR Art. 5(1)(c) and 5(1)(e), PIPEDA Principle 4.5, Quebec Law 25); text delivery records as evidence of consent and opt-outs (CASL, TCPA); audit logs under 45 CFR 164.312(b). | | Dorvi records (suggested actions, drafts, cited passages, approvals and dismissals, outbound fax records, received faxes and their PDFs) | Follow the retention of the visit they belong to. When a visit or patient is deleted, the related actions, fax records, fax PDFs and filled form PDFs are deleted with it. | Part of the visit record produced for the practice; service delivery and audit. | | AI usage records (organization, user, feature, AI provider and model, cost; no clinical content) | Kept while the organization's account exists and deleted with it. The link to a user is removed when that user's account is deleted. | Counting included and extra AI credits, billing extra credits, cost control, and resolving billing disputes. | | Dictations (global dictation: speech you dictate into a text field in the web app, desktop app, or Chrome extension, the text it produces, and up to 1,000 characters of the text around your cursor) | Audio: deleted once transcription finishes, normally within a few minutes and in all cases within about 20 minutes of recording. Text around your cursor (sent only to improve accuracy): deleted when transcription finishes, and in all cases within about 20 minutes; never kept in your dictation history. Dictated text: kept in your personal dictation history for the period you choose: off, 1, 7, or 30 days (default 7 days), then deleted. Your dictation history is visible only to you, and you can delete a single dictation or clear your whole history at any time. With history off, the text is deleted a few minutes after it is inserted (in all cases within about 20 minutes). Dictation record without text (for example, the app you dictated from and whether the dictation succeeded or failed): deleted after 24 hours, or at the end of your history period if that is later. Dictation records are deleted when your user account or your organization's account is deleted or when you ask us to erase your data, and stored dictation text is included when you ask for access to or a copy of your data. | Service delivery; data minimization and storage limitation, with the history period under your control (GDPR Art. 5(1)(c) and 5(1)(e), PIPEDA Principle 4.5, Quebec Law 25). Dictation is transcribed by speech models we run in our own Canadian infrastructure; no third party receives dictation audio or text. Dictated text you insert into a clinical note becomes part of that note and follows the note's retention period above. | | Patient form drafts (answers saved automatically before a patient submits a form) | Replaced by the submitted answers when the patient submits. If the form is never submitted, deleted 30 days after the link expires or is cancelled. | Lets the patient finish later; data minimization and storage limitation (GDPR Art. 5(1)(c) and 5(1)(e), PIPEDA Principle 4.5, Quebec Law 25). | | Submitted patient forms (answers, scores, flags, completed PDFs) | Kept with the patient's record in the Services until the practice deletes that patient or the practice's account ends. Deleting a patient deletes their answers, drafts and completed PDFs. On termination, return or destruction follows the Business Associate Agreement. | Part of the practice's clinical record. The practice sets its own record-retention period under the law that applies to it and should keep a copy in its own medical record system (see BAA § 1.5). | | Patient form consent and signature records (form version, consent wording reference, date and time, hashed IP address and browser details) | Kept after the patient is deleted, without the signer's name or drawn signature, as proof that consent was given; deleted when the practice's account data is deleted. | Establishing, exercising or defending legal claims and meeting record-keeping obligations (GDPR Art. 17(3)(b) and (e); Quebec Law 25 s. 23; HIPAA 45 CFR 164.530(j)). | | Chrome-extension audit / telemetry metadata (session ID, EHR detected, version, timestamps, integrity hashes) | Server-side: 6 years on the same basis as other PHI-access logs. On-device: limited rolling window, purged automatically. | HIPAA audit-control requirement, 45 CFR 164.312(b). | | Account data (provider profile, credentials, preferences) | Duration of the account; deleted within 30 days of account closure, except where law requires retention. | Service delivery and contract. | | How you found us (campaign tags, referring website, starting page and your answer; see § 4.5) | With an account: kept with the account and deleted with it, or when you ask us to erase your data. With a contact request: kept without your name, email address or message, and deleted 2 years after the request. | Legitimate interest in knowing which of our marketing works (GDPR Art. 6(1)(f)); data minimization and storage limitation (GDPR Art. 5(1)(c) and 5(1)(e), PIPEDA Principle 4.5, Quebec Law 25). | | Billing data (via Stripe) | Retained as required by tax / financial-record law (typically 7 years). | Legal obligation; Stripe processes billing only. | | Contact and demo requests (name, email address, organization, role, practice size, topic and message you send through our contact page) | Kept in our staff mailboxes for 24 months after our last exchange with you, then deleted; deleted earlier on request. | Responding to your request and pre-sales follow-up; storage-limitation default. | | Marketing data | Until consent withdrawal, plus any period required by law. | Consent (opt-in). | | CASL suppression list (unsubscribed recipients) | Indefinite. | Required to honour unsubscribe requests under Canada's Anti-Spam Law (CASL § 6). | | Audit logs (security / HIPAA) | Minimum 6 years. | HIPAA Security Rule documentation retention, 45 CFR 164.312(b) and 164.530(j). | | Operational telemetry (not derived from the substance of content) | Retained as needed for security and capacity planning. We do not create de-identified data from your content. | Service operation and security. |

Account closure and PHI. The retention periods above apply only while your organization's account is active. When an organization's subscription ends, or an owner deletes the organization, the organization has 30 days to export its records, starting when we send its owners written notice that the Services have ended; we then delete its content from active systems within 30 days, and backup copies expire within 90 days after the export window. Audit logs (which contain no clinical content) and billing records are kept for the periods in this table. Dictation history is personal to each user: it is never kept longer than the period that user chose (at most 30 days), and it is deleted earlier when the user's account or the organization's account is deleted, or when the user's data is erased on request. For clinics in Ontario, Alberta and British Columbia, Schedule D of our Data Processing Agreement governs.

HIPAA does not itself prescribe a minimum retention period for PHI in patient records; the record-retention obligations applicable to your practice are set by state, provincial, and professional regulations. The residual-backup treatment in § 10.2 applies to all categories above and does not extend any of these periods; residual encrypted backups age out on a bounded cycle.

10.2 Deletion and Disposal

• Deletion from active databases and file storage
• Expiry of encrypted backups on a bounded schedule
• Certificate of destruction provided when a customer's contract ends
• Audit trail of deletion activities

When data is deleted from our active systems under Section 10.1 or in response to a deletion request, residual copies may persist in our encrypted backups until those backup sets expire on their normal schedule, and in any case within 90 days. Individual records cannot be excised from an encrypted backup snapshot; backups are encrypted, access-controlled, and disposed of using the methods above when they age out. This residual-backup window is the standard treatment for backup media under HIPAA and PIPEDA and does not extend the retention periods described in Section 10.1.

11. INTERNATIONAL DATA TRANSFERS

11.1 Data Residency

Our production environment runs on a single Canadian-resident infrastructure stamp in Ontario, with backups at the same site:

• All Personal Health Information at rest — Postgres records, MinIO object storage, Redis caches, audit logs — lives on Canadian infrastructure under PIPEDA / Quebec Law 25
• Audio transcription (speech-to-text) runs on self-hosted infrastructure within the Canadian stamp; raw audio never leaves Canada
• AI inference jurisdiction is decoupled from at-rest residency and depends on your organization's country and AI residency setting (see Sections 8.2.1 and 11.1.1)

US and EU stamps are on our roadmap. They will be deployed when customer demand contractually requires US-only or EU-only residency. Until those stamps exist, US customers may operate on the Canadian stamp under a cross-border Data Processing Agreement (DPA) executed at onboarding. EU residency is not currently available; please contact us if you require it.

11.1.1 AI Inference Routing

AI inference is routed according to the organization's country of operation and its AI residency setting (§ 8.2.1), independent of where the at-rest data lives. The route is logged on every clinical AI request:

• Canadian organizations: clinical AI inference runs on models hosted within Canada (Google Cloud Vertex AI in its Montréal region, or models we host on our own Canadian infrastructure); no cross-border processing unless the organization has opted in to enhanced cross-border AI (§ 8.2.1), in which case a request may be served in the United States by Google Cloud Vertex AI or the Anthropic API
• United States organizations: clinical AI inference runs in the United States on the Anthropic API or Google Vertex AI in a US region, each under a Business Associate Agreement (§ 8.2.1 describes how each handles a request); because at-rest data is held in Canada, this is a documented cross-border processing leg covered by the customer's DPA. A United States organization that has opted in to enhanced cross-border AI may also have a request served by Google Cloud Vertex AI in Canada when the US service cannot serve it
• Other jurisdictions (including the European Union): clinical AI inference is not routed outside the organization's region unless the organization has opted in to enhanced cross-border AI. There is no in-region AI service in the European Union today, so clinical AI features for EU organizations are available only with that opt-in, in which case requests are served in Canada (Google Cloud Vertex AI) or the United States (Google Cloud Vertex AI or the Anthropic API) under Standard Contractual Clauses. Coverage is added per region as it becomes available

11.2 Transfer Mechanisms

When international transfers occur:

• Standard Contractual Clauses (EU Commission approved)
• Adequacy decisions where applicable
• Binding Corporate Rules for intra-group transfers
• Explicit consent for specific transfers
• Derogations for vital interests or legal claims

11.3 Transfer Safeguards

• Encryption in transit (TLS) and at rest
• Transfer impact assessments
• Supplementary measures per Schrems II
• Government access transparency reporting
• Enhanced contractual guarantees

12. YOUR PRIVACY RIGHTS

12.1 HIPAA Rights

The rights below derive from HIPAA. Note: the formal vehicle for these rights is your healthcare provider's Notice of Privacy Practices, not this Policy (see the callout in § 2). Where Transcribe Health holds your PHI as a Business Associate, we support your provider in honouring these rights:

• Access your PHI and receive copies
• Request amendments to incorrect PHI
• Accounting of disclosures
• Request restrictions on uses and disclosures
• Confidential communications
• File complaints with OCR

12.2 GDPR Rights (EU/EEA Residents)

• Access (Article 15)
• Rectification (Article 16)
• Erasure/"Right to be Forgotten" (Article 17)
• Restriction of processing (Article 18)
• Data portability (Article 20)
• Object to processing (Article 21)
• Automated decision-making rights (Article 22) — see § 5.6 for our ADMT disclosure

12.3 CCPA/CPRA Rights (California Residents)

Transcribe Health does not sell or share personal information, and does not use sensitive personal information for any purpose other than providing the Services and purposes the CPRA exempts from the right to limit. We nonetheless honour the following rights and provide the controls described below.

• Know what information we collect
• Delete personal information
• Correct inaccurate information
• Opt out of the sale or sharing of personal information
• Limit the use of sensitive personal information
• Non-discrimination for exercising your rights

Opt-out control. Although we do not sell or share personal information, we provide an opt-out control regardless. If you have a Transcribe Health account, you can set your opt-out preference at any time from your account's Privacy & Data Rights settings, using the "Do Not Sell or Share My Personal Information" control. When you opt out, we display a confirmation of your opt-out status and the date it took effect; you may opt back in after the 12-month period required by California law.

Limit the use of sensitive personal information. Because we use sensitive personal information solely to provide the Services and for purposes the CPRA exempts from the right to limit, no separate limitation is required for those uses. We do not use sensitive personal information to infer characteristics about you.

Global Privacy Control (GPC). We honour the Global Privacy Control browser signal. If your browser or extension sends a GPC signal (the Sec-GPC header), we treat it as a valid request to opt out of any sale/sharing of personal information and reflect your opted-out status accordingly; the status is shown to you so you can confirm it has been applied.

To make any CCPA/CPRA request you may also contact us at privacy@transcribe.health (see § 12.5 and § 23).

12.4 PIPEDA Rights (Canadian Residents)

• Access personal information
• Challenge accuracy and completeness
• Withdraw consent
• Register complaints with Privacy Commissioner
• Know about breaches affecting you
• For Quebec residents: the right to be informed of, and to submit observations on, automated decisions based on your personal information (Law 25 § 12.1) — see § 5.6

12.5 Exercising Your Rights

• Submit requests to: privacy@transcribe.health
• Identity verification required
• Response within 30 days (45 for complex requests)
• No fee for reasonable requests
• Appeal process available
• Designated agent submissions accepted with authorization

12.6 Requests About Information a Practice Collects Through Us

For patient forms, online booking, phone calls answered by Dorvi, clinical-encounter recordings and other patient information we hold for a healthcare practice, the practice is the organization responsible for that information (the controller under GDPR, the covered entity under HIPAA, and the organization or enterprise responsible under PIPEDA, Quebec Law 25 and provincial law). Patients should send requests to see, correct or delete that information, or to withdraw consent, to the practice. The practice can view, export and delete a patient's form answers in the Services. If you send such a request to us, we will tell you which practice to contact where we can, forward the request to the practice without undue delay, and help the practice respond. Contacting us instead of the practice does not mean your request is lost. You may still contact our privacy officer (§ 23) or a privacy regulator at any time.

13. CHILDREN'S PRIVACY

13.1 Age Restrictions

• The Services are a professional tool for healthcare providers and are not directed to children. We do not knowingly collect personal information directly from children for our own purposes.
• United States (COPPA): we do not knowingly collect personal information from children under 13 for our own commercial purposes.
• EU/EEA/UK (GDPR Art. 8): where a child's consent is the basis for an online service, the digital-consent age ranges from 13 to 16 depending on the Member State; below that age, consent must be given or authorised by the holder of parental responsibility.
• Quebec (Law 25): for a minor under 14, any collection of personal information requires the consent of the person having parental authority, except where collection is clearly for the minor's benefit.
• California (CCPA/CPRA): because we do not sell or share personal information, this restriction does not arise in practice; were it to, we would not sell or share the personal information of consumers we know to be under 16 without affirmative authorization (from the minor if 13-15, or from a parent/guardian if under 13).
• Patient PHI relating to minors is processed only on behalf of, and under the authority of, the healthcare provider, whose own Notice of Privacy Practices and applicable health-records law govern parental access and adolescent-confidentiality rules.

13.2 Parental Rights

• Access to minor's information (subject to state law)
• Consent management for minor patients
• Restrictions on sensitive health topics per jurisdiction
• Transition procedures at age of majority

14. COOKIES AND TRACKING TECHNOLOGIES

14.1 Cookies and Similar Technologies We Use

We use a minimal set of cookies. We do not use advertising cookies, and we do not load third-party analytics or marketing trackers on our marketing site. The table below lists the cookies set in connection with the Services.

| Cookie | Provider | Purpose | Duration | Party | |---|---|---|---|---| | access_token | Transcribe Health (auth-service) | Strictly necessary, holds your authenticated session (HttpOnly, Secure). | Session / short-lived | First-party | | refresh_token | Transcribe Health (auth-service) | Strictly necessary, renews your session without re-login (HttpOnly, Secure). | Up to session-renewal window | First-party | | browser_id | Transcribe Health (auth-service) | Strictly necessary, account security (HttpOnly, Secure, SameSite=Lax). A random value with no personal details, set when you sign in or your session renews. It lets us tell whether two attempts to renew the same sign-in came from the same browser, so a stolen session token used from another browser is detected and the session is ended. It stays after you sign out so this check keeps working the next time you sign in. A hashed copy is held briefly in our session-security records. | 400 days | First-party | | csrf_token, csrf_token_verify | Transcribe Health (auth-service) | Strictly necessary, protects sign-in and account requests against cross-site request forgery (csrf_token_verify is HttpOnly). | 24 hours | First-party | | mfa_token, mfa_enrollment_token | Transcribe Health (auth-service) | Strictly necessary, carries a sign-in through multi-factor authentication or multi-factor setup (HttpOnly, Secure). | 5 to 10 minutes | First-party | | oauth_flow, saml_flow | Transcribe Health (auth-service) | Strictly necessary, ties a Google or single sign-on (SSO) sign-in to the browser that started it, so a sign-in cannot be completed from another browser (HttpOnly, Secure). | 10 minutes | First-party | | device_limit_ticket | Transcribe Health (auth-service) | Strictly necessary, lets you remove a device during sign-in when your account has reached its device limit (HttpOnly, Secure). | 5 minutes | First-party | | device_trust | Transcribe Health (auth-service) | Strictly necessary, account security: remembers that this browser completed multi-factor authentication (HttpOnly, Secure). | 30 days | First-party | | active_org | Transcribe Health | Functionality, remembers which of your organizations you are working in. | Browser session | First-party | | NEXT_LOCALE | Transcribe Health | Functionality, remembers your language/region (e.g. en-US, en-CA, fr-CA). | Session cookie, or 1 year when you choose a language or region with the region selector | First-party | | cw_conversation | Transcribe Health (Chatwoot support chat, self-hosted in Canada) | Functionality, keeps your support chat conversation so you can return to it. Set only after you open the support chat. | Up to 1 year | First-party | | __cf_bm, cf_clearance | Cloudflare | Strictly necessary, bot-management and security for our CDN/WAF. | Up to ~30 min / as set by Cloudflare | Third-party (infrastructure) |

The browser_id cookie is set only for people who sign in to the Services. Patients who fill in forms or book appointments through a practice link do not sign in and do not receive it, and the patient forms page sets no cookies of its own.

Support chat. Our support chat runs on Chatwoot, open-source software we host on our own infrastructure in Canada (§ 8.2). The chat software loads only when you click the chat button on our website or choose to contact support from your account menu in the Services. Once loaded, it sets the cw_conversation cookie and receives what you type into the chat, your browser and device details and the page you are on.

Google Sign-In. Google Identity Services, which shows the Google One Tap prompt on our sign-in and sign-up pages, is described in § 8.2. A sign-in with Google uses the oauth_flow cookie listed above.

Strictly-necessary cookies do not require consent. Where any non-essential cookie is introduced in the future, we will obtain consent first where required (ePrivacy/GDPR, Quebec Law 25, CPRA).

14.2 Your Choices

• Browser controls. You can block or delete cookies in your browser settings. If you block strictly necessary cookies, you will not be able to sign in to the Services.
• Support chat. The chat cookie is set only if you open the support chat. You can delete it at any time in your browser.
• Global Privacy Control (GPC). We honour GPC signals as described in § 12.3.
• Analytics and advertising. We use no analytics or advertising cookies.

15. AI TRANSPARENCY AND ETHICS

15.1 AI Principles

We commit to:

• Transparency: Clear disclosure of AI use
• Fairness: Evaluation of AI features with synthetic or public test data
• Accountability: Human oversight of AI decisions
• Privacy by Design: Privacy considered at every stage
• Beneficence: AI used to improve healthcare outcomes
• Non-maleficence: Do no harm principle

15.2 Clinical Decision Support Disclaimer

IMPORTANT: Our AI-generated clinical insights are provided for informational purposes only and do not constitute medical advice. Healthcare providers retain full responsibility for clinical decisions. AI outputs must be reviewed and validated by qualified medical professionals before use in patient care.

15.3 Research and Development

We do not use your content, or data derived from it, for research.

16. DATA BREACH NOTIFICATION

16.1 Breach Response Procedures

In the event of a breach:

• Immediate investigation and containment
• Risk assessment and harm evaluation
• Notification within HIPAA required timeframes (60 days for individual notification under 45 C.F.R. §164.404)
• GDPR notification within 72 hours where applicable to a supervisory authority
• Individual notice via email and certified mail
• Regulatory reporting to HHS, state attorneys general
• Credit monitoring offered where appropriate

Where Transcribe Health acts as a Business Associate, breach notification to the Covered Entity is governed by the applicable Business Associate Agreement, which requires a preliminary notice within 24 hours of confirming or reasonably suspecting a breach and a full written notice within 72 hours. For clinics in Ontario, Alberta and British Columbia, Schedule D of our Data Processing Agreement governs notice to the clinic, with the same 24-hour and 72-hour times. This BA-to-Covered-Entity obligation is separate from, and does not displace, the regulator- and individual-facing notification timelines described above.

16.2 Breach Prevention

• Continuous security monitoring
• Periodic security assessment (an internal white-box assessment was completed; an independent third-party penetration test is planned), scheduled in the compliance calendar
• Employee security training
• Vendor risk assessments
• Incident response drills
• Cyber-liability insurance (being procured; no coverage amount stated until a policy is bound)

17. LIMITATION OF LIABILITY AND INDEMNIFICATION

17.1 LIMITATION OF LIABILITY

TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, AND EXCEPT FOR RIGHTS AND REMEDIES THAT CANNOT BE LIMITED OR WAIVED UNDER APPLICABLE LAW (INCLUDING NON-WAIVABLE RIGHTS UNDER GDPR/UK GDPR, CCPA/CPRA, PIPEDA, QUEBEC LAW 25, BC PIPA, ALBERTA PIPA, AND HIPAA), IN NO EVENT SHALL TRANSCRIBE HEALTH, ITS OFFICERS, DIRECTORS, EMPLOYEES, AGENTS, AFFILIATES, OR LICENSORS BE LIABLE FOR ANY INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL, PUNITIVE, OR EXEMPLARY DAMAGES, INCLUDING BUT NOT LIMITED TO DAMAGES FOR LOSS OF PROFITS, REVENUE, GOODWILL, USE, DATA, OR OTHER INTANGIBLE LOSSES, ARISING OUT OF OR RELATING TO THIS POLICY OR THE SERVICES, REGARDLESS OF THE THEORY OF LIABILITY AND WHETHER OR NOT TRANSCRIBE HEALTH HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

Aggregate cap. To the maximum extent permitted by applicable law, our total aggregate liability arising out of or relating to this Policy or the Services shall not exceed the total fees paid by your organization to Transcribe Health in the trailing twelve (12) months preceding the event giving rise to the claim.

Protected Health Information. This aggregate cap does not apply to, and does not govern, liability for Protected Health Information. The handling of Protected Health Information, and the parties' respective liability for it, is governed by the applicable Business Associate Agreement or, for clinics in Ontario, Alberta and British Columbia, by Schedule D of our Data Processing Agreement, each of which applies the general contractual liability cap in the Terms of Service with no PHI-specific supercap. Nothing in this Policy limits or excludes any liability that cannot be limited or excluded under applicable law, or any statutory privacy right that the law makes non-waivable.

17.2 Indemnification

You agree to defend, indemnify, and hold harmless Transcribe Health and its affiliates from and against any claims, damages, losses, and expenses (including reasonable attorneys' fees) arising out of or relating to:

• Your violation of this Policy
• Your violation of applicable laws or regulations
• Your use of the Services in a manner not authorized by this Policy
• Any content or data you provide through the Services
• Your violation of any third-party rights

17.3 Healthcare-Specific Exclusions

We expressly disclaim liability for:

• Clinical decisions made using our Services
• Medical malpractice or professional liability claims
• Accuracy of AI-generated clinical insights
• Integration failures with third-party systems
• Compliance with your specific regulatory obligations

18. DISCLAIMERS AND WARRANTIES

18.1 Service Disclaimer

THE SERVICES ARE PROVIDED "AS IS" AND "AS AVAILABLE" WITHOUT WARRANTIES OF ANY KIND, EXPRESS OR IMPLIED. WE SPECIFICALLY DISCLAIM ALL WARRANTIES, INCLUDING MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE, AND NON-INFRINGEMENT.

18.2 Medical Disclaimer

WE DO NOT PROVIDE MEDICAL ADVICE. THE SERVICES ARE TOOLS TO ASSIST HEALTHCARE PROVIDERS AND DO NOT REPLACE PROFESSIONAL MEDICAL JUDGMENT. WE ARE NOT RESPONSIBLE FOR ANY MEDICAL DECISIONS, DIAGNOSES, OR TREATMENTS BASED ON THE USE OF OUR SERVICES.

18.3 Accuracy Disclaimer

WHILE WE STRIVE FOR HIGH ACCURACY, WE DO NOT GUARANTEE 100% ACCURACY IN TRANSCRIPTION OR AI-GENERATED CONTENT. ALL OUTPUT MUST BE REVIEWED AND VALIDATED BY QUALIFIED HEALTHCARE PROFESSIONALS.

19. QUALITY IMPROVEMENT AND HEALTHCARE OPERATIONS

19.1 Quality Improvement Programs

We measure the performance of the Services using operational telemetry that is not derived from the substance of your content (for example, error rates and processing times), and synthetic or public test data.

We do not use de-identified, anonymized, aggregated or synthetic data derived from your content to train, fine-tune or improve any AI model, including transcription or specialty-specific models (§ 5.1).

19.2 Healthcare Operations Support

Our Services support your healthcare operations including:

• Quality assessment and improvement
• Patient safety activities
• Protocol development
• Case management and care coordination
• Practice management activities
• Accreditation and licensing

20. DISPUTE RESOLUTION AND GOVERNING LAW

20.1 Dispute Resolution

Except where prohibited by applicable law, and excluding any claim or right that applicable law makes non-waivable or non-arbitrable (including statutory privacy claims and any right to lodge a complaint with a supervisory or data-protection authority), disputes arising out of or relating to this Policy or the Services may be resolved through binding arbitration administered by the ADR Institute of Canada (for Canadian residents) or the American Arbitration Association (for U.S. residents), seated in Ontario, Canada.

Nothing in this Section prevents you from lodging a complaint with a data-protection or privacy regulator (including the OPC, the Commission d'accès à l'information du Québec, the BC or Alberta OIPC, the CNIL or another EU supervisory authority, the UK ICO, the California Privacy Protection Agency or Attorney General, or HHS/OCR), or from exercising any non-waivable statutory right, regardless of this arbitration provision.

20.2 Class Action Waiver

To the extent permitted by applicable law, you agree to bring claims against us only in your individual capacity. This waiver does not apply to any claim or representative action that applicable law makes non-waivable (including representative actions available under certain consumer-protection statutes).

20.3 Governing Law

This Policy shall be governed by the laws of the Province of Ontario and the federal laws of Canada applicable therein, without regard to its conflict of law principles. For international users, local mandatory consumer protection laws may apply.

20.4 Venue

Exclusive venue for any dispute not subject to arbitration shall be the courts located in Ontario, Canada.

20.5 Time Limitation

You must bring any claim within one (1) year after the cause of action arises, or such claim is forever barred.

21. REGULATORY COMPLIANCE

21.1 United States Compliance

• HIPAA Privacy, Security, and Breach Notification Rules
• HITECH Act requirements
• 42 CFR Part 2 (substance abuse records)
• State medical records laws
• CCPA/CPRA (California)
• Biometric privacy laws (Illinois BIPA, Texas, Washington)
• State breach notification laws

21.2 Canadian Compliance

• PIPEDA (federal)
• Ontario: Personal Health Information Protection Act, 2004 (PHIPA)
• Quebec: the Act respecting the protection of personal information in the private sector, as amended by the Act to modernize legislative provisions as regards the protection of personal information (Law 25)
• Alberta: Health Information Act (HIA)
• British Columbia: Personal Information Protection Act (PIPA BC)
• Saskatchewan: Health Information Protection Act (HIPA)
• Manitoba, New Brunswick, Newfoundland and Labrador: Personal Health Information Acts (PHIA)
• Nova Scotia, PEI, Territories: PIPEDA as applicable federal legislation

21.3 International Compliance

• GDPR (European Union) - applicable when serving EU-based users
• UK Data Protection Act - applicable when serving UK-based users
• Other applicable national laws as required by jurisdiction

21.4 Industry Standards

• HL7 FHIR specifications
• ONC certification requirements
• NIST Cybersecurity Framework
• ISO 27001/27799 standards
• Cloud Security Alliance guidelines

22. PRIVACY PROGRAM GOVERNANCE

22.1 Privacy by Design

We implement privacy by design principles:

• Proactive not reactive
• Privacy as default setting
• Full functionality with privacy
• End-to-end security
• Visibility and transparency
• Respect for user privacy
• Privacy embedded into design

22.2 Privacy Impact Assessments

We conduct assessments for:

• New features and services
• AI model deployments
• Third-party integrations
• International data transfers
• High-risk processing activities

23. CONTACT INFORMATION

Person Responsible for the Protection of Personal Information (Quebec Law 25 § 3.1)

The person responsible for the protection of personal information at Transcribe Health is the Privacy Officer, Transcribe Health Corporation, reachable at privacy@transcribe.health.

Security Officer

For privacy-related inquiries, data subject rights requests, or concerns about our privacy practices:

Security Officer Transcribe Health Corporation Email: privacy@transcribe.health (preferred for data-subject rights, DPIA / PIA requests, and sub-processor enquiries) Email: hello@transcribe.health (general contact) Response Time: Within 48 business hours

Additional Contacts

For comprehensive contact information including security incidents, legal inquiries, compliance matters, and audit support, please visit our Compliance page.

Regulatory Authorities

Office of the Privacy Commissioner of Canada 30 Victoria Street, Gatineau, Quebec K1A 1H3 Toll-free: 1-800-282-1376 Website: www.priv.gc.ca

U.S. Department of Health and Human Services Office for Civil Rights 200 Independence Avenue, S.W., Washington, D.C. 20201 Toll-free: 1-877-696-6775 Website: www.hhs.gov/ocr

European Data Protection Authorities For EU/EEA residents: Contact your local supervisory authority Directory: https://edpb.europa.eu/about-edpb/board/members_en

Information Commissioner's Office (ICO) — United Kingdom For UK residents: Wycliffe House, Water Lane, Wilmslow, Cheshire SK9 5AF, United Kingdom Helpline: +44 (0)303 123 1113 Website: ico.org.uk

24. CHANGES TO THIS POLICY

24.1 Right to Modify

We may modify this Policy from time to time. For any material change, the change takes effect only after the advance-notice period described in § 24.2. Non-material changes (such as typographical corrections or clarifications that do not reduce your rights or change how we handle your information) may take effect upon posting, with the "Last Updated" date revised accordingly.

24.2 Notice of Material Changes

For material changes, we will:

• Email notice to registered users
• In-app notifications
• Banner notice on website
• 30-day advance notice for material adverse changes

24.3 Continued Use

For material changes, your continued use of the Services after the 30-day notice period (and any required re-acceptance) constitutes acceptance of the modified Policy. If you disagree with a material change, you must discontinue use before it takes effect.

24.4 Version History

Previous versions available upon written request to hello@transcribe.health. We maintain a complete version history for compliance purposes.

25. SEVERABILITY AND WAIVER

25.1 Severability

If any provision of this Policy is found to be unenforceable or invalid, that provision shall be limited or eliminated to the minimum extent necessary, and the remaining provisions shall remain in full force and effect.

25.2 Waiver

No waiver of any term of this Policy shall be deemed a further or continuing waiver of such term or any other term, and our failure to assert any right or provision shall not constitute a waiver of such right or provision.

26. FORCE MAJEURE

We shall not be liable for any failure or delay in performance under this Policy which results from any cause beyond our reasonable control, including but not limited to acts of God, natural disasters, war, terrorism, riots, embargoes, acts of civil or military authorities, fire, floods, accidents, pandemics, strikes, or shortages of transportation facilities, fuel, energy, labor, or materials.

27. ASSIGNMENT

You may not assign or transfer any rights or obligations under this Policy without our prior written consent. We may assign our rights and obligations without restriction.

28. ENTIRE AGREEMENT

This Policy, together with our Terms of Service and any applicable BAA, constitutes the entire agreement between you and Transcribe Health regarding privacy and data protection, and supersedes all prior and contemporaneous understandings, agreements, representations, and warranties.

29. SURVIVAL

Sections relating to limitation of liability, indemnification, disclaimers, dispute resolution, and any other provisions that by their nature should survive, shall survive any termination or expiration of this Policy.

30. ACKNOWLEDGMENT AND ACCEPTANCE

BY USING THE SERVICES, YOU ACKNOWLEDGE THAT YOU HAVE READ THIS PRIVACY POLICY, UNDERSTAND IT, AND AGREE TO BE BOUND BY ALL OF ITS TERMS AND CONDITIONS. IF YOU ARE ACCEPTING ON BEHALF OF AN ORGANIZATION, YOU REPRESENT AND WARRANT THAT YOU HAVE THE AUTHORITY TO BIND SUCH ORGANIZATION.

---

© 2024-2026 Transcribe Health Corporation. All rights reserved.

---

EFFECTIVE DATE: December 1, 2024 LAST UPDATED: January 6, 2027 VERSION: v2026.11.7 DOCUMENT ID: POL-PRIV-2024-001