HIPAA Limited Data Set Checklist: Required Elements, Agreements, and Examples

Limited Data Set Definition

A HIPAA Limited Data Set (LDS) is protected health information (PHI) stripped of direct identifiers of the individual and of relatives, household members, and employers. An LDS may retain certain demographics and dates, enabling analysis while reducing identification risk. You may use or disclose an LDS for research, public health disclosure, or healthcare operations compliance when a full de-identification would undermine the purpose.

An LDS is still PHI, not anonymized data. You must have a Data Use Agreement before sharing, and you must apply the Minimum Necessary Standard to decide which fields belong in scope.

What an LDS can be used for

• Research activities that require granular time windows or geography.
• Public health disclosure such as surveillance, outcomes tracking, or evaluation.
• Healthcare operations compliance, quality improvement, cost management, or utilization review.

What an LDS is not

• Not fully de-identified data; re-identification risk remains if mishandled.
• Not a substitute for patient authorization where authorization is required.
• Not permissible to use for contacting individuals or re-identifying them.

Example

You analyze 30-day readmissions across hospitals. Your LDS includes city, state, ZIP code, admission and discharge dates, diagnoses, and procedure codes—without names, street addresses, phone numbers, or medical record numbers.

Permitted Elements in Limited Data Set

You may include

• Geography at the level of city, state, and ZIP code (no street address).
• All elements of dates related to the individual (e.g., admission, discharge, service, birth, and death dates).
• Clinical and utilization fields that are not direct identifiers (e.g., diagnoses, procedures, medications, lab results, length of stay).
• Age values (including 90 and over), and derived variables that do not directly identify a person.

Remove these direct identifiers

• Names.
• Street address and other granular location details beyond city, state, and ZIP code.
• Telephone, fax, and email addresses.
• Social Security numbers, medical record numbers, health plan beneficiary numbers, and account numbers.
• Certificate/license numbers.
• Vehicle identifiers and serial numbers (including license plates).
• Device identifiers and serial numbers.
• Web URLs and IP addresses.
• Biometric identifiers (e.g., fingerprints, voiceprints).
• Full-face photographs and comparable images.
• Any direct identifier or code that could permit identification of the individual.

Edge considerations

• Free-text notes often contain direct identifiers; scrub or exclude them.
• Suppress extremely small cell counts or highly unique combinations to lower re-identification risk.
• If combining an LDS with external datasets, reassess risk and adjust fields accordingly.

Data Use Agreement Requirements

A Data Use Agreement (DUA) governs each LDS disclosure. It defines purpose, limits use, and obligates safeguards and accountability. Build your DUA around the following required elements.

Core requirements

• Permitted uses and disclosures: describe the specific research, healthcare operations compliance activity, or public health disclosure.
• Authorized recipients: name the recipient organization and individuals or roles permitted to access the LDS.
• Prohibition on re-identification and contact: recipient will not re-identify or contact individuals.
• Safeguards: implement administrative, physical, and technical controls proportionate to the data’s sensitivity.
• Unauthorized use reporting: prompt written notice to the covered entity of any use or disclosure not permitted by the DUA, with mitigation steps.
• Flow-down obligations: require agents and subcontractors to agree to the same restrictions and conditions.
• Return or destruction: at project end, return or destroy the LDS; if infeasible, continue protections and limit further use.
• Compliance and oversight: allow reasonable audit/verification of compliance with the DUA.

Covered Entity Obligations

• Validate that the LDS is the minimum necessary for the stated purpose and that all direct identifiers are removed.
• Verify recipient qualifications, safeguards, and need-to-know access.
• Execute and retain the DUA and related approvals before any disclosure.
• Maintain procedures for tracking disclosures and for responding to unauthorized use reporting.
• Provide training and guidance to workforce members who prepare or share the LDS.

Recipient responsibilities

• Use the LDS only for the permitted purpose and within the authorized team.
• Apply least-privilege access, encryption, logging, and secure storage/transfer.
• Report, mitigate, and document any non-permitted use or disclosure without delay.
• Ensure agents/subcontractors adhere to the same restrictions.
• Return/destroy data as required and certify completion.

Minimum Necessary Standard

The Minimum Necessary Standard applies to limited data sets. Even though dates and certain geography can remain, you must limit fields, records, and time windows to what is reasonably necessary for the defined purpose.

Operationalizing minimum necessary

• Define the purpose precisely and translate it into data elements, timeframes, and populations.
• Map requested fields to the purpose; exclude fields that do not materially affect the analysis.
• Reduce precision when feasible (e.g., month instead of exact date, ZIP instead of census tract).
• Use role-based access and data partitions so only authorized users can view sensitive elements.
• Periodically re-validate scope; remove fields no longer needed as the project matures.

