PHIPA compliance for Ontario health technology

What PHIPA covers, and what it does not

The Personal Health Information Protection Act, 2004 is Ontario's health privacy statute. It regulates the collection, use and disclosure of personal health information, which is identifying information about an individual that relates to their physical or mental health, the provision of health care to them, payments or eligibility for health care, the donation of body parts or substances, their health number, or the identity of their substitute decision-maker. The definition is broad on purpose. A booking record that shows a named person attended a fertility clinic is personal health information even if it contains no clinical detail at all.

PHIPA binds health information custodians. That is a defined list, not a judgement call: practitioners such as physicians, nurses and psychologists, hospitals, long-term care homes, pharmacies, laboratories, ambulance services, community health centres, medical officers of health, and a handful of provincial bodies. If you are a software company, you are almost never a custodian. Your customer is.

This is the single most important structural fact about PHIPA and the one founders get wrong most often. The law does not hand you a compliance certificate to obtain. It hands your customer a set of duties, and your customer discharges some of those duties through you. Your obligations arrive partly through the statute and its regulation, and partly through the contract your customer signs with you. Both matter, and a well-drafted contract does not relieve you of the statutory pieces.

PHIPA also does not cover everything a health technology company holds. Employee records, marketing lists, billing information about a corporate customer, and information about individuals who are not receiving health care through your custodian customers generally fall under PIPEDA or provincial private-sector law instead. Companies that draw the line badly end up applying health-grade controls to a CRM and no controls at all to a clinical audit trail.

Agent, electronic service provider, or health information network provider

PHIPA and its general regulation, O. Reg. 329/04, create three different relationships a vendor can have with health information. They are not mutually exclusive, and most Ontario health tech products sit in two or three at once.

An agent is a person or organization authorized by a custodian to perform services or activities on the custodian's behalf in respect of personal health information. An agent may collect, use, disclose, retain or dispose of health information only as permitted by the custodian, only for the purposes the custodian permits, and only if the custodian itself would be permitted to do the same thing. An agent holds no independent right to the information. That is the sentence that kills most product analytics roadmaps: the data being in your database does not make it yours to learn from.

An electronic service provider is a person who supplies goods or services for the purpose of enabling a custodian to use electronic means to collect, use, modify, disclose, retain or dispose of personal health information. Section 6 of O. Reg. 329/04 sets out what an electronic service provider who is not an agent may and may not do: broadly, it may not use the information it has access to except as necessary to provide the services, may not disclose it, and must not permit its own staff or contractors to access it unless they have agreed to comply with the same restrictions. Hosting, storage and infrastructure providers frequently land here.

A health information network provider, universally shortened to HINP, is an electronic service provider that supplies services to two or more custodians primarily to enable them to use electronic means to disclose personal health information to one another. The obligations in section 6(3) of the regulation attach to a HINP directly rather than flowing through a contract, which is why the status matters so much. If your product lets one clinic share a record with another clinic, or connects practices to a shared repository, you should assume you are a HINP and work backwards from there.

The HINP duties are concrete. Notify every affected custodian at the first reasonable opportunity of any unauthorized handling of the information. Provide each custodian with a plain-language description of the services, including the safeguards in place, in a form the custodian can make available to the individuals it serves. Keep, and make available to each custodian on request, an electronic record of all accesses to and all transfers of personal health information associated with the custodian. And perform, at least every two years, a written assessment of the services covering threats, vulnerabilities and risks to the privacy of the information and its integrity, then make the results available to the custodians.

That last one has a budget consequence people discover late. A recurring written assessment every two years is an operating cost from the day you connect your second custodian, and it looks a great deal like a threat and risk assessment. Firms that plan for it schedule it alongside their penetration test and reuse the evidence. Firms that do not plan for it get asked for it in a procurement cycle and have eight weeks to produce something that takes longer than eight weeks to do properly.

The custodian's flow-down duty, and why your contract reads the way it does

When a custodian provides personal health information to an agent, PHIPA requires the custodian to take steps that are reasonable in the circumstances to ensure that the agent, and any electronic service provider that agent uses, will handle the information in accordance with the custodian's permissions and the Act. That single duty is why hospital contracts are shaped the way they are.

