Healthtech Demo Videos Without PHI: A HIPAA-Safe Workflow

A healthtech demo video has one job most SaaS demos don't: it must contain zero real patient data. Not blurred, not cropped. Absent. In 2018, three Boston hospitals paid a combined $999,000 to settle HIPAA cases after letting an ABC documentary crew film patients without first getting their authorization. Two years earlier, NewYork-Presbyterian paid $2.2 million over the same kind of filming for "NY Med".

Those were TV crews, not product teams. But the lesson carries straight over to your screen recordings: once a patient's information is in a published video, you can't take it back.

The short answer: build every healthtech product demo inside a sandbox filled with synthetic patients, so there is no protected health information (PHI) to leak in the first place. Then check each video against the 18 identifiers in HIPAA's de-identification rule before it goes out. That list includes things a screen recording catches without anyone noticing: URLs, IP addresses, device serial numbers, faces and voices.

Here's the workflow:

This is a product team's workflow, not legal advice. Run your process past your privacy officer once, then reuse it for every video.

Why "we'll blur it later" fails for PHI

Blurring is a fix applied after the fact. It assumes someone will spot every name, date and chart number in every frame. In a 3-minute recording at 30 frames per second, that's 5,400 frames to check.

PHI is also wider than most people expect. HIPAA's Safe Harbor method (45 CFR 164.514(b)(2)) lists 18 types of identifier that must be removed before health data counts as de-identified. Names are only the first. The list also includes:

• Every date part except the year for dates tied to a person: birth, admission, discharge, death
• Any location smaller than a state, including street, city and most ZIP codes
• Medical record numbers, health plan numbers and account numbers
• Web URLs and IP addresses
• Device identifiers and serial numbers
• Biometric identifiers, including voice prints
• Full-face photos "and any comparable images"

A blurred name next to a visible admission date and medical record number is still a problem. Prevention beats cleanup: if no real patient ever exists in the environment, there's nothing to blur.

