HIPAA-Compliant Messaging: Complete Guide for Healthcare

Messages are the channel through which PHI travels most casually and most frequently. Clinical staff text each other lab results on WhatsApp, coordinate care on group chats, and communicate with patients in messengers. It’s fast and convenient, yet it’s the weakest link for breaches.

To avoid data leaks and fines up to $1.9 million per violation category per year, this communication should be properly protected and comply with HIPAA. In this guide, we cover what HIPAA actually requires for messaging, what the technical security looks like in practice, how to evaluate platforms, and how to run an implementation without it becoming a six-month project.

What Is HIPAA and Why Does It Apply to Messaging?

HIPAA (Health Insurance Portability and Accountability Act) is a US federal law issued in 1996 that outlines the rules for protecting sensitive patient health information. Messaging is mainly governed by two of its rules – the Privacy Rule and the Security Rule. The third rule – the Breach Notification Rule – tells what to do in the case of a breach. Let’s look closer.

• The Privacy Rule. It tells who should be able to access the PHI and for what reasons. In the context of communications, this implies that any exchanges containing the patient’s confidential data must be restricted to individuals with a legitimate purpose to view it.
  
• The Security Rule. It gets specific about technology. It requires administrative, physical, and technical safeguards for anything that stores, processes, or transmits electronic PHI. The technical safeguard requirements – encryption, access controls, audit logs, staff training – are what determine whether a messaging platform qualifies. We’ll cover those in detail in the next section.
  
• The Breach Notification Rule. This one covers what happens when something goes wrong. Discovery triggers a 60-day clock to notify affected patients. If 500 or more people are involved, HHS gets notified too – and that goes onto a public breach portal. At that point, the media often picks it up regardless of whether you’ve called them directly.

One thing that catches organizations off guard: HIPAA follows the data, not just the organization holding it. Any vendor who touches PHI on your behalf – your messaging platform included – is a business associate under the law. Before a single patient message hits their servers, they need to sign a Business Associate Agreement (BAA). No signed BAA means you’re exposed, whatever the vendor says verbally about their security posture.

Why Standard Messaging Apps Are Not HIPAA Compliant

The clinical staff sending patient information over iMessage or WhatsApp aren’t being careless – those apps work great, and they’re already on everyone’s phone. The problem is structural: consumer messaging platforms were built for convenience, not for healthcare’s legal requirements. 

A few specific scenarios worth knowing about:

• SMS and carrier storage. Standard SMS is unencrypted in transit, stored by carriers, and has no access controls. A nurse texting a colleague about a patient’s lab results is sending PHI through an infrastructure that HIPAA has no jurisdiction over.
  
• WhatsApp group chats. WhatsApp refuses to sign BAAs. When somebody leaves the group chat, messages are still on their device. There are no audit trails, and data can’t be removed remotely.
  
• iCloud and Google Drive backups. Messages on iPhones and Android devices often back up automatically to cloud services. A message containing PHI that gets backed up to a personal iCloud account is an uncontrolled copy of ePHI, and that backup provider hasn’t signed a BAA.
  
• Standard Slack. Slack’s Pro and Business+ plans do not qualify for HIPAA compliance. The Enterprise Grid plan, with a signed BAA and specific configuration, can be compliant – but at a price point that most smaller organizations won’t justify for messaging alone.

Here’s the quick comparison between customer apps and HIPAA-compliant ones.

Requirement	Consumer apps	HIPAA-compliant platform
BAA available	No – most refuse	Yes
End-to-end encryption	Varies, often not	Required
Access controls (RBAC)	Basic or none	Role-based
Audit trails	None	Complete logs
Remote wipe	Limited	Full device/session wipe
Data residency control	Vendor’s servers (unknown)	Your choice of region/server
MFA	Optional, not enforced	Enforceable

Technical Requirements for HIPAA-Compliant Messaging

HIPAA splits its safeguard requirements into three buckets – administrative, physical, and technical. The administrative and physical ones matter, but when you’re evaluating a messaging platform, the technical safeguards are where most decisions get made. Below is the list of what you actually need.

Encryption

The healthcare industry requires end-to-end encryption (E2E) for data in transit and at rest. This means messages should be encrypted before leaving your server, and can be decrypted only on the recipient’s device. While they are in between, no one (even your server) can read it. The HIPAA doesn’t specify required encryption standards, but TLS 1.2+ is used in healthcare for moving information, and AES-256 is used for anything that you store.

Access Controls

Role-based control ensures that only authorized users can access the information. For example, administrative personnel shouldn’t have access to the patients’ health data.

Multi-factor authentication (MFA)

Multi-factor authentication should be an option, it should be mandatory. It is an extra measure that greatly minimizes the risk of a security breach. Single sign-on (SSO) to your current identity management solution (such as Active Directory, Okta, Azure AD) is important since you will need centralized user lifecycle management. 

