Architecting a HIPAA-Compliant Chat API for Telehealth and Text Chat

A chat API can carry PHI when three things are in place: a signed business associate agreement (BAA) that covers the exact services you use, a configuration that applies the Security Rule safeguards, and your own policies and procedures. The vendor supplies the first and part of the second. Most of the design decisions, including identifiers, push payloads, logs, analytics and retention, stay with you. This guide maps each place PHI can travel in a chat feature and says who owns the control at each point.

Short answer: what makes a chat API usable with PHI

Three conditions apply together:

1. A BAA that covers the services you use. A BAA is scoped to specific products, plans and features. A signed agreement does not extend to a feature it does not list.
2. A configuration that applies the safeguards. The administrative, physical and technical safeguards of the Security Rule (45 CFR 164.308, 164.310, 164.312) and the business associate contract requirements (164.314) apply to how the service is set up and used. (ecfr.gov)
3. Your own policies and procedures. Who may message whom, how long messages are kept, how access is reviewed and what happens after an incident are decisions your organization documents.

A chat API is a component, not a compliance status. No vendor makes your whole application compliant, and this page does not treat any vendor as compliant as a product property. Compliance depends on a signed BAA, configuration and the customer's policies.

This page covers text chat in telehealth and patient-facing apps. For the overall decision on which channel you need, see which kind of chat you need under HIPAA. For live video visits, see HIPAA-compliant video chat. Vendor comparisons and SDK specifics sit in the HIPAA-compliant chat APIs for developers section.

Map where PHI travels in a chat feature

Start with the message and work outward. A feature that protects the message body but leaks the patient's name in a push payload has still disclosed PHI.

Primary content

• Message bodies, such as "My incision is red and warm."
• Attachments and images, such as wound photos, lab PDFs and insurance cards.
• Voice notes and any transcripts generated from them.

Metadata that can identify a patient

• User IDs, especially when they are an email, phone number or MRN.
• Channel or conversation names, such as "Jane Doe – post-op."
• Timestamps, which show when a patient contacted a clinic or a specific provider.
• Device tokens and IP addresses.

Metadata can identify a patient and reveal a care relationship, even with no message text. Treat it as potentially in scope until you have decided otherwise and documented why.

Secondary paths

• Push notification payloads through APNs or FCM.
• Email and SMS fallbacks for unread messages.
• Webhooks that forward events or message content to your servers or third parties.
• Search indexes built from message text.
• Analytics and crash-reporting SDKs in the client app.
• Error and debug logs, on your servers and in the vendor's dashboard.
• Backups and replicas of any store above.

Exercise. Draw the data-flow diagram for your feature. Mark every hop (client, your app server, chat vendor, push provider, log store, analytics, backup) and label it one of three ways: covered by a BAA, not covered, or does not carry PHI by design. Any hop labeled "not covered" that carries PHI is a defect to fix before launch.

What a BAA with a chat API vendor does and does not cover

BAA scope is defined per product, plan and feature. Read the agreement and the vendor's HIPAA documentation for the list of covered services and the list of exclusions. Do not infer coverage from marketing pages or from the fact that a vendor "supports HIPAA."

Typical gaps to check in the vendor's documents:

• Beta or preview features.
• Add-ons and separately billed products, such as moderation, translation, search or analytics modules.
• Third-party subprocessors. The vendor needs downstream BAAs with subprocessors that handle PHI on its behalf. Ask for the subprocessor list and how it addresses this.
• AI features, such as summaries, auto-replies and sentiment detection. These often route data to a separate model provider. See AI chat and PHI for what a BAA covers there.
• Push and SMS delivery channels. Treat them as outside the BAA unless the vendor's document says they are included.
• Plan restrictions. A BAA may be offered only on certain plans.

You sign a BAA with the vendor. The vendor, in turn, must hold the downstream agreements its own handling of PHI requires. You do not sign with its subprocessors, but you should ask how they are covered.

Vendor-by-vendor coverage is in chat API providers with a BAA compared, with verdicts maintained at hipaacompliant.wiki. This page does not restate them. The wiki's vendor directory is at https://hipaacompliant.wiki/is/, and developer platforms such as Twilio and Firebase are listed under its Developer platforms category at https://hipaacompliant.wiki/hipaa-compliant/software-development/. (hipaacompliant.wiki)

Reference architecture for telehealth text chat

The pattern below keeps the most sensitive decisions on your side of the boundary.

Backend-for-frontend. The mobile or web client never talks to the chat vendor with long-lived credentials. Your app server authenticates the user (patient or clinician), checks authorization, and issues a short-lived chat token. It also enforces who may message whom: a patient may open a channel only with a clinician on their care team, and a front-desk user may see only the channels their role allows. Do not rely on client-side checks.

