Patient Data Is Different: What HIPAA Demands of Software That Handles PHI
A leaked marketing email is an embarrassment. A leaked medical record is a federal case, a fine that scales with every name in the file, and a patient who learns their diagnosis traveled somewhere they never agreed to send it. That gap is what protected health information means in practice, and it is why software that handles PHI lives under a stricter law than almost anything else you will build. HIPAA is that law, and it does not grade on effort.
Most teams meet HIPAA the way they meet a fire code, as a row of boxes to tick on the way to launch. That earns a certificate and not much safety. The useful way to read HIPAA is as one demand stated three ways: hold the least patient data you can, guard hard what you must hold, and make every vendor in the chain sign for their share of the risk. Collect less, harden the rest, put it in writing.
The short version: PHI is any health detail tied to a person, and HIPAA governs every system that stores or moves it. Three things keep you on the right side of it. First, data minimization: keep PHI out of every layer that does not strictly need it, because the data you never collected cannot leak. Second, hardening: encryption in transit and at rest, access locked to named people, an audit trail of who saw what, and the minimum-necessary rule enforced in code. Third, a Business Associate Agreement, the contract that makes every vendor touching that PHI directly liable for protecting it. Skip any one and the other two cannot cover for it.
Why PHI is treated differently from ordinary data
PHI is protected health information: a person’s condition, care, or payment for care, tied to something that identifies them. A name beside a diagnosis. A phone number beside an accident date. On its own, each piece is mundane. Joined, they become the most personal record a stranger could hold, and the law guards the join, not the pieces.
The reason is plain. You can change a leaked password. You cannot change your medical history. A breach of PHI is permanent in a way a breach of a card number never is, so the penalties are built to match: fines assessed per record, climbing into the millions, and a public breach notice that does its own damage. When the cost of being wrong is that lopsided, you stop designing for the good day and start designing for the morning the data tries to walk out the door.
What HIPAA actually requires of your software
Strip away the legal language and HIPAA’s Security Rule asks for a short list of concrete things. Everyone who reaches PHI has their own identity in the system, not a shared login. The data is encrypted in transit and at rest, so a stolen disk or an intercepted request is noise instead of names. Every access is recorded, so the system can answer who opened this record and when without anyone rebuilding it by hand. And each person reaches only the PHI their job needs, which is the minimum-necessary rule: the front desk does not need the chart, and the chart does not need the billing note.
None of that is exotic. It is the engineering you would want around any valuable data, written into law because health data earned it. The trap is treating these as switches you flip once. They are properties the system has to keep being true on every request, long after launch, when nobody is watching.
| The obligation | What it looks like in the build |
|---|---|
| Collect less | Keep PHI out of every layer that does not strictly need it, so most of the system has nothing sensitive to leak. |
| Harden the rest | Encrypt in transit and at rest, log every access, and wall each role to the minimum data its job needs. |
| Sign for it | A Business Associate Agreement makes every vendor that touches PHI directly liable and bound to report a breach. |
The hardening that turns a policy into a wall
A privacy policy is a promise. Hardening is what makes the promise hard to break by accident. The two are not the same thing, and patients live in the gap between them.
Where I can, I push the protection below the level where one forgotten line can undo it. The strongest move is to not hold the PHI at all: keep the public-facing layer free of anything clinical, so a form, a webhook, or a log file has nothing sensitive to spill in the first place. What must be held gets isolated and encrypted, with one tenant or one role walled off from another’s records by the database itself, not by a filter someone has to remember to write. Access runs through named accounts on an allowlist, not a password making the rounds. Alerts carry the fact of an event, never the patient inside it. Each of these deletes a way to be wrong, instead of asking a person to remember not to be.
The BAA: why every vendor that touches PHI has to sign
Here is the part teams building for healthcare miss until a deal stalls on it. The moment patient data flows through your software, HIPAA stops seeing you as merely the vendor. You become a business associate, directly liable for that data, and the practice you serve is legally barred from handing it to you until you sign a Business Associate Agreement.
A BAA is the contract that carries the wall past the clinic’s own four walls. It names what you may do with the PHI and nothing beyond that, commits you to guard it to HIPAA’s standard, requires you to report a breach instead of quietly absorbing it, and binds your own subcontractors to the same terms, so the cloud host underneath you is covered too. The why is liability: HIPAA will not let a covered entity shed its duty by outsourcing the data. The what is a signature that turns your good intentions into obligations a regulator can enforce.
A BAA without real hardening is a promise you cannot keep. Hardening without a BAA is exposure you are not allowed to carry. You need both, and you need them before the first record arrives, not after.
Collect less, harden the rest, sign for what you hold. The safest patient record is the one you never collected, and the next safest is the one only the right person can reach.
Frequently asked questions
What is protected health information (PHI)?
PHI is any health information that can be tied to a specific person: a diagnosis, a treatment, a payment for care, or even an appointment, joined to something that identifies them like a name, a phone number, or an account. The identifier plus the health fact together are what HIPAA protects.
What does HIPAA require software to do?
At a technical level, HIPAA’s Security Rule asks for a unique identity for everyone who reaches PHI, encryption of that data in transit and at rest, an audit log of who accessed what, and access limited to the minimum each person actually needs. These are properties the system must keep true on every request, not one-time settings.
What is a Business Associate Agreement (BAA)?
A BAA is a contract HIPAA requires between a healthcare provider and any vendor whose software stores or moves PHI on its behalf. It makes the vendor directly liable for protecting that data, limits what the vendor may do with it, requires breach reporting, and binds the vendor’s own subcontractors to the same terms.
Does an app that only collects a callback request need a BAA?
If the intake genuinely holds no health information, that public layer is not handling PHI, and the BAA is about the systems that do. The cleanest design keeps PHI out of the front door entirely, so the part patients touch carries nothing sensitive, while the BAA covers the protected systems behind it where the clinical data actually lives.
What is the minimum-necessary rule?
It is HIPAA’s principle that a person or system should use or disclose only the least PHI needed for the task at hand. In practice it means the front desk cannot pull a full chart, a billing tool sees charges and not clinical notes, and every role is walled to exactly the data its job requires.