A founder emailed me last year with a short brief: "Build the patient portal, and make it HIPAA compliant." That sentence sounds reasonable. It's also the single most common misunderstanding in HIPAA software development — the idea that compliance is a checkbox you flip near the end of the project, somewhere between "add SSL" and "deploy to production."
It isn't. HIPAA is mostly about process, and only partly about code. And the parts that are about code are rarely the parts developers focus on.
I've spent enough time in healthcare-adjacent builds — patient intake, telehealth scheduling, clinical data pipelines, ML models on de-identified records — to have a decent list of what goes wrong. Here it is, plus an honest section on when you can skip all of this.
First: there is no such thing as "HIPAA certified" software
No government body certifies applications. Anyone selling you a "HIPAA certification" is selling you an audit against a framework, which can be genuinely useful, but it is not a legal seal of approval.
What actually exists is a set of rules — the Privacy Rule, the Security Rule, and the Breach Notification Rule — that apply to covered entities (providers, health plans, clearinghouses) and their business associates (that's usually you, the software vendor, if you touch Protected Health Information on their behalf).
The Security Rule breaks safeguards into three groups: administrative, physical, and technical. Developers obsess over the technical third. Auditors and breach investigators spend most of their time on the administrative third — your policies, your risk analysis, your training records, who has access and why. If you've written beautiful AES-256 encryption but have no documented risk assessment, you are in worse shape than you think.
The mistakes I see most in HIPAA software development
1. Assuming encryption equals compliance
Encryption at rest and in transit is table stakes, and you should absolutely do it. But under the Security Rule, encryption is technically an "addressable" specification — meaning you implement it or document a reasonable alternative. Meanwhile, audit controls are required. So is access control. So is a mechanism to authenticate that data hasn't been improperly altered.
Translation: knowing who looked at which patient record and when matters at least as much as scrambling the bytes on disk.
2. Logging PHI — this is the big one
If I audit one thing first, it's logs. Nine times out of ten I find Protected Health Information sitting in plain text somewhere it shouldn't be:
- Full request bodies dumped into application logs on error
- Patient names and diagnoses inside exception messages sent to a third-party error tracker
- Query parameters with medical record numbers captured by web analytics
- Debug logging left on in production "temporarily" eight months ago
- PHI in Slack alerts from a monitoring webhook
Your logs are a database you didn't secure. Redact at the source, keep an allowlist of loggable fields rather than a blocklist of forbidden ones, and never log full payloads for endpoints that carry clinical data.
3. Third-party services without a signed BAA
Every vendor that stores, transmits, or can access PHI needs a Business Associate Agreement. People remember AWS and forget everything else: the transactional email provider, the SMS gateway, the PDF generator, the session-replay tool, the chatbot widget, the CI system that has production DB access, the analytics script.
And a BAA with a cloud provider does not cover every service they sell. AWS, Azure, and Google Cloud all publish lists of HIPAA-eligible services. If you're using something outside that list to handle PHI, the BAA doesn't help you. Check the current list yourself — they change.
4. Real patient data in staging
"We just cloned prod to test the migration." I've heard this on more than one project. Now PHI lives on a server with weaker access control, no audit logging, and a shared password in a team wiki. Build a synthetic data generator early. It costs a few days and saves you an incident report.
5. Notifications that leak
Email and SMS are the sneakiest failure mode because they feel like a UX decision, not a security one. "Reminder: your MRI at Dr. Shah's oncology clinic is tomorrow at 3pm" is PHI sitting in an inbox you don't control. The safe pattern is a content-free nudge — "You have a new message in your portal" — with the actual detail behind authentication. Some clinics do send more detail with patient consent; that's a decision for their compliance officer, not for your sprint board.
6. No plan for de-provisioning, backups, or deletion
Who removes access when a nurse leaves? How long do backups persist, and are they encrypted with keys you control? Can you honour a records request or a deletion policy without a database engineer writing ad-hoc SQL? These are boring questions that show up in every real audit.
When you probably don't need HIPAA at all
Here's the part most agencies won't tell you, because HIPAA scope means bigger invoices.
HIPAA applies to covered entities and their business associates. It is not a general-purpose "health data" law. If you're building a direct-to-consumer fitness tracker, a meditation app, or a nutrition logger with no relationship to a provider or insurer, HIPAA likely does not apply to you. In the US, the FTC's Health Breach Notification Rule and state privacy laws may — which is a real obligation, just a different one.
Also worth knowing:
- Properly de-identified data isn't PHI. If you follow the Safe Harbor method (removing the 18 specified identifiers) or get an expert determination, the data falls outside HIPAA. For most analytics and ML work, this is the right move — and it dramatically simplifies your architecture.
- Aggregate reporting rarely needs PHI. Ask what the dashboard actually has to show. "Average wait time by clinic" doesn't need names.
- If you're in the UK or EU, HIPAA isn't your law. Health data is special category data under GDPR/UK GDPR, with its own lawful-basis and DPIA requirements. Different rules, similar engineering discipline.
The cheapest compliance strategy is almost always scope reduction. Fewer systems touching PHI, fewer vendors in the chain, less data retained. Before we design anything for a healthcare client, we map where PHI genuinely needs to flow — and then try to shrink that map.
On that note, an honest disclosure: our own Orbis Lead CRM is built for general sales and lead pipelines, not as a HIPAA-scoped clinical system. When a healthcare prospect asks whether they can drop patient records into it, we say no and help them design something appropriate instead. A CRM tracking "someone enquired about our clinic" is a very different risk profile from one holding diagnoses.
AI, LLMs and PHI: the newest landmine
This one is moving fast, and I'm seeing genuine carelessness. Piping clinical notes into a public LLM endpoint to "summarise the chart" is a disclosure of PHI to a third party. If that provider hasn't signed a BAA covering the specific service and configuration you're using, you have a problem — no matter how good the feature demo looked.
What we do on AI and ML projects involving health data:
- De-identify before inference wherever the use case allows it
- Use enterprise/cloud AI endpoints that fall under an existing BAA, with zero-retention and no-training settings verified in writing — not assumed from a blog post
- Consider self-hosted open-weight models inside the client's own HIPAA-eligible environment when data absolutely cannot leave
- Log prompts and outputs carefully, because a prompt log is a PHI log
- Keep a human in the loop for anything touching clinical judgement
A practical baseline I'd start from
If you're scoping a build today, these are the things I'd insist on before writing a feature:
- A written risk analysis — even a modest one — and named ownership of security decisions
- Role-based access control with the "minimum necessary" principle actually enforced in code
- Immutable, queryable audit logs of PHI access, retained per policy
- PHI redaction in logging, error reporting, and analytics by default
- A vendor inventory with BAA status for every single service
- Synthetic data for all non-production environments
- Encryption in transit and at rest, with documented key management
- A tested incident response and breach notification runbook
- Onboarding/offboarding procedures and training records
Realistically, on a mid-sized product, doing this properly from the start adds somewhere in the region of 15–30% to engineering effort compared with an equivalent non-regulated build. Retrofitting it later costs far more, because it changes your data model, your logging, and sometimes your vendor list. That's not a sales line — it's just what rework costs.
The short version
Good HIPAA software development isn't about exotic cryptography. It's about knowing exactly where PHI lives, keeping that footprint small, proving who accessed what, and having signed paperwork with everyone in the chain. Most breaches I read about are mundane: a misconfigured bucket, a log file, an ex-employee's active account.
And one caveat I'll repeat because it matters — I'm an engineer, not your lawyer. Architecture decisions and legal interpretation need to happen together, ideally with your compliance officer in the room from week one.
If you're building something that touches health data and you'd like a straight answer on whether HIPAA actually applies to you — and what a sensible architecture looks like if it does — get in touch. You can also browse our work to see the kind of systems we build. Happy to tell you if you need less than you think.