Open-source chat under HIPAA: what you can use and what you still owe

Open-source chat can be used with PHI, but the license does not make it compliant. Self-hosting can remove the need for a vendor BAA in some setups, and it moves every Security Rule safeguard onto your team. This guide maps who is responsible for what, lists the projects evaluators ask about, and compares the cost with buying a BAA-backed service. For the wider decision, see HIPAA-compliant chat APIs for developers.

Short answer: can open-source chat be used with PHI?

Yes, in principle. HIPAA regulates covered entities and business associates, not software licenses. A clinic or a health-tech company can run an open-source chat server and exchange PHI over it if the safeguards in the Security Rule are in place. No open-source project is "HIPAA certified." There is no such certification for software, and a project's docs or marketing cannot make your deployment compliant.

Compliance depends on three things together: a signed BAA wherever a third party handles PHI for you, the way you configure the system, and your organization's own policies and procedures.

The trade is simple. You get control over data, code and configuration, and you pay no per-seat license fee. In return you own operations, security, documentation and incident response. If what you need is internal chat for clinic staff or another channel, start at which kind of chat you need under HIPAA.

Why self-hosting changes who needs a BAA

A BAA is required when a third party creates, receives, maintains or transmits PHI on your behalf (45 CFR 164.502(e) and 164.504(e)). Who that third party is depends on where the software runs.

Your own hardware, in your own facility. No outside vendor holds PHI, so there is no vendor to sign a BAA with. Everything else still applies. You carry the administrative, physical and technical safeguards, including the physical security of the server room and the disposal of drives.

A cloud or colocation provider. If the server stores or transmits PHI on that provider's infrastructure, the provider is likely a business associate, and you need a BAA with it. Whether a given provider offers one, for which services and on which plans, varies. HHS states that a cloud service provider that stores ePHI is a business associate even if it stores only encrypted ePHI and holds no decryption key: "Lacking an encryption key does not exempt a CSP from business associate status and obligations under the HIPAA Rules." A BAA is required and the provider is directly liable under HIPAA (https://www.hhs.gov/hipaa/for-professionals/special-topics/health-information-technology/cloud-computing/index.html). HHS does not address colocation providers on that page (hhs.gov). HHS notes one narrow exception: a service that only transmits data, with any storage temporary and incidental to that transmission, may qualify as a mere conduit. Verdicts on individual hosting providers, including Google Cloud, AWS, Azure, Liquid Web, Atlantic.Net, GoDaddy and WP Engine, are collected on the hipaacompliant.wiki hosting page at https://hipaacompliant.wiki/hipaa-compliant/hosting/. (hhs.gov).

Managed hosting from the project's company. If you buy a hosted version of an open-source product, the company running it is the business associate. BAA availability, plans and covered services are set by that vendor, not by the open-source license. (rocket.chat).

Two practical consequences follow. A BAA with your host does not cover what you build on top of it, such as an unencrypted backup bucket in another service. A BAA also does not replace your own risk analysis.

What you must build yourself: Security Rule safeguards

The Security Rule (45 CFR 164.308, 164.310, 164.312, 164.314 and 164.316) does not name chat servers. It requires you to assess risk and apply safeguards that are reasonable for it. For a self-hosted chat, that translates into the work below. architecting chat that touches PHI covers the data-flow side in more detail.

Access control

• Unique user IDs for every person. Shared accounts such as "frontdesk" break accountability.
• Multi-factor authentication, ideally through your identity provider with SSO.
• Session timeouts and automatic logoff on shared front-desk workstations.
• Prompt deprovisioning when someone leaves the practice.

Encryption

• TLS for all client-to-server and server-to-server traffic.
• Encryption at rest for the database, file storage and search index.
• The same for backups, with key management you can document: who holds keys, how they rotate, how they are recovered.

Audit, retention and deletion

• Audit logs of logins, access, admin changes and exports, kept where administrators cannot quietly edit them.
• A defined retention period, and a deletion process that actually removes data.
• Behavior of message edits, deletions and attachments. Check whether an edited message keeps its original text, and whether deleted files remain in object storage or backups.

Hidden PHI leaks

• Push notifications. Mobile push usually passes through Apple or Google. A notification that shows "Jane Doe: lab results are back" has put PHI in a third-party channel. Configure notifications to show no content.
• Search indexes. A separate search service holds a second copy of message text and needs the same controls.
• Federation. In federated systems such as Matrix, messages replicate to other servers you do not control.
• Bridges and integrations. A bridge to Slack, SMS or email sends PHI into systems with different terms.
• Logs and analytics. Error trackers, reverse-proxy logs and crash reports can capture message content.

