Cookies and browser technologies

This document describes MediSend’s first-party cookies and browser storage. Karizo EOOD operates the service technologies; the identified clinic or other sender determines the purpose and authorised access for medical files. Roles and operator details must be read with the Privacy Policy and, where applicable, the data-processing agreement.

Cookies may contain encrypted session material or random identifiers that remain personal or linkable data. Encryption and masking do not make them anonymous. Questions and requests may be sent to [email protected]. Reading this draft neither replaces the effective document nor records acceptance.

We distinguish technologies strictly necessary for an explicitly requested service from preferences and optional technologies. Necessity is assessed for the specific function; describing a technology as security-related does not automatically exempt every use from choice requirements. Personal-data information remains necessary even where consent is not required for the device storage or access itself.

The reviewed code does not implement advertising tags, marketing profiling or general behavioural analytics. This does not certify every technology in the actual deployment. Loaded scripts and network requests must be checked before publication. Any added optional technology must remain blocked pending the applicable valid choice, with accessible refusal and withdrawal. The assessment for preferences and diagnostics is a separate approval decision.

__Host-medisend_session contains encrypted material for the requested sign-in and is read by the server. The application session defaults to 12 hours, or up to 30 days when remembering the device is selected. The cookie follows the server-returned expiry; a separate eight-hour fallback applies only when no expiry is supplied. Neither eight nor twelve hours is a universal duration for every cookie. Revocation, sign-out or server-session expiry may end access earlier.

__Host-medisend_device stores a random device identifier for up to 180 days for session management and security checks. It is not an advertising identity and does not by itself authorise sign-in or file access. Approved configuration can change actual durations, which must then be reflected in this inventory.

__Host-medisend_mfa_challenge and __Host-medisend_login_challenge retain the short multi-factor or additional sign-in check for up to ten minutes. __Host-medisend_assisted_signup retains an encrypted invitation or individual offer for a selected assisted-registration process for up to 90 days by default, or until use, removal or a shorter supplied expiry. It is not medical access authorisation.

__Host-medisend_linked_challenge supports explicitly initiated account linking for up to ten minutes or the challenge’s remaining lifetime. __Host-medisend_linked_sessions retains encrypted session records for switching between linked accounts, with a browser lifetime of up to twelve hours and individual server-session expiry checks. Linking requires separate sign-in and confirmation; it does not merge permissions, medical data or billing.

__Host-medisend_transfer_claim retains encrypted proof for an explicitly requested addition of an authorised examination to a personal account for up to twelve hours. The __Host-medisend_transfer_upload_* cookies retain encrypted material for resuming a particular upload for up to 24 hours, with a limit of eight concurrent records. They do not extend source expiry or permissions and are checked for the relevant workflow.

A resume identifier or record does not confirm that a file was received, checked or sent. The server verifies state, expiry and permission, and may require the same file to be selected again after interruption. Clearing a cookie can remove the ability to resume without deleting files already received by the server.

First-party production cookies use Secure and HttpOnly, path / and __Host- names, without a shared domain for other hosts. Sessions and requested transfers use SameSite=Lax; short checks and linked-account cookies use Strict. HttpOnly restricts browser JavaScript access but does not replace device and server security.

An isolated local environment may use medisend_bff_session and names without __Host- to work over local HTTP. This exception neither describes production nor permits an insecure deployment. Older session names are cleared during the relevant authentication lifecycle. Production HTTPS, hosts and actual issued cookies must be checked before approval.

medlink-app-locale retains the chosen language. medisend:professional-preference:<user id> retains only a selected filter and sort order for the personal inbox. medisend.help.release.seen retains the last-seen release date. medisend.help.feedback.v1 retains local usefulness-response counters by article identifier; this feedback is not sent as external analytics.

medisend.uploads.v1 retains opaque identifiers and scope hashes, expiry values and technical upload flags. Secret resume material is retained in encrypted HttpOnly cookies rather than this record. The local record contains no medical filenames, contents, patient fields, PINs or authentication tokens. Pointers may remain until completion, dismissal, subsequent cleanup or browser removal; server expiry still limits their use.

medisend:auth-change and medisend:workspace-change contain only random signals to notify other open tabs of authentication or workspace changes. They contain no clinic contents or credentials. The reviewed implementation has no local medisend:pinned-packages registry or medical IndexedDB store. Private notes and current medical payloads are not written to the listed persistent browser storage.

The interface temporarily displays medical data, files, a PIN or an authorised link in page memory to perform the requested task. This differs from persistent browser storage. Downloads, printouts, screenshots and copied text remain under the recipient’s and device’s control; revoking access does not remove those copies.

On a shared device, sign out, avoid remembering the device and remove unwanted downloads and site data. Clearing local preferences does not erase accounts, clinical records or accounting documents on the server. Use the privacy contact for a verified personal-data request.

Cloudflare Turnstile loads on configured protected forms to counter automated abuse. The provider may process IP addresses, headers, challenge interaction and device signals. It is not presented as advertising, but its role, necessity, actual technologies and transfers must be assessed for the deployment.

Stripe opens following a selected payment or customer-portal action and may use its own technologies for the requested payment process and fraud prevention. This does not authorise automatic charging. Applicable notices, contracting recipient and locations must be confirmed in the supplier register.

Sentry operates only when configured. The code sends a limited scrubbed diagnostic event and excludes request bodies, user context, raw messages, arbitrary tags, breadcrumbs, application logs, request tracing and session replay. It is not general behavioural analytics. The network provider may observe technical transport data; retention, region and the applicable basis require separate confirmation.

You can inspect, block and remove site data through your browser. Blocking necessary cookies may interrupt sign-in, checks, account linking or upload recovery. This inventory is updated when a function, duration, supplier or legal basis changes; editing the notice alone does not activate a new optional use.

Before final approval, the operator documents actual production technologies, durations and recipients, and legal counsel assesses compliance with device storage/access and personal-data rules. Requests are verified proportionately; clearing cookies does not automatically erase all server-held data.