HIPAA does not certify software. There is no badge, no approved list, and no vendor can sell you a product that is HIPAA compliant on its own. Compliance is a property of how an organisation operates, and software is one part of that. What software can do is make compliance possible or make it impossible.
That distinction matters because it changes the question. Not “is this tool HIPAA compliant” but “can we operate compliantly while using it”. Four technical decisions determine the answer, and three of them are expensive to reverse.
Where the data is allowed to live
This is the decision that cannot be undone cheaply.
Protected health information can only be stored on infrastructure covered by a business associate agreement — a contract in which the hosting provider accepts responsibility for safeguarding that data. AWS, Azure, Google Cloud and Supabase all offer one. Shared hosting providers of the kind that run most small business websites generally do not.
The practical consequence: if a case management platform is built on the same hosting as the marketing site, moving it later means migrating the database, the application, the storage layer, and every integration pointing at them. We treat hosting as the first architectural decision on any project touching PHI, before a single feature is designed.
A second rule follows from it. Any third-party service that sees the data needs its own agreement — email delivery, file storage, error monitoring, analytics. Error monitoring is the one teams forget, because stack traces frequently contain the record that caused the error.
Access control has to be about records, not screens
Most software implements roles as visibility of pages. HIPAA’s minimum necessary standard is stricter: a person should only reach the specific records their job requires, not every record on a screen they are allowed to open.
In case management that usually means a caseworker sees their assigned cases, a supervisor sees their team’s cases, and a biller sees the billing fields of cases they are invoicing but not the clinical notes. That is a data-layer constraint. If authorisation is enforced only in the interface, the API underneath will happily return everything to anyone who asks it directly.
Retrofitting record-level authorisation onto a system that assumed page-level roles is one of the more expensive corrections available, because it touches every query.
Audit logging is the part auditors actually read
The requirement is to record who accessed which record and when, and to keep it long enough to be useful — six years is the retention period for HIPAA documentation.
What makes audit logs useful in practice is being specific. “User viewed clients page” is not an audit trail. “User 41 opened record 8823 at 14:06” is. Logs also need to be append-only from the application’s perspective: if the same account that reads records can quietly edit the log of having read them, the log proves nothing.
This is worth building early, and it is not difficult early. It is tedious later, because you have to find every path that touches a record.
Encryption, which is the easy one
In transit: TLS everywhere, no exceptions for internal services. At rest: database encryption, which every managed provider offers as a setting. Backups encrypted with the same standard as the primary store, because a backup is a complete copy of everything you were protecting.
This is the requirement teams worry about most and get wrong least, because the defaults on managed infrastructure are already correct. The failures we see are not weak ciphers — they are an unencrypted backup on someone’s laptop, or a database export emailed for convenience.
What this costs in practice
Building these in from the start adds perhaps ten to fifteen percent to the initial engineering effort of a case management platform. Retrofitting them typically means rebuilding the data access layer, which is a substantial fraction of the original build.
The asymmetry is the entire argument for deciding early. None of the four decisions above is technically difficult. Three of them are structural, and structure is what you cannot change later without rewriting the parts that depend on it.
The question worth asking a vendor
If you are evaluating software rather than building it, the useful question is not whether the product is HIPAA compliant. Ask:
- Will you sign a business associate agreement?
- Where is our data physically stored, and by whom?
- Can access be restricted to specific records rather than specific screens?
- Can we export the audit log, and what exactly does each entry contain?
- What happens to our data when we leave?
A vendor who answers those precisely has thought about it. A vendor who answers “yes, we’re fully HIPAA compliant” and moves on has not.
Techveus builds case management and behavioural health platforms for organisations serving children and families. If you are scoping one, tell us what you are trying to build and we will tell you honestly what it involves.