If you are adding chat to a healthcare app, HIPAA is not a feature you bolt on at the end. It shapes your architecture, your vendor choices, and even the wording of your push notifications. This guide covers what HIPAA actually requires for a chat feature, where the Business Associate Agreement (BAA) fits in, how build-vs-buy changes under HIPAA, and the mistakes that trip up otherwise well-built apps.
Up front: this is an engineering guide, not legal advice. Have counsel or a compliance officer review your specific setup.
What HIPAA actually covers, and when it applies to your chat
HIPAA applies when protected health information (PHI) is created, received, stored, or transmitted by a covered entity (providers, health plans, clearinghouses) or a business associate working on their behalf. PHI is broader than most developers assume, and in a chat context it includes:
- A message from a patient describing symptoms
- An appointment reminder that names a clinic or specialty (“Your cardiology appointment is tomorrow”)
- A photo of a prescription or a wound shared in chat
- Even the fact that a specific person is messaging a mental health provider at all
If your chat feature lives in a consumer wellness app with no covered entity involved, HIPAA may not apply at all (though FTC health data rules and state privacy laws might). The moment a hospital, clinic, telehealth service, or insurer is your customer, you are in business associate territory and the rules bind you.
Three rules matter for chat builders: the Privacy Rule (how PHI can be used and disclosed), the Security Rule (safeguards for electronic PHI, where most of your engineering work lives), and the Breach Notification Rule (notifying individuals and regulators after a breach of unsecured ePHI; properly encrypted data lost without its keys generally does not trigger notification, one more reason encryption is not optional in practice).
Technical safeguards, translated into chat features
The Security Rule is technology neutral. It does not say “use TLS 1.3” or “use AES-256.” It defines outcomes, and some specifications are “required” while others are “addressable,” meaning you implement them or document why an alternative is reasonable. In 2026, treat the addressable ones as required. Regulators and customers’ security teams certainly do, and HHS has been moving toward making safeguards like encryption and multi-factor authentication explicitly mandatory in proposed Security Rule updates. Here is what each safeguard means for a messaging system.
Encryption in transit and at rest
All chat traffic should run over current TLS, including WebSocket connections, file uploads, and media CDN links. At rest, the message store, attachment storage, search indexes, and backups all need encryption. The parts people forget: message queues, Redis caches holding message payloads, and object storage buckets for images and voice notes.
Note what HIPAA does not require: end-to-end encryption in the WhatsApp sense. Server-side encryption with strong key management satisfies the rule, and many healthcare deployments deliberately avoid E2EE because the organization needs auditable access to conversations for record-keeping and moderation. E2EE is a design choice, not a compliance mandate.
Access controls
Every user needs a unique identity; shared logins are a straightforward violation. Add role-based access so a billing clerk cannot open a clinician’s conversation with a patient, conversation-level permissions in the chat system itself, and an emergency access procedure for outages. Multi-factor authentication for staff accounts is table stakes with enterprise buyers even where the rule text does not spell it out.
Audit logs
You must be able to record and examine activity involving ePHI: who logged in, who read which conversation, who exported or deleted what, and when. For chat this means server-side audit trails covering message access and administrative actions, retained per your policy (six years is the common benchmark for HIPAA documentation) and stored tamper-resistant, for example append-only or as write-once exports to object storage.
Automatic logoff
Sessions that touch ePHI must terminate after inactivity. In mobile chat this means token expiry plus a re-authentication prompt (PIN, biometric) after an idle period, and remote session revocation for lost devices. A chat app that stays signed in forever on a shared nursing station tablet is a finding waiting to happen.
Integrity
ePHI must not be improperly altered or destroyed. For chat: immutable message history (edits stored as revisions, not overwrites), checksums on attachments, and clear rules on who can delete content and whether deletion is soft or hard.
The BAA: the part you cannot engineer around
A Business Associate Agreement is a contract in which a vendor handling PHI on behalf of a covered entity accepts direct HIPAA obligations. The rule is simple and unforgiving: every vendor that creates, receives, maintains, or transmits PHI for you must sign a BAA. That chain extends downward. If your chat vendor runs on a cloud provider, the chat vendor needs a BAA with that provider too.
For a typical chat stack the BAA list includes your cloud provider (AWS, Google Cloud, and Azure all offer BAAs covering specific services), your chat platform vendor if hosted, transcription or AI services that process message text, and any analytics or logging SaaS that could see message payloads. There is a narrow “conduit” exception for services that merely transport data without persistent access, like an ISP. Do not stretch it; a chat vendor that stores your messages is not a conduit.
The practical consequence: a vendor that will not sign a BAA cannot be in the PHI path, no matter how good its SDK is. That single question eliminates a surprising number of consumer-grade chat and notification tools.
Build vs buy: three realistic paths
1. Hosted chat vendor with a BAA. Several commercial chat API vendors (CometChat, Sendbird, Twilio, Stream and others) will sign BAAs, usually on enterprise tiers. You get speed and offload infrastructure, but PHI lives on their servers, your posture depends on their controls, and BAA-eligible plans typically cost more than standard tiers. Verify the BAA covers the exact products you use, not just the vendor’s flagship service.
2. Self-hosted chat platform. Running the chat server inside your own cloud account (covered by your existing cloud BAA) keeps PHI within infrastructure you control, removes a third party from the PHI chain, and makes audits more direct. The tradeoff is operational: you own patching, scaling, monitoring, and incident response. Open source options make this path viable; Ethora, for example, is an open source chat and AI SDK that can be self-hosted precisely for this kind of regulated deployment (disclosure: Ethora is our product, see ethora.com).
3. Fully custom build. Maximum control, maximum liability. You inherit every safeguard: presence, delivery, encryption, audit trails, admin tooling. For most teams this only makes sense when chat is the product, not a feature.
If you are weighing specific SDKs for a React Native healthcare app, our React Native chat SDK comparison covers the main options; for HIPAA work, add “will you sign a BAA” and “can we self-host” to whatever feature checklist you use.
Common mistakes that leak PHI
- Push notification content. The classic failure: “Dr. Reyes: your biopsy results are ready” on a lock screen, routed through APNs and FCM which have not signed your BAA. Send a generic alert (“You have a new secure message”) and fetch the real content over TLS after authentication.
- Application logs. Debug logging that prints message bodies or identifiers into log aggregators outside your BAA chain. Scrub PHI at the logging layer, not in a cleanup script later.
- Crash reporting and analytics. Crash reporters happily capture screen contents, breadcrumbs, and network payloads. Configure them aggressively or keep them off PHI screens entirely.
- Backups. Encrypted production database, unencrypted snapshots in a forgotten bucket. Backups are ePHI and need the same encryption, access control, and retention discipline, plus tested restores.
- Client-side caches. Message content in unencrypted local storage, or sensitive screens visible in the OS app switcher preview. Use encrypted on-device storage and mask task-switcher snapshots.
- Retention with no policy. Keeping every message forever grows breach surface; deleting freely may violate record-keeping duties. Define retention with your compliance owner and enforce it in the system.
Practical checklist
- Confirm whether HIPAA applies: is a covered entity or business associate in the loop?
- Run and document a risk assessment before writing code
- TLS on every connection, including WebSockets and media URLs
- Encryption at rest for messages, attachments, caches, search indexes, and backups
- Unique user IDs, RBAC, MFA for staff, emergency access procedure
- Automatic logoff and remote session revocation
- Server-side, tamper-resistant audit logs for access and admin actions
- Generic push notifications, content fetched after auth
- PHI scrubbing in logs, crash reports, and analytics
- BAAs signed with every vendor in the PHI path, cloud provider included
- Documented retention and deletion policy, enforced in code
- Breach response plan with defined notification steps
- Workforce training and written policies (compliance is organizational, not just technical)
FAQ
Is Slack or Microsoft Teams HIPAA compliant for healthcare?
They can be, in specific configurations. Both vendors offer BAAs on certain enterprise plans, and compliance then depends on how the workspace is configured and used. A free or standard workspace without a BAA is not an acceptable place for PHI. And no tool is “HIPAA compliant” by itself; compliance describes the whole deployment, including your policies and training.
Do I need a BAA for a chat SDK?
It depends on where messages live. If the vendor hosts the chat backend and PHI passes through or is stored on their servers, yes. If you use an open source SDK and self-host the entire backend in your own cloud account, no BAA with the SDK maker is needed because they never touch your PHI; your cloud provider’s BAA covers the infrastructure.
Is end-to-end encryption required by HIPAA?
No. HIPAA requires encryption in transit and, as a practical matter, at rest, but it does not mandate end-to-end encryption where only the endpoints hold keys. Many compliant healthcare systems use server-side encryption specifically so the organization retains auditable access to conversations. E2EE can be a good choice for some threat models, just not a regulatory requirement.
Can I send appointment reminders by SMS or push notification?
Yes, with care. Keep content minimal and generic, get patient consent for the channel where required, and keep clinical detail behind authentication in the app. The risk is not the reminder itself but PHI on lock screens and in transit through carriers and notification services outside your BAA chain.