Building HIPAA-compliant healthcare software in 2026

HIPAA-compliant healthcare software in 2026 is the operating posture, contracts, and technical controls that satisfy the HIPAA Privacy Rule (45 CFR Part 164 Subpart E), the Security Rule (45 CFR Part 164 Subpart C), and the Breach Notification Rule (45 CFR Part 164 Subpart D) when Protected Health Information (PHI) moves through your product. It is not a certification. It is a continuous posture, backed by a Business Associate Agreement (BAA) with every PHI-touching vendor in your subprocessor chain, technical safeguards mapped to 45 CFR 164.312, and administrative safeguards mapped to 45 CFR 164.308. After the HHS Office for Civil Rights published its Notice of Proposed Rulemaking on the Security Rule on 27 December 2024, most addressable safeguards moved to required status, and the procurement perimeter for carriers, hospitals, healthcare enterprises, ISVs, and growth-stage founders tightened in the same direction.

This article is the long-form 2026 pillar. It covers the HIPAA refresher, the post-NPRM Security Rule, the BAA chain and HIPAA-eligible cloud services, technical safeguards mapped to 45 CFR 164.312, administrative safeguards under 45 CFR 164.308, the orchestration gap that Jan-Felix Schneider of Health Tech Nerds has named, the procurement-readiness gaps that show up in vendor questionnaires, an FAQ, and where Life Value sits in this stack.

HIPAA refresher: the three rules and the 2024 NPRM

HIPAA is one statute and three implementing rules. Treating them as one thing is the first source of confusion in procurement reviews.

The Privacy Rule (45 CFR Part 164 Subpart E) governs when and how PHI can be used or disclosed, including the minimum-necessary standard, individual access rights, and the Notice of Privacy Practices. Source: HHS, 45 CFR §§ 164.500 to 164.534.

The Security Rule (45 CFR Part 164 Subpart C) covers the administrative, physical, and technical safeguards around electronic PHI (ePHI). It is the rule healthcare software teams spend most of their time inside. Source: HHS, 45 CFR §§ 164.302 to 164.318.

The Breach Notification Rule (45 CFR Part 164 Subpart D) sets the obligations when something goes wrong, including notice to affected individuals, notice to the Secretary, and, for breaches affecting 500 or more individuals, notice to prominent media. Source: HHS, 45 CFR §§ 164.400 to 164.414.

The 2013 Omnibus Rule pulled business associates and their subcontractors directly into the regulatory perimeter. That is the part most healthcare ISVs and growth-stage founders still underestimate. If your software touches PHI on behalf of a covered entity, you are a business associate. Every vendor in your stack that touches PHI is then your subcontractor under HIPAA, whether or not they think of themselves that way. Source: HHS Omnibus Final Rule, 78 Fed. Reg. 5566, 25 January 2013.

The 2024 NPRM on the Security Rule is the most consequential update in over a decade. HHS OCR proposed moving most addressable safeguards to required status, mandating multi-factor authentication on systems handling ePHI, requiring asset inventories and network maps, and setting a 72-hour breach response expectation for restoring affected systems. Source: HHS OCR, HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information, 89 Fed. Reg. 101740, 27 December 2024.

Two other federal updates sit alongside the NPRM. CMS-0057-F, the Interoperability and Prior Authorization Final Rule, finalized on 17 January 2024, created new FHIR R4 API obligations for payers (Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization APIs) with most provisions effective 1 January 2026. Source: CMS-0057-F, 89 Fed. Reg. 8758. And 2024 OCR enforcement actions against covered entities and business associates totaled in the tens of millions of dollars in resolution payments, with a meaningful share against small business associates. Source: HHS OCR Resolution Agreements and Civil Money Penalties, 2024.

The 2026 perimeter: BAA chain, subprocessor map, HIPAA-eligible cloud services, audit logging

The single most useful artifact a HIPAA-compliant team owns in 2026 is a written subprocessor map: every service that can touch PHI, the BAA status with that service, the HIPAA-eligible service list it draws from, and the audit-log destination for events that service emits. Procurement teams at carriers and hospitals ask for this map directly. Without it, the security questionnaire turns into a six-week archaeology project.

The BAA chain

