Single Blog

Every year, healthcare organizations in the US pay out over $100 million combined in HIPAA settlements — and a growing share of those penalties trace back to third-party software: patient portals, telehealth apps, and EHR integrations built without compliance baked in from day one. If you’re building or buying healthcare software, the checklist below covers what actually matters, not just what looks good on a compliance slide deck.

Why “HIPAA Compliant” Is Not a Feature You Add Later

HIPAA compliance isn’t a settings toggle you flip before launch. It’s a set of architectural decisions — how data is encrypted, who can access what, how long logs are retained — that are far more expensive to retrofit than to design in from the start. We’ve seen clinics spend more re-architecting a “compliant-ish” app after an audit than they would have spent building it correctly the first time.

Technical Safeguards

These are the engineering controls auditors check first:

• Unique user authentication — every user (not every role) needs a distinct login, so access can be traced to an individual, not just a login shared across a nursing team.
• Automatic session logoff — idle sessions on shared clinic workstations are one of the most common real-world PHI exposure points; 10–15 minutes of inactivity is a reasonable default.
• Encryption in transit and at rest — TLS 1.2+ for anything moving over a network, AES-256 for anything stored, including backups and any analytics pipeline the data flows into.
• Audit controls — a tamper-evident log of who accessed which record, when, and what changed. This is the first thing an auditor asks for after any incident.
• Emergency access procedure — a documented, auditable “break glass” path so care isn’t blocked by an access control during an emergency.

Physical Safeguards

Often overlooked because they feel like “IT’s problem,” but they’re squarely in scope:

• Workstation use policies — screens auto-lock, devices aren’t left logged in at nurses’ stations, PHI isn’t displayed on screens visible to waiting rooms.
• Device and media controls — a documented process for wiping PHI from decommissioned laptops, phones, and backup drives before disposal or reassignment.

Administrative Safeguards

The paperwork side, which is where most audits actually start:

• A designated Security Officer — one named person accountable for the compliance program, not a shared responsibility that ends up owned by no one.
• Workforce security training — documented, repeated (not once at onboarding and forgotten), covering phishing and social engineering specifically, since that’s how most breaches actually start.
• Information access management — role-based access so a billing clerk can’t see clinical notes and a front-desk scheduler can’t see lab results.

The Part Most Teams Miss: Business Associate Agreements

If your app sends data to any third party — a hosting provider, an analytics tool, an SMS/email service, an AI API — that vendor needs a signed Business Associate Agreement (BAA) before any PHI touches their systems. This is the single most common gap we find auditing other vendors’ work: a team builds a technically secure app, then pipes appointment reminders through an SMS provider with no BAA in place, which is a HIPAA violation regardless of how good the encryption is everywhere else.

What This Looks Like in Practice

Over 19 years building healthcare software — EHR customizations, telemedicine platforms, and patient portals for US clinics — the pattern holds: compliance failures are almost never dramatic hacks. They’re a shared login here, an un-encrypted backup there, a vendor without a BAA. A HIPAA-ready build process checks all three safeguard categories above at the architecture stage, not the QA stage.

Get a Compliance-Ready Build

If you’re scoping a healthcare app — patient portal, telemedicine platform, or an EHR integration — we can walk through exactly how this checklist applies to your specific build before you write a line of code.