Blogs

Smart Hyperbaric Chambers and Client Data Privacy: A Plain-English Guide for Non-Medical Operators

Table of Contents

If you run a wellness studio, recovery lounge, athletic facility, or private practice that uses a non-medical hyperbaric oxygen therapy chamber, you probably did not set out to become a privacy regulator. But the smart hyperbaric chamber you bought is a small computer that takes on passengers, and every session leaves a trail of client data someone somewhere can subpoena. 

This page is a working guide for owners and operators of non-medical HBOT chambers: what your chamber is collecting, who is allowed to see it, what laws actually apply to you, and how to turn vague promises from a vendor into paperwork you can hold.

1. "Smart chamber" is not one thing. There are four, and they have very different privacy obligations.

Four product categories get lumped together under the label "smart hyperbaric chamber" or "smart HBOT chamber," and they fall under different privacy rules. Before you read a single line of vendor copy, you need to know which bucket you sit in.

Category Who uses it Typical buyer Privacy regime that actually applies
Medical HBOT system (FDA-cleared) Hospitals, wound-care clinics Hospitals, specialty clinics HIPAA (if covered entity), FDA §524B, state laws
HBOT EMR / clinic software Clinics running HBOT HBOT providers HIPAA, state laws
General medical cloud Anyone storing PHI All healthcare HIPAA Security Rule, BAA
Non-medical wellness chamber (HBOT chamber for recovery / fitness) Wellness, recovery, athletic, private Studios, gyms, spas, private clubs Mostly not HIPAA — but FTC Health Breach Notification Rule and state privacy laws still apply

Most readers of this page are in the last row. The next sections are written for that reader, with explicit notes when something only applies to the medical path.

2. Your chamber is collecting more than you think. Here is the field list.

Every "smart" hyperbaric oxygen therapy chamber, medical or not, generates a stream of telemetry that becomes a record the moment it can be tied back to a person. If a session log, a video clip, or a vitals reading can identify the person in the chamber, it falls under whatever privacy law applies to your business.

Typical data fields a connected chamber may capture:

  • Chamber telemetry — internal pressure (ATA), oxygen concentration, temperature, humidity, session duration, treatment profile used
  • Session record — who entered, when, which protocol, what the chamber logged during the run
  • Operator inputs — pre-session questionnaire, intake notes, waivers, payment record
  • Vitals integrations — SpO₂, heart rate, sometimes ECG, if your chamber accepts external sensors
  • Video and audio — internal cameras, intercom audio, optional session recording
  • Identity binding — name on a tablet, an RFID wristband, a paired phone

The HIPAA Security Rule defines this as electronic protected health information (ePHI) when it can identify a person — see the HHS overview here. The label on the device is irrelevant. What matters is whether the data can identify the person in the chamber.

3. Does HIPAA apply to your wellness chamber? A three-step test.

Most non-medical chamber operators are not HIPAA covered entities — but the assumption that "HIPAA does not apply because we are not a clinic" is itself a major compliance risk. Privacy is determined by what you actually do, not by the name on your door.

Walk through these three questions in order:

  1. Do you act as a healthcare provider? — Do you have a licensed clinician on staff who diagnoses, prescribes, or bills? Is the chamber being used as part of a treatment plan, or is it an experience sold as wellness/recovery/fitness? If there is no licensed clinical decision-making, you are probably not a HIPAA covered entity.‍
  2. Do you electronically transmit health information in connection with a HIPAA-covered transaction? — Submitting insurance claims, verifying eligibility, requesting prior authorization. If you are pure cash/card, no insurance paperwork, the second leg of the test usually fails.‍
  3. Even if both above are no, you may still be a "business associate" if a covered entity (a clinic, a hospital network) sends patients to you and shares their records. In that case the covered entity's BAA pulls you in.

Practical branching rule (this is the part vendors will not tell you): Pure-cash studios with no licensed clinicians and no electronic insurance transactions are usually NOT HIPAA covered entities. But the FTC Health Breach Notification Rule, state breach-notification statutes, and contractual obligations from any medical partner still apply. "HIPAA does not apply" is not the same as "no rules apply."

