HIPAA-Compliant Software Development: What It Actually Means

Every software agency that's ever looked at a healthcare client has added "HIPAA-compliant development" to their website. Most of them mean they've read the Wikipedia article.

I've been building software for US healthcare clients for years. I've seen what HIPAA compliance actually looks like in production — and I've seen what happens when a dev team treats it as a checkbox rather than an architecture decision. This post is the honest version: what HIPAA compliance actually requires in software, where most developers get it wrong, and how to tell the difference between a team that's done this before and one that's hoping for the best.

First, what HIPAA actually governs

HIPAA — the Health Insurance Portability and Accountability Act — sets the rules for handling Protected Health Information, or PHI. PHI is any information that could identify a patient combined with health-related data: names, dates of birth, medical record numbers, diagnoses, treatment records, billing information, and more.

If your software touches PHI in any way — stores it, transmits it, processes it, displays it — you're operating under HIPAA. That includes your application, your infrastructure, your third-party services, and your team.

The relevant piece for software development is the Security Rule, which specifies the safeguards required for electronic PHI (ePHI). It's organized into three categories: administrative safeguards, physical safeguards, and technical safeguards. Most of what developers need to care about lives in technical safeguards — but they don't exist in isolation from the other two.

The three things most developers get wrong

1. They treat it as documentation, not architecture

The most common mistake I see is teams that approach HIPAA compliance as a paperwork exercise. They write a privacy policy, sign a Business Associate Agreement (BAA) with their cloud provider, and call it done. The actual code, the actual data flows, the actual infrastructure — those stay unchanged.

HIPAA compliance isn't a document you sign. It's a set of technical requirements that shape how you architect your system from the ground up. If you design the system first and try to bolt compliance on afterward, you will almost always miss things that require expensive rework later.

The right approach: treat PHI handling as an architectural constraint from day one. Where does PHI enter the system? Where does it rest? Where does it move? Who can access it under what conditions? These questions need answers before you write a single line of code, not after.

2. They confuse encryption with compliance

Encryption is necessary but nowhere near sufficient. I've spoken to teams who've implemented TLS for data in transit and AES-256 for data at rest and genuinely believed they'd handled the technical requirements. They hadn't.

