Omi Scribe Cloud — Privacy Notice
Version: 1.6
Effective: 11 May 2026
Provider: Omi Health B.V., Eindhoven, Netherlands
Contact: [email protected]
This Privacy Notice applies to Omi Scribe Cloud (the “Service”) and related support services. It does not apply to Omi Scribe for Mac (Offline), which has a separate privacy policy at /legal/mac-privacy.
This Notice is written for:
- Customers (clinics, hospitals, practices) evaluating or using the Service; and
- End users (clinicians and staff) using the Service under a Customer account.
> Important: For patient-related content, the Customer is typically the data controller. Omi Health typically acts as a processor for that content.
1. Summary
Omi Scribe Cloud is built to be privacy‑first:
- We process audio, transcripts, and clinical drafts only to provide the Service.
- No training on your content. We do not use Customer Content to train, fine‑tune, or evaluate machine learning models.
- Review‑first. Outputs are AI‑generated drafts with evidence links that point each generated claim back to its source segment in the transcript, so the clinician can verify before finalising. The clinician reviews and finalises as the sole author of the clinical record.
- Regional data residency. The Service is deployed in three regional clouds — EU (Azure Sweden Central), Australia (Azure Australia East — serves ANZ), and US (Azure Central US). The Customer selects the region at order time. Customer Content is stored and processed within the selected region and is not pooled across regions or customers. UK customers are served from the EU region today; a UK‑resident option is on the roadmap.
- Multilingual. The Service supports Dutch, English, German, French, and Spanish today. AI inference for each language is provided through the regional sub‑processor stack (see /legal/sub-processors).
- You control retention and deletion of Customer Content through tenant settings.
- Enterprise security pack available under NDA (DPA, DPIA, ROPA, incident response, and security policies). Region‑specific addenda are available for UK, Australia, and US Customers — see Section 12 and the linked addendum documents.
2. Roles and responsibilities
2.1 Customer Content (patient-related)
If you use the Service through a clinic, hospital, or other organisation (the “Customer”), that Customer is typically the Controller for patient-related content (“Customer Content”). Omi Health B.V. acts as a Processor and processes Customer Content only on the Customer’s documented instructions, as set out in the service agreement and Data Processing Addendum (DPA).
2.2 Service Data (account and operational)
Omi Health B.V. is the Controller for “Service Data” used to operate the Service (for example: account details, authentication logs, security logs, billing and usage data, and service communications). This Privacy Notice covers Service Data.
3. What we process
3.1 Customer Content (processed on the Customer’s behalf)
Depending on the Customer’s configuration and use, Customer Content may include:
- Audio recordings or uploaded audio files
- Speaker‑labelled transcripts (diarisation)
- AI‑generated draft notes (e.g., SOAP), letters, and summaries
- Structured clinical extraction outputs (e.g., problem list, medications, assessment/plan fields)
- Session metadata (timestamps, language, session identifiers)
Customer Content may contain special category data (health data) and sensitive information.
3.2 Service Data (processed by Omi Health as Controller)
Service Data may include:
- Account and profile: name, work email, organisation/tenant, role
- Authentication and access: login timestamps, IP address, device/browser metadata, token/session identifiers
- Audit and security logs: user actions (e.g., create session, delete session, export), admin actions, and security events
- Usage and billing metrics (more granular than “feature usage”):
STT and LLM provider and model identifiers, audio duration, token counts (input/output), estimated cost, template identifiers, locale, and operation types (e.g., STT, finalise note, extract, regenerate)
- Support communications: emails or tickets you send to us (and our responses)
We design logs and telemetry to avoid storing clinical content, and we do not intentionally log Customer Content.
3.3 Cookies and similar technologies
The web app uses essential cookies to provide secure authentication and session management.
- We use an HTTP‑only refresh token cookie (typically named `refresh_token`) with a maximum lifetime of 30 days to keep users signed in.
- We do not use cookies for behavioural advertising.
If we add non-essential analytics cookies in the future, we will provide appropriate notice and consent controls where required.
4. Why we process information (purposes and legal bases)
4.1 Customer Content (processor purposes)
We process Customer Content solely to provide the Service under the Customer’s instructions, including:
- transcription and diarisation
- drafting notes and structured extraction
- displaying and storing sessions as configured
- enabling exports and integrations initiated by users/admins
- security and abuse prevention
4.2 Service Data (controller purposes)
We process Service Data for:
- Providing and operating the Service (GDPR Art. 6(1)(b) — contract)
- Security, abuse prevention, and reliability (GDPR Art. 6(1)(f) — legitimate interests; and Art. 6(1)(c) — legal obligations where applicable)
- Billing and subscription management (contractual necessity; legal obligations)
- Customer support (contractual necessity; legitimate interests)
- Product improvement using aggregated and/or de‑identified telemetry (legitimate interests)
We do not use Customer Content to train models.
5. How the Service uses AI models
The Service processes Customer Content using speech-to-text and language models to provide transcription and draft generation:
The Service uses dedicated GPU VMs and Azure AI Foundry (Data Zone Standard) within the Customer's region. All AI processing stays in-region. Azure AI Foundry operates under Microsoft enterprise terms and does not use customer data for model training.
Real‑time streaming transcription
The Service may support real-time streaming transcription. Streaming audio is processed incrementally and held in memory during the session by the STT component. Customer Content retention is governed by the Customer’s configuration and storage settings for the session.
6. Sharing and disclosures
We do not sell Customer Content or Service Data.
We may share information in these limited cases:
A) Sub‑processors
We use vetted service providers (“sub‑processors”) to host and operate the Service (for example, Microsoft Azure and Azure AI services). Sub‑processors are contractually bound to process data only to provide services to us and to protect it.
A current list of sub‑processors is available at /legal/sub-processors.
B) Customer-controlled integrations
If the Customer enables integrations (e.g., EHR export, storage export, identity provider, or other internal tools), Customer Content may be transmitted to those systems under the Customer’s control and terms.
C) Identity providers (SSO)
If a user logs in via a third-party identity provider (e.g., Microsoft or Google), the login flow is handled by that provider under its own privacy policy. We receive only the profile information necessary for authentication (typically name and email). No Customer Content is shared with identity providers.
D) Support and troubleshooting
Authorized Omi Health personnel may access Service Data and (where necessary and permitted) limited Customer Content to provide support, resolve incidents, or investigate misuse. Access is restricted by role, logged, and limited to what is necessary.
E) Legal and safety
We may disclose information where required by law or valid legal process, or to protect the rights, safety, and security of the Service, our Customers, users, and the public.
7. Data residency and international transfers
7.1 Available hosting regions
| Region | Azure location | Live status | Customers served |
|---|---|---|---|
| EU | Sweden Central | Live | EU/EEA, UK (served from EU today; UK-resident option on the roadmap), and any Customer selecting the EU region |
| ANZ | Australia East | Rolling out | Australia, New Zealand, and any Customer selecting the ANZ region |
| US | Central US | Rolling out | United States and any Customer selecting the US region |
The Customer selects the region at order time. Customer Content and Service Data are stored in the selected region. Each region is an isolated deployment — Customer Content is not pooled across regions or across Customers.
7.2 AI processing within region
AI processing uses dedicated GPU VMs and Azure AI Foundry (Data Zone Standard) within the Customer’s region. See /legal/sub-processors for the per‑region detail.
7.3 Cross-border situations
- UK ⇄ EU. Where Customer Content is transferred from the UK to the EEA for processing in the EU region, transfers rely on the UK government’s adequacy decision for the EEA. Where adequacy is unavailable, the UK International Data Transfer Agreement (IDTA) or the UK Addendum to the EU Standard Contractual Clauses is used.
- EU ⇄ US. Where Service Data limited support access from the EU touches US-located staff or systems, transfers rely on EU Standard Contractual Clauses with supplementary measures (encryption, access controls, audit logs). Microsoft Corporation is certified under the EU‑U.S. Data Privacy Framework for the services it provides.
- AU ⇄ EU/US. Customer Content for ANZ Customers is stored and processed in Australia East. Where Service Data limited support access touches EU- or US-located staff, appropriate safeguards (contract terms, encryption, access controls) apply.
7.4 Remote access and transfers
Authorized remote access (for example, support or incident response) may occur from locations outside the Customer’s selected region. Where such access constitutes an international transfer, we rely on appropriate safeguards (such as Standard Contractual Clauses, the UK IDTA, or the relevant Azure data‑plane terms) and technical measures (encryption, access controls, audit logs). Remote access to Customer Content requires a documented support ticket and is logged.
8. Retention and deletion
8.1 Customer Content
Customer Content retention is controlled by the Customer’s tenant settings. The Service applies the following default retention periods (configurable per tenant):
- Audio recordings: 7 days
- Transcripts, notes, and structured extraction: 90 days
- Audit logs: 6 years (not configurable; required for compliance)
- Usage metrics: 2 years
Customers may shorten defaults (including immediate deletion of audio after transcription) or extend them as needed for their regulatory and clinical requirements. Manual deletion of individual sessions is available at any time.
Audio files are stored in Azure Blob Storage and subject to lifecycle management (tiered to cool and archive storage before deletion). An automated purge process runs daily to enforce configured retention policies.
8.2 Backups
Encrypted backups may retain deleted data for a limited period for disaster recovery. Current PostgreSQL backup retention is up to 35 days. Backup retention may change as the Service hardens, but is not intended for “archival use.”
8.3 Service Data
Service Data is retained as needed to provide the Service and comply with legal obligations (for example, accounting and tax retention). We minimise retention where possible.
9. Security measures
We implement technical and organisational measures designed to protect Customer Content and Service Data, including:
- Encryption: TLS in transit; encryption at rest (Azure-managed encryption for infrastructure, plus application-layer AES-256-GCM encryption for clinical content fields)
- Access controls: role‑based access, least privilege, strong authentication via OIDC/SSO
- Tenant and user isolation: tenant-scoped queries and user-scoped access for clinician sessions
- Logging and monitoring: audit logs and operational telemetry designed not to contain Customer Content
- Secrets management: Azure Key Vault and managed identities for service-to-service access
We maintain documented internal security policies (information security, access control, data classification) and an incident response plan. These are available to enterprise Customers under NDA.
Network isolation features (such as private endpoints and additional network segmentation controls) are supported by the architecture and are implemented progressively as part of security hardening.
No system is perfectly secure, but we design the Service to reduce exposure and access to sensitive data.
10. HIPAA (United States)
If the Service is used by a HIPAA Covered Entity (or its Business Associate) to process Protected Health Information (PHI), a Business Associate Agreement (BAA) must be executed.
- If a BAA is in place, Omi Health B.V. will act as a Business Associate and process PHI under the terms of the BAA.
- If no BAA is in place, the Customer must not submit PHI to the Service.
BAA inquiries: [email protected].
11. Your rights and choices
11.1 If you are a patient
For patient-related Customer Content, the Customer (e.g., your clinic) is typically the Controller. Please contact your clinic to exercise rights. Omi Health can act only on the Customer’s instructions.
11.2 If you are an end user or business contact
You may have rights to access, correct, or delete your Service Data. To request this, contact [email protected].
We may need to verify identity and authority before fulfilling requests.
12. Regional disclosures
12.1 EEA (GDPR)
Where Omi Health is Controller for Service Data, legal bases include contract performance, legitimate interests, and legal obligations. You may have rights under GDPR (access, rectification, deletion, restriction, objection, portability). You may lodge a complaint with your supervisory authority. For the Netherlands: Autoriteit Persoonsgegevens (autoriteitpersoonsgegevens.nl).
Where Omi Health is Processor for Customer Content, we process that data only on the Customer’s documented instructions under the DPA.
12.2 United Kingdom (UK GDPR + Data Protection Act 2018)
UK customers are served from the EU region today (Azure Sweden Central). Transfers between the UK and the EEA rely on the UK government’s adequacy decision for the EEA; where adequacy is unavailable, the UK International Data Transfer Agreement (IDTA) or the UK Addendum to the EU SCCs is used. UK data subjects may lodge complaints with the Information Commissioner’s Office (ICO) (ico.org.uk). See also the UK Privacy Addendum at /legal/uk-privacy-addendum.
12.3 Australia and New Zealand (Privacy Act 1988 + Australian Privacy Principles; NZ Privacy Act 2020)
ANZ customers are served from the Australia East region; Customer Content is stored and processed in Australia. We handle personal information in accordance with the Australian Privacy Principles (APPs). Notifiable data breach assessment under Part IIIC of the Privacy Act 1988 applies; we will notify affected Customers and (where required) the Office of the Australian Information Commissioner (OAIC) (oaic.gov.au) consistent with our DPA and incident response plan. NZ data subjects may contact the Office of the Privacy Commissioner (privacy.org.nz). See also the AU/NZ Privacy Addendum at /legal/au-privacy-addendum.
12.4 United States (CCPA/CPRA and other state laws)
We do not sell personal information and do not share it for cross‑context behavioural advertising under CCPA/CPRA. US residents (including California, Virginia, Colorado, Connecticut, Utah, Texas, and other states with comprehensive consumer privacy laws) may have rights to know/access, delete, correct, and limit use of sensitive personal information where applicable. HIPAA-regulated workflows require a Business Associate Agreement (BAA) — see Section 10. To exercise rights: [email protected]. See also the US Privacy Addendum at /legal/us-privacy-addendum.
13. Children
The Service is not intended for children under 16 and should be used only by authorised healthcare professionals in lawful workflows. Customers are responsible for obtaining any required consents for recordings and processing in their care setting.
14. Changes
We may update this Privacy Notice from time to time. We will publish updates at /legal/cloud-privacy and update the effective date. Material changes may be communicated through the Service or to account administrators.
15. Contact
Omi Health B.V. — Eindhoven, Netherlands
Email: [email protected]