Data Retention & Deletion
How long data is kept, what happens when a customer leaves, and the one thing the platform deliberately will not do.
1.The governing principle
Financial records are not deleted casually. A recovery case is an assertion made to a payer about money, and the ability to reconstruct that assertion years later is what makes it defensible. So the platform's default is status transitions, not destruction: a finding that turns out to be wrong is closed with a reason and stays readable, rather than vanishing.
That is a deliberate trade against a privacy instinct to purge, and it is the right one for a system of financial record — but it means retention has to be governed explicitly rather than by neglect.
2.What is kept, and why
| Data | Retained because |
|---|---|
| Raw 837 / 835 / 277 transmissions | Provenance. Every figure must trace to the file it came from. Stored encrypted. |
| Claims, remittances, adjustments | The financial record itself. |
| Contract documents and verified terms | The authority a recovery rests on, and the evidence cited to a payer. |
| Appeal packages as sent | Byte-for-byte, with a hash. A payer disputing receipt is answered with what left, not a description of it. |
| Audit events | Who did what. Deleting these would defeat their purpose. |
| Provider-supplied attachments | Part of what was enclosed with an appeal. |
3.Retention periods
Retention periods for claim and remittance data are set per customer in the agreement, driven by the customer's own record-retention obligations, state law, payer contract terms and the statute of limitations on the claims involved — commonly six to ten years in healthcare.
The right answer is a configurable retention period agreed per customer in the services agreement, with the platform enforcing it. Until counsel and each customer set it, data is retained for the life of the agreement.
4.Deletion on request
A customer may instruct us to delete specific records or a category of records. We will do it and confirm in writing.
Two honest limits:
- Audit events referencing deleted records are retained. The event says an action happened, by whom and when; it is the integrity control and is not removed on request. Identifying content within it can be redacted.
- Backups age out rather than being surgically edited. A record deleted from the live system may persist in an encrypted backup until that backup expires. It is not restored to live use in the interim.
5.When a customer leaves
Termination is where vendors quietly become difficult, so the commitment is specific.
- Export. For thirty days after termination, the customer keeps its access and may take its data out in machine-readable form. Audit events and findings download as CSV from the application; claims, remittances, cases and evidence are readable as JSON through the authenticated API; and on written request we supply the complete data set as a single machine-readable extract. No fee, no negotiation.
- Deletion. On written instruction, or ninety days after termination if none is given, customer data is deleted from live systems and the customer is told when it is done.
- Backups. Encrypted backups age out on their normal cycle.
- No hostage-taking. Export is never conditioned on settling a disputed invoice. A customer's own claims data is theirs.
6.The demonstration environment
The public demonstration tenant contains synthetic data only — generated claims, generated patients, generated remittances. No real patient information has ever been loaded into it, and it is walled off from every customer tenant, so nothing real may ever be. Access for a security review is given on request through the security address below.
Questions about this document: · · · All policies