HIPAA and healthcare software: what the rule actually requires
No software is "HIPAA compliant" on its own, and no development agency can sell you compliance as a feature. HIPAA regulates covered entities and their business associates — organisations, not code. What software can do is implement the safeguards the Security Rule describes, and be documented well enough that your compliance officer can evidence them. That distinction matters, and vendors who blur it should worry you.
Where we stand, stated plainly
Vixit AI Studios holds no HIPAA certification, and there is no such thing as a HIPAA certification for software in the first place — there is no government body that issues one. Third-party attestations exist, and they are audits of an organisation's controls, not a stamp on a codebase.
What we do is build to the safeguards the Security Rule sets out, and document them so your compliance officer has something to work with rather than a marketing claim to unpick. If you are a US covered entity, you will also need a Business Associate Agreement with any vendor who touches protected health information, including your hosting provider. That is a legal instrument, not an engineering one.
Any agency that answers "are you HIPAA compliant?" with an unqualified yes, and cannot produce an audit report, has just told you something useful.
The technical safeguards, in engineering terms
The Security Rule is written in legal language and maps onto a fairly short list of engineering decisions.
| Safeguard | What it means in the codebase |
|---|---|
| Access control | Unique user identity per person — never a shared clinic login. Role-based permissions decided before the first admin screen, not retrofitted around it. |
| Audit controls | An append-only record of who viewed or changed which record, and when. Log reads, not just writes — improper access is the common failure. |
| Integrity | Records that cannot be silently overwritten. Amendments create a new version with a reason; the prior value survives. |
| Transmission security | TLS everywhere, including between internal services if they cross a network boundary. |
| Encryption at rest | Database and file storage encrypted, medical imaging included. Keys managed outside the application. |
| Automatic logoff | Sessions that expire, and a way to revoke a session immediately when someone leaves. |
Minimum necessary is an architecture decision
The rule expects a user to see only the information their role requires. This is easy to say and awkward to retrofit, because the natural way to build a clinical screen is to fetch the whole patient record and render part of it — which means the full record crossed the network and sat in a browser regardless of what was displayed.
Doing it properly means the server decides what to send based on role, and the client never receives what it must not show. That is a decision made when the API is designed. Afterwards it is a rewrite of every endpoint.
Multi-tenancy, where the worst breaches come from
If your platform serves more than one clinic, the tenancy boundary is the single highest-consequence decision in the system. Row-level tenant identifiers are quick to build and one missing filter away from clinic A reading clinic B's patients — and that is a reportable breach, not a bug.
Separate schemas or databases cost more to operate and make the leak structurally difficult rather than merely unlikely. We will push toward isolation and tell you what it costs to run, because this is the decision you cannot cheaply reverse once real patient data exists.
What we can and cannot do for you
We can build the safeguards, write the documentation that evidences them, host in a region you specify, and sign a BAA where appropriate. We can also tell you honestly which parts of your compliance posture are organisational rather than technical — training, policies, incident response — because those are the parts that software cannot fix and auditors always ask about.
We cannot certify you, and neither can anyone selling you a "HIPAA compliant" template.
Frequently asked
Is your software HIPAA compliant?
No software is HIPAA compliant on its own — HIPAA regulates organisations, not code, and there is no government-issued certification for software. We build to the safeguards the Security Rule describes: unique user identity, role-based access, append-only audit trails, encryption in transit and at rest, session expiry and revocation. We hold no attestation and say so.
What does HIPAA actually require of software?
Access control with unique per-person identity, audit controls recording who viewed or changed each record, integrity protection so records cannot be silently overwritten, transmission security, encryption at rest, and automatic logoff. The rule also expects minimum necessary access, which is an API design decision rather than a UI one.
Do we need a Business Associate Agreement?
If you are a US covered entity and a vendor handles protected health information on your behalf, yes — including your hosting provider. A BAA is a legal instrument, not an engineering deliverable, and it should be in place before any real patient data reaches the system.
How should multi-tenant healthcare software isolate clinics?
Decide the boundary before the first screen is built. Row-level tenant identifiers are quick and one missing filter away from cross-clinic exposure, which is a reportable breach rather than a bug. Separate schemas or databases cost more to run and make the leak structurally difficult. It is not cheaply reversible once real data exists.
Can an agency make us HIPAA compliant?
No. An agency can build the technical safeguards and document them so your compliance officer can evidence them, and can sign a BAA. Compliance itself also covers training, policies, risk assessment and incident response — organisational work that software cannot substitute for.
Related
Want this built?
Tell us what you are trying to ship and we will tell you honestly whether we are the right team for it.