HIPAA-Compliant Chat SDKs: What to Check Before You Build

No chat SDK is "HIPAA compliant" on its own. What you can verify is whether the vendor will sign a business associate agreement (BAA) covering the exact hosted services your app calls, and whether your integration keeps PHI inside that scope. This page gives you a checklist for evaluating an SDK as a client library plus a hosted backend. For vendor-by-vendor facts, see the rest of the HIPAA-compliant chat APIs for developers section.

Short answer: what "HIPAA-compliant chat SDK" actually means

An SDK is a client library. It renders message lists, opens connections and caches data on the device. The PHI-handling parts are elsewhere:

• the vendor's hosted backend, which stores messages, files and user records;
• the vendor's subprocessors, such as cloud hosting, push delivery and file storage;
• your own app, servers, logging and analytics.

There is no certification for a chat SDK. Whether a deployment meets HIPAA depends on a signed BAA, how you configure the service, and the customer's own policies and risk analysis. A vendor marketing page that says "HIPAA compliant" settles none of those.

This site uses one phrase for vendor verdicts: "BAA available on <plans> for <services>." It is deliberately narrow. It names the plans the agreement covers and the services it covers, because a BAA on an enterprise plan says nothing about a starter plan, and a BAA for messaging says nothing about a moderation add-on. Those facts are collected in chat API providers with a BAA compared.

If you are not yet sure an SDK is the right kind of chat (versus website live chat, video or staff messaging), start with which kind of chat you need under HIPAA.

Where PHI touches a chat SDK

Map the surfaces before you read any vendor documentation. In a patient portal or clinic app, PHI shows up in more places than the message text. The wider design questions are covered in architecting chat that touches PHI; this is the SDK-specific list.

Surface	What can carry PHI	Example from a clinic app
Message bodies	Free text from patients and staff	"My A1C result was 9.1, should I change my dose?"
Attachments	Photos, PDFs, lab reports	A wound photo sent to a nurse line
Identifiers and metadata	User IDs, channel names, custom fields, display names	Channel named jsmith-mrn448812
Client-side storage	Local cache, SQLite or IndexedDB, device backups, screenshots	Message history cached on a lost phone
Push notifications	Preview text and payload sent through APNs or FCM	Lock-screen banner showing the message
Logs and telemetry	Request logs, analytics events, crash reports, webhooks	Crash report that includes the last message string

Two points are easy to miss. First, the fact that a person is a patient of a particular practice can itself be identifying, so a channel name or user ID that links a person to a clinic is a PHI question even if no clinical text appears. Second, anything your app sends to a third party, such as a webhook receiver or an error tracker, sits outside the chat vendor's BAA unless that third party has its own agreement with you.

BAA scope: the first filter

Request the BAA text before you evaluate features. A vendor that will not share its terms until a sales call is a different evaluation than one that publishes them. Check:

• Plans covered. Is the BAA available on every plan, or only on specific paid or enterprise plans? Is signing self-serve or sales-gated?
• Services covered. Messaging storage is the obvious one. Ask separately about push delivery, file storage, moderation, search, analytics and any AI features. For AI-assisted features such as summaries, smart replies or bots, see AI chat and PHI; an AI feature that calls a separate model provider may fall outside the chat BAA.
• Subprocessors. Does the vendor publish a list, and do those subprocessors carry their own BAAs with the vendor?
• Shared responsibility. Most agreements and vendor documents state what the customer must do: configuration, access management, avoiding PHI in unsupported fields. Read that section as your task list.

Write down the result in the form "BAA available on X for Y." If you cannot fill in both blanks from the vendor's own documents, treat the gap as an open risk item.

Technical controls to check in the SDK and backend

Check these against the vendor's published documentation, not sales claims. Where the vendor does not publish a statement, note that and ask in writing.

Encryption. Look for documented encryption in transit and at rest, and who holds the keys. The Security Rule treats encryption as an addressable specification, so your risk analysis should record what you rely on. HHS says "addressable" does not mean optional: the entity must assess whether the measure is reasonable and appropriate, and if not, adopt an equivalent alternative and document why (HHS Security Rule page modified 2026-08-07; summary dated 2024-05-21). Check the specific citations at 45 CFR 164.312(a)(2)(iv) and (e)(2)(ii) on eCFR, and the status of the pending Security Rule NPRM, before publishing. (hhs.gov)

Access control.

• How are client tokens issued, and how long do they live? Tokens should be minted by your server, not embedded in the app.
• Can you restrict who can create channels, read history or invite users?
• Who at the vendor can access your data, and how is that access logged?

Audit, retention and deletion.

• Is there an audit log of reads, exports and admin actions?
• Can you set retention per channel or per app, and does deletion reach backups and search indexes?
• Can you export a conversation for a records request?

