In the limited data set vs de-identified data choice, the key difference is status. A limited data set is still PHI: it drops names and record numbers but keeps dates, city, state and ZIP code under a data use agreement. De-identified data is no longer PHI. Choose the limited set when analysis needs dates or place.
Limited data set vs de-identified data at a glance
A limited data set and de-identified data sit at different points on the same line, from fully identified records to records HIPAA no longer covers. A limited data set keeps dates and some geography under contract. De-identified data drops far more and needs no contract. Pseudonymized data, with names swapped for tokens, usually falls short of both.
Both terms are defined in 45 CFR 164.514 on the eCFR. Paragraph (e)(2) says a limited data set "is protected health information that excludes" a list of 16 direct identifiers. Paragraphs (a) and (b) set the de-identification standard and its two methods.
The table compares four states a document set can be in. The example fields are fictional.
| State | Example fields kept from a fictional claim | Agreement needed | Still PHI under HIPAA? |
|---|---|---|---|
| Fully identified PHI | Name "Dana Ruiz", member ID "XQZ123456789", street address, birth date 07/02/1958, service date 03/14/2026 | A BAA if a vendor handles it for you | Yes |
| Limited data set | Birth date 07/02/1958, service date 03/14/2026, town "Fairview", state, ZIP 59301 | A data use agreement with the recipient | Yes |
| Pseudonymized data | Token "P-000417" in place of name and member ID, plus everything else | Depends on what is left; often the same as fully identified PHI | Usually yes |
| De-identified data | Birth year 1958, service year 2026, ZIP "593" if the area qualifies | None under the Privacy Rule | No |
The limited data set list differs from the Safe Harbor list in three ways that matter for billing and lab documents. It does not remove dates. It keeps "town or city, State, and zip code" from postal address information. And it has no catch-all for "any other unique identifying number", so it is shorter by two items. The Safe Harbor list itself is set out in the 18 HIPAA identifiers, and the two de-identification methods are compared in Safe Harbor vs Expert Determination side by side.
What does a data use agreement for a limited data set require?
A data use agreement for a limited data set is the contract HIPAA requires before a covered entity uses or discloses one. Under 45 CFR 164.514(e)(4), the covered entity must obtain "satisfactory assurance, in the form of a data use agreement", that the recipient "will only use or disclose the protected health information for limited purposes".
Paragraph (e)(4)(ii) lists what the agreement must contain. In the regulation's words, it must:
- "Establish the permitted uses and disclosures of such information by the limited data set recipient", consistent with the permitted purposes, and it "may not authorize the limited data set recipient to use or further disclose the information in a manner that would violate the requirements of this subpart, if done by the covered entity"
- "Establish who is permitted to use or receive the limited data set"
- Provide that the recipient will "Not use or further disclose the information other than as permitted by the data use agreement or as otherwise required by law"
- Provide that the recipient will "Use appropriate safeguards to prevent use or disclosure of the information other than as provided for by the data use agreement"
- Provide that the recipient will "Report to the covered entity any use or disclosure of the information not provided for by its data use agreement of which it becomes aware"
- Provide that the recipient will "Ensure that any agents to whom it provides the limited data set agree to the same restrictions and conditions"
- Provide that the recipient will "Not identify the information or contact the individuals"
The purposes are narrow. Paragraph (e)(3)(i) allows a limited data set "only for the purposes of research, public health, or health care operations". A data use agreement cannot widen that list.
Paragraph (e)(4)(iii) adds a duty for the covered entity. If it "knew of a pattern of activity or practice" by the recipient that "constituted a material breach or violation" of the agreement, it must take reasonable steps to cure it. If those steps fail, it must stop disclosing to the recipient and report the problem to the Secretary.
The agreement can also sit inside a vendor relationship. 45 CFR 164.504 on the eCFR, paragraph (e)(3)(iv), lets a covered entity that discloses only a limited data set to a business associate for a health care operations function rely on a data use agreement that complies with 164.514(e)(4).
Data use agreement vs business associate agreement
A data use agreement and a business associate agreement (BAA) are different contracts with different jobs. A BAA covers a vendor that handles PHI on the covered entity's behalf, such as a company that reads and stores its claims. A data use agreement covers a recipient of a limited data set, such as a research partner, and binds it to the purposes and promises in paragraph (e)(4)(ii).
The overlap is narrow. The 164.504(e)(3)(iv) provision applies only when a covered entity discloses nothing beyond a limited data set, and only for a health care operations function. A vendor that also sees names, member IDs or full documents needs a BAA. What a BAA must say is set out in what is a business associate agreement.
Is pseudonymized data de-identified under HIPAA?
Pseudonymized data is not de-identified under HIPAA just because names were replaced. Pseudonymization swaps direct identifiers for a consistent token so records can still be linked. HIPAA does not use the word. It asks whether the data meets 164.514(b), and whether any re-identification code meets 164.514(c).
The difference is in what stays behind. A fictional pseudonymized extract might replace "Dana Ruiz" and member ID "XQZ123456789" with token "P-000417" but keep her full birth date, service dates and street address. Those are still on the Safe Harbor list, so the extract is still PHI. Pseudonymization vs de-identification is a question of the remaining fields, not of the token.
HIPAA does allow a re-identification code inside de-identified data, under strict terms. Paragraph (c) lets a covered entity assign "a code or other means of record identification" if two conditions hold:
- Derivation: the code "is not derived from or related to information about the individual and is not otherwise capable of being translated so as to identify the individual"
- Security: the covered entity "does not use or disclose the code or other means of record identification for any other purpose, and does not disclose the mechanism for re-identification"
A token built by hashing a member ID is derived from information about the person, which the derivation condition rules out. A random number assigned from a lookup table the covered entity keeps to itself is not derived from the person at all. Once the code itself is shared in a way that allows re-identification, 45 CFR 164.502 on the eCFR says in paragraph (d)(2)(i) that disclosing it "constitutes disclosure of protected health information".
So deidentified PHI can carry a code, and that is useful for linking a later batch of documents to an earlier one. The code just cannot come from the patient's own data or leave the covered entity's control.
Choosing a limited data set for billing and quality analytics
A limited data set is often the better choice for billing and quality analytics because those analyses run on dates and place. It keeps service dates, birth dates, town, state and ZIP code, which de-identification would cut to a year and three digits, while still removing names, member IDs and account numbers.
The permitted purposes line up with this work. Paragraph (e)(3)(i) of 164.514 allows research, public health and health care operations. The definition of health care operations in 45 CFR 164.501 on the eCFR includes "Conducting quality assessment and improvement activities" and "conducting cost-management and planning-related analyses related to managing and operating the entity".
A fictional example shows the gain. A billing group wants to measure days from service to payment by town across 2,000 example EOBs. Under Safe Harbor, every service date and paid date becomes "2026", and town names go. In a limited data set, a fictional line keeps service date 03/14/2026, paid date 04/02/2026 and town "Fairview", so the 19-day lag and the town comparison survive.
The same logic applies to quality work on lab data. Turnaround from collection to result, or the spacing of repeat tests, needs real dates. Revenue cycle analyses of denials, payment lags and payer mix are covered across the revenue cycle automation category.
The trade-off is that a limited data set never stops being PHI. It needs a data use agreement, the recipient must safeguard it, and it may be used only for the listed purposes. If the analysis works with years and three-digit ZIP codes, de-identified data carries fewer obligations.
Treating a limited data set as if it were de-identified
Treating a limited data set as if it were de-identified is an easy mistake to make. The data looks anonymous because names and account numbers are gone, so teams share it without a data use agreement, pass it to a new analyst or vendor, or post it. Under 164.514(e), it is still PHI throughout.
Four mistakes come up with document data.
Skipping the agreement is the first. Paragraph (e)(4)(i) says a covered entity may use or disclose a limited data set "only if" it obtains a data use agreement. Sending an extract first and papering it later does not meet that.
Passing it on is the second. The agreement must make the recipient "Ensure that any agents to whom it provides the limited data set agree to the same restrictions and conditions". A recipient that hands the file to a contractor without that promise breaks the chain.
Using it for a new purpose is the third. A data set built for a quality project cannot be repurposed for marketing, because the rule limits use to research, public health and health care operations.
Assuming the scans are clean is the fourth. A limited data set built from scanned EOBs and lab reports may still carry names and phone numbers in fax headers, stamps and handwritten notes. Removing those from the PDF itself, including the text layer, is covered in redacting PHI from PDFs. The full process for producing a de-identified copy instead is in PHI de-identification in five steps for a document set.
For teams evaluating document software, the safer starting point is a set of de-identified sample documents rather than a limited data set. Schema Care's Free plan is set up for de-identified sample documents, and its paid plans include a BAA for when real patient paperwork is involved.