HIPAA for Engineers: What the Rule Requires of the System You Build

Teams building healthcare software usually meet HIPAA as a checklist handed over late, written for lawyers. The useful translation — what it means for the schema, the logs and the vendor contracts — rarely comes with it.

Start with the correction that saves the most confusion: there is no such thing as being HIPAA certified. No authority issues that. There are obligations, there is your evidence that you meet them, and there is an auditor's judgement. Any vendor claiming a HIPAA certificate is telling you something about their marketing rather than their controls.

The boundary is the design decision

Almost everything follows from one question: where does protected health information live, and where does it not?

PHI is health information tied to an identifiable person. The identifiers are broader than teams expect — not just name and record number, but dates more precise than a year, full postcodes, device serials, IP addresses in some contexts, and any other field that could single someone out.

Draw the boundary deliberately and keep it small. Systems that let PHI diffuse everywhere are the ones where compliance becomes permanently expensive, because every new service inherits the full control set. The teams that stay fast are the ones that decided early which components are inside the boundary and pushed everything else out.

The corollary is that de-identification is an architectural tool, not a reporting convenience. Analytics, testing and most machine learning can run on de-identified data. Doing that shrinks the boundary permanently.

Controls that become code

Four obligations translate directly into engineering work:

• Access control, meaning minimum necessary. Not "authenticated users can read patients" but "this role, for these patients, for this reason". Role-per-job-function is usually too coarse; the access decision often needs the treatment relationship as an input.
• Audit logging that answers who saw what, when. Read access, not just writes. This is the requirement most often missed, because ordinary application logging records changes and HIPAA cares about views. Retrofitting read-audit into a mature system is expensive.
• Encryption in transit and at rest, with key management you can describe. Addressable rather than strictly required in the text, but in practice the alternative is documenting why you chose not to, which nobody wants to write.
• Integrity and disposal. Being able to show records were not improperly altered, and that data is actually destroyed when retention ends — including in backups, which is the part that gets forgotten.

Business associate agreements are an architecture constraint

Any vendor that touches PHI on your behalf needs a business associate agreement. That includes the obvious infrastructure providers and also the ones teams forget: error tracking, log aggregation, analytics, email delivery, customer support tooling, and increasingly whichever API is behind an AI feature.

This constrains design in a way worth knowing before you build. A stack trace containing a patient identifier, shipped to a monitoring service without a BAA, is a disclosure. Scrubbing at the edge is not optional, and it is much easier to build in than to add.

The failure mode: compliance as a phase

The pattern that produces the worst outcomes is treating HIPAA as a gate before launch. A team builds the product, a review lands weeks out, and the findings are structural — PHI in a search index, no read-audit, a third-party integration with no agreement in place.

Those are not fixes. They are redesigns, discovered at the moment there is least time. The cheap version of this work is a boundary decision in the first architecture conversation and a scrubbing layer written in the first sprint.

Where we would push back

If the product does not need identifiable health data to deliver its value, do not collect it. The cheapest compliance posture is a smaller footprint, and teams routinely collect date of birth and full address out of habit rather than requirement.

We would also push back on treating HIPAA as the whole obligation. State law can be stricter, particularly around mental health, reproductive and substance-use records; consumer privacy law may apply to the same data on a different basis. A design that satisfies only the federal rule can still be non-compliant.

What we do

We build to these requirements and support clients through their own audits. We hold no certification ourselves, and as above, none exists to hold. What we bring is the boundary conversation early, read-audit and scrubbing built in from the start, and a written record of the decisions — because when an assessor asks why something was done a particular way, the answer needs to have been written down at the time.

Breach notification sets a clock you must be able to meet

The obligation people plan for is prevention. The one that catches teams out is what happens afterwards: when protected information is exposed, there are notification duties on a defined timetable, and meeting them requires knowing precisely whose data was involved.

That is a logging requirement disguised as a legal one. If your audit trail cannot reconstruct which records a compromised account accessed, you cannot scope the disclosure, and the conservative answer becomes notifying everyone. The difference between a precise trail and a vague one is the difference between contacting two hundred people and contacting the whole database.

Build for that question specifically. Read-level audit, retained long enough to cover a breach discovered months later, queryable by account and by record rather than only by timestamp. Then test it: take a random account and ask what it accessed last quarter. If nobody can answer within a day, the trail will not hold up when it matters.

More on the surrounding work in healthcare and security engineering.