Modernization
Modernization4 min read
What “HIPAA-compliant software” actually requires
There is no HIPAA certification for software. What exists is a set of controls you either implemented or did not, plus a BAA that makes them your problem.
Working on something like this?
Get an estimateThe short version
- No software is “HIPAA certified.” There is no such certification. Treat any vendor claiming one as a warning.
- Your cloud provider's BAA covers their infrastructure, not your application. The gap is where breaches happen.
- Retrofitting compliance costs roughly three times designing it in, mostly in access control and audit logging.
- PHI is broader than medical records. An appointment time tied to a name is PHI.
“Is it HIPAA compliant?” is asked of software constantly and cannot be answered as asked. HIPAA regulates covered entities and their business associates, meaning organisations rather than applications. Software can support compliance or undermine it. It cannot possess it.
What that means in practice is a specific set of controls, a chain of agreements, and a documented ability to prove both. It is why every healthcare build we take on starts by drawing the PHI boundary rather than by drawing screens.
What counts as PHI
Broader than teams expect. PHI is health information combined with anything that identifies an individual, and the identifiers list runs to eighteen items.
- An appointment time attached to a name is PHI
- An email address on a list of clinic patients is PHI
- A support ticket saying “can't log in to my therapy portal” is PHI
- An IP address in a log alongside a patient session is PHI
- A full-face photograph is PHI on its own
This is why the surface area is larger than “the database with the medical records.” Your logs, your error tracker, your analytics, your support desk, and your backups are all in scope the moment identifiable health data reaches them, and it reaches them by default unless someone stopped it.
The BAA chain, and the gap in it
A Business Associate Agreement is required with every vendor that touches PHI on your behalf. AWS, Azure, and GCP all sign one.
The critical detail: a cloud BAA covers the provider's infrastructure, not your use of it. AWS commits that S3 is secure. It does not commit that your bucket is private, and a public bucket is your breach, not theirs. This is also the argument for the software running in *your* account rather than a vendor's — one clinic group rejected a portal proposal on exactly that point before we were involved.
Each provider also publishes a list of HIPAA-eligible services. Using a non-eligible service for PHI puts you outside the BAA regardless of how the service is configured. That is a common and unforced error.
Every vendor in the path needs a BAA
- Cloud provider, and only its HIPAA-eligible services
- Error tracking, if a stack trace can carry a record identifier
- Log aggregation and APM
- Email and SMS providers, if messages reference appointments or care
- Support desk, if tickets contain patient detail
- Analytics, since most consumer analytics tools will not sign one
The controls that actually get built
1
Access control that is per-record, not per-role
“Clinicians can read charts” is insufficient. The question is which clinician, for which patient, and on what basis. This is minimum-necessary access, and it is the control most often under-built.
2
Audit logging that answers who saw what, when
Every read of PHI, not only every write. Immutable, retained, and queryable by a compliance officer without an engineer. This is the second most under-built control and the one auditors ask about first.
3
Encryption in transit and at rest
TLS 1.2+ everywhere including internal service calls, encrypted volumes and buckets, managed keys with rotation. The straightforward part, and the part vendors point at to avoid discussing the first two.
4
Automatic session termination
Idle timeouts on anything displaying PHI. Shared clinical workstations make this concrete rather than theoretical.
5
Backup, retention, and disposal
Encrypted backups, a tested restore, a defined retention period, and documented destruction. Backups are PHI too, and they outlive the systems that made them.
6
Breach detection and a written response plan
The Breach Notification Rule imposes deadlines. Meeting them requires knowing a breach occurred, which requires monitoring built beforehand.
Why retrofitting costs three times more
Designed in, these controls are architecture. Retrofitted, they are surgery on a running system, and they land in the cost of the build either way.
~36933×
typical cost of retrofitting compliance versus building it in
1471193788
identifiers that turn health data into PHI
What to ask a development partner
- 1Will you sign a BAA, and have you before? This and the rest of the list belong in the questions you ask any agency.
- 2How do you keep PHI out of logs, error reports, and analytics?
- 3Show me an audit log design from a previous build.
- 4How is minimum-necessary access enforced in the data layer, not the UI? This is database work as much as application work.
- 5What is in scope for PHI, and what is deliberately kept out, and how?
The last one is the most revealing. Good healthcare architecture is mostly about keeping PHI out of places it does not need to be. A team that only talks about protecting it everywhere has not designed the boundary.
Working through this on a real project?
Tell us what you are building. You will get a scoped estimate and an architecture you own, not a capability deck.
Common questions
No. HIPAA regulates covered entities and their business associates, meaning organisations rather than applications, and no government body certifies software as compliant. Vendors advertising a HIPAA certificate are describing a self-assessment or a third-party audit against a private checklist. That can be useful evidence, but a vendor that presents it as certification is misrepresenting it.
Health information combined with any of eighteen identifiers. In practice that is much broader than medical records: an appointment time attached to a name, an email address on a clinic's patient list, a support ticket mentioning a therapy portal, an IP address logged alongside a patient session, or a full-face photograph. Logs, error trackers, analytics, and backups are all in scope by default.
No. A cloud BAA covers the provider's infrastructure, not how you use it. AWS commits that its services are secure; it does not commit that your bucket is private. Providers also publish lists of HIPAA-eligible services, and using a non-eligible service for PHI places you outside the BAA regardless of configuration.
Expect 20–35% on top of an equivalent unregulated build when designed in from the start, and roughly three times that premium if retrofitted. The difference is concentrated in per-record access control and audit logging: as architecture they are patterns every query follows, but retrofitted they mean auditing every query already written and finding every access path in a live system.