Corrections

Introduction

Under PHIPA an individual who has been given access to their record may ask a custodian to correct information in it. The custodian may accept, partly accept, or refuse — and the obligations differ in each case.

The prior access is part of the right rather than a formality: the individual is disputing information they have seen, and the access request that showed it to them is an ordinary clinical Task recorded exactly the way this one is.

The requirement has five parts: strike out incorrect information in a way that does not obliterate the record, label information as incorrect, sever it, store it separately with a traceable link, and notify users where information is incorrect so they are directed to the corrected version.

Nothing in this estate yet performs any of them beyond retaining prior versions. See What is not implemented at the foot of this page.

A correction is an ordinary clinical Task, with one narrowing

A correction request is a clinical Task like any other, and it appears in the same worklist, in the same bin, sorted the same way. Since 1.26.0 it also has a profile of its own, correction task, which narrows one element and changes nothing else.

A profile costs nothing in reachability. A worklist searches Task?owner=…, and every Task comes back whatever meta.profile says; nothing in this estate filters a task query by profile. Earlier releases said this guide would publish no correction Task profile because a second Task shape would put statutory work somewhere nobody looks. That reasoning did not hold: the reachability it was protecting is not affected by a profile.

What the profile buys is a vocabulary a code cannot close. The correction lifecycle is the statutory record of a decision about someone's chart, and it needs a set of business statuses that is closed and is not available to ordinary work. The base profile's binding admits both vocabularies, because a FHIR binding cannot be conditional on a sibling element; the correction profile narrows it to the correction half. Ordinary tasks are held off the correction codes from the other direction, by the nexus-task-bizstatus-scope invariant on the base.

A writer must declare it. meta.profile carries no weight unless it is written, and nothing in this estate stamps a profile onto a Task today. Until a producer does, an instance is held to the base profile alone — which still blocks a correction code on a non-privacy task, but does not hold a privacy task to the correction vocabulary.

Element	Carries
Task.code	privacy-request — the worklist bin. Optionally a second coding, medRecCxReq, from the correction task types
Task.restriction.period	The response clock. Its end is the statutory deadline
Task.businessStatus	Where the request has reached — correction business status
Task.status	The lifecycle. completed on a refusal
Task.for	The individual
Task.focus	The disputed record
Task.requester	The staff member who logged the request
Task.statusReason	Why, on a refusal

A refused request is a completed task carrying a businessStatus of denied, never a failed one. Somebody reviewed it and decided. A failed task says the system broke, which loses the only fact the law cares about.

The terminal states, stated once as a progression. A refusal ends at businessStatus = denied. If the individual then files a statement of disagreement it moves to disagreement-logged. Only a formal rebuttal from the custodian reaches completed. So completed is the rarest of the three, not the ordinary end state, and a request that was simply accepted and amended never passes through any of them — it ends at amendment-completed.

Note that completed occurs twice in this model with different meanings: as a Task.status (the work item is closed) and as a businessStatus (a rebuttal was provided). They are different elements and they are not synchronised.

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. That separation is honest about who is accountable for the work.

The response clock has a home: restriction.period

The statutory deadline 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." There is no privacy-specific deadline element and none is needed, which also means the deadline is visible to any worklist that already sorts on a due date.

Do not write it on Task.executionPeriod, which means when the work is being or was done. The fuller treatment, including what does and does not watch this element, is on access requests.

Which duration applies is a separate question from where the date goes, and it is answered below for records held elsewhere.

Why the vocabulary is adopted but the profiles are not

HL7 published Patient Request for Corrections 1.0.0 (STU1, R4, July 2025): a Task/Communication workflow with a $correction-request operation and a business-status vocabulary.

This guide adopts its codes and not its profiles, for the worklist reason above. Adopting a vocabulary keeps the workflow legible to an outside reader; adopting the profiles would import an operation, a search-parameter set, and a second Task shape competing with the one this estate already routes work through. The package is deliberately not a dependency, so terminology-aware validators will report that these codes cannot be verified against their system. That is expected.

