A HIPAA Compliance Guide for Virtual Reality Therapy Vendors

Virtual reality (VR) therapy can produce more than session notes: a platform may also process voice, movement, gaze, sensor, or usage data. Whether that information is protected health information (PHI) depends on its connection to an individual’s health care and whether the individual can be identified—not simply on the fact that a headset collected it.

For vendors serving health care providers, a practical HIPAA program starts by understanding the vendor’s role, mapping where data flows, and assessing the risks to electronic PHI (ePHI). The HIPAA Security Rule requires safeguards suited to the organization and its risks; it does not prescribe one VR-specific compliance checklist. HHS’s Summary of the HIPAA Security Rule explains the framework.

When does a VR therapy vendor qualify as a business associate?

A VR therapy vendor generally qualifies as a business associate when it creates, receives, maintains, or transmits PHI on behalf of a HIPAA covered entity—such as a qualifying health care provider—or on behalf of another business associate. For example, a vendor may be a business associate when a provider contracts with it to deliver therapy sessions, manage patient progress, store session records, or process identifiable session data for the provider. HHS’s Business Associates guidance describes the definition and includes health care app developers and cloud providers among examples.

The relationship and the work being performed matter more than whether the product is called a VR therapy app. A company offering a consumer app directly to individuals, without handling PHI on behalf of a covered entity or business associate, does not automatically become a business associate just because users discuss health concerns. HHS explains that an app’s role in facilitating access at an individual’s request alone does not necessarily create a business associate relationship. HHS’s guidance on apps and business associate agreements explains this distinction.

Assess each service and data flow rather than relying on a product label. If your company is acting as a business associate, it generally needs a business associate agreement (BAA) with the covered entity; if a subcontractor handles PHI on your behalf, you generally need an appropriate agreement with that subcontractor before sharing the information.

How should vendors handle protected health information in VR sessions?

Start by identifying what information the system collects, where it travels, who can access it, and why it is needed. A VR therapy session may generate treatment notes and patient identifiers, as well as voice recordings, movement or gaze data, sensor readings, session timestamps, and usage logs. These data types are not automatically PHI in every setting. They may be PHI when they relate to a person’s health, care, or payment and identify that person—or could reasonably be used to identify them.

For example, movement measurements linked to a named patient’s therapy record may reveal information about that person’s treatment or condition. A technical log that is not linked to an individual or health information may not meet the PHI definition, but vendors should assess whether it can be linked with other data to identify the user. HHS’s guidance on PHI and de-identification explains that both the health-related context and identifiability matter.

Map data from the headset through the application, provider systems, cloud storage, analytics tools, support channels, and any connected software development kits (SDKs). Collect and retain only what the service needs, and document permitted uses and disclosures in the BAA and related policies. HIPAA’s minimum necessary standard generally requires covered entities to make reasonable efforts to limit PHI to what is needed for the purpose, although the standard does not apply to disclosures to or requests by health care providers for treatment. HHS’s minimum necessary guidance describes the rule and its limits.

What safeguards protect VR therapy data?

The HIPAA Security Rule calls for reasonable and appropriate administrative safeguards, physical safeguards, and technical safeguards to protect ePHI’s confidentiality, integrity, and availability. Vendors should use a documented risk analysis to consider VR-specific data flows, shared or lost headsets, account compromise, cloud storage, software updates, and the consequences of service interruption. A risk analysis is not a one-time exercise; revisit it when the technology, operations, or risks change. HHS’s risk analysis guidance explains the Security Rule’s assessment requirement.

Administrative safeguards include assigning security responsibility, training and managing workforce access, reviewing system activity, and maintaining incident and contingency procedures. Physical safeguards can include controlling access to work areas and equipment, securing headsets and other devices, and managing storage, reuse, and disposal so that PHI is not exposed. HHS identifies facility access, workstation security, and device and media controls as physical safeguard areas. HHS’s explanation of physical safeguards provides more detail.

Technical safeguards should match the risks identified. Consider protections for data in transit and at rest, audit logging, secure software updates, backup and recovery, and mechanisms to protect data from unauthorized alteration or destruction. Encryption is an addressable implementation specification under the Security Rule, not a blanket requirement to use one particular method in every circumstance: the regulated entity must assess whether it is reasonable and appropriate and document its decision and any alternative measure. HHS’s Security Rule summary explains how required and addressable specifications work.

How should vendors manage access controls and user authentication?

Give each workforce member an individual account and access only to the systems and information needed for their role. Use role-based permissions where appropriate, review access when responsibilities change, and promptly remove access when a person leaves or no longer needs it. Shared clinician or support accounts make it harder to determine who viewed or changed ePHI.

The Security Rule’s technical safeguards include access controls, unique user identification, person or entity authentication, and audit controls. For VR systems, apply those protections across clinician dashboards, administrative consoles, support tools, and any headset or companion app that can display ePHI. Consider multi-factor authentication for privileged or remote access as a risk-based security measure; HIPAA does not name multi-factor authentication as a specific standalone requirement. 45 CFR § 164.312 sets out the technical safeguard standards.

