Data Handling Policy & Procedures — Clinics and Marketplace Vendors

Last updated: 20 September 2026 · Version: 1.0 (draft — pending legal review)

This document sets out, for Clinics, Clinic staff, and marketplace Vendors, how Levantra handles data in practice, what a Clinic may and may not do with client data accessed through the Platform, our security and audit measures, our sub-processors, and our procedures for data-subject requests and security incidents as they touch business partners. It is the operational companion to /en/pages/privacy/clinics-vendors.

1. Purpose and scope

This policy applies to every Clinic and Vendor account, every staff member a Clinic invites onto the Platform, and every system that processes their data or, on their behalf and with client consent, a client's data.

2. Roles and the permission model

A Clinic's staff access is governed by roles, each a named bundle of granular permissions (for example: view clients, edit clinical notes, manage the product catalog, manage staff, view billing) rather than hard-coded job titles. A Clinic assigns one or more roles to each staff member and can create custom roles. This means:

A Catalog Manager role can curate which products the Clinic recommends without ever having access to clinical notes.
A Receptionist/Scheduler role can manage the appointment calendar and client invitations without clinical-notes access.
A Specialist role sees only the clients assigned to them, can adjust routines, message clients, and write clinical notes.
A Billing Viewer role (optional) has read-only access to subscription, invoices, and commission reports, and nothing else.
An Owner role has full account control.

Every permission check happens in application code at the moment of the request; a role that does not grant a permission cannot be worked around by knowing a record's identifier.

3. What a Clinic may and may not do with client data

A Clinic's access to a client's data is strictly scoped to what that client has consented to share with that specific Clinic, and to the purpose of providing that client's requested consultation or treatment guidance. Specifically:

A Clinic may view and act on the parts of a client's profile, analysis history, and routine the client has consented to share, write clinical notes about the engagement, adjust the client's routine, and message the client.
A Clinic may not access, in any form, a client's conversation with the Platform's AI assistant. This is enforced structurally: the two conversations are stored and served through entirely separate code paths, and the assistant conversation is never included in what a specialist reads, even when a specialist and the AI conversation concern the same client on the same day. The only thing that ever crosses from the AI conversation to a Clinic is a routine the client explicitly chooses to send for review.
A Clinic may not export, copy, retain outside the Platform, or reuse client personal data for any purpose beyond that client's own consultation — including not using it for the Clinic's own separate marketing, research, or any other client relationship.
A Clinic may not access a client's data before the client's link to that Clinic is active, and may not access a former client's data after the client has revoked that consent or unlinked from the Clinic, other than the Clinic's own already-written clinical notes, which remain the Clinic's business record.
Writing to your own Clinic is never gated by what a client's plan includes — the conversation between a client and their own linked Clinic is a service the Clinic provides its own patient, independent of the client's Platform subscription tier.

4. Security requirements

Staff accounts require a password meeting the Platform's password policy; two-factor authentication is available and its use is encouraged, particularly for Owner and Specialist roles.
A person's Clinic staff identity and their own personal customer account (if they have one) are kept as separate logins — inviting a customer's email address as staff does not silently convert their personal account, and a staff invitation is refused outright if it would create that overlap.
Sessions are short-lived and refreshable; a password change revokes other active sessions.
A Clinic is reduced to, at minimum, one Owner-role staff member at all times where technically enforceable, so a Clinic can never be left with no one able to manage its own staff.

5. Audit logging

Every access a staff member makes to a client's clinical data — viewing a profile, reading an analysis, writing or editing a note, adjusting a routine — is logged with the acting staff member, the action, the client record affected, and the timestamp. This log is retained as an accountability record independent of the underlying data's own retention period, and is available to support a Clinic's own compliance obligations as a data controller for that data (see /en/pages/privacy/clinics-vendors §2).

6. Sub-processors

The same sub-processors described in /en/pages/data-handling §6 process Clinic and Vendor data in their respective roles (hosting, email delivery, payment/payout processing). Additionally, for Vendors specifically:

Sub-processor	Role	Data involved
Stripe Connect	Vendor payout processing	Payout account details, transaction amounts, commission split

7. International transfer mechanisms

See /en/pages/data-handling §7 — the same mechanisms and review note apply to Clinic and Vendor data.

8. Financial and payout data handling

Commission rates are individually agreed per Clinic and recorded on the Clinic's account; the platform-wide per-extra-seat subscription rate is set by us and applied uniformly, not negotiated per Clinic.
Marketplace sales referred by a Clinic are split automatically at the point of payment: the Vendor's share, our commission, and — where a sale was referred by a Clinic — the Clinic's individually agreed additional commission, are calculated and recorded in a commission ledger.
Vendor payouts are processed through our payment processor's connected-account product; we do not ourselves hold Vendor bank account numbers.
Invoices issued to Clinics are numbered sequentially with no gaps, allocated at the point of issuance, to meet standard invoicing-integrity expectations.

9. Data-subject request handling involving a Clinic

Where a client's request concerns data the Clinic itself controls (its own clinical notes), we notify the Clinic and support it in responding as the controller, consistent with /en/pages/privacy/clinics-vendors §9.
Where a client deletes their own Platform account, any request they had open with a Clinic is closed out as part of that deletion, and the Clinic is left with its own record of the closed request as its business record — the Clinic is not left with an indefinitely "pending" item referring to an account that no longer exists in any meaningful sense.
Where a Clinic itself is closed, its own staff and business records are retained per /en/pages/privacy/clinics-vendors §8; clients previously linked to it are not otherwise affected in their own accounts.

10. Security incident / breach notification

See /en/pages/data-handling §10 — the same procedure applies. Where an incident specifically involves data a Clinic controls (its own clinical notes), we additionally notify the affected Clinic promptly so it can meet its own notification obligations as a controller.

11. Termination and data return/deletion

On termination of a Clinic's or Vendor's agreement with us: staff access is revoked; the account is deactivated; financial and audit records are retained per §8 and the retention schedule in /en/pages/privacy/clinics-vendors §8; and, on request and where technically and legally feasible, we will support a Clinic's export of its own business and clinical-note records before deactivation. [Legal review note: the exact data-return process and timeline should be specified in the Clinic-facing agreement, not left to this policy alone.]

12. Vendor and Clinic due diligence

Before onboarding a new Vendor or approving a Clinic's application, we review the business information provided in /en/pages/privacy/clinics-vendors §3.1–3.4. [Legal review / operational note: document your actual verification steps here — for example, business registration checks, and Stripe Connect's own KYC process for payout accounts.]

13. Review cadence

See /en/pages/data-handling §14 — the same review cadence applies.

This document is a draft prepared for legal review and has not yet been finalized by counsel.