PHIPA Compliance in Ontario: What Health Tech Actually Has to Do

Direct answer: PHIPA is Ontario's health privacy law and it applies to personal health information handled by health information custodians and their agents. If you build software for Ontario clinics, hospitals or practitioners, you are almost certainly an agent, and your obligations flow from the custodian's through your contract with them.

Custodian or agent

A custodian is the clinic, hospital or practitioner who holds the health information. An agent acts on the custodian's behalf, which is where most health tech vendors sit. Agents may only use health information as permitted by the custodian, for the purposes the custodian permits, and must not use it for their own purposes without authority.

That is stricter than founders expect, and it catches product analytics. Using identifiable health information to improve your product is not automatically permitted because it sits in your database.

What the custodian will require of you

A written agreement covering permitted use. Safeguards proportionate to the sensitivity, which for health data means encryption, access control and logging that shows who accessed which record. Breach notification to the custodian, who has their own duty to notify the Information and Privacy Commissioner of Ontario and affected individuals. Retention and secure disposal. Often a privacy impact assessment before deployment.

PHIPA is not HIPAA

They are different statutes in different countries. A HIPAA-oriented programme covers much of the same practical ground, so the safeguards travel, but the legal obligations, the regulator and the breach thresholds do not. Claiming HIPAA compliance to an Ontario custodian answers a question nobody asked.

If you sell into both, run one control set and map it to both obligations rather than running two programmes.

Where SOC 2 fits

PHIPA is law; SOC 2 is an attestation. Neither replaces the other. In practice Ontario custodians increasingly ask for a SOC 2 report as evidence that the safeguards PHIPA requires actually operate, so the efficient route is a SOC 2 scoped to include the controls your PHIPA obligations turn on.

Our health data readiness work covers both, and this case study walks through a SOC 2 Type I for an Ontario medtech company putting an AI clinical assistant in front of practitioners.

The category most vendors miss: health information network provider

Agent is not the only status PHIPA hands out. Ontario Regulation 329/04 defines a health information network provider, a HINP, as a person who supplies services to two or more custodians primarily to enable them to use electronic means to disclose personal health information to one another. If your platform lets one clinic share a record with another clinic, or connects practices to a shared repository, you are probably a HINP as well as an agent, and the obligations are concrete rather than contractual.

A HINP must notify every affected custodian at the first reasonable opportunity of any unauthorised handling of the information. It must provide each custodian with a plain-language description of the services, including safeguards, that the custodian can make available to patients. It must keep and make available on request an electronic record of all accesses to and transfers of the information. And it must, every two years, perform and make available to custodians a written assessment of the services covering threats, vulnerabilities and risks to privacy and integrity. That last obligation is the one founders discover late, because it means a recurring third-party assessment is baked into your operating cost from the day you connect your second custodian.

Being a HINP does not make you a custodian. You still hold no independent right to use the information. What changes is that some duties now attach to you directly rather than flowing through a contract, which means a weakly drafted agreement will not save you.

What the custodian is worried about, and why

Custodians are not applying vendor risk theatre when they push hard on your architecture. They carry personal exposure. Since the 2017 amendments, PHIPA offences carry fines up to $200,000 for an individual, with the possibility of imprisonment, and up to $1,000,000 for an organisation, and prosecution no longer requires the six-month limitation period that previously blocked most cases. Regulated health professionals also face mandatory reporting to their college when an employee is disciplined for a privacy breach, which turns a snooping incident into a professional discipline matter. When a privacy officer at a hospital asks who at your company can read a patient record, they are asking a question they will personally have to answer.

The specific asks that come up in nearly every Ontario procurement are these. Where is the data hosted and which subcontractors can reach it. Who at your organisation has standing production access and what breaks that glass. Can you produce, for a named patient and a date range, the list of every user who viewed that record. How do you segregate one custodian's information from another's. What is your retention period and how is disposal evidenced. What happens to the information if the contract ends or the company is sold.

PHIPA itself contains no data residency requirement. Ontario has never had the blanket prohibition that British Columbia and Nova Scotia once applied to public bodies. What custodians have instead is institutional policy and, in the hospital sector, procurement templates that require Canadian hosting anyway. Do not argue the law at them. If your product can run in a Canadian region, run it in a Canadian region and remove the objection.

The audit log requirement is a product requirement

