ScriBee

Política de privacidad de ScriBee

Cómo ScriBee recopila, utiliza y protege sus datos como escriba médico con IA y plataforma de documentación clínica.

Lynx ERP Solutions Inc. · Revision date: September 30, 2026

ScriBee helps healthcare professionals prepare clinical documentation. This Policy explains how Lynx ERP Solutions Inc. (Lynx, we, us or our) handles personal information through the ScriBee web application, browser extension, websites and related services. It covers account holders, clinic staff, patients whose information is processed, website visitors and people who contact us.

1. Who is responsible for your information

We are responsible for personal information we collect for our own account administration, billing, security and communications. For patient information, we act on the instructions of the clinician, clinic or other organization responsible for that information, referred to here as the Customer. The Customer’s legal role depends on its jurisdiction and activities; an individual staff member is not necessarily the health information custodian.

In Ontario, our role may be that of an agent or electronic service provider under the Personal Health Information Protection Act, 2004 (PHIPA), as applicable. Other laws may apply in other jurisdictions. These descriptions do not establish that a particular deployment satisfies every applicable law.

Schedule A of the ScriBee Terms of Service governs our processing of patient information. HIPAA-regulated use requires a separate applicable business associate agreement and a deployment approved for that use before protected health information is submitted. The standard Terms alone are not a representation of HIPAA compliance.

Patients should normally direct health-record questions and access or correction requests to their clinician or clinic. We will help identify the appropriate Customer and securely route requests where appropriate, without disclosing information to an unverified recipient.

2. Information we handle

Account and clinic information includes names, professional details, contact information, clinic details, team membership, roles, preferred languages and, where supplied, profile images, clinic branding and signature images. A signature image is sensitive and should be uploaded only by someone authorized to use it.

Authentication and security information includes login credentials or authentication identifiers, session tokens, security settings, sign-in events, IP addresses and browser or device details. If Google Sign-In is used, basic profile information is received for authentication. Any separate integration is governed by the permissions requested for that integration.

Patient information may include identifiers and contact details; health card, medical record and insurance information; encounter audio and transcripts; clinical histories; uploaded charts, referrals, laboratory reports, images and PDFs; intake responses; appointment information; and clinician-entered observations. AI prompts and outputs may include draft notes, letters, handouts, orders, tasks, coding suggestions and questions or answers about a patient record, where those features are enabled.

Operational information includes feature usage, errors, diagnostics, audit events and support correspondence. Audit records may contain patient identifiers and versions of clinical content. We treat such material as patient information rather than assuming that all logs are anonymous. Payment records include subscription and transaction information; payment card details are handled through the payment processor.

Information comes from account holders and clinic administrators, patients or their authorized representatives where an intake feature is used, authorized record imports and integrations, and technical operation of the Services. We seek to collect only the information necessary for the relevant purpose.

3. Browser extension and device permissions

The extension supports user-initiated capture of content from an authorized EMR page, recording and transfer of documentation where supported. Before capture, check the patient, page and content selected. A page may contain information about other people; avoid including it unless necessary and authorized.

Recording requires the relevant microphone and, for supported virtual visits, tab or system-audio permissions. Browser sharing controls may expose more content than intended. Select the narrowest available sharing option and stop sharing when finished. Do not assume that every screen-sharing selection captures audio or that every integration handles video in the same way.

Local browser or extension storage may contain authentication tokens, settings, patient or encounter context, draft transcripts, consent confirmations and pending audio. Shared or unmanaged devices may expose this information. Revoking a browser permission does not delete information already uploaded; signing out, deleting a session and closing an account are separate actions.

4. Purposes and limits on use

We process patient information to deliver the Customer’s requested transcription, documentation, extraction, record assistance, scheduling, intake, export and communication functions, and to support their secure operation. We also process it where required by law. Access by personnel must be limited to authorized duties, including necessary troubleshooting and incident investigation.

We use account and operational information to authenticate users, manage subscriptions, prevent misuse, resolve support requests, maintain service reliability and meet legal obligations. We may use non-clinical usage statistics to improve the Services. Patient content is not available for unrelated product development merely because it is labelled de-identified or aggregated; any such use requires a separate lawful basis and the Customer’s express written authorization.

We do not sell patient information or use it for advertising. We do not use patient information to train AI models. Providers processing patient information on our behalf must be engaged under contractual restrictions consistent with these limits; a consumer or free AI service must not be substituted where its terms permit incompatible use.

