Correction Task Profile

Canonical	../StructureDefinition/nexus-correction-task
Status	draft · 1.26.0
Base	Task Profile (constraint)
Source	FSH · JSON

A patient's request to correct their own record, or to log a disagreement where a correction was refused, carried as an ordinary clinical task with the statutory correction vocabulary. Same worklist, same shape, narrower status set. AN ACCESS REQUEST IS NOT HELD TO THIS PROFILE. Every code in this vocabulary describes a correction or a disagreement, so a request to be given a copy of the record has no terminal state here it could truthfully reach. It shares the privacy-request worklist bin and stays on the base clinical task, which binds the wider set.

Overview

A patient asks for something in their own record to be changed. Somebody reads the request, decides, and the decision is recorded. If the answer is no, the patient may file a statement of disagreement, and that refusal is what entitles them to.

This profile is that request. It is an ordinary clinical task — same worklist, same inbox, same sorting — narrowed in two places: it is always filed under privacy-request, and its businessStatus draws on the statutory correction lifecycle rather than the general one.

The vocabulary is HL7's, not ours

businessStatus binds to the ten-code lifecycle from HL7's Patient Request for Corrections guide: queued, in-review, waiting-for-information, requester-cancelled, accepted, partial-accept, amendment-completed, denied, disagreement-logged, completed.

Nothing about that is local. A correction request means the same thing in Ontario as anywhere else, the international guide had already modelled it on Task.businessStatus, and a reader outside this estate should not need our value set to understand an outcome. Where this guide differs from HL7 is only in deriving from its own clinical task, so these land in the same worklist as everything else.

A refusal is a completed task, not a failed one

status = completed with businessStatus = denied. Not failed.

The distinction carries the whole point. failed says the system broke — the request was lost, the job errored, nobody got to it. completed + denied says a person read the request and decided against it, which is the only fact the statute cares about and the only one that starts the disagreement clock. A refusal recorded as a failure loses the decision and the decider.

The Statement of Disagreement that may follow points back here on its partOf — at the task that reached denied. That is the audit trail: who decided, when, and on what stated reason.

Why this is a profile at all

Until 1.26.0 there was no correction task profile, deliberately, and the reason recorded was that privacy work had to land in the same worklist as everything else and that worklist read the clinical task profile.

That reason does not hold. A worklist searches Task?owner=…; every task comes back whatever meta.profile says, and nothing in this estate filters a task query by profile. A second profile costs nothing in reachability.

What it buys is a vocabulary that ordinary work cannot reach. The correction lifecycle records decisions about someone's chart under a statutory clock; pre-review and awaiting-triage do not. Both used to be equally valid on any task, because the binding was extensible and invited exactly that. Since 1.26.0 the base profile binds businessStatus required to the union of the two vocabularies, and an invariant keeps the correction half off ordinary tasks. This profile closes the other direction: a task that declares it is held to the correction half alone.

A writer has to declare the profile

meta.profile does nothing unless it is written, and today nothing in this estate stamps a profile onto a Task. Until the privacy path does, an instance is held to the base profile — which still refuses a correction code on a non-privacy task, but does not hold a privacy task to the correction vocabulary. Declaring the profile is what closes that second half.

What is not constrained here

The statutory response deadline lives on restriction.period.end, as it does for any privacy-request task, and this profile does not make it mandatory. It probably should be — a deadline nobody wrote down cannot be reported on, and the inbox's overdue sorting is the only thing that surfaces an approaching one. It is left alone because requiring it would invalidate stored privacy tasks that predate the rule, and that deserves a migration rather than arriving as a side effect of closing a binding.

Which of the two a given task is — a correction or a disagreement — is not constrained either. It comes from the optional second code coding, drawn from the international correction task-type system. That coding is optional because a task written before the vocabulary existed carries none, so read its absence as weak.

An access request is not one of these

privacy-request is named for the right, not the outcome, so one worklist bin covers access, correction and disagreement: the same role handles all three and all three run on statutory clocks. This profile is narrower than the bin. It covers corrections and disagreements only.

The reason is the vocabulary. Every code in the correction lifecycle describes a record being amended or a disagreement being logged, and an access request does neither — it releases a copy. The intake states carry over (queued, in-review, waiting-for-information, requester-cancelled) and so does denied, which is what makes refusal reporting work across all privacy requests. But nothing in the set says the packet was released, or released in part. businessStatus is 1..1 here and bound to that set alone, so an access request held to this profile would have to close on a code that misstates what happened.

Do not reach for completed to close one. HL7 defines completed as the state where a disagreement has been logged and a formal rebuttal provided — not "the work is over" — so it would record a correction fact about a request that corrected nothing, and break the property that makes refusal counts portable.

So an access request stays on the base clinical task, in the same bin, binding the wider business-status set. Access requests is the page that describes it, including the part that is still missing: an access vocabulary this guide has deliberately not invented, because the states it would name have nothing yet to produce them.

Terminology bindings

Path	Strength	Value set
Task.businessStatus	required	Correction Business Status Value Set