How to Build a HIPAA Compliant App: Step-by-Step Guide 2025
Building a HIPAA compliant app is not as simple as adding encryption and calling it done. HIPAA compliance is a systematic program covering your architecture, security controls, vendor relationships, documentation, and ongoing monitoring. This guide walks you through every step — from determining whether HIPAA applies to your app through launch and beyond.
This guide covers both mobile (iOS and Android) and web application development. Where requirements differ between platforms, we call it out explicitly. We cover technical implementation decisions in depth — this is a developer's guide, not a summary of regulations.
In This Guide
- 01Determine If HIPAA Applies to Your AppDay 1
- 02Map Your PHI Data FlowsWeek 1
- 03Conduct a HIPAA Security Risk AnalysisWeek 1–2
- 04Design Your HIPAA Compliant ArchitectureWeek 2–3
- 05Implement HIPAA Technical SafeguardsOngoing Development
- 06Mobile-Specific HIPAA RequirementsDuring Mobile Development
- 07HIPAA Security TestingBefore Launch & Annually
- 08Documentation and Compliance ProgramOngoing
Determine If HIPAA Applies to Your App
Day 1Before writing a line of code, determine whether your app is subject to HIPAA. Not every health-related app is a HIPAA covered app.
Does your app create, receive, maintain, or transmit PHI?
HIPAA applies to apps that handle Protected Health Information on behalf of a covered entity or as a business associate. A general wellness app (calorie counter, step tracker with no connection to a healthcare provider) is typically not subject to HIPAA. An app that a healthcare provider uses to communicate clinical information about identified patients is.
Are you building for a covered entity or acting as a business associate?
If a hospital, health system, clinic, health plan, or other covered entity is your customer, and your app handles their patients' PHI, you are a business associate subject to HIPAA. The key question is not what your app does in isolation, but whether it processes PHI on behalf of an entity that is covered by HIPAA.
Consumer health apps and FTC oversight
Consumer health apps not connected to a covered entity are generally not covered by HIPAA, but they may be subject to FTC oversight — particularly the FTC Health Breach Notification Rule for apps collecting personal health data. Don't confuse 'not HIPAA covered' with 'no health privacy obligations.'
Map Your PHI Data Flows
Week 1The foundation of HIPAA app development is a complete, accurate map of where PHI enters, moves through, and exits your application.
Identify every PHI input point
List every place PHI enters your system: patient registration forms, EHR data feeds via FHIR/HL7, lab result imports, document uploads, messaging, wearable device data, insurance verification responses. Each input point is a potential vulnerability that needs appropriate controls.
Trace PHI through your system architecture
Follow PHI from every input through your processing logic, databases, caches, log files, queues, third-party API calls, and analytics systems. PHI has a way of leaking into unexpected places — application error logs, third-party monitoring tools, analytics dashboards. Map it all.
Document every PHI output and disclosure
Document where PHI leaves your system: API responses to authorized clients, data exports, reports, notifications, and any PHI sent to third-party services. Each output must be either permitted under HIPAA (treatment, payment, operations) or supported by patient authorization.
Create a data flow diagram
Document your PHI data flows in a formal data flow diagram (DFD). This diagram becomes the primary tool for your HIPAA Security Risk Analysis and is essential evidence of a documented compliance program. Update it whenever the architecture changes.
Conduct a HIPAA Security Risk Analysis
Week 1–2The HIPAA Security Rule requires a risk analysis before implementing security controls. A risk analysis is not a checklist — it's a structured assessment of threats, vulnerabilities, and risk.
Identify threats and vulnerabilities for each PHI data flow
For every PHI data flow you mapped in Step 2, identify potential threats (unauthorized access, malware, natural disaster, employee error) and vulnerabilities (weak authentication, unencrypted storage, unpatched software). NIST SP 800-30 provides a widely used methodology for this.
Assess likelihood and impact
For each threat-vulnerability combination, assess the likelihood of occurrence (considering existing controls) and the potential impact on PHI confidentiality, integrity, and availability. Produce a risk level (High / Medium / Low) that guides your control prioritization.
Identify controls to reduce risk to acceptable levels
For each identified risk, determine the controls that will reduce the risk to an acceptable level — then implement them. Document the rationale for every control decision, including cases where you deemed a control not reasonable or appropriate (for addressable specifications).
Document everything
The risk analysis must be documented and retained for 6 years. OCR investigations routinely start with a request for the organization's most recent risk analysis. An undocumented risk analysis is, legally, no risk analysis at all.
Design Your HIPAA Compliant Architecture
Week 2–3With the risk analysis complete, design your application architecture with HIPAA technical safeguards built in from the start.
Choose a HIPAA-eligible cloud provider and sign a BAA
Select AWS, Azure, or GCP — all three offer HIPAA BAAs and extensive HIPAA-eligible services. Sign the BAA before any PHI touches the cloud environment. Deploy PHI workloads only in HIPAA-eligible services. Design a VPC with private subnets for PHI resources and no direct public internet access to PHI data stores.
Design your authentication and authorization model
Implement authentication using an established identity provider (Auth0, Cognito, Azure AD B2C, or your own OIDC server) — don't roll your own auth. Design a role model that enforces least-privilege PHI access. Plan for MFA from the start; retrofitting it is painful. Design API authorization using short-lived JWTs with appropriate scopes.
Design your encryption architecture
Plan encryption for every PHI data store: database (TDE or field-level), file storage (server-side encryption with CMEK), backups (encrypted), and local mobile storage (device-derived keys). Design your key management approach — where keys are stored, how they rotate, and how they are accessed by your application without exposure.
Design your audit logging architecture
Design a centralized audit log that captures every PHI access event from your application. Determine the log schema (userId, action, resourceType, resourceId, timestamp, sourceIP) and the log storage backend (CloudWatch, Splunk, OpenSearch). Plan for write-once storage, 6-year retention, and access controls on the log data itself.
Identify and obtain BAAs for all third-party services
Inventory every third-party service your app will use: analytics, crash reporting, push notifications, email, SMS, customer support, monitoring. Determine which will have access to PHI (directly or through metadata). Obtain BAAs from those that will. For services without BAAs, design your integration to exclude PHI from the data they receive.
Implement HIPAA Technical Safeguards
Ongoing DevelopmentWith architecture designed, implement the four technical safeguard categories required by 45 CFR § 164.312.
Access Controls (§ 164.312(a))
Implement unique user IDs, role-based access control, MFA, automatic session timeouts, and emergency access procedures. Every PHI endpoint must validate the authenticated user's permissions before returning data. Never trust client-side access control claims — enforce authorization server-side.
Audit Controls (§ 164.312(b))
Implement audit logging for every CRUD operation on PHI records. Log at the application layer (not just database query logs) to capture user context. Use structured logging formats (JSON) for queryability. Implement log forwarding to your centralized SIEM with real-time anomaly alerting.
Integrity Controls (§ 164.312(c))
Protect PHI from unauthorized modification. Implement soft-delete patterns for PHI records (never hard delete — audit requirements demand retention). Use database triggers or application-layer versioning to track PHI record changes. Validate document checksums at upload and retrieval.
Transmission Security (§ 164.312(e))
Enforce TLS 1.2+ on all endpoints. Configure strong cipher suites. Implement HSTS. Add certificate pinning to mobile apps. Use private connectivity (VPC endpoints, PrivateLink, Direct Connect) to avoid traversing the public internet for backend communication. Implement mutual TLS (mTLS) for service-to-service calls.
Mobile-Specific HIPAA Requirements
During Mobile DevelopmentMobile apps face unique HIPAA challenges related to device security, offline data access, push notifications, and distribution.
Implement biometric authentication
Use Face ID, Touch ID, or Android biometric APIs to protect PHI access. Store authentication credentials in platform-secure hardware (Keychain on iOS, Keystore on Android). Implement a fallback PIN/passcode with progressive lockout on failed attempts.
Encrypt all locally stored PHI
If your app stores any PHI offline (appointment data, patient records, messages), encrypt it using device-derived keys from the Secure Enclave (iOS) or StrongBox (Android). Never store PHI in shared preferences, external storage, or unencrypted SQLite databases.
Design PHI-free push notification payloads
Push notification payloads pass through Apple APNs and Google FCM servers — which may not have BAAs or may not be considered PHI-eligible. Design notifications to carry only a notification ID; the app fetches the actual message content after the user authenticates in-app.
Implement app transport security and background restrictions
Enable App Transport Security (iOS) to enforce TLS. Disable background app refresh for PHI-containing views. Implement screenshot prevention for sensitive screens. Clear PHI from memory and UI when the app moves to the background.
HIPAA Security Testing
Before Launch & AnnuallyHIPAA compliance must be verified through rigorous security testing before production launch and regularly thereafter.
Penetration testing
Commission a third-party penetration test covering your full application stack — web/mobile app, APIs, authentication, access controls, and cloud infrastructure. The pentest should specifically test HIPAA controls: can a standard user access another user's PHI? Can an unauthenticated request reach PHI data? Can audit logs be modified?
Automated SAST and DAST in CI/CD
Integrate SAST (Semgrep, Checkmarx, Snyk Code) and DAST (OWASP ZAP, Burp Suite) into your CI/CD pipeline. Fail builds on critical vulnerabilities in PHI-handling code. Run dependency scanning (Snyk, Dependabot) and block deployments with known critical CVEs in dependencies.
HIPAA-specific test cases
Write test cases that validate HIPAA controls: verify audit log generation for each PHI operation, test MFA bypass resistance, confirm session timeout behavior, validate that encrypted storage is actually used, test that deprovisioned users cannot access PHI, and verify that API responses don't leak PHI to unauthorized roles.
Vulnerability scanning and compliance monitoring
Run continuous vulnerability scanning on your cloud infrastructure (AWS Security Hub, Azure Defender, GCP Security Command Center). Use infrastructure-as-code scanning (Checkov, tfsec) to catch misconfigurations before deployment — open S3 buckets, publicly accessible databases, or missing encryption settings.
Documentation and Compliance Program
OngoingTechnical controls alone are not sufficient. HIPAA requires documented policies, procedures, and evidence of ongoing compliance monitoring.
Maintain a HIPAA security documentation set
Required HIPAA documentation includes: your risk analysis and risk management plan, policies and procedures for all required and addressable specifications, training records, incident response logs, BAA inventory, and your contingency plan. All must be retained for 6 years.
Establish a HIPAA incident response process
Define your process for detecting, investigating, and reporting HIPAA security incidents and breaches. The process must include who is notified (Privacy Officer, legal, leadership), how you conduct the four-factor risk assessment to determine reportability, and your timeline for notifications to affected individuals and HHS.
Conduct annual HIPAA reviews
HIPAA requires periodic review of security policies and updating them when environmental or operational changes occur. At minimum, conduct an annual HIPAA Security Rule review — revisit the risk analysis, review new threats, assess new systems added to scope, and update documentation accordingly.
Final Thoughts: HIPAA Compliance Is an Ongoing Process
HIPAA compliance is not a one-time certification — it is an ongoing program. Your risk profile changes as you add new features, new vendors, new staff, and as the threat landscape evolves. The most important mindset shift for development teams is treating HIPAA compliance as a continuous engineering discipline, not a pre-launch checkbox.
The most common cause of HIPAA violations in software is not intentional wrongdoing — it's the gradual accumulation of small technical shortcuts taken under schedule pressure. A logging change that accidentally captures PHI. A new third-party SDK added without a BAA. An access control that works correctly in the happy path but has an edge case that allows privilege escalation.
Build HIPAA review into your regular engineering processes: sprint planning, architecture review, code review, and deployment pipelines. Use our HIPAA Software Development Checklist as a recurring reference. And when in doubt about a compliance decision, ask — the cost of a free consultation is far less than the cost of a breach.
Ready to Build Your HIPAA Compliant App?
Our HIPAA software development team can guide you through every step in this guide — from data flow mapping and risk analysis through architecture, implementation, and launch.