How to Build HIPAA-Compliant Video Chat (and When to Use Open Source)

You can build video chat that carries PHI by embedding a vendor video SDK under a BAA, self-hosting an open source WebRTC stack on infrastructure covered by a cloud BAA, or combining the two. HIPAA attaches to who handles PHI and how, not to a codebase, so open source is allowed, but no project hands you compliance. This guide covers each path and the obligations you keep under it. For the wider picture, see HIPAA-compliant video chat.

Short answer: three ways to build, and what each leaves you responsible for

Compliance depends on a signed BAA, your configuration and your organization's policies. No library, protocol or vendor makes an app compliant by itself.

Approach	What you build	What the BAA chain covers	What you still own
1. Vendor video API/SDK	App, UX, user management	The vendor's video service, if the BAA names that service and plan	Your app, access control, logging, your own hosting and downstream BAAs, policies
2. Self-hosted open source WebRTC	Everything: media server, TURN/STUN, signaling, client, recording	Only the cloud services your hosting provider lists in its BAA	Patching, hardening, audit logs, backups, incident response, all policies
3. Hybrid	App, signaling, storage	Vendor-managed media, if covered by the vendor's BAA	Your app and storage layers, plus the integration between them

Approach 1 shifts the most operational work to a vendor. Approach 2 gives the most control and the most workload. Approach 3 splits responsibility, so you have to document where one party's duty ends and the other's begins.

First decide whether your video touches PHI

Before choosing a stack, work out your role. If you are a covered entity (a clinic, for example) building video visits for your own patients, vendors that handle PHI for you are business associates and need BAAs. If you are a startup or health IT vendor building video for clinics, your company will likely be a business associate, and you will need BAAs with your clinic customers and with your own subcontractors. HHS cloud computing guidance says a cloud service provider that creates, receives, maintains or transmits ePHI for a covered entity or business associate is itself a business associate, and that a business associate's subcontractor is also a business associate. 45 CFR 164.308(b)(2) requires a business associate to obtain written assurances from its subcontractors. (hhs.gov)

Then list where PHI can appear, because each item changes your scope:

• Audio and video itself. A patient describing symptoms or showing a rash is PHI in transit.
• Participant names and identifiers. Display names, email addresses and phone numbers tied to a visit.
• Appointment metadata. Visit time, provider, clinic name, reason for visit.
• In-call chat messages and shared files. A pasted lab result is PHI.
• Recordings and transcripts. These create stored PHI with retention duties.
• Logs and analytics. Room names or user IDs that map to patients can turn a debug log into a PHI store.

A video feature that never records, never stores identifiers and is used only for non-clinical calls may fall outside PHI. Once it is used for visits with patients, assume it is in scope.

Build with a vendor SDK: BAA scope and what to check

Embedding a vendor SDK is the shortest path to launch, but the BAA is where it succeeds or fails. Check these points on the vendor's own BAA and documentation pages:

1. Service and plan coverage. Confirm the BAA names the specific video product and the plan you will use, not just the company. A BAA that covers one product does not automatically cover another.
2. Exclusions. Look for recording, transcription, AI features, SMS or email notifications, and beta or preview products.
3. Subprocessors. Find out which subprocessors touch media or metadata, and whether the vendor has BAAs in place with them.
4. Your own downstream BAAs. The vendor's BAA does not cover your cloud hosting, logging service, error tracker or support desk. Any of these that receive PHI needs its own agreement.
5. Configuration obligations. Vendor documentation often lists settings you must enable or avoid, such as disabling recording by default or restricting metadata fields.

This page does not repeat vendor verdicts. The video chat providers with a BAA compared page covers BAA status by provider, plan and service.

If your video visit also needs text chat or file exchange, the same BAA-scope questions apply to that service. See HIPAA-compliant chat APIs for developers for how chat SDKs are evaluated.

Build with open source: what the license does and does not give you

An open source license gives you code access and the right to modify and run it. It does not give you a BAA. No open source project signs one, so for a self-hosted stack the BAA chain runs through your hosting provider, and only for the services it lists. More precisely, the license itself is not a BAA, and the BAA chain runs through your hosting provider and any other vendor that creates, receives, maintains or transmits ePHI for you (for example a hosted TURN, monitoring or notification service), each only for the services its BAA lists. A provider storing only encrypted ePHI without the key is still a business associate. Google Cloud's BAA, for example, names Compute Engine, Cloud Storage, Cloud Load Balancing and Cloud Logging. Check AWS and Azure eligible-service lists directly. (cloud.google.com)

