Waivers, intake and screening: what your software has to record, one modality at a time

Seventeen studio and wellness platforms were checked in September 2026 for what they publish about waivers and intake. Several publish digital waiver capture as a standard feature. At least two publish waivers or custom intake forms as tier-gated capabilities, so the feature exists but arrives with an upgrade. One publishes no first-party waiver feature at all and instead carries Waivers and Forms as a category in its third-party integration directory, which tells you where it thinks the responsibility sits. And several publish nothing about waivers or intake anywhere in their pricing or feature pages.

That distribution is reasonable for the businesses these platforms were built around. A yoga studio needs a signed release and little else. A recovery studio running a heat room, a plunge, a cryotherapy device and a hyperbaric chamber is a different problem, because the release is the easy half. The hard half is a screening record: an answer, captured before the session and attached to the right person, to a question that is specific to the device they are about to use.

The distinction runs through everything below. A waiver is a liability document, signed once, recording a person's acknowledgement of risk and agreement to your terms. A screening record is an operational document, refreshed on a cadence, capturing whether this person should be doing this session today and what the desk did about the answer. Vendors sell the first and describe it as intake. The second is built by the operator out of whatever forms the platform allows, and it is worth building deliberately.

What the platforms actually publish about waivers

Waiver capture is close to commoditised, which is good news: you should not pay a premium to collect a signature on a phone. What varies is where the feature sits in the tier structure and whether the record it produces is any use afterwards.

One platform publishes online waivers on every tier[1] while reserving custom intake forms for its top tier, which is exactly the split this guide is about: the liability document is universal and the screening instrument is an upsell. Another publishes digital waivers and custom terms as mid-tier and above[2], alongside SMS and multi-location reporting. A third lists digital waivers and contracts directly on its pricing page as a standard line item. A fourth publishes waivers and forms with no contract and month-to-month billing. And one large incumbent publishes no first-party waiver feature on its pricing page, carrying Waivers and Forms instead as one of nineteen categories in its partner integration directory[5].

The last of those deserves thought rather than dismissal. An integration is not automatically worse: a specialist waiver product usually has better signature handling, templating and retention controls than a booking platform's afterthought. What it does mean is that signed records live in a second system with a second contract, a second export path and a second place to look when a member is at the desk. Whether that is acceptable depends on whether the integration writes a visible status back onto the customer record in the system your team already has open.

• Ask which tier includes waivers, and which tier includes custom forms. Those are frequently different tiers, and the second is the one that carries screening.
• Ask whether a waiver status is visible on the check-in screen, or only inside a documents area nobody opens mid-shift.
• Ask whether forms can be attached to a specific service or resource instead of to the customer in general. Per-modality screening is impossible without that.
• Ask whether the platform stores the version of the terms the person signed, not merely the fact that they signed something.

A waiver is a liability document, not a screening tool

The failure mode is easy to describe. A studio collects one waiver at first visit: a general acknowledgement of risk, a release, a media clause and a broad health question along the lines of do you have any medical conditions we should know about. The member ticks no, because the question is unanswerable at a counter with someone waiting behind them. Eighteen months later that signature is still the studio's entire record of their suitability for four devices, two installed after they signed.

That document may do its legal job. It is not doing an operational one, and the two are different jobs with different designs. A release is drafted by counsel, is deliberately broad, and is meant to be read once. A screening record is drafted by you, is deliberately narrow and specific, and is meant to be answered again whenever something changes. Broad and specific are opposites, which is why the attempt to merge them into a single form produces a document that is weak at both.

Your front desk should be able to answer a concrete question from the record in seconds. Somebody books their first hyperbaric session on a Saturday: does the system show that the modality-specific questions were asked, when, and what was recorded? If the only answer is a waiver signed in 2024, you have a liability document and no screening. Building the second is a forms-and-workflow problem and not a legal one, and it belongs to operations.

Screening is modality-specific, which is why one form cannot hold it

A recovery menu is not one service with variations. Heat, cold, pressurised oxygen, compression and enclosed relaxation sessions place different demands on a person, and the published safety literature for each names different groups and considerations. One generic health question elicits none of it, because the person answering does not know which of their circumstances is relevant to which device, and it is not their job to know.