Operations

• Patching on a schedule, with a vulnerability management process.
• Backup and disaster recovery, with restore tests.
• A written, dated risk analysis and risk management plan.
• A breach response plan that meets the Breach Notification Rule (45 CFR 164.400–414).

Open-source projects evaluators ask about

The table lists projects in alphabetical order, not by preference. Every cell below is a placeholder to fill from the official license, docs and BAA pages.

Project	License	Self-host option	Managed offering with BAA	E2EE support	Federation
Matrix (Synapse server) with Element	Dual-licensed: AGPL-3.0 or a paid Element Commercial License (Synapse repository). Element's pricing page describes the free Community edition as for non-professional deployments and evaluations, not production use (github.com)	Yes. Element Server Suite Community is free and open source under AGPL; Enterprise (ESS Pro) is also self-hosted, priced per seat; Sovereign is air-gapped (element.io)	No Element-hosted or managed plan is listed on Element's pricing page, and Element publishes no BAA (checked 2026-11-03). (element.io)	Encrypted by default, not enforced: Element describes ESS Pro as end-to-end encrypted by default, direct messages and private rooms default to encryption (with opt-out), and configuration can create unencrypted rooms. Public rooms not addressed (element.io)	Yes, federation is on by default; it can be closed by enabling the allow list with no servers added (docs.element.io)
Mattermost	Team Edition is MIT-licensed open source; Enterprise Edition is under a commercial license (free with no subscription, not open source; paid with a subscription). Confirm Team Edition is still distributed, as the current Editions page no longer lists it (docs.mattermost.com)	Yes, self-hosted open-core platform; Entry is a free self-hosted mode (docs.mattermost.com)	Not stated in the public documentation (checked 2026-11-03)	Not documented; the encryption docs cover encryption in transit and at rest only (docs.mattermost.com)	No Matrix-style federation found; paid Enterprise offers connected workspaces between Mattermost instances only (docs.mattermost.com)
Rocket.Chat	MIT for code outside the ee directories; code under ee/ and apps/meteor/ee/ is under a separate enterprise license (github.com)	Yes, on-prem, private cloud and air-gapped deployment; Starter and Community are free self-managed entry points (rocket.chat)	Commercial plan offers Rocket.Chat-managed dedicated cloud hosting and states a Business Associate Agreement is available; covered services and BAA eligibility of other plans are not stated, and pricing is by quote (rocket.chat)	Supported for private and direct conversations; plan-by-plan scope not confirmed (Government plan lists E2EE) (docs.rocket.chat)	Yes, built in since v7.11, using the Matrix protocol, controlled by workspace permissions (docs.rocket.chat)
Zulip	Apache 2.0 (github.com)	Yes, free self-hosted plan with all features; Zulip Cloud also available (zulip.com)	Not stated in the public documentation (checked 2026-11-03)	No message-level E2EE found; E2EE applies to push-notification content only, with TLS in transit and encryption at rest for self-hosters (docs.zulip.com)	Not offered in the documentation reviewed; organizations run separate instances (zulip.com)

Where a vendor does not publish a BAA or does not state which plans it covers, say so in the cell. Do not assume one exists. Also check audit logging and retention controls in each project's docs, since those often differ between the free edition and paid tiers. Mattermost's free Entry mode has no monitoring, exports, legal hold or data retention, with granular audit logs and enhanced compliance controls under paid Enterprise; Rocket.Chat's Government plan lists tamper-evident audit logs and granular retention; Zulip lists per-channel retention policies and an admin-action audit log on all plans (docs.mattermost.com).

Verdicts on whether a specific product can be used under a BAA live on hipaacompliant.wiki and are not repeated here. Note that the wiki's team chat page (https://hipaacompliant.wiki/hipaa-compliant/team-chat/) does not yet include entries for Element/Matrix, Mattermost, Rocket.Chat or Zulip. (hipaacompliant.wiki).

Open-source chat components for developers

A full chat app and a chat component solve different problems. A full app, such as the projects above, gives your staff or patients a ready interface. Libraries and server SDKs let you embed messaging in a patient portal, a telehealth app or an intake flow. In that case you also own the user interface, the account model and the way messages map to patient records. HIPAA-compliant chat SDKs covers how SDKs compare.

A self-hosted backend changes several things you would otherwise buy:

