Building software that handles protected health information (PHI) is fundamentally different from building a standard SaaS application. The regulatory requirements are specific, the penalties for non-compliance are severe, and the technical decisions you make in the first sprint will echo through every phase of your product's lifecycle.
At Apptitude, we have built HIPAA-compliant applications across telehealth, patient engagement, and clinical workflow domains. This guide distills what we have learned into a single, comprehensive resource for founders, product managers, and CTOs who need to get HIPAA compliance right the first time.
What HIPAA Actually Requires for Software
HIPAA is not a single rule. It is a set of interconnected regulations, and three of them directly affect how you build software.
The Privacy Rule governs how protected health information can be used and disclosed. For app developers, this means your software must enforce policies about who can see what data, under what circumstances, and with what consent.
The Security Rule is the most technically prescriptive. It establishes administrative, physical, and technical safeguards that any system handling electronic PHI (ePHI) must implement. This is where encryption requirements, access controls, audit logging, and integrity controls live.
The Breach Notification Rule defines what happens when something goes wrong. If unsecured PHI is accessed, used, or disclosed in a way that violates the Privacy Rule, you must notify affected individuals, the Department of Health and Human Services (HHS), and in some cases the media — within 60 days.
PHI and ePHI: What Actually Counts
Protected health information is any individually identifiable health information held or transmitted by a covered entity or its business associates. The key word is "individually identifiable." A dataset of anonymized blood pressure readings is not PHI. A blood pressure reading tied to a patient name, email address, or medical record number is.
The 18 HIPAA identifiers include the obvious (names, Social Security numbers, medical record numbers) and the less obvious (device identifiers, full-face photos, any unique identifying number or code). If your application stores health data alongside any of these identifiers, you are handling PHI.
ePHI is simply PHI in electronic form — which, for app development purposes, means virtually all PHI your application touches.
Covered Entities vs. Business Associates
Covered entities are health plans, healthcare clearinghouses, and healthcare providers who transmit health information electronically. If you are building an app for a hospital or health system, they are the covered entity.
Your company is almost certainly a business associate — a person or organization that performs functions or activities on behalf of a covered entity that involve access to PHI. This distinction matters because it determines your legal obligations and liability.
Since the HITECH Act of 2009, business associates are directly liable for HIPAA compliance. You cannot hide behind your client's compliance program. You are on the hook.
The Business Associate Agreement
A Business Associate Agreement (BAA) is a legal contract between a covered entity and a business associate that establishes the permitted uses and disclosures of PHI. You need one before any PHI touches your systems.
Every cloud provider, SaaS tool, and subcontractor in your stack that could access PHI must have a BAA in place. No BAA, no PHI — it is that simple.
Cloud provider BAAs are well-established but limited in scope. AWS, Google Cloud, and Microsoft Azure all offer BAAs, but they only cover HIPAA-eligible services. AWS, for example, will sign a BAA that covers services like RDS, S3, Lambda, API Gateway, and DynamoDB — but not every AWS service is included. You must consult the provider's list of HIPAA-eligible services and restrict your architecture accordingly.
Here is the misconception that trips up most teams: using a HIPAA-eligible cloud provider does not make your application HIPAA compliant. The cloud provider's BAA covers their responsibility for the infrastructure. Everything you build on top of that infrastructure — your application code, your access controls, your logging, your data handling — is entirely your responsibility. AWS will encrypt your S3 bucket. AWS will not stop your developer from logging a patient's Social Security number to CloudWatch.
Technical Safeguards: The Engineering Checklist
The Security Rule defines technical safeguards as "the technology and the policy and procedures for its use that protect electronic protected health information and control access to it." Here is what that means in practice.
Encryption
In transit: All data containing or potentially containing ePHI must be encrypted using TLS 1.2 or higher. This applies to every network hop — client to server, server to database, service to service. Certificate pinning is recommended for mobile applications.
At rest: Use AES-256 encryption for all stored ePHI. On AWS, this means enabling encryption on RDS instances, S3 buckets, EBS volumes, and DynamoDB tables. Use AWS Key Management Service (KMS) with customer-managed keys (CMKs) rather than default encryption. Customer-managed keys give you explicit control over key rotation, access policies, and audit trails.
Access Controls and Authentication
HIPAA requires unique user identification, emergency access procedures, automatic logoff, and encryption and decryption controls. In practical terms:
- Unique user identification. Every user who accesses ePHI must have a unique identifier. No shared accounts, no generic logins.
- Multi-factor authentication (MFA). Required for any user accessing ePHI. TOTP-based authenticators or hardware security keys are preferred over SMS-based MFA.
- Role-based access control (RBAC). Users should only access the minimum PHI necessary for their role. A billing clerk does not need access to clinical notes. Implement this at the application level, not just the database level.
- Session management. Sessions must have automatic timeouts. For applications handling ePHI, 15-minute idle timeouts are a common standard. Sessions should be invalidated on logout, and concurrent session limits should be enforced.
Audit Logging
HIPAA requires that you log all access to ePHI — who accessed it, when, from where, and what they did with it. This is non-negotiable.
Your audit logs must capture: user identity, timestamp, action performed (read, create, update, delete), the resource accessed, source IP address, and success or failure of the action. Store audit logs in a tamper-evident, append-only system. AWS CloudTrail combined with S3 Object Lock (in compliance mode) is one effective approach. Retention requirements vary by state, but six years is the HIPAA minimum for compliance documentation.
Critically, audit logs themselves must not contain PHI. Log that user 4582 accessed patient record 9271 at 14:32 UTC. Do not log that Dr. Smith accessed Jane Doe's diabetes diagnosis.
Data Integrity Controls
You need mechanisms to ensure ePHI has not been improperly altered or destroyed. This includes database integrity checks, checksums for data at rest, and version control or change tracking for clinical records. Many healthcare applications implement soft deletes rather than hard deletes, maintaining a complete history of all record modifications.
Infrastructure and Architecture
Your infrastructure choices are constrained by HIPAA eligibility. Not every cloud service qualifies, and your architecture must be designed around this reality.
HIPAA-Eligible Services on AWS
AWS maintains an explicit list of HIPAA-eligible services. Key services include EC2, RDS (PostgreSQL, MySQL, Aurora), DynamoDB, S3, Lambda, API Gateway, ECS, Fargate, Cognito, KMS, CloudWatch, CloudTrail, SNS, SQS, and Secrets Manager. Services not on the list — such as certain AI/ML services or newer offerings — cannot be used with PHI until AWS adds them.
Database Design
Encrypt your database at the instance level using KMS. Enable encryption for automated backups and read replicas. Use SSL/TLS for all database connections — configure your connection pool to reject unencrypted connections. Implement column-level encryption for particularly sensitive fields (SSNs, diagnoses) as an additional layer beyond volume encryption.
Access the database through IAM authentication rather than static credentials where possible. If using static credentials, store them in AWS Secrets Manager with automatic rotation enabled.
Network Architecture
Deploy HIPAA workloads within a dedicated VPC. Place databases and backend services in private subnets with no direct internet access. Use NAT gateways for outbound traffic and VPC endpoints for AWS service access. Implement security groups and network ACLs following the principle of least privilege — only open the specific ports and protocols required.
Serverless Considerations
Serverless architectures (AWS Lambda, API Gateway) can simplify HIPAA compliance in some ways. You do not manage operating systems, so you eliminate an entire class of patching and hardening concerns. However, serverless introduces its own considerations: Lambda environment variables should not contain PHI (use Secrets Manager), function logs must be configured with appropriate retention and encryption, and cold start behavior must be understood in the context of session management.
Container Security
For containerized workloads on ECS or EKS, use Fargate to avoid managing the underlying EC2 instances. Scan container images for vulnerabilities using Amazon ECR image scanning or tools like Trivy. Never bake credentials or PHI into container images. Use IAM roles for task-level permissions and pull secrets from Secrets Manager at runtime.
Mobile-Specific HIPAA Considerations
Mobile applications introduce unique risks because the device itself is outside your control.
Data at rest on device. Never store ePHI in plain text on a mobile device. On iOS, use the Keychain for sensitive tokens and credentials, and enable Data Protection (NSFileProtectionComplete) for any cached health data. On Android, use the Android Keystore for cryptographic keys and EncryptedSharedPreferences or EncryptedFile from the Jetpack Security library.
Biometric authentication. Face ID, Touch ID, and Android BiometricPrompt provide strong local authentication, but they should supplement — not replace — your backend authentication. A biometric unlock should release a securely stored authentication token, not bypass your auth flow entirely.
Push notifications. Never include PHI in push notification content. A notification that reads "Your lab results for your HIV test are ready" is a HIPAA violation. Use generic messages like "You have a new message" and require authentication before displaying any health information.
Screenshot and app backgrounding. iOS and Android both capture screenshots of your app when it moves to the background (for the app switcher). Implement a privacy screen or blur overlay in your app delegate or activity lifecycle to prevent ePHI from appearing in these screenshots. On iOS, use applicationWillResignActive to overlay a privacy view. On Android, set FLAG_SECURE on windows displaying PHI.
Enterprise deployment. For apps deployed in clinical settings, consider integration with Mobile Device Management (MDM) solutions like VMware Workspace ONE or Microsoft Intune. MDM enables remote wipe, enforced encryption, and managed app configuration.
Common HIPAA Violations in App Development
These are the mistakes we see most often, and every one of them represents a real compliance risk.
Logging PHI to crash reporting tools. Sentry, Crashlytics, Bugsnag — these tools capture stack traces, request bodies, and local variables. If a patient's name, diagnosis, or medical record number appears in any of these contexts, you have transmitted PHI to a third party that almost certainly does not have a BAA with you. Scrub all PHI from error reports before they leave your application.
Storing PHI in unencrypted local storage. localStorage, AsyncStorage, UserDefaults without Data Protection, SharedPreferences without encryption — none of these are acceptable for ePHI. Use platform-specific secure storage mechanisms.
Including PHI in URLs or query parameters. URLs appear in server logs, browser history, referrer headers, and CDN logs. A URL like /patients/john-doe/records/diabetes-diagnosis is a violation even if the page itself is access-controlled.
Using non-HIPAA-eligible third-party services. Every service that touches PHI needs a BAA. That includes your analytics platform, your email provider, your SMS gateway, and your customer support tool. If a service will not sign a BAA, it cannot process PHI.
Inadequate access controls. Building an admin panel that shows all patient records to all authenticated users is not compliant, regardless of how strong your authentication is. Access must be scoped to the minimum necessary for each user's role.
The Development Process for HIPAA Apps
HIPAA compliance is not a feature you add at the end. It is a property of your entire development process.
Security-first architecture. Before writing code, map every point where PHI enters, moves through, rests in, and exits your system. Document your data flow diagrams. Identify every third party that will access PHI. This architecture review should happen before your first sprint, and it should be revisited whenever you add a new integration or data flow.
Code review practices. Every pull request should be reviewed with PHI handling in mind. Establish a checklist: Does this change introduce new logging that could capture PHI? Does it add a new third-party integration? Does it modify access control logic? Does it change how data is stored or transmitted? Automate what you can — lint rules that flag direct console.log usage in PHI-handling modules, for example.
Penetration testing and vulnerability scanning. Conduct penetration testing at least annually, and after any significant architectural change. Use automated vulnerability scanning (Dependabot, Snyk, or similar) to catch known vulnerabilities in dependencies. OWASP ZAP or Burp Suite are standard tools for web application security testing.
Documentation. HIPAA requires policies and procedures to be documented and retained for six years. Document your security architecture, access control policies, incident response procedures, and employee training records. This documentation is what auditors will review, and it is what protects you in an investigation.
Ongoing monitoring. Compliance is not a point-in-time certification. Implement continuous monitoring with tools like AWS Config, GuardDuty, and Security Hub. Set up alerts for anomalous access patterns, failed authentication attempts, and configuration changes to HIPAA-relevant resources.
Cost and Timeline Expectations
HIPAA compliance adds meaningful cost and time to application development. Setting realistic expectations upfront prevents painful surprises later.
Development cost premium. Based on our experience, HIPAA compliance adds 20 to 40 percent to development costs compared to a non-regulated application with similar functionality. This premium covers security architecture design, encrypted infrastructure provisioning, audit logging implementation, access control systems, security testing, and compliance documentation.
Timeline impact. A HIPAA-compliant MVP typically takes 25 to 35 percent longer than an equivalent non-regulated application. The additional time goes to security architecture review, infrastructure hardening, penetration testing, documentation, and the iterative review cycles that compliance requires.
The cost of cutting corners. HIPAA penalties range from $100 to $50,000 per violation, with an annual maximum of $1.5 million per violation category. The OCR (Office for Civil Rights) has imposed penalties exceeding $16 million in a single case. Beyond fines, a breach triggers mandatory notification costs, legal fees, remediation expenses, and reputational damage that can be existential for a startup. The 30 percent premium for doing it right is a bargain compared to the cost of doing it wrong.
Building a HIPAA-compliant application is demanding, but it is not mysterious. The requirements are well-defined, the technical patterns are proven, and the path forward is clear — if you approach it systematically from day one.
If you are planning a healthcare application and want to talk through architecture, compliance strategy, or development approach, get in touch. We have been through this process multiple times and are happy to share what we have learned.