Session management

Session management usually includes automatic logouts for idle sessions and restrictions for simultaneous logins. This minimizes exposure from forgotten logins, shared credentials, or compromised devices.

Remote wipe

This allows deleting sensitive information if the device was stolen, lost, or compromized. Additionally, admins can revoke access from those who no longer should have it.   

Audit trails

Every message sent, read, edited, deleted – logged, timestamped, tied to a user ID. HIPAA mandates six-year retention. The logs have to be tamper-proof and exportable. That last part is important: if OCR requests records or you’re running an internal investigation, you need to be able to pull a clean report without filing a support ticket with your vendor and waiting three business days.

Self-hosted platforms give you the audit database directly. Cloud platforms surface logs through a dashboard or API, which works until it doesn’t – vendor dashboards have outages, rate limits, and filtering constraints that your own database doesn’t.

Data management

Retention policies need to be configurable with automatic deletion – not a manual process someone has to remember. Data residency means knowing the specific AWS region or data centre, not just “US-based servers.” Encrypted backups with documented recovery procedures. And secure deletion when retention periods expire – this one gets skipped in vendor demos constantly. Ask specifically: what happens to our data at the end of retention? How is deletion verified?

Administrative Safeguards

Technical controls get most of the attention, but administrative safeguards are what hold them together operationally. A few things that belong in your platform evaluation, not just your internal policies.

BAA. Already covered, but worth repeating here: it’s an administrative requirement, not a technical one. You can have AES-256 everywhere and still be non-compliant if the vendor hasn’t signed one.

Risk assessments. HIPAA requires covered entities to conduct regular security risk assessments. A reputable vendor should have their own — and should be able to share documentation of it. If they can’t, that’s a gap in their security posture you’d be inheriting.

Incident response. Not just “we’ll notify you if something happens.” Ask for their documented breach response procedure: who gets contacted, at what threshold, through what channel, and in what timeframe. A vendor with a real process can answer this quickly. One without a process will tell you to check the terms of service.

Staff training. Platform-level security only goes so far if the people using it aren’t trained on what PHI looks like or when messaging it is appropriate. Some platforms support mandatory security awareness acknowledgment on login or as part of onboarding. It’s a small thing that reduces the risk of the most common violation: someone forwarding a message to the wrong person without thinking.

Self-Hosted vs Cloud: What Actually Changes for Compliance

Both approaches can be HIPAA-compliant. The question is where the compliance responsibility sits and how much control you need over it.

Aspect	Self-hosted	Cloud (SaaS)
Data control	Complete – you own the servers	Shared with vendor
Audit trail access	Direct database access	Via vendor dashboard or API
Compliance responsibility	Primarily yours	Shared with vendor
Configuration control	Full	Limited to the vendor’s options
Cost model	Higher upfront, lower at scale	Lower upfront, ongoing per-user
Maintenance overhead	Your team or managed service	Vendor handles

Self-hosting makes the most sense when complete audit trail control is non-negotiable – you query your own database, you don’t wait on a vendor’s report generation. It’s also the right call for sub-sectors with requirements layered on top of HIPAA: 42 CFR Part 2 for substance abuse records has stricter disclosure rules than standard HIPAA, and those are easier to enforce on infrastructure you control. Same for any organization with an existing on-premises compliance infrastructure that can’t route data through a cloud intermediary.

A cloud deployment works fine for most organizations, provided the vendor holds SOC 2 Type II and will sign a comprehensive BAA. Just don’t let “the vendor handles it” become a mental shortcut. Your configuration decisions are your compliance decisions. What access controls you enable, what retention policies you set, what regions you choose for data residency – those are yours. The BAA defines what they’re responsible for. Everything else is on you.

How to Evaluate a HIPAA-Compliant Messaging Platform

A few conversations with sales teams will blur together quickly. Having a specific checklist going in makes the evaluation faster and harder to dodge.

Must-have — non-negotiable

• Will sign a BAA – Ask for it in writing in the first call, not the last
• End-to-end encryption – Confirm it covers files too, and which pricing tier enables it
• Role-based access control (RBAC) – You configure the roles, not just pick from a preset list
• Audit trail with 6-year retention – Exportable on demand, not via support ticket
• MFA – Enforced at the admin level, not left as a per-user choice
• Remote wipe – For lost or stolen devices, executable without vendor involvement
• SOC 2 Type II – Request the actual report. How long have they held it?
• Documented breach notification process – When would they tell you, and how fast

Important — most production deployments need these

• Self-hosted option – Even if you start in the cloud, the option matters
• SSO integration – SAML or OIDC, connecting to your identity provider
• Data residency choice – Specific US region, not just “US servers”
• API and SDK – For integration into existing clinical workflows or your own apps
• Configurable data retention – Automatic deletion when retention expires
• Mobile app with PIN/biometric lock – Enforced, not optional for clinical users