Account for the realities of shared headsets and clinical spaces. Configure sign-out or session timeouts where appropriate, prevent the next user from viewing a prior patient’s session, and ensure that emergency access procedures do not become routine shortcuts. Maintain logs that let authorized personnel review access and investigate suspicious activity.

What should a business associate agreement cover?

A BAA should describe the PHI uses and disclosures the vendor is permitted or required to make, prohibit other uses or disclosures except as allowed by the agreement or law, and require appropriate safeguards. For ePHI, it must address applicable Security Rule obligations. It should also require reporting of impermissible uses or disclosures and breaches of unsecured PHI, and require appropriate protections in agreements with relevant subcontractors. HHS’s sample BAA provisions outline required terms.

For a VR service, use the agreement to clarify the details that affect real operations: which session recordings or telemetry the vendor may process, whether the vendor may use data for product analytics, how long data is retained, how support personnel may access it, and what happens to it when the contract ends. Specify incident-reporting timelines and the information the vendor must provide to support investigation and any required notifications. The contract should also address return or destruction of PHI when feasible and the handling of PHI that cannot feasibly be returned or destroyed.

A BAA is not a certification that a VR platform is compliant, and signing one does not by itself make either party compliant. The parties still need to carry out their respective obligations, maintain appropriate safeguards, and address the actual data flows and risks of the service.

How can vendors assess third-party VR platforms and integrations?

Inventory each platform, cloud provider, SDK, analytics tool, transcription service, support vendor, and integration that may create, receive, maintain, or transmit PHI. Determine what data each receives, whether it can identify users, whether it stores or reuses data, and who can access it. Do not assume that a vendor’s marketing language or a general privacy statement answers those questions.

If a third party processes or stores ePHI on behalf of your organization, assess its service and security practices as part of your risk analysis and determine whether a BAA is required. HHS states that a cloud service provider may be a business associate even when it stores encrypted ePHI without possessing the encryption key. HHS’s cloud computing guidance explains business associate responsibilities in cloud arrangements.

Before enabling an integration, ask about data collection, retention and deletion, access controls, incident reporting, backup and recovery, subcontractors, and whether the provider will sign a BAA covering the relevant service. Confirm that the BAA, service terms, and any service-level agreement are consistent. Restrict unnecessary telemetry and advertising or analytics disclosures, and re-evaluate integrations when their features, data practices, or subcontractors change.

What breach response and notification duties apply?

Prepare a response process for suspected security incidents, including incidents that may not ultimately qualify as a reportable breach. The Security Rule requires regulated entities to identify and respond to suspected or known security incidents, mitigate harmful effects where practicable, and document incidents and their outcomes. 45 CFR § 164.308 sets out these administrative safeguard duties.

If an incident may involve PHI, promptly contain it, preserve relevant logs and evidence, determine what information and individuals may be affected, and notify the covered entity under the BAA’s timeline. A business associate must notify the covered entity of a breach of unsecured PHI without unreasonable delay and no later than 60 days after discovery. That federal deadline is an outside limit, not a reason to wait; a BAA may set a shorter reporting period. HHS’s Breach Notification Rule guidance describes business associate reporting duties.

An impermissible use or disclosure of unsecured PHI is generally presumed to be a breach unless an exception applies or a risk assessment demonstrates a low probability that the PHI was compromised. Document the assessment and the basis for any decision that notification is not required. The covered entity generally handles required notices to affected individuals, HHS, and, in certain cases, the media, though it may delegate notice tasks to the business associate. The BAA should explain how the vendor will support the investigation and any delegated notifications.

In practice, a sound VR therapy HIPAA program connects the vendor’s business associate status, data inventory, risk analysis, safeguards, third-party contracts, access controls, and incident response. Review those elements together whenever the platform or its data flows change.

FAQs

Does a VR therapy vendor need a business associate agreement?

Usually, if the vendor creates, receives, maintains, or transmits PHI on behalf of a covered entity or another business associate, a BAA is generally required. A consumer app that is not performing services on behalf of a covered entity or business associate does not automatically require a BAA. The vendor’s role and the specific data relationship determine the answer. HHS’s business associate guidance explains the general rule and relevant exceptions.

What types of VR therapy data count as protected health information?

Identifiable treatment records, session notes, and related data may be PHI when they relate to a person’s health, health care, or payment for care. Voice, gaze, movement, sensor, or usage data may also be PHI when connected to identifiable health information or reasonably usable to identify the person. A data type is not automatically PHI in every context; assess its relationship to health information and identifiability.

Which HIPAA safeguards apply to VR therapy platforms?

When the Security Rule applies, the vendor must use reasonable and appropriate administrative, physical, and technical safeguards for ePHI. Relevant protections may include documented risk analysis, workforce access management, physical protection of devices, authentication, access controls, audit review, incident procedures, and appropriate data protection and recovery measures. The safeguards should reflect the platform’s actual risks.

What must a vendor do after a suspected data breach?

Contain the incident, preserve evidence, investigate the affected systems and data, mitigate harm where practicable, and document what happened. Notify the covered entity promptly according to the BAA and provide information that supports its risk assessment and response. If a breach of unsecured PHI is confirmed, the business associate must notify the covered entity without unreasonable delay and no later than 60 days after discovery; the covered entity generally manages required individual and government notifications unless it delegates those tasks.