HIPAA-Compliant Software in 2026: What Actually Makes One, Vendor Comparison, and the AI Complication

Three developments since 2023 made the “is this software HIPAA-compliant?” question harder to answer. The proposed December 2024 NPRM would require mandatory encryption at rest, mandatory MFA, mandatory annual pen testing, and a 72-hour breach response window, upgrading several previously “addressable” safeguards to required ones. 

The EU AI Act’s high-risk obligations created a second compliance layer for US healthcare organisations serving EU patients. 

And the LLM wave introduced a new category of risk: protected patient data processed by AI APIs. 

This article covers what actually makes software HIPAA-compliant, the 5 technical conditions that matter in 2026, the AI complication in detail, and an honest comparison of 8 vendors across clinical team chat and embedded patient communication use cases.

In this article 

• What HIPAA-compliant software actually means 
• The 5 technical conditions + 2024 NPRM updates
• The AI complication: ChatGPT, LLMs, and HIPAA 
• 8 vendors honestly compared 
• Ethora: embedded patient chat + AI SDK

What “HIPAA-Compliant Software” Actually Means

There is no “HIPAA-certified software” – the Department of Health and Human Services doesn’t certify vendors. But the HIPAA Security Rule requires technical safeguards, and vendors must sign a BAA (Business Associate Agreement) for the specific service you use. HIPAA-compliant software means end-user applications – a messaging app, video, patient portals – built so they can be used in HIPAA-covered workflows without creating violations.

The compliance obligation sits with the covered entity – the hospital, clinic, health plan, or healthcare clearinghouse – not with the vendor. A vendor can be BAA-eligible and have all the right encryption configurations; if the covered entity doesn’t implement proper access controls, train staff, or execute a risk analysis, the deployment is still non-compliant. Vendors are business associates under HIPAA, sharing in the obligation through the BAA. But the primary responsibility is yours.

The 5 Technical Conditions That Actually Matter in 2026

These conditions help you ensure HIPAA compliance. They work together – you can’t skip one. 

Signed BAA for the specific SKU you’re using

A BAA is the legal contract between a covered entity and a business associate that defines each party’s obligations for handling ePHI (electronic protected health information). Every vendor that handles ePHI (whether it’s a chat provider, cloud host, or anyone else) needs a signed BAA before any patient data flows through their system. 

Usually, vendors sign BAAs on Enterprise plans, and lower-tier plans exclude BAA coverage. If you’re on a Starter plan and haven’t verified whether it includes a BAA, check now. A deployment on a tier that excludes BAA coverage is non-compliant regardless of how good the encryption is.

Encryption

Under the current 2013 Security Rule, encryption is “addressable” – meaning a covered entity can choose not to implement it if they document a reasonable alternative. The December 2024 NPRM proposes making both at-rest and in-transit encryption required, not addressable. The direction is clear: building to the NPRM standard now is the low-risk approach. 

For HIPAA-compliant messaging specifically: AES-256 at rest (customer-managed keys where feasible – vendor-managed keys still pass the standard but give you less audit control), TLS 1.3 in transit, applied to chat messages, attachments, user profiles, and audit logs. For HIPAA-compliant video chat: WebRTC uses SRTP for media in transit. HIPAA doesn’t require true end-to-end encryption – encryption through an SFU is sufficient – but recordings stored server-side must be encrypted at rest.

Access controls (RBAC + MFA + automatic logoff)

HIPAA requires role-based access control with time-limited grants, audit per access event, and automatic session logoff. Users should see the “necessary minimum” – only the information required for their role. 

The 2024 NPRM would make MFA mandatory for privileged access (currently “addressable”). OAuth 2.0 + SAML for SSO, WebAuthn or FIDO2 for MFA, and short idle timeouts (15 minutes is common in clinical environments) are the 2026 implementation pattern.

Audit trail 

You should use software and hardware, as well as implement procedural mechanisms to record and examine activity in systems that contain ePHI. This means you should record:

• Every login 
• Every access to PHI (message read, patient search, etc.)
• Any action with PHI (messages sent, attachments uploaded, start and end of video sessions)
• Failed attempts to access information 

These records should include:

• User ID
• Timestamp
• IP address
• Device identifier

This data should be retained for a minimum of 6 years (in some states longer) and stored immutably: append-only stream, WORM storage, or cryptographic hashing to detect tampering.

Physical and operational safeguards 

Data must reside in a HIPAA-eligible environment. AWS, Azure, and GCP all offer HIPAA-eligible services under their respective BAAs – but “HIPAA-eligible” means the specific service is covered under the BAA, not that all services automatically qualify. AWS maintains a HIPAA-eligible services reference list; verify your specific services are on it. 

On-premises deployment is still common in hospital IT environments – roughly half of hospital software deployments remain on-prem – for teams where IT policy doesn’t permit third-party cloud BAAs for primary patient data.

