HIPAA software compliance guide
What the Security Rule asks of a system that handles electronic health information, and the evidence that proves it.
What the guide covers
4 things that decide this
- 01No government body certifies software as HIPAA compliant. You put safeguards in place and write down why. That written record is what an investigation reads.
- 02HHS splits the rules into required and addressable. Addressable does not mean optional. Treating it that way is the most common buyer mistake.
- 03The Security Rule covers health data held or sent electronically. The same details on paper, or said out loud, sit outside it.
- 04Audit controls shape the software most. Your system has to record activity on that data, and let a person examine it.
Buyers keep asking for a certificate that does not exist
Ask a vendor whether their software is HIPAA compliant and you will usually get a yes. The question has no yes or no answer. So that yes tells you nothing.
HHS built the Security Rule to be, in its words, "scalable, and technology neutral". It does not name the security measures you must use. Instead it asks you to weigh four things: your size, your infrastructure, what a measure costs, and how likely and how serious the risks are.
Ask what evidence the system produces instead, and who signed off on the choices behind it. TrialTriage was built that way. It is HIPAA-aligned, tracks 23 audit action types, and sets access by role across four user types. Any result traces back to what produced it.
- Risk analysisAccurate, thorough, and written down
- Access controlOnly authorised people reach the data
- Audit recordActivity recorded and examinable
- Integrity checkConfirms data was not altered improperly
- Transmission securityProtection across a network
- Written decisionsWhy each measure was reasonable
HHS names the outcomes, not the technology. Evidence of the decision is part of the requirement.
Required, addressable, and what each means for a build
The distinction that decides most disputes. Wording follows the HHS summary of the Security Rule.
| Term | What HHS says | What it means for your software |
|---|---|---|
| Standard | Regulated entities must comply with every Security Rule standard | Non-negotiable. No trade-off analysis applies here |
| Required specification | Required implementation specifications must be implemented | Build it. There is no alternative route |
| Addressable specification | Addressable does not mean optional | Implement it where reasonable and appropriate, or adopt an alternative that achieves the same purpose |
| Skipping an addressable item | The entity must document why it is not reasonable and appropriate | The written reasoning is itself the deliverable |
| Risk analysis | An accurate and thorough assessment of potential risks and vulnerabilities to ePHI | It drives every other choice, so it comes before the architecture |
| Audit controls | Hardware, software or procedural mechanisms that record and examine activity | Logging alone is not enough. Someone has to be able to examine it |
| Business associate agreement | Required in writing before a business associate touches the data | It obliges subcontractors too, so the chain has to be mapped |
A signed BAA is a contract, not a control
A business associate agreement records a vendor's assurance that they will safeguard the data. It inspects nothing. It cannot make a weak design safe.
Two gaps show up again and again. One is scope. The rule covers electronic data, so the same details read aloud on a support call still matter but sit outside it. The other is subcontractors. A BAA commits your vendor to binding anyone they pass data to. Your model provider, your logging tool and your analytics vendor all belong on a map somebody keeps current.
For an AI feature, ask where the data goes when the model runs, and what is kept. Answer that before you pick a model. It shapes the architecture rather than following from it.
- 01Write the risk analysis first. HHS treats it as the thing that drives every other safeguard.
- 02Make the audit trail readable by a person, not just written to a log file nobody opens.
- 03Map every subcontractor that touches the data, including the ones added after launch.
- 04Decide what a model may receive, and keep that boundary in code rather than in a policy document.
