Retention, archive and deletion

MediSend provides file exchange and controlled access, not an indefinite medical-record archive. The customer determines necessary retention for customer medical data, its lawful basis and processor instructions. Karizo EOOD manages separate periods for its contractual, accounting and security records. Statutory medical-record periods must be assessed for the customer and document type.

The customer exports and retains records it must keep outside the service. A product default is not medical-record retention advice and does not replace an agreed limit or statutory duty. Final periods and their implementation process require approval before this policy is published.

A named recipient has a separate access period, defaulting to seven days and up to thirty days under the current policy, also bounded by the available source’s retention deadline. Patient Keys, their grants and public sessions may have different periods. The displayed expiry for the particular resource governs; registration, saving an examination or linking accounts does not extend it.

Expiry and revocation end subsequent access through the particular authorisation without destroying the file or every other grant. Patient Key reissue or revocation must not be represented as revoking separately issued permissions. Downloaded, printed or copied data remain with the recipient and are governed by their applicable duties.

Revocation applies to new authorised application requests. Transfers already started, received bytes, browser caches or separately issued short-lived addresses are not represented as instantly terminated or erased. Current downloads use application streaming; signed S3 part-upload addresses have a separate bounded lifetime. Actual delivery and residual copies must be verified for the particular deployment.

Current code defaults establish a sixty-day active period and an overall 365-day period measured from handover creation. The overall period is not an additional 365 days after the first sixty. Configuration, agreement and applicable law can require different values; actual dates are displayed in the handover.

Reaching a date alone does not guarantee physical archiving or deletion. Archiving checks handover completion, outstanding information and required replies or acknowledgement. Holds and other conditions can postpone an action. Those safeguards do not relieve the operator of reviewing records retained beyond the approved period.

Files have a separate recorded lifecycle policy. The current standard model provides sixty active days, an infrequent-access class from day 61, an archive class from day 181 and overall retention of 365 days. Deep archive is disabled by default. These are code/policy values; actual classes and transitions depend on applied storage rules and state reconciliation.

An archived file may require preparation before download. Requested, processing, ready and expired temporary-copy states are distinct, with no promise of immediate restoration. The standard prepared-copy duration is seven days according to the file policy. Preparation creates no new medical permission and does not automatically alter overall retention.

Execution and post-expiry deletion are not universally enabled: the standard execution, production-deletion and per-file deletion-policy flags are disabled. The scheduled deletion command defaults to a non-deleting review. Actual deletion requires permitted configuration, a confirmed action, a due applicable period and checks of the particular file and storage target.

Deletion can be blocked by an incomplete check, active recipient access, an active Patient Key or separate grant, a pending/approved renewal, archive preparation, a valid temporary copy, legal hold or extended expiry. Physical archiving also checks active rights and outstanding handover responsibility. Failed removal is not marked successful; the record remains for review and an eligible retry.

Successful file-byte removal records deletion and ends delivery of that content from primary storage. It does not automatically delete the file or handover database row. The code can retain the original filename, storage path/key and disk, checksum, size, timestamps, reason, clinical title, patient references, messages, context and other metadata.

Those records can contain or reveal health and other personal data. They are not described as anonymous or merely technical evidence. They require separate approved retention, access limits and minimisation, erasure or lawful-hold processes. No universal automatic process is established that turns every deleted file into anonymous history.

Personal saved markers and notes belong to the receiving account and particular grant. Saving does not extend access, create a medical-storage copy or acknowledge review/reply. Revocation, expiry or permission loss makes the personal work inaccessible through the interface and API.

Saving or editing a private note establishes the earlier of ninety days and current source/grant expiry. Toggling the saved marker does not restart that period. Removing or emptying a note clears its encrypted contents; periodic cleanup removes expired notes and ineligible records. Later access renewal does not resurrect a deleted note. Backups follow a separate regime.

For raw file evidence submitted for professional verification, the code provides removal after ninety days from submission through a restricted cleanup process. An unfinished review may require fresh evidence once the period ends. A professional-details decision, directory visibility and medical permissions are distinct states.

The decision, reasons and necessary history are not automatically erased with the raw file. Their periods, organisation-verification records and documented objections require separate purpose-specific legal approval. The operator must verify cleanup execution and failed operations.

Incomplete uploads have a standard server reservation of up to 24 hours. Expired reservations and parts are handled by cleanup with checks and retries. Recognised leftover temporary scanning artifacts older than two hours are eligible for removal by a separate process; this does not give an accepted medical file a two-hour retention period.

Ordinary application sessions default to twelve hours, remembered sessions to up to thirty days. Expired sessions are revoked; revoked-session metadata are removed by the corresponding command after ninety days from revocation. The random device identifier and short browser workflows have separate durations in the cookie inventory. A browser pointer does not retain a file or override server restrictions.

Accounts, memberships, contractual acceptances, linking consents, audits, support requests and delivery events serve different purposes. No single automatic period is established for all such records. Exact periods, triggering events, access and minimisation require an approved retention matrix; medical fields in those records require separate consideration.

Invoices, payments, tax records and accounting evidence are retained according to applicable accounting and legal duties. An arbitrary universal period does not replace assessment by Bulgarian accounting and legal advisers. Particular records may be needed for contractual evidence, claims or a security incident, but that does not permit unrestricted retention of all clinical data.

A legal or incident hold must have a basis, defined scope, owner and review. It can block physical removal without creating a new right to routine medical access. Technical hold support does not prove that every hold is lawful; decisions are documented and released when their basis ends.

Backups are not necessarily erased record by record simultaneously with primary storage. Exact retention, schedules, regions, access, protection and rotation are not proven by code and require operational and contractual approval. Restoration must reapply deletions and revocations. A backup-target probe or synthetic restoration does not prove an actual production backup, automatic recovery or a guaranteed period.

Trial expiry or non-payment can restrict new organisational work according to displayed dates and terms. It is not a hidden instruction for immediate destruction and does not alone determine the lawful retention basis. Customer and provider arrange return, export or removal through a verified instruction and agreed process, taking account of required retention and actual availability.

Requests may be sent to [email protected] or the agreed contact and are verified proportionately. There is no universal self-service button automatically erasing an account, organisation records, files, accounting and backups. Deleting a personal account does not automatically erase clinic files or other members’ records; unlinking does not delete an account. Applicable explanations are supplied for refusals, limits or lawful holds.

The notification worker removes encrypted link material from the sending record at a terminal state. This does not automatically erase necessary operational history or establish a common retention period for all notifications. Pending, blocked or unconfirmed records require operating processes and an approved review, minimization and retention matrix.

Moving a completed handover to the Archive list is distinct from physical transition of file bytes. A local file may remain immediately available; having no preparation to perform does not establish cloud restoration. Downloading, holds and deletion continue to depend on the particular permissions, periods and applicable policy.