2024 NPRM – 6 additional proposed requirements 

The December 2024 NPRM goes beyond the five conditions above. It proposes: mandatory vulnerability scanning, mandatory annual penetration testing, mandatory patch management with 48-hour critical patch windows, mandatory 12-month risk analysis and response cycles, a 72-hour incident response requirement (down from 60 days for breach notification), and mandatory technical controls for network segmentation. The NPRM is proposed, not final – but building to this standard now avoids a compliance retrofit when it finalises.

The AI Complication: ChatGPT, LLMs, and HIPAA

The question “is ChatGPT HIPAA-compliant?” generates enormous search volume because the answer is neither obvious nor consistent across products. Here’s the breakdown.

Consumer ChatGPT

This includes chat.openai.com, ChatGPT Plus, and ChatGPT Team and is not HIPAA-compliant. OpenAI explicitly excludes these products from BAA coverage. A patient message sent to the consumer ChatGPT interface is a HIPAA violation if it contains PHI – full stop. The same applies to the standard consumer Claude interface. 

Azure OpenAI Service

With a Microsoft BAA, it is HIPAA-compliant for the specific models covered under the BAA (GPT-4o, GPT-4o-mini, and GPT-5 are all covered as of mid-2026). The Microsoft Azure BAA is a standard commercial agreement available without an enterprise negotiation. Anthropic’s enterprise API with a signed BAA is also compliant; a BAA is available on request from Anthropic directly, or via Amazon Bedrock (which covers Anthropic’s models under the AWS BAA).

Self-hosted open-weights models

Self-hosted models meet HIPAA compliance requirements because no PHI leaves your infrastructure – there’s no third party involved, so no BAA is required. Llama 3.3 70B, Mistral Large, and Meditron-70B (EPFL’s medical-fine-tuned Llama variant) all run on 4× A100 80GB hardware at roughly €3,000-6,000/month cloud infrastructure costs. Yet there’s an ops burden: you’ll need to manage inference infrastructure, model updates, and latency monitoring. But for hospital systems where data sovereignty is a hard requirement, self-hosting eliminates the BAA dependency on LLM providers. 

The most practical approach is the combination of self-hosted models used for high-traffic operations (like scheduling, patient education, FAQs), and sending complex clinical queries to BAA-covered Azure OpenAI or Anthropic enterprise APIs. Both systems can provide HIPAA-compliant operations, but you need to appropriately distribute the complexity of the question and MLOps capabilities between them.

Even with a BAA, verify API data-retention and training-use policies for your specific tier. Enterprise API terms typically differ from consumer tiers. Self-hosting removes this ambiguity entirely.

EU AI Act overlap 

For US healthcare organisations serving EU patients, AI used for medical triage, diagnosis-adjacent tasks, or treatment recommendations is high-risk under EU AI Act Annex III – enforcement took effect August 2, 2026. High-risk classification requires conformity assessment, technical documentation, human oversight mechanisms, and Article 12 record-keeping per AI interaction. HIPAA audit trail requirements and EU AI Act Article 12 overlap, but they’re not identical – you need both. A self-hosted stack on an EU sovereign cloud (OVHcloud, Scaleway) with a BYO EU LLM (Mistral Large) is the architecture that satisfies both simultaneously. See the EU digital sovereignty guide for the detailed stack.

8 Vendors Honestly Compared

Before choosing the vendor, you need to know which category your product falls into. Two different use cases are often confused: clinical communication (provider-to-provider or internal team communication) and embedded patient-facing software (patient portals, telehealth apps, or a chat within your product). Before choosing the vendor, you need to know which category your product falls into.

Ethora · Embedded SDK · Patient-facing · AI 

Purpose-built to embed chat, AI, and video inside your patient-facing product – not as a standalone team-chat replacement. React, React Native, iOS, Android, Node.js, and Python SDKs. HIPAA-eligible with a BAA at the Enterprise tier. Audit trail native per chat message and video session, satisfying both HIPAA §164.312(b) and EU AI Act Article 12 requirements in the same log. 

BYO LLM via the AI Bots SDK for medical assistants: Azure OpenAI with BAA, Anthropic enterprise, or self-hosted Llama 3.3 – configurable without changing application code. RAG Crawler indexes your patient education library and clinical protocols so the AI assistant answers from your verified content rather than general training data. Dr. Talks, a HIPAA-compliant medical AI assistant, is built on Ethora’s self-hosted stack.

Rocket.Chat Open source · Team chat first

This product is targeted at internal clinical communication – nurse-physician handoffs, on-call coordination, departmental channels. BAA on the Enterprise plan. ISO 27001, SOC 2. WCAG 2.1 Level AA accessibility. If your requirement is a HIPAA-compliant internal team communication platform with strong open-source provenance, Rocket.Chat is a serious option. 

