What PHIPA actually asks of a denture practice's records

"PHIPA compliant" appears on the front page of nearly every product sold into Ontario healthcare, and it is not a thing anyone can be certified as. There is no auditor, no badge, no register. PHIPA does not regulate software at all — it regulates custodians, and in a denture practice the custodian is you.

Which sounds worse than it is. It means the useful question is not "is this software compliant" but "does this software let me do the things the Act requires of me". That question has concrete answers, and you can test most of them in an afternoon.

Who is responsible — the practice or the vendor?

The practice is the custodian; the vendor is an electronic service provider acting on the practice's behalf. That is the whole architecture of the thing, and almost every other conclusion follows from it. The record belongs to your practice. The duty to your patients is yours. A vendor cannot absorb that liability by describing itself as compliant, and you should be sceptical of one that implies it can.

What a vendor can do is stay inside its role: use the information only to provide the service, disclose it to nobody, not sell or rent it, not train AI models on it, and keep it under stated safeguards. Those are commitments you can read and hold someone to. "Compliant" is not.

What do my records actually have to be able to do?

Four capabilities carry most of the weight in a small practice. Not an exhaustive reading of the Act — the obligations that turn into daily software behaviour:

• Account for access. You should be able to answer "who looked at this patient's chart, and when". Preventing improper access matters; being able to demonstrate what access occurred matters just as much, and is the part software either does or does not do for you.
• Give a patient their record. A right-of-access request has to produce a readable copy of the complete chart within a defined time. If it takes an email to a support desk, you have a process problem wearing a software costume.
• Transfer care. A patient moving practices takes their chart with them, in a form the receiving system can ingest — radiographs and scanned documents included. A transfer without the images is not a transfer.
• Retain the record, and keep it trustworthy. College retention periods run for years after the last entry, longer for minors. And a record that can be silently revised or backdated is not evidence of anything, which is why clinical notes should lock and corrections should append.

What has to be in an audit trail?

Enough that "who accessed this record" is a question with an answer, not an investigation. Concretely: logins and failed logins; every chart view, not just every edit; every creation, amendment and deletion; and — the one most systems miss — every export, flagged separately. A record that leaves as a download otherwise leaves no trace at all, and exports are precisely the events you will later need to evidence.

Each entry wants the staff member, the record affected, a timestamp and the originating address. When you evaluate software, do not ask whether it has audit logging — everything says yes. Ask someone to open a demo chart while you watch, then show you the entry that just appeared.

Why can I not just delete a chart?

Because your retention obligation usually outlives the request to remove it — and because a chart that can be erased on impulse is not a legal record. This is the point where the instinctive answer, that a patient should be able to have their data deleted, runs into a different rule.

"Send me my record and delete it" is two requests. The first can be honoured on the spot. The second usually cannot, because a College retention period is running and it binds the practice regardless of what the patient prefers. Where a genuine erasure obligation does arise, it should be a deliberate, audited, administrator-level operation with its legal basis written down — never a button on the chart.

What about reminders and recall messages?

Consent has to be true at the moment the message goes out, not when it was queued. This sounds like a small distinction and is the one that produces complaints: a patient who withdraws consent on Monday, messaged Tuesday morning by something scheduled the week before, has a legitimate grievance and your practice answers for it.

The behaviours worth checking: messaging off by default rather than on; consent verified at send time; a patient's STOP honoured immediately and reversible only by that patient; quiet hours enforced in the practice's local time zone; and every message retained on the chart, so you can evidence what a patient was told.

How do I test a vendor on this?

Ask for four things live, on a demo chart, without warning: show me the audit entry for the view you just did; produce a patient PDF of the whole record; produce a structured export with the radiographs in it; and state your retention position in writing. Each takes minutes if the software does it, and produces a follow-up email if it does not.

We will do all four on a call. What DentureFlowPro does on each is set out in detail on our privacy and PHIPA page — written that way because a prospective practice's privacy officer will check it.