If you're building software that touches patient data, even as a third-party cloud provider, HIPAA compliance isn't optional. This guide cuts through the legal fog and focuses on what matters for tech teams.
Who actually needs to comply?
Most developers assume HIPAA is a hospital problem. It isn't.
If your product falls into any of these categories, you're in scope:
- Custom healthcare software for a medical org
- EMR/EHR platforms
- Cloud storage or processing of any PHI
- Any SaaS tool used by a covered healthcare entity
You're likely classified as a Business Associate (BA) — which means you're directly liable under HIPAA, and you need a signed Business Associate Agreement (BAA) before processing any patient data.
No BAA = you're already in violation before writing a single line of code.
What counts as PHI?
Protected Health Information (PHI) is broader than most devs expect. Any data that can identify a patient and relates to their health condition qualifies — including:
- Names, SSNs, addresses, emails
- Medical records and diagnoses
- Billing and payment data
- Biometric identifiers
In 2026, this also extends to wearables and IoT medical devices that transmit health data to the cloud. If your app ingests data from a smartwatch connected to a patient's health record, you're handling ePHI.
The three technical safeguards you must implement
HIPAA requires three layers of protection:
- Administrative safeguards
Documented security policies
Employee training programs
Regular risk assessments
- Physical safeguards
Controlled access to servers/workstations
Workstation-level security policies
- Technical safeguards (where most dev teams start)
Encryption in transit and at rest
Role-based access controls (RBAC)
Audit logs for all PHI access
Automatic session timeouts
Build these in from day one. Retrofitting is painful and expensive.
HIPAA vs HITECH: the key difference
Bottom line for devs: HITECH means your subcontractors (hosting providers, analytics tools, third-party APIs) are also on the hook. Vet your entire stack.
Penalty tiers (updated January 2026)
Source: HIPAA Violation Fines, cost-of-living adjusted for 2025.
Tier 4 is where companies get destroyed. If you know about a violation and don't fix it, you're looking at both financial ruin and criminal prosecution.
Common violation patterns to avoid
❌ Sending PHI via unencrypted email
❌ Logging PHI in application error logs
❌ No audit trail on who accessed patient records
❌ Missing BAA with cloud providers (AWS, GCP, Azure all offer them)
❌ Using a third-party analytics SDK that collects PHI
The two most critical first steps:-
- Determine if you're a Business Associate. If you process PHI on behalf of a covered entity, you are. Get that BAA signed before any data flows.
- Design for compliance at the architecture level. Encryption, RBAC, and audit logging should be in your initial design doc — not your post-launch backlog.
Compliance is a process, not a checkbox
HIPAA has no official certification. There's no "HIPAA certified" badge you earn once. It's an ongoing operational commitment — regular audits, employee training refreshes, security upgrades as your stack evolves.
IoT and wearables are expanding the PHI surface area every year. Plan for scope creep.
Want a deeper dive into BAA requirements, architecture patterns, and compliance tooling for software teams?
→ Read the full guide: innostax.com
Built healthcare software? Ran into a compliance wall? Drop your experience in the comments, would love to hear what tripped up your team.
A few things I changed and why:
- Reframed the opening to speak directly to developers, not a general audience — dev.to readers want to know if they are affected, immediately.
- Added a code block for common violations — dev.to audiences respond to scannable, technical formatting.
- Converted the penalty table to plain markdown (renders natively on dev.to, no image dependency).
- Sharpened the CTA — two touchpoints: one mid-post soft mention and a final dedicated CTA with a discussion prompt to drive comments (which boosts dev.to algorithmic reach).
- Removed infographic references since those don't translate to the platform.
- Added the subcontractor angle more prominently since that's what catches SaaS/API devs off guard.
Top comments (0)