Reference table
Retention
Sets out how long Pensieve keeps each type of record, the basis for each period, and what happens to data once its term ends.
Pensieve does not keep everything for one period. Retention is a property of each record class, because the law that governs a clinical record, a financial voucher, a statutory register and a processing log is different in each case. A single statement that the platform keeps data for a set number of years would be wrong for most of them.
How a period is computed
Each record class carries four pieces of metadata. From them the platform computes an effective destruction date, and recomputes it whenever a hold is placed or lifted.
The law that governs the class in the deployment's market. The anchor and the period both differ by jurisdiction, so the same clinical record can carry a different obligation in two countries.
The event the clock starts from, such as the commencement of treatment or the last entry made in a register.
How long the class is held, measured from its anchor event.
Whether a statutory, litigation or medico-legal hold suspends destruction regardless of the period. A hold names who applied it and carries a review trigger so it cannot quietly become permanent.
The record classes
The hospital sets the actual values against its own legal advice, its state rules and its accreditation requirements, and the configured values are recorded in the deployment record. Financial records are held by Vault as the hospital's books of account. An audit entry carries no period of its own. It is kept for the period of the record it describes, so a record entry follows the clinical record and a financial entry follows the books of account. The periods below are the basis for each class, not a single vendor-asserted number.
| Record class | How long it is kept | Basis | Who sets the value |
|---|---|---|---|
| In-patient clinical record | A multi-year statutory minimum, extended to the hospital's own policy period | Medical professional conduct rules | Hospital |
| Out-patient clinical record | The hospital's policy period | Hospital policy, with no single uniform statutory period | Hospital |
| Medico-legal case record | An indefinite hold that no scheduled destruction clears | Evidentiary need, since a case may be reopened years later | Hospital, and the hold cannot be lifted by the retention job |
| Statutory registers, such as pre-natal diagnostic, narcotic and radiology | The period the relevant statute sets for that register | The specific statute | Hospital, configured per register |
| Consent forms and authorisations | With the record they relate to | Evidentiary | Hospital |
| Financial and billing records, tax documents | The statutory books-of-account and tax periods | Tax and companies legislation | Hospital |
| Audit trail of record amendments | For as long as the record itself | The amendment history is part of the record | Hospital, following the record class |
| Audit trail of financial postings | For as long as the financial records it describes | The entry is the evidence for the posting | Hospital, following the books-of-account and tax periods |
| Processing and system logs | Not less than one year | The higher of the data protection and security retention rules | Pensieve configures, and the hospital owns in DM-3 Customer cloud and DM-4 On-premise |
Deletion can itself be a duty
Some registers must be destroyed on a fixed schedule, so deletion is a legal obligation rather than a courtesy. The termination-of-pregnancy admission register, for example, is held in confidence and then destroyed once its statutory term ends. A platform that only knows how to retain would be non-compliant here, so scheduled destruction is a first-class operation, not only a hold.
Four clocks, kept separate
Backup retention, record retention and log retention are routinely conflated. Pensieve keeps them as distinct clocks, because a record leaving the live system does not leave the backups on the same day. A fourth clock belongs to the hospital. The downtime pack is the extract ward staff read while the link to the platform is down. It sits on storage the hospital nominates and administers, so no Pensieve software holds it at the site and the hospital keeps its clock.
| Clock | What it governs | How long |
|---|---|---|
| Record retention | How long a clinical or financial record stays in the live system | Per record class, from the table above |
| Backup retention | How far back a restore can reach | The backup window configured for the deployment |
| Log retention | How long audit and system logs are kept | Not less than one year |
| Downtime pack retention | How long the hospital's downtime extract stays readable at the site | Until the next refresh supersedes it, then destroyed by the hospital on its own schedule |
Destruction is approved and evidenced
When a class reaches the end of its period the records are queued for destruction, not destroyed automatically. A nominated hospital role approves the queue, and a statutory, litigation or medico-legal hold suppresses destruction regardless of the schedule, visibly in the queue. Pensieve does not destroy a hospital's clinical records on its own initiative. Every destruction event is written to a destruction register, retained as evidence for accreditation and for the hospital's own record.
| Recorded on destruction | Detail |
|---|---|
| Record class | Which class of records was destroyed |
| Date range | The span of records the event covered |
| Count | How many records |
| Method | By what method they were destroyed |
| Authorisation | On whose authority |
| Time | When it was done |
In DM-1 Dedicated and DM-2 Shared, Pensieve executes the approved destruction. In DM-3 Customer cloud it does so inside the hospital's own project. In DM-4 On-premise the hospital runs the same mechanism on its own hardware and its own media. A downtime pack sits outside this mechanism, on storage the hospital nominates and administers, so the hospital destroys it and evidences that destruction in its own records. The hospital, as the Data Fiduciary, decides the periods against its own legal advice. Pensieve provides the engine and records what happens.
Does Pensieve set a single retention period?
No. Retention is per record class, each with its own jurisdiction, anchor event, period and hold state. A statutory minimum overrides an erasure request, and in some cases a fixed-schedule destruction is itself the obligation.
Who decides when a record is destroyed?
The hospital. It configures the periods as the Data Fiduciary, and a nominated hospital role approves each destruction. Pensieve executes and evidences it in the hosted models, and the hospital executes it in DM-4 On-premise.
Is a record gone from backups the moment it leaves the live system?
No. Backup deletion follows the backup rotation, so the record expires from backups on that window rather than instantly. The clocks run separately for exactly this reason.
Read where each class is stored in where data lives, how a hospital takes its records out in export and exit, and how a patient request is handled in data subject requests.