The custodian cannot discharge a duty to take reasonable steps by trusting you. It has to be able to show a regulator what those steps were. So it writes them into an agreement, asks you to attest to them, and asks for evidence they operate. Every clause you find irritating in a hospital template is an artifact of somebody needing to prove they did something reasonable.

Separately, PHIPA requires a custodian that uses electronic means to handle personal health information to comply with the requirements prescribed by regulation, which is the hook that pulls O. Reg. 329/04 into force. Your customer inherits those prescribed requirements and can only meet some of them if your product behaves correctly. The audit log is the clearest example, and we come back to it below.

What this means practically is that the negotiation is rarely about whether you accept an obligation. It is about whether the obligation is expressed in terms you can evidence. "Vendor shall maintain appropriate security" is unfalsifiable and will be reinterpreted against you after an incident. "Vendor shall encrypt personal health information at rest using AES-256 and in transit using TLS 1.2 or higher, shall maintain per-user access logs retained for not less than the custodian's retention period, and shall provide those logs to the custodian on request within five business days" is something you can build a control around and a control you can pass.

The safeguards duty in section 12, translated into engineering

Section 12 of PHIPA requires a custodian to take steps that are reasonable in the circumstances to ensure that personal health information in its custody or control is protected against theft, loss and unauthorized use or disclosure, and that records containing the information are protected against unauthorized copying, modification or disposal. The statute deliberately does not list controls. The Information and Privacy Commissioner of Ontario's orders and guidance are where the expectations become specific.

In practice, an Ontario health data platform that passes review has most of the following. Encryption in transit and at rest, with keys managed outside the application and rotated on a schedule. Role-based access control where roles map to clinical function rather than to convenience. Multi-factor authentication for every administrative and remote path into the environment. Logical separation between custodians, evidenced, so that one clinic's information cannot be reached from another clinic's tenant even by a misconfigured query. Production access that is time-boxed, reason-coded and attributable to a named human. Backups that are encrypted, tested by restore, and covered by the same retention and disposal rules as the primary data.

Two areas fail reviews more often than the rest. The first is mobile and endpoint: a clinician-facing application that caches records on a device, or an employee laptop that can pull an export, extends the custodian's risk surface into places nobody assessed. The IPC has been consistent for years that unencrypted mobile devices holding health information are unacceptable, and a custodian that has been through a lost-laptop incident will ask you pointed questions about local caching.

The second is your own staff. Support engineers with standing production access are the most common serious finding in a health technology environment. The fix is not a policy saying access is limited. It is an impersonation or break-glass mechanism where a support engineer requests access to a specific tenant for a specific reason, that request is approved and time-limited, and the resulting session appears in the same audit log the custodian can read. Build that once and roughly a third of the hard questions in a hospital review answer themselves.

Section 13 adds a related duty: records must be retained, transferred and disposed of in a secure manner. Secure disposal is a control that has to produce evidence. A deletion job that runs and logs nothing is indistinguishable from a deletion job that silently failed two quarters ago.

Audit logging is a product requirement, not a policy

PHIPA requires custodians that use electronic means to maintain personal health information to keep an electronic audit log, and to be able to produce it to the Commissioner on request. The log has to answer a specific question: for a given record, who accessed it, and when. Your customer cannot answer that question if your software does not generate the answer. This makes record-level access logging a functional requirement of the product rather than a document in a compliance folder.

The version that fails is application logging that records API calls, HTTP status codes and latency but does not record which patient record was viewed by which named user. The second version that fails is logging that captures end users properly but treats your own support staff, batch jobs and integrations as a single service account. From the custodian's side, "svc-app" opened four thousand records last Tuesday is not an audit trail, it is a finding.

A log that survives a review generally carries, per access event: the identity of the individual whose record was accessed, the identity of the person who accessed it, the organization or tenant that person belongs to, the date and time with timezone, the nature of the access, whether it was a read, a modification, an export or a disclosure, and where relevant the reason code or the workflow that triggered it. Automated and integration access is labelled as such and attributable to a configured integration, not to a shared credential.

Retention of the log is its own decision. Custodians commonly expect the audit log to be retained at least as long as the underlying record, because a privacy complaint about a 2019 access is investigated in 2026. Cheap log storage tiers exist for exactly this. What does not work is a ninety-day observability retention policy applied to a clinical audit trail because both happen to be called logs.

