Who is responsible?
For personal data relating to patients, clients, or staff that your organisation enters into MHT, your organisation is typically the data controller for that content, and MHT is generally used as a processor on your organisation’s instructions.
For account access, authentication metadata, security logs, and operation of the software itself, the controller is the legal entity that operates this MHT deployment (for example your employer, the healthcare provider, or the SaaS operator hosting the service). If you are unsure who that is, ask your organisation’s privacy or IT contact.
This document describes processing performed by the MHT application and its standard integrations. It does not replace your organisation’s own privacy notice for healthcare or employment data.
Cookies we use
The table below lists first-party cookies set by this application or its authentication library on this site’s domain. Exact names for authentication session cookies may vary by release of our identity provider (Kinde); they remain first-party to this service.
| Cookie or identifier | Purpose | Typical maximum duration | Category |
|---|---|---|---|
| MHT_TENANT | Stores the selected organisation (tenant) identifier when you sign in without a tenant subdomain, so requests are routed to the correct workspace. | 30 days | Strictly necessary |
| Kinde authentication cookies | Session, CSRF, and related tokens issued by Kinde (our identity provider) on our domain to keep you signed in securely. | Session or as configured by your administrator / Kinde settings | Strictly necessary |
| mht_patient_session | HttpOnly token binding the browser to an active kiosk / handover patient session for secure document access. | Up to 2 hours by default (configurable via HANDOVER_PATIENT_SESSION_TTL_SECONDS) | Strictly necessary |
| mht_handover_id | HttpOnly kiosk navigation lock so staff cannot leave the handover flow on shared hardware without ending the session. | Up to 7 days by default (configurable via HANDOVER_LOCK_COOKIE_TTL_SECONDS) | Strictly necessary |
| mht_handover_reauth | HttpOnly marker requiring a fresh staff sign-in if a kiosk session was abandoned and the lock cookie later expired. | Up to 1 year | Strictly necessary |
| MHT_APP_LOCALE | HttpOnly preference for your application language, synced from your profile where available. | 1 year | Functional (preference) |
| MHT_WORKSPACE_DEFAULT_LOCALE | HttpOnly default locale for the workspace, used to resolve pages before your personal preference loads. | 1 year | Functional (preference) |
| mht-color-theme | Workspace colour theme preference for PDF previews and UI alignment (not HttpOnly). | 1 year | Functional (preference) |
| sidebar_state | Remembers whether the application sidebar is expanded or collapsed. | 7 days | Functional (preference) |
Legal basis (UK/EU)
Strictly necessary cookies are used to provide an online service you explicitly request (for example staying signed in, tenant routing, and kiosk security). They are exempt from consent under the ePrivacy Directive / UK PECR in line with ICO and WP29 guidance. Functional (preference) cookies remember non-essential choices such as UI layout or colour theme; we rely on your implied preference when you use those features, and you can clear cookies in your browser at any time.
Browser local storage
We store the workspace colour theme key (`mht-color-theme`) in local storage so the correct theme can apply before server preferences load. This mirrors the functional cookie above and is not used for advertising. You can clear site data in your browser to remove it.
Server-side logs and usage metrics
We may process server logs (for example HTTP requests, errors, and security events) on infrastructure operated by us or our sub-processors. Where we implement product analytics, we design them to avoid advertising networks and, where feasible, to avoid persistent per-user tracking in analytics events (for example aggregated or tenant-level counts). Technical data such as IP addresses in logs may constitute personal data; we use such processing for security, reliability, and service improvement. The legal basis is typically legitimate interests and/or performance of the contract, balanced against your rights; where required by law we will complete a legitimate interests assessment and support data subject requests via your organisation or our contact channel.
Performance metrics (optional)
If this deployment sets `NEXT_PUBLIC_WEB_VITALS_ENDPOINT`, the browser may send anonymised Core Web Vitals metrics to that endpoint (no advertising). If the variable is not set, this feature is inactive.
Sub-processors and integrations
Depending on configuration, data is processed using services such as:
- Kinde — authentication and organisation membership
- Google Cloud / Firebase — application data and configuration (for example Firestore) where enabled
- Hosting and edge delivery (for example Vercel) — application runtime and TLS termination
Your organisation’s data processing agreement or order form may list the definitive sub-processor register for your deployment.
Your rights
Under the UK GDPR and EU GDPR you may have rights to access, rectify, erase, restrict, or object to processing, and to data portability, where applicable. Many requests relating to health or employment data must be handled by your organisation as controller. For rights against the operator of this deployment, use the contact below.
Contact
For privacy questions about this deployment, contact the organisation that provided your account or the data protection officer named in your organisation’s privacy notice. If you operate this deployment and need product privacy documentation, maintain an internal contact published to your users.
Changes
We will update this page when our use of cookies, storage, or analytics changes materially. The date at the top states when the notice was last revised.