A hospital group's analytics team wants six years of encounters in a research store to model 30-day readmissions, which needs exact admission and discharge dates. The privacy office will not approve protected health information in the analytics account as it stands. Which arrangement fits the requirement as stated?

The deciding property

The model needs exact dates, and that single fact eliminates the cheapest option. Under the HIPAA safe harbor method at 45 CFR 164.514(b)(2), dates directly 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. The readmission window the model has to measure is 30 days, and an interval of 30 days cannot be computed from years.

Why a limited data set

The limited data set at 45 CFR 164.514(e) is the middle tier that exists for exactly this case. Direct identifiers go: names, postal address other than town or city, 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, for the patient and for relatives, employers and household members. Dates stay. Use or disclosure requires a data use agreement that fixes the permitted uses, names who may receive the data, requires safeguards, obliges the recipient to report unauthorised use and prohibits re-identification.

The architectural consequence is the part teams miss: a limited data set is still protected health information. The analytics account inherits access control, audit logging, encryption decisions and the business associate chain. You have not moved the data out of scope; you have reduced what it contains and bound what may be done with it.

Why not the others

• Safe harbor is the right answer when month or year granularity is enough, because it takes the dataset out of HIPAA's scope entirely and that is a large and permanent saving. It cannot support a day-level interval.
• Expert determination can permit dates where a qualified expert documents a very small re-identification risk, and it is the route for datasets that must leave as non-PHI. It is dataset-specific, needs re-doing when the data or the population changes, and costs expert time on every revision. Reach for it when the data has to be published or shared widely, not for an internal store.
• A keyed hash of the patient id is pseudonymisation, not de-identification under either method. It fails both tests. Dates, ZIP and diagnosis sequences remain, the combination still singles people out, and the data stays fully in scope while the team believes otherwise. That belief is the failure mode: controls get relaxed on a store that is still regulated, and the gap surfaces as an unlogged access path during an audit.

In production the tier should be a pipeline stage or a view with tests over the identifier columns, never a manual export, because the transformation is the control.

When this is the wrong answer

Ask what granularity the model actually needs before choosing a tier. If a readmission flag can be computed upstream in the clinical system and only the flag plus month of discharge leaves, safe harbor applies and the whole analytics estate drops out of scope. Pushing the date-sensitive computation to where the data already lives is cheaper than negotiating agreements and running a second compliant account, and it is the option nobody proposes because the analytics team asked for rows rather than for an answer.