Audit Logging in Healthcare Apps: What PHIPA Requires

As of September 9, 2025.

The Personal Health Information Protection Act (PHIPA) is Ontario's primary law governing how health information custodians collect, use, and disclose personal health information (PHI). When your app touches an electronic health record (EHR), PHIPA does not just regulate what you store — it requires you to keep a detailed, tamper-evident log of every access. Getting audit logging right protects your patients, satisfies the Information and Privacy Commissioner (IPC), and keeps your organization out of enforcement proceedings.

This article covers what PHIPA's audit log requirements are, how they compare to the Personal Information Protection and Electronic Documents Act (PIPEDA) and the American Health Insurance Portability and Accountability Act (HIPAA), and what a compliant implementation looks like for a Canadian healthtech product. For the broader data protection picture, see our guide on PHIPA, PIPEDA, and skin health data.

What does PHIPA require for audit logs?

Short answer: PHIPA requires Ontario health information custodians who operate electronic health records to log every instance where PHI is viewed, modified, or disclosed. Under section 55.3(4)(i), Ontario Health and custodians using provincial EHR systems must record who accessed which records, at what time, and what action was taken. The IPC can demand a copy of these logs at any time, and custodians must be able to produce them on request from a patient whose record was accessed.

The 2020 amendments introduced by Bill 188 (the Connecting People to Home and Community Care Act) made the audit log obligation explicit in the statute. Before that, the duty was inferred from the general obligation to have administrative safeguards. The amendment removed ambiguity: if you run an electronic health record system in Ontario, a functioning audit log is not optional.

The IPC's guidance document Digital Health under PHIPA sets out the expectation that logs capture at minimum: the identity of the user who accessed the record, the date and time of access, the specific record or data element accessed, and the type of action (view, edit, delete, export, print). Organizations that use DermaDex for artificial intelligence (AI)-assisted dermatology assessments should ensure their integration with any connected EHR satisfies these four fields for every transaction.

What fields must a PHIPA-compliant audit log capture?

Short answer: At minimum, a compliant audit log must record the user identity, timestamp, the specific PHI record touched, and the action performed. Ontario's IPC guidance and PHIPA section 55.3 together require these four data points. Most mature implementations also capture the patient's identifier, the workstation or IP address, and the application module initiating the transaction, which helps with breach investigation.

The table below maps required fields across PHIPA, PIPEDA, and HIPAA so Canadian teams building cross-border or federated systems know where the obligations converge and where they differ.

Field	PHIPA (Ontario)	PIPEDA (Federal)	HIPAA (US)
User / accessor identity	Required (s. 55.3)	Recommended (Principle 7)	Required (§ 164.312(b))
Timestamp (date + time)	Required	Recommended	Required
Record / data element accessed	Required	Recommended	Required
Action type (view / edit / delete)	Required	Recommended	Required
Patient / subject identifier	Strongly implied	Not specified	Required
Workstation or IP address	Recommended by IPC	Not specified	Addressable
Reason / purpose of access	Required for disclosures	Not specified	Addressable
Export or print events	Required	Not specified	Addressable

PIPEDA does not prescribe audit log fields with the same precision as PHIPA or HIPAA, but organizations subject to both laws — for example, a Canadian telehealth platform that also serves patients in the US — must satisfy the stricter standard on each field. If you store or transmit patient images, our article on encrypting patient images at rest and in transit covers the complementary technical controls PHIPA expects alongside audit logging.

How long must healthcare organizations retain audit logs?

Short answer: Ontario health regulations require health records to be retained for at least ten years from the date of the last entry, or until the patient turns 18, whichever is longer. Audit logs are part of the health record under PHIPA and inherit that retention schedule. In practice, most Ontario health information custodians apply a seven-to-ten year retention window for audit log data specifically, consistent with guidance from the Ontario Ministry of Health.

Log retention is a common gap in healthcare app compliance programs. Development teams often set database purge jobs that trim logs after 90 days for storage cost reasons, not realizing that audit trail data is subject to the same retention rules as the clinical record itself. A short-retention audit log does not just create a regulatory risk — it also eliminates your organization's ability to investigate a privacy breach that surfaces years after the fact.

For cloud-hosted systems, immutable log storage services (append-only buckets, write-once object storage) satisfy both the retention and the tamper-evidence expectations in the IPC guidance. The IPC has noted in enforcement decisions that mutable logs — where records can be altered or deleted by administrators — do not meet the spirit of the audit log requirement even if the raw retention period is met.

What is an EHR audit trail?

Short answer: An EHR (electronic health record) audit trail is a time-stamped, sequential record of every interaction with a patient's digital health record. It captures who did what, when, and from where. The audit trail serves three purposes: detecting unauthorized access, supporting breach investigations, and giving patients a verifiable account of who has seen their information.

