HIPAA
HIPAA compliant software, built the cheap way round
Audit trails and de-identified fields cost little when the schema is drawn. Retrofitting them into a live clinical system is the expensive path.
Five things to get right before you write code
5 things that decide this
- 01HIPAA names no certification at all, which is exactly why buyers fall back on asking for SOC 2 Type II or HITRUST.
- 02Audit controls are a required standard under the technical safeguards at 45 CFR 164.312. Encryption sits in the addressable category, which means you implement it or record a reasoned alternative.
- 03Most teams do this backwards. They encrypt everything, log almost nothing, and then cannot say which records a named person opened on a given day.
- 04A signed business associate agreement is a promise about handling, not proof of a control. It also does not transfer liability, and it does not cover your subcontractors automatically.
- 05Every subcontractor touching protected health information needs its own agreement, including the model provider behind an AI feature.
Compliance is a data model decision, not a checklist
Teams usually meet HIPAA as a questionnaire. Somebody in procurement sends a spreadsheet, and engineering answers it after the product is built. By then the expensive answers are already fixed.
Two decisions carry most of the weight, and both are made in the first week. What you collect, and what you record about who touched it. Neither is a feature you can add on a Friday.
The Breach Notification Rule makes this concrete. A breach question asks which records a specific person accessed and when. Reconstructing that after the fact is not possible from ordinary request logs. Somebody has to have designed for the question.
Required against addressable, and what each means for a build
From the technical safeguards at 45 CFR 164.312. Addressable does not mean optional. It means implement it, or document a reasoned equivalent.
| Safeguard | Category | What the build has to do |
|---|---|---|
| Access control | Required standard | Unique identification per user. No shared logins, because attribution is the point. |
| Audit controls | Required standard | Record activity on systems holding PHI, and make that record reviewable rather than merely stored. |
| Integrity | Required standard | Show that records are intact, and that any improper change would be caught. |
| Authentication | Required standard | Verify that a person or system is who it claims to be. |
| Encryption | Addressable | Implement it, or write down the reasoned alternative you chose instead. |
| Automatic logoff | Addressable | End sessions after inactivity, or justify why your setting differs. |
- Decide the fieldsCollect the least the job needs.
- Draw the schemaAge bands, prefixes, stand-in IDs.
- Design the trailWho touched which record, when.
- Set the rolesLeast privilege, enforced at the API.
- Then buildFeatures sit on top of all four.
Reverse this order and every step becomes a migration against live patient data. That is the same work, done under pressure, with a regulator's clock running.
Minimum necessary applied at the screen, not the endpoint
A front end hides the fields a role should not see. The endpoint behind it still returns the whole record. Anyone who opens the browser developer tools gets everything, and the access log shows a normal request.
This passes a demo, a code review and often a penetration test scoped to the user interface. It fails the standard, because the disclosure already happened at the API.
The fix is unglamorous. Filter at the query, test the endpoint directly as each role, and treat a field appearing in a response as a disclosure regardless of what the screen drew.
- Test every endpoint as every role, not just the screens.
- Treat free-text notes as identified until a scrubber and a human say otherwise.
- Log the read, not only the write. Breach questions are about who looked.
Systems built around regulated data from the first commit
TrialTriage
AI clinical trial matching for oncology nurses and insurers.
Read the case study →
Shift Link
AI workforce compliance and shift management for healthcare and logistics.
Read the case study →
WorkMateAI
Dispute resolution, payments, and compliance for Australia's on-demand trades.
Read the case study →
“I am extremely happy with the results and would highly recommend Hashlogics to anyone.”
Daniel Khin · CEO, PremiumAudit.io
What we build regulated systems on
Application
Data
Access
Delivery
What teams ask about HIPAA and software
01Does using AWS or Azure make our app HIPAA compliant?
No. A cloud provider will sign an agreement covering its own infrastructure obligations, and that is where its coverage stops. How you configure the service, what you store, who can reach it and what you log are all yours. Two teams on identical infrastructure can land in completely different places.
02Do we need HITRUST, or is SOC 2 enough?
It turns on who is buying, because HIPAA requires neither. Digital health startups and most commercial buyers accept SOC 2 Type II. Health systems and payers increasingly specify HITRUST, and some make it a contractual precondition. Ask your three biggest prospects what their security team demands before you spend a year on the wrong one.
03Is a wellness app covered by HIPAA?
Often not, and that surprises founders in an unpleasant direction. HIPAA reaches covered entities and their business associates. A direct-to-consumer app may sit entirely outside it, and still face a state health privacy law, some of which carry a private right of action. Falling outside HIPAA is not the same as being unregulated.
04What does a business associate agreement actually cover?
It obliges the business associate to safeguard PHI, limits how the data may be used, requires breach reporting to the covered entity, and requires agreements to flow down to subcontractors. It does not make software compliant, it does not transfer liability, and it does not remove the covered entity's own obligation to run a risk analysis.
05Are encryption and multi-factor sign-in mandatory yet?
Not as of August 2026, though building as if they are is the cheaper bet. A rule proposed in January 2025 would drop the addressable category and require both outright. It remains a proposal. Any vendor presenting those as today's requirements has not checked, which tells you something about the rest of their advice.
Go deeper
- How do you build HIPAA-compliant AI? →Where PHI enters an AI pipeline and what must be true at each point.
- What a BAA does not cover →A signed agreement is a promise, not a control.
- PHI (protected health information) →Health data plus anything that points at a person.
- Healthcare compliance in practice →The regulation map, the buyers, and the security review.
