One turn in a task's conversation: who said it, when, and what they said. Both people and machine actors (harness graphs, decision-support rules) author turns. Because R4 does not permit Device as an Annotation.author target and a profile cannot widen it, a machine-authored turn is an identifier-only logical reference under the nexus-harness-graph or nexus-cds-rule NamingSystem, carrying a display and no literal reference; the identifier's system is what says the author is a graph. Human authors use the element normally.
A text note which also contains information about who made the statement and when.
Comments
For systems that do not have structured annotations, they can simply communicate a single annotation with no author or time. This element may need to be included in narrative because of the potential for modifying information. Annotations SHOULD NOT be used to communicate "modifying" information that could be computable. (This is a SHOULD because enforcing user behavior is nearly impossible).
May be used to represent additional information that is not part of the basic definition of the element. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension.
Comments
There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.
Who said it: a person, or a machine actor (identifier-only reference)
Definition
The author of this turn.
A person is referenced normally (authorReference to a Practitioner, Patient, RelatedPerson or
Organization), or named as free text with authorString where no structured reference exists.
A machine actor is an identifier-only logical reference: authorReference.identifier under its
producing registry's namespace -- ../NamingSystem/nexus-harness-graph naming
a harness graph, or ../NamingSystem/nexus-cds-rule naming a decision-support
rule -- with
authorReference.display carrying a readable name and NO authorReference.reference. Device is
not an allowed target of this element in R4 and a profile cannot add one, so the identifier system
carries the identity. Reference.type is omitted deliberately: setting it to Device would assert
a target the element does not permit.
Comments
Required here though optional in base R4: an unattributed turn is a statement in the record with nobody behind it. PractitionerRole is NOT a permitted target in R4 even though Task.owner permits it -- a task can be owned by a role and still have every turn authored by a person, and a writer that reaches for the same reference in both places will produce an invalid note. (R5 adds PractitionerRole; R4 does not, and a profile cannot widen the list.) For agent authors see nexus-note-agent-author, which enforces the identifier-only shape. Granularity for a machine author is the GRAPH or the RULE -- the unit a clinician or auditor recognises -- never the model or the prompt; per-model trace stays with the producer.
When the turn was made -- the thread's ordering key
Definition
When this turn was made. Required here though optional in base R4, because the turns are read as an ordered thread and a turn with no time cannot be placed in it.
Comments
Turns are read oldest-first by time. This element is the ordering key, which is why it is required: one undated turn makes the whole conversation's order a guess.
Markdown, per base R4. A turn carries prose, not structured payload: a turn that needs to cite chart resources cites them from the Task (focus, input, supportingInformation), not from inside the annotation. See the Task profile's note element for the graduation valve if that ever becomes insufficient.