HIPAA Compliant Video Sharing: A Step-by-Step Guide

Decide whether your video counts as PHI

A video is not HIPAA compliant because it is encrypted. Compliance depends on whether the video holds protected health information, and on whether the controls, the business associate agreement and the consent match what the file contains.

The Security Rule covers electronic protected health information (ePHI) that covered entities and business associates create, receive, use or maintain. It asks for administrative, physical and technical safeguards together. Encrypting the file, or serving the link over HTTPS, does not tick those boxes on its own.

Sort the recording before you upload anything. A clinical clip with a recognisable patient is a different object from a staff briefing that never names a person.

The row people skip is the last one. An email address, a city, or minutes watched can carry health context once you can tie that trail to a patient. Treat the analytics as data to protect, not as a harmless dashboard.

If a stranger could work out a patient's condition from what the link shows or what it records, treat the share as PHI today.

A generic voiceover does not save you if the screen behind it shows a name, a date of birth, or a ward list. If you are mapping this against wider duties, our note on security and compliance requirements is the place to line the video up with the rest of your stack. I would classify the file before I touch a vendor form.

Get the BAA signed before anything goes out

No signed Business Associate Agreement, no patient-related upload. I would rather delay a send than discover the host will not put its name on the contract.

HHS telehealth guidance says covered entities using remote communication technology must pick vendors that comply with HIPAA and will sign a BAA. A product badge, or a TLS certificate, does not move that duty onto the vendor. HHS also allows treatment-related disclosures by email, telephone or other channels when you apply reasonable safeguards, so "compliant" is not a yes or no property of the platform.

Ask the vendor for four written answers before any clinical file leaves your laptop:

• Will you sign a BAA? A verbal yes, or a marketing line, is not the agreement.
• Which subcontractors touch the data? Hosting, transcoding, email and support all count.
• How long do you keep analytics? Viewer location and time viewed widen what the contract must cover.
• How does deletion work on request? You need a method, not a promise to "look into it".

Then read the agreement against the full path: recording, hosting, thumbnail or transcript generation, viewer authentication, email notifications, analytics, downloads and deletion. A secure link is still the wrong link if retention and subcontractors are undocumented. Backups belong in that same pass: ask whether a restore would put ePHI back into a system you no longer control.

Set up your workflow in eight steps

You want a written plan you can hand to a new starter on a Monday, not a slide that says "we take security seriously".

HHS splits access controls into required specifications and addressable ones. Required means you implement them. Addressable means you assess whether they are reasonable, then implement them or document an equivalent. HHS technical safeguard guidance is clear that encryption on its own does not give you integrity, availability, a risk analysis, or your administrative and physical safeguards. Customers can still own authentication and access even when a cloud provider encrypts the infrastructure.

Lock down every link, viewer and analytics trail

Treat every release as its own decision. A folder permission from last year is not a reason to send today's recording.

The HHS security regulations require mechanisms to record and examine activity in systems that contain or use ePHI. They do not hand you a universal log-content list or a review frequency. You justify both from your risk analysis.

1. Authenticate the sender before the link exists. A shared inbox password fails this step.
2. Confirm who the recipient is, and limit access to named users or an approved organisation.
3. Set an expiry and a way to revoke. "We'll delete it later" is not a control.
4. Turn off public indexing, and turn off any download the recipient does not need.
5. Gate the analytics separately. Timestamps, locations, email addresses and viewing behaviour can be sensitive on their own.

For any link you should be able to pull creation, recipient authorisation, playback, page access, downloads, reopening and revocation. Test that path with synthetic data, not a real chart: expired links, strangers, forwarded URLs, a stolen password, browser cache, a phone, a restored backup, and the incident steps themselves.

Anyone with the link can view a LiveDocument file without signing in. For patient-related content, do not bet on the URL staying secret. Link expiry and revocation help, but they are not an identity check, and the Security Rule expects you to verify who is accessing ePHI. If a link alone cannot give you that, use a sharing method that does, such as a named-user portal, for patient-related files. The same habit shows up in secure file sharing for business, where a quiet link is not the same as a controlled one.

What usually goes wrong:

• Treating an email address as identity: collecting an address is not confirming the person.
• Obscurity: a long URL is still a URL someone can forward.
• Endless analytics: keeping viewer trails "just in case" fights the minimum necessary.
• PHI in the subject line: the notice can leak what the link was meant to protect.
• Support with production access: a vendor engineer should not browse patient links by default.

Technical locks do not replace administrative, physical, contingency and breach-response controls. Put those owners in the same procedure as the expiry date.

Keep consent separate from clinical sharing

One signature does not cover every later use. I would rather have four short records than one vague form that tries to bless "education and marketing".

HHS consumer guidance states that health information generally cannot be used or shared without written permission unless HIPAA allows it. Treatment communications can go out without patient authorisation when you use reasonable safeguards. Permission to record or send a video for care does not automatically permit a copy for a family member, a consultant, a prospective client, a conference audience, or a marketing page.

Test, monitor and plan for a breach

Test with fake patients. A real chart in a "quick check" is already a disclosure if the wrong person is on the call.

Walk the paths before you publish:

• Expired links: confirm they fail closed, including copies saved in email.
• Unauthorised users: a colleague outside the role should get nothing.
• Forwarded URLs: assume the first recipient will pass the link on.
• Compromised credentials: revoke the account and see which links die with it.
• Browser caching and mobile playback: check a phone that was used on guest Wi-Fi.
• Backup restoration: a restore should not resurrect a video you deleted.
• The incident itself: name who calls whom, and where the notes go.

HHS requires a way to record and examine activity. It does not set how often you read the logs. Pick a cadence from your risk analysis and write it down. A log nobody opens is a diary, not a control.

Encryption and destruction can make PHI unusable, unreadable or indecipherable to unauthorised people. That split changes the response. A lost encrypted file and an exposed plain-text recording are not the same event, even if both feel awful on a Friday afternoon.

HHS breach reporting sets the large-breach clock: if unsecured PHI affects 500 or more individuals, the covered entity notifies the Secretary without unreasonable delay and no later than 60 calendar days after discovery. Smaller breaches still need documenting and reporting. The route and the Secretary's timing differ. They are not optional because the list is short.

Frequently asked questions