Sources for this branching: HHS Security Rule landing page and the FTC Health Breach Notification Rule text.

4. So what does apply to a non-medical chamber? Four regulators, in plain English.

You are not HIPAA. Now what? Here is what actually governs you, in language you can take to your attorney.

Regulator

Applies to you when…

What you must do

FTC Health Breach Notification Rule (HBNR)

You collect health data from consumers through an app, a connected device, or a service linked to the chamber, and you are not HIPAA-covered

Notify affected individuals; notify the FTC generally within 60 days of discovery; if 500+ people are affected, also notify media

State breach-notification laws

You handle personal information of state residents (almost all operators)

Notify affected residents promptly; many states also require a separate notice to the state attorney general; timelines are often stricter than FTC

State privacy laws (e.g. CCPA/CPRA in California)

You meet the threshold (revenue, volume, or specific data categories)

Disclose what you collect, honor deletion and opt-out requests, keep service-provider contracts in shape

Contractual obligations

A clinic, hospital network, or wellness partner sends you patients and shares records

You likely become a business associate under their HIPAA program — sign their BAA, follow their safeguards

The single most useful sentence in this whole guide: if you collect health information from customers and you are not HIPAA-covered, the FTC HBNR is your primary federal breach-notification obligation — see the FTC's updated rule explainer.

5. The cybersecurity half: what the FDA actually requires, and when it applies to you.

The FDA cybersecurity rule (§524B of the FD&C Act) was written for medical device makers submitting to the FDA. Most non-medical wellness chambers are not in that pipeline. That said, if you sell into the medical channel, the cybersecurity questions become yours to answer.

The FDA rule requires three things from any qualifying "cyber device" submission — see the FDA cybersecurity FAQ:

  1. A post-market vulnerability and patch plan including a coordinated vulnerability-disclosure process (you cannot ignore a security researcher who emails you a bug)‍
  2. A Secure Product Development Framework (SPDF) aligned with the manufacturer's quality system (and ultimately with ISO 13485 and the 21 CFR 820 / QMSR transition)‍
  3. A machine-readable Software Bill of Materials (SBOM) covering commercial, open-source, and off-the-shelf software in the device

If you sell or co-deploy with a clinic, ask the chamber vendor for these three artifacts by name. If they do not know what an SBOM is, you have learned something important about the vendor in five minutes.

Why the FDA cyber rules matter even for non-medical operators: the same engineering hygiene (patch plans, SBOM, vulnerability disclosure) is what stops your customer data from leaking in the first place. The regulation is not aimed at you, but the practice is. The FDA cybersecurity landing page is the canonical reference.

6. The certifications and clearances worth asking for (and what they do not prove).

There is a widespread habit of treating compliance like a logo wall. A logo is not a guarantee; a logo is a question you have to ask about. Here is the field guide.

6.1 What the chamber itself needs

Document What it actually proves What it does not prove
FDA 510(k) clearance (only if medical) The device was reviewed and substantially equivalent to a predicate device — see the FDA's HBOT safety letter It is not a cybersecurity clearance. A 510(k) does not tell you the device is secure.
ASME PVHO-1 (pressure vessel for human occupancy) The vessel was built and inspected to the recognized pressure-vessel standard; ask for the GR-1 form and the per-unit PVHO stamp It is not a cybersecurity or data-privacy certification
ISO 13485 The manufacturer's quality management system is audited for medical-device processes Same caveat — process quality, not product security
UL / IEC 60601 Electrical safety of the device Same caveat

"FDA registered" is a paperwork status, not a clearance. A vendor who lists registration instead of a 510(k) number is showing you an address, not a permission.

6.2 What the software/cloud side needs (these are the documents that actually answer the privacy question)

Document What it proves What it does not prove
SBOM You can inventory every software component in the device, including open-source It does not mean the device is secure — only that vulnerabilities can be found
MDS2 (Manufacturer Disclosure Statement for Medical Device Security) A structured form about authentication, encryption, patching, audit logging It is a self-reported form; it is only useful if you compare it against your own risk analysis
SOC 2 Type II report The vendor's controls were audited over a period of time, not a single day The report scope may exclude the product you are buying; ask to read the full report, including the system description and any qualifications
ISO 27001 certificate The vendor runs an information-security management system, audited annually It is a management-system certification, not a product certification; ask for the statement of applicability / certificate scope to confirm the chamber product is in scope
HITRUST e1 / i1 / r2 A risk-based inheritance of controls; higher levels mean more assurance Different layers are not interchangeable with the others above; r2 is closer to a SOC 2 + ISO 27001 hybrid

