PHIPA: What Your Clinic Website Form Can Collect

Ontario's Personal Health Information Protection Act, 2004 (PHIPA), consolidated on 1 January 2026, governs how "health information custodians" collect, use, disclose and protect personal health information. As of 15 October 2026, the sections that matter for a clinic website are:

Table · scrolls sideways

The practical question for a website is "does this form collect personal health information, and does it need to?" Section 30 answers the second half for most fields.

Keep every public form on the marketing side of a clear line. A name, a way to reply and a general reason for contact are usually enough to book a call. When a field asks someone to describe symptoms, list medications, confirm a diagnosis or enter a health card number, the form is collecting personal health information it does not need, and the systems behind it (form plugin, inbox, spreadsheet) now hold it.

Table · scrolls sideways

Even the "yes" rows are not automatically outside PHIPA. Section 4 includes information that identifies someone as a person's health care provider, so a message from an existing patient to their clinic can be personal health information. That is a reason to limit who can read submissions, not a reason to add fields.

Apply the same test to any field added after launch: does it need to sit on the website's systems before a patient relationship exists, or can it wait for the booking system?

A marketing site is often built and maintained by someone other than the clinic's EMR vendor: a web studio, a freelancer, a form plugin. That is fine while the form collects nothing clinical. Once it does, two rules engage:

1. Agents (PHIPA s. 17). A person who handles personal health information on the clinic's behalf is its agent, and the clinic remains responsible for what the agent does with it.
2. Electronic service providers (O. Reg. 329/04 s. 6). A person who supplies services that let a custodian collect or store personal health information electronically, without being its agent, may use the information only as needed to provide the service, may not disclose it, and must bind its own staff to the same restrictions.

The IPC's PHIPA FAQ describes both roles. A web vendor with access to form submissions is in one of them, often without either side having agreed to it.

In your practice-management system: Jane, Cliniko or whatever you already use. Link to or embed that system's own booking flow rather than building a parallel "request an appointment" form that collects overlapping information in a second place. We cover the link-versus-embed decision in choosing online booking for a small clinic. One booking system means one patient record and one place your safeguards have to work.

The common failure is not a hacked database. It is a form notification forwarded to a personal inbox, or a shared spreadsheet of "who called about what". The IPC's email fact sheet sets out what it expects of custodians that use email:

• Encrypt where you can; many booking and EMR systems include encrypted messaging.
• Before using unencrypted email with patients, notify them of a written email policy and get their consent. The fact sheet gives limiting unencrypted email to appointment scheduling as one example.
• Send from professional accounts, not personal ones, which may have weaker security.
• Collect and send only the minimum information needed.

A spreadsheet that holds health information needs the same access controls as your EMR.

Put a short line at the point of submission, not only in a linked policy: what the form is for, and what not to include. For example: "This form is for booking enquiries only. Please don't include health information; our team will follow up through our secure booking system."

Link it to a plain-language privacy statement that says who can see a submitted form, how long it is kept, and who to contact with a question. A statement a patient can read in a minute does more than one that mirrors the statute.