We may send account and service notices. Marketing messages are separate, use appropriate consent where required, and include a way to unsubscribe. Unsubscribing from marketing does not stop necessary security, billing or service notices.

5. Artificial intelligence processing

Audio, text, documents and relevant record context may be transmitted to AI and speech-recognition providers to perform the requested task. Names and other identifiers may be present; removing a patient name alone does not necessarily make clinical content anonymous.

For patient-record questions, relevant chart material, transcripts or draft notes may be included in the request. Users should avoid adding patient details to general questions when those details are unnecessary. Outputs can omit, misinterpret or invent information and must be reviewed by the responsible clinician before use.

A paid API subscription or a no-training term does not establish permission for clinical use. The selected provider contract must expressly permit the intended healthcare workflow and meet the applicable information-protection requirements. No model-training use does not mean no provider retention. Providers may temporarily retain inputs or outputs for service delivery, security or legal obligations, depending on the contracted service and configuration. The applicable processing arrangements must identify these uses and limits. We do not make a blanket zero-retention or Canada-only processing promise.

6. Consent and choices

The Customer must have lawful authority to submit information and must explain the proposed recording and AI-assisted processing to patients, including relevant external processing. The clinician must obtain and document consent when required, respect a refusal or withdrawal, and address capacity, substitute decision-makers, interpreters and other participants as applicable.

A consent checkbox records the user’s confirmation; it does not independently establish that valid consent was obtained. Patients who decline should be offered an appropriate alternative documentation workflow. Stopping recording prevents further capture but does not automatically erase an existing record that must lawfully be retained.

Account holders may ask to withdraw consent to optional uses or close their account. Some processing is necessary to deliver the Services or comply with law. We will explain the implications and any lawful retention when responding.

7. Service providers and other disclosures

We use providers for hosting and storage, speech recognition, AI processing, transactional email, payments, authentication and abuse prevention. The provider arrangements described for ScriBee include Google Cloud Platform for hosting, Google AI services for generation, Soniox for transcription, Stripe for billing, Amazon Web Services SES for email, and Google Sign-In or anti-abuse services such as Cloudflare Turnstile or Google reCAPTCHA where enabled. Deepgram may be used as an alternative transcription provider where enabled. The Customer’s written processing configuration identifies the providers actually authorized for its deployment.

Before patient information is processed, that configuration must identify each provider receiving it, the service and purpose, relevant data categories, processing and storage countries, retention arrangements and contractual restrictions. Customers may request the current provider information through our privacy contact. Schedule A governs changes and objections.

We disclose information within a clinic according to authorized roles and sharing settings, and to recipients or integrations the Customer directs. Users must verify destinations before sending documents. Ordinary email may create additional privacy risk; use an approved secure transfer method for patient information.

We may disclose information where required or permitted by applicable law, including a valid legal demand or a lawful emergency disclosure. We limit disclosure to what is necessary and notify the Customer where legally permitted. A business transfer is subject to applicable law and continuing confidentiality and purpose restrictions; it does not authorize unrelated reuse of patient records.

8. Storage and processing locations

Hosting location and processing location are different. Information may be processed outside Canada, including in the United States, through the transcription, AI or other providers used for a deployment. Backups, technical support access and provider logs must also be considered when assessing location requirements.

Foreign laws may permit access by courts, regulators or public authorities. Contractual and technical safeguards reduce risk but cannot eliminate foreign legal requirements. A Canadian hosting region alone does not establish that all information remains in Canada. Customers with residency restrictions must obtain a compatible written processing configuration before use.

9. Data Retention and Deletion

9.1 Infrastructure & Enterprise Scope

ScriBee processes all patient interactions, audio recordings, clinical prompts, generated notes, and transcripts via enterprise-grade Google Cloud Vertex AI infrastructure operating under a signed Business Associate Agreement (BAA). Customer Protected Health Information (PHI) and clinical inputs processed by Gemini models via Vertex AI are never retained, logged, or utilized by Google or ScriBee to train, fine-tune, or improve public or proprietary foundational AI models.

9.2 Customer-Configured Retention Lifecycle

We retain Customer Data, including PHI and clinical records, solely to fulfill the services described in this Agreement and to satisfy applicable statutory obligations. The Customer (as the Covered Entity or Data Controller) retains sole operational authority over the retention and deletion schedules for:

  • Source audio files and raw upload buffers
  • AI-generated clinical notes, summaries, and transcripts
  • Prompt/response logs and audit trails

