Auto-purge intervals: 14 days, 30 days, or forever?

The form had been collecting submissions for four years. Nobody had ever deleted any of them. The database now held 11,000 patient intake records, each with name, date of birth, reason for visit, allergy list, insurance information, and a freeform notes field. The clinic had moved most of that information into the EHR after each appointment. The form database was redundant. It was also a four-year archive of PHI, sitting in a system designed to be temporary. Auto-purge intervals are the retention rule most clinic forms forget to set.

When I asked the practice manager what the retention policy was, she said there was not one. The data had simply accumulated. That accumulation is the most common mistake clinics make with form data, and it is one of the easiest to fix.

Why retention is a security control

Data you do not have cannot leak. Every record retained beyond its useful life is a record an attacker could exfiltrate, a record an internal misuse could expose, a record that has to be encrypted, audited, and protected for as long as it exists. Retention is not a compliance checkbox. It is the simplest reduction of attack surface available, and it costs almost nothing to implement.

HIPAA does not specify a retention period for form data. It requires the clinic to have a documented retention policy that reflects the operational need. The clinic decides. The deciding question is: how long does this data need to live in this system to do its job?

The three honest auto-purge intervals

For most clinic form data, the choice comes down to three honest windows. Which one is right depends on what the form does.

14 days. The right default for new-patient intake forms where the information is captured into the EHR at the first visit. After the visit, the form record is redundant. Two weeks is enough time for the front desk to catch a delayed appointment, transcribe the intake if it did not auto-import, or follow up on a question. After that, the form record’s job is done.

30 days. The right default for contact forms, callback requests, and forms that may not result in an appointment within a week. Slightly longer to accommodate parents who fill out the form, then take three weeks to schedule. Anything in the system longer than 30 days without an appointment is essentially abandoned, and the operational value of keeping it drops to zero.

90 days. The right default for screening forms (PSC-17, EPDS, behavioral health screeners) where there is a documented clinical workflow for following up on results. The longer window accommodates the cadence of follow-up scheduling, repeat screens, and parent-driven response timelines. 90 days is the ceiling, not the floor.

Notice what is not on this list. “Forever” is not on this list. “Just in case” is not on this list. “Until the database fills up” is not a retention policy. It is the absence of one.

The “but we might need it” objection

The most common objection to short retention windows is: what if we need the data later? What if a parent calls in six months asking about the intake they submitted?

The right answer is that the data they submitted should be in the patient’s chart in the EHR, not in the form database. The form database is a transit lane, not a permanent archive. If the data did not make it into the EHR, that is a process failure, not a justification for keeping the form record forever.

The other version of this objection is: what if there is a legal dispute and we need to produce the original form? In practice, the audit trail provides this. The audit trail captures that the form was submitted on a given date by a given session, that it was viewed and processed, and what happened to it. That is what a dispute actually needs. The contents of the form are in the EHR. The form record itself, after a reasonable transit period, is overhead.

What “purge” should actually mean

A real purge deletes the data, not just the visibility of it. This is worth checking with any form vendor.

• Is the row hard-deleted from the database, or is a flag set to hide it from the admin UI?
• Are backups also purged on the same schedule, or do they retain everything for the backup retention window?
• Are derived copies (cached views, exports, integration syncs) also purged?
• Is the audit trail entry retained, with the actual data removed?

If “purge” means soft-deletion, the data is still there. The retention policy is the marketing version, not the security version. The fix is to enforce hard deletion at the application layer and at the backup layer.

The implementation, end to end

A clean retention implementation looks roughly like this. The form record is created with a TTL (time to live) field set to submission date plus the retention window. A nightly cron job runs against the form database. It selects records past their TTL. It hard-deletes them. It writes an audit trail entry recording the purge: how many records, against which retention policy. The audit trail entry contains no PHI. The backup system’s retention is set to match or be shorter than the form retention. Encrypted offsite backups follow the same TTL.

The whole implementation is roughly 50 lines of code plus a cron entry. The work is in the policy decision, not the engineering.

The numbers, in practice

The clinic at the top of this post adopted a 14-day window for intake forms and a 30-day window for contact forms. After the first nightly run, the database went from 11,000 records to about 280. After 30 days, the database stabilized between 250 and 400 records at any given time, representing the actual operational window of in-flight submissions.

The attack surface dropped by roughly 97 percent. The operational impact was zero. No front desk task changed. No clinical workflow broke. The data the clinic needed was always in the EHR, where it should have been. The form database had been a four-year accumulation of redundant copies.

If your form database has more than 1,000 records and you cannot point to a retention policy, you have the same accumulation problem the clinic above had. The fix is short, the cost is small, and the reduction in exposure is large. See the related post on audit trails for the supporting piece, and our plans page for how we structure form work to make retention the default rather than an afterthought.