Finally, the log has to be queryable by the question the custodian will ask. That question is almost always "produce every user who viewed this named patient's record between these two dates". If answering it requires an engineer to write a one-off query against cold storage, you will answer it slowly during an active privacy investigation, which is the worst possible time. Build the report.

Consent, the circle of care, and the lockbox

PHIPA runs on consent, but not the click-through kind. For the purpose of providing or assisting in the provision of health care, a custodian may generally rely on an individual's implied consent to collect, use and disclose personal health information among the custodians involved in that care. Practice calls this the circle of care, and it is why a specialist can pull a referral without collecting a signature.

Two limits narrow it, and both have product consequences. First, implied consent covers health care purposes. It does not cover your purposes. Product analytics on identifiable health information, model training, benchmarking across customers, marketing and research are not health care purposes, and no amount of terms of service between you and the custodian creates a consent the individual never gave. Research use in particular has its own route under PHIPA involving a research plan and a research ethics board, and it is not a route you can take unilaterally as a vendor.

Second, an individual may withhold or withdraw consent to a specific use or disclosure. This is the lockbox, and it is the requirement most commonly missing from a health technology data model. If a patient instructs their family physician not to disclose a particular episode of care to another provider, the custodian has to be able to honour that instruction, and if the record lives in your system, you have to be able to represent it. A custodian that discloses despite a directive is in breach, and a product that cannot flag a record or a data element as restricted from onward disclosure is a product a custodian cannot lawfully operate.

The associated behaviour is subtler than a boolean. When a custodian discloses information for health care purposes and has withheld something because of a directive, it must notify the recipient that the disclosure does not include everything. So the receiving side of your integration needs to be able to display a flag saying information has been withheld, without revealing what was withheld. Teams that discover this late usually have to change a schema and a rendering layer at the same time.

De-identification is the other consent-adjacent trap. PHIPA gives custodians more freedom with de-identified information, 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 plus date of service plus a rare diagnosis in a small Ontario community is identifying. If your roadmap includes 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 actually permit.

Breach: who notifies whom, and in what order

PHIPA breach handling has a fixed order of operations, and vendors get into trouble by improvising it. If you are an agent, your first duty is to notify the custodian at the first reasonable opportunity when personal health information is stolen, lost, used or disclosed without authority. Your contract very often compresses "first reasonable opportunity" into a specific number of hours. Read that number before you sign it and check it against how quickly your on-call process can confirm a security event, not how quickly it can detect one.

The custodian, not you, decides on notification to the affected individuals, and the custodian, not you, decides whether the incident falls into one of the categories that must be reported to the Information and Privacy Commissioner of Ontario. Those prescribed circumstances include information used or disclosed without authority by a person who knew or ought to have known they were not permitted to do so, theft, further unauthorized use or disclosure after an initial one, a pattern of similar incidents, disciplinary action taken against a member of a regulated health profession or another employee in connection with unauthorized handling, and breaches that are significant having regard to the circumstances. Custodians also file annual breach statistics with the IPC.

If you are a health information network provider, you have your own direct duty to notify every affected custodian at the first reasonable opportunity. That obligation does not wait for you to establish scope, and it does not go through a single lead customer. Every custodian whose information may have been affected gets told.

Practical advice from incident work. Do not send a preliminary record count. Send the custodian what you know, what you do not yet know, when you will next update them, and what containment has already happened. Counts change, and a revised number reads to a privacy officer as a second incident after they have already briefed their executive. Keep a written timeline from the first alert onward, because the custodian will need it for their own record and possibly for their report to the IPC. Nominate one named contact on your side and keep them the same person for the whole incident.

Understand also why the custodian sounds anxious. PHIPA offences carry fines of up to $200,000 for an individual, with the possibility of imprisonment, and up to $1,000,000 for an organization. Regulated health professionals 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 hospital privacy officer asks who at your company can read a patient record, they are asking a question they may personally have to answer.

What a hospital vendor review actually asks for

Ontario hospital procurement is more structured than a typical enterprise SaaS review, and it is run by people who do this constantly. The document set is fairly consistent across institutions, which is good news: build it once and it serves every subsequent bid.