Custodians who use electronic systems to maintain personal health information must keep an electronic audit log recording, for every instance of access, the identity of the person accessing, the record accessed, and the date and time. They must be able to produce it to the Commissioner on request. Your customer cannot meet that duty if your product does not generate it, which makes record-level access logging a functional requirement of your software rather than a compliance document.

The version that fails a review is application-level logging that records API calls but not patient identity, or logging that captures end users but treats your own support staff and background jobs as a single service account. If a support engineer opens a customer tenant to reproduce a bug, that access needs to be attributable to a named human and visible to the custodian. Build impersonation as a logged, time-boxed, reason-coded action, and the hardest question in the review answers itself.

Consent, the circle of care, and the lockbox

PHIPA runs on implied consent for the provision of health care within what practice calls the circle of care, which is why a specialist can pull a referral without a signature. Two things narrow that. First, implied consent covers health care purposes, not your purposes, so it never authorises product analytics, model training, marketing, or benchmarking. Second, a patient can withhold or withdraw consent to specific disclosures, the so-called lockbox, and the custodian must be able to honour that instruction. If your data model cannot flag a record or a data element as restricted from onward disclosure, you have built something a custodian cannot lawfully operate.

The related trap is de-identification. PHIPA lets custodians use and disclose de-identified information more freely, but the standard is that the information must not reasonably be expected to identify an individual alone or in combination with other information. Postal code and date of service in a small Ontario community is identifying. If your roadmap depends on an aggregate data product, get the de-identification methodology written down and reviewed before you build the pipeline, not after a custodian asks what your terms of service actually permit.

When a breach happens

Your first duty as an agent is to notify the custodian at the first reasonable opportunity, and your contract may compress that to a fixed number of hours. The custodian then decides on notification to the individual, and separately whether the incident is one of the categories requiring a report to the Information and Privacy Commissioner of Ontario: theft, use or disclosure without authority, a pattern of similar incidents, disciplinary action against a college member or other employee, or a breach significant in the circumstances. Custodians also file annual breach statistics with the IPC.

Practical advice from incident work: do not send the custodian a preliminary count. Send them what you know, what you do not yet know, when you will next update them, and the containment steps already taken. The count will change, and a revised number reads as a second incident to a privacy officer who has already briefed their executive. Keep a written timeline from the first alert, because the custodian will need it for their own record and possibly for the IPC. Our first twenty-four hours guide covers the containment side, and retainer clients get the notification drafting handled with them rather than for them.

What drives cost and effort

Four things set the size of a PHIPA readiness programme. The number of custodians you serve, because each one may run its own assessment and each contract may impose different notification clocks. Whether you are a HINP, because the recurring written assessment and the transfer log are ongoing costs. Whether your architecture is multi-tenant with row-level separation or per-custodian instances, since instance sprawl multiplies access review and patching work. And whether you already produce record-level audit logs, because retrofitting them into a mature product is engineering work measured in sprints, not policy work measured in days.

The most common wasteful pattern is buying a privacy impact assessment from one firm, a threat risk assessment from another, and a SOC 2 readiness engagement from a third, then discovering all three asked your team the same questions and produced overlapping control descriptions. Run one control set, evidence it once, and let each deliverable draw from it. That is how our compliance work is structured, and it is why a Type I for an Ontario medtech can carry the PHIPA safeguards conversation at the same time.

When you should not hire us for this

If you have one Ontario clinic customer, a handful of records, and no plans to connect custodians to each other, you do not need an advisory engagement. Read the IPC's own guidance, which is genuinely good and free, sign a clear agreement covering permitted use and breach notification, turn on encryption and per-user audit logging, and revisit the question when you sign your fifth custodian. If your obligation is a one-off privacy impact assessment that a single hospital's procurement office requires, and your architecture is simple, a solo privacy consultant will do it for less than we will, and you should let them.

Bring us in when the picture is harder than that. Multiple custodians with conflicting contract terms, an AI feature that puts health information into a model provider's infrastructure, a product that has quietly become a HINP without anyone noticing, an access log that cannot answer the question a custodian is asking, or a stalled review where the safeguards exist but nobody can evidence them. Those are the situations where an outside operator earns the fee, and if yours is not one of them, we would rather tell you on the call. Talk to us and we will give you the honest read.