Source audio and raw upload files are stored temporarily in transient memory/encrypted local buffers only for the duration required to complete speech-to-text processing and note synthesis. The generation or export of a clinical note does not automatically imply the deletion of underlying source audio unless configured by the Customer’s designated retention workflow.

9.3 Medical Record System of Record

ScriBee is a documentation processing assistant and does not serve as a primary Electronic Health Record (EHR) or legal medical record repository. The Customer remains solely responsible for exporting, archiving, and maintaining required clinical documentation within its designated legal EHR or medical record system in compliance with applicable federal, state, and provincial medical board retention laws.

9.4 Deletion, Backups, and Legal Holds

Upon a customer-initiated deletion request or account termination:

  • Active database records and associated transient files are permanently purged from primary application servers.
  • Residual copies held in encrypted system backups, disaster recovery snapshots, or immutable security audit logs will be rendered inaccessible and completely overwritten according to ScriBee’s automated backup rotation cycles (not to exceed 30 days).
  • Deletion may be delayed or restricted solely where required by a binding court order, legal hold, or mandatory regulatory obligation. Where legally permissible, ScriBee will notify the Customer of any such statutory retention exception.

9.5 Account, Billing, and Administrative Records

Non-PHI administrative data (including account metadata, subscription details, billing history, and security logs) are retained separately in accordance with applicable tax, legal, and corporate compliance frameworks. Subscription cancellation or account deactivation does not automatically purge non-PHI accounting records required by law. Comprehensive data export and account offboarding procedures upon contract termination are detailed in Schedule A.

10. Safeguards and incidents

Our contractual safeguards include appropriate encryption in transit and at rest, access controls, confidentiality obligations, auditability, security maintenance and incident response. The Customer should review the safeguards applicable to its deployment, enable available multifactor authentication and secure its devices. No service can guarantee absolute security or uninterrupted access.

Where we process patient information for a Customer, we notify it of a relevant privacy or security incident at the first reasonable opportunity and without unreasonable delay, subject to any stricter legal or contractual duty. We provide available information, updates and cooperation for containment, investigation and required notifications.

For information for which we are independently accountable, we assess and make notifications required by the applicable law. PIPEDA’s real-risk-of-significant-harm test is not a universal threshold for all PHIPA reporting or notification duties. We retain incident records as required and coordinate communications without delaying a legal deadline.

11. Access correction and complaints

Depending on the applicable law, you may request access to your personal information, correction, details about its use or disclosure, withdrawal of consent, or deletion subject to lawful limits. Health records do not carry an unrestricted right to erasure. Requests concerning restrictions on patient information, including applicable PHIPA consent directives, should be addressed to the responsible clinic.

We verify identity and authority using proportionate measures. Do not email identity documents or clinical records unless a secure method has been arranged. We respond within the applicable legal period, explain any permitted extension, refusal or fee, and provide complaint options. Customers receive assistance needed to meet their own deadlines.

You may complain to the Office of the Privacy Commissioner of Canada at www.priv.gc.ca or the applicable provincial authority, including the Information and Privacy Commissioner of Ontario at www.ipc.on.ca. You need not first resolve a complaint with us before exercising a regulatory right.

12. Cookies children and policy changes

Cookies, tokens and browser storage may be used for authentication, security and preferences. Disabling essential storage may affect operation. Optional analytics or advertising technologies, if introduced, require an appropriate notice and consent mechanism where applicable; this Policy does not authorize undisclosed tracking of clinical content.

Professional account holders must meet the age and authority requirements in the Terms. Clinicians may document care for patients of any age and remain responsible for applicable capacity and consent requirements. The Services are not marketed as an independent healthcare service for children.

We communicate material changes by email or in the Services before they take effect, except where an earlier change is required by law or urgent security needs. A policy update does not by itself authorize a new incompatible use of patient information. The effective date will be identified in the publication or change notice.

13. Contact

Contact Lynx ERP Solutions Inc. at hello@aiscribee.com. For privacy matters, address the message to the Privacy Officer and use the subject Privacy request. For a suspected incident, use Urgent security incident. Do not include patient details in an ordinary email. Request a secure channel if sensitive information is necessary.

ScriBee web application app.aiscribee.com