Retention periods for clinical records usually come from state law and your own policies, not from the chat vendor. HIPAA itself requires only that Security Rule policies and risk-analysis documentation be kept for 6 years (45 CFR 164.316(b)(2)(i)); confirm clinical record retention periods with counsel. (ecfr.gov)

Data residency. If you have contractual or state-level requirements, check whether the vendor publishes region options. If it does not publish them, say so in your review.

End-to-end encryption. E2EE reduces what the vendor and your own servers can read, but it also limits server-side moderation, search, automated escalation and compliance export. It does not by itself satisfy HIPAA, and it does not remove the need to evaluate the rest of the data flow. Decide per use case: a patient-to-clinician thread that must be searchable and exportable into the record usually conflicts with E2EE.

Hosted SDK vs. self-hosted open source

Hosted. You ship faster, the BAA sits with the vendor, and the vendor operates storage, scaling and patching. You still own configuration, the app, and everything outside the vendor's covered services.

Self-hosted. The library license is free, but you carry the security controls and the BAA chain: a signed BAA with your cloud or hosting provider, plus your own backups, patching, access logging and incident response. An open-source license is not a HIPAA position either way.

The trade-offs, projects and hosting patterns are in open-source chat under HIPAA; this page does not repeat them.

Evaluation checklist before integrating

1. Get the BAA first. Request and review it before any prototype touches real data. Use synthetic data in development and staging.
2. Map every data flow. Draw client → vendor → every third party. Mark each arrow as inside or outside a BAA.
3. Minimize identifiers. Use opaque IDs for users and channels. Keep names, MRNs and dates of birth out of custom fields.
4. Handle push deliberately. Send a generic alert ("You have a new message") and fetch content after the user authenticates.
5. Control the client. Check what the SDK caches locally, whether it can be encrypted or disabled, and how you wipe it on logout or remote revoke.
6. Test lifecycle end to end. Create a thread, apply retention, delete it, and confirm it is gone from search, exports and any webhook consumers. Confirm access logs record who read it.
7. Audit bundled SDKs. Review analytics, crash reporting and session-replay tools in the same app.
8. Document the decision. Record the vendor, BAA scope, configuration and residual risks in your risk analysis.

Common mistakes

• Assuming a free or starter tier is covered. BAAs are often tied to specific plans. Confirm the plan you will actually run in production.
• Putting patient names in channel IDs or custom fields. These are indexed, logged and often returned in webhooks.
• Sending PHI through analytics or error tracking. A crash payload containing the last message or a screen capture goes to a vendor you have no BAA with.
• Treating the chat vendor's BAA as covering your infrastructure. It covers the vendor's services. Your API servers, databases, log stores and cloud accounts need their own coverage.
• Letting the staging environment hold real patient data. Test accounts with real messages are still PHI.

Sources and last verified

FAQ

Is there a HIPAA-certified chat SDK?

No. HHS does not certify chat SDKs or other software for HIPAA. What you can check is whether a vendor offers a BAA for the hosted services behind the SDK, on which plans, and what the documentation says about controls.

Do I need a BAA to use a chat SDK in a patient app?

If the SDK's hosted backend creates, receives, maintains or transmits PHI on your behalf, the vendor is acting as a business associate and you need a BAA with it. A purely client-side library that never sends PHI to the vendor is a different case, but check what telemetry it sends. HHS cloud computing guidance says a service provider that creates, receives, maintains or transmits ePHI for a covered entity is a business associate even if it stores only encrypted ePHI and holds no key. (hhs.gov)

Does a BAA make my app HIPAA compliant?

No. A BAA covers the vendor's services. Your app, servers, access policies, workforce training, risk analysis and incident response remain your responsibility.

Can I use a chat SDK's free plan with PHI?

Only if the vendor's BAA explicitly covers that plan. Many agreements are tied to particular paid plans, so confirm in writing before real data touches a free or starter tier.

Are push notifications with message content allowed under HIPAA?

HIPAA does not name push notifications specifically, so it is a risk analysis decision. Notification content passes through APNs or FCM and appears on lock screens. The conservative pattern is a generic alert with no clinical content, with the message fetched after sign-in. Confirm whether your vendor's BAA covers push delivery.

Is an open-source chat SDK HIPAA compliant?

An open-source license says nothing about compliance. If you self-host, you are responsible for the infrastructure controls and for BAAs with your hosting providers. See open-source chat under HIPAA for the details.

What should I do with chat logs and retention?

Decide retention from your record-keeping obligations, which usually come from state law and your own policies. Set it in the platform, test that deletion propagates to search, exports and backups, and keep PHI out of application logs and third-party monitoring tools. Confirm the periods with counsel; HIPAA itself requires only that its policy and risk-analysis documentation be kept for 6 years (45 CFR 164.316(b)(2)(i)). (ecfr.gov)