HIPAA Compliant Software Development

The HIPAA Security Rule at 45 CFR 164.312(a)(2)(iv) and 164.312(e)(2)(ii) specifies encryption and decryption as addressable implementation specifications -- in practice, this means encryption is required unless you document a specific alternative control with equivalent protection, which in software development means encryption is always implemented. AES-256 encryption at rest covers all PHI stored in databases (RDS PostgreSQL with storage encryption enabled), object storage (S3 with SSE-KMS), file uploads (S3 presigned URLs with server-side encryption), and automated backups. Encryption keys are managed through AWS KMS with key rotation enabled and key access restricted by IAM policy to only the services that require it.

TLS 1.3 is enforced for all PHI in transit with TLS 1.2 as the minimum acceptable version -- older protocol versions are disabled at the load balancer and API gateway level. No plaintext PHI transmission is permitted over any channel: API responses, webhook payloads, message queue messages, and internal service calls all use TLS. Application-level encryption is applied to particularly sensitive data categories that warrant a second layer of protection beyond database encryption: 42 CFR Part 2 substance use disorder treatment records, psychiatric records, and genetic information each carry elevated legal protection and are encrypted at the field level so a database credential compromise does not expose these categories.

The HIPAA Privacy Rule at 45 CFR Part 164 defines the 18 PHI identifiers (names, geographic subdivisions smaller than state, dates other than year, phone numbers, fax numbers, email addresses, SSNs, MRNs, health plan beneficiary numbers, account numbers, certificate/license numbers, vehicle identifiers, device identifiers, web URLs, IP addresses, biometric identifiers, full-face photos, and any other unique identifying number) -- all 18 are treated as PHI in the data classification model and encrypted accordingly.

The HIPAA Security Rule at 45 CFR 164.312(a)(1) requires access controls with four implementation specifications: unique user identification (required), emergency access procedure (required), automatic logoff (addressable), and encryption/decryption (addressable). In practice, all four are implemented as baseline requirements. Role-based access control (RBAC) applies the minimum necessary standard -- a nurse accessing patient vitals should not see psychiatric notes, a billing user should not see clinical documentation. Access is granted to the minimum PHI categories required to perform the job function.

RBAC roles are defined during the discovery phase based on your actual user types and their PHI access requirements. Amazon Cognito handles user authentication with MFA enforcement for all roles accessing PHI. Cognito User Pools support TOTP (Time-based One-Time Password) authenticator apps and SMS OTP as second factors. Fine-grained IAM policies restrict which AWS resources each application role can access, enforcing least privilege at the infrastructure level, not just the application level.

Automatic session logoff is configured at 15 minutes of inactivity for clinical workstations and 30 minutes for administrative users -- the HIPAA addressable specification requires the timeout to be implemented "when appropriate," and these thresholds are the standard clinical implementation. Session tokens are invalidated server-side on logout; client-side token deletion is not sufficient because tokens can be extracted from browser storage. Emergency access procedures ("break the glass") allow designated users to access PHI outside normal role boundaries in a genuine clinical emergency, with the access event automatically flagged in the audit log for review. Access control lists are reviewed quarterly -- access provisioned at onboarding should not persist indefinitely if the user's role changes or they leave.

The HIPAA Security Rule at 45 CFR 164.312(b) requires audit controls: hardware, software, and procedural mechanisms to record and examine activity in systems that contain PHI. Every PHI access event is captured: user ID, timestamp (UTC), patient record accessed, specific data fields accessed, action taken (view, create, modify, delete, export, print), source IP address, and user agent. The audit log is the evidence that your system satisfies the audit controls requirement -- if you cannot demonstrate what each user accessed and when, you cannot demonstrate HIPAA compliance.

Application-level audit logs are written to an append-only log store. AWS CloudWatch Logs is the primary collection point, with CloudTrail providing the infrastructure-level audit trail for all AWS API calls. Log retention is configured for a minimum of 6 years to satisfy the HIPAA requirement that documentation of HIPAA compliance be retained for 6 years from creation or last effective date. Logs are stored in S3 with Object Lock (WORM) to prevent deletion or modification by application users, including infrastructure administrators.

Automated alerts via CloudWatch Alarms and GuardDuty detect anomalous access patterns: bulk PHI record downloads above a configurable threshold, after-hours access from a role that has never accessed the system outside business hours, access from a geographic location inconsistent with the user's normal access pattern, and failed authentication attempts against PHI-accessible accounts. GuardDuty's machine learning-based anomaly detection identifies threats that rule-based alerting misses. Security incident response documentation is built during the project -- the procedures your team follows when an alert fires, aligned with the HIPAA Breach Notification Rule 60-day notification requirement at 45 CFR 164.400.