So the design is a small shared core plus a per-modality question set. The core covers anyone: emergency contact, whether they are under a clinician's care for anything they think relevant, current medications, pregnancy where applicable, and an acknowledgement that staff are not clinicians. The per-modality sets are short, sit in front of the first booking of that modality, and are written from what the published guidance for that modality names.

One rule governs all of them and should be printed on the form your staff use. These questions exist to route, not to decide. The desk records the answer and, where an answer lands in a flagged category, refers the member to their own clinician before the session. A studio is not a clinical setting and nobody working the floor should be assessing whether a disclosed condition is compatible with a device. Recording the answer, applying a written routing rule and referring out is the whole job, and it is defensible because it does not pretend to be more.

• Keep a shared core short: emergency contact, current medications, clinician care, pregnancy where applicable, and the statement that staff are not clinicians.
• Attach a distinct question set to each modality, triggered before the first booking of that modality rather than at first visit to the studio.
• Write the routing rule next to each question: what the desk does when the answer is yes, in one sentence, with no interpretation required.
• Record the answer and the action taken, both timestamped. An unanswered flag with no recorded action is worse than no flag.
• Never write a clinical conclusion into the record. Record what was disclosed and what you did about it.

Heat rooms: the questions the published guidance actually names

For sauna and other heat modalities, public health guidance on heat and health names the groups considered to be at higher risk, including children with asthma, people with heart disease, pregnant women[8], adults sixty-five and over, and outdoor workers and athletes. It also advises reviewing medications with a doctor, because some increase the risk of dehydration or overheating. Read that as a specification for a form, not as advice you pass on: your heat intake needs an age field, a pregnancy field where applicable, a cardiac history field and a current-medications field, because each appears by name in the guidance.

The same guidance lists the symptoms of heat illness, which is a staff-training artifact and not an intake one, but the two connect. If intake has recorded that a member takes a medication affecting heat tolerance, whoever supervises the floor should know a flag exists without opening a separate document. That is a software question: does a per-modality flag surface on the check-in screen, and can it show without exposing the disclosure itself?

Nothing here is a threshold, a temperature or a duration, and none of it should be. Session parameters belong to the manufacturer's instructions and to the member's own clinician. What belongs to your software is the record that the question was asked, the answer given, the date, and what the desk did next.

Cold: the chamber and the cryosauna are not the same intake

An international scoping review of whole-body cryotherapy safety draws a distinction most studio intake forms do not: true whole-body cryotherapy in a refrigerated-air chamber is not the same exposure as a partial-body liquid-nitrogen cryosauna, and the review notes the latter carries higher burn and hypoxia risk[7]. It documents a small number of adverse events across the published studies and concludes they appear rare relative to how widely the practice has grown, which is a reason to be precise rather than a reason to relax.

The operator consequence is concrete. If your form says cryotherapy, it is describing two devices with different risk profiles as one service, and your record will not tell you which one a person was screened for. Name the device on the service and attach the question set to the service instead of to the category. If you run a nitrogen unit, the supervision and ventilation record is part of the same file: what monitoring is in place, who was present, and what the manufacturer's instructions require. Cold plunge and contrast circuits raise their own set, and the shared core plus a short circuit-specific set is usually enough.

Contrast work deserves one extra field because of sequencing. A member moving between a heat room and a plunge is doing two exposures back to back, so both question sets apply and the record should show both were asked. A platform that can only attach one form per customer forces a merge, and a merged form is the generic form again.

Hyperbaric: the heaviest documentation load on a recovery menu

Hyperbaric oxygen carries the most specific published guidance of anything likely to appear on a recovery menu, and it is the modality where a generic waiver is least defensible. A widely read clinical reference names groups who should not receive hyperbaric oxygen therapy, including people with a collapsed lung[6], people with lung disease such as COPD, cystic fibrosis or emphysema, people with an active fever or cold, and people with a recent ear injury or surgery. It also describes risks including claustrophobia, middle-ear and sinus injury, temporary nearsightedness among people having many treatments, and rare oxygen toxicity and seizures, and it stresses receiving the therapy from an experienced provider in an accredited facility for approved conditions.