De-Identification Checklist

When feasible, prefer de-identified data. De-identification removes more risk and eliminates the need for a DUA. You have two pathways.

Pathway A: Safe Harbor

• Remove the 18 identifiers, including: names; full address details; all elements of dates (except year) directly related to an individual; phone/fax/email; SSN; MRN; health plan and account numbers; certificate/license numbers; vehicle and device identifiers; URLs; IP addresses; biometric identifiers; full-face photos; and any other unique identifying number, characteristic, or code.
• Ensure you have no actual knowledge that the remaining data could identify the individual.

Pathway B: Expert Determination

• An experienced professional applies accepted methods to determine very small identification risk.
• Document methods, assumptions, and controls, and re-evaluate if data or context changes.

Choosing between LDS and de-identified

• Use an LDS when dates and ZIP codes are necessary and cannot be generalized.
• Use de-identified data when analysis tolerates generalized dates or coarser geographies.

Limited Data Set Checklist

• Confirm purpose: research, public health disclosure, or healthcare operations compliance.
• Inventory requested data elements and justify each against the purpose.
• Remove all direct identifiers; retain only permitted elements (e.g., dates, city, state, ZIP).
• Scrub free text and attachments to eliminate embedded identifiers.
• Assess re-identification risk; suppress small cells and rare combinations as needed.
• Draft and execute a Data Use Agreement covering permitted uses, safeguards, and unauthorized use reporting.
• Vet recipient safeguards and limit access to named individuals or roles.
• Apply minimum necessary: trim fields, timeframe, and population to the smallest useful scope.
• Secure transfer and storage with encryption, logging, and retention limits.
• Monitor compliance; address incidents promptly and document mitigation.
• At project end, return or destroy the LDS and confirm completion in writing.
• Review lessons learned and update templates, procedures, and training.

Sample Data Use Agreement

Template structure (illustrative)

• Parties and purpose: identify the covered entity and recipient; describe the research, public health disclosure, or operations activity.
• Definitions: limited data set, direct identifiers, agents/subcontractors.
• Permitted uses/disclosures: list allowed analyses and outputs; forbid attempts to contact individuals.
• Access control: limit access to named personnel/roles with a need to know.
• Restrictions: no re-identification; no linkage with other data to identify a person.
• Safeguards: administrative, physical, and technical controls; encryption; auditing; training.
• Unauthorized use reporting: timelines, content of notices, mitigation, and cooperation duties.
• Flow-down: require agents to sign agreements with the same restrictions and conditions.
• Data management: secure transfer, storage locations, retention, and permitted derivatives.
• Publications/outputs: aggregate thresholds and suppression rules to avoid identification.
• Return/destruction: method, timeline, and certification; contingency if destruction is infeasible.
• Oversight: right to verify compliance and request corrective action.
• Term and termination: causes, effect on data, and continuing obligations.
• Covered Entity Obligations and recipient warranties: accuracy of representations and compliance with the Minimum Necessary Standard.
• Signatures: authorized representatives of both parties.

Conclusion

This HIPAA Limited Data Set Checklist helps you decide when an LDS is appropriate, which elements you may include, how to structure a strong Data Use Agreement, and how to apply the Minimum Necessary Standard. Follow the checklists to prepare, share, and retire an LDS confidently while protecting privacy and meeting compliance goals.

FAQs

What information is excluded from a HIPAA limited data set?

A limited data set must exclude direct identifiers such as names; street addresses; phone, fax, and email; Social Security numbers; medical record and account numbers; health plan beneficiary numbers; certificate/license numbers; vehicle and device identifiers; URLs and IP addresses; biometric identifiers; and full-face photos or comparable images. You may keep dates and city, state, and ZIP code, along with non-identifying clinical and utilization data.

What must be included in a limited data set agreement?

A Data Use Agreement must specify the permitted uses/disclosures, identify authorized recipients, prohibit re-identification and contact, require safeguards, mandate unauthorized use reporting, flow down the same restrictions to agents/subcontractors, and require return or destruction of the data at project end (or continued protections if destruction is infeasible). It should also outline oversight and compliance expectations.

How does the minimum necessary standard apply to limited data sets?

You must include only the least amount of information reasonably needed to achieve the purpose. Define the purpose precisely, justify each field, reduce precision when possible, restrict access to authorized users, and periodically re-validate that all elements in the LDS remain necessary for the work.