Who this applies to (and why your BAA doesn't cover demos)

HIPAA applies to covered entities (providers, health plans, clearinghouses) and to their business associates. If your product stores or processes PHI for clinics or hospitals, you're almost certainly a business associate. That means you've signed business associate agreements (BAAs).

Those contracts limit you. Under 45 CFR 164.502(a)(3), a business associate may use or disclose PHI "only as permitted or required by its business associate contract" or by law. A BAA covers running your product for the customer. It doesn't cover recording a customer's live patient screens for your marketing site.

Marketing has its own rule too. 45 CFR 164.508(a)(3) requires a patient's written authorization for any use of their PHI for marketing. Face-to-face conversations and promotional gifts of nominal value are the only exceptions.

The practical rule: a customer's production environment is never a recording location, even with their permission, even "just for a sales call".

Step 1: Build a sandbox with synthetic patients

The foundation is a demo tenant that was never connected to real patient data. Data you generated from nothing isn't de-identified PHI. It was never PHI at all.

You don't have to invent patients by hand. Synthea, an open-source tool from the not-for-profit MITRE Corporation (Apache 2.0 licence), generates synthetic patients with full medical histories. It exports HL7 FHIR, C-CDA and CSV. If your product imports FHIR, you can load a believable population in an afternoon. A command like run_synthea Massachusetts generates patients placed in that state.

A few rules make the sandbox look real on camera without becoming a risk:

• Generate, don't copy. Never "anonymize" a real export by swapping names. Dates, ages and rare diagnoses can still point to a real person.
• Make it look lived-in. Vary names, ages and visit histories so the screen doesn't read like placeholder text.
• Use reserved contact details. In North America, 555-0100 to 555-0199 are set aside for fictional use. The example.com domain is reserved for documentation. Neither will reach a real person.
• Keep it permanent. One maintained demo tenant beats rebuilding a fake environment for every video.
• Label it. A small "Demo data" badge in the sandbox UI answers the question every compliance reviewer will ask.

Once this tenant exists, every recording made inside it is safe by design. That's the whole point.

Step 2: Lock down the recording machine

Most leaks in sandbox recordings don't come from the demo screen. They come from everything around it.

• Use a separate browser profile with no history, saved logins or bookmarks for real customer environments. The address bar and autocomplete are on screen too.
• Silence notifications. On a Mac, open System Settings > Notifications and turn off Allow notifications when mirroring or sharing the display. Then turn on Do Not Disturb as well, because a plain screen recording doesn't always count as "sharing". On Windows, turn on Do not disturb before you record.
• Record one window or one screen. Never record a full desktop with email, chat or an EHR open on a second monitor.
• Close the support inbox. A ticket preview sliding in from a real clinic is exactly the kind of frame nobody catches live.
• Check your own camera feed. A whiteboard or printed schedule behind you is in the shot.

If you record on a Mac, our guide to screen recording on Mac without a watermark covers which tool records audio on which macOS version.

Treat the recording machine as part of the sandbox: if it can show something real, assume it eventually will.

Step 3: Script the click path before you record

Unscripted demos wander. A presenter opens a patient list, scrolls past the sandbox data and clicks into "just one more" record. Scripting removes the wandering.

Write down three things before recording:

1. The patients you'll open, by synthetic name. Pick two or three and use only those.
2. Every click, in order: list view, open chart, change one setting, show the result.
3. The narration, one line per click. About 150 spoken words is roughly a minute of video, per the National Center for Voice and Speech.

A script also keeps the video short. A tight 60-90 second walkthrough of one workflow gives you fewer frames to review than a 10-minute tour.

If it isn't in the script, it doesn't get clicked.

Step 4: Review every video against the 18 identifiers

Even a perfect sandbox needs a second pair of eyes. Someone types a real colleague's name into a test note. A browser tab shows a real hospital's portal. A voice in the background says a patient's name.

Have someone other than the recorder scrub the final export with this checklist:

Check the audio separately from the picture. Voice prints are on the Safe Harbor list, and a recorded patient call playing inside your product is easy to miss with the sound muted.

Keep the signed checklist with the video file. When someone asks "who checked this?", you'll have the answer.

Step 5: Handle real patient stories separately

Real outcomes are the most persuasive thing a healthtech company can show. They're also the highest-risk content you'll make.

• Get written authorization first. If a real patient's story, face or voice appears, the marketing rule in 164.508(a)(3) applies. Your customer's privacy team will usually run this process. Don't run it yourself.
• Don't count on removing names. A rare condition plus a small town plus a month can identify someone without a name on screen.
• Use composites clearly labelled as such. "An illustrative example based on common patterns" is honest and keeps the story without the person.
• Prefer clinician and admin voices. A nurse explaining how the product saved time on discharge paperwork tells a strong story with no patient in it.

If you're turning a written case study into a video, our guide to building a testimonial video from a case study PDF covers the structure. Run the same authorization check before you start.

When in doubt, tell the story from the care team's side, not the patient's.

Where Poko fits

Poko makes product videos from a source you give it: a screen recording, a PDF, a slide deck or a code repository. That suits this workflow, because the source is fixed and can be checked before any video exists. Record your scripted sandbox walkthrough, review it, then hand Poko only the clean file. Our guide to choosing the right source for Poko explains which input gives which result.

Poko renders on your own computer, which keeps finished files off a third-party render server. See local rendering vs. cloud video tools for the trade-offs. The AI model that writes and edits the script is still a separate service. So treat anything you give Poko as leaving your machine. With a synthetic sandbox, that's fine: there's no PHI in it.

You can also change the video by typing instructions, such as "cut the part where the patient list scrolls". That fixes a risky frame without re-recording.

The tool doesn't replace the review step. It gives the review step one fixed file to check.

Your next step

Before your next demo, spend one afternoon on step 1. Generate 50 synthetic patients, load them into a demo tenant and add a "Demo data" badge. Then write the 8-row review checklist above into your video template. Every healthtech demo you record after that starts safe instead of being cleaned up later.