Search all 478 artefacts by title, document ID or content.
Disclosure | Family 3, Security, Privacy & Trust Disclosures
This document exists to answer one objection before it is raised: "if we put everything into your platform, are we trapped?" The answer is published here, in advance, in public, with formats, timelines and prices, because an exit promise made at termination is worth nothing, and one published before signature is…
This document is the source of truth for: deletion-and-return-process, export-formats, certificate-of-deletion, exit-timeline, rfp-data-portability-answer, marketing:/trust/data-deletion
Those surfaces render this text from here. They do not keep their own copy, so they cannot drift from it.
Artefacts this one references or cannot be issued without.
Artefacts that would be blocked if this one were missing or out of date.
This document exists to answer one objection before it is raised: "if we put everything into your platform, are we trapped?" The answer is published here, in advance, in public, with formats, timelines and prices, because an exit promise made at termination is worth nothing, and one published before signature is checkable.
DM-1 Dedicated |
DM-2 Shared |
DM-3 Customer Cloud |
DM-4 On-Premise |
|---|---|---|---|
| Full process | Full process | The data is already in the hospital's project (Section 7) | The data is already on the hospital's hardware (Section 7) |
| Commitment | Value |
|---|---|
| Export on demand at any time during the term, self-service, no notice, no fee | The hospital's own users can export their data from the Platform whenever they wish, under DIS-GL-029 formats |
| A demonstration of data export before signature | On request, during evaluation. Pensieve Labs recommends every hospital ask for this (of Pensieve Labs and of every other vendor) |
| Full export on termination | Delivered within 10 business days of the termination effective date, or of a written request within the retrieval window |
| Retrieval window after termination | 60 days from the termination effective date, during which the hospital may request further exports |
| Export fee | None for the standard export in the published formats. A bespoke transformation to a third party's schema is chargeable and quoted in advance |
| Deletion from live systems | Within 30 days of the end of the retrieval window, or earlier on the hospital's written instruction |
| Deletion from backups | Within the backup rotation, and in any event within 90 days of live deletion (Section 4) |
| Certificate of Deletion | Issued within 10 business days of backup deletion completing |
| Data held hostage for a commercial dispute | Never. Section 6 |
Everything the hospital put in, plus everything the Platform generated about it.
| Category | Included | Format |
|---|---|---|
| Clinical records: encounters, notes, orders, results, medication administration, nursing records, allergies, vital signs | Yes | HL7 FHIR R4 resource bundles, plus a structured CSV/JSONL extract of every table for teams without a FHIR consumer |
| Documents and scanned records | Yes | Original files, with a manifest mapping each file to its patient, encounter and document type |
| Images | Yes | DICOM in their original form where they were stored as DICOM, with the accompanying study and series metadata |
| Reports and letters generated by the Platform | Yes | PDF, plus the structured data they were generated from |
| Billing, invoicing, receipts, claims and insurance records | Yes | Structured CSV/JSONL |
| Inventory, purchase, stock and supplier records | Yes | Structured CSV/JSONL |
| Human resources, roster and payroll data held in the Platform | Yes | Structured CSV/JSONL |
| Master data: tariffs, formulary, service catalogue, departments, users and roles | Yes | Structured CSV/JSONL |
| The audit trail: record access, amendments with prior values, disclosures, administrative changes | Yes | Structured JSONL. This matters more than the records at exit: without it the hospital loses the evidentiary integrity of the records it just received |
| Configuration: retention schedule, roles, forms, templates with their versions and effective dates | Yes | Structured export |
| Hospital-supplied credentials for external systems | Not returned: they are already the hospital's, held by the hospital at source. They are deleted (DIS-GL-025) |
|
Pensieve Labs's own application code, infrastructure code and internal operational data |
Not the hospital's data. The escrow route for code is ADD-GL-011 |
A data dictionary accompanies every export, describing each file, each column, each code system in use and each identifier, so that the receiving system's implementer does not have to reverse-engineer it. An export without a data dictionary is a compliance gesture rather than a portability capability.
| Step | Timing | Owner | Output |
|---|---|---|---|
| 1 | On notice of termination | Hospital | Written notice under MSA-IN-001, and a nominated exit contact |
| 2 | Within 5 business days of notice | Pensieve Labs |
An Exit Plan naming the export scope, formats, dates, the receiving system if known, and the named owners on both sides (ADD-GL-017) |
| 3 | Before the termination date | Both | Trial export, verified by the hospital against a sample of its own records. This is the step that finds the problem while there is still time to fix it |
| 4 | Within 10 business days of the termination effective date | Pensieve Labs |
Full export delivered to the hospital's nominated secure destination, with checksums and the data dictionary |
| 5 | Within the 60-day retrieval window | Hospital | Verification, and any further export requests |
| 6 | On the hospital's written confirmation, or at the end of the window | Hospital → Pensieve Labs |
Deletion Instruction |
| 7 | Within 30 days of step 6 | Pensieve Labs |
Deletion from live systems: database, object storage, secret store, caches, and any operational copy |
| 8 | Within the backup rotation, and in any event within 90 days of step 7 | Pensieve Labs |
Deletion from backups (Section 4) |
| 9 | Within 10 business days of step 8 | Pensieve Labs |
Certificate of Deletion (Section 5) |
Transition services, where the hospital wants Pensieve Labs to keep the Platform running while it
migrates, are available under ADD-GL-018 on published terms. The point of publishing them is that the
hospital knows the price of a graceful exit before it needs one.
This is the section most vendors write vaguely, so it is written precisely.
| Store | What happens | When |
|---|---|---|
| Database | Records deleted. In DM-1 and DM-3 the entire database instance and its project resources are destroyed rather than merely emptied |
Step 7 |
| Object storage | Objects deleted, versions purged, soft-delete windows expired | Step 7, with soft-delete expiry following the configured window |
| Secret store | Hospital-supplied credentials destroyed (DIS-GL-025) |
Step 7 |
| Caches and search indexes | Rebuilt or destroyed; no residual copy of record content | Step 7 |
| Encryption keys | In DM-1, the hospital's dedicated key ring is destroyed, after which the ciphertext of any residual copy is unrecoverable. In DM-2, the tenant's data encryption key is destroyed, which is the mechanism that makes deletion from shared storage meaningful |
Step 7, with the provider's key-destruction delay |
| Backups | Not deleted instantaneously. Backup sets expire on their rotation. Pensieve Labs does not restore, edit and re-write a backup set to remove one tenant, because that would compromise the integrity of the backups protecting every other hospital. The tenant's data becomes cryptographically unrecoverable at key destruction and the backup sets then expire on schedule, within 90 days |
Step 8 |
| Logs | Retained to the end of their statutory retention period, then expired. They are not deleted early, because the retention obligation under the data protection rules and the CERT-In directions survives the contract (DIS-GL-034) |
On expiry |
| Hospital KYC / subscriber record | Retained 5 years after termination under CERT-In Direction (v), applied conservatively. This is the hospital's corporate master data, not patient data. See DIS-GL-022 Section 3 |
5 years |
| Executed contracts and financial records | Retained for the statutory books-of-account and limitation periods | Per statute |
The honest sentence about backups. A vendor who says "your data is deleted from backups immediately"
either has no backups or is not telling the truth. Pensieve Labs states the actual period and states
the mechanism (key destruction first, expiry second) so that a hospital can assess the residual exposure
rather than accept an assurance.
Issued on Pensieve Labs's letterhead, signed, and carrying:
| Field | Content |
|---|---|
| Hospital | Customer legal name |
| Deployment | The model, the region and the tenant identifier |
| Deletion Instruction | Its date and the instructing person |
| Live system deletion | The date completed, and the stores covered |
| Key destruction | The date, and the key resources destroyed |
| Backup expiry | The date the last backup set containing the hospital's data expired |
| What was not deleted, and why | Logs retained to statutory expiry; the KYC record retained for five years; executed contracts and financial records retained per statute. Stated on the certificate itself, because a certificate that implies total erasure when statutory retention applies is a false certificate |
| Signature | [TO BE SUPPLIED], Director |
| Verification | Document hash and the verification URL under the Trust Center's /verify endpoint |
Edsol Edtech Pvt. Ltd. will not withhold a hospital's data over a commercial dispute.
| Situation | Position |
|---|---|
| Invoice in dispute | Export proceeds. Pensieve Labs pursues the debt through the mechanisms in MSA-IN-001, not by holding the hospital's clinical records |
Termination for Pensieve Labs's breach |
Export proceeds, and the transition assistance in ADD-GL-018 applies |
| Termination for the hospital's breach, including non-payment | Export still proceeds. MSA-IN-001 may permit suspension of the service; it does not permit destruction of, or refusal to return, the hospital's data |
| Suspension for a security reason | Export proceeds through a controlled channel once the security reason is addressed |
The reason is not generosity. A hospital's clinical records are the evidentiary basis for the care it has given and for its statutory obligations, and a vendor that holds them hostage is creating a patient-safety event to win a payment argument.
DM-3 and DM-4: the short version| Model | Position |
|---|---|
DM-3 |
The data is already in the hospital's own cloud project. Exit is: Pensieve Labs's IAM access is revoked by the hospital, Pensieve Labs hands over the infrastructure-as-code and the operational runbooks, and the hospital either operates the Platform itself under the applicable licence terms or exports and migrates. Pensieve Labs deletes nothing, because it holds nothing. The Certificate of Deletion covers only any copies in Pensieve Labs's own systems, of which there are none beyond support correspondence |
DM-4 |
The data is already on the hospital's own hardware. Same position, and even simpler. Pensieve Labs confirms that no copy exists in its systems |
This is the third legitimate reason to choose DM-3 or DM-4: exit is structurally trivial. It is stated
here rather than only in WPR-GL-004 because an exit conversation is where it is most persuasive.
Distinct from exit, and often confused with it. Where a patient exercises a right to erasure:
| Step | Owner |
|---|---|
| Receive and assess the request, including whether a statutory retention obligation or a medico-legal hold overrides it | Hospital: it is the Data Fiduciary |
| Execute the deletion in the Platform where the hospital decides it must be actioned | Pensieve provides the workflow; the hospital approves each one |
| Record the request, the decision, the reasoning and the outcome | Pensieve records it; the hospital owns the response to the individual |
Pensieve Labs does not decide whether a patient's record may be erased, and will not action such a
request received directly from a patient. It refers the individual to the hospital's grievance officer.
Deleting a clinical record that a hospital is statutorily obliged to retain would expose the hospital, not
Pensieve Labs.
9.1 Backup deletion is not instantaneous. Section 4. Up to 90 days after live deletion, cryptographically unrecoverable from the point of key destruction.
9.2 Statutory retention survives the contract. Logs, the KYC record, executed contracts and financial records are retained after deletion of the clinical data, and the Certificate of Deletion says so.
9.3 The export is Pensieve's data model, not the receiving system's. Pensieve Labs
delivers FHIR R4, DICOM, structured extracts and a data dictionary. It does not guarantee that a specific
third-party system will ingest them without mapping work, because that depends on the third party. A
bespoke transformation is available and chargeable, quoted in advance.
9.4 Free-text and image content is returned as it was stored. Pensieve Labs does not restructure a
clinician's free-text note into coded data at exit, and would not be right to.
9.5 No independently verified deletion attestation. The Certificate of Deletion is
Edsol Edtech Pvt. Ltd.'s own signed statement, not a third-party attestation. It is falsifiable: a
hospital may require the deletion evidence and the key-destruction record, but it is not audited.
9.6 Trial export is the hospital's responsibility to actually perform. Step 3 exists so that problems surface early. A hospital that skips it and discovers a mapping issue on day 9 of a 10-day window has compressed its own schedule.
| Question | Document |
|---|---|
| Export formats, code systems and interoperability standards | DIS-GL-029 Interoperability & Standards Disclosure |
| Record classes, retention and destruction during the term | DIS-GL-022 Data Classification & Handling Disclosure |
| Backup rotation and why deletion follows it | DIS-GL-014 Section A3 |
| Key destruction as the deletion mechanism | DIS-GL-011 Section 5 |
| Hospital-supplied credentials at offboarding | DIS-GL-025, ADD-GL-007 |
| The contractual termination and exit clauses | MSA-IN-001, ADD-GL-017 Termination & Exit Agreement |
| Transition services while migrating | ADD-GL-018 Transition Services Agreement |
| Escrow, if the concern is vendor failure rather than exit | ADD-GL-011 |
| The processor's deletion obligation | DPA-GL-001 |
| Version | Date | Author | Summary |
|---|---|---|---|
| 1.0.0 | 31 July 2026 |
Pensieve Labs Engineering |
First published edition. Timelines, formats and fees published before signature. Backup deletion stated accurately with its mechanism. No-hostage position published. Audit trail included in the export scope. |