25.33 — HIPAA, PHI and Privacy in Practice

A developer needs realistic data to debug a problem in production. She copies a few thousand patient records to her laptop, removes the names, and gets to work.

She has just created a reportable breach. The records still contain dates of birth, full postal codes, admission dates and medical record numbers, so they are still identifiable under the law. The laptop is outside the controlled environment. Nobody authorised the copy. And the organisation now has a legal duty to determine whether notification is required.

This chapter exists so that you never do that, and so that you can explain to a client's security officer exactly why your design does not require it.

Who the rules apply to

HIPAA — the Health Insurance Portability and Accountability Act of 1996 — applies to covered entities and, through them, to their business associates.

Covered entities are health plans, healthcare clearinghouses, and healthcare providers who transmit health information electronically in connection with standard transactions. In practice: insurers, hospitals, physician practices, pharmacies, laboratories.

A business associate is anyone who creates, receives, maintains or transmits protected health information on behalf of a covered entity. Your services company, hosting or processing a client's patient data, is a business associate. So is your cloud provider, as your subcontractor.

Two consequences follow that engineers routinely get wrong.

Business associates are directly liable. Since the 2013 changes, a business associate can be penalised by the regulator directly — not merely sued by its customer.

And the obligation flows down the chain. A business associate agreement is required between the covered entity and you, and between you and every subcontractor who touches the data. A gap anywhere in that chain is a finding.

And an important limit: a pharmaceutical manufacturer is generally not a covered entity. It becomes subject to these rules when acting as a business associate of one, or through the patient authorisations that govern programmes like those in Chapter 25.25 — which is why authorisation language matters so much there.

What counts as protected health information

PHI is individually identifiable health information held or transmitted by a covered entity or business associate, in any form. In electronic form it is called ePHI.

"Individually identifiable" is broader than most people assume, and the eighteen identifiers used in the de-identification standard are the practical list. Names; geographic subdivisions smaller than a state, including postal codes at full precision; all dates directly related to an individual except the year, including birth date, admission and discharge dates and date of death; telephone and fax numbers; email addresses; social security numbers; medical record numbers; health plan numbers; account numbers; certificate and licence numbers; vehicle identifiers; device identifiers and serial numbers; web addresses; IP addresses; biometric identifiers including fingerprints and voiceprints; full-face photographs and comparable images; and any other unique identifying number, characteristic or code.

Read the third item again, because it is the one that catches development teams. Admission and discharge dates are identifiers. A "de-identified" data set that retains exact dates is not de-identified.

What data may be used for

The rule permits use and disclosure for treatment, payment and healthcare operations without the patient's authorisation. Everything else generally needs a written authorisation from the patient, with defined exceptions such as public health reporting, certain law enforcement situations, and research under an ethics committee waiver.

And a principle applies across nearly all of it: minimum necessary. Use or disclose only what is needed for the purpose. Treatment is excluded from this limit, because a clinician needs the whole picture.

In engineering terms, minimum necessary is a role and scope requirement. A billing analyst does not need clinical notes. A support engineer does not need any patient record to reset a password. Systems that grant broad access because scoping was inconvenient are the normal cause of the largest breach findings, and the fix is architectural rather than procedural.

De-identification, done properly

De-identified data is outside the rule entirely, which makes de-identification enormously useful — and the two permitted methods are specific.

The safe harbor method removes all eighteen identifier categories listed above, and requires that the organisation has no actual knowledge that the remaining information could identify someone. It is mechanical, cheap and conservative, and it destroys a lot of analytic value — particularly by reducing dates to years.

Expert determination has a qualified statistician apply accepted methods to conclude that the risk of identification is very small, and document that analysis. It permits richer data — shifted dates preserving intervals, wider geography — at the cost of a formal assessment.

There is also a middle category, the limited data set: certain identifiers removed but dates and some geography retained, usable for research, public health and operations under a data use agreement.

One warning worth carrying into any conversation about anonymised health data. Re-identification is easier than people assume. A small number of attributes — approximate age, sex, postal area, a rare diagnosis and a date — can be enough to single somebody out in a population. Treat "we removed the names" as the beginning of the work, not the end of it.

The Security Rule, in engineering terms

The Security Rule governs electronic PHI specifically, and it is organised into administrative, physical and technical safeguards.

Administrative: a formal risk analysis, a risk management process, workforce training, access management, incident response, contingency planning, and periodic evaluation.

Physical: facility access controls, workstation security, and device and media controls including how equipment is disposed of and reused.

