Self-hosted video conferencing for HIPAA telehealth: what the Security Rule asks
A covered entity or telehealth operator deciding whether to host video visits on its own servers should start with the transmission security standard in 45 CFR 164.312(e)(1), which requires technical measures that guard against unauthorized access to ePHI sent over an electronic communications network. The addressable encryption specification in 164.312(e)(2)(ii) governs the media path itself. Self-hosting shifts who operates the servers, the TLS termination, the media relays and any recordings, but it does not move the obligation. The entity remains responsible for assessing whether encryption is reasonable and appropriate for each flow, documenting its reasoning if it chooses an equivalent alternative, and extending the same safeguards to any vendor that touches ePHI on its behalf.
There is no HIPAA certification for a video platform, and the sentence to avoid in a procurement file is that a product is "HIPAA certified." HHS states that no Security Rule standard requires certifying compliance and that it does not endorse or recognize private certifications. The HHS Office for Civil Rights enforces the Security Rule through complaint investigations, compliance reviews and audits, and its 2024 to 2025 audit program reviewed 50 covered entities and business associates on provisions most relevant to hacking and ransomware. The evidence an assessor will ask for is therefore your own: a documented risk analysis that addresses encryption for each media path, configuration records for the video stack, and access and audit logs under 164.312(b). Confirm with your compliance counsel which of these your organization must hold before go-live.
Two regulatory points change the design before any server is provisioned. The Security Rule revision proposed on January 6, 2025 (90 FR 898) had no final rule as of October 2026, so the current text still governs, and the Unified Agenda projects final action for July 2027. Second, a hosting provider becomes a business associate when it creates, receives, maintains or transmits ePHI for you, which is the question covered in the next section. Ask any managed-service partner for its written position on the business associate agreement before it touches session logs, recordings or waiting-room data.
Which Security Rule requirements a self-hosted telehealth video stack must meet
This table maps each HIPAA Security Rule requirement that touches telehealth video to what the stack must do and how Jitsi Meet or BigBlueButton can be configured to support it. Read each row as a question to answer in your risk analysis, then confirm the decision and the evidence with your compliance lead and your hosting partner. The main takeaway is that the Security Rule sets outcomes and leaves the method to you, so the configuration choices must be documented.
| Requirement | What the stack must do | Configuration to confirm |
|---|---|---|
| 164.312(e)(1) transmission security | Guard against unauthorized access to ePHI sent over the network during patient sessions, chat and recordings. | HTTPS with a valid domain certificate for Jitsi Meet; a valid hostname and SSL for BigBlueButton; no self-signed certificates for clients. |
| 164.312(e)(2)(ii) encryption in transit (addressable) | Decide whether encryption is reasonable and appropriate for each transmission path, and encrypt where it is. | Confirm TLS on the web app, signaling and TURN paths; record the decision and any equivalent alternative if you do not adopt a measure. |
| 164.306(d) addressable decisions | Assess each addressable specification, implement it or document why not and what equivalent measure you use. | Keep a written decision log for encryption and integrity choices tied to the risk analysis, including any optional features you leave off. |
| 164.312(b) audit controls | Record and review activity in systems that hold ePHI, such as session starts, room access and admin changes. | Confirm which logs Prosody, Jicofo, Jitsi Videobridge or BigBlueButton produce, where they go, who reviews them and how long they are kept. |
| 164.308(b)(1) business associate assurances | Obtain satisfactory assurances before a hosting or support provider creates, receives, maintains or transmits ePHI for you. | Decide whether your hosting or managed support provider handles ePHI; if so, execute the required agreement before go-live. |
| 164.308(b)(2) subcontractor assurances | Require the same assurances from any subcontractor the provider uses that can touch ePHI. | Ask the provider to list subcontractors such as cloud, TURN or recording storage vendors and confirm each has its own agreement. |
| Access control for rooms and guests | Limit who can join a patient session and verify identity before entry. | Use JWT token authentication and a separate guest domain; avoid the deprecated secure domain method; use lobbies for patient arrival. |
| Shared secrets and API keys | Keep credentials that sign room access or API calls out of the browser. | Never embed the BigBlueButton shared secret or JWT signing keys in a web page; generate tokens on the server side. |
| Recording storage and retention | Treat any recording or transcript containing ePHI as a record with defined storage, access and deletion rules. | Confirm where recordings land, who can download them, encryption at rest, backup handling and the retention period set by your policy. |
Jitsi Meet or BigBlueButton for patient-facing visits
One-to-one clinician visits and small group sessions, such as a care team conferring with a patient and a family member, fit Jitsi Meet well because each room is lightweight and the clinical workflow is short. The design question is who can enter a room. Jitsi's own guidance has moved away from the older secure domain method, which relies on username and password room creation, and recommends JWT token authentication for new installations. In that model, the scheduling system issues a signed token per visit, and a separate anonymous domain handles guests such as patients who join without an account. The Jitsi Docker guide also lists LDAP and Matrix-based verification, which may suit organizations that already run directory or chat identity.
- JWT per visit: The EHR or scheduling service signs a short-lived token that names the room and the clinician, so a patient cannot enter an unscheduled room.
- Separate guest domain: Patients join through an anonymous domain with restricted room rights, which keeps clinician-only actions out of reach.
- LDAP or Matrix options: Use these only if the clinician directory is already maintained there, and confirm the setting names in the
.envfile for your release. - HTTPS with a valid certificate: Audio and video depend on a proper certificate, and self-signed certificates cause problems, especially on mobile devices.
- Recording off by default: Keep recording disabled unless the clinical policy defines retention, because any recording becomes stored ePHI.
Confirm with the chosen Jitsi version and your EHR scheduling system how tokens are generated and how waiting room or lobby behavior is configured before you commit to this model.
Scheduled group education, peer support and patient group sessions have different needs. They involve presenters, slides, polls, breakout rooms and a set schedule, which is the virtual classroom model BigBlueButton was built for. BigBlueButton 4.0 installs on Ubuntu 24.04 64-bit, and the install documentation recommends a clean server because direct upgrades from 2.6, 2.7 or 3.0 are not supported. Greenlight v3 is the front end for room management, and it supports external authentication through OpenID Connect, which the documentation suggests pairing with Keycloak for other login methods.
- Sizing floor: The install docs call for at least 16 GB of RAM with swap and 8 CPU cores with high single-thread performance for a BigBlueButton 4.0 server.
- Recording storage: Recordings need 500 GB of disk, while a server without recording needs 50 GB, so size storage from the expected session count and the retention period.
- OpenID Connect sign-in: Greenlight v3 can use an external identity provider, which lets staff and clinicians sign in with the organization's accounts.
- Network reachability: TCP ports 80 and 443 and UDP ports 16384 to 32768 must be reachable, and a TURN server is recommended for patients behind restrictive firewalls.
- Secret handling: Every API call must carry a checksum made with the shared secret, and that secret must never appear in a web page, so integrations with the scheduling system should run server-side.
Confirm with the chosen BigBlueButton release and your scheduling or LMS integration how room creation, patient access and recording retention are configured before procurement.
Both platforms need an answer to who the user is and how they get in, and that answer shapes the HIPAA access control and audit story. On Jitsi, the choice is between internal XMPP accounts, JWT tokens, LDAP, Matrix verification and a hybrid Matrix plus JWT mode. On BigBlueButton, the choice is mostly between Greenlight's local accounts and an OpenID Connect provider. Either way, patients should not hold standing accounts unless the clinical program needs them, and each visit should be tied to a scheduled appointment.
- Clinician identity: Map clinicians to the directory or identity provider that already controls clinical system access, so deprovisioning follows one process.
- Patient access: Prefer time-limited, per-visit links or tokens over reusable passwords shared by email.
- Audit trail: Log who joined which room and when, because the Security Rule's audit controls require mechanisms that record and examine activity in systems containing ePHI.
- Shared secrets: Store the Jitsi and BigBlueButton secrets in a secrets manager and rotate them on a documented schedule.
- Check against the release: Authentication options and configuration keys change between releases, so verify them against the documentation for the version you deploy.
Ask your implementation partner to show how each visit is authorized end to end, from scheduling through room entry and log retention.
Whether a hosting provider becomes a business associate depends on whether it creates, receives, maintains or transmits ePHI on the covered entity's behalf. If your organization runs Jitsi or BigBlueButton on infrastructure it owns, the platform operator is your staff and no outside hosting provider handles the media. If an outside cloud provider or managed service hosts the servers, recordings or logs, that provider may hold ePHI, and the covered entity must obtain satisfactory assurances under 45 CFR 164.308(b)(1) before permitting it to do so. Any subcontractor that the provider uses for ePHI requires its own assurances under 164.308(b)(2).
- Self-operated servers: Keep the media servers, recordings and logs inside your own accounts and data centers to limit the outside parties involved.
- Hosted or managed operators: Treat the provider as a potential business associate, and obtain a written agreement that covers ePHI before any session runs.
- Subcontractors: Ask which of the provider's subcontractors touch the servers, backups or support access, since they can fall under the same rule.
- Hosted recordings and logs: Storage of recordings, chat logs and connection logs can hold ePHI even when the media path is encrypted.
- Public instances: A free public instance is not a suitable home for patient visits, because the covered entity has no contract or control over it.
Have legal counsel confirm the business associate analysis for each deployment model before the first patient session.
Open-source platforms that fit a HIPAA telehealth video function
A telehealth program usually needs a video engine, a place to exchange ePHI files, and a messaging layer that clinicians will actually use. Each platform below fits a different part of that picture, and each carries license and hosting terms that change what your team must review. No open-source product is HIPAA compliant or certified on its own; compliance comes from how you configure, host and govern it.
Jitsi Meet for patient video visits
Jitsi Meet is licensed under Apache-2.0, and a self-hosted deployment runs a web server, Prosody, Jicofo and Jitsi Videobridge inside your own environment. For telehealth, the design decisions are authentication (the handbook recommends JWT tokens over the deprecated secure domain method), a separate anonymous domain for patient guests, and a valid certificate, since self-signed certificates cause audio and video problems. Confirm which encryption modes your clinical workflow needs before you commit.
BigBlueButton for scheduled clinical sessions
BigBlueButton is licensed under LGPL-3.0 and suits scheduled sessions such as group education, care team reviews and structured consults, with chat, shared notes and polling built in. Its 4.0 install requires a clean Ubuntu 24.04 server, and it needs TCP 80 and 443 plus UDP 16384 to 32768 reachable. Recordings of patient content are ePHI, so storage location, access and deletion must be settled before enabling recording.
Nextcloud for secure ePHI file exchange
Nextcloud Server is licensed under AGPL-3.0 and can hold consent forms, referral letters and visit summaries that a clinician needs to send before or after a video visit. The HIPAA transmission security standard requires guarding ePHI in transit, so confirm TLS on every endpoint, enable audit logging for access to ePHI, and decide how share links expire. Pair it with a documented retention rule so files do not sit indefinitely on the server.
Mattermost or Rocket.Chat for clinician messaging
Mattermost compiled releases are licensed under MIT, while its source may be used under AGPL-3.0 subject to listed exceptions. Rocket.Chat is MIT except for content in its ee directories, which uses a separate enterprise license. Before choosing, check which features your deployment depends on, confirm which license covers each component you install, and verify that message retention and audit export meet your policy. Do not assume chat is covered by the video configuration.
Synapse where Matrix federation is needed
Synapse, the Matrix homeserver maintained by Element, is licensed under AGPL-3.0. Choose it only when clinicians must message across organizational boundaries that do not share one server, because federation sends messages to other homeservers you do not control. Each federated link adds a third party to the ePHI data flow, which means an assessment and, where that party handles ePHI for you, the business associate analysis covered elsewhere on this page.
Business associate and subcontractor agreements
The software license is not the compliance question. If a hosting provider, managed service or support firm can create, receive, maintain or transmit ePHI on your behalf, you need a business associate agreement with them, and any subcontractor they use needs its own assurances. Self-hosting inside your own cloud account can narrow this, but confirm with counsel how your provider's terms apply to your specific setup before you rely on that position.
When a hosting provider becomes a business associate
A provider that creates, receives, maintains or transmits ePHI on a covered entity's behalf is a business associate, and under 45 CFR 164.308(b)(1) the covered entity may allow that access only after obtaining satisfactory assurances under 164.314(a) that the information will be safeguarded. For a telehealth deployment, the question is practical: if a party operates the video servers, stores session recordings, holds waiting room logs or administers the accounts that connect clinicians to patients, that party is likely handling ePHI. A subcontractor that handles ePHI for the business associate needs the same assurances under 164.308(b)(2), so every hosting company, data center operator or managed service firm in the chain must be identified and covered. Confirm each party's role in writing before any patient data touches the system.
The classification turns on who operates the stack and where it runs. When DeployOpen plans, installs and supports a Jitsi Meet or BigBlueButton deployment inside the client's own cloud account or data center, under a written scope, the client keeps control of the servers, the recordings and the access credentials. Whether DeployOpen then needs a business associate agreement depends on whether its staff access ePHI during implementation or support, and that is for counsel to decide. When a vendor instead hosts the same software on its own infrastructure, that vendor stores and transmits the ePHI itself and is much more clearly a business associate, with the subcontractor chain extending into its own providers. Counsel should decide the classification for each engagement, and the written scope should state who may access production systems and recordings.
Evidence auditors and OCR ask for from a self-hosted telehealth video stack
This table lists the evidence an assessor or OCR investigator is likely to request for a self-hosted telehealth video stack, the component that produces each item, and what a reviewer looks for. HIPAA does not issue certifications, so the evidence is what supports a compliance position. Use the table as a checklist to confirm with your compliance lead and implementation partner before the first session with patients.
| Evidence item | Component that produces it | What a reviewer checks |
|---|---|---|
| Risk analysis entry for the video service | GRC system and risk register | Video is listed as a system handling ePHI, with threats to transmission and the controls chosen against them |
| Encryption decision record with addressable rationale | GRC system, signed by the security officer | Why encryption of transmitted ePHI is applied, and for any addressable choice, the documented reasoning and any equivalent measure |
| Certificate and TLS configuration records | Reverse proxy configuration, certificate inventory, Jitsi or BigBlueButton SSL setup | Valid domain certificates in use, supported TLS versions, and no self-signed certificates on patient-facing paths |
| Authentication configuration | Jitsi .env and Prosody settings (JWT, LDAP or Matrix modes), Greenlight external authentication for BigBlueButton | JWT token authentication is enforced, the deprecated secure domain method is disabled, and guest access uses a separate anonymous domain |
| Access and audit logs | Reverse proxy logs, Prosody or BigBlueButton logs, central log store | Who joined which room and when, with logs retained and protected from unauthorized change |
| Recording and retention policy | Jibri or BigBlueButton recording storage, GRC policy record | Whether recordings containing ePHI exist at all, where they are stored, who can view them, and when they are deleted |
| Signed business associate agreements or assurances | Contract repository, legal team | A signed agreement with any hosting or support provider that can access ePHI, and subcontractor assurances where applicable |
| Change and upgrade records | Git or configuration management, ticketing system, release notes | Each version change, who approved it, test results, and the date it reached production |
| Backup and restore test results | Backup software logs, test runbook, GRC system | Evidence that configuration and any stored data can be restored, with dated test outcomes and the issues found |
What the open-source video stack does not settle on its own
Self-hosting gives a telehealth program control over where media and recordings live, but it does not produce HIPAA compliance by itself. The gaps below sit with the covered entity or its business associates, and each one changes what the video platform must be paired with before patient sessions start.
Risk analysis and policies stay with you
The Security Rule expects the covered entity to decide whether and how encryption is used, and HHS OCR's risk analysis guidance treats that decision as one the risk analysis should inform. No open-source package performs that analysis for you. Document which telehealth data flows exist (video, chat, recordings, waiting-room data, scheduling links), who can reach them, and which safeguards you chose and why. Confirm the analysis covers the self-hosted servers, their logs and their backups, not only the application.
No certification means no vendor badge
HHS states that no Security Rule standard requires certification, and that it does not endorse or recognize private certifications. A logo, a self-declared compliance page or a certificate from a vendor or consultant is therefore not evidence of HIPAA compliance. Ask for the evidence instead: your own written risk analysis, configuration records for TLS and authentication, access reviews, audit logs and the agreements you hold with each business associate. Independent assessments come from auditors you engage, and DeployOpen prepares the evidence for them but does not issue them.
End-to-end encryption is a separate control
Transport encryption protects media between the client and the media server, which is what the transmission security standard addresses. End-to-end encryption protects media so that the server cannot read it, but it limits features such as server-side recording, transcription and some guest access. Choose the control per meeting type and record that choice in the risk analysis. Confirm which clients and browsers support end-to-end encryption on your Jitsi version before you promise it to clinicians or patients.
The 2025 Security Rule revision is pending
HHS proposed a major Security Rule revision on January 6, 2025 (90 FR 898), with comments due March 7, 2025. As of October 2026 no final rule has been published, and the latest Unified Agenda lists final action as projected for July 2027. Requirements for encryption, audit controls and business associate oversight could change before then. Build the telehealth design so that the controls can be tightened without rebuilding the platform, and assign an owner to track the rulemaking.
NIST SP 800-66 Rev. 2 is guidance only
NIST SP 800-66 Rev. 2, published in February 2024, maps key activities and sample questions to every Security Rule standard. HHS lists it as informational, not legally binding. Use it as a checklist for designing the telehealth controls and for writing the evidence file, but do not cite it as the standard you meet. Where a sample question does not fit a self-hosted video design, record the reasoning in your documentation.
What a HIPAA Security Rule failure can cost
Penalty exposure under HIPAA is set by what the organization knew and how fast it corrected the problem, not by the platform choice alone. For penalties assessed on or after January 28, 2026, the inflation-adjusted civil money penalty in 45 CFR 102.3 for violations on or after February 18, 2009 runs from $145 per violation where the entity did not know of the violation, up to $2,190,294 per violation for uncorrected willful neglect, with a calendar-year cap of $2,190,294. Telehealth teams should read those figures as a ceiling on what a single failure category can cost, and they should confirm the current table with counsel before using it in a board paper, since the amounts are adjusted over time.
Knowledge and correction drive where an organization lands in that range. A self-hosted Jitsi or BigBlueButton deployment that carries patient sessions without HTTPS on the web tier, without a documented decision on the encryption implementation specification under 164.312(e)(2)(ii), or with no record of who changed the server configuration is the kind of gap that becomes harder to defend once someone has noticed it. The practical step is to keep a dated risk analysis entry for the video platform, a configuration baseline for the .env file or the BigBlueButton server settings, and a ticket trail showing when each gap was found and closed. Ask the implementation partner to deliver those artifacts as part of the handover, not after an incident.
The HHS Office for Civil Rights audit program reviews covered entities and business associates against Security Rule provisions most relevant to hacking and ransomware, so a telehealth video service is in scope for an audit even when it looks like a small tool. Expect an auditor to ask for the audit controls required by 164.312(b), the transmission security decision, and evidence that patient-facing access is authenticated. Confirm with your counsel and your partner which logs the platform writes, where they are stored and how long they are kept, because those answers determine whether your evidence survives an audit request.
How much does self-hosted HIPAA telehealth video cost and what does the work need from us?
What drives the cost of self-hosted HIPAA telehealth video?
The main cost drivers are the media servers, bandwidth, TURN relay capacity, recording storage, identity integration and the assessment effort around them. Servers and bandwidth scale with peak concurrency, so the number of simultaneous visits matters more than the number of registered clinicians. The BigBlueButton 4.0 install docs list a minimum server of 16 GB of RAM with swap, 8 CPU cores with high single-thread performance, 500 GB of disk for recordings (50 GB without recording) and 250 Mbit/s symmetrical bandwidth. For Jitsi, the scalable setup guide suggests a 4 CPU, 8 GB machine for the central server and 4 or 8 CPU with 8 GB RAM for each videobridge, and it notes that videobridges scale by adding more. Recording storage recurs every month and grows with visit volume and retention rules. Ask any quote to split these costs and show what recurs.
Can our own team build and run this without a partner?
Many teams can run the platform in-house if they already operate Linux servers, TLS certificates, firewalls and container or package-based deployments. The harder parts are the HIPAA-specific work: documenting the risk analysis, deciding how encryption is applied to transmitted ePHI, setting audit controls, and keeping evidence current across upgrades. Jitsi's handbook says valid HTTPS certificates are necessary for working audio and video, and BigBlueButton requires a valid hostname for SSL, so certificate and DNS ownership must be settled before go-live. Be honest about staffing: someone must own patching, monitoring and capacity changes after launch. DeployOpen can plan, implement, harden, document and support self-hosted platforms in your environment, and most engagements are fixed-scope with the scope agreed in writing before work starts.
How long does a fixed-scope self-hosted telehealth rollout take?
Duration depends on scope, which is why no general timeline is given here. The main variables are the number of platforms (Jitsi, BigBlueButton or both), the number of integrations with scheduling and the EHR, the authentication model, whether recording and patient waiting rooms are in scope, and how much of the risk analysis and policy work is included. A single platform with standard SSO and no recording will take far less time than a multi-server deployment with recording storage, LDAP or JWT integration and formal evidence collection. Ask for a written phase plan with dated milestones, and ask which phases depend on your own approvals, such as change windows, certificate issuance and legal sign-off.
What does the work need from our clinical, security and legal teams?
The work needs three kinds of input. First, your risk analysis: the HHS OCR guidance on risk analysis names deciding whether and how to use encryption as a decision the risk analysis should inform, so your security lead must supply current system inventories, data flows and threat assumptions. Second, clinical workflow owners who define who may join a visit, how patients are admitted from a waiting room, how guests are verified, and what gets recorded. Third, legal review of retention periods, consent language for recordings and the business associate position. Also name a technical owner who can approve firewall rules for TCP 80 and 443 and UDP 16384 to 32768 for BigBlueButton, or 10000/UDP for Jitsi. Without these inputs the scope cannot be fixed.
Do we need a business associate agreement for a self-hosted video platform?
It depends on who hosts and can access the ePHI. If your own staff run the servers inside your infrastructure and no outside party creates, receives, maintains or transmits ePHI on your behalf, a business associate agreement is generally not needed for the software itself. If a hosting provider, managed operator or support firm can access ePHI on your behalf, HIPAA requires you to obtain satisfactory assurances under 45 CFR 164.314(a) before permitting that access, as set out in 45 CFR 164.308(b)(1). Those assurances are typically documented in a business associate agreement. Any subcontractor that handles ePHI for that partner also needs assurances under 45 CFR 164.308(b)(2). Confirm the classification with your privacy officer and counsel before signing a scope that gives a partner access to recordings or logs.
What should a quote include for a self-hosted telehealth video project?
A usable quote should state the scope in writing and separate one-time work from recurring costs. Ask for the list of platforms and versions to be deployed, the number of servers and their sizing basis (peak concurrency, bandwidth, storage), the TURN and firewall plan, the authentication design, and the recording and retention approach. Require explicit line items for risk analysis support, documentation of encryption decisions, audit control configuration, backup and restore testing, and handover training. Ask which items are fixed-scope deliverables and which are retainers for upgrades, monitoring and continuous testing. Also ask who signs any business associate or subcontractor terms, and what the quote assumes about your own team's time. DeployOpen does not publish price lists, so the quote follows from the written scope.
How DeployOpen scopes a HIPAA telehealth video deployment
The written scope moves from the legal relationship to a tested, documented deployment, so the client knows who is responsible for each control before any server is built. DeployOpen prepares the controls and evidence, and independent auditors and certification bodies decide what they are worth.
Classify the hosting relationship with counsel
Before any design work, the client's counsel and compliance lead decide whether the hosting provider, the cloud account owner or DeployOpen will create, receive, maintain or transmit ePHI on the covered entity's behalf. That determines whether a business associate agreement is needed under 45 CFR 164.308(b)(1) and whether subcontractor assurances flow down under 164.308(b)(2). DeployOpen documents the answer in the scope so the work is done only on systems the client has confirmed. Done when counsel has signed off on the classification and the scope names every party that touches ePHI.
Complete the video portion of the risk analysis
The client's security team records every place ePHI can appear in a telehealth session: media paths, signaling, recordings, chat, waiting-room data and logs. For each path, the team decides whether encryption in transit is reasonable and appropriate, as HHS guidance asks the risk analysis to do, and documents the reasoning for any addressable specification it does not implement. DeployOpen supplies the architecture diagrams and data flow inventory it needs. Done when the video components appear in the client's risk analysis with a named owner and a documented decision for each.
Configure encryption and authentication
DeployOpen configures transport encryption, including a valid domain certificate for the web tier, and authentication for hosts and guests according to the decisions in the risk analysis. For Jitsi, that means choosing among internal accounts, JWT tokens or LDAP and keeping the deprecated secure domain method out of new installations. For BigBlueButton, it means setting up external authentication and protecting the API shared secret. Done when a test session shows encrypted media, authenticated hosts, and guest access that matches the documented policy.
Build the evidence records
DeployOpen assembles the records the client will need in an assessment: configuration baselines, certificate and key inventory, access role matrix, logging and audit settings aligned with 164.312(b), and change records from the build. These records are kept in the client's own document store so the client controls retention. DeployOpen prepares this evidence but does not certify it, and the client should confirm with its auditor which records that auditor expects. Done when the evidence set maps each reviewed control to a file or export the client can produce on request.
Run a fixed-scope security test
DeployOpen tests the agreed scope, which typically covers the web application, signaling and media services, guest access paths and any recording storage. Findings are ranked, fixed or accepted in writing by the client, and retested before the scope closes. The test scope and rules of engagement are agreed before testing starts so the client knows which systems are in play. Done when the test report lists each finding with its status and a retest result.
Hand over runbooks and support terms
DeployOpen delivers operating runbooks for certificate renewal, user and guest administration, upgrades, backup and restore, and incident response that touches ePHI. Each runbook is reviewed with the client's operations team and tied to the evidence records. Ongoing support, upgrades and continuous testing are available as a separate retainer, so the client decides who operates the system after handover. Done when the client's operators have run the certificate and access procedures themselves and the runbooks are filed with the risk analysis.
How DeployOpen delivers and supports self-hosted telehealth video
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source video platforms inside your own cloud accounts, data centers or networks. For HIPAA telehealth, the work centers on a written scope that sets out how transmission security, access control and audit evidence are handled for each session type.
How we scope
- Written scope lists which session types, patient access paths and clinical roles the platform will serve.
- Scope records the hosting boundary, including whether any vendor will handle ePHI and needs a business associate agreement.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- Deployment on Jitsi Meet or BigBlueButton inside your infrastructure, with HTTPS certificates issued from your own domain.
- Authentication configured for clinicians and patients, such as JWT tokens with a separate guest domain or OpenID Connect.
- Testing of encryption settings, lobby and waiting room behavior, and audit logging, with results documented for your risk analysis.
How we hand over
- Documentation covering configuration, encryption settings, access roles, recording storage locations and retention settings.
- Compliance readiness material mapped to the HIPAA Security Rule transmission security and audit control provisions, for your assessors to review.
- Runbooks for backups, upgrades and incident response, with a walkthrough for your operations and clinical staff.
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers after handover.
- Upgrade planning that avoids scheduled clinic hours and documents each change for your change records.
- Periodic review of configuration and testing results as your patient volume, sites or recording needs change.
