Healthcare organizations often ask whether iorad is HIPAA compliant and whether we'll sign a Business Associate Agreement (BAA). The short answer is that a BAA doesn't apply to iorad, and this article explains why.
Why iorad falls outside HIPAA's scope
HIPAA requires covered entities to sign BAAs with vendors that create, receive, maintain, or transmit Protected Health Information (PHI) on their behalf. iorad doesn't do any of those things.
iorad is a user-generated content platform. When someone records a tutorial, iorad captures screenshots of what's on screen. It doesn't connect to your systems, extract data, read data fields, or interpret anything in the underlying application. The output is a visual, step-by-step representation — not a data record.
Because iorad never receives or processes PHI, it doesn't qualify as a Business Associate under HIPAA. A BAA is not applicable.
Your responsibility as a content creator
While iorad doesn't process PHI, sensitive information can still appear in a tutorial if a creator records in a live production environment without taking precautions. That responsibility sits with your team.
Two controls cover most of the risk.
Record in non-production environments when possible.
Use a test, staging, sandbox, or demo environment with fictional or sanitized data whenever one is available. If your organization has demo accounts or masked datasets, use them. Production environments should be the exception, not the default, and any exception should be documented and approved internally.
Require a second-person review before publishing.
No tutorial should be published, shared externally, or distributed until someone other than the creator has reviewed it. The reviewer should confirm that no PHI, credentials, internal URLs, or other sensitive information appears in screenshots, annotations, transcript text, or downloadable assets.
iorad also gives creators a built-in tool for situations where sensitive data does appear on screen: the blur feature. Any sensitive area can be blurred during capture, and once saved, the blurred version is the only version stored on iorad's servers. No unblurred copy is retained.
What reviewers should check
Before approving a tutorial for publish or share, reviewers should confirm that none of the following are visible:
- Real patient or customer names
- Account numbers, financial balances, or transaction history
- Email addresses, phone numbers, or mailing addresses
- Dates of birth, SSNs, tax IDs, or similar identifiers
- Credentials, API keys, tokens, or session details
- Browser tabs, bookmarks, internal URLs, or side panels that expose internal information
- Internal-only confidential business data
If any of these are found, the tutorial should be rejected and corrected before release.
Keeping records
For teams that need to demonstrate compliance controls internally, it's worth retaining evidence for each tutorial: the environment used, who created it, who reviewed it, and any exceptions or remediation notes. This gives your InfoSec or compliance team an audit trail without placing any burden on iorad.
A per-tutorial worksheet covering each of these checkpoints is available as a companion to this article. Teams can adopt it as-is or adapt it to fit existing evidence-retention policies.
Summary
iorad does not collect, store, or process PHI. It's a screenshot-based content tool, and the data that appears in any tutorial is entirely determined by the person recording it. Because of this, HIPAA's BAA requirement doesn't apply to iorad. The compliance piece is an internal workflow question: record in safe environments, review before publishing, and blur anything sensitive.