EHR audit trails differ from application logs in one critical way: they are patient-centric rather than system-centric. A system log might record that a database query ran at a given timestamp. An EHR audit trail maps that query to a specific patient record, a specific clinician credential, and a specific clinical purpose. Research published in JAMIA by Kannampallil et al. (2022) documents how EHR audit log data has become a significant research resource for understanding clinical workflows — precisely because of this patient-record linkage.

For healthcare apps built on top of an existing EHR (such as Oscar Electronic Medical Record (EMR) or TELUS PS Suite), the audit trail responsibility may be split: the EHR vendor logs access within their system, but your application must log the actions it takes via the EHR's API. Both layers are required.

What is an audit trail for electronic records?

Short answer: An audit trail for electronic records is a mechanism that automatically records every create, read, update, and delete operation applied to a record, along with the actor and time. In healthcare, this typically means a separate, append-only log table or log service that cannot be modified by the same user roles that access the clinical data.

From a software architecture standpoint, audit trails are most reliably implemented at the database or middleware layer rather than in application code. Application-layer logging can be bypassed by direct database access, batch jobs, or administrative tools. A trigger-based or change-data-capture approach at the data layer ensures that every write to a PHI table generates a corresponding audit entry regardless of which application component initiated the change.

For healthcare apps in Ontario, the IPC expects audit trails to be accessible to privacy officers without requiring the same administrative privileges used for clinical operations. Separating the audit log read path from the EHR admin path is both a security control and a governance requirement under PHIPA.

What should be included in an audit trail?

Short answer: A complete healthcare audit trail should include: user or system identity, timestamp (with timezone), the specific record or dataset affected, the action type, the patient identifier, the application module or API endpoint, the IP address or workstation identifier, and — for disclosures to third parties — the recipient and stated purpose. This set satisfies PHIPA, aligns with HIPAA addressable requirements, and gives privacy officers the information needed to answer a patient's access request.

Optional but valuable fields include the session ID (to link events in a single login session), the EHR version or schema version (useful when investigating historical access after a system upgrade), and a hash of the accessed record (to prove the record has not changed since it was accessed). These fields add storage overhead but significantly reduce the time to close a privacy breach investigation.

What are the four different types of audit trails?

Short answer: In healthcare IT, audit trails are commonly categorized as: (1) access audit trails, which log who viewed a record; (2) change audit trails, which log modifications including edits and deletions; (3) disclosure audit trails, which log when PHI was sent to an external party; and (4) system audit trails, which log administrative and configuration actions. PHIPA's audit log requirement primarily covers the first three; the fourth is a security best practice rather than a statutory requirement.

Each type serves a different compliance function. Access audit trails respond to patient requests ('who has seen my file?'). Change audit trails support clinical integrity investigations and malpractice defense. Disclosure audit trails document the chain of custody for PHI shared with insurers, researchers, or other custodians. System audit trails detect privilege escalation and unauthorized configuration changes.

Mature healthcare apps implement all four, with access and change trails stored in the same patient-centric audit table and disclosure trails recorded in a separate consent-and-disclosure register. The IPC's enforcement decisions suggest that access and disclosure trails are the most frequently requested during investigations.

Sources

• Ontario. Personal Health Information Protection Act, 2004, SO 2004, c 3, Sch A, s 55.3(4)(i). https://www.ontario.ca/laws/statute/04p03
• Information and Privacy Commissioner of Ontario. Digital Health under PHIPA: Selected Overview. https://www.ipc.on.ca
• Kannampallil T, et al. 'Using electronic health record audit log data for research.' J Am Med Inform Assoc, 2022. https://pubmed.ncbi.nlm.nih.gov/35390822/
• Government of Canada. Personal Information Protection and Electronic Documents Act (PIPEDA), SC 2000, c 5. https://laws-lois.justice.gc.ca/eng/acts/P-8.6/
• Office of the Privacy Commissioner of Canada. PIPEDA in Brief. https://www.priv.gc.ca/en/privacy-topics/privacy-laws-in-canada/the-personal-information-protection-and-electronic-documents-act-pipeda/pipeda_brief/
• US Department of Health and Human Services. HIPAA Administrative Simplification — Security Rule (45 CFR § 164.312). https://www.cdc.gov/phlp/php/resources/health-insurance-portability-and-accountability-act-of-1996-hipaa.html
• Meingast M, et al. 'Security and privacy issues with health care information technology.' Conf Proc IEEE Eng Med Biol Soc, 2006. https://pubmed.ncbi.nlm.nih.gov/17946847/
• Adler-Milstein J, et al. 'EHR audit logs: A new goldmine for health services research.' J Am Med Inform Assoc, 2020. https://pubmed.ncbi.nlm.nih.gov/32363392/