The single sentence the FDA does not say but every cybersecurity person knows: SOC 2 is not ISO 27001 is not HITRUST is not "HIPAA compliant" is not a BAA. These are five different things. Treating them as one thing is the most common mistake buyers make.

7. The data flow: five hops, each one a separate question to ask.

A connected chamber is not one device — it is a chain, and every link in the chain is a place data can leak. Walk the chain once and you will see where your real exposure is.

  1. Sensor → chamber controller — internal bus, often vendor-proprietary‍
  2. Controller → on-prem gateway or local tablet — usually Wi-Fi or wired Ethernet; this hop decides whether your guest Wi-Fi can touch the device‍
  3. Gateway → vendor cloud — the question most buyers skip: is the cloud route encrypted, authenticated, rate-limited, and logged?‍
  4. Cloud → dashboard / mobile app — who can log in, with what factors, from where, at what time‍
  5. Cloud → EHR / billing / analytics — for medical operators, this is where the BAA chain must be complete

Each hop is a separate question to ask your vendor. The most common blind spot is hop 4 — the vendor's own remote access. This is where most breaches in connected medical equipment actually start.

The HHS guidance on cloud computing under HIPAA is a useful reference for hop 3, even for non-HIPAA operators.

8. Vendor remote access: the most overlooked hole in this whole category.

The single biggest gap between what vendors say and what they actually do is in how their own people access the device. A vendor can be ISO 27001 certified and still let a remote support engineer log into your chamber with a default password over an unencrypted channel.

What to demand in writing:

  • MFA on every support account, not just on customer logins
  • Just-in-time or brokered remote sessions, not standing VPN tunnels
  • No default passwords shipped on the device or in the cloud account
  • Full logging of every remote session, with a review process your team can audit
  • No remote access to chamber controls during a live session — read-only, or disabled entirely while a customer is in the chamber

9. Data ownership, export, and exit: the part vendors leave blank.

When the relationship ends, who owns the data you have been generating for years? Most contracts contract is silent on this. Make sure yours is not.

Demand these clauses in your vendor agreement — see the HHS cloud guidance and the ONC EHR contracts guide for templates:

  • Data ownership — the data is yours; the vendor only has a limited license to use it for the service
  • Export rights — machine-readable format (CSV or JSON, not a PDF printout), on demand, at no charge
  • Return or destruction at termination — including backups, with written confirmation
  • No use for product improvement or AI training without a separate written agreement
  • Reasonable transition period — 30 to 90 days post-termination for a clean exit

10. People are still the weakest part. Build the boring stuff.

Most breaches in connected-device environments are not zero-days. They are a forgotten account, a shared password, an ex-employee who still has dashboard access. The HIPAA Security Rule has known this for twenty years, and 45 CFR §164.308 makes workforce training a required safeguard.

Minimum things to do, even as a non-medical operator:

  • Designate a privacy lead (the rule names this a "privacy officer"; for a small studio it can be the owner with documented responsibility) — see 45 CFR §164.530
  • Run a written risk analysis once a year and after any material change (new chamber model, new cloud vendor, new location) — the HHS risk-analysis guidance is the canonical reference
  • Train anyone who can see the dashboard — a 30-minute onboarding, an annual refresh, and a quiz for the record
  • Document, even informally — a shared folder with your risk analysis, training records, vendor BAA (if any), and incident-response plan is often enough to satisfy regulators and partners

11. Cameras and recording in the chamber: if you have them, this is the rule.

A camera inside a chamber is not the same as a camera in a lobby. The moment footage can identify a customer, it becomes protected information under whichever privacy law applies to your business. For HIPAA-covered clinics, HIPAA governs; for non-medical operators, state privacy and wiretap laws govern — and the practical rule is the same.