A BAA is a contract that splits liability between a covered entity and a business associate, or between a business associate and its subcontractor. It is required under 45 CFR § 164.502(e) and 45 CFR § 164.504(e). A BAA is not a green light. It does not absolve the business associate of responsibility for the technical safeguards on its end. It allocates obligations and remedies if PHI is disclosed in violation of the agreement.

Every vendor downstream of you that can touch PHI needs a BAA in place before the first byte flows. The list is longer than most teams expect: cloud infrastructure (AWS, Google Cloud, Microsoft Azure), observability (Datadog, New Relic, Sumo Logic, Honeycomb), communications (Twilio, SendGrid, Postmark), AI inference (Anthropic via AWS Bedrock or direct enterprise contracts, OpenAI via Azure OpenAI Service, Google via Vertex AI), error tracking (Sentry, Rollbar), and product analytics that processes session data with potential PHI.

HIPAA-eligible cloud services

The three major US hyperscalers all publish HIPAA-eligible service lists and will sign BAAs. The lists are not identical to the full product catalog. A service that is not on the eligible list cannot lawfully process PHI, even with a BAA in place. Sources: AWS HIPAA Eligible Services Reference; Google Cloud HIPAA Compliance product list; Microsoft Azure HIPAA BAA-covered services list.

AWS added Anthropic models on AWS Bedrock to its HIPAA eligibility list in 2024, which made Bedrock the first major US-region BAA-eligible path to Claude inference for PHI workloads. Sources: AWS Compliance, HIPAA Eligible Services Reference, 2024 updates; AWS Bedrock service documentation.

Audit logging

Audit controls are required under 45 CFR § 164.312(b). The control is short. The implementation is not. Audit logs need to record who accessed which PHI records, when, from which session, and what action was taken. Logs need tamper-evidence (hash-chained storage, write-once buckets, or a SIEM with cryptographic integrity), retention aligned to the covered entity's documented policy, and a destination that itself sits inside the HIPAA perimeter.

The most common audit-log failure mode in 2026 is logs that escape the perimeter. An engineer adds a new observability tool, the application starts streaming structured logs to it, a stack trace serializes a patient identifier, and the log now lives in a service that does not have a BAA. The fix is to enforce log-destination policy in infrastructure-as-code, scrub structured logs at the source, and review subprocessor changes the same way you review architecture changes.

Technical safeguards mapped to 45 CFR 164.312

The Security Rule's technical safeguards live in 45 CFR § 164.312. There are four standards. Each has implementation specifications. Mapping a healthcare product against this section is the most efficient way to find gaps before a vendor questionnaire does.

164.312(a) Access control

Required: unique user identification, emergency access procedure, automatic logoff, encryption and decryption of ePHI at rest.

In practice: SSO via SAML 2.0 or OpenID Connect (OIDC), no shared accounts, role-based access control (RBAC) with enforced least privilege, session timeouts shorter than the device's screen lock, AES-256 for ePHI at rest in databases, object stores, backups, and disk volumes, and a documented break-glass account procedure with separate credentials and high-volume audit.

164.312(b) Audit controls

Required: hardware, software, and procedural mechanisms that record and examine activity in information systems that contain or use ePHI.

In practice: tamper-evident audit logs, a SIEM (Splunk, Sumo Logic, AWS Security Lake, Microsoft Sentinel, Elastic Security) with retention aligned to the documented policy, alert rules for anomalous PHI access patterns, and quarterly access reviews tied to HR records for active workforce.

164.312(c) Integrity

Required: protection of ePHI from improper alteration or destruction.

Implementation specification: a mechanism to authenticate ePHI (addressable, now effectively required under the NPRM).

In practice: hash-based integrity checks on backups and transmitted records, signed FHIR Bundles where possible, write-once storage for archived records, and immutable backups via object-lock or vaulted snapshots.

164.312(d) Person or entity authentication

Required: procedures to verify that a person or entity seeking access to ePHI is the one claimed.

In practice: MFA on every account that can read PHI (NPRM makes this explicitly required), service-to-service authentication via signed JWTs, mutual TLS for sensitive integrations, and Substitutable Medical Applications and Reusable Technologies (SMART) on FHIR for app-to-EHR authentication and authorization.

164.312(e) Transmission security