A self-hosted video stack usually has these parts, and you must assess each:

• Media server (SFU or MCU). Routes or mixes audio and video between participants.
• TURN/STUN servers. Help clients connect across firewalls and NATs; TURN relays media when direct paths fail.
• Signaling service. Coordinates who joins which session; usually carries user and room identifiers.
• Client library. Runs in the browser or mobile app.
• Recording service, if you offer recording.

Common self-hosted stacks are built on open-source WebRTC servers; before shortlisting one, read the project's own license and its statements on encryption and recording — this page deliberately names none without those sources in hand.

Hosting these yourself means you own:

• Patching of the OS, the media server and every dependency
• Access control to servers, consoles and keys
• Audit logging and log retention
• Backups and tested restores for anything that stores PHI
• Incident detection and response

The cost trade-off is real. License cost goes down, but operational and security workload goes up. A two-person team with no on-call rotation may find that a media server outage during clinic hours costs more than a vendor's per-minute fees.

Technical safeguards checklist mapped to the Security Rule

The Security Rule's technical safeguards cover access control, audit controls, integrity, person or entity authentication and transmission security. These are set out in 45 CFR 164.312: (a) access control, (b) audit controls, (c) integrity, (d) person or entity authentication and (e) transmission security. Some implementation specifications are addressable, which does not mean optional. (ecfr.gov) The checklist below maps video-specific work to those headings. The rule is flexible about how you meet it, so document your decisions.

Transmission security

• Media uses DTLS-SRTP and signaling uses TLS. WebRTC keys media encryption with DTLS-SRTP, but it does not define signaling, so running signaling over TLS (HTTPS or secure WebSockets) is your implementation choice, not a protocol guarantee. HIPAA's transmission security standard is 45 CFR 164.312(e)(1), and its encryption specification is addressable. (rfc-editor.org)
• A standard SFU design decrypts media at the server to route it. That is acceptable only if the server is inside your covered environment. End-to-end encryption between clients changes that, but it adds key management and typically limits server-side recording. More precisely, an SFU that decrypts media is acceptable when it runs on infrastructure covered by a BAA and included in your risk analysis. End-to-end encryption reduces what the server can see, but it does not remove the BAA requirement: HHS says a provider holding encrypted ePHI without the key is still a business associate. A hosted TURN provider also generally needs a BAA, because HHS reads the conduit exception narrowly. (hhs.gov)
• Encrypt TURN traffic and confirm what TURN relays can observe.

Access control and authentication

• Unique user IDs for staff and patients, with no shared logins.
• Authenticated and authorized room join. A patient should only reach their own appointment's room.
• Short-lived join tokens issued by your backend, not long-lived API keys in the client.
• No guessable room links. Use unpredictable room identifiers and expire them after the visit.
• Automatic session timeout for staff consoles.

Audit controls

• Log who joined which session, when, and from what account.
• Keep PHI out of logs: no names in room titles, no message bodies, no raw SDP dumps tied to identifiable users.
• Test that logs are retained, protected from alteration and reviewable.

Recording and storage

• Recording off by default, turned on per visit by an authorized role.
• Encrypted at rest, with keys managed separately from the storage.
• Retention and deletion rules that match your records policy.
• AI note-taking or transcription creates new PHI flows and needs its own BAA review; see AI chat and PHI.

Integrity

• Protect stored recordings and visit records against unauthorized modification.

Administrative and organizational requirements that code cannot cover

Most HIPAA obligations are not technical, and a clean architecture does not satisfy them.