Technical: access control with unique user identification, automatic logoff and emergency access; audit controls recording activity in systems containing ePHI; integrity controls; authentication; and transmission security.

The rule is deliberately technology-neutral, distinguishing required specifications from addressable ones — where addressable means you must implement it if reasonable and appropriate, or document why not and implement an equivalent alternative. "Addressable" has never meant optional, and treating it that way is the single most common misreading of the rule.

A substantial update is in progress and its status matters when advising a client. A notice of proposed rulemaking to strengthen the Security Rule was published in the Federal Register on 6 January 2025, with the comment period closing on 7 March 2025 and more than four thousand comments received. As of mid-2026 no final rule has been issued, and the expected timetable for final action has moved out to 2027.

What it proposes is close to modern security practice made mandatory: removing the required-versus-addressable distinction so that all specifications are required, requiring an asset inventory and network map, requiring multi-factor authentication, expanding encryption requirements, requiring vulnerability scanning and penetration testing, strengthening oversight of business associates, and requiring detailed incident response and recovery planning. Any client asking what to build towards should be building towards that, because it is unlikely to become less demanding.

Breaches, and the notification clock

A breach is an impermissible acquisition, access, use or disclosure of unsecured PHI. It is presumed to be a breach unless a risk assessment shows a low probability that the information was compromised — considering the nature of the data, who obtained it, whether it was actually viewed, and how far the risk was mitigated.

The obligations that follow are time-bound. Affected individuals must be notified without unreasonable delay and no later than 60 days after discovery. Breaches affecting 500 or more individuals must be reported to the regulator without unreasonable delay and within 60 days, and prominent media notice is required in the affected area. Smaller breaches are logged and reported annually. A business associate must notify the covered entity, which is why your incident response process and theirs must interlock and be tested.

And there is a safe harbour worth designing towards. Properly encrypted data, where the key was not compromised, is not "unsecured" — so a lost encrypted laptop is not a reportable breach. This is the clearest example in health IT of a control that pays for itself in a single incident.

Penalties are tiered by culpability, from unknowing violations at the low end to wilful neglect that was not corrected at the high end, with per-violation amounts and annual caps that are adjusted for inflation. The largest settlements have typically arisen not from a single clever attack but from a missing risk analysis, unencrypted devices, or access controls nobody had reviewed for years.

The rules beyond HIPAA

Assuming HIPAA is the whole picture is the second most common mistake in this area.

Substance use disorder treatment records from federally assisted programmes carry stricter federal protection under their own regulation, historically requiring specific consent for most disclosures. Recent rulemaking has aligned parts of it more closely with HIPAA, but it remains a distinct regime, and systems that mix these records with general clinical data without segmentation create real problems.

State laws can be stricter and are not overridden. Several states have specific rules for mental health, genetic information, HIV status and minors' records, and newer state privacy laws create obligations around health data held by organisations that are not covered entities at all.

Which is the gap most people miss. A wellness app, a symptom checker, or a direct-to-consumer test may hold deeply sensitive health information and fall entirely outside HIPAA, because the entity is not a covered entity. Other law — state privacy statutes and consumer protection enforcement — applies instead. "We are not covered by HIPAA" is not the same as "we may do what we like with this data", and saying so early in a product discussion prevents an expensive reversal later.

And European data protection law applies to personal data of people in the European Union, including clinical trial and safety data, with its own basis-for-processing, transfer and rights requirements (Chapter 25.14).

Rules of thumb for engineers

These are the habits that keep you and your client out of trouble, and every one of them is cheap if adopted at the start.

Never copy production data to a development environment. Generate synthetic data, or use a properly de-identified set produced through a controlled process. This one rule prevents most accidental breaches.

Encrypt everywhere — at rest and in transit — and manage the keys properly, because the safe harbour depends on it.

Log access to PHI, and review the logs. An audit log nobody reads has the same failure mode as the unreviewed audit trails of Chapter 25.20.

Scope access by role, and make broad access require an explicit, recorded justification — the "break glass" pattern, which is legitimate when it is logged and reviewed.

Put retention and deletion in the design. Data kept beyond its purpose is risk with no benefit, subject to the retention obligations of the regulated processes elsewhere in this Part.

And be careful with what leaves the boundary. Analytics scripts, error reporting, screenshots in support tickets, third-party libraries that phone home, and log lines containing request bodies have all caused real breaches. The disclosure does not have to be deliberate to be reportable.

Next: Chapter 25.34, your own chapter — what it is actually like to build software inside a GxP environment, what you will be asked for, and the traps that catch engineers who arrive from ordinary technology work.