HIPAA at Waiver.com

1. Our role

Some of our customers are covered entities under HIPAA — physical therapy and chiropractic clinics, med spas, dental and orthodontic practices, therapy and wellness providers — and some are business associates of one. When such a customer uses Waiver.com to collect intake, consent, or health-history answers, those answers are protected health information, and we become that customer’s business associate.

That relationship has a precise meaning. You remain responsible for your patients and for your own obligations under the Privacy Rule, the Security Rule, and the Breach Notification Rule. We may use and disclose the protected health information you put into the platform only to provide the service to you, only as your written agreement with us allows, and only as law requires. We are also directly liable to the Department of Health and Human Services for the obligations HIPAA places on business associates.

If none of your forms touch health information, none of this applies to you and the Terms of Service and Privacy Policy are all you need.

2. What “HIPAA-eligible” means, and what it does not

There is no such thing as a government certification for HIPAA. No agency audits a product and stamps it approved, and any vendor that implies otherwise is selling you something that does not exist. HIPAA does not certify software; it places obligations on covered entities and on their business associates.

When we describe Waiver.com as HIPAA-eligible with BAA-covered infrastructure, we mean three specific and checkable things:

• the platform is built and operated with the safeguards described in sections 4 through 6;
• we will sign a business associate agreement with you, at no charge, before you put protected health information into it;
• no vendor beneath us receives protected health information until it has signed a business associate agreement with us.

What it does not mean is that using Waiver.com discharges your obligations. Your program, your training, your access decisions, and your notices remain yours. A platform can support your compliance work. It cannot do it for you, and we will not pretend it can.

3. The business associate agreement

Our agreement follows the structure the Department of Health and Human Services publishes for business associate contracts and the required elements of 45 CFR 164.504(e). You can read the whole thing before you ask for it, at /baa. In summary, it commits us to:

• use and disclose protected health information only as the agreement and the law permit;
• apply the safeguards of the Security Rule to everything we hold electronically;
• report unauthorized uses, disclosures, security incidents, and breaches to you;
• bind every subcontractor to the same restrictions before it touches the data;
• help you meet individual requests for access, amendment, and an accounting of disclosures;
• make our books and practices available to the Secretary of HHS when required;
• return or destroy protected health information when our relationship ends.

How to get it signed. Email help@waiver.comfrom an address on your account with the subject “BAA request” and the legal name and address of your covered entity. We countersign and return an executed copy. There is no fee and no plan requirement. If you would rather use your own form, send it and we will review it.

Please do not put protected health information into the platform before the agreement is executed. That includes uploading historical records during an import.

4. Technical safeguards

• Encryption in transit.Every connection to the application, the signing pages, and the API uses TLS, with certificates from Let’s Encrypt renewed automatically. The browser-facing hosts add HTTP Strict Transport Security, so a browser will not fall back to an unencrypted request.
• Encryption at rest. The database and file storage sit on DigitalOcean volumes, which are encrypted at rest; files in object storage are encrypted again with a key of our own.
• Field-level encryption.Answers to sensitive questions — health conditions, medications, allergies, anything a customer marks sensitive — along with a signer’s date of birth, are encrypted individually with AES-256-GCM, above and beyond the volume encryption, so that a database copy alone does not reveal them.
• Immutable, hash-chained records. Each signed record is written once and chained to the one before it by a cryptographic hash. A signed record cannot be edited through the product, and the database itself rejects the change. A correction is a fresh record; the original is retained, and can be voided with a reason, but never altered.
• Access logging.Every human read of a signer’s record is written to an access log — who read it, when, and which record. That log is the raw material for the accounting of disclosures you owe your patients. There is no customer-facing view of it yet; until there is, we produce it for you on request.
• Role-based access.Staff see what their role allows and nothing else. Data is separated by organization at the query layer, so one customer’s account cannot reach another’s.
• Two-factor authentication. Optional for your staff — available to every user, and we recommend requiring it of anyone who can open a record — and mandatory for our own administrative access, enforced in the admin application itself.
• Session controls.Sessions expire and idle sessions time out. A user can end their own sessions on other devices, an owner can remove a member and end that person’s access, and a password reset invalidates every session.

5. Administrative safeguards

We are a small company, and this is our program rather than a compliance department. What it consists of:

