Building healthcare software that handles protected health information (PHI) is not a matter of adding encryption and calling it compliant. HIPAA is a comprehensive regulatory framework with specific technical, administrative, and physical safeguard requirements that affect every layer of your application, from infrastructure architecture to user interface design to operational procedures. The penalties for non-compliance are severe: fines range from $100 to $50,000 per violation (per affected record), with a maximum of $1.5 million per violation category per year. A single data breach affecting 10,000 patients can trigger investigations, mandatory corrective action plans, and fines that bankrupt a startup.
This guide covers the technical requirements for building HIPAA-compliant software, with specific implementation guidance for each major safeguard category.
Understanding What HIPAA Actually Requires
HIPAA’s technical requirements come primarily from two rules: the Privacy Rule (who can access PHI and under what conditions) and the Security Rule (how to protect electronic PHI). The Security Rule specifies three categories of safeguards.
Administrative safeguards include risk analysis, workforce training, access management policies, contingency planning, and business associate management. These are organizational requirements, not purely technical ones, but your software must support them. For example, your software must support the access management policies by implementing role-based access control. Your audit logging must support the risk analysis requirement by providing evidence of who accessed what data and when.
Physical safeguards address the physical protection of systems that store or process PHI: facility access controls, workstation use policies, and device and media controls. For cloud-hosted applications, your cloud provider handles most physical safeguards (AWS, Azure, and GCP are all HIPAA-eligible), but you need their Business Associate Agreement (BAA) on file and you must configure their services according to HIPAA requirements.
Technical safeguards are where software development decisions matter most. The Security Rule specifies requirements in four areas:
- Access control: Unique user identification, emergency access procedures, automatic logoff, encryption and decryption.
- Audit controls: Mechanisms to record and examine access to electronic PHI.
- Integrity controls: Protection against improper alteration or destruction of PHI.
- Transmission security: Protection of PHI transmitted over electronic networks.
The Security Rule distinguishes between “required” and “addressable” implementation specifications. Required specifications must be implemented. Addressable specifications must be assessed — if the specification is reasonable and appropriate for your environment, you must implement it. If not, you must document why and implement an equivalent alternative measure. “Addressable” does not mean “optional.”
Encryption and Data Protection Architecture
Encryption is the most discussed HIPAA technical requirement and the one most frequently implemented incorrectly.
Data at rest: Encrypt all PHI stored in databases, file systems, backups, and caches using AES-256. Use your cloud provider’s encryption services (AWS KMS, Azure Key Vault, GCP Cloud KMS) to manage encryption keys. Configure database-level encryption (RDS encryption, Azure SQL TDE, or Cloud SQL encryption) as a baseline. For highly sensitive fields (Social Security numbers, diagnosis codes, genetic information), implement field-level encryption within the application so that database administrators and infrastructure operators cannot read PHI even with database access.
Key management is where most encryption implementations fall short. Do not store encryption keys alongside the encrypted data. Use a dedicated key management service with access controls separate from your application’s database access. Implement key rotation on a defined schedule (annually at minimum) without requiring data re-encryption. Envelope encryption (encrypting data with a data encryption key, then encrypting the data key with a master key) enables key rotation at the master key level without touching every encrypted record.
Data in transit: Enforce TLS 1.2 or higher for all network communications. This includes client-to-server, server-to-server, and server-to-database connections. Disable older TLS versions and weak cipher suites. Implement HTTP Strict Transport Security (HSTS) headers to prevent protocol downgrade attacks. For internal service-to-service communication, use mutual TLS (mTLS) to authenticate both endpoints.
Data in use: This is the hardest category. Data must be decrypted in memory to be processed, creating a window of vulnerability. Minimize the window by decrypting PHI only when actively needed, clearing it from memory promptly after use, and never writing decrypted PHI to log files, temporary files, or error reports. Configure your application’s error reporting to redact PHI from stack traces and error messages. A stack trace containing a patient’s diagnosis code in a Sentry report is a HIPAA violation.
Access Control and Authentication
HIPAA requires unique user identification, which means shared accounts are prohibited. Every person who accesses a system containing PHI must have a unique identifier tied to their individual identity.
Multi-factor authentication (MFA) is an addressable specification under the Security Rule, but in practice it is effectively required. OCR (the Office for Civil Rights, which enforces HIPAA) has cited lack of MFA as a contributing factor in numerous enforcement actions. Implement MFA for all user accounts that can access PHI. Hardware security keys (FIDO2/WebAuthn) provide the strongest protection, followed by authenticator app TOTP codes. SMS-based MFA is better than nothing but is vulnerable to SIM swapping attacks.
Automatic session termination is a required specification. Sessions must terminate after a period of inactivity. The specific timeout period is not defined by HIPAA — you must assess what is reasonable for your use case. Clinical workstations in emergency departments might use 15-minute timeouts. Administrative applications might use 30-minute timeouts. The key is to document your chosen timeout period and the rationale behind it.
Emergency access procedures (the “break-glass” requirement) must allow authorized personnel to access PHI in emergencies when normal access controls would prevent it. Implement a mechanism that grants temporary elevated access, requires documentation of the emergency justification, triggers immediate alerts to privacy officers, creates an enhanced audit trail, and automatically revokes the elevated access after a defined period (2-4 hours is typical).
Minimum necessary access is a Privacy Rule principle that requires limiting PHI access to the minimum amount necessary for each user to perform their job function. A billing specialist should see diagnosis codes and procedure codes (needed for billing) but not clinical notes (not needed for billing). Implement this through role-based access control with granular permissions at the data-element level, not just the record level.
See also: HIPAA Patient Portal Development
Audit Logging Requirements
HIPAA requires audit controls that record and examine activity in systems containing PHI. The specific implementation is left to the covered entity, but OCR enforcement actions provide clear guidance on what is expected.
Log every access to PHI. This includes reads, not just writes. When a nurse views a patient’s medication list, log it. When a billing clerk accesses a claim record, log it. When a physician reviews lab results, log it. Each log entry should record the user identity, the timestamp, the action performed (view, create, update, delete, export, print), the patient whose data was accessed, the specific data elements accessed, the source IP address and device identifier, and the outcome (success or failure).
Log access to the audit system itself. Meta-auditing prevents the scenario where someone queries audit logs to identify evidence of their own unauthorized access and then attempts to cover their tracks.
Retain audit logs for six years. HIPAA requires that documentation of security policies and procedures be retained for six years. While audit logs are not explicitly called out with a specific retention period, six years is the standard practice and the expectation in enforcement actions.
Implement proactive monitoring. Do not just log access — monitor for anomalous patterns. Alert on access to records outside a user’s normal scope, access at unusual times, bulk data exports, and access to VIP or employee patient records (which are common targets for inappropriate access). Integrate audit log monitoring with your security information and event management (SIEM) system.
Patient access reporting is a specific requirement: patients have the right to receive an accounting of disclosures of their PHI. Your audit system must be able to generate a report of all disclosures of a specific patient’s PHI over a requested time period, excluding disclosures for treatment, payment, and healthcare operations (which are exempt from the accounting requirement).
Business Associate Agreements and Vendor Management
If any third-party vendor handles PHI on your behalf — cloud hosting, email delivery, analytics, payment processing, customer support tools — you must have a Business Associate Agreement (BAA) in place before sharing any PHI with them.
A BAA is a legal contract that requires the business associate to implement appropriate safeguards to protect PHI, report security incidents and breaches, ensure their own subcontractors comply with HIPAA, and return or destroy PHI at the end of the relationship.
Cloud infrastructure providers (AWS, Azure, GCP) all offer BAAs, but signing the BAA does not automatically make your deployment HIPAA-compliant. You must use HIPAA-eligible services within those platforms (not all services are eligible), configure those services according to HIPAA requirements (encryption enabled, logging configured, access controls set), and implement your own application-level safeguards on top of the infrastructure controls.
Evaluate every SaaS tool in your stack for HIPAA compliance before allowing any PHI to flow through it. Common violations include sending patient names in email subject lines through a non-BAA email provider, logging PHI in an application monitoring tool without a BAA, storing patient communications in a customer support platform without a BAA, and using analytics tools that capture PHI in URLs or form fields.
Create a vendor inventory that lists every service that touches PHI, the BAA status, the date the BAA was executed, and the next review date. Review this inventory quarterly and whenever you add a new tool to your stack.
Breach Response and Notification
Despite your best efforts, breaches can happen. Your response plan must be documented, tested, and executable under pressure.
HIPAA’s Breach Notification Rule requires notification within 60 days of discovering a breach affecting 500 or more individuals. For breaches affecting fewer than 500 individuals, notification to affected individuals is still required within 60 days, but reporting to HHS can be batched annually. Breaches affecting 500+ individuals must also be reported to prominent media outlets serving the affected area.
Your incident response plan should define roles and responsibilities (who leads the response, who communicates with patients, who handles regulatory reporting), forensic investigation procedures (preserve evidence, determine the scope of the breach, identify the root cause), notification procedures and templates, and remediation steps to prevent recurrence.
Run a tabletop exercise at least annually where your team walks through a simulated breach scenario from detection through notification and remediation. These exercises consistently reveal gaps in the response plan that are far better discovered during a drill than during an actual incident.
If you are building healthcare software and need to ensure HIPAA compliance is built into your architecture from day one, contact our team. We have built HIPAA-compliant platforms for healthcare providers, health tech startups, and digital health companies, and we can help you navigate the technical requirements without sacrificing development velocity.