Three details of that vocabulary carry traps:

• completed does not mean "finished". HL7 defines it as the state where the disagreement has been logged and a formal rebuttal provided — see the progression above.
• disagreement-logged closes an administrative step only. The statement it refers to must still travel with the disputed information for as long as the record exists.
• partial-accept ships with a typo in its published display ("Partail Acceptance"). It is carried as HL7 publishes it, so that a validator does not flag a mismatch. Render your own text.

Two codes appearing in HL7's narrative — inform-rebuttal-option and partial-amendment-completed — are absent from the published code system and are not carried.

Applying the correction to the record

The workflow is one thing; changing the clinical record is another, and R4 already has per-resource mechanisms for most of it:

Resource	Correction	Invalidation
Observation	status = corrected	status = entered-in-error
Condition, AllergyIntolerance	Amend in place with provenance	verificationStatus = entered-in-error
DocumentReference	docStatus for the document; relatesTo replaces for a new version	status = entered-in-error, with a status reason
Composition	Amendment status plus a replacement policy	—
Patient demographics	Versioned field change with provenance	No generic error status exists

A clinical correction and invalidating an erroneous entry are different acts. Do not use resolved or inactive to pretend an erroneous diagnosis or allergy clinically ended — it did not; it was never true.

Version history retains what the record used to say. Provenance records who changed it and why.

The two gaps R4 leaves, and how this guide fills them

There is no portable pointer from a wrong record to its replacement. DocumentReference has relatesTo; Observation, Condition, AllergyIntolerance and Patient have nothing equivalent in R4. So a reader holding the wrong record cannot reach the right one — and the requirement is explicitly to direct users to corrected information, which needs an address.

The Corrected By extension carries it. It points forward, from wrong to right, which is the opposite of relatesTo. The direction is chosen for the reader who needs help: they are holding the stale record and need somewhere to go.

Severing has no representation at all. Severed content stays retrievable — a correction has to be auditable — while ceasing to be presented as part of the clinical picture. That is an instruction about visibility, and no status code expresses it: status is about whether content is true.

The Record Severed extension carries the date, the reason, and the basis on which the content is still retained. That last sub-extension exists because a severed record raises the obvious question of why it is still here, and the answer belongs on the record rather than in somebody's memory — it is also what tells a later retention sweep whether the content may now go.

Records held by another custodian

A correction request about information that came from somewhere else is routed to the custodian responsible for it. A local user cannot rewrite another custodian's authoritative record, and a user interface that implies otherwise is making a promise the estate cannot keep.

Capture receipt, decision, any extension of the response period and its justification, and the notification dates. The deadline itself goes where every other deadline goes, on restriction.period.end; what has to be established with the holding custodian is which duration applies — theirs may not be ours, an extension may move it, and inheriting a period from an international example is how a request is answered late while looking on time.

Regulatory reporting comes out of the same query

A custodian reports counts: requests received in a period, requests refused, and the provisions invoked. That is not a new artifact. It is a query over the request Tasks, grouped by Task.businessStatus, where refusals are the denied bucket and the provision relied on is on Task.statusReason. Task.code = privacy-request selects privacy work and Task.authoredOn bounds the period.

Because the buckets are HL7's published vocabulary rather than a private status column, the report is portable: a denied count means the same thing in any store carrying that vocabulary, and nobody needs a mapping table from this estate's local names to produce or read it. That is a second reason not to extend the vocabulary locally. The same query covers access requests; see access requests.

What is not implemented

• Nothing labels a record as incorrect in ordinary clinical views, so nexus-corrected-by is written by nothing and read by nothing.
• No severing workflow exists; no protected retention location exists.
• No user is notified when information they have seen is later corrected.
• Nothing tracks who a record was previously disclosed to, so prior recipients cannot be notified.
• No $correction-request operation and no correction search parameters are exposed.
• Nothing watches restriction.period, so a statutory deadline recorded on a request is a date and not a reminder: no escalation, no extension record, no overdue view.
• No reporting query is built or exposed. The grouping above describes what the model supports, not something the estate produces.