• Workforce training. Anyone who could encounter protected health information is trained before they are given access to it.
• Least privilege. Production access is granted by role, only to people whose work requires it, and removed when someone leaves or changes jobs.
• Incident response. A written plan, in place before the first customer BAA is countersigned, naming who is called, how an incident is contained and investigated, how affected customers are told, and what is recorded afterwards.
• Risk assessment. A review of the risks to the confidentiality, integrity, and availability of the data we hold, completed before the first customer BAA is countersigned and revisited after any material change to the architecture.
• Vendor management. No vendor touches customer data until it is reviewed, and none receives protected health information until it has signed a business associate agreement with us.
• Change management. Code is reviewed before it ships, dependencies are watched for known vulnerabilities, and deployments are recorded.

Where one of these is an obligation to you rather than a description of us, section 5 of the business associate agreement is what binds us to it.

6. Physical safeguards

We hold no protected health information on our own premises. There is no server in our office, no filing cabinet of records, and no drive in a desk. Everything runs in data centers operated by DigitalOcean in the United States, which maintain SOC 2 audited physical and environmental controls — staffed perimeters, badge and biometric entry, camera coverage, and audit trails for every visit.

Staff reach the production system only through logged, access-controlled paths.

7. Breach notification

If we discover a breach of unsecured protected health information affecting your data, we will notify you without unreasonable delay, and in any event within the window your business associate agreement sets. We do not wait for a complete investigation to make first contact.

Our notice will tell you, to the extent we know it at the time and supplemented as we learn more:

• what happened and when we discovered it;
• which individuals and what categories of information were involved;
• what we have done to contain and investigate it;
• what we are doing to prevent a repeat;
• whatever else you need to make your own notifications.

The duty to notify affected individuals, HHS, and where required the media is yours as the covered entity. We will give you what you need to do it. Security incidents that do not compromise data — blocked scans, failed logins, and the rest of the daily noise of the internet — are reported to you in aggregate on request rather than one at a time.

8. Retention and deletion

Signed records are retained for 7 years from signing by default, and that period is adjustable on request. You can ask us to delete a specific record, a specific person, or everything, at any time, by writing to help@waiver.com. We complete a deletion request within 30 days unless a legal hold applies.

We will not delete against your instructions, and we will not delete something you are obliged to keep — a record under a legal hold, or one your own retention rules require you to preserve. When our relationship ends, section 14 of the business associate agreement governs return or destruction.

9. What stays your responsibility

Plainly, so there is no confusion later. You are responsible for:

• The content of your forms. What you ask, why you ask it, whether asking it is the minimum necessary, and any consent or disclosure language your jurisdiction requires. We do not review your questions.
• Your staff’s access. Who you invite, what role you give them, whether you have them turn on two-factor authentication, and how quickly you remove someone who leaves.
• Your own HIPAA program. Your notice of privacy practices, your policies, your training, your risk analysis, your patient authorizations, and your own breach notifications.
• Where records go next. Any export, integration, or webhook you configure sends data somewhere we no longer control.
• Devices in your building. A kiosk tablet on your counter is yours to secure, position, and lock.
• Executing the agreement first. No protected health information should enter the platform before the BAA is countersigned.

10. Sub-processors

Only our hosting provider holds protected health information, and no vendor receives any until it has signed a business associate agreement with us. Where each one stands:

• DigitalOcean — Hosting: droplets, our PostgreSQL and Redis, and encrypted file storage. Active. Protected health information: Yes — a business associate agreement with our hosting provider is put in place before any customer BAA is countersigned.
• Cloudflare — DNS for our domains. Active. Protected health information: None.
• Resend — Transactional email — invitations, receipts, and account notices. Active. Protected health information: None — names and addresses only.
• Stripe — Subscription billing and payments. Not yet active. Protected health information: None.
• An SMS provider — SMS delivery for signing links and reminders. Not yet active. Protected health information: None.
• Google Analytics — Visitor measurement on the waiver.com marketing site. Active — marketing site only, never the app or signing pages. Protected health information: None.

The sub-processor page is the current list, says which vendors are active today, and explains how changes are announced.

11. Ask us, or ask for the agreement

To request a countersigned business associate agreement, to ask a question about a safeguard, to report a security problem, or to send us your security questionnaire, write to help@waiver.com.