What HIPAA Actually Demands of Your Software Architecture

Published by CodeNicely, the product studio founded by Meghal Agrawal and Ujjwal Agrawal in 2017

For: A UK-based Chief Product Officer or CTO at a digital health or health-tech enterprise whose US enterprise client or US-listed investor has just required HIPAA compliance as a condition of the contract or next funding round — and who does not yet know that HIPAA places specific, auditable demands on the software itself, not just the privacy policy

HIPAA compliance for a software product is an architecture problem, not a documentation problem. The Security Rule (45 CFR §164.308–§164.312) mandates specific technical controls — encryption of ePHI at rest and in transit, unique user identification, automatic logoff, tamper-evident audit logs, and emergency access procedures — that must be demonstrably operating in the live system and producing evidence an auditor can inspect. A signed Business Associate Agreement and a well-written privacy policy satisfy none of these. If your platform cannot, today, produce a log naming every user who accessed a specific patient record over the last six years, you are not HIPAA compliant regardless of what your policies say.

That gap is where enforcement is landing. In 2024, the HHS Office for Civil Rights collected more than $9.9 million in HIPAA fines across 22 enforcement actions, and 14 of those 22 resolved Security Rule failures — the technical safeguards, not the paperwork. Montefiore Medical Center alone paid $4.75 million in February 2024 because it had no audit controls on its EHR, which let an employee quietly exfiltrate 12,517 patient records over six months before anyone noticed (HHS OCR).

If you are a UK-based CPO or CTO who has just been told HIPAA is a condition of a US enterprise contract or a US investor's term sheet, this post is what your engineering team needs to hear before they estimate the work.

What triggers the obligation in the first place

HIPAA applies when your software creates, receives, maintains, or transmits electronic protected health information (ePHI) on behalf of a US covered entity — a US healthcare provider, health plan, or clearinghouse — or on behalf of another business associate that serves one. The trigger is not where you are incorporated. A London-headquartered digital health platform that processes patient data for a US hospital system is a business associate, full stop, and is directly liable under the HITECH Act for Security Rule violations.

Two consequences UK teams routinely miss:

• Your UK GDPR and ISO 27001 posture does not transfer. They overlap meaningfully but HIPAA has specific requirements — audit log retention, emergency access, contingency planning — that ISO 27001 treats as optional controls. An ISO-certified system almost always fails a HIPAA technical audit without additional work.
• Your sub-processors inherit the obligation. Every vendor that touches ePHI — your cloud provider, your logging stack, your email relay, your analytics, your LLM API — must sign a BAA and must themselves meet the Security Rule. If OpenAI or Anthropic will not sign a BAA for the tier you use, that call path cannot process ePHI.

What the Security Rule demands of the architecture

The Security Rule's Technical Safeguards live in §164.312 and break into five standards. Treat the list below as the minimum evidence an auditor will ask for, not a definition.

1. Access control (§164.312(a))

Every person and every service account that can reach ePHI must have a unique identifier. Shared admin logins, service accounts written into config files, and "break-glass" accounts used by multiple engineers all fail here. The system must also enforce automatic logoff after a period of inactivity — a session timeout implemented in the application layer, not just an idle warning banner — and must have an emergency access procedure that lets authorised staff reach ePHI during a system failure, with that access itself logged.

Encryption of ePHI at rest is listed as "addressable" under the current rule but is treated as mandatory in practice by every auditor, and the January 2025 NPRM (90 FR 898) proposes to remove the addressable designation entirely and make encryption, MFA, semi-annual vulnerability scans, and annual penetration tests unambiguous requirements. Build to that standard now; retrofitting after procurement review is brutal.

2. Audit controls (§164.312(b)) — the most-failed standard

This is the single requirement that trips the most well-intentioned teams. The standard requires "hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information." In practice an auditor expects:

• A log entry for every read, write, update, delete, export, and print of ePHI, not just login/logout events
• Each entry stamped with user identity, timestamp (to the second, in UTC), action taken, and the specific record or record set touched
• Logs that are tamper-evident — write-once storage, cryptographic chaining, or shipped in real time to a separate account/tenant that the application's own operators cannot modify
• Retention for at least six years, queryable within a reasonable window
• Evidence that someone actually reviews the logs on a defined cadence — alerts, dashboards, documented review meetings

OCR has cited Banner Health, Oklahoma State University, and Lifetime Healthcare in recent years specifically for failing to implement and review these logs. Montefiore was fined $4.75 million for essentially the same gap. If your team cannot, in a ten-minute live demo, pull up every action taken against patient record #12345 over the last three years, you will fail.

3. Integrity (§164.312(c))

The system must be able to show that ePHI has not been altered or destroyed in an unauthorised manner. This usually means checksums or hashes on stored records, versioned storage, and database-level audit trails that distinguish a legitimate clinical edit from a tampering event. If your EHR integration overwrites records in place without versioning, you have a problem.