Required: technical security measures to guard against unauthorized access to ePHI being transmitted over an electronic communications network.

Implementation specifications: integrity controls and encryption.

In practice: TLS 1.2 minimum, TLS 1.3 where supported, no PHI in URLs or query strings, no PHI in third-party analytics events, CDN configurations that never cache PHI-bearing responses, and a checked policy that re-validates after every integration change.

Administrative safeguards under 45 CFR 164.308

Technical safeguards get most of the engineering attention. Administrative safeguards, under 45 CFR § 164.308, are the ones procurement teams actually review during a vendor security assessment.

Workforce training

Required under 45 CFR § 164.308(a)(5). Every workforce member with access to ePHI receives security awareness training at hire and on a recurring basis. The 2024 NPRM tightens cadence expectations and asks for evidence per workforce member, not aggregate attendance.

Contingency planning

Required under 45 CFR § 164.308(a)(7). Data backup plan, disaster recovery plan, emergency mode operation plan, plus testing and revision procedures. The NPRM proposes a 72-hour expected restoration window for systems containing ePHI, which has the practical effect of forcing a tested runbook and not just a documented one.

Incident response

Required under 45 CFR § 164.308(a)(6) as security incident procedures. In practice: a documented incident response plan, named roles (incident commander, comms lead, forensic lead, legal lead), a tested runbook with at least one tabletop exercise per year, and a notification timeline that matches the Breach Notification Rule's 60-day outer bound for individual notice under 45 CFR § 164.404, plus the 72-hour restoration expectation from the NPRM.

Risk analysis and risk management

Required under 45 CFR § 164.308(a)(1). The risk analysis is a living document, reviewed when the architecture changes, not once a year as a CYA exercise. OCR settlements in 2023 and 2024 repeatedly cited inadequate or stale risk analysis as the root finding. Source: HHS OCR Resolution Agreements 2023 to 2024.

The orchestration gap: why most healthcare orgs cannot assemble the HIPAA stack alone

Jan-Felix Schneider, a frequent contributor to the Health Tech Nerds (HTN) community, has framed what he calls the orchestration gap: healthcare organizations are not buyers of microservices. Carriers, hospital systems, established healthcare companies, and growth-stage healthtech teams lack the engineering bench to stitch together Redox, Particle Health, Health Gorilla, Candid Health, MedPlum, Aptible, Verifiable, Eligible, and Vanta into a coherent, audit-ready product. Each individual vendor is well-built. The composition is the missing capability. Source: Jan-Felix Schneider, Health Tech Nerds community posts on the orchestration layer, 2024 to 2025.

The orchestration gap matters for HIPAA because the BAA chain, the subprocessor map, the audit-log topology, and the FHIR integration surface are all composition problems, not single-vendor problems. A hospital integrated delivery network can buy every component on the market and still not have HIPAA-compliant healthcare software, because the integrations are where the perimeter leaks. The team that closes the orchestration gap on a project is, in practice, the team that owns the HIPAA posture for that product.

This is also where the architecturally honest patient-mediated exchange model that Brendan Keeler has called the alternative to the PHR tarpit sits. Patient-held records via TEFCA-certified pathways, instead of vendor-locked patient portals, push more of the PHI control surface to the individual and reduce the surface area covered entities and business associates have to defend. HealthWallet.me, the open-source patient-held EHR maintained by Life Value, takes that route: FHIR R4 native, encrypted on device, biometric authentication, TEFCA-certified via the Fasten Health on-prem partnership connecting more than 50,000 US health systems and 78 percent of US hospital beds. Sources: HealthWallet.me project documentation; Fasten Health OnPrem coverage statistics, 2025.

Common procurement-readiness gaps

Five patterns show up in almost every vendor security questionnaire response that stalls a sales cycle by six weeks or more.

