A data retention policy for medical documents a vendor processes should name each copy the work creates, from source scan to extracted fields, review logs, exports and backups, and give each a retention period, an owner and a deletion method. HIPAA sets a six-year rule for compliance documentation, while mostly state law governs how long medical records are kept.
What HIPAA does and does not say about medical document retention
HIPAA sets a six-year retention period for compliance documentation, such as policies, procedures and records of required activities. It does not set a retention period for medical records themselves. How long a provider must keep a patient's chart, claims or bills comes from state law and other rules, and those periods vary by state.
The Privacy Rule's documentation standard is in 45 CFR 164.530 on eCFR. Its retention period specification says: "A covered entity must retain the documentation required by paragraph (j)(1) of this section for six years from the date of its creation or the date when it last was in effect, whichever is later." Paragraph (j)(1) covers policies and procedures, required written communications, and records of actions or designations the rule says to document.
The Security Rule has a parallel requirement for its own policies and records in 45 CFR 164.316 on eCFR, with the same six-year length. Both rules are about proving what the organization did. Neither tells a clinic how long to keep a lab report or a discharge summary.
Medical record retention periods are set elsewhere: state medical record laws, state licensing rules, payer contracts and program rules. The periods vary by state, so a policy should name the specific laws that apply to the organization rather than a single national number. The covered entity, usually the clinic or billing client, owns that decision.
For a vendor, this division is useful. The vendor's copies of documents are working copies held for the customer, not the legal medical record. The vendor's policy can therefore aim to keep each copy only as long as the work and the contract require, and leave the long record retention to the customer's own systems.
Should you delete source documents after extraction?
Deleting source documents after extraction lowers risk, because a scan that no longer exists cannot be lost or stolen. Keeping the original briefly has value too: a reviewer can check a field against the page, and a team can answer a dispute. A policy can serve both by keeping the source for a set window, then deleting it.
The case for keeping the source a while:
- Review. A reviewer confirming an uncertain field needs the page it came from.
- Corrections after posting. A billing lead who finds a wrong amount a week later wants to see the original EOB.
- Disputes and audits. A payer or auditor may ask where a value came from.
- Reprocessing. If extraction rules change, the team may want to run old documents again.
The case for deleting:
- Less to protect. Every stored scan is a full page of PHI, often for several patients.
- Smaller breach. A breach involving 30 days of documents is easier to assess and smaller in scope than one involving five years.
- Duplicate copies. The customer usually keeps the original in its own document management system or EHR, so the vendor's copy is a second copy.
A workable middle path is to set a window tied to the work. For example, a policy might keep source scans for 30 days after all fields are approved, then delete them, while the extracted fields and review log live on for the period the contract sets. The right number depends on how long corrections and disputes realistically take in that customer's workflow.
Example: choosing a window for EOB scans
This example is fictional. A clinic's billing team posts EOB payments within five business days, and its staff tell the vendor that payer questions about a posted line usually surface within the following month. The clinic keeps its own copy of every EOB in its document system. Together they set the vendor's source-scan window at 45 days after approval. Corrections after that point are made from the clinic's copy, not the vendor's. The decision, the reasons and the date go into the policy, so the next reviewer can see why 45 was chosen rather than 30 or 90.
Two signals suggest a window is too short: reviewers asking for deleted pages, and corrections made without checking the source. Two suggest it is too long: scans kept for months that nobody opens, and a breach assessment that has to count patients far beyond the current work.
Schema Care's homepage compliance list shows its retention item as "In progress", with the description "Delete source documents on a schedule you set."
Writing the data retention policy for medical documents, clause by clause
A data retention policy for medical documents works best as a short set of clauses: scope, ownership, a schedule per artifact, deletion methods, exceptions such as legal holds, contract end, and review. The schedule is the heart of it. Each artifact a workflow creates gets its own period and method.
Clause 1: Scope
State which documents and systems the policy covers. Example: "This policy covers EOBs, claim forms, lab reports and intake forms that [Vendor] receives from [Customer] for data extraction, and every copy made in processing."
Clause 2: Ownership
Name who decides and who carries out deletion. The covered entity decides how long its records are kept. The vendor follows that decision for the copies it holds.
Clause 3: Retention schedule
This fill-in template lists each artifact. The periods in brackets are examples only; replace them with the periods your contract and applicable law require.
| Artifact | Retention period | Starts when | Deletion method | Owner |
|---|---|---|---|---|
| Source scan or PDF | [Example: 30 days] | All fields approved | Delete from storage, then confirm it is gone from caches | [Vendor operations] |
| Extracted fields | [Example: length of contract] | Field approved | Delete records, or return to customer at contract end | [Vendor operations] |
| Review log of approvals and corrections | [Example: 6 years] | Log entry written | Delete from the archive after the period | [Vendor security] |
| Exports | [Example: 7 days on vendor side] | Export created | Delete export files after customer confirms receipt | [Vendor operations] |
| Backups | [Example: 35 days rolling] | Backup taken | Expire automatically; encrypted media destroyed at end of life | [Vendor infrastructure] |
Clause 4: Deletion methods
Describe how each kind of media is cleared. 45 CFR 164.310 on eCFR makes two related items required: policies for the final disposition of electronic PHI and the media it is stored on, and procedures for removing electronic PHI from media before re-use.
Clause 5: Exceptions
Say what pauses deletion, such as a legal hold, an open dispute or a regulator's request, and who can approve one. Holds and deletion inside document systems are covered under legal holds and deletion in document management software.
Clause 6: Contract end and review
State what happens when the contract ends, and how often the policy is reviewed. Log retention specifically is discussed in how long HIPAA audit logs should be kept.
What happens to retained documents when a vendor contract ends?
When a vendor contract ends, HIPAA requires the business associate agreement to oblige the vendor to return or destroy all PHI it still holds, and keep no copies. If return or destruction is not feasible, the vendor must extend the agreement's protections to what remains and limit its use to the reasons destruction was not possible.
The language comes from the contract requirements in 45 CFR 164.504 on eCFR. The required provision says that at termination of the contract, the business associate must, "if feasible, return or destroy all protected health information" it received or created on the covered entity's behalf "that the business associate still maintains in any form and retain no copies of such information". The full set of clauses a business associate agreement contains is covered in what a business associate agreement is.
In practice, a clean exit has four steps:
- Decide return or destroy. The customer chooses whether it wants extracted data back, and in what form, or whether everything should be destroyed.
- Return what was asked for. The vendor delivers the data over an encrypted channel and confirms receipt.
- Destroy the rest. Source scans, extracted fields, exports, logs with PHI and working copies are deleted under the policy's methods.
- Certify. The vendor gives a written statement of what was destroyed and when, and notes anything it could not destroy, such as data in backups awaiting expiry.
Backups are one reason destruction is "not feasible" on the day the contract ends. A policy that states the backup expiry window lets both sides know when the last copy will be gone. On Schema Care's current plans, every paid plan includes a BAA, as shown on the pricing section.
Backups and stray copies a retention policy forgets
A retention policy for medical documents can easily miss copies that sit outside the main system: backups, export files, email attachments, local downloads, fax inboxes, test environments and logs. Each one keeps PHI alive after the official record is deleted, so the policy should list them and give each a period.
Common stray copies include:
- Backups. A source scan deleted on day 30 can live in nightly backups for weeks. State the backup window in the policy.
- Exports. Spreadsheets sent to a billing lead often sit in a downloads folder for months.
- Email and chat. A reviewer who forwards a page image to a colleague creates a copy no schedule tracks.
- eFax inboxes. Received faxes stay in the service's mailbox until someone deletes them.
- Test and training data. Real documents copied into a test system to debug a problem.
- Logs. Error logs and review logs can hold field values.
- Printouts. Paper copies of scanned pages left in trays and files.
Two controls catch most of these. First, limit where copies can go: no exports to personal drives, no PHI in chat, de-identified samples for testing. Second, run a periodic sweep of the known places stray copies collect, and record what was found and deleted.
A stray copy that turns up in the wrong place may be a breach. How to assess it is covered in the breach notification rule basics. For the request and review side of records work, see the records retrieval and review category.