The HIPAA Privacy Rule at 45 CFR 164.502(e) and 164.504(e) requires a Business Associate Agreement (BAA) with every vendor that creates, receives, maintains, or transmits PHI on your behalf. Without a BAA, using a vendor that touches PHI is a HIPAA violation regardless of the vendor's security posture. BAA coverage is therefore a prerequisite, not an optional enhancement, for every infrastructure component in a HIPAA-regulated system.

AWS HIPAA Eligible Services covered under the AWS BAA include: EC2, RDS (PostgreSQL, Aurora, MySQL), S3, Lambda, API Gateway, ECS, EKS, Cognito, CloudWatch, CloudTrail, SNS, SQS, Secrets Manager, KMS, and Elastic Load Balancing. These are the services used to build the application compute, data storage, and authentication layers. AWS services not on the HIPAA Eligible list (some analytics and ML services) may not be used with PHI without an alternative control.

Google Cloud Platform provides the Google Cloud Healthcare API (FHIR R4 store) and a range of HIPAA-covered GCP services under the Google Cloud BAA. GCP HIPAA-covered services include Compute Engine, Cloud SQL, Cloud Storage, Cloud Functions, and Cloud Logging. For products targeting Epic or Cerner integrations where the health system uses Google Cloud for FHIR data exchange, GCP Healthcare API is the natural integration substrate.

Third-party integrations are evaluated for BAA availability before they are included in the architecture. EHR API providers, telehealth video platforms (Daily.co, Twilio with BAA), communication providers (Twilio SendGrid with BAA for transactional email, Twilio SMS for appointment reminders), and analytics platforms are each assessed before inclusion. If a provider cannot sign a BAA, PHI does not flow through it -- the architecture routes around it using a PHI-free abstraction layer where needed.

The HIPAA minimum necessary standard at 45 CFR 164.502(b) requires covered entities and business associates to make reasonable efforts to limit PHI use, disclosure, and requests to the minimum necessary to accomplish the intended purpose. In software terms, this means the data model does not collect PHI the application does not need, API responses do not return PHI fields the calling function does not use, and role-based access returns only the PHI the user's role requires -- not the full patient record.

PHI de-identification following HIPAA Safe Harbor at 45 CFR 164.514(b) removes all 18 PHI identifiers, producing a de-identified dataset that is no longer PHI under HIPAA and can be used for analytics, reporting, and ML model training without BAA requirements on the downstream system. Expert Determination de-identification at 45 CFR 164.514(b)(1) -- a qualified statistician certifies the risk of re-identification is very small -- is used for datasets where Safe Harbor removal would render the data analytically useless (geographic data reduced below county level, date data reduced to year only).

Secure PHI deletion workflows cascade through all storage locations: primary database, read replicas, backups, archived logs, and any derived datasets or analytics tables. PHI is not considered deleted until it is confirmed deleted from all locations. Data retention schedules are configured per PHI category based on applicable state medical records laws (retention periods vary from 5 years to 10 years depending on state and patient age at treatment). Data residency configuration restricts PHI to specific AWS regions for organisations with contractual requirements to keep patient data within a specific country or state. PHI inventory mapping -- a living document of what PHI is stored, where, and for what purpose -- is maintained as part of the HIPAA Security Rule risk management programme, following NIST SP 800-66 implementation guidance.

HIPAA compliance requires both technical safeguards and the documentation to demonstrate they are in place. The HIPAA Security Rule at 45 CFR 164.316 requires covered entities to document their security policies and procedures and retain that documentation for 6 years. We provide the technical documentation your compliance team needs to complete that programme -- we do not write your policies (that is your legal and compliance team's domain) but we give them the technical evidence they need to write them accurately.

Documentation delivered as part of every HIPAA software project: technical architecture diagrams showing all system components and their BAA status, data flow diagrams per NIST SP 800-66 mapping every PHI flow through the system from collection through deletion, access control specifications listing every role and the PHI categories each can access, encryption implementation documentation covering which algorithm, key length, and key management approach is used for each PHI store, and audit logging specifications documenting the events captured and the retention configuration.

HITRUST CSF certification is the most widely recognised third-party validation for health tech companies selling to health systems, payers, and large enterprise healthcare organisations. The HITRUST r2 assessment covers 325+ controls across 19 control categories. We design technical controls to map to HITRUST CSF requirements from the start, reducing the gap between the built system and the assessor's requirements when the certification process begins. The HITRUST pathway is significantly less expensive when the system was built for it than when it is retrofitted.

Penetration testing per the OWASP Healthcare Security Testing Guide is conducted before production launch. The test scope covers FHIR API security (injection, broken object level authorisation, excessive data exposure), authentication bypass testing, session token entropy and fixation, PHI leakage in API error responses, and network-level testing of the VPC configuration. Findings are remediated and retested before go-live. The penetration test report supports your security risk assessment documentation.