Who is legally responsible for health data in New Brunswick?

The word is 'custodian', it is defined in statute, and a software vendor is almost never one. Knowing which side of that line you sit on determines your entire obligation set.

Start with the right statute

The most common mistake in Canadian health software is answering the privacy question with "we're PIPEDA compliant". PIPEDA is real and important - it is the federal private-sector regime, built on a set of fair information principles covering accountability, identifying purposes, consent, limiting collection, limiting use, disclosure and retention, accuracy, safeguards, openness, individual access and challenging compliance [2], and enacted as S.C. 2000, c. 5 [3].

But health care delivery and the regulation of health care providers are provincial and territorial responsibilities [4], and the provinces have written their own health information statutes. In New Brunswick that statute is the Personal Health Information Privacy and Access Act, assented to June 19, 2009 [1]. If you are handling personal health information for a New Brunswick custodian, that is the law that describes your obligations, and the federal private-sector framing will not map cleanly onto it.

The Office of the Privacy Commissioner even publishes an interactive tool to work out which privacy law applies [2], which is a fair indication that "which law applies" is not a trivial question in this country.

The two definitions that decide everything

PHIA's architecture rests on two defined terms, and almost every downstream obligation follows from which one you are.

A custodian is defined as an individual or organization that collects, maintains or uses personal health information for the purpose of providing or assisting in the provision of health care or treatment or the planning and management of the health care system or delivering a government program or service [1]. The Act then enumerates: public bodies; health care providers who are not agents or employees of a custodian; the Minister; and a specified list of organizations including EM/ANB Inc., the New Brunswick Health and Senior Care Council, regional health authorities, the Workplace Health, Safety and Compensation Commission and Canadian Blood Services; along with research data centres, approved researchers, laboratories and specimen collection centres, and nursing homes and their operators [1].

An agent, in relation to a custodian, means an information manager or an individual or organization that acts for or on behalf of the custodian in respect of personal health information for the purposes of the custodian and not for the agent's own purposes, whether or not that party is remunerated by the custodian - and it expressly does not include an employee of the custodian [1].

Read that agent definition slowly, because it contains the trap. Two clauses matter disproportionately. First, whether or not remunerated: you do not escape the category by working for free or in a pilot. Second, not for the agent's own purposes: the entire distinction turns on whose purposes the data serves.

Why "our own purposes" is the line that catches vendors

A vendor processing data strictly to deliver the service the custodian asked for sits comfortably in the agent category. The trouble starts with the things software companies do almost reflexively.

Aggregating data to improve a model. Producing benchmark analytics to sell back to the market. Retaining records after a contract ends because storage is cheap and it might be useful. Each of these is a use for the agent's purposes, and each moves the organization away from the position it believes it occupies.

This is worth deciding deliberately and early, because it is very difficult to retrofit. A product architecture that assumes it may pool data across custodians is a different product from one that does not, and the difference reaches into the schema.

The residency question is a legal one

Engineers usually treat hosting location as a cost, latency and availability decision. In Canadian health data it is a statutory one.

PHIA's regulation-making provisions include an explicit power respecting the personal health information in the custody or under the control of a custodian that may be stored outside Canada [1]. That the legislature wrote a specific regulation-making power for this tells you the province regarded storage location as something it might need to control.

The practical consequence is that "our cloud provider has a Canadian region" is the beginning of the analysis and not the end of it. Backups, disaster recovery replicas, log aggregation, error tracking, analytics pipelines and support tooling all hold or transit personal health information, and each is a separate location decision. Systems tend to be well designed for the primary data store and thoughtless about the seven other places the data ends up.

Access is half the statute

PHIA is a privacy and access act, and the access half is routinely under-built. Section 2 sets out purposes including providing individuals with a right to examine and receive a copy of their personal health information maintained by a custodian, subject to limited and specific exceptions; a right to request correction or amendment; a set of rules for collection, use, disclosure, retention and secure destruction; accountability mechanisms for persons having custody or control; safeguards for the security and integrity of that information; and independent review and resolution of complaints [1].

Two of those create engineering work that teams frequently postpone. Correction and amendment means records cannot be write-once-and-immutable in the naive sense - there has to be a defined way to amend while preserving the history of what was previously recorded. Secure destruction means retention has to be modelled and enforced, which is the opposite of the default engineering instinct to keep everything forever.

Where the standards help

FHIR provides structures that map onto these obligations rather than fighting them. Its Security and Privacy module covers Security, Consent, Provenance and AuditEvent as first-class concerns of the specification [5].

Provenance and AuditEvent in particular are the technical shape of the accountability purposes PHIA describes [1]. Consent is the shape of the rules around collection, use and disclosure. Building these as core resources rather than as an audit table bolted on at the end is what makes an access request or a complaint review answerable without an archaeology project.

There is a subtlety in the agent definition that is easy to miss and useful to hold onto: an agent expressly does not include an employee of the custodian [1]. That means the Act draws its line around organizational relationships, not around individual people with access. A contractor and an employee touching the same record sit in different statutory categories, which is why access control lists alone never demonstrate compliance - the question is not only who can see the data but under what relationship they see it, and that relationship has to be documented somewhere other than the permissions table.

The practical checklist

Four questions, in order, before any Canadian health software design is settled. Which custodian does this product serve, and under which province's statute? Are we an agent, and have we written down every use of the data so we can confirm none of them are for our own purposes? Where does every copy of the data live, including the non-obvious ones? And can we answer an individual's access, correction and destruction request without engineering heroics?

MapleTriage is being built in Moncton, New Brunswick with those four questions answered before the schema was settled, on the view that a compliance posture retrofitted is a compliance posture you do not have. It is in development and not generally available. Nothing here is legal advice - the statute and its regulations are the authority, and a custodian's own counsel is the right reader of them.

By Joel Gathercole · Published 2026-08-09