Limited Data Set

A readmissions model needs the number of days between discharge and the next admission, and the measure the clinical team reports on is readmission within 30 days. A privacy office will not approve protected health information in the analytics account. The reflex answer is de-identification, and it fails on the first column: under the HIPAA safe harbor method at 45 CFR 164.514(b)(2), dates related to an individual keep only the year, ages over 89 collapse into "90 or older", and ZIP codes keep at most three digits and only where that area holds more than 20,000 people. A 30-day interval cannot be computed from years.

The limited data set at 45 CFR 164.514(e) exists for this gap. Direct identifiers are removed for the patient and for relatives, employers and household members: names, postal address other than town or city plus state and ZIP, telephone and fax numbers, email addresses, social security and medical record numbers, account and device identifiers, URLs and IP addresses, biometrics and full-face images. Dates stay. Use or disclosure requires a data use agreement.

Why it matters

Teams treat de-identification as a binary and then design around the wrong one. A limited data set is still protected health information, so the account that holds it inherits access control, audit logging, encryption decisions and the business associate chain. What the tier buys is not freedom from the rules; it is a dataset that supports interval analysis while sharply reducing what a breach would expose, bound by an agreement that fixes what may be done with it.

Getting the tier wrong is expensive in both directions. Choosing safe harbor when dates are needed produces an analysis that cannot be done. Choosing a limited data set when month granularity would have served leaves an entire analytics estate in scope for no benefit.

Implementation patterns

• Build the tier as a view or a pipeline stage, not a manual export. The transformation is the control, so it must be code with tests over the identifier columns.
• Keep the data use agreement machine-visible: the agreement id on the dataset, permitted purposes as metadata, and access grants that reference it. An agreement nobody can see from the warehouse is a document, not a control.
• Put the re-identification prohibition in the access path, not only in the contract: no joins to identified sources, enforced by the account boundary rather than by review.
• Record which tier each dataset is in the catalogue, with the citation, so the next team does not have to re-derive it.
• Push date-sensitive computation upstream where you can, so the flag travels and the dates do not.

Industry example

Academic medical centres publish their own de-identification tooling and policy around exactly this three-tier choice, and the recurring pattern in those policies, in production, is that the limited data set plus a data use agreement is the default route for internal research, with expert determination reserved for data that must leave as non-PHI. The reason is operational rather than legal: expert determination is dataset-specific and has to be redone whenever the data or the population changes, so it is a recurring cost attached to a moving target, while the limited data set is a transformation you can automate once.

Failure scenarios

• Believing it is de-identified. Controls are relaxed on a store that is still regulated, and the gap shows up as an unlogged access path during an audit.
• Free text left in. A discharge summary contains names, addresses and employers. The identifier list says nothing about narrative fields, which is where the identifiers actually live.
• Quasi-identifier re-identification. Dates plus ZIP plus a diagnosis sequence single people out, which is why the agreement's re-identification prohibition carries the weight.
• Agreement drift. The recipient's use expands over two years while the agreement describes the original study.
• A keyed hash mistaken for a tier. Pseudonymising the patient id is neither method under the rule, and the data remains fully in scope while the team believes it does not.

Trade-offs

When not to use it

If the analysis can be expressed on month or year granularity, safe harbor is the better architecture because it removes the dataset from scope rather than managing it inside scope. And if the readmission flag can be computed in the clinical system so that only the flag plus a month leaves, neither tier is needed for the analytics estate at all. The question to ask before choosing a tier is what granularity the analysis needs, not what rows the analytics team asked for.

Interview question

Q: Analytics wants six years of encounters with exact admission and discharge dates for a 30-day readmission model, and the privacy office refuses PHI in the analytics account. Which sharing tier do you choose, and what does the account then have to provide?

What a strong answer covers: safe harbor eliminated by the date requirement, with the specific rule; the limited data set as the fitting tier, with its identifier removals and the data use agreement's required terms; the recognition that the data is still PHI so logging, access control and the associate chain still apply; expert determination as the route only when data must leave as non-PHI; and the cheaper alternative of computing the interval upstream.

Quick check

Quiz: What does a limited data set keep that safe harbor removes, and what does it cost you? Dates and town or city plus state and ZIP; the cost is that the data remains protected health information and needs a data use agreement.

Flashcard: Why is a limited data set not a de-identification method? Because it is still protected health information - it restricts content and binds use by agreement rather than taking the dataset out of the rule's scope.