Patient Data Is Different: What HIPAA Demands of Software That Handles PHI

A leaked medical record can expose a diagnosis, treatment, payment history, and identity at once. That is why software handling protected health information belongs in a stricter risk category. HIPAA sets the legal framework, and the implementation has to match the system’s actual threats and data flows.

The useful engineering brief has three parts: hold the least patient data the job needs, protect what must remain, and document which vendors are business associates. Collect less, harden the rest, and put each party’s duties in writing.

The short version: PHI is health information tied to an identifiable person. A sound HIPAA software design minimizes PHI, uses individual access controls and audit records, performs the required security risk analysis, and protects data in transit and at rest according to that analysis. HIPAA treats encryption as an addressable Security Rule specification, which means the organization must assess it and implement it when reasonable and appropriate, or document an equivalent measure or why none is reasonable. A Business Associate Agreement is generally required when a vendor creates, receives, maintains, or transmits PHI for a covered entity. A narrow conduit exception exists for entities that only transport information with temporary, incidental storage.

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 reset a leaked password. You cannot replace a medical history. HHS can investigate complaints and breaches, require corrective action, and impose civil penalties based on the facts and level of culpability. The current HHS enforcement overview is a better reference than a fixed dollar figure that changes through inflation adjustments.

What HIPAA actually requires of your software

Strip away the legal language and the Security Rule still starts with risk analysis and risk management. Everyone who reaches electronic PHI should have an attributable identity rather than a shared login. The system needs access controls, audit controls, integrity protections, authentication, and transmission security appropriate to its risks. The Privacy Rule’s minimum-necessary standard should also shape roles and workflows, so each person or system uses only the PHI needed for the task.

HHS explains that encryption is addressable, not automatically mandatory in every circumstance. Addressable does not mean optional by convenience. The organization must assess whether encryption is reasonable and appropriate. If it is, implement it. If it is not, document the decision and use an equivalent alternative when reasonable and appropriate. In most modern software handling PHI, strong encryption in transit and at rest is a sensible control, but the legal statement should remain exact.

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	Complete a risk analysis, use named access, audit activity, protect integrity and transmission, and assess encryption for data in transit and at rest.
Contract correctly	Sign a BAA with vendors that create, receive, maintain, or transmit PHI on the covered entity’s behalf, subject to narrow exceptions.

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: which vendors need to sign

If a vendor creates, receives, maintains, or transmits PHI while performing a function for a covered entity, that vendor is generally a business associate and needs a Business Associate Agreement before the work begins. HHS applies this even when a cloud provider stores only encrypted PHI and does not hold the decryption key, as its cloud-computing guidance explains.

The scope is not literally every company whose infrastructure carries a packet. HHS recognizes a narrow conduit exception for transmission services with only temporary, incidental storage. Persistent storage generally moves a provider outside that exception. The data flow and service role decide the answer, so contract review should follow the actual architecture.

A BAA limits permitted uses and disclosures, requires safeguards and incident reporting, and addresses subcontractors that handle PHI. It does not replace technical controls or a risk analysis. It documents duties that the architecture must be capable of meeting.

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.

The same put-it-in-writing instinct governs other regulated work. An automated calling program is legal only when consent is captured and logged before the first dial, its own version of this discipline.

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. I built this into phone operations a medical practice watches live.

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 calls for risk analysis and appropriate administrative, physical, and technical safeguards. Software commonly needs attributable identities, access controls, audit controls, integrity protections, authentication, and transmission security. Encryption is an addressable specification that must be assessed and documented, and is often the reasonable control for modern PHI systems.

What is a Business Associate Agreement (BAA)?

A BAA is the required contract when a vendor is acting as a business associate by creating, receiving, maintaining, or transmitting PHI for a covered entity. It limits permitted uses, requires safeguards and reporting, and extends relevant duties to subcontractors. Narrow exceptions such as a true conduit should be assessed against the actual service.

Does an app that only collects a callback request need a BAA?

It depends on the data, the parties, and the service. A callback request can become PHI when it links identifiable information to care from a covered provider. Map every field and recipient, keep clinical details out of public intake where possible, and have counsel confirm the covered-entity and business-associate roles.

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.