Self-hosted Jitsi for HIPAA telehealth safeguards

The transit protection that Jitsi documents covers audio and video. According to jitsi.org, Jitsi Meet encrypts audio and video on the network with DTLS-SRTP, and the videobridge decrypts packets in memory only to route them, without storing them. That statement describes the upstream design. Confirm it against your own architecture before you rely on it for telehealth: identify which hosts run the videobridge, whether Jibri, Jigasi or any logging component sees the same media path, and whether a reverse proxy or load balancer terminates TLS. Decrypted media that passes through a proxy, a packet capture host or a debug log carries a different risk from the one the vendor describes, and your transmission security assessment needs to address each of those points.

End-to-end encryption is a separate and narrower control. According to jitsi.org, Jitsi Meet offers it in Chromium 83 or later and in the Jitsi Electron client. It covers audio, video and screen sharing, but it does not cover chat or polls. For a visit, this means media protection depends on the browser or client in use and on whether the feature is enabled for that session. Decide whether E2EE is required for every visit type or only some, and align the policy with the browser versions your clinicians and patients actually use. Also confirm with the Jitsi documentation for your release how E2EE interacts with any recording, streaming or transcription component you enable, because those components process media on the server side and need their own review.

The HIPAA mapping does not end in a simple yes or no. 45 CFR 164.312(e)(1) requires technical security measures to guard against unauthorized access to ePHI transmitted over an electronic communications network. Its two implementation specifications, integrity controls and encryption, are both addressable under Appendix A to Subpart C. Addressable does not mean optional. For each specification, the covered entity must assess whether it is reasonable and appropriate, document the reasoning if it is not, and implement an equivalent alternative where that is reasonable. The default DTLS-SRTP protection supports the encryption assessment, but the file still needs the decision record, the configuration evidence and the E2EE setting for each visit type. No HIPAA certification can substitute for that record, because HHS states that private certifications do not prevent a later finding of violation.

Certificates are where many self-hosted deployments fail. The Jitsi handbook states that HTTPS with a proper domain certificate is necessary for working audio and video, and it warns that self-signed certificates cause problems, especially with mobile clients. For telehealth, a failed mobile connection during a visit is an availability problem, and staff under time pressure may move the call to an unmanaged tool. Plan for a certificate from a certificate authority that patient and clinician devices trust, with renewal automated and monitored. Test on the iOS and Android clients your patients use, because a passing desktop test does not prove mobile access works. Keep the certificate chain and TLS settings in the evidence set so the transmission security assessment can point to them.

Recordings, transcripts and chat sit outside the transmission controls that protect the video stream, so each needs its own access, storage and disposal decisions. Jibri recordings and Jitsi transcripts are written to ${CONFIG}/storage/jibri and ${CONFIG}/storage/transcripts in the Docker layout from stable-11146. Once a file lands in those directories, it is a store of electronic protected health information. DTLS-SRTP protects audio and video in transit, and the videobridge does not keep media, so the files on disk are the point where your team must add controls. Decide who can read these directories, how the files are encrypted at rest, how long they are kept and how they are securely deleted before the deployment goes live. Jibri records a conference by running Chrome in a virtual framebuffer and encoding the output with ffmpeg. Its README states that one recording at a time is supported on a single Jibri, which should run on its own machine or VM. For telehealth, this means concurrent recorded visits require additional, isolated Jibri instances, and each one needs its own host hardening, restricted operating system accounts and monitored storage. Confirm with your privacy officer and clinical leads whether visits may be recorded at all, how patient consent is captured and who can start a recording. Those answers determine how many Jibri hosts you need and which staff accounts get the Jibri role in the Jitsi configuration. Jigasi transcription can use Google Cloud, Vosk or Whisper backends, and the choice determines where the audio or text goes. A cloud backend sends speech data to a third party, which generally means you need a business associate agreement with that provider before any ePHI is processed. Under 45 CFR 164.314(a)(2)(i), such a contract must require the business associate to follow the Security Rule, flow the same terms down to subcontractors and report security incidents. Confirm whether the provider will sign that agreement for the service you plan to use. For self-hosted Vosk or Whisper, confirm the configuration keeps audio and transcripts inside your environment, including logs and any model download or update traffic. Chat and polls are not covered by end-to-end encryption, even when that setting is enabled for audio, video and screen sharing. Treat text typed during a visit as ePHI. Decide whether chat is logged or retained, and set a clinical policy on what clinicians may type into it. The same question applies to shared notes from Etherpad and whiteboards from Excalidraw if you enable them. Test whether a message remains in server memory, browser history or any stored file, and confirm which components handle that text and where it can be exported. Before enabling any optional component, document its data flow in your risk analysis. Record what data it creates, where it is processed, where it is stored, who can access it, how long it is kept, how it is deleted, what is logged and whether a business associate agreement is needed. Where a safeguard is addressable, record the decision and any equivalent measure under 45 CFR 164.306(d). Ask your Jitsi implementation partner to show the storage paths, permissions and retention settings on a test deployment before any clinical visit uses the component.

Before anyone changes a Jitsi configuration for telehealth, your team has to hand over a set of decisions and facts that the technical work cannot infer. The first is the current telehealth workflow: which visit types run on video, who starts a meeting, whether patients join from a link, a waiting room or an app, and where any clinical content is discussed beyond the video itself. Those answers determine which Jitsi features are in scope at all. Without them, the risk analysis under 45 CFR 164.308 has nothing concrete to test, and the configuration will either be too loose for the visit or too restrictive to be used.

The second input is the identity source. Decide how clinicians are verified and how patients are verified before they join a room. Jitsi's documented options include internal XMPP accounts, JWT tokens, LDAP, Matrix user verification and a hybrid Matrix plus JWT mode, set through the .env file in the Docker layout. Your team needs to choose which source is authoritative for clinicians, whether patients are issued room-specific tokens, and who owns the directory those tokens depend on. The Jitsi handbook recommends JWT token authentication over the deprecated secure domain method for new installations, so confirm that choice with your identity owner before any settings are written.

Third, confirm ownership of the network, the domain and the certificate. Jitsi needs HTTPS with a proper domain certificate for working audio and video, and the handbook warns that self-signed certificates cause problems, particularly on mobile clients. Your team must name who controls the DNS zone, who issues and renews the certificate, and which firewall rules expose ports 80/TCP, 443/TCP and 10000/UDP. Fourth, state where the servers will run and whether that environment is covered by a business associate agreement, or whether it is operated under your own covered entity controls. Jibri recording hosts and any transcription backend must be placed in the same decision, because each one may handle ePHI.

Finally, decide in writing whether recordings and transcripts are permitted at all. If they are, name the retention period, the storage location under the Jibri and transcript paths, and who may access them. Identify the people who will sign off on the risk analysis and the residual risk, typically a privacy or compliance officer and a clinical lead, and confirm that they will review the configuration before go-live. Responsibility is split: your organization decides policy, retention, access rules and the attestations it will make, while the technical configuration and its evidence are prepared by the implementation team. Ownership of policies and attestations stays with your organization throughout.