Expect a privacy and security questionnaire that is the institution's own workbook rather than a standard framework. Expect a request for a privacy impact assessment, sometimes one the hospital runs with your input, sometimes one they expect you to have. Expect a threat and risk assessment or the results of a recent penetration test with a remediation status. Expect a data flow diagram naming every system and every subprocessor that can touch personal health information, including anything used for support ticketing, error reporting and analytics. Expect a hosting and residency answer. Expect proof of cyber liability insurance with limits, and increasingly, evidence you have tested a restore and exercised an incident response plan.

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

That last question deserves a real answer before it is asked. Custodians are entitled to know that a change of control does not silently transfer their patients' information to a new owner with different intentions. A clause committing to return or certified destruction on termination, plus a statement that health information is not an asset you would transfer without custodian consent, closes it.

On residency, be straightforward. PHIPA itself contains no data residency requirement, and Ontario has never had the blanket prohibition that some other provinces applied to their public bodies. What custodians have instead is institutional policy and procurement templates that require Canadian hosting anyway. Arguing the law at a hospital procurement officer is a losing move. If your product can run in a Canadian region, run it in a Canadian region and remove the objection. Our guide to Canadian data residency covers how to answer the question honestly when you cannot.

Retention, disposal and what happens at the end

Retention under PHIPA is set by the custodian, not by you, and it is longer than software teams expect. Ontario regulated health professionals operate under college record retention rules that commonly run to ten years after the last entry, or ten years after a patient reaches the age of majority for paediatric records. Hospitals have their own schedules. A vendor whose deletion default is thirty days after account closure is not being conservative, it is breaking the custodian's record-keeping obligations.

The correct architecture is retention as a per-custodian configuration with a documented default, not a global constant. That means every deletion path in the system consults the configuration, including backups, exports, search indexes, caches, message queues, analytics warehouses and any copies held by subprocessors. Teams that have never mapped this discover during a review that a full copy of the primary database has been sitting in a business intelligence tool with no retention policy at all.

Secure disposal has to be evidenced. A disposal record should say what was disposed of, at whose instruction, under what authority, when, by what method, and who confirmed it. For cloud storage, the honest answer is usually cryptographic erasure plus the provider's deletion attestation, and it is fine to say so as long as you say it precisely. For physical media, a certificate of destruction is standard and easy to obtain.

Contract end is where the sequence has to be planned in advance. The custodian needs its information back in a usable format, then confirmed destruction of your copies, then a certificate. A defensible exit process states the export format, the timeframe, the transition assistance period, the deletion timeline including backup expiry, and the form of the destruction certificate. Backup expiry is the detail everyone forgets: if your backups have a thirty-five day retention, your certificate cannot honestly be issued on day one, and it is much better to say that up front than to be asked about it later.

PHIPA alongside PIPEDA, and why the answer is usually both

PHIPA and PIPEDA are not alternatives you choose between. Ontario's health privacy provisions have been declared substantially similar to PIPEDA for the purposes of personal health information handled by custodians in Ontario, so PHIPA effectively occupies that field for that information within the province. PIPEDA continues to apply to personal information collected, used or disclosed in the course of commercial activity that PHIPA does not cover, and to information crossing provincial or national borders in the course of commercial activity.

For a typical Ontario health technology company, the honest position is that PHIPA governs the clinical data you hold on behalf of custodians, and PIPEDA governs the rest of your business: your prospects, your website analytics, your employees where applicable, and any direct-to-consumer product where you are not acting for a custodian. Direct-to-consumer is the tripwire. The moment your app collects health information directly from an individual outside a custodian relationship, you are no longer an agent, and you become the accountable organization under PIPEDA in your own right, with all the consent, access, correction and breach-reporting duties that come with it.

If you also sell in Quebec, Alberta or British Columbia, add the applicable provincial statute. Quebec's Law 25 has its own private-sector regime and a cross-border assessment requirement. Alberta has both a private-sector act and a separate Health Information Act with its own custodian concept. British Columbia has PIPA. Our guides on which Canadian privacy law applies and on Alberta HIA and BC PIPA work through the overlaps.

PHIPA is also not HIPAA. They are different statutes in different countries, with different regulators, different breach thresholds and different vocabulary. A HIPAA-oriented program covers a lot of the same practical ground, so the safeguards travel well, but the legal obligations do not. Telling an Ontario custodian you are HIPAA compliant answers a question nobody asked and signals that you have not read their statute. Our HIPAA in Canada guide covers that mismatch in more depth.

