Statement of Disagreement Profile

Canonical	../StructureDefinition/nexus-statement-of-disagreement
Status	draft (experimental) · 1.26.0
Base	Communication Profile (constraint)
Source	FSH · JSON

The individual's own statement about information they asked to have corrected and the custodian refused to correct.

Overview

Where PHIPA gives a right to require that a statement of disagreement be attached to the record, this is the resource that holds it. The statement is the individual's words, disclosed as written.

The obligation outlives the workflow. Once attached, the statement must accompany the disputed information every time that information is disclosed -- through the API, in a printed chart, in a referral packet, in a generated summary -- for as long as the record exists. Closing the correction Task does not end this. Nothing in FHIR enforces it: a release path must read the statement's associations and assemble accordingly, and one that cannot carry the statement must refuse the disclosure rather than send the disputed information alone.

⚠ FIRST PASS. No release path in this estate currently consults these associations.

Handbook: Statements of Disagreement

Statement of Disagreement Profile

Overview

When an individual asks for information in their record to be corrected and the custodian refuses, Ontario law gives them a right to have a statement of disagreement attached to the record. This profile holds that statement.

It derives from the Communication profile. It is #draft and experimental = true.

THE effective date is sent.

Worked example

• A statement about a refused correction, and the correction task that was refused

The obligation outlives the workflow

Every other message in this estate is finished once it has been delivered. This one is not.

The requirement has two halves, and the second is the one implementations miss. The custodian must attach the statement to the record, and must ensure it is included wherever that information is shared. Separately, the custodian must notify people the information was already disclosed to.

So a statement of disagreement must accompany the disputed information every time that information is disclosed — through the API, in a printed chart, in a referral packet, in a generated summary — for as long as the record exists.

Nothing in FHIR enforces that. The profile does the part a resource can do: make the association durable, unambiguous and findable. A release path has to read those associations and assemble accordingly, and a channel that cannot carry the statement must refuse the disclosure rather than send the disputed information alone.

Closing the correction task does not end this. The task reaches disagreement-logged and later completed; both describe the clinic's workflow. An implementation that stops carrying the statement once its task closed has broken the requirement at precisely the moment it looked finished.

Two references on about, and you need both

about names the records this statement attaches to. Carry the disputed content twice:

Reference	Why
Version-pinned (Observation/x/_history/3)	Pins the exact content the individual disputed. This is what an auditor needs.
Unversioned (Observation/x)	What a current-state export actually looks at.

A version-pinned reference alone will not cause today's chart export to include the statement, because a consumer assembling the current record never looks at that version. A statement associated only with a superseded version stops being disclosed the moment the record is edited for any unrelated reason — and nothing reports that it has.

about is deliberately not sliced. Separating the disputed record from the workflow task by reference target type needs a discriminator that resolves the reference, which this guide's evaluable-slicing convention avoids: an unevaluable slice renders on the published page and then checks nothing. The correction task is carried on partOf instead, so the two associations sit on different elements and no discriminator is needed.

This reverses HL7's Patient Request for Corrections guide, which carries the task association in an about slice and uses partOf for message threading. A consumer converting between the two must move the reference rather than copy it.

The words are the payload

payload is required, and it carries the individual's statement as written.

Not summarised, not paraphrased, not edited into a chart note. A clinic that condenses a statement into its own prose has substituted the custodian's account for the one the individual is entitled to have carried — which is the failure the right exists to prevent.

contentString for a statement given in writing or transcribed verbatim; contentAttachment or a contentReference to a DocumentReference for a signed letter the individual supplied.

Who may author one

sender is narrowed to Patient or RelatedPerson — the individual, or their substitute decision-maker. Nobody else. A statement authored by the clinic is the custodian's account wearing the patient's name.

A substitute decision-maker is a RelatedPerson, never the Patient. This is why the parent Communication profile's sender and recipient were widened to admit RelatedPerson in this release: recording an SDM's statement as though the patient made it loses the fact that authority was delegated, which is what gets checked when the statement is challenged.

Withdrawal

entered-in-error is the only route to withdrawing a statement, and it is for statements recorded in error — not for statements the custodian would rather not carry.

An individual who wishes to change their statement supplies a new one. The original stays in version history. A custodian deleting an individual's account of a dispute is the shape of the problem the right exists to prevent, so the model does not offer a clean way to do it.

The correction workflow around it

A correction request is a clinical Task, in the same worklist and the same bin as every other piece of clinic work. Since 1.26.0 it also has a profile, correction task, which narrows businessStatus to the correction vocabulary and leaves everything else as the base profile has it. It is what this statement's partOf points at.

Element	Carries
Task.code	privacy-request (the worklist bin), plus optionally HL7's medRecCxReq for an outside reader
Task.businessStatus	Where the request got to — correction business status
Task.status	completed on a refusal. Not failed — somebody reviewed it and decided
Task.focus	The disputed record
Task.statusReason	Why it was refused

A refused request is a completed task carrying a businessStatus of denied. Reading a refusal as a failure loses the decision, and the decision is the part the law cares about.

The progression from there: denied, then disagreement-logged once the individual files a statement, and completed only where the custodian provides a formal rebuttal.

What is NOT implemented

• No release path consults about when assembling a disclosure.
• Nothing tracks who the disputed information was previously disclosed to, so the obligation to notify prior recipients cannot yet be discharged from the record. That trail is an AuditEvent question and the disclosure entries it needs are a first pass.
• No channel refuses a disclosure it cannot carry the statement through.