HIPAA Engineering Patterns

HIPAA for healthcare. Patterns and gotchas.

BAA

HIPAA compliance is one of those engineering challenges that sounds tractable until you start doing it. The Health Insurance Portability and Accountability Act has specific technical and administrative requirements that apply to any organization handling Protected Health Information (PHI). Engineering teams entering the healthcare space need to understand the specifics; assuming "we have SOC 2, we are fine" is a path to compliance failure.

What BAAs actually require:

• Business Associate Agreements with vendors.: Any vendor that handles PHI on your behalf must sign a BAA. The BAA specifies how the vendor will protect PHI, how they will report breaches, and what happens if they fail. Without a signed BAA, sharing PHI with the vendor is a HIPAA violation.
• Required before processing PHI.: The BAA is signed before any PHI flows to the vendor. The signing is part of the vendor onboarding; without it, the vendor cannot be used. Retrospectively obtaining BAAs after data has flowed is messy and may not satisfy investigators.
• BAA from your customers too, if they are covered entities.: If your service handles PHI on behalf of a healthcare provider or insurer (a "covered entity" under HIPAA), you sign a BAA with them. The BAA flows in both directions; you have BAAs with your vendors and from your customers.
• Subcontractor flow-down.: Your vendors' subcontractors that touch PHI also need BAAs. The flow-down obligation extends through the supply chain. Each layer signs the BAA equivalent with the layer below; the chain extends from the original covered entity to wherever PHI eventually reaches.
• Termination terms.: The BAA specifies what happens at the end of the relationship: PHI is returned or destroyed, the vendor certifies the action, the audit trail is preserved. The exit terms matter as much as the entry terms; HIPAA-compliant relationships have to end as well as begin compliantly.

BAAs are the legal foundation. They do not substitute for technical controls; they specify the contract that supports the controls.

Encryption

HIPAA's technical controls require encryption of PHI at rest and in transit. The exact requirements are mostly aligned with modern security best practices, but the specifics matter for compliance. Skipping any of them is a finding.

• Encryption at rest.: All storage of PHI must be encrypted. Database storage, backup snapshots, log archives, file shares, anything that holds PHI. The encryption uses AES-256 or equivalent strength. Most modern storage platforms support this natively; the discipline is making sure it is enabled.
• Encryption in transit.: All network transfer of PHI must use TLS 1.2 or higher. This includes internal service-to-service traffic, not just public-facing endpoints. The combination of TLS-everywhere and HIPAA's encryption-in-transit requirement is the same control; one satisfies both.
• AES-256 specifically.: HIPAA does not technically require AES-256 specifically, but it is the de facto standard. Older algorithms (DES, 3DES) are not acceptable. Newer algorithms (ChaCha20-Poly1305, AES-GCM) are also acceptable. The key length matters; AES-128 is below the practical bar even though theoretically allowed.
• Key management.: Encryption keys must be managed in a way that ensures only authorized parties can decrypt PHI. Customer-managed keys in cloud KMS, HSM-backed keys, or properly-protected key vaults. The key management is part of the audit; auditors verify the keys are not in plaintext somewhere.
• Encryption of devices.: Workstations and mobile devices that may hold PHI also need encryption. Laptop full-disk encryption, mobile device management with encryption enforcement. The endpoint encryption extends the scope beyond servers to user devices.

HIPAA encryption requirements align with modern security best practice. Teams that have implemented best practice are mostly compliant; teams that have not are exposed.

Access

The access control requirements under HIPAA are stricter than typical SaaS practices. The standard is "minimum necessary access," which means each user and each system has access only to the PHI they specifically need to perform their function. Granting broader access by default violates the standard.

• Minimum necessary access.: Each user is authorized for specific PHI based on their role. A clinician handling a specific patient has access to that patient; they do not have access to other patients in the same facility unless their role requires it. The principle of least privilege is enforced precisely.
• Audit log every access.: Every read or modification of PHI is logged. Who, when, which patient's data, which fields. The log is preserved for 6 years (HIPAA's standard retention requirement). The log is queryable; auditors and investigators can reconstruct access patterns over the retention window.
• Standard SOC 2 controls plus stricter access reviews.: SOC 2's quarterly access review becomes monthly under HIPAA-strict practice. The review specifically verifies minimum-necessary continues to apply. Roles get scoped tightly; broad-access roles are reviewed for whether the breadth is still justified.
• Authentication requirements.: Strong authentication for all access to PHI. MFA for all users with PHI access; session timeouts shorter than typical SaaS; password complexity requirements. The authentication layer is hardened relative to non-PHI systems.
• Patient-level access controls.: Some systems enforce access at the individual record level, not just at the dataset level. A user accessing patient X's data does not implicitly get access to patient Y's data. The granular control is more work but matches the regulatory expectation.

HIPAA engineering is a real category of operational work that goes beyond generic security best practice. Nova AI Ops integrates with HIPAA-compliant logging, audit trails, and access controls, surfaces the cases where the access pattern suggests minimum-necessary may not be satisfied, and produces the audit artifacts HIPAA-compliant operations require.