Where SOC 2 and ISO 27001 fit

PHIPA is law. SOC 2 is an attestation by a licensed CPA firm about your controls. ISO 27001 is a certification of a management system. None of them substitutes for the others, and a SOC 2 report does not make you PHIPA compliant.

What a report does is answer the evidence question. A custodian discharging its duty to take reasonable steps needs something more than your assurance. An independent report describing your controls and, in a Type II, testing that they operated over a period, is the most efficient thing you can hand them. That is why Ontario custodians increasingly ask for one even though no statute mentions it.

The efficient structure is a single control set scoped so that the controls your PHIPA obligations turn on are inside the audit boundary. Concretely: access control and reviews, logging and monitoring including the record-level audit trail, encryption, change management, vendor management covering your subprocessors, incident response including the custodian notification path, and secure disposal. Evidence those once, and let the SOC 2 report, the privacy impact assessment, the HINP biennial assessment and the hospital questionnaire all draw from the same pile.

The wasteful pattern, which we see often, is buying a privacy impact assessment from one firm, a threat and risk assessment from another and a SOC 2 readiness engagement from a third, then discovering all three asked the same team the same questions and produced three overlapping descriptions of the same controls that now have to be kept in sync. Our evidence register approach exists because of that pattern.

A realistic sequence for a vendor starting from zero

The order matters, because several of these depend on each other and the expensive one is engineering work that cannot be compressed.

First, establish status. Write down, for each product and each customer relationship, whether you are an agent, an electronic service provider, a health information network provider, or the accountable organization in your own right. This takes an afternoon and it determines everything downstream. Getting it wrong in the optimistic direction is the most expensive mistake available.

Second, map the data. Every place personal health information lands, including support tooling, error trackers, analytics, email, backups and every subprocessor. Name the owner of each. This is also the artifact the hospital will ask for, so build it in the form you would send.

Third, fix the audit log, because it is engineering work measured in sprints rather than policy work measured in days. If record-level, per-user access logging does not exist, start it before anything else. Everything else in this list can be produced faster than this can.

Fourth, build the access model: named accounts, multi-factor authentication, no standing production access, break-glass with reason codes, and quarterly access reviews that produce a signed record. Fifth, write the documents: information practices, retention schedule, incident response plan with the custodian notification path and clock in it, and a subprocessor list. Sixth, run the assessment, whether that is a privacy impact assessment, a threat and risk assessment, or the HINP biennial assessment, and remediate what it finds.

Then, and only then, consider the audit. A SOC 2 Type II observation window over a control set that does not yet work is an expensive way to document that it does not work. Our SOC 2 requirements guide covers what has to be in place before the window opens, and what it costs.

Realistic timing for a small vendor with a working product and no prior program: two to four months to status, mapping, documents and access controls, plus however long the audit logging work takes, which is anywhere from three weeks to two quarters depending on how the product was built. Then a three to six month observation window if a Type II is the goal.

The failure modes we see most often

Assuming the contract is the whole obligation. Electronic service provider and health information network provider duties attach directly. A weakly drafted agreement does not save you from them, and a strongly drafted one does not exhaust them.

Product analytics on identifiable health information. The most common quiet breach in Canadian health tech. An agent has no independent right to use the information for its own purposes, including improving its own product, unless the custodian has authorized it and the custodian could lawfully do it itself.

Becoming a health information network provider without noticing. The feature that lets one customer share a record with another customer is often shipped as a convenience. It changes your legal status and adds a recurring biennial assessment obligation.

Audit logs that cannot answer the question. API-level logging, shared service accounts, and ninety-day retention are the three variants. All three surface at exactly the moment a custodian is investigating a complaint.

Support access as a standing privilege. Easy to fix early, painful to retrofit once support workflows depend on it.

Retention defaults set by engineering convenience. Thirty-day deletion after account closure conflicts with a ten-year college retention rule, and the custodian is the one who ends up in breach.

Treating a SOC 2 report as the answer to PHIPA. It is evidence about controls, not compliance with a statute, and a sophisticated custodian will tell you so.

// at a glance

Your status under PHIPA and what attaches to it

// questions

Frequently asked

// keep reading

Related