• Risk analysis. Cover the video feature before launch, including vendors, hosting, logs and recordings. The Security Rule requires this under 45 CFR 164.308(a)(1)(ii)(A), an accurate and thorough assessment of risks and vulnerabilities to the confidentiality, integrity and availability of ePHI (required), with risk management at 164.308(a)(1)(ii)(B). (ecfr.gov)
• Policies. Write down rules for session recording, screen sharing (a clinician's open EHR tab is a common leak), patient identity verification at the start of a visit, and which staff roles can join or view sessions.
• Incident and breach response. Define who investigates a misdirected link or a lost laptop with a cached recording, and how notification decisions are made.
• Workforce training. Staff should know how to start a visit, confirm identity and end a session correctly.
• BAAs with every vendor that touches PHI. That includes the video vendor, the cloud host, and any support, logging or storage tool that receives PHI.

Build vs. buy: how to decide

Ask these questions first:

• How large is the engineering team, and who is on call when video fails during clinic hours?
• Do you need custom UX, such as a waiting room tied to your scheduling system?
• Does anyone on staff have security experience with real-time media infrastructure?
• What call volume do you expect, and does it justify running your own media servers?
• How quickly do you need to launch?

Factor	Vendor SDK	Self-hosted open source	Hybrid
Control over media path	Limited to vendor options	Full	Partial
BAA coverage	Depends on vendor's BAA for the service and plan	Depends on cloud BAA scope; you cover the rest	Vendor BAA for media plus your own hosting BAA
Operational load	Lowest	Highest	Medium
Time to market	Shortest	Longest	Medium
Customization	Within SDK limits	Unlimited	High on app layer

If you only need video visits for a clinic and do not need to embed anything in your own product, a finished conferencing tool with a BAA may be enough, and building would add cost without benefit. The provider comparison lists options by BAA status, plan and price.

Pre-launch checklist and sources

Use this as a working checklist, not a guarantee of compliance:

• BAAs signed with every vendor and host that touches PHI, covering the specific services and plans you use
• Risk analysis completed and documented for the video feature
• Encryption verified in transit and at rest in your actual deployment
• Audit logging tested, with a check that logs contain no PHI
• Recording policy set, defaulted off, with retention and deletion rules
• Access tested: unauthorized users cannot join, tokens expire, room links are not guessable
• Screen-sharing, identity verification and incident response procedures written and trained

If your clinic needs a different channel, such as website chat or staff messaging, see which kind of chat you need under HIPAA.

FAQ

Can I use WebRTC and still be HIPAA compliant?

Yes, WebRTC can be part of a compliant setup, but the protocol alone does not make an app compliant. Compliance comes from BAAs with the parties that handle PHI, the safeguards you configure around signaling, access, logging and storage, and your policies. It also depends on the risk analysis required by 45 CFR 164.308(a)(1)(ii)(A). Section 164.312 does not mandate any particular technology, and HHS offers no HIPAA certification program. (ecfr.gov)

Is there an open source video chat that is HIPAA compliant?

No open source project can be called HIPAA compliant or certified as a product, and HHS does not certify software. You can run open source software as part of a compliant deployment if the hosting is covered by a BAA and you implement the safeguards and policies yourself. (hhs.gov)

Do I need a BAA if I self-host the video server?

It depends on who hosts it and who can access PHI. If a cloud provider hosts your servers and PHI passes through or is stored on them, you generally need a BAA with that provider covering the services you use. If you run your own hardware and no outside party touches PHI, there may be no hosting BAA, but you still have the full set of safeguard and policy duties. If you build for clinics, you will likely need BAAs with them as a business associate. HHS cloud guidance says using a cloud provider to maintain ePHI without a BAA violates 45 CFR 164.308(b)(1) and 164.502(e). The no-BAA case for self-run hardware is our inference, not an HHS statement. (hhs.gov)

Does end-to-end encryption remove the need for a BAA?

Not automatically. End-to-end encryption can limit what a server can see, but a vendor may still handle metadata, relay traffic, store recordings or provide support access. Whether a BAA is needed depends on whether the vendor creates, receives, maintains or transmits PHI for you. Actually, encryption does not remove the need for a BAA. HHS says a cloud provider that stores or processes only encrypted ePHI and does not hold the key is still a business associate. A BAA may be unnecessary only for a pure transmission conduit (no storage beyond temporary storage incident to transmission) or where the vendor never handles ePHI. Whether TURN relays qualify as a conduit is a legal question HHS has not addressed. (hhs.gov)

Can I record video visits, and what changes if I do?

You can, but recording creates stored PHI. You need a recording policy, a BAA that covers the recording feature (vendors may exclude it), encryption at rest, retention and deletion rules, and access controls on who can view recordings. Patient consent requirements vary by state. Encryption at rest is an addressable specification under 45 CFR 164.312(a)(2)(iv), so document your decision. Confirm state recording-consent rules with counsel. (ecfr.gov)

Do I need a BAA with the cloud provider hosting my media server?

If PHI is processed or stored on that provider's services, yes, and the BAA must cover the specific services you use. A cloud BAA typically lists covered services, and anything outside that list is not covered. For example, Google's BAA defines Covered Services as the products identified on its HIPAA page and applies solely with respect to Covered Services. (cloud.google.com)

How do I handle chat messages and file sharing inside the call?

Treat them as PHI. Run them through a service covered by your BAA chain, apply the same access control and audit logging as the video session, and set retention rules for messages and files. If you use a separate chat SDK, confirm its BAA covers that service; see HIPAA-compliant chat APIs for developers for the evaluation criteria.

Sources and last verified