Every item on that list is a field. A hyperbaric intake needs a respiratory history question, a recent-ear-surgery question, a same-day illness question asked at each session instead of once at signup, and a clear statement of what your facility is and is not. The same-day question is the one most often missing from studio software, because a form attached to a customer record is designed to be filled in once.

This is where the routing rule matters most. A disclosed respiratory condition is not a decision for the front desk; it is a referral, made before the booking, and recorded. Studios running hyperbaric should expect their intake to be the most structured thing in the building, and should not expect a booking platform's standard waiver module to provide it.

Re-signature: when a signed record stops being current

A signature has a shelf life, and the expiry is a setting, not a default. Three separate events should invalidate a record and trigger a fresh ask, and they are easy to write into policy and hard to enforce without software support. The first is time: a health disclosure from two years ago describes a person who may no longer exist. The second is a change to your terms, your menu or your equipment, because a person who signed before you installed a chamber never consented to anything about a chamber. The third is the first booking of a modality the member has not used before, which is the only one that is genuinely per-session rather than per-person.

Ask any platform how it handles all three, and read a vague answer as a no. The capabilities to look for are an expiry date on a form, an automatic re-ask when a form version changes, and a service-level requirement that blocks or flags a booking until the matching form is complete. A platform that can only mark a customer as having signed something, with no expiry and no version, will let a 2024 signature sit against a 2026 device indefinitely, and staff diligence does not reliably compensate.

Then set the cadence deliberately rather than defaulting to never. An annual refresh on the shared core, a re-ask whenever terms or equipment change, and a per-modality set on first booking is a pattern a small team can actually run. The failure to avoid is re-signature that is technically configured but arrives as an email nobody opens, producing a queue of expired records and a desk that waves people through anyway.

Where the record lives decides whether it gets used

A screening record that is correct and invisible is worth very little. The test is whether a staff member covering a busy Saturday, in the interface they already have open, can see that a member is cleared for the service they just booked, without opening a documents area and without reading the underlying disclosure. That design property does more for real safety practice than the wording of the form, because it decides whether the form is consulted at all.

Which means the integration question from earlier returns as an operational one. If waivers live in a third-party product, does that product write a status back onto the booking record, or does it merely store a PDF that somebody could retrieve if they thought to? If forms are first-party, are they attached to services or only to customers? Ask for a live demonstration on the check-in screen instead of a feature list, and watch how many clicks it takes.

One boundary belongs on a page about records. Praxium captures no waiver and holds no screening answer; it lists studios for city and modality searches, and its optional protocol layer reads a booking system without becoming one. The signed record stays in the system that took it, which is where it belongs.

• Status visible on the check-in screen, not in a documents tab.
• Cleared or not-cleared shown without exposing the disclosure itself to every staff member.
• Forms attachable to a service or resource, so per-modality screening is possible at all.
• A record searchable by member and by date, because the moment you need it is the moment you are in a hurry.

The export problem, and what to test before you sign

Signed records are the part of your data that has to outlive your software, and the part most likely to be trapped. Migration marketing here is extensive and thin: several platforms advertise free data migration without publishing what moves, and the most detailed migration page in the set names twelve source platforms while publishing only the phrase secure migration of client data. Almost nothing in the category says whether signed documents, with their timestamps and terms version, come with you.

So test it during evaluation, not at exit. Ask for a sample export of signed waivers and completed forms from a demo account and open the file. What you want to see is one row or one file per signed record, carrying the member identifier, the timestamp, the form version and the answers, in a format you could hand to counsel or import elsewhere. What you often get is a PDF bundle with no index, or a customer export with a boolean column saying accepted, which preserves the fact of consent and destroys its content.

The reason to care is not hypothetical. These records are the evidence in exactly the situations where evidence matters, and the retention period you need is measured in years while a platform relationship is often shorter. If a vendor cannot show you an export today, assume you will reconstruct your consent history by hand later, and price that in alongside the subscription.

• Request a real export from a demo account during evaluation and open it before you sign anything.
• Confirm the export includes the timestamp and the form or terms version, not just an accepted flag.
• Confirm answers to custom intake questions export too, since these are often stored separately from waivers.
• Confirm what happens to records after account closure, and for how long the vendor retains them.
• Keep your own periodic export regardless of what the vendor promises. It is the cheapest insurance in the stack.