What 'HIPAA-Compliant Software' Actually Means: A Technical Checklist

"HIPAA-compliant software" is one of the most overused and least-defined phrases in healthcare technology marketing. HIPAA itself doesn't certify software — there is no official government seal a vendor can obtain. What actually exists is a set of required administrative, physical, and technical safeguards under the HIPAA Security Rule, and a covered entity or business associate has to demonstrate that its systems and processes meet them. This is a practical checklist for evaluating whether a vendor's architecture genuinely supports HIPAA compliance, rather than just claiming it.

The technical safeguards that matter for software architecture

• Encryption in transit and at rest. TLS 1.2+ for all data in transit, and encryption (typically AES-256) for data at rest in databases, backups, and object storage. Ask specifically how encryption keys are managed — a vendor who can't answer this clearly is a red flag.
• Access controls and unique user identification. Every user needs a unique login (no shared credentials), role-based access control scoped to the minimum necessary data, and session timeout policies.
• Audit logging. Every access to, modification of, or export of protected health information (PHI) needs to be logged with who, what, and when — and those logs need to be tamper-resistant and retained per your policy (commonly 6+ years).
• Automatic logoff. Sessions accessing PHI should time out after a defined period of inactivity.
• Data integrity controls. Mechanisms to ensure PHI isn't improperly altered or destroyed, including backup and disaster recovery procedures.

The business/contractual side

• A signed Business Associate Agreement (BAA). If a vendor touches, stores, or processes PHI on your behalf, you need a BAA in place before any PHI flows through their system — this is a legal requirement, not optional paperwork. If a cloud provider (AWS, Azure, GCP) is in the stack, confirm they offer a BAA for the specific services being used (not all services from every provider are covered).
• Data residency and subcontractor disclosure. Where is data physically stored, and does the vendor use any subcontractors (e.g., a third-party analytics or email tool) that would also need to be HIPAA-compliant and covered under a BAA?
• Breach notification procedures. The vendor should have a documented process for detecting and reporting breaches within HIPAA's required timelines.

What to ask a software vendor directly

1. "Walk me through how PHI is encrypted at rest in your architecture, and who holds the keys."
2. "Can you provide a BAA, and does it cover every subprocessor that will touch our data?"
3. "Show me an example of an audit log entry for a PHI access event."
4. "What's your data retention and secure deletion policy?"
5. "Have you had a third-party security assessment (e.g., SOC 2, HITRUST) performed, and can we see a summary report?"

A note on GDPR overlap

If you also serve patients or handle data originating in the EU/UK, GDPR applies in parallel to HIPAA and imposes additional requirements — including a lawful basis for processing, data subject rights (access, erasure, portability), and generally stricter breach-notification timelines (72 hours under GDPR vs. HIPAA's "without unreasonable delay, and no later than 60 days"). A system built only to a HIPAA bar is not automatically GDPR-compliant, and vice versa — treat these as two separate compliance checklists that happen to share a lot of good security hygiene in common.

The bottom line

"HIPAA-compliant" is a description of a system of safeguards and legal agreements, not a checkbox a vendor ticks. Any vendor that can't speak specifically to encryption key management, audit logging implementation, and BAA coverage for every subprocessor in their stack hasn't actually built for HIPAA — they've just used the phrase in their marketing copy.