Pseudonymous identifiers in the chat layer. Use opaque IDs (for example, a random UUID per user and per conversation) in the vendor system. Keep the mapping to patient records in your own database. Name channels by ID, not by patient name. If the chat vendor is breached, or a support engineer views your account, the data shows conversations between opaque IDs rather than named patients. This reduces exposure; it does not remove the need for the BAA if message bodies still carry PHI.

System of record. Decide where the authoritative history lives:

Option	What it means	Trade-off
Vendor-hosted history	The vendor stores messages; your app fetches them	Less to build; retention, deletion and export depend on vendor features and BAA scope
Your own store, vendor as transport	Messages are written to your database and delivered through the vendor	More to build; you control retention, audit and patient access requests

Choose before you write code, because migrating later means moving live clinical conversations.

Attachments. Either store files in your own BAA-covered storage and send only a reference (an object key or a signed, expiring URL) through chat, or confirm that the vendor's attachment storage is in BAA scope.

Client side. The client is where analytics SDKs, crash reporters and local caches live. See HIPAA-compliant chat SDKs for client-side considerations. If you need full control of hosting, a self-hosted stack is an option, with its own safeguards burden; see open-source chat under HIPAA.

Diagram note for designer: Left to right: patient app and clinician web app → your app server (auth, authorization, token issuer, patient-ID mapping) → chat vendor API (messages, channels) and your attachment storage (BAA-covered). Dashed lines from the vendor to the push provider (generic alert only) and to your webhook endpoint. Below: your audit log store and backup. Color each box by BAA status: covered, not covered, no PHI by design.

Security Rule safeguards applied to chat

The Security Rule is technology-neutral. Here is how its safeguards translate to a chat feature.

Access control and authentication.

• Unique user IDs for every patient and staff member; no shared inboxes with shared logins.
• MFA for clinicians and administrators.
• Session timeout on the client, and token expiry on the server.
• Role-based channel permissions enforced by your server.

Transmission security and encryption at rest. Require TLS between all hops. Ask the vendor what it documents for encryption in transit and at rest, and verify your own components (your database, object storage, log store, backups). On encryption generally, the Security Rule treats it as an implementation specification, and HHS's position on "addressable" specifications needs to be quoted accurately. HHS OCR FAQ 2001 says the final Security Rule made encryption an addressable implementation specification. It must be implemented if a risk assessment finds it reasonable and appropriate. Otherwise the entity must document why and use an equivalent alternative where reasonable. Addressable does not mean optional. (hhs.gov) End-to-end encryption is a design choice with trade-offs (server-side search, moderation, record-keeping, multi-device history). This page does not treat it as a legal requirement.

Audit controls. Decide what you log: who sent, read, exported or deleted which conversation, and when. Decide where those logs live, who can read them, and how long you keep them. Avoid putting message text in the audit log. Log the event and the IDs.

Retention and deletion.

• Set a message retention period by policy, then configure it in the vendor system or your own store.
• Check whether the vendor offers a deletion API and whether deletion reaches replicas and backups.
• Plan for patient access requests: you must be able to find and export a patient's conversation, which is far easier when your own store holds the system of record.

Integrity and availability.

• Understand the vendor's delivery guarantees and what happens to messages in flight during an outage.
• Show the sender a clear failed or pending state. A patient who thinks a symptom message was delivered when it was not is a patient-safety issue, not only a UX one.
• Define a fallback, such as a phone number to call for urgent issues, and display it in the chat UI.

Push notifications, SMS and email fallbacks

A push payload that contains message text can show on a locked screen and passes through the push provider (APNs or FCM). Those providers are separate parties from your chat vendor. Google does not list Firebase Cloud Messaging among the services covered by its BAA, and we found no Apple documentation offering a BAA for APNs, so keep PHI out of push payloads. (docs.cloud.google.com)

The safer pattern is a generic alert: "You have a new message." The app opens, the user authenticates, and the client fetches the content from your server or the chat API. Avoid the clinic name or provider specialty in the alert if it would reveal sensitive care, for example "New message from Oncology."

SMS and email are separate channels with separate BAA questions. Treat them as outside the chat API unless the vendor's BAA says otherwise. If you add an "unread message" fallback, send a generic prompt with a link to log in, not the message.

Design review checklist for a privacy officer

Ask the vendor (answers should be in the BAA, security documentation or trust page):

• Which products, plans and features does the BAA list, and which does it exclude?
• Who are the subprocessors, and how are they covered?
• What are token lifetimes, encryption practices, retention settings and deletion options?
• Where are attachments stored, and are they in BAA scope?
• What happens to data when the contract ends?

