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.

Access

What the endpoint offers

Declared for Task by the capability statements this IG publishes. One row per statement; follow it for the rest of what that statement says about this type.

Capability statement	Interactions	Search parameters
Server Capability Statement	read vread history-instance search-type create update delete	_id _lastUpdated authored-on based-on business-status code focus identifier intent location owner patient priority requester restriction-period-end status

A cell reading none declared means that statement declares none, which is not the same as the endpoint having none. See how to read a capability statement for what a declared interaction and a declared search parameter do -- and do not -- promise.

SMART on FHIR scopes

Task is reachable by a SMART on FHIR app. These are the scopes an app can request, and the platform permission each one resolves to.

Request this scope	Grants	Permission required
user/Task.rs	Read and search	task:read
user/Task.cu	Create and update	task:write
user/Task.d	Delete	task:delete
user/Task.cruds	Everything above	task:read, task:write, task:delete

Task is not in the FHIR patient compartment, so only the user context applies. A patient/Task.rs scope has nothing to narrow to and is not grantable.

Reading the suffix

A clinical scope is <context>/<ResourceType>.<interactions>.

• Context is patient (the launch patient's data only, and only for resource types in the FHIR patient compartment) or user (everything the authenticated user may see, valid for any type). There is no system context.
• Interactions are the letters c create, r read, u update, d delete, s search, written in cruds order. Order does not matter on the way in: Task.sr and Task.rs are the same scope.
• The older SMART v1 suffixes still work and fold on arrival: .read becomes .rs, .write becomes .cud, and .* becomes .cruds.
• Wildcards (patient/*.rs) expand over the SMART-exposed resource types only, never over everything this IG profiles.

Ask for a whole permission, or none of it

The platform has one read permission covering both r and s, and one write permission covering both c and u. A scope asking for half of either could only be granted by handing over more than it asked for, so it is refused rather than quietly widened: request Task.rs, not Task.r.

An unrecognised or ungrantable scope is rejected outright. It never silently resolves to an empty grant, which a caller could mistake for "no narrowing needed".