4. Person or entity authentication (§164.312(d))

Multi-factor authentication is not optional for any user or admin who can reach ePHI. The Change Healthcare breach — which exposed more than 190 million patient records and cost over $2.8 billion — started with stolen credentials used against a Citrix portal with no MFA. The January 2025 NPRM would make MFA explicitly mandatory; buyers and auditors already treat it that way.

5. Transmission security (§164.312(e))

TLS 1.2 or higher for every network hop that carries ePHI, including internal service-to-service calls. End-to-end encryption, not just edge termination at a load balancer. Email containing ePHI must be encrypted or routed through a secure messaging channel — plain SMTP to a clinician's inbox is a violation.

The administrative safeguards that have architectural consequences

The Administrative Safeguards (§164.308) are often filed as "policy work" but three of them force architectural decisions:

• Risk analysis (§164.308(a)(1)(ii)(A)) — a documented, system-specific threat model covering every place ePHI lives, moves, or could be inferred. Generic ISO 27001 risk registers do not satisfy this.
• Contingency plan (§164.308(a)(7)) — tested backup, disaster recovery, and emergency mode operation procedures. The auditor will ask when you last restored from backup and whether the restore was verified against ePHI integrity.
• Information system activity review (§164.308(a)(1)(ii)(D)) — proof that someone looks at the audit logs on a regular cadence. Logs no one reads are not compliance; they are a liability.

What this demands of the vendors you hire

Every sub-processor that touches ePHI must sign a BAA and must itself meet the Security Rule. Practical implications for a typical digital health stack:

• Cloud provider: AWS, Azure, and GCP all offer BAAs, but only for a defined subset of their services. Running ePHI through a service not on that list voids the BAA. Check the HIPAA-eligible services list for your provider on the day you design the architecture, not the day before audit.
• LLM and AI APIs: OpenAI, Anthropic, and Google all offer BAA-eligible paths now, but typically only on enterprise tiers and with specific data-handling settings. A developer who drops a free-tier API key into a prototype has just created a reportable incident if real ePHI flowed through it.
• Observability, logging, analytics, feature flags, customer support tools: each needs a BAA or must be architecturally prevented from receiving ePHI. PII-scrubbing at the edge is a defensible pattern; hoping developers remember not to log patient names is not.
• Development partner: if you outsource build or modernisation, the firm handling the code and (critically) any test data derived from real ePHI is a business associate. They must sign a BAA, must have their own Security Rule controls on their development environment, and must be able to produce their own audit logs.

How long readiness takes and what drives it

There is no honest universal number. Readiness time is driven by five variables that compound:

1. Starting posture. A greenfield build designed around the Security Rule from day one is dramatically faster than retrofitting a two-year-old platform that logs inconsistently and shares service accounts. Retrofitting audit logging alone — instrumenting every ePHI read/write across an existing codebase, backfilling a tamper-evident log pipeline, and proving six-year retention — is often the longest single workstream.
2. Scope of ePHI. How many services touch it, how many integrations carry it, how many third parties process it. A platform with one EHR integration and no analytics stack is a different project to one with FHIR connections to five health systems, an ML inference pipeline, and a clinician mobile app.
3. Cloud and vendor choices. If your current stack contains services your cloud provider will not cover under a BAA, migration time dominates the schedule.
4. Which assurance the buyer actually wants. "HIPAA compliant" is a self-attestation; a third-party HIPAA assessment or a HITRUST certification adds months and is often what enterprise buyers really mean.
5. Whether you need SOC 2 Type II alongside. Most US enterprise health buyers ask for both. Doing them together is cheaper than doing them sequentially but front-loads the work.

Illustrative only: a UK scaleup with a single-tenant SaaS platform, one EHR integration, no existing ePHI in production, an ISO 27001-certified baseline, and a willing cloud provider typically treats HIPAA readiness as a multi-quarter programme rather than a sprint, with audit logging, MFA rollout, BAA chasing, and risk analysis consuming the bulk of the calendar. Every one of those assumptions changes the number materially. To turn this into a real estimate, three specifics matter most: (a) how many services and integrations touch ePHI today, (b) whether your current cloud services are all BAA-eligible, and (c) whether the buyer wants self-attestation, third-party assessment, or HITRUST. A scoping conversation with a team that has done this before will collapse the range quickly.

Nothing in this post is legal advice. HIPAA interpretation is fact-specific and your counsel or a qualified HIPAA auditor should review your specific architecture, contracts, and data flows before you represent the system as compliant to a customer or investor.

The three things teams discover far too late

