Someone on the team says the words "we're building for healthcare." Immediately there are two camps: the people who understand this changes everything about how you build, and the people who think you add a privacy policy and you're done. HIPAA-compliant app development isn't a checkbox or a document. It's a set of specific technical, administrative, and physical safeguards that fundamentally shape how your architecture is designed. The penalties are not theoretical: OCR (Office for Civil Rights) fines for HIPAA violations run from $100 to $50,000 per violation category, with annual maximums up to $1.9 million per category. In 2023, the average HIPAA settlement was $1.3 million. For a startup, a single violation can be existential. This guide covers exactly what your development team must build — the technical safeguards that are required, not optional.
💡 TL;DR
HIPAA-compliant app development requires: encryption at rest and in transit for all PHI (Protected Health Information), comprehensive audit logging of every PHI access event, role-based access control with minimum necessary access principles, automatic session timeout (15 minutes of inactivity is the common standard), Business Associate Agreements with every vendor that touches PHI, and a documented incident response plan with a 60-day breach notification window. These are technical requirements, not suggestions. Your development timeline for a HIPAA-compliant product is 30–50% longer than an equivalent non-healthcare product.
What Is PHI — and Why the Definition Matters for Your Tech Stack
PHI (Protected Health Information) is any individually identifiable health information held or transmitted by a covered entity or business associate. The "individually identifiable" part is critical. A patient's diagnosis alone isn't PHI. A patient's diagnosis combined with any of 18 specific identifiers — name, date of birth, email address, IP address, account number, and more — is PHI. The full list of 18 identifiers is in the HIPAA Safe Harbor de-identification standard.
This matters for your tech stack because if your system touches PHI, every component that stores, processes, or transmits it must be HIPAA-compliant. That includes: your database, your application servers, your logging infrastructure, your error tracking tool, your analytics platform, your email provider, and your backup system. Not just the features that display health data. Every layer of your stack that handles or could handle PHI.
⚠️ The most common HIPAA gap in SaaS products
Sending PHI to analytics tools or error trackers that don't have HIPAA Business Associate Agreements. If your error tracker logs a stack trace that includes a patient ID, diagnosis code, or email address — and the error tracker doesn't have a BAA with you — that's a potential HIPAA violation. Audit your full data flow before any PHI enters your production system.
The Five Required Technical Safeguards
HIPAA's Security Rule defines three categories of safeguards: administrative, physical, and technical. The technical safeguards are the engineering team's responsibility. All five are required — some specific implementations are flexible, but the safeguards themselves are not optional.
🔐 Access Control (§164.312(a)(1))
Implement technical policies that allow only authorised persons to access PHI. In practice: role-based access control with defined roles and minimum necessary access, unique user IDs for every account (no shared logins), automatic logoff after 15 minutes of inactivity (this specific threshold isn't in the regulation but is the standard that most auditors expect), and emergency access procedures for when the primary access system is unavailable. Document every role and what PHI it can access.
📋 Audit Controls (§164.312(b))
Record and examine all activity in systems that contain PHI. This is a harder requirement than most startups realise. Not just authentication events — every read, write, and delete of PHI must be logged with who did it, what they accessed, when, and from where. Log storage must be tamper-evident and retained for a minimum of 6 years. Your audit logs for PHI are held to a higher standard than general application logs — they're legal records.
🔒 Integrity Controls (§164.312(c)(1))
Protect PHI from improper alteration or destruction. Technical implementation: checksums or hash verification on PHI data to detect corruption or unauthorised modification, version history or immutable audit records for PHI changes, and backup integrity verification. For most SaaS apps, this means ensuring your database backups are verified and your change logs for PHI records are immutable.
🌐 Transmission Security (§164.312(e)(1))
Guard against unauthorised access to PHI during electronic transmission. This means TLS 1.2 or higher on all connections that transmit PHI — no exceptions, no fallback. Test every endpoint with an SSL/TLS scanner. Check your API clients, webhooks, and background jobs — not just your web UI. Internal service-to-service communication that transmits PHI also needs TLS, even within your private network.
🗝️ Encryption at Rest (§164.312(a)(2)(iv)) — Addressable, but Skip at Your Peril
HIPAA technically classifies encryption at rest as "addressable" rather than required — meaning you can choose an alternative if you document the reasoning. In practice, no auditor or enterprise healthcare customer will accept a HIPAA-compliant app without encryption at rest. Encrypt your database volumes, your S3 buckets, and your backup snapshots. AES-256 is the standard. This is also a breach protection: encrypted data at rest is excluded from HIPAA breach notification requirements under the Safe Harbor provision.
Business Associate Agreements — Every Vendor, No Exceptions
A Business Associate Agreement (BAA) is a contract that HIPAA requires between you (the covered entity or business associate) and any vendor that creates, receives, maintains, or transmits PHI on your behalf. No BAA means that vendor relationship is a HIPAA violation if they touch PHI.
The major cloud and SaaS vendors that offer HIPAA BAAs: AWS (sign in the console under My Account → AWS Artifact), Google Cloud (available via GCP console), Microsoft Azure (via Azure portal), and Twilio (email their legal team). Major tools that offer BAAs with specific plans: Zendesk, Salesforce, HubSpot (Enterprise), and some versions of Slack. Tools that do not offer BAAs: many standard analytics platforms, some error tracking tools at lower tiers, and consumer-grade communication tools.
Before your first PHI enters any system, audit your complete tech stack. For every tool: does PHI flow through it? If yes, do you have a signed BAA? If no BAA is available, either eliminate PHI from that data flow or replace the tool with one that offers a BAA. This is non-negotiable.
Tool Category | PHI Risk | BAA Available? | Action |
|---|---|---|---|
AWS / GCP / Azure | High — stores all data | Yes — sign before launch | Sign BAA in console settings |
Error tracker (Sentry, Datadog) | High — may log PHI in stack traces | Enterprise tier only, some tools | Sanitise PHI from logs OR use HIPAA-tier plan |
Email provider (SendGrid, Mailgun) | Medium — may send PHI in emails | Available at some tiers | Sign BAA or avoid sending PHI via email |
Analytics (Mixpanel, Amplitude) | High if user events include PHI | Rarely available at standard tiers | Sanitise PHI from event data strictly |
Backup solution | High — full copy of your data | Must have BAA | Use cloud provider backup (covered under cloud BAA) |
Breach Notification — 60 Days and a Specific Process
If you have a security breach involving unsecured PHI, HIPAA requires you to notify affected individuals within 60 days of discovering the breach, and to notify the Department of Health and Human Services (HHS) within the same window. Breaches affecting more than 500 people in a state also require notification to prominent media outlets in that state. The 60 days is a hard deadline — not a guideline.
"Unsecured PHI" is the key phrase. PHI that was encrypted at rest and in transit (meeting NIST standards) is considered secured and exempt from breach notification requirements even if it was accessed. This is the Safe Harbor provision — one of the strongest practical reasons to implement encryption at rest, beyond the obvious security benefit.
Build a breach notification runbook before you go live with any PHI. The runbook should cover: how you detect a breach (monitoring and alerting), how you assess its scope (which PHI was affected, how many individuals), who is responsible for notification decisions, and the template communications for individual notification. The 60-day clock starts from the moment your organisation discovers the breach — not from when you complete your investigation.
Trusted by 500+ startups & agencies
"Hired in 2 hours. First sprint done in 3 days."
Michael L. · Marketing Director
"Way faster than any agency we've used."
Sophia M. · Content Strategist
"1 AI dev replaced our 3-person team cost."
Chris M. · Digital Marketing
Join 500+ teams building 3× faster with Devshire
1 AI-powered senior developer delivers the output of 3 traditional engineers — at 40% of the cost. Hire in under 24 hours.
Architecture Decisions That HIPAA Shapes
HIPAA isn't just a checklist you apply to an existing architecture. It shapes the architecture itself. Here are the decisions that experienced HIPAA-compliant development teams make differently from the start.
PHI isolation. Keep PHI in a dedicated database or schema, separate from general application data where possible. This makes access control cleaner, audit logging more targeted, and data subject requests (including HIPAA's Right of Access) significantly easier to fulfil. When PHI is mixed throughout your general data model, every compliance operation becomes a cross-database archaeology project.
Minimum necessary access at the data layer. Implement column-level access control or row-level security at the database level, not just the application level. If a user role doesn't need access to a specific PHI field, the database should enforce that — not rely on the application to filter it. This defence in depth catches bugs in the application layer before they become PHI exposure events.
Detailed change logging on all PHI tables. Every INSERT, UPDATE, and DELETE on tables containing PHI should be logged to an audit table with: the old and new values (or a reference to them), the user who made the change, the timestamp, and the application context. This is the integrity control requirement in practice — and it's the record that proves no unauthorised modification occurred if a patient or regulator asks.
The Bottom Line
HIPAA-compliant app development adds 30–50% to your development timeline. Build this into your estimates from day one — it can't be added quickly at the end.
The 18 PHI identifiers include obvious ones (name, SSN) and less obvious ones (IP address, account numbers, dates other than year). Audit your data model against the full list before your first patient data enters the system.
Every vendor that touches PHI needs a signed Business Associate Agreement. Sign your cloud provider BAA before launch. Audit every tool in your stack for PHI exposure. No BAA = HIPAA violation.
PHI audit logs must be retained for a minimum of 6 years and must be tamper-evident. This is a legal record, not a debugging log — treat it accordingly.
Encryption at rest is technically "addressable" under HIPAA but is non-negotiable in practice. It also triggers the Safe Harbor breach notification exemption — encrypted data that's breached doesn't require notification.
Your breach notification runbook must be live before any PHI enters your system. The 60-day notification window starts from breach discovery, not investigation completion. Unpreparedness at breach time costs far more than preparation before it.
OCR HIPAA settlement averages were $1.3 million in 2023. For a startup, a single violation can be existential. The engineering investment in compliance is not the expensive option — it's the cheap one compared to the alternative.
Frequently Asked Questions
What does HIPAA-compliant app development mean in practice?
It means building specific technical safeguards into your application architecture: encryption at rest and in transit for all PHI, comprehensive audit logging of every PHI access event, role-based access control with minimum necessary access principles, automatic session timeout, and Business Associate Agreements with every vendor that handles PHI. It also means a development timeline 30–50% longer than an equivalent non-healthcare product and a team that understands the requirements before they write the first line of code.
What is Protected Health Information (PHI) under HIPAA?
PHI is any individually identifiable health information held or transmitted by a covered entity or business associate. The identifiability comes from a list of 18 specific identifiers: name, geographic data smaller than state, dates (other than year), phone numbers, fax numbers, email addresses, Social Security numbers, medical record numbers, account numbers, certificate/license numbers, URLs, IP addresses, biometric identifiers, full-face photographs, and any other unique identifying number or code. A health condition combined with any one of these is PHI and must be protected under HIPAA.
Do I need a Business Associate Agreement with AWS or Google Cloud for a HIPAA app?
Yes — if your application stores or processes PHI on those platforms, you need a signed BAA. Both AWS and Google Cloud offer standard HIPAA BAAs that you can sign directly through your account settings (AWS Artifact for AWS, the Google Cloud HIPAA BAA via your console). This must be signed before any PHI enters the system. The BAA covers the infrastructure services — you're still responsible for the security controls within your own application.
How long do you need to retain HIPAA audit logs?
HIPAA requires a minimum retention period of 6 years for most documents, including audit logs. Your audit logs for PHI access are legal records — they must be retained for 6 years from the date of creation or the date when they were last in effect, whichever is later. Store them in tamper-evident, immutable storage — not in your application database where they could be modified by application code or an SQL error.
What is the HIPAA breach notification requirement timeline?
If a breach of unsecured PHI occurs, you must notify affected individuals within 60 calendar days of discovering the breach. You must also notify the HHS Office for Civil Rights within the same 60-day window. Breaches affecting more than 500 residents of a state require notification to prominent media outlets in that state. The 60 days starts when your organisation discovers the breach — not when the breach occurred, and not when your investigation concludes. Have a runbook ready before you handle any PHI.
Can a startup build a HIPAA-compliant app without a large dedicated security team?
Yes — but you need developers who understand the requirements and a clear technical brief that maps HIPAA safeguards to engineering tasks. The administrative safeguards (policies, training, workforce management) require people with compliance expertise, but the technical safeguards are engineering deliverables. A strong senior developer with healthcare compliance experience can drive the technical implementation. The key is having the requirements clearly defined before development starts — not discovering them at the compliance audit.
What's the difference between HIPAA compliance and SOC 2 compliance for a SaaS app?
They address different things. HIPAA is a US federal law governing the handling of protected health information — specific to healthcare data. SOC 2 is a security certification framework (from the AICPA) that covers general security controls for any SaaS product. A healthcare SaaS product often needs both: HIPAA compliance for the regulatory requirement and SOC 2 certification for enterprise customer security questionnaires. The controls overlap significantly — audit logging, encryption, access control — but each has requirements the other doesn't cover.
Build for Healthcare — with Developers Who Know the Requirements
devshire.ai matches healthcare SaaS teams with pre-vetted developers who understand HIPAA technical safeguards, PHI audit logging, BAA requirements, and the architecture decisions that compliance shapes from day one.
Find a HIPAA-Experienced Developer at devshire.ai →
No upfront cost · Shortlist in 48–72 hrs · Freelance & full-time · Stack-matched candidates
About devshire.ai — devshire.ai matches AI-powered engineering talent with SaaS product teams. Every developer in the network has passed a live proficiency screen covering tool use, output validation, and real codebase review. Freelance and full-time options. Typical time-to-hire: 8–12 days. Start hiring →
Related reading: GDPR Compliance for SaaS Startups · SOC 2 Compliance for Developers · SaaS Security Best Practices · User Data Privacy in SaaS · API Security Best Practices · Vetted AI Developers for Hire
Devshire Team
San Francisco · Responds in <2 hours
Hire your first AI developer — this week
Book a free 30-minute call. We'll match you with the right developer for your project and get you started within 24 hours.
<24h
Time to hire
3×
Faster builds
40%
Cost saved