PHIPA and AI: What Ontario Healthcare Organizations Must Know

The Personal Health Information Protection Act, 2004 was written two decades before ambient scribes and clinical decision support — and it applies to them completely. This guide walks through how PHIPA's existing scheme maps onto AI systems that process personal health information, and where organizations most often get it wrong.

PHIPA is technology-neutral — and that cuts against you

The Personal Health Information Protection Act, 2004(S.O. 2004, c. 3, Sched. A, in force since 1 November 2004) does not mention artificial intelligence, and it does not need to. Its obligations attach to personal health information (PHI) and to the health information custodian who holds it, regardless of the technology in the middle. An AI scribe's audio capture, a model's input context, a generated draft note, a decision-support tool's risk score derived from a chart — all of it is PHI or a use of PHI, and all of it sits inside the existing statutory scheme. There is no AI exemption, no pilot exemption, and no "the vendor handles compliance" exemption.

Three structural points matter most. First, the custodian remains accountable. When an AI vendor processes PHI on your behalf, it is typically acting as your agent under section 17 of PHIPA (or as an electronic service provider), and section 17 requires that the agent handle PHI only as permitted by the custodian, only for the custodian's purposes, and subject to the custodian's conditions. You cannot delegate accountability by contract, and a vendor's own privacy policy does not substitute for your authority.

Second, collection, use, and disclosure limits apply to every model interaction. PHIPA permits custodians to collect, use, and disclose PHI only with consent or under a specific statutory authority. Sending a chart excerpt to a hosted model is a use; if the vendor is not properly an agent, it may be a disclosure. Each pathway needs an identified legal basis before deployment, not after.

Third, section 12 safeguards are mandatory. Custodians must take steps that are reasonable in the circumstances to protect PHI against theft, loss, and unauthorized use or disclosure. For AI systems that means the unglamorous controls: encryption in transit and at rest, least-privilege access to transcripts and outputs, logging sufficient to reconstruct which systems and people touched which records, and a documented understanding of where the vendor hosts and processes data. The Information and Privacy Commissioner of Ontario's AI-scribe guidance for the health sector (January 2026) treats vendor assessment, contractual safeguards, and privacy impact assessments as baseline expectations — guidance, not statute, but it is the lens the regulator will apply when something goes wrong.

Consent for AI scribes and clinical decision support

PHIPA's consent model is built on knowledgeableconsent: the individual must reasonably understand the purposes of the collection, use, or disclosure. For an ambient scribe, that means patients should know a recording is being made, that an AI system will transcribe and draft documentation, and — in plain terms — where that data goes. A poster in the waiting room is notice of a sort; it is not a consent workflow. The IPC's scribe guidance emphasizes transparency and a genuine ability to decline, which in practice requires three things: a script clinicians actually use, a way to record an objection, and an encounter workflow that proceeds normally without the scribe when a patient says no. If refusing the scribe degrades the patient's care experience, the consent is not meaningfully voluntary.

Clinical decision support raises a different consent question. Where a tool operates on PHI already collected for the purpose of providing care, custodians often rely on implied consent within the circle of care — but that reliance should be examined, not assumed, particularly where the tool sends PHI outside the custodian's environment or where outputs materially shape treatment decisions. The joint IPC and Ontario Human Rights Commission principles for responsible AI use (January 2026, non-binding) add an equity dimension: transparency and recourse expectations apply with particular force where automated outputs affect individuals. Where your analysis is uncertain, document the uncertainty and the reasoning — an honest, recorded judgement is defensible; an unexamined assumption is not.

Data minimization applied to model inputs

Section 30 of PHIPA prohibits collecting, using, or disclosing PHI where other information would serve the purpose, and prohibits handling more PHI than is reasonably necessary. Applied to AI, this is a design constraint on model inputs. Questions to put to any deployment: Does the scribe need the full audio retained after transcription, or only the transcript? Does the decision-support tool need the full chart, or a defined subset of fields? Can identifiers be stripped or tokenized before the data reaches the vendor? Is PHI being used to train or fine-tune the vendor's models — and if so, under what authority, since improving a vendor's commercial product is not the custodian's purpose of providing care?

That last question deserves contractual teeth. A contract that is silent on training-data use is not a prohibition; it is an open door. The minimum position is an express clause barring the use of your patients' PHI for model training, with audit rights to verify it.

Breach duties when an AI vendor is involved

If PHI handled by an AI vendor is stolen, lost, or used or disclosed without authority, PHIPA's breach duties land on the custodian, not the vendor. Section 12 requires notifying the affected individual at the first reasonable opportunity, and notification to the IPC is required in the circumstances prescribed by regulation. Custodians also have annual statistical reporting obligations to the IPC for privacy breaches. Section 17 places a corresponding duty on agents to notify the custodian when PHI they handle is breached — but a statutory duty on the vendor does you little good operationally unless the contract converts it into a concrete commitment: a defined notice window, a named contact, and the forensic detail you need to run your own analysis and meet your own timelines.

The practical failure mode is temporal: the custodian's clock starts when the vendor tells them, and vendors without contractual deadlines tell them late. Your incident-response plan should treat every AI vendor holding PHI as a breach source, with the escalation path tested before it is needed.

The compliance gaps we see most often

Across assessments, the same gaps recur. Vendor contracts silent on training-data use — the single most common finding, and the cheapest to fix at signature time. PIAs skipped for "pilots"— PHIPA has no pilot exemption; a pilot processing real patient encounters is a deployment, and the IPC's guidance expects the assessment before PHI flows. Retention inherited from vendor defaults — audio and transcripts kept for whatever period the vendor happened to configure, which nobody on the custodian side has read, let alone approved against a retention schedule. And no audit trail of model access to PHI — organizations that can say which staff opened a chart often cannot say which encounters were sent to which model version, which makes both breach analysis and section 12 diligence unprovable. None of these gaps requires new law to close. They require someone to be accountable for closing them.

References