Practical rules that work everywhere:

  • Get written consent from the person entering the chamber (or their legal decision-maker)
  • Video-only by default; disable audio to avoid the all-party consent rules many states have for audio recording
  • Visible signage in the chamber room
  • Camera placement must not cover changing areas or bathrooms, even by accident
  • Retention — set a fixed retention period (e.g. 30 days) and stick to it; indefinite retention creates risk
  • Marketing or testimonial use requires a separate, written authorization under 45 CFR §164.508 (for HIPAA-covered operators) and equivalent state-law consent (for everyone else)

12. When something goes wrong: the 60-day clock and the two-track notification rule.

The day you discover a breach is the day the clock starts. Two federal rules and a stack of state laws all have their own clocks, and the rule is: run the strictest one. The HIPAA Breach Notification Rule gives you up to 60 calendar days to notify affected individuals — see HHS. The FTC HBNR gives you up to 60 days to notify the FTC. Many state laws are stricter (some require notice "as soon as possible" or within 30 days).

The two-track checklist:

Track Notify whom Within
HIPAA Breach Notification Rule (if covered) Affected individuals; HHS; media if 500+ Without unreasonable delay, no later than 60 days
FTC HBNR (if not covered) Affected individuals; FTC; media if 500+ Generally within 60 days of discovery
State breach-notification laws Affected residents; often the state attorney general Often stricter — many states want notice within 30 days or "as soon as practicable"

Treat the 60-day ceiling as a worst case, not a target. If your state wants 30, do 30. If you cannot notify in 60, document why.

13. The buyer checklist: eleven things to put in writing before you sign.

This is the page that earns its keep. Take this list to your next vendor call and watch what happens.

  1. 510(k) clearance number for the medical SKU (or written confirmation this is a non-medical device)‍
  2. ASME PVHO-1 GR-1 form and per-unit stamp if your chamber is a pressure vessel for human occupancy‍
  3. ISO 13485 certificate scope (does it cover the model you are buying, or only the manufacturer's general operations?)‍
  4. UL or IEC 60601 electrical safety certificate
  5. SBOM for the chamber firmware and any cloud-side software stack‍
  6. MDS2 form for the chamber‍
  7. SOC 2 Type II report (full report, not a summary) covering the cloud and the product line‍
  8. ISO 27001 certificate and Statement of Applicability — confirm the chamber product is in scope‍
  9. BAA available on request (for any sale into a covered-entity customer)‍
  10. Written patch SLA — what is the response window for critical vulnerabilities? What does the customer have to do?‍
  11. Documented remote-access controls — MFA, just-in-time sessions, no default passwords, session logging

If a vendor can hand you all eleven without flinching, you have found a vendor worth talking to.

14. Five questions to ask a chamber vendor this week.

  1. "Show me the SBOM." If they ask "what is that," you have your answer.‍
  2. "What is your patch SLA for a critical CVE?" Anything vaguer than "15 to 30 days, written down" is a no.‍
  3. "Does your remote support use just-in-time access and MFA, or a standing VPN with shared credentials?" The honest answer is usually one of the two, and both should make you ask follow-ups.‍
  4. "Can I export everything you store about my sessions, in CSV or JSON, on demand?" If the answer is "we will get back to you," watch out.‍
  5. "If we stop being your customer, what happens to our data, including backups?" "We will delete it" is incomplete. Ask for written confirmation, including the backup deletion.

15. A short, honest disclaimer.

This page is informational. It is not legal advice, not medical advice, and not a substitute for talking to a privacy attorney familiar with your state and your customer mix. Regulations change; vendors change; the FTC has updated the Health Breach Notification Rule in 2024 and may update it again. Anything you read here is current as of late 2025 against the public HHS, FTC, FDA, and 45 CFR sources cited above. For final compliance decisions, confirm with the source documents and your own counsel.

‍

get started

Find the Right Chamber  for Your Life

The best model is the one that fits your space, your body, and your daily rhythm. Whether you're exploring hyperbaric wellness for the first time or looking for a specific chamber format, the Oxyboss team is here with clear recommendations and honest comparisons.

Get a Personalized Recommendation