1. Audit logs were never designed in. The system logs errors and HTTP requests but has no concept of "ePHI access events" as first-class, tamper-evident records. Retrofitting this means instrumenting every data-access path, standing up a separate log sink your own operators cannot write to, and backfilling historical gaps you cannot actually backfill. Build it in on day one or accept a long remediation.

2. The LLM path leaks ePHI into a non-BAA vendor. A feature was prototyped against a free-tier API, telemetry was enabled, and patient-identifiable prompts flowed to a third party with no BAA. This is not just a compliance finding; under the Breach Notification Rule it can trigger reporting obligations to HHS and to every affected individual. Gate ePHI at the architecture level — tokenisation, de-identification, or routing only through BAA-covered endpoints.

3. The regulatory floor is rising mid-project. The January 2025 NPRM would eliminate the "addressable" distinction, mandate encryption at rest and in transit, mandate MFA, require semi-annual vulnerability scans and annual penetration tests, and tighten incident response timelines. Teams building to the 2003-era rule are building to a standard their buyers and auditors already consider obsolete. 41% of healthcare organisations admit to only partial Security Rule safeguards today — that gap closes forcibly when the rule finalises.

How CodeNicely can help

Our most relevant engagement for this problem is HealthPotli, an e-pharmacy platform where we built the clinical workflow, prescription handling, and AI drug-interaction checks from the ground up — which meant designing access controls, audit trails, and PHI-handling boundaries into the architecture rather than bolting them on. The patterns that engagement proved out — tamper-evident access logging keyed to individual patient records, BAA-safe routing for AI calls, role-based access that survives audit — are exactly what a UK digital health platform needs to put in front of a US enterprise buyer or US investor.

Where we are useful to a CPO or CTO in your position is in the scoping and remediation phase: a focused technical assessment of where your current architecture meets the Security Rule, where it does not, and what the shortest credible path to readiness looks like given your product roadmap and the specific assurance your buyer wants. We do this as a defined engagement, with full IP ownership staying with you, and we work alongside (not instead of) your HIPAA auditor and your US counsel.

The bottom line

HIPAA is an architecture requirement. A BAA and a policy binder are necessary and nowhere near sufficient. The Security Rule asks specific, auditable questions of the running system — who touched which record, when, under what authentication, with what encryption, and can you prove it six years from now — and in 2024 the fines for failing those questions got materially bigger. Design for the January 2025 proposed rule rather than the 2003 one, treat audit logging as a first-class product feature rather than an ops afterthought, and make sure every vendor in the ePHI path has signed a BAA before a single real patient record touches your system. The buyer who just put HIPAA in your contract will ask for evidence, not assurances.

Frequently Asked Questions

Does HIPAA apply to a UK company that has no US entity?

Yes, if your software processes ePHI on behalf of a US covered entity or another business associate. Under the HITECH Act, business associates are directly liable regardless of where they are incorporated. Your UK GDPR compliance does not satisfy HIPAA, and HIPAA does not satisfy UK GDPR — you will need to meet both, which overlaps meaningfully on security but diverges on data subject rights and breach notification.

Is ISO 27001 or SOC 2 enough to pass a HIPAA audit?

No. They overlap significantly with HIPAA's administrative safeguards, but HIPAA's technical safeguards — specifically the audit control standard §164.312(b), emergency access, and the six-year log retention requirement — go beyond what ISO 27001 mandates. Most US enterprise health buyers ask for SOC 2 Type II and HIPAA assurance, often alongside HITRUST, and the smart move is to scope all three together rather than sequentially.

How much does HIPAA readiness cost and how long does it take?

Honestly, there is no universal number. The cost and timeline are driven by how much ePHI your system touches today, how many of your current cloud services and third-party vendors are BAA-eligible, how much audit-logging retrofit your codebase needs, and whether the buyer wants self-attestation, a third-party assessment, or HITRUST certification. The single biggest cost driver is usually retrofitting tamper-evident audit logging across an existing platform. To turn the range into a real estimate, a scoping call that inventories your ePHI data flows, your current vendors, and your buyer's specific assurance requirement is the fastest path.

Can we use OpenAI, Anthropic, or other LLM APIs with patient data?

Only on enterprise tiers that offer a signed BAA, and only with the specific data-handling settings (no training on your data, zero data retention where available) that the BAA requires. Free tiers and standard commercial tiers do not qualify. The safer architectural pattern is to de-identify or tokenise ePHI before it reaches any LLM, so the AI call path never carries identifiable data in the first place.

What is the single most common HIPAA audit failure?

The absence of tamper-evident audit logs that can name every user who accessed a specific ePHI record and when. The Montefiore $4.75 million settlement, the Banner Health enforcement action, and multiple others all turned on this gap. Login/logout logs do not satisfy §164.312(b) — the standard requires per-record access events, retained for six years, with evidence that someone reviews them.