Access Requests

Introduction

Under PHIPA an individual has a right of access to their own record. The custodian must respond within a statutory period, may grant access in whole or in part, and where it refuses must say so in writing with the reason and the provision relied on.

Access is also the gate on the rest of this section. The right to ask for a correction belongs to an individual who has been given access to the information, so an access request is the step the corrections workflow assumes has already happened.

Nothing about access requests is implemented. This page states where the request is recorded and which element carries each part of it, so that a request logged today is readable when enforcement is built. No packet is assembled, no clock is watched, and no refusal is reportable. See What is not implemented at the foot of this page.

An access request is an ordinary clinical Task

There is no access-request Task profile. An access request is a clinical Task and nothing about it needs narrowing: unlike a correction, it carries no statutory decision vocabulary of its own, so there is no binding for a profile to close. (A correction does, which is why correction task exists as of 1.26.0. The difference is the vocabulary, not the worklist — both land in the same one.)

The bin is privacy-request in Task code, and it already covers access by its own definition: the code is named for the right being exercised, not the outcome, and one bin carries access, correction and disagreement because the same privacy role handles all three and all three carry statutory response clocks.

Element	Carries
Task.code	privacy-request — the worklist bin
Task.restriction.period	The response clock. Its end is the statutory deadline
Task.for	The individual
Task.focus	The records the request is about
Task.requester	The staff member who logged the request
Task.status	The lifecycle. completed on a refusal, as for a correction
Task.statusReason	Why, on a refusal, including the provision relied on

As with a correction, the individual cannot be Task.requester — that element is constrained to a practitioner. The request itself is a Communication from the individual; the Task is the clinic's work item raised from it.

Nothing in Task.code distinguishes an access request from a correction request. The optional second coding from correction task types names a correction or a disagreement and is simply absent on an access request, which makes absence the only available signal — and absence is also what a task written before that vocabulary existed looks like. Read it as weak, and do not build a worklist filter that treats "no second coding" as "access request".

The response clock is Task.restriction.period

A privacy request has a deadline set by law, and it is carried as an ordinary task due date: restriction.period.end, the end of the fulfillment window, whose base definition is "the time by which the task should be completed." No privacy-specific element exists, and none is needed.

Do not reach for executionPeriod

Task.executionPeriod sits beside it and is also a period, but it means when the work is being or was done. A deadline written there produces a task claiming to have been worked on a date in the future. The same trap is described with the rest of the triage elements on One Task Model.

Which duration applies is a separate question from where the date goes. The statutory period, when it starts, what extends it and what notice an extension requires are matters of the governing legislation and the custodian's own undertakings — and a request about records held by another custodian may run on that custodian's clock. Establish the duration with the custodian rather than inheriting one from an international example, then write the resulting date here.

Nothing watches this element. A deadline recorded on a task that no service reads is a date, not a reminder.

Deciding the request, and the status vocabulary that does not exist

The decision is carried on Task.businessStatus, and this is the honest gap on this page.

The vocabulary this guide adopted is HL7's correction business status, and it is correction-specific. Its intake states carry over cleanly — queued, in-review, waiting-for-information, requester-cancelled describe any privacy request — and so does denied, which is what makes refusal reporting work. Its terminal states do not: accepted, partial-accept and amendment-completed describe a record being changed, and an access request does not change a record. Nothing in the vocabulary says the packet was released, or released in part.

So an access decision has no status vocabulary yet, and the guide does not invent one. Using amendment-completed to mean "disclosed" would put a correction fact on an access request and break the one property that makes refusal counts portable.

What would settle it: an access vocabulary published by HL7 or by a Canadian guide, adopted the same way this one was; failing that, a minted code system, which is only worth minting once a release path exists to produce the states it would name. Until then, the states an access request can truthfully reach are the intake states and denied.

A refusal is a completed task carrying businessStatus = denied, never a failed one. Somebody reviewed the request and decided. A failed task says the system broke, which loses the only fact the law cares about. The provision relied on goes in Task.statusReason.

The released packet: provenance, completeness, and the watermark

A watermark is a property of a rendered output, not of a FHIR resource. Stamping a page with the recipient's name and the release date is something the export layer does to a PDF at the moment it renders one, and the same content released twice to two recipients carries two different watermarks. An extension asserting a watermark on a resource would be asserting a fact about every future rendering of it, which is not a fact the resource has.

What the model carries instead is what has to travel with a released packet:

• Who assembled it, from what, and when. Provenance on the released Bundle or document. This is authorship, not disclosure: the record that the packet left is an AuditEvent disclosure entry, and it is the only thing from which prior recipients can later be found.
• Whether it is complete. Where the individual's own directive, or a lawful refusal of part of the request, has removed something, the packet carries REDACTED on meta.security — on the packet being released, never on the source record, which is not itself incomplete. The marker deliberately does not say what was removed. See security labels.

The watermark belongs to the export layer, and so does every other rendering concern: pagination, a cover letter, a footer naming the recipient. The FHIR side carries the provenance and the completeness marker, and it carries them because a recipient needs them to read the packet correctly.

Regulatory reporting is a query, not an artifact

A custodian reports counts: requests received in a period, requests refused, and the provisions invoked. None of that needs a new resource, a counter or a parallel table. It is a query over the request Tasks:

• the bin, Task.code = privacy-request, selects privacy work;
• Task.authoredOn bounds the reporting period;
• Task.businessStatus groups the outcomes, and refusals are the denied bucket;
• Task.statusReason on those tasks names the provision invoked.

R4 defines business-status as a search parameter on Task, so the grouping is expressible as a search rather than a scan over the worklist.

The report is portable because the vocabulary is HL7's rather than a private column. A count of denied tasks means the same thing in any store that carries the published vocabulary, so a figure produced here is comparable with one produced elsewhere, and a consumer building the report does not need a mapping table from this estate's status names. A local status enum would make every number a local artifact — which is the reason the vocabulary was adopted rather than minted, and the reason it should not be extended locally for the access states named above.

The same query answers the correction side of the report; see corrections.

What is not implemented

• Nothing implements an access request end to end. No intake surface logs one, no worklist view filters the privacy-request bin to access requests, and no service assembles a responsive packet.
• Nothing watches restriction.period. No deadline is escalated, no extension is recorded, and no overdue request is surfaced.
• No access status vocabulary exists, so a released or partly released request cannot state that outcome in businessStatus.
• No release path applies REDACTED, because nothing yet suppresses a record on the strength of a directive and so nothing yet has an occasion to.
• No export layer applies a watermark, and no Provenance is written for a released packet.
• No reporting query is exposed, and no search parameters for privacy requests are declared in the CapabilityStatement.
• Nothing records that access was granted, so a later correction request cannot be checked against the prior access it depends on.