The Security Rule requires encryption, yes — but it also requires access controls (who can see what, and under what conditions), audit controls (logs of who accessed what, when), integrity controls (ensuring data isn't improperly altered or destroyed), and transmission security. Each of these is a separate technical implementation, and each one has real depth.

Access control alone, done properly, means role-based permissions tied to clinical roles, not just user accounts. A field clinician should see their assigned patients. An administrator should see scheduling data. A billing coordinator should see billing data. These aren't the same thing, and a system that just has "admin" and "user" roles isn't compliant with the spirit or letter of the minimum necessary standard.

3. They don't think about Business Associate Agreements

Every third-party service that touches PHI requires a BAA — a contract in which the vendor agrees to handle PHI in compliance with HIPAA. This includes your cloud provider, your database service, your email provider if you're sending any PHI-related notifications, and any analytics or monitoring tools that might log PHI.

This catches teams off guard constantly. You might build a perfectly secure application, then route error logs through a monitoring service that doesn't have a BAA — and suddenly you have a compliance gap, because those logs might contain PHI.

Before you integrate any third-party service into a HIPAA-covered application, the first question is: can this service sign a BAA? If the answer is no, you either don't use it, or you architect around it so PHI never touches it.

What HIPAA-compliant architecture actually looks like

Here's the practical picture of what we build when a client needs genuine HIPAA compliance.

Infrastructure layer

We use cloud providers that offer BAAs and HIPAA-eligible services — AWS is the most common in our healthcare work, specifically services that are on AWS's HIPAA-eligible list (not all AWS services are, which is another thing that catches developers off guard). The infrastructure is deployed in isolated VPCs, with PHI-containing resources in private subnets that have no direct internet access. Access to those resources goes through controlled, audited pathways.

Encryption

TLS 1.2 minimum (TLS 1.3 preferred) for all data in transit — not just API calls, but internal service-to-service communication too. AES-256 for data at rest. Encryption keys managed through a proper key management service (AWS KMS in our case), not hardcoded or environment-variable based. Separate encryption keys per environment so development, staging, and production never share keys.

Access controls

Role-based access control tied to clinical and administrative roles, not generic user types. Row-level security in the database for multi-tenant systems — one agency's patients are never visible to another agency's users, enforced at the data layer, not just the application layer. Session management with appropriate timeouts — automatic logoff after inactivity is an addressable specification in the Security Rule.

Audit logging

Every access to PHI is logged: who accessed it, what they accessed, when, from what IP, through what action. These logs are immutable — stored separately from application data, write-only by the application, with access restricted to authorized personnel. Audit logs are retained for a minimum of six years per HIPAA requirements. This is non-negotiable and frequently overlooked in initial implementations.

Data minimization

The minimum necessary standard in HIPAA means you should only collect, transmit, and store the PHI that's actually needed for the specific function. This influences API design (don't return full patient records when a summary is sufficient), search functionality (don't expose PHI in URL parameters), and logging (scrub PHI from application logs — application logs and audit logs are different things).

Breach detection and response

HIPAA's Breach Notification Rule requires notification within 60 days of discovering a breach affecting 500 or more individuals. This means you need monitoring in place to detect unauthorized access, anomalous access patterns, or data exfiltration — not just periodic manual review.

The BAA checklist for common services

When we audit a new healthcare software project, here's what we check for BAAs:

• Cloud infrastructure — AWS, GCP, Azure all offer BAAs, but you must request and sign them specifically
• Database services — RDS and managed database services are typically covered under your cloud provider BAA
• Email delivery — most transactional email services don't offer BAAs; AWS SES does
• Error monitoring — Sentry offers a BAA on paid plans; many alternatives don't
• Analytics — Google Analytics cannot sign a BAA; you need a HIPAA-compliant alternative if tracking PHI-adjacent behavior
• Video and telehealth — Zoom for Healthcare, Daily.co, and Twilio Healthcare all offer BAAs
• Authentication providers — Auth0 offers a BAA on enterprise plans; verify for any auth service you use

What to ask a development team before hiring them

If you're evaluating software development teams for a HIPAA-covered project, here are the questions that separate teams with real experience from teams that are guessing:

"Walk me through how you handle audit logging." A team with real experience will immediately start talking about immutable logs, retention periods, what events get logged, and how logs are protected. A team without experience will say something vague about logging user actions.

"How do you handle PHI in your development environment?" The right answer involves synthetic or de-identified data for development, never real patient data. It also involves encrypted development databases, not local files with a copy of production data.

"Which services will you use that touch PHI, and do they offer BAAs?" If they haven't thought about this yet, that's your answer.

"How do you handle encryption key management?" Hardcoded keys or environment variables are red flags. A proper answer involves a managed key service with key rotation.

"What's your process when a vulnerability is discovered post-launch?" HIPAA requires a risk management process. A development team building HIPAA-covered software should have a clear answer about security patching, vulnerability disclosure, and incident response.

The honest bottom line

HIPAA compliance isn't impossibly hard. But it requires treating it as an architectural foundation, not an afterthought. The teams that get this right start with PHI flows and access controls before they start with features. The teams that get it wrong start with features and try to layer compliance on top.

At Nexios, we've built HIPAA-compliant systems for home health, care coordination, and telehealth clients. The experience isn't just in knowing the rules — it's in knowing how those rules translate to the specific decisions you make when designing an API, configuring a database, or choosing a third-party service.

If you're building software in healthcare and want to talk through your architecture, book a 30-minute call. We'll tell you honestly whether your current approach has gaps and what it would take to close them.