1. No subprocessor map. The team can name AWS and a few other vendors but cannot produce the full BAA-status list. Procurement teams ask for this verbatim.
2. Stale risk analysis. The last risk analysis predates the current architecture by 12 to 24 months. OCR considers this the canonical Security Rule failure.
3. Audit logs outside the perimeter. Application logs stream to a service without a BAA. The fix is destination policy in infrastructure-as-code plus log scrubbing at source.
4. Consumer LLM endpoints in production paths. PHI prompts hit chat.openai.com, claude.ai, or gemini.google.com. The fix is a routed inference layer pointed at BAA-eligible endpoints (Anthropic on AWS Bedrock or direct enterprise, OpenAI on Azure OpenAI Service, Google on Vertex AI), with de-identification on the way in and audit capture on the way out.
5. Stacking compliance theater on top of weak security. SOC 2 Type II and ISO/IEC 27001:2022 are useful and often requested. They do not substitute for the HIPAA Security Rule controls. The right sequence in 2026 is HIPAA controls at build, SOC 2 Type II in year one or two, HITRUST when an enterprise customer demands it.

A practical signal during partner selection: ask the engineering lead to walk through the last incident response drill. A team that has personally configured AWS or Google Cloud for HIPAA workloads, run a tabletop exercise, and produced a postmortem in the last 12 months will answer this in under five minutes. A team that cannot will get vague. That is information.

Frequently asked questions

What is HIPAA-compliant software?

HIPAA-compliant software meets the technical, administrative, and physical safeguards required by the HIPAA Security Rule when handling PHI, plus the Privacy Rule and Breach Notification Rule obligations. It is not a certification. It is a continuous operating posture, supported by a Business Associate Agreement with every PHI-touching vendor in the subprocessor chain.

Do I need a BAA with my cloud provider?

Yes. AWS, Google Cloud, and Microsoft Azure each publish HIPAA-eligible service lists and will sign BAAs. Without a signed BAA in place before PHI flows, you are not HIPAA-compliant regardless of how the cloud is configured. Source: AWS, Google Cloud, and Microsoft Azure HIPAA compliance documentation.

What changed in the HIPAA Security Rule in 2024 to 2026?

The December 2024 NPRM proposed moving most addressable safeguards to required status, making MFA mandatory on systems with ePHI access, requiring asset inventories and network maps, and setting a 72-hour restoration expectation for systems affected by an incident. CMS-0057-F separately created new FHIR R4 API obligations for payers, with most provisions effective 1 January 2026. Sources: HHS OCR NPRM, 89 Fed. Reg. 101740, 27 December 2024; CMS-0057-F, 89 Fed. Reg. 8758, 17 January 2024.

How do you handle PHI in a large language model?

Use a BAA-eligible endpoint: Anthropic on AWS Bedrock or via direct enterprise contracts, OpenAI through Azure OpenAI Service, Google through Vertex AI on Google Cloud. De-identify the data before it goes to the model, capture the input and output in your audit log, and never route PHI to consumer chat endpoints. Sources: AWS Bedrock HIPAA eligibility, 2024; Microsoft Azure OpenAI Service HIPAA BAA coverage; Google Cloud Vertex AI HIPAA compliance.

Is SOC 2 the same as HIPAA?

No. SOC 2 demonstrates the security and availability of a service organization against the AICPA Trust Services Criteria. HIPAA is a federal regulation. They overlap but the controls and the obligations are different. Carriers, hospitals, and enterprise buyers often ask for both, plus ISO/IEC 27001:2022 for international deployments.

Where Life Value sits in this

Life Value works in the orchestration layer Schneider has described. The team carries HIPAA, GDPR, HL7 FHIR R4, ISO 13485, and ISO/IEC 27001:2022 credentials, ships into 15-plus countries, and runs two pillars that map directly to this article. The HealthTech Consulting pillar covers the architecture, BAA chain, and FHIR integration surface for carriers, hospital systems, established healthcare companies, ISVs, and growth-stage healthtech teams. The Infrastructure and Security pillar covers the technical safeguards mapped to 45 CFR 164.312, the audit-log topology, and the procurement-ready evidence pack. Both feed into the open-source work on HealthWallet.me and the Fasten Health OnPrem aggregator that connects more than 50,000 US health systems.

If you are a payer, a public health system, a private hospital or integrated delivery network, an established healthcare company, an ISV, or a growth-stage founder, the question to answer in 2026 is the same: does your subprocessor map, your BAA chain, and your 45 CFR 164.312 mapping survive a procurement review without a rebuild. If the answer is unclear, a 30-minute architecture review is the cheapest way to find out. Book a HIPAA architecture review with Life Value.