Gravity Forms & HIPAA Compliance

Overview

When building contact forms for therapy practices and other healthcare-adjacent clients, a common tension arises between wanting a capable, SEO-friendly form solution and managing HIPAA compliance risk. Gravity Forms is the recommended solution, but it requires a deliberate strategy around data retention and form design to stay compliant.

This pattern emerged from work with ^[1] and applies broadly to any client operating under HIPAA.

The Core Problem

A standard contact form on a therapy website creates a HIPAA gray area:

• When a visitor submits a form, they are not yet a client — so HIPAA technically doesn't apply.
• However, if that person becomes a client, the data collected during that initial contact (name, email, phone, IP address) may retroactively constitute Protected Health Information (PHI).
• Storing that pre-client submission indefinitely in a WordPress database creates compliance exposure.

Google Forms (even within a HIPAA-configured Google Workspace) has been used as a workaround, but it lacks the SEO, tracking, and flexibility benefits of a native WordPress form solution.

Recommended Solution: Gravity Forms + Auto-Delete

Why Gravity Forms

• Stores submissions natively in WordPress, enabling conversion tracking and UTM attribution
• Flexible field configuration — can be kept minimal to reduce PHI surface area
• Integrates with analytics and CRM workflows
• Looks and behaves like a native site element (better UX and SEO signals than an embedded Google Form)

Form Design Principles

Keep the initial contact form minimal to reduce PHI exposure:

• Name
• Email
• Phone number
• Brief open-text message (optional)

Do not include symptom checklists, diagnosis fields, insurance details, or other clinical information on the initial contact form. Those belong inside the HIPAA-compliant EHR onboarding flow.

PHI Disclaimer

Include a short disclaimer near the message field advising users not to share sensitive health information:

Please do not include sensitive personal health information in this message. This form is not a secure clinical channel.

This sets expectations and reduces the likelihood of a visitor voluntarily submitting PHI before they are a client.

Automated Deletion of Pre-Client Submissions

The highest-risk scenario is a submission that sits in the WordPress database after the person becomes a client. The recommended mitigation is to automate deletion of initial contact form entries once a prospect converts to an active client.

Approach to investigate:
- Trigger deletion via a Zapier/Make automation when the client is marked active in the EHR (e.g., Jane App)
- Alternatively, set a time-based auto-purge (e.g., delete all entries older than 30 days) as a blunt but effective fallback
- Gravity Forms supports entry deletion via its REST API, making automation feasible

⚠️ Status (as of 2026-03-20): Automated deletion workflow is still being researched for the A New Dawn Therapy implementation. This is an open action item.

What This Does Not Cover

This pattern addresses the initial contact form only. Once a client is onboarded into the EHR:

• All clinical communication and records should live inside the HIPAA-compliant EHR platform (e.g., Jane App)
• The WordPress site should not be used to collect or store ongoing clinical data
• Payment and intake forms should route through the EHR, not WordPress

Digital product sales (e.g., downloadable workbooks) requiring payment processing are a separate scope and need their own compliance review — see ^[2] (future article).

Related Patterns

• ^[3] — another case where keeping content on-site (vs. redirecting to a job board) has SEO and control benefits
• ^[4] — AI-citation-friendly question framing for therapy sites
• ^[5] — source meeting where this pattern was defined

Client Evidence