• Scale. You size and monitor the message store, the websocket layer and the file storage. A clinic network with a vaccine-reminder campaign sees spikes that a vendor would absorb.
• Moderation. You build reporting, blocking and review tools for patient-facing channels.
• Mobile push. You configure Apple and Google push yourself and must keep PHI out of payloads (see above).
• Identity. You decide how a patient's identity is verified before a conversation can mention their record.

Token handling, logging and the PHI data flow are covered on the architecture page linked in the safeguards section.

Total cost: self-hosting versus a service with a BAA

The license is free. Running it is not. The cost lines to estimate:

• Engineering: initial deployment, integration with your identity provider, upgrades.
• Hosting: servers, storage, backups and a second region if you need failover. Add the BAA-eligible tier of your cloud provider if the cheaper tier is excluded. Eligibility depends on the service, not the price tier. AWS says PHI should be processed only in HIPAA-eligible services listed in its BAA; Azure covers in-scope services under its Product Terms and DPA; Google Cloud's BAA covers listed products, and unsupported services should be disabled when handling PHI (aws.amazon.com).
• Security review: penetration testing, configuration review, and the risk analysis document.
• Audit and documentation: evidence for policies, access reviews and log retention.
• On-call and incident response: someone must answer when the server fails at 2 a.m. or when a lost phone has the app signed in.

Where open source makes sense: you already have a platform team that runs and patches production systems, you have data residency requirements that a vendor cannot meet, or you need custom workflows such as routing messages into your own EHR integration.

Where a BAA-backed service is simpler: a small team with no dedicated security staff, a fast launch deadline, or no one who can own the operational duties above. chat API providers with a BAA compared lists plans and BAA availability.

A fair comparison counts staff time and risk, not only the monthly invoice.

Decision checklist before you deploy

Work through this list with your privacy officer. The architecture guide linked earlier, architecting chat that touches PHI, covers the technical items in depth.

1. Who hosts, and is a BAA signed with them? Cover the cloud provider, the managed host, and any backup or monitoring vendor that could see PHI.
2. Is PHI limited by design? Apply minimum necessary: decide which message types may contain PHI, and scrub notifications, logs and analytics.
3. Is there a documented risk analysis? Include a breach response plan and a named security owner.
4. Are federation and third-party bridges disabled or covered by a BAA and by your policies?
5. Can you delete and retain messages according to policy, including edits, attachments, search indexes and backups?
6. Are accounts individual, with MFA and timely deprovisioning?
7. Have you tested restore from backup and a simulated lost-device scenario?

FAQ

Is there a HIPAA-compliant open-source chat?

No open-source project is compliant as a product property, and none is certified. A deployment can meet the Security Rule when it is hosted under the right agreements, configured correctly and run under documented policies.

Do I need a BAA if I self-host?

It depends on where you host. On your own hardware, with no outside party handling PHI, there may be no vendor to sign with. On a cloud or colocation provider, or with a managed host, the provider is likely a business associate and a BAA is needed. Backup, monitoring and support vendors that can access PHI need one too.

Is Matrix or Element usable with PHI?

Possibly, with conditions. Matrix servers can be self-hosted, but federation copies messages to servers you do not control, so restrict or disable it. For a managed Element offering, note that Element's pricing page lists only self-hosted (Community, Enterprise/ESS Pro) and air-gapped (Sovereign) plans and publishes no BAA, so ask Element sales directly (element.io). Verdicts are on hipaacompliant.wiki. There is no Element/Matrix entry on the wiki yet; see the team chat category page at https://hipaacompliant.wiki/hipaa-compliant/team-chat/. (hipaacompliant.wiki).

Is end-to-end encryption enough for HIPAA?

No. Encryption is one safeguard. You still need access control, audit logs, retention and deletion, risk analysis, workforce training and BAAs where required. End-to-end encryption can also limit your ability to audit content or recover messages, so check how a project's implementation affects your retention policy. Scope varies: Element encrypts DMs and private rooms by default but not enforced; Rocket.Chat supports E2EE for private and direct conversations; Mattermost documents no E2EE; Zulip applies E2EE to push-notification content only (github.com).

Can I use Mattermost or Rocket.Chat for patient messages?

Both are commonly used for internal staff chat. Using either for patient-facing messages adds identity verification, notification handling and retention questions that you must solve. Rocket.Chat states a BAA is available on its Commercial plan; Mattermost, Zulip and Element publish no BAA on the pages reviewed (rocket.chat). Staff-only chat is covered separately, starting from the navigator on the home page.

Is open-source cheaper than a commercial chat API?

Not necessarily. License fees disappear, but engineering, hosting, security review, audit and on-call costs remain. It tends to cost less when you already run production infrastructure and security operations.

Sources and last verified