Health Details Sent Through a Plain HTTP Form

A form that asks a great deal, openly

A clinic or therapist's website has a form for new patients. It asks for a name, a date of birth, the symptoms, current medications, past surgeries, and sometimes a health card number.

The site still runs on plain HTTP, so there is no padlock in the address bar. When the visitor presses send, everything they typed travels to the server in readable form.

From there it arrives as an ordinary email in a shared inbox that several people read on their phones, and it stays there for years.

None of this was a decision. It is how the form was built when the site went up. The notes below are general information and should not be read as legal advice.

What the law expects

Canada's private-sector privacy laws expect a business to protect personal information in proportion to its sensitivity. The more sensitive it is, the stronger the protection should be.

PIPEDA, the federal law, does not cover every business. Some provinces have their own private-sector privacy laws, and which law applies depends on where and how the business handles personal information.

Health information sits near the top of any list of sensitive information. Professional regulators often add rules of their own about records, so check with yours as well.

Where the details travel

• From the visitor's browser to your server, readable on the way without HTTPS.
• From the server to your mail host as an ordinary email.
• Into a shared inbox that several people open.
• Onto every phone and computer that collects that inbox.
• Into backups and archives nobody thinks of as patient records.

The first is the one HTTPS fixes. The others need decisions about where submissions go and who can see them, and HTTPS does nothing for those.

What plain HTTP means for a form

Without HTTPS, what a visitor types crosses the network as readable text. On the public Wi-Fi of a cafe or a hotel, someone on the same network can capture it with freely available tools.

HTTPS encrypts what passes between the browser and your server, so the details cannot be read on the way. Browsers show it with a padlock beside an address that starts with https.

Visitors are learning to look for that padlock before typing anything personal. A health form without one asks them to trust a page that gives them no reason to.

Moving the form to HTTPS

It starts with a certificate for your domain, installed by your host or developer. A basic domain-validated certificate costs relatively little each year.

Move the whole site rather than the form page alone, and redirect every old address to its secure version.

Then check where the form actually sends. A form on a secure page that submits to an address beginning with plain http still travels unencrypted, whatever the padlock suggests.

Test it on a phone and a computer: the padlock should appear on every page, with no warnings about insecure content.

Email is not a filing cabinet

HTTPS protects a submission only as far as your server. Once it is sent on as an email, it sits in an inbox, gets forwarded, and copies itself to every device that reads that inbox.

Better systems keep the submission on a secure server, or inside the clinic's booking software, and send the inbox only a notice that something has arrived, with a link to sign in and read it.

Where email has to be used, send it to one restricted mailbox rather than a general one, and move each submission into the patient's file, then delete it.

Give each person who reads submissions a login of their own rather than one shared password, so access ends when someone leaves.

A worked example

An athletic therapy clinic with two certified athletic therapists treats sprains, strains and recovery after surgery for weekend athletes and school teams, from a unit beside a community recreation centre.

Its website had a form for booking an assessment, asking for a name, a date of birth, the injury and how it happened, current medications, past surgeries and any history of concussion. The site ran on plain HTTP.

Each submission arrived as an email in the clinic's general inbox, which both therapists and the front desk read on their phones. Two years of injury histories sat there among supplier invoices and newsletters.

The clinic moved the whole site to HTTPS, with every old address redirecting to its secure version.

The form now asks only for a name, a phone number or email, the sport, the injury in a few words and preferred times.

Medications, surgeries and concussion history are taken at the first appointment and recorded in the clinic's booking software, where each therapist has a login of their own.

The old submissions were moved into the patient files they belonged to, or deleted. The general inbox no longer holds anyone's health history.

Ask only what the first contact needs

A first enquiry needs enough to call someone back and book the right appointment: a name, a way to reach them, the reason in a few words and when they are free.

The full history belongs at the first visit, or in a secure intake form sent once the appointment is booked. Collecting it earlier means holding sensitive details about people who may never come in.

Leave out anything the clinic does not use. A health card number on a contact form is rarely needed, and every field removed is one less thing to protect.

The counter-case

A clinic whose form asks for nothing beyond a name, a phone number and a good time to call holds far less, and the risk is smaller. HTTPS is still worth having, but the urgency is lower.

Some clinics already book through software that runs its own secure forms. For them, the work is checking that the website links to those forms rather than to an old one of its own.

But any form that asks about health should run on HTTPS, deliver somewhere private, and ask for no more than the first contact needs.

This month

1. List every form that asks about health.
2. Move the whole site to HTTPS with redirects.
3. Check where each form actually submits.
4. Cut questions the first contact does not need.
5. Send notices, not full submissions, by email.
6. Move old submissions into patient files or delete them.
7. Issue separate logins to everyone who reads submissions.

Step four reduces the risk at its source. Details that are never collected cannot be intercepted, forwarded or forgotten in an inbox, and a shorter form is quicker to fill in as well.

What the recent changes to PIPEDA mean for consent wording is covered in PIPEDA changes in the Digital Privacy Act.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.