> Disclaimer: This content is for educational and reference purposes for software builders only. It does not constitute medical, legal, financial, or regulatory advice. Consult a qualified professional before making decisions based on this content.
What encryption algorithm should I use to protect ePHI at rest?
AES-256 in GCM mode is the industry-standard choice for encrypting ePHI at rest. AES-256 satisfies the HIPAA addressable specification for data-at-rest encryption (45 CFR § 164.312(a)(2)(iv)) and is universally regarded as reasonable and appropriate. GCM mode adds authenticated encryption, providing both confidentiality and integrity in a single operation. Manage keys separately from the encrypted data using a Hardware Security Module (HSM) or a cloud KMS service whose provider has signed a BAA.
What TLS version is required for ePHI in transit?
TLS 1.2 is the current minimum for transmitting ePHI (45 CFR § 164.312(e)(2)(ii)). TLS 1.3 is strongly recommended as the default. SSLv3, TLS 1.0, and TLS 1.1 are deprecated and must be disabled in all servers, reverse proxies, and client libraries. Configure your TLS termination point to reject any handshake below TLS 1.2, and test with an automated scanner (e.g. testssl.sh) after each deployment.
Does every third-party vendor I integrate need a BAA?
Yes - any vendor that will create, receive, maintain, or transmit PHI on your behalf is a business associate and requires a signed BAA before PHI is shared. (45 CFR § 164.504(e)) This includes cloud storage providers (AWS, Azure, GCP), email/notification platforms, analytics tools, logging aggregators, and even container orchestration platforms if they will store PHI. Verify each vendor offers a BAA (many provide templates) and maintain a BAA register. Vendors that explicitly state they do not offer BAAs cannot be used to process PHI.
How should I implement audit logging for ePHI access?
Implement audit logs that capture at minimum: user identifier (not group or role), timestamp (UTC, millisecond precision), resource accessed (record type + primary key), action performed (read/write/delete/export), outcome (success/failure), and source IP address. (45 CFR § 164.312(b)) Logs must be written to a tamper-evident, append-only destination (separate from the application database). Retain audit logs for at least six years (aligned with HIPAA's documentation retention period). Implement real-time alerting for anomalous patterns such as bulk exports, after-hours access, or access from unusual geographic locations.
What does "minimum necessary" mean for a software builder?
The minimum-necessary principle (45 CFR § 164.514(d)) means your system should never provide more PHI than is needed for the specific task a user is performing. Implement this through: (1) fine-grained RBAC that restricts each role to the PHI fields required for that function; (2) query-level filtering that returns only relevant records; (3) UI components that mask or omit sensitive fields not needed for the current workflow; and (4) API endpoints that accept user_id+role context and return only the authorised subset. Avoid returning all patient fields in API responses "for convenience."
Is a cloud provider's default storage encryption enough to satisfy HIPAA?
Default cloud-provider server-side encryption (SSE) satisfies the at-rest requirement only if you have a signed BAA with the provider and the encryption key management meets your risk assessment. However, "default" SSE often uses provider-managed keys, which means the provider could technically access your data. For higher-sensitivity PHI, use customer-managed keys (CMEK) or envelope encryption where you control the root key in your HSM/KMS. Always document your key management decision in your risk analysis.
How do I handle the right-to-access (patient records request) in my application?
HIPAA requires covered entities to provide individuals with access to their PHI in a designated record set within 30 days of request (extendable once by 30 days with notice). (45 CFR § 164.524) Build a records-export workflow that: authenticates the requester's identity; queries all data stores for records matching the individual; packages the response in a portable format (PDF or CCDA); delivers it through a secure authenticated channel; and logs the request and fulfilment in your audit trail.
What are the required components of a HIPAA risk analysis?
A required administrative safeguard (45 CFR § 164.308(a)(1)(ii)(A)), a risk analysis must: (1) identify the scope of all ePHI in your environment (databases, backups, dev/test clones, logs, mobile devices); (2) identify all threats and vulnerabilities to each ePHI store; (3) assess the current security controls; (4) determine the likelihood and potential impact of each risk; (5) assign a risk level; and (6) document all findings. OCR has published a Security Risk Assessment (SRA) Tool that guides this process. Risk analysis must be performed initially and repeated when significant environmental changes occur (new system, new vendor, major code changes).
How long must I retain ePHI and audit logs?
HIPAA's retention rules apply to the documentation of your HIPAA compliance policies and procedures - these must be retained for six years from creation date or last effective date (45 CFR § 164.316(b)(2)). Medical record retention is governed by state law, typically 5–10 years for adult records, longer for minors. Audit log retention: at minimum six years, but longer if required by state law or your organisation's retention policy. Align your database and object-storage lifecycle policies with these periods.
What is a Business Associate and how does my SaaS platform qualify?
Any entity that performs functions or activities involving PHI on behalf of a covered entity is a business associate. If your SaaS platform stores, processes, routes, or analyses PHI on behalf of a healthcare provider, payer, or clearinghouse, your platform is a business associate. This triggers the full HIPAA Security Rule compliance obligation for your systems plus a BAA requirement with each covered entity client. You must also execute BAAs with your own subcontractors (hosting, logging, monitoring) that will touch PHI.
How should I implement automatic logoff for HIPAA compliance?
Automatic logoff is an addressable specification (45 CFR § 164.312(a)(2)(iii)) that terminates an electronic session after a predetermined period of inactivity. Implement: (1) a configurable inactivity timeout (common defaults: 5–15 minutes for clinical workstations, 30 minutes for administrative applications); (2) a client-side idle timer that refreshes on user interaction; (3) server-side session expiry that invalidates tokens after the timeout regardless of client state; and (4) a clear user notification before logoff with an option to extend the session.
What is de-identification and when can I use de-identified data?
De-identification removes PHI so that the resulting data is no longer subject to HIPAA. HIPAA provides two safe harbours (45 CFR § 164.514(b)–(c)): (1) Expert Determination - a qualified statistician certifies that the re-identification risk is very small; (2) Safe Harbor - remove all 18 specified identifiers (name, address, dates more granular than year, SSN, medical record numbers, etc.). De-identified data can be used for analytics, model training, and research without HIPAA constraints. Note: "de-identified" data can sometimes be re-identified with auxiliary data - evaluate re-identification risk before release.
How do I securely handle PHI in application logs?
Application logs (error logs, request/response logs, debug logs) frequently contain PHI inadvertently. Controls: (1) configure log formatters to mask or redact known PHI fields (patient IDs, SSNs, dates of birth) before writing; (2) use structured logging and define a PHI-exclusion schema for log fields; (3) store logs in a separate, access-controlled SIEM with its own audit trail; (4) never log request/response bodies containing PHI in plaintext; (5) include log sanitisation as part of your pre-release security checklist.
What security incident response process does HIPAA require?
Covered entities and business associates must implement procedures to identify, respond to, mitigate, and document security incidents (45 CFR § 164.308(a)(6)). Build an incident response pipeline: detection (SIEM alert, anomaly detection); triage (severity classification); containment (revoke tokens, isolate systems); eradication (patch, rotate credentials); recovery (restore service, verify integrity); documentation (incident timeline, affected records, actions taken). HIPAA breach notifications are required within 60 days of discovering a breach affecting 500+ individuals.
Do I need HIPAA compliance for a mobile health app?
It depends on whether your app handles PHI and whether a covered entity or business associate is involved. Consumer health apps used solely by individuals to manage their own health data are generally not covered entities. However, if your app connects to a healthcare provider system, receives PHI from a covered entity, or is used by a covered entity as part of care delivery, HIPAA applies. Review the HHS guidance on mobile apps in health care (HHS.gov) and consult legal counsel for your specific use case.
What is the difference between the Privacy Rule and the Security Rule?
The HIPAA Privacy Rule (45 CFR Parts 160 and 164 Subparts A and E) governs the use and disclosure of PHI in all forms - paper, oral, and electronic. It establishes patient rights (access, amendment, accounting of disclosures). The Security Rule (45 CFR Parts 160 and 164 Subparts A and C) governs exclusively ePHI and mandates administrative, physical, and technical safeguards to ensure confidentiality, integrity, and availability. Software builders primarily implement Security Rule controls.