Ask engineering:

• Show the data-flow diagram with every hop labeled.
• What is the token lifetime, and how is a token revoked when a staff member leaves?
• What do the application, webhook and error logs contain? Does any contain message text?
• Which third-party SDKs are in the client, and what do they collect?
• What does the push payload contain?

Document the decision. Record the architecture and the chosen controls in your risk analysis. Keep the signed BAA, the vendor's covered-services list, and a record of your configuration settings. Re-review when the vendor adds features or when you add an SDK.

PHI path	Owner	Control	Evidence to keep
Message body in transit and storage	Vendor and customer	BAA covering the service; TLS; encryption at rest; access control	Signed BAA, covered-services list, configuration export
Attachments	Customer, or vendor if in BAA scope	Own BAA-covered storage with signed expiring URLs, or confirmed vendor scope	Storage config, vendor attachment documentation
User IDs and channel names	Customer	Opaque IDs; mapping held in your system	Data model, sample records
Chat tokens	Customer	Short lifetime, server-side issuance, revocation	Token settings, offboarding procedure
Push payloads	Customer (push provider separate)	Generic alert only	Payload samples, test screenshots
SMS and email fallbacks	Customer, plus provider	Generic prompt; separate BAA review	Provider BAA, message templates
Webhooks and search indexes	Customer	Minimize content; protect endpoints; BAA for any third party receiving PHI	Endpoint inventory, recipient BAAs
Application and error logs	Customer, and vendor for dashboard logs	No message text in logs; access limits; retention	Log samples, retention settings
Analytics and crash SDKs	Customer	Remove from chat screens or confirm BAA and data collected	SDK inventory, vendor terms
Backups	Vendor and customer	Retention aligned to policy; deletion reaches backups	Backup policy, deletion test records
Audit trail	Customer	Log events and IDs, not content	Log schema, review records

FAQ

Does a BAA with the chat API vendor make my telehealth app HIPAA compliant?

No. The BAA covers the vendor's services as listed in it. Your application, your servers, push and SMS channels, logs, analytics and staff procedures remain your responsibility. Compliance depends on a signed BAA, configuration and your policies.

Can I send PHI through a chat API without a BAA?

If the vendor creates, receives, maintains or transmits PHI on your behalf, HIPAA expects a business associate agreement with it. Under 45 CFR 160.103, a business associate is a person who, on behalf of a covered entity, creates, receives, maintains or transmits PHI for a regulated function or activity. 164.502(e) and 164.308(b) require satisfactory assurance documented in a written contract. (ecfr.gov) If you cannot get a BAA for the services you need, design so that PHI does not reach that vendor, or choose another vendor.

Is end-to-end encryption required for HIPAA text chat?

This page does not treat it as required. The Security Rule addresses encryption as an implementation specification. HHS says encryption is an addressable implementation specification, not a required one: it must be implemented where reasonable and appropriate after risk assessment, and otherwise the reasoning must be documented along with an equivalent alternative where reasonable. (hhs.gov) You still need a documented risk analysis showing how you protect data in transit and at rest.

Should message content go in push notifications?

No. Send a generic alert and fetch content after the user authenticates. Push payloads can appear on lock screens and pass through the push provider.

Where should I store chat history: with the vendor or in my own database?

Either can work. Vendor-hosted history is less to build but ties retention, deletion and export to the vendor's features and BAA scope. Your own store gives you control of audit, retention and patient access requests, with the vendor acting as transport. Decide before launch.

Do analytics and crash-reporting SDKs in a chat client need a BAA?

If the SDK can receive PHI, including identifiers, screen content, message text in crash dumps or device data tied to a patient, treat the SDK vendor as needing review and, where PHI is involved, a BAA. The simpler path is to keep these SDKs off chat screens and scrub payloads.

How long do I have to retain chat messages?

The answer depends on whether the messages are part of the medical record and on state law. HIPAA also has a six-year documentation retention requirement for certain policies and records. Under 45 CFR 164.316(b)(2)(i), documentation required by the Security Rule must be retained for 6 years from the date of its creation or the date it last was in effect, whichever is later. This covers Security Rule policies, procedures and records of required actions and assessments. By its text it does not set a retention period for message content, so confirm with counsel. (ecfr.gov)

How is a chat API different from a chat SDK or an off-the-shelf chat app?

A chat API is a set of server endpoints you call to create users, channels and messages. An SDK is client or server code that wraps the API and often adds UI components, which means more code running on your patients' devices. See HIPAA-compliant chat SDKs for the client-side view. An off-the-shelf chat app is a finished product with its own interface; it is outside this page's scope.

Sources and last verified