Where it doesn’t fit: it’s a team-chat replacement, not an embeddable SDK. Integrating Rocket.Chat’s UI inside a third-party patient portal requires substantially more engineering than using a purpose-built embedded chat SDK. MongoDB stack ops at scale needs real DevOps capacity. Per-user pricing on Enterprise compounds at hospital-system headcount. AI features are add-ons rather than native modular components.

TigerConnect · Clinical workflows

Purpose-built for clinical communication – on-call scheduling, shift handoffs, alarm management, nurse-physician secure messaging. HIPAA-ready with a BAA on all clinical plans. SOC 2. The product assumes your users are clinicians communicating with each other; it doesn’t try to be a patient-facing portal or an embeddable SDK. 

Per-user pricing. Proprietary. Not suitable for embedding inside a third-party product. If you need clinical team communication with scheduling and workflow integrations, TigerConnect is a credible choice. If you need patient-facing chat with AI capabilities inside your telehealth app, it’s the wrong tool.

Spok · Legacy paging replacement

The dominant paging-replacement vendor for hospital systems still running dedicated pager infrastructure. Secure messaging for healthcare in legacy environments, on-call directory integration, escalation workflows. HIPAA-ready. For hospitals migrating off dedicated pagers to smartphone-based secure messaging, Spok is the established path. For teams building new patient-facing software or AI-enabled care coordination, it’s outside the relevant category.

Wickr (AWS) · FedRAMP High · Defense-grade

FedRAMP High and DoD IL5 authorized. Strong encryption model. HIPAA-ready under the AWS BAA. Product roadmap has been uncertain since acquisition – AWS has not invested heavily in Wickr’s healthcare-specific feature development. For teams that need the FedRAMP High authorization specifically, Wickr is sometimes the required choice. For general healthcare HIPAA compliance without federal authorization requirements, other options have cleaner roadmaps.

Element (Matrix) · Open source · Federated E2EE

Protocol-level federation means independent health systems can communicate without a central authority – relevant for multi-hospital-system deployments and for organizations that need inter-institutional secure messaging without sharing infrastructure. E2EE via Olm/Megolm (MLS migration underway). Used by several European government health ministries and the German Bundeswehr. Element Server Suite includes BAA coverage for self-hosted deployments; the open-source community edition requires you to be the covered entity operating your own infrastructure. 

Synapse (the Python homeserver) is resource-intensive at scale; Dendrite (Go) is newer and leaner but less battle-tested. UX is less polished than TigerConnect or Rocket.Chat for clinical users unfamiliar with federated messaging concepts. Best fit: multi-institution deployments, European healthcare organisations, teams with strong DevOps capacity who value open-source and federation.

Doximity Dialer + Doximity Chat · Physician network

Physician-to-physician and physician-to-patient communication (via masked phone number for Dialer). HIPAA-ready with BAA. Free for physicians. The network value is substantial for any product targeting physician adoption – if your users are already on Doximity, leveraging that network is faster than building a new one. 

Not designed for non-physician staff. Not embeddable in third-party products. No meaningful AI or care coordination features. Best fit: physician communication, referral coordination, telehealth that connects into the existing Doximity physician network.

OnPage · On-call workflows 

Secure HIPAA-compliant messaging plus on-call scheduling and escalation automation. HIPAA-ready with BAA. Narrower feature scope than Rocket.Chat or TigerConnect, which is also its advantage for teams that specifically need the on-call workflow automation and don’t want to operate a larger platform. Primarily proprietary; not open-source.

Vendor	BAA availability	Self-host	SDK-embeddable	AI/LLM native	Best for
Rocket.Chat	Enterprise plan	✅ open source	⚠️ extra work	Add-on	Internal clinical team chat
TigerConnect	All clinical plans	❌	❌	Limited	On-call workflows, clinical comms
Spok	✅	❌	❌	❌	Paging replacement
Wickr	Under AWS BAA	❌ (AWS only)	❌	❌	FedRAMP required environments
Element (Matrix)	Element Server Suite	✅ open source	⚠️ nontrivial	❌	Multi-institution, federated
Doximity	✅	❌	❌	❌	Physician-to-physician network
OnPage	✅	❌	❌	❌	On-call escalation workflows
Ethora	Business tier	✅ all tiers	✅ purpose-built	✅ BYO LLM	Embedded patient chat + AI

Ethora: Embedded Patient Chat + AI SDK

The case for Ethora is specific: if you’re building a patient-facing product – a telehealth app, a patient portal, a care coordination platform – and need to embed HIPAA-compliant messaging, video, and AI inside your own product’s UI, Ethora is built for that use case. The HIPAA-compliant chat SDK deploys as modules you enable – patient-provider messaging, video visits, AI triage bot, RAG over clinical content – on your infrastructure, with your branding, under your BAA. 

If you’re looking for a HIPAA-ready chat solution for your product, drop us a line. We’ll answer all of your questions and guide you through the development process, so you can be sure you meet all regulatory requirements.