Patient Intake Forms on WordPress: A Privacy Checklist for Canadian Clinics

Why ordinary WordPress forms are a problem

A default WordPress form does two things with each submission: it saves a copy in the site database and it emails a copy to the clinic. Both are weak places to keep health information. The database sits on a web server that is exposed to the internet, and ordinary email is not encrypted from end to end and tends to be forwarded, searched and kept forever.

In Canada, health information is treated as sensitive personal information. Federal private-sector privacy law (PIPEDA) and provincial health information laws, such as PHIPA in Ontario and the Health Information Act in Alberta, set expectations about safeguards, consent and access. Which law applies to your clinic depends on your province and how you practise, which is why this article stays with practical safeguards and leaves the legal reading to your adviser. Our broader guide to a healthcare clinic WordPress website covers the other parts of a clinic site.

Sort your forms into three groups

Start by sorting every form on the site by what it collects, because only one group needs special handling.

The middle group is the one clinics overlook. A message box labelled "Tell us about your concern" invites a patient to type symptoms into a form that emails them in plain text. Change the label to "Preferred days and times", add a short line asking people not to include medical details, and the form does its job with much less risk.

Three ways to handle sensitive forms

For intake and history forms there are three sound approaches. The right one depends on the software your clinic already uses.

1. Use your practice management or EMR system's own forms. Many clinic systems offer online intake and booking that feed the patient record directly. The website then only links to or embeds that form. This is usually the best answer because the information never touches WordPress at all.
2. Use a dedicated secure form service. If your clinic system has no intake feature, a form service designed for health information can collect the data and hold it in its own encrypted storage. WordPress again only links or embeds. Ask where the data is stored and who can access it.
3. Keep the form on WordPress but keep the data off it. With custom development, a form can pass its contents straight to a secure system and store nothing in the website database, sending the clinic a notification that contains no patient details. This takes careful work and testing, and it is the option to choose only when the first two are not available. It is the kind of job our custom plugin development service handles.

In all three cases the principle is the same: the website is the front door, not the filing cabinet. The same thinking applies to online booking. See how to add a booking system to WordPress for the general options, and apply the vendor questions below before you choose one.

The privacy checklist

Use this list to review a clinic site. Every item can be checked by the clinic manager with help from whoever maintains the site.

• Inventory. List every form, what it collects, where entries are stored and who receives the email.
• Collect less. Remove every field you do not need at that step. Do not ask for a health card number on a web form unless your adviser has confirmed it is appropriate and the form is in a suitable system.
• No health details by email. Notification emails should say "a new form was submitted" and link to the secure system, not include the answers.
• Turn off entry storage in WordPress for any form that might receive health details, or set entries to delete automatically after a short period.
• HTTPS everywhere, with the certificate renewing automatically.
• Limited access. Each staff member has their own WordPress login with the lowest role they need, with two-factor authentication on administrator accounts. Remove accounts when people leave.
• Updates and backups. Core, theme and plugins are kept up to date, and backups are encrypted and stored off the server. Remember that a backup of the database contains whatever your forms stored.
• Tracking. Analytics, advertising pixels and session recording tools should not run on pages where patients enter information. Review every third-party script on the site.
• File uploads. If patients upload referrals or images, they must go to the secure system, not the WordPress media library, where files can be publicly reachable by URL.
• Privacy notice. The site explains what is collected, why, where it is stored and who to contact, in plain language.
• A plan for incidents. Someone is named as responsible for privacy, and you know who to call and what to do if the site is compromised.

The general hardening steps are covered in how to secure a WordPress website. They are the base layer for everything above.

Questions to ask a form or booking vendor

Before you embed any third-party form or booking tool, get written answers to a short set of questions. A vendor that serves healthcare will have them ready.

1. Where is the data stored, and can it be stored in Canada?
2. Is data encrypted in transit and at rest?
3. Who at the vendor can access patient submissions, and is that access logged?
4. Will you sign an agreement that covers your role in handling health information?
5. How long is data kept, and how do we delete it or export it?
6. How will you tell us about a breach?
7. Does the tool send the contents of submissions by email?

Keep the answers on file. Be cautious with vendors, developers or hosting companies that describe themselves as "certified compliant" with a privacy law. Compliance is something a clinic achieves through its own practices, and no plugin or host can grant it. We do not claim any such certification ourselves. What a developer can do is build the site so that good practice is the easy path.

Common mistakes on clinic sites

The same few problems come up again and again, and all of them are fixable in a day or two.

• A full medical history form built in a general form plugin, with years of entries still sitting in the database.
• Form notifications going to a shared free webmail account.
• An advertising pixel firing on the appointment request page.
• One shared administrator login for the whole front desk.
• PDF intake forms that patients are told to email back.
• Old form plugins left installed after a switch to a clinic system, still collecting data nobody checks.

If the first item describes your site, export what you are required to keep into your clinic system, then delete the entries from WordPress and from old backups where you can.

Next step

Run the inventory first. It takes an hour and tells you whether you have a small tidy-up or a real problem. If you would like a second pair of eyes, we review clinic sites and rebuild form flows so that patient details stay out of WordPress. See our healthcare WordPress development page for how we work with clinics, or contact us with a list of the forms you use today.