Best HIPAA-Compliant Form Plugins for Medical and Therapy Practices
No WordPress plugin can make you HIPAA compliant, and any plugin marketed as “HIPAA-compliant” is describing an arrangement rather than a feature. Compliance attaches to you, the covered entity, and to every vendor who touches protected health information on your behalf. Each of those vendors needs a signed Business Associate Agreement, and most WordPress plugin companies will not sign one.
That sounds like bad news and is actually the route to a workable answer. If the plugin stores data on your server and never transmits it anywhere, the vendor is not a business associate and no BAA is needed from them. The compliance question moves to your host, your email, and your own configuration, which are all things you control. This article maps that architecture.
Verified August 2026. This is a practical guide, not legal advice. BAA availability changes and must be confirmed in writing with each vendor before you rely on it.
Who is a business associate, and who is not
A business associate is anyone who creates, receives, maintains or transmits protected health information on your behalf. That definition, not a vendor’s marketing page, is what decides whether you need a BAA.
Your hosting provider is a business associate. Patient data sits on their disks. This is non-negotiable and it is the first BAA you need. Several managed hosts offer HIPAA-eligible plans with a BAA, usually at a significant premium over standard hosting, and standard shared hosting is not one of them.
A self-hosted form plugin generally is not. If the plugin writes entries to your own database and the vendor’s servers never see them, the vendor is not maintaining or transmitting PHI. Software you run yourself is closer to a filing cabinet than a service provider. This is why the self-hosted architecture is the practical answer.
Everything else attached to the form probably is. Email delivery, cloud file storage, spam filtering that inspects submissions, CRM sync, analytics that captures field values, and any form service that renders on someone else’s infrastructure. Each of those receives or transmits PHI, and each needs a BAA or needs removing from the path.
The 6 options compared
1. A self-hosted builder with entries stored locally
The architecture that makes this tractable, available from any major builder: Gravity Forms from $59, Fluent Forms from $63, Formidable from $35.55, WPForms from $49.50. All of them store entries in your WordPress database by default.
What makes the difference is not which one you pick but what you switch off. Disable the admin notification email that contains field values. Disable any integration that pushes entries outward. Turn off third-party spam services that inspect content. At that point the form is a local application writing to a local database, and the vendor is out of scope. The plugin choice then comes down to ordinary criteria such as conditional logic, file handling and price, and the compliance work happens in the settings rather than the shopping.
- BAA needed from vendor: Generally no, if nothing leaves your server
- Price: From $35.55 to $63 a year
- Best for: Practices that control their own hosting
- Watch out for: Default notification emails carry PHI off the server
2. HIPAA-eligible hosting with a signed BAA
The purchase that actually matters, and the one most practices skip while buying a plugin instead. Your host holds the data, so your host must sign.
Expect HIPAA-eligible hosting to cost several times standard managed WordPress hosting, because you are buying encryption at rest, access logging, staff background controls and a contractual commitment rather than a faster server. Ask three questions in writing: will you sign a BAA, is data encrypted at rest, and who on your staff can access the database. A host that hesitates on any of them is not the right host, regardless of what their marketing page says about security. This is also the item to buy first, because the plugin decision barely matters if the server underneath is not covered.
- BAA needed: Yes, absolutely, and in writing
- Price: Substantially above standard managed hosting
- Best for: Every practice storing PHI on a website
- Watch out for: Shared hosting cannot satisfy this
3. Encrypted field storage add-ons
The technical control that turns a database breach into a much smaller problem: entry values encrypted at rest, decryptable only with a key held outside the database.
Several builders offer this through add-ons or premium tiers, and it is worth having for exactly one reason: if the database is exfiltrated, encrypted fields are not a disclosure. The practical costs are real. Encrypted fields are hard to search, exports need decryption, and if you lose the key the data is gone permanently rather than inconveniently. Store the key outside the web root, back it up separately from the database, and test the restore before you rely on it. Encryption you cannot reverse in a crisis has protected nothing except your data from yourself.
- BAA needed: No, if the add-on is self-hosted
- Price: Add-on or premium tier, varies by builder
- Best for: Any form storing PHI in the database
- Watch out for: Lose the key and the data is unrecoverable
4. A hosted form service that will sign a BAA
The opposite architecture: let a specialist hold the data and take on the compliance obligation contractually. Several form SaaS providers offer HIPAA plans with a BAA, embedded into a WordPress page.
This is a legitimate and often sensible choice for a small practice with no technical staff. You are paying a premium, typically on a monthly plan well above a WordPress plugin licence, and in exchange the encryption, access control, audit logging and the BAA are somebody else’s problem. The catch to check is scope: a provider may offer a BAA only on specific plans, and embedding their form on your page can still load scripts from your site that touch the submission. Read which plan the BAA attaches to, and confirm that the embed method keeps PHI inside their boundary rather than passing through yours.
- BAA needed: Yes, and it is the point of the purchase
- Price: Monthly, typically well above a plugin licence
- Best for: Small practices without technical staff
- Watch out for: BAA may attach only to specific plans
5. Not collecting PHI on the website at all
Free, and correct far more often than the category admits. Most practice websites do not need to collect health information; they need to book an appointment and get somebody into a system that is already covered.
Ask what each field is actually for. A contact form asking for name, email and preferred appointment time is not collecting PHI in any meaningful sense, and the whole compliance problem evaporates. The intake questionnaire, symptom description and insurance details can live inside your practice-management system or patient portal, which is already covered by a BAA you have already signed and already paid for. The website’s job becomes getting the patient to that portal. This is the cheapest, safest architecture available and it is the one a surprising number of practices arrive at after spending months on the alternative.
- BAA needed: None beyond what you already have
- Price: Free
- Best for: Most practice websites, honestly
- Watch out for: Audit every field; “just in case” fields create the problem
6. The patient portal your EHR already includes
Almost every practice-management and EHR system ships a patient portal with intake forms, and almost every practice underuses it while building the same thing on WordPress.
The portal is already covered by your existing BAA, already has authentication, already writes into the patient record rather than into an inbox, and already handles retention. Building intake on the website means rebuilding all of that and then manually transcribing submissions into the record, which is both a compliance surface and a transcription-error surface. Before commissioning anything, ask your EHR vendor what their portal does. The honest answer for a large share of practices is that the website should link to it rather than compete with it, and the money is better spent making that link obvious than on encrypted form fields.
- BAA needed: Already signed with your EHR vendor
- Price: Included in software you already pay for
- Best for: Any practice with an EHR or practice-management system
- Watch out for: Portal usability is often poor; that is a real objection
Comparison table
| Option | Vendor BAA needed | Where PHI lives | Cost | Best for |
|---|---|---|---|---|
| Self-hosted builder, local entries | Generally no | Your database | $35.55 to $63/yr | Practices controlling hosting |
| HIPAA-eligible hosting | Yes, essential | Their servers | Premium over standard | Everyone storing PHI |
| Encrypted field storage | No, if self-hosted | Your database, encrypted | Add-on or premium tier | Defence against breach |
| Hosted HIPAA form service | Yes, that is the point | Their infrastructure | Monthly, premium | Practices without IT staff |
| Collect no PHI | None | Nowhere | Free | Most practice websites |
| EHR patient portal | Already signed | Your EHR | Already paid for | Practices with an EHR |
Email is where this usually goes wrong
A practice can buy compliant hosting, encrypt the database and pick the right plugin, and then undo all of it with one setting that is switched on by default in every form builder.
- The notification email contains everything. By default, builders email you the submitted values. That email crosses your mail provider, sits in an inbox and may be forwarded. Send a bare “new submission received” alert with a link to the admin screen instead.
- Your mail provider is a business associate the moment PHI is in a message. Either get a BAA from them or ensure PHI never enters an email at all. The second is easier and free.
- Spam filtering may inspect content. Services that analyse submissions to score them are receiving PHI. Use a honeypot or a local method instead of a cloud filter on forms carrying health data.
- Analytics can capture field values. Session recording and heatmap tools are the serious risk here; several can record form input. Exclude them from any page with an intake form.
- Backups contain PHI too. If you back up off-site, that storage provider is in scope, and encryption of the backup is the fix.
Set a retention period at the same time. Form entries containing health information should not accumulate indefinitely in a database table because nobody thought to delete them, and “we still have every intake form since 2019” is a disclosure risk with no clinical benefit.
Frequently asked questions
Is any WordPress form plugin HIPAA compliant?
No plugin is compliant on its own, because compliance describes your whole arrangement rather than a piece of software. A self-hosted plugin can be part of a compliant setup; it cannot deliver one by itself.
Do I need a BAA from my form plugin vendor?
Generally not, if the plugin runs on your server and transmits nothing to the vendor. You do need one from your host, and from any service the form sends data to. Confirm each in writing.
Can I use standard managed WordPress hosting?
Not for storing PHI. You need a host that will sign a BAA and can describe its encryption and access controls. Standard shared hosting cannot meet that, whatever its security page claims.
Is an SSL certificate enough?
No. TLS protects data moving between browser and server. It does nothing about data at rest in your database, in notification emails, in backups or in exports, which is where most exposure actually sits.
What about a simple appointment request form?
Name, email and a preferred time are usually not PHI in any meaningful sense. The moment you add “reason for visit” or symptoms, it is. Audit your fields and remove anything you do not genuinely need.
Who is actually responsible if this goes wrong?
You are, as the covered entity. A BAA distributes obligation contractually but does not remove yours, which is why “the plugin said it was compliant” is not a defence and why written agreements matter more than marketing claims.
The verdict
First, audit whether you need to collect PHI on the website at all. For a large share of practices the answer is no, and an appointment-request form plus a link to the existing patient portal removes the entire problem for nothing.
If you must collect it, buy the hosting before the plugin. HIPAA-eligible hosting with a signed BAA is the purchase that matters; the form builder is a $35 to $63 decision on top of it.
Then switch off the notification email. The default setting that emails you every submitted value is the single most common way a carefully built compliant setup leaks health data, and fixing it costs nothing.
And get every BAA in writing before you rely on it. Vendor policies change, marketing pages are not contracts, and the obligation stays with you regardless of what any plugin’s feature list says.