Nice to have — worth asking about

• HITRUST certification – A security assessment that helps validate that the provider meets standards like HIPAA, NIST, ISO, and PCI DSS
• AI chatbot – If you plan to use an AI assistant for patient-facing intake or triage, check whether it runs on their servers or yours
• EHR integration – Ask whether they support your specific system (Epic, Cerner, Athenahealth)
• Video calling – Is it built-in or do they use third-party integrations?
• White-label – Thus, patients will see your brand, not the vendor’s

Questions that reveal a lot about a vendor

Ask where your data is stored – the specific region and data centre, not “US-based cloud.” Ask what their mean time to breach detection is, what happens to your data when you cancel, how deletion is verified, how long they’ve held SOC 2 Type II, and request the report directly, and ask to see a sample audit log export. None of these is unreasonable. A vendor who hedges on any of them is worth being skeptical about.

Building HIPAA-Compliant Messaging with Ethora

Ethora is a messaging and AI SDK platform built for organisations that need to embed HIPAA-compliant communication into their own products – patient portals, telehealth apps, care coordination tools, and provider-facing dashboards. It’s not a standalone messaging app for internal teams – it’s infrastructure you build into your product.

The compliance story is built around self-hosting. You run Ethora on your own AWS, Azure, GCP, or on-premises infrastructure — PHI stays inside your security perimeter, full stop. Your compliance team can query the audit database directly, configure encryption at the infrastructure level, and demonstrate data residency to an auditor without going through a vendor’s support portal.

The other piece that matters for healthcare specifically: self-hosted AI. Most healthcare organisations want to offer patients an AI assistant for FAQs, intake, and appointment scheduling. Most cloud AI APIs (OpenAI, Anthropic’s public API) require careful evaluation before PHI touches them. Ethora’s AI runs on your own infrastructure – same patient data controls, same audit trail, no third-party cloud AI vendor to evaluate or negotiate a BAA with.

Here’s what Ethora offers:

• BAA. Enterprise plans. Get this signed before any PHI moves. 
• Self-hosted. You can self-host an app on your AWS, Azure, GCP, or on-premises. 
• Dedicated server. If you use our server, Ethora manages a dedicated instance for your organisation on isolated infrastructure.
• End-to-end encryption. Ethora complies with the health industry standards and utilizes TLS 1.2+ for encrypting data in transit and AES-256 for encrypting data at rest.
• RBAC. Role configuration on clinical, administrative, and customer-facing layers. 
• Audit trails. Immutable, directly queryable. Not surfaced through a dashboard. 
• SDKs for React, React Native, iOS, and Android. Embeds into your iOS, Android, or web app. Patients use your product, not a new one. 
• Self-hosted AI. LLM runs on your infrastructure. Patient queries never reach a third-party API. 
• White-label. You customize the app from A to Z, making it match your brand.
• SOC 2. Ethora complies with SOC 2 standards for security, availability, and confidentiality
• Push notifications. Secure push notifications for new messages (without PHI in notification content)

Learn more about Ethora for healthcare

Implementation Roadmap

Eight weeks is realistic for a well-resourced team. Slippage usually happens at the SSO integration step or during security testing if the platform vendor is slow to respond to questions. Build buffer into weeks 5 and 6.

Here is an approximate schedule for rolling out HIPAA-compliant messaging within healthcare organizations:

Week 1-2 : Planning & Assessment

• Conduct a security risk assessment for the messaging use case
• Define user roles and access control requirements
• Choose deployment model (self-hosted vs cloud vs dedicated)
• Sign the BAA with the vendor

Week 3-4 : Technical Setup

• Deploy messaging infrastructure (server setup, encryption configuration)
• Integrate with identity provider (SSO/MFA)
• Configure audit logging and retention policies
• Set up monitoring and alerting

Week 5-6 : Integration & Testing

• Integrate messaging SDK into your application (patient portal, provider app)
• Security testing and penetration testing
• Compliance review against the HIPAA checklist
• User acceptance testing with clinical staff

Week 7-8 : Rollout

• Staff training on secure messaging policies
• Phased rollout (start with one department/team)
• Monitor audit logs and usage patterns
• Document policies and procedures

Need to figure out the right architecture for your organisation before committing to a platform? We can walk through your requirements and compliance constraints in a 30-minute call.

Schedule an architecture review

Frequently Asked Questions

*Disclaimer: This article is for informational purposes only and does not constitute legal advice. Consult your compliance team or legal counsel for HIPAA-specific requirements applicable to your organisation.  Penalty figures referenced are based on HIPAA Journal’s 2026 update and HHS Office for Civil Rights guidance; these figures are subject to annual inflation adjustments.