Skip to content

Correction Task Profile

Canonical../StructureDefinition/nexus-correction-task
Statusdraft · 1.26.0
BaseTask Profile (constraint)
SourceFSH · 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.

Elements / Details

Every element this profile touches, with its full definition. Element names in the tables link here.

Task.id

Short Logical id of this artifact
Definition The logical id of the resource, as used in the URL for the resource. Once assigned, this value never changes.
Comments The only time that a resource does not have an id is when it is being submitted to the server using a create operation.
Cardinality 0..1
Type http://hl7.org/fhirpath/System.String

Task.meta

Short Metadata about the resource
Definition The metadata about the resource. This is content that is maintained by the infrastructure. Changes to the content might not always be associated with version changes to the resource.
Cardinality 0..1
Type Meta
Invariants ele-1

Task.implicitRules

Short A set of rules under which this content was created
Definition A reference to a set of rules that were followed when the resource was constructed, and which must be understood when processing the content. Often, this is a reference to an implementation guide that defines the special rules along with other profiles etc.
Comments Asserting this rule set restricts the content to be only understood by a limited set of trading partners. This inherently limits the usefulness of the data in the long term. However, the existing health eco-system is highly fractured, and not yet ready to define, collect, and exchange data in a generally computable sense. Wherever possible, implementers and/or specification writers should avoid using this element. Often, when used, the URL is a reference to an implementation guide that defines these special rules as part of it's narrative along with other profiles, value sets, etc.
Cardinality 0..1
Type uri
Modifier yes — This element is labeled as a modifier because the implicit rules may provide additional knowledge about the resource that modifies it's meaning or interpretation
Invariants ele-1

Task.language

Short Language of the resource content
Definition The base language in which the resource is written.
Comments Language is provided to support indexing and accessibility (typically, services such as text to speech use the language tag). The html language tag in the narrative applies to the narrative. The language tag on the resource may be used to specify the language of other presentations generated from the data in the resource. Not all the content has to be in the base language. The Resource.language should not be assumed to apply to the narrative automatically. If a language is specified, it should it also be specified on the div element in the html (see rules in HTML5 for information about the relationship between xml:lang and the html lang attribute).
Cardinality 0..1
Type code
Binding languages (preferred)
Invariants ele-1

Task.text

Short Text summary of the resource, for human interpretation
Definition A human-readable narrative that contains a summary of the resource and can be used to represent the content of the resource to a human. The narrative need not encode all the structured data, but is required to contain sufficient detail to make it "clinically safe" for a human to just read the narrative. Resource definitions may define what content should be represented in the narrative to ensure clinical safety.
Comments Contained resources do not have narrative. Resources that are not contained SHOULD have a narrative. In some cases, a resource may only have text with little or no additional discrete data (as long as all minOccurs=1 elements are satisfied). This may be necessary for data from legacy systems where information is captured as a "text blob" or where text is additionally entered raw or narrated and encoded information is added later.
Cardinality 0..1
Type Narrative
Invariants ele-1
Also called narrative, html, xhtml, display

Task.contained

Short The suggested-resource Bundle, plus anything else this task carries in-line
Definition On a suggested-resource task: a transaction Bundle holding the suggested resources as its entries, referenced from the suggestion input. That containment is what MAKES the task a suggested-resource task -- neither Task.code nor Task.intent says it. The Provenance carrying the suggestion's citations is an ENTRY IN THAT BUNDLE, not a sibling of it: a urn:uuid resolves only inside its own Bundle, so a Provenance beside the Bundle pointing at an entry within it is a dangling reference. Being an entry also means the citations are written on acceptance, which is the outcome AI attribution requires -- an accepted chart entry with no trail back to the passage it came from is the thing those rules exist to prevent. Anything else the task carries in-line -- an attachment born with it, having no independent existence in the chart -- is contained beside the Bundle. There is no ambiguity about which resources are suggested, because those are the Bundle's entries. The prototypes inside it are fully typed resources that state the clinical fact their citations support -- they carry NO pending-review marker of their own. Review state lives on the Task (Task.status for the decision, Task.intent for what is being asked), so a prototype is instantiable as-is rather than needing to be edited on acceptance. What each entry would DO to the chart is entry.request: method POST to add, PUT to update, with the target on request.url. Instantiating writes the Bundle; declining retains this Task (status cancelled, statusReason saying a human declined) with the Bundle still contained, as the record of what was refused.
Comments This should never be done when the content can be identified properly, as once identification is lost, it is extremely difficult (and context dependent) to restore it again. Contained resources may have profiles and tags In their meta elements, but SHALL NOT have security labels.
Cardinality 0..*
Type Resource
Also called inline resources, anonymous resources, contained resources

Task.extension

Short Additional content defined by implementations
Definition May be used to represent additional information that is not part of the basic definition of the resource. 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.
Cardinality 0..*
Type Extension
Invariants ele-1, ext-1
Also called extensions, user content

Task.extension:threadId

Short Harness thread id (AI-created tasks)
Definition May be used to represent additional information that is not part of the basic definition of the resource. 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 SHOULD be present on every harness-created Task. Assigning the Task back to an agent resumes this thread (the approve/resume contract). Never rendered in the UI.
Cardinality 0..1
Type Extension(Harness Thread Id)
Must Support yes
Invariants ele-1, ext-1
Also called extensions, user content

Task.modifierExtension

Short Extensions that cannot be ignored
Definition May be used to represent additional information that is not part of the basic definition of the resource and that modifies the understanding of the element that contains it and/or the understanding of the containing element's descendants. Usually modifier elements provide negation or qualification. 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 is allowed to define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension. Applications processing a resource are required to check for modifier extensions. Modifier extensions SHALL NOT change the meaning of any elements on Resource or DomainResource (including cannot change the meaning of modifierExtension itself).
Requirements Modifier extensions allow for extensions that cannot be safely ignored to be clearly distinguished from the vast majority of extensions which can be safely ignored. This promotes interoperability by eliminating the need for implementers to prohibit the presence of extensions. For further information, see the definition of modifier extensions.
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.
Cardinality 0..*
Type Extension
Modifier yes — Modifier extensions are expected to modify the meaning or interpretation of the resource that contains them
Invariants ele-1, ext-1
Also called extensions, user content

Task.identifier

Short Business identifier(s) for the task (any system; machine-written tasks carry their producer's key)
Definition Business identifier(s) for task tracking and audit. A business identifier is RECOMMENDED but not required, and no specific canonical system is mandated: a task that originates in an external system should carry that system's identifier, while a task created inside the EMR has no external record to name and is tracked by the server-assigned id alone. A task a machine writes on its own behalf SHOULD carry an identifier under its own producer's key namespace -- ../NamingSystem/nexus-harness-key for the AI harness, ../NamingSystem/nexus-cds-key for a decision-support rule -- whose value is derived from the GAP the task addresses rather than from the run that produced it, so that re-running the producing capability updates this task instead of creating a second one. The two namespaces are deliberately separate: a producer searches its key and updates the task it finds, so a shared key space would let one producer's re-run overwrite the other producer's task.
Comments Readers must tolerate a task with no identifier at all -- that is the ordinary shape of a task created in the chart, not a malformed record. For machine-written tasks the producer's business key is the idempotency contract: a producer searches Task?identifier={its own key system}|{key} before writing (../NamingSystem/nexus-harness-key|{key} for the harness, ../NamingSystem/nexus-cds-key|{key} for a decision-support rule), updates the task it finds, and resolves that task when the gap it addresses no longer holds. Not sliced here: the element is left open, so adding the key is additive for every existing writer. A source system's own identifier SHOULD be carried alongside this one, flagged use = secondary. See Carrying the raw code.
Cardinality 0..*
Type Identifier
Invariants ele-1

Task.instantiatesCanonical

Short Formal definition of task (canonical)
Definition References to formal protocols, guidelines, or ActivityDefinitions that this task follows.
Requirements Enables a formal definition of how he task is to be performed, enabling automation.
Comments MERT requirement for protocol-based task execution.
Cardinality 0..1
Type canonical
Must Support yes
Invariants ele-1

Task.instantiatesUri

Short Formal definition of task (URI)
Definition URI references to external protocols, guidelines, or specifications.
Requirements Enables a formal definition of how he task is to be performed (e.g. using BPMN, BPEL, XPDL or other formal notation to be associated with a task), enabling automation.
Comments MERT requirement for external protocol references.
Cardinality 0..1
Type uri
Must Support yes
Invariants ele-1

Task.basedOn

Short Request fulfilled by this task (available, not must-support)
Definition The request, order, or authorization that initiated this task.
Comments The ORDER this task carries out, and only an order: base R4 leaves this open to any resource, and this profile narrows it to the four request types, so basedOn cannot quietly become a second focus. Distinct from focus (the chart element the task is filed against) and from encounter (the visit it arose in). Available and typed, but not must-support -- populate it when a task genuinely fulfills an order, and do not synthesize one to fill the element.
Cardinality 0..*
Type Reference(ServiceRequest | MedicationRequest | CarePlan | SupplyRequest)
Invariants ele-1

Task.groupIdentifier

Short Shared identifier for tasks raised together (e.g. one decision-support card)
Definition Identifier shared by every task raised in one batch, so the batch is recoverable as a set. For suggestions produced by a decision-support service, this carries the CARD: all of a card's suggestions become sibling tasks with the same value here. Distinct from Task.identifier, which identifies THIS task (and, for machine-written tasks, the gap it addresses under the producing capability's key namespace).
Requirements Billing and/or reporting can be linked to whether multiple requests were created as a single unit.
Comments A DISPLAY GROUPING AND NOTHING ELSE: consumers MUST NOT read this element, or its absence, as a signal of which producer raised a task, because grouping is available to every producer -- a harness capability proposing several chart entries from one note is one evaluation raising a set exactly as a card is. Producer is declared on requester. Find the siblings with Task?group-identifier={system}|{value}. Grouping is orthogonal to intent: siblings are ALTERNATIVES only when they carry intent = #option, in which case accepting one normally cancels the rest. Where the group has no natural upstream identifier, any stable value the producer can regenerate will do -- but derive it from what the card is ABOUT, on the same reasoning as the business key, or a re-evaluation produces a new group for the same advice.
Cardinality 0..1
Type Identifier
Must Support yes
Invariants ele-1

Task.partOf

Short Parent task for sub-tasks and branches
Definition Reference to parent task when this task is part of a larger workflow or represents a sub-task.
Requirements Allows tasks to be broken down into sub-steps (and this division can occur independent of the original task).
Comments Supports Nexus EMR workflow branching and task hierarchy.
Cardinality 0..*
Type Reference(Task Profile)
Must Support yes
Invariants ele-1

Task.status

Short Where the task is in its lifecycle
Definition Where this task sits in its lifecycle. THESE ARE MEANINGS, NOT A PATH -- any state may follow any other, and the ordinary cases prove it: ready straight to completed is a normal day's work, and accepted back to ready is handing something back. What each code means is the specification; the order is not. - draft -- being composed. In nobody's list yet, and nobody is expected to act on it. - ready -- actionable and in its owner's list. Where the owner is a CareTeam, it is in the team's pool and nobody has claimed it. Where there is no owner at all, it is in EVERY user's list: unassigned work is ready work that has not been narrowed to anyone yet. - accepted -- claimed by its owner and not yet started. The point of a state between ready and in-progress is CIRCULATION: claiming a pooled task moves owner from the team to the person and takes it out of everyone else's view, which is a real event even though no work has started. - in-progress -- actively being worked. - on-hold -- deliberately parked: snoozed, or waiting on something outside this task. Distinct from ready because a parked task should not read as awaiting action. - completed -- the work was done. - cancelled -- the work will not be done. This covers BOTH a proposal a human declined and a proposal that became moot (its alternative was approved, or the gap closed on its own), which is why Task.statusReason matters here more than anywhere else on this profile.
Requirements These states enable coordination of task status with off-the-shelf workflow solutions that support automation of tasks.
Comments The binding is a REQUIRED subset of R4 TaskStatus, not the base value set: requested (a second name for ready), received, rejected, failed and entered-in-error are excluded, each for a reason given on the value set. The one worth knowing is rejected: a declined proposal is cancelled, so declining something and it becoming moot no longer live in different states. Task.statusReason carries which of the two happened and SHOULD be populated whenever a proposal is cancelled -- without it the record cannot say whether a clinician considered this and said no.
Cardinality 1..1
Type code
Must Support yes
Modifier yes — This element is labeled as a modifier because it is a status element that contains status entered-in-error which means that the resource should not be treated as valid
Binding Clinical Task Statuses (required)
Invariants ele-1

Task.statusReason

Short Reason for current status
Definition Captures why the task is in its current state, particularly for cancelled or failed states.
Comments Load-bearing on a CANCELLED PROPOSAL and close to required there in practice. cancelled carries two facts that used to be separate states: a human considered this and declined it, and this stopped being on offer (its alternative was approved, the care gap closed on its own). Those are different clinical records and only this element can now tell them apart, so a writer cancelling a proposal without a reason destroys information the model can no longer recover.
Cardinality 0..1
Type CodeableConcept
Must Support yes
Invariants ele-1

Task.businessStatus

Short Where the correction request has got to
Definition The correction 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. completed does NOT mean the work is over. HL7 defines it as the state where a disagreement has been logged AND a formal rebuttal provided; a request that was accepted and amended ends at amendment-completed, and one refused without a rebuttal ends at disagreement-logged. Do not reach for it because a task is finished.
Requirements There's often a need to track substates of a task - this is often variable by specific workflow implementation.
Comments REQUIRED here, and required on this profile rather than optional as it is on the base: a correction request always has a position in its lifecycle, and an absent one is indistinguishable from a request nobody has looked at. denied is the load-bearing value -- it is the refusal that entitles the requester to file a statement of disagreement, and the Statement of Disagreement profile's partOf points back at the task that reached it. A refusal is a task whose status is completed and whose businessStatus is denied: failed would say the system broke, which loses the only fact the statute cares about. The vocabulary is HL7's rather than this guide's on purpose -- the concepts are not local, and a reader outside this estate should not need our value set to understand the outcome.
Cardinality 1..1
Type CodeableConcept
Must Support yes
Binding Correction Business Status Value Set (required)
Invariants ele-1

Task.intent

Short order (do this) | proposal (consider this) | option (one of these)
Definition What the owner is being asked to do with this task. Independent of whether the task carries a suggestion. * order -- the work is authorized and assigned; the owner is expected to DO it. Inbox items, follow-ups and to-dos are orders, and a user sees them in a Tasks list. A suggested-resource task MAY be an order, where the suggested entry is already authorized and the task exists to get it recorded rather than decided. * proposal -- something is being offered and takes effect only if the owner APPROVES it, which flips this element to order, one-way. A user sees proposals in a Suggestions list rather than a Tasks list, and that list membership is the whole practical meaning of this code. A machine-extracted chart entry pending review is the usual case: the requester (a non-human agent) has no authority to commit it. * option -- this task is ONE OF A SET of alternatives, grouped by a shared groupIdentifier. Accepting one moots the others, which are then cancelled rather than rejected. A decision-support card offering three ways to close the same gap raises three tasks at option, not three independent proposals.
Comments A consumer branching on 'is this mine to do, or mine to decide?' reads intent, and a UI splitting a Suggestions list from a Tasks list is reading exactly this element. A consumer asking 'does this carry a suggested chart entry?' must NOT read it: read the contained Bundle, because an #order carrying a suggested resource is a real and ordinary shape. APPROVING a proposal sets this element to order and is one-way; it moves the task between lists and writes nothing to the chart. That is a different act from ACCEPTING the task (Task.status) and from INSTANTIATING its contained graph -- see the suggested-resource section for all three.
Cardinality 1..1
Type code
Must Support yes
Binding Clinical Task Intent Value Set (required)
Invariants ele-1

Task.priority

Short How urgent the task is
Definition Clinical priority level for workflow triage and routing.
Requirements Used to identify the service level expected while performing a task.
Comments Used for inbox sorting and urgent task highlighting in UI. routine is the FLOOR of this vocabulary and the binding cannot be widened -- base R4 binds it REQUIRED, a profile may only strengthen a binding, and the element is a bare code with no second coding slot even if it could. A priority below routine therefore rides the priorityDetail extension below, under a rule that makes it safe to ignore.
Cardinality 0..1
Type code
Must Support yes
Binding request-priority (required)
Invariants ele-1

Task.priority.id

Short xml:id (or equivalent in JSON)
Definition unique id for the element within a resource (for internal references)
Cardinality 0..1
Type http://hl7.org/fhirpath/System.String

Task.priority.extension

Short Additional content defined by implementations
Definition May be used to represent additional information that is not part of the basic definition of the resource. 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.
Cardinality 0..*
Type Extension
Invariants ele-1, ext-1
Also called extensions, user content

Task.priority.extension:priorityDetail

Short A refinement finer than request-priority allows (currently: trivial)
Definition May be used to represent additional information that is not part of the basic definition of the resource. 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 When present, Task.priority SHALL be routine (nexus-task-priority-detail-1). A consumer that does not read this extension therefore sees routine, the nearest true statement in the base vocabulary, and under-states the task rather than mis-sorting it.
Cardinality 0..1
Type Extension(Task Priority Detail)
Must Support yes
Invariants ele-1, ext-1
Also called extensions, user content

Task.priority.value

Short Primitive value for code
Cardinality 0..1
Type http://hl7.org/fhirpath/System.String

Task.code

Short Always privacy-request
Definition The category this task is filed under, so a view can sort tasks into bins. The vocabulary is expected to grow. The element is OPTIONAL -- most tasks in the chart predate this vocabulary and carry none, and readers must tolerate its absence rather than treat it as malformed. Extensible: a deployment whose category has no concept in the bound value set stays conformant under its own system.
Comments Fixed, and required where the base profile leaves code optional. This is the worklist bin for work arising from someone exercising a right over their own record -- access, correction, or a disagreement to be logged where a correction was refused. It is NAMED FOR THE RIGHT, NOT THE OUTCOME: which of the three this task is, and where it has got to, are read off businessStatus and off the optional second code coding from the international correction task-type system. THE BIN IS WIDER THAN THIS PROFILE. It also carries access requests, which this profile does not cover, so code = privacy-request is not on its own a statement that a task conforms here -- a consumer that needs the correction shape reads meta.profile, or reads the correction vocabulary off businessStatus.
Cardinality 1..1
Type CodeableConcept
Must Support yes
Binding Task Codes (extensible)
Pattern {"coding":[{"code":"privacy-request","system":"../CodeSystem/nexus-task-code"}]}
Invariants ele-1

Task.description

Short The ask: original task content, stable throughout lifecycle
Definition Canonical task description that provides the core content and remains stable throughout the task lifecycle. This is the ASK -- the statement of what is wanted and why the task exists. The turns that follow it live in note, and a writer should NOT duplicate this text into note[0]: that puts the same statement in two places and opens the conversation with something nobody said. May include structured forms (lab requisition, referral, etc.) and supports Markdown formatting for rich content.
Comments Nexus EMR requires description (1..1) vs MERT optional (0..1) to prevent ambiguous work items. It is also what makes note optional: the ask is carried here, so a task with no conversation on it yet is complete rather than malformed.
Cardinality 1..1
Type string
Must Support yes
Invariants ele-1

Task.focus

Short The chart element this task is about (form, inbox document, note, ...)
Definition The patient-chart element this task concerns: the form that was completed, the document that arrived, the note that needs signing, the problem being followed up. Forms and inbox documents are NOT stored inside the task. A completed form is a QuestionnaireResponse, an arriving document is a DocumentReference, an authored note is a Composition, and the task points at it. One copy, in the chart, readable by consumers that know nothing about task workflow. focus does NOT say what a suggested-resource task would write. An earlier revision of this profile made it the add-versus-update marker -- focus absent meant add, focus present meant update. That broke on the first suggested-resource task that wanted to do both, because focus is 0..1. What each suggested resource would do to the chart is now entry.request inside the contained prototype Bundle: method POST to create, PUT to update, with the target on request.url, stated once per entry. So focus on a suggested-resource task means what it means everywhere else on this profile: the chart element the task is filed against. A suggested change to a medication may well name that medication here, because that is what the task is about -- but it is entry.request that makes it an update, and a reader must not infer one from the other. Retiring an entry is the same shape: there is no delete in this chart, so a suggestion to withdraw a resource is an update whose payload carries the entered-in-error status its own resource type defines. focus names the target, the payload states the end state, and nothing here needs a vocabulary of actions.
Requirements Used to identify the thing to be done.
Comments focus is what the task is ABOUT; input carries what the task NEEDS -- chiefly a contained machine-suggested resource. A reader looking for 'which chart element is this task on' reads focus and nothing else. Where a workflow genuinely spans several elements, focus names the one the task is filed against and the rest ride in input. ALWAYS A RESOURCE THAT ALREADY EXISTS IN THE CHART: never a contained resource, never a local # reference, enforced by nexus-task-focus-not-contained. On a suggested-resource task it does NOT say whether a suggested resource is created or updated -- that is entry.request.method inside the contained Bundle, stated per suggested resource, so one task can do both.
Cardinality 0..1
Type Reference(QuestionnaireResponse Profile | DocumentReference Profile | Composition Profile | Condition Profile | DiagnosticReport Profile | ServiceRequest Profile | MedicationRequest Profile | Observation Profile | AllergyIntolerance Profile)
Must Support yes
Invariants ele-1

Task.for

Short Patient this task is about, when it is about one
Definition The patient this task concerns. Patient context is STRONGLY RECOMMENDED and is always set for a task created from a patient chart, because a clinical task whose patient link is missing is a safety problem. It is not required, because the profile also carries standalone work items -- administrative or practice-level to-dos -- that are about no patient at all.
Requirements Used to track tasks outstanding for a beneficiary. Do not use to track the task owner or creator (see owner and creator respectively). This can also affect access control.
Comments When present the reference must be a NexusEmrCorePatient. Readers must tolerate its absence and treat a patient-less task as a standalone work item, not a malformed record; a surface that assumes for is populated will drop those tasks or fault on them. Never infer the patient from focus -- focus is the chart element the task is filed against, and a task can carry one without the other.
Cardinality 0..1
Type Reference(Patient Profile)
Must Support yes
Invariants ele-1
Also called Patient

Task.encounter

Short Healthcare encounter during which task was created
Definition Links the task to the specific clinical encounter that generated it.
Requirements For some tasks it may be important to know the link between the encounter the task originated within.
Comments Provides clinical context for task creation and helps with documentation workflow.
Cardinality 0..1
Type Reference(Encounter Profile)
Must Support yes
Invariants ele-1

Task.executionPeriod

Short Start and end time of execution
Definition Expected or actual time period during which the task is to be or was executed.
Comments MERT requirement for task timing management.
Cardinality 0..1
Type Period
Must Support yes
Invariants ele-1

Task.authoredOn

Short When task was first created
Definition Timestamp when the task was initially created for complete audit trail.
Requirements Most often used along with lastUpdated to track duration of task to supporting monitoring and management.
Comments Nexus EMR requires creation timestamp (1..1) vs MERT optional (0..1) for audit compliance.
Cardinality 1..1
Type dateTime
Must Support yes
Invariants ele-1
Also called Created Date

Task.lastModified

Short Task last modified date
Definition Most recent timestamp when the task was modified.
Requirements Used along with history to track task activity and time in a particular task state. This enables monitoring and management.
Comments MERT requirement for modification tracking.
Cardinality 0..1
Type dateTime
Must Support yes
Invariants ele-1
Also called Update Date

Task.requester

Short Who originally requested this task (person, AI graph, or decision-support rule)
Definition The person or agent that initiated this task. THIS IS WHERE THE PRODUCER OF A MACHINE-WRITTEN TASK IS DECLARED, and a consumer telling producers apart reads this element and nothing else. Machine-created tasks (e.g. suggestions) use a LOGICAL Device reference: Reference.type = "Device" and Reference.identifier under the producing registry's namespace -- ../NamingSystem/nexus-harness-graph naming the AI-harness graph, or ../NamingSystem/nexus-cds-rule naming the decision-support rule. Two namespaces because two separately owned registries mint these values and either could mint the same string. The identifier need not resolve to a Device resource on the server -- it points into the producing registry. Granularity is the graph or rule (a name a clinician or auditor can recognize); per-agent trace stays with the producer.
Requirements Identifies who created this task. May be used by access control mechanisms (e.g., to ensure that only the creator can cancel a task).
Comments Nexus EMR requires requester (1..1) vs MERT optional (0..1) for clear accountability chain. Reference.display SHOULD carry the human-readable name. Ask "was the requester a machine" with Reference.type = "Device" and "was this content machine-produced" with the AIAST security label; read identifier.system only for WHICH KIND of producer, and expect the list of producing registries to grow. Do NOT infer the producer from intent (humans raise proposals) or from groupIdentifier (grouping is available to every producer).
Cardinality 1..1
Type Reference(PractitionerRole Profile | Practitioner Profile | Device)
Must Support yes
Invariants ele-1

Task.performerType

Short Requested performer type
Definition The type of performer (person, device, organization) required to complete the task.
Requirements Use to distinguish tasks on different activity queues.
Comments MERT requirement for specifying required performer characteristics.
Cardinality 0..*
Type CodeableConcept
Must Support yes
Binding performer-role (preferred)
Invariants ele-1

Task.owner

Short Who holds this task now; absent means the whole clinic holds it
Definition Who is responsible for the next action on this task. ABSENT -- responsibility has NOT been narrowed: the task belongs to every user in the clinic. Unassigned work is collective work, not unowned work, and a consumer MUST surface it in every user's default inbox view (see the element comment). This is the ordinary state of work that has arrived and not yet been triaged, including work written by an external system that names no owner. PRESENT -- responsibility is narrowed to exactly one party: - An individual practitioner (the ordinary case) - A practitioner role, when the capacity is what matters rather than the individual (the on-call physician, the nurse covering a clinic) - A CareTeam for group assignment - the sanctioned mechanism for pool/work-stream ownership (e.g., a nursing pool): the team as a whole holds the work until a member claims or completes the task. groupIdentifier remains available to name the batch or work stream a task belongs to; it is not the ownership mechanism. - Machine actors as first-class owners: a LOGICAL Device reference (Reference.identifier under the producing registry's namespace -- ../NamingSystem/nexus-harness-graph naming a harness graph, or ../NamingSystem/nexus-cds-rule naming a decision-support rule -- with Reference.type = "Device"; the identifier need not resolve to a Device resource on the server). Assigning a Task to a HARNESS GRAPH is additionally the approve/resume contract: the harness watches for task-assignment changes and resumes (or starts) the thread named by the thread-id extension. That contract is the harness's own; assigning a task to a rule carries no such undertaking. An absent owner is the ONLY representation of unassigned. A sentinel owner -- a per-tenant "unassigned" CareTeam, or an Organization standing for the practice -- is a second spelling of one state, reads as narrowed to any consumer testing whether the element is populated, and must not be written. NOT SETTLED (1.26.0): whether an absent owner is permitted at all is still open, and this element may change in a future release. The competing position is that every task names an owner when it is written, with a configured default owner where the producer has nobody to name. It is scheduled to be settled after the September 2026 demo. A producer that always sets owner conforms under either outcome; a consumer must handle an absent owner today.
Requirements Identifies who is expected to perform this task.
Comments The owner is responsible for the next action on this task. Ownership transfers with each significant action (forward, reply, assign-to-agent, claim-from-pool, etc.). When owner is ABSENT, responsibility has not been narrowed and rests with every user in the clinic: a consumer MUST show unassigned tasks in each user's default inbox view rather than behind a filter or a tab the reader must select, and count them wherever outstanding work is counted. That visibility is what makes the un-narrowed state safe; a consumer that hides it has not implemented this element. Assigning a CareTeam narrows responsibility to the team as a unit; accountability remains singular because the reference is still exactly one owner. Note the asymmetry with note.author, which CANNOT be a CareTeam or a PractitionerRole -- R4 does not permit either as an Annotation.author target, so a task owned by a team still has every turn authored by a person (see the Task Note profile). Reference.display SHOULD carry the human-readable name (person, team, or graph). NOT SETTLED (1.26.0): whether an absent owner is permitted at all is under review and may change in a future release -- see the element definition.
Cardinality 0..1
Type Reference(PractitionerRole Profile | Practitioner Profile | CareTeam Profile | Device)
Must Support yes
Invariants ele-1
Also called Performer, Executer

Task.location

Short Where task should be performed
Definition Principal physical location where the task is to be performed.
Requirements Ties the event to where the records are likely kept and provides context around the event occurrence (e.g. if it occurred inside or outside a dedicated healthcare setting).
Comments MERT requirement for task location specification.
Cardinality 0..1
Type Reference(Location Profile)
Must Support yes
Invariants ele-1

Task.reasonCode

Short Why task is needed (coded)
Definition Coded indication of why the task was created.
Comments MERT requirement for coded task rationale. Where this code was mapped from a source system's own vocabulary, carry the raw coding alongside the mapped one, flagged userSelected = true. See Carrying the raw code.
Cardinality 0..1
Type CodeableConcept
Must Support yes
Invariants ele-1

Task.reasonReference

Short Clinical reason for this task (available, not must-support)
Definition Reference to the clinical finding that justifies the task -- the condition being followed up, the abnormal result being chased, the document being actioned.
Comments Why the task exists, pointing at a clinical resource; reasonCode carries the same fact as a code. Not the same as focus, which is the chart element the task is filed AGAINST: a task to review an abnormal potassium has that DiagnosticReport as its focus, and the Condition it relates to (if any) as its reasonReference. Never the Patient -- every task is about the patient, so that says nothing.
Cardinality 0..1
Type Reference(Condition | Observation | DiagnosticReport | DocumentReference)
Invariants ele-1

Task.insurance

Short Associated insurance coverage
Definition Insurance coverage that is relevant to the performance of this task.
Comments MERT requirement for insurance context.
Cardinality 0..*
Type Reference(Coverage)
Must Support yes
Invariants ele-1

Task.note

Short The conversation on this task, oldest first; the ask itself is description
Definition The conversation on this task, oldest first, and one of the reasons this profile exists. What is being asked, and why the task exists, is description -- required, stable for the life of the task, and NOT repeated here. note is what has been said SINCE: the question that came with a forward, the answer that came back, the reason it was put on hold. Both people and AI-harness graphs author turns (see the Task Note profile, which carries the rules for machine authorship). No turn is required. A task nobody has commented on yet carries no note at all, which is the ordinary state of newly created work rather than a malformed record. A writer should NOT copy description into a turn to fill the thread: that puts the same statement in two places and opens the conversation with something nobody said. The thread runs the whole life of the task -- extended at every handoff, still readable when the task is closed and someone asks a year later what happened. A task handed between people is only intelligible to the receiver if that exchange travels with it, which is why the turns live on the task rather than in separate resources that would have to be gathered up. This is the ONLY conversation mechanism on a task. Communication is not used for task turns.
Comments Notes are what people SAID; relevantHistory is what HAPPENED (Provenance: created, forwarded, completed, by whom). Keep them apart -- the audit trail must not depend on anyone having chosen to comment. The ask is description, so a consumer showing "what is this task" reads description and one showing "what was said" reads every note; note[0] is the first thing said AFTER the task was created, not the ask itself, and a task may have no notes at all. Turns are typed to the Task Note profile, which requires an author and a time on every turn and defines how an AI-harness graph is named as author (R4 does not permit Device on Annotation.author, and a profile cannot widen it).
Cardinality 0..*
Type Annotation(Task Note (one conversation turn))
Must Support yes
Invariants ele-1

Task.relevantHistory

Short Key events in history of the Task
Definition Links to Provenance records for past versions of this Task that identify key state transitions or updates that are likely to be relevant to a user looking at the current version of the task.
Comments This element does not point to the Provenance associated with the current version of the resource - as it would be created after this version existed. The Provenance for the current version can be retrieved with a _revinclude.
Cardinality 0..*
Type Reference(Provenance)
Invariants ele-1
Also called Status History

Task.restriction

Short Constraints on fulfillment tasks
Definition Constraints that apply to the fulfillment of the task.
Requirements Sometimes when fulfillment is sought, you don't want full fulfillment.
Comments MERT requirement for task execution constraints. restriction.period is where a DUE DATE lives: its end is the time by which the task should be completed, per the base definition, and it is the element an inbox sorts overdue work on. For a privacy-request task that due date is the STATUTORY RESPONSE DEADLINE -- an individual's request to access or correct their own record has to be answered within a period set by law, and no privacy-specific element exists or is needed to hold it. Do not write a due date on executionPeriod, which means when the work is being or was done: a deadline written there produces a task claiming to have been worked on a date in the future.
Cardinality 0..1
Type BackboneElement
Must Support yes
Invariants ele-1

Task.restriction.id

Short Unique id for inter-element referencing
Definition Unique id for the element within a resource (for internal references). This may be any string value that does not contain spaces.
Cardinality 0..1
Type http://hl7.org/fhirpath/System.String

Task.restriction.extension

Short Additional content defined by implementations
Definition 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.
Cardinality 0..*
Type Extension
Invariants ele-1, ext-1
Also called extensions, user content

Task.restriction.modifierExtension

Short Extensions that cannot be ignored even if unrecognized
Definition May be used to represent additional information that is not part of the basic definition of the element and that modifies the understanding of the element in which it is contained and/or the understanding of the containing element's descendants. Usually modifier elements provide negation or qualification. 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. Applications processing a resource are required to check for modifier extensions. Modifier extensions SHALL NOT change the meaning of any elements on Resource or DomainResource (including cannot change the meaning of modifierExtension itself).
Requirements Modifier extensions allow for extensions that cannot be safely ignored to be clearly distinguished from the vast majority of extensions which can be safely ignored. This promotes interoperability by eliminating the need for implementers to prohibit the presence of extensions. For further information, see the definition of modifier extensions.
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.
Cardinality 0..*
Type Extension
Modifier yes — Modifier extensions are expected to modify the meaning or interpretation of the element that contains them
Invariants ele-1, ext-1
Also called extensions, user content, modifiers

Task.restriction.repetitions

Short How many times to repeat
Definition Indicates the number of times the requested action should occur.
Requirements E.g. order that requests monthly lab tests, fulfillment is sought for 1.
Cardinality 0..1
Type positiveInt
Invariants ele-1

Task.restriction.period

Short When fulfillment sought
Definition Over what time-period is fulfillment sought.
Requirements E.g. order that authorizes 1 year's services. Fulfillment is sought for next 3 months.
Comments Note that period.high is the due date representing the time by which the task should be completed.
Cardinality 0..1
Type Period
Invariants ele-1

Task.restriction.recipient

Short For whom is fulfillment sought?
Definition For requests that are targeted to more than on potential recipient/target, for whom is fulfillment sought?
Cardinality 0..*
Type Reference(Patient | Practitioner | PractitionerRole | RelatedPerson | Group | Organization)
Invariants ele-1

Task.input

Short Resource(s) this task NEEDS in order to be worked
Definition Reference(s) to what the task needs -- chiefly the contained machine-suggested resource, and any additional chart elements a workflow spans beyond the one it is filed against. NOT the element the task is about: that is focus, which is typed. May reference any resource.
Requirements Resources and data used to perform the task. This data is used in the business logic of task execution, and is stored separately because it varies between workflows.
Comments Read focus to answer 'which chart element is this task on'; input never answers that question on its own. input.type is a human-readable label for now; a controlled chart-element vocabulary may be bound later. Non-reference input parameters are not supported -- use note/description for free text.
Cardinality 0..*
Type BackboneElement
Must Support yes
Invariants ele-1
Also called Supporting Information

Task.input.id

Short Unique id for inter-element referencing
Definition Unique id for the element within a resource (for internal references). This may be any string value that does not contain spaces.
Cardinality 0..1
Type http://hl7.org/fhirpath/System.String

Task.input.extension

Short Additional content defined by implementations
Definition 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.
Cardinality 0..*
Type Extension
Invariants ele-1, ext-1
Also called extensions, user content

Task.input.modifierExtension

Short Extensions that cannot be ignored even if unrecognized
Definition May be used to represent additional information that is not part of the basic definition of the element and that modifies the understanding of the element in which it is contained and/or the understanding of the containing element's descendants. Usually modifier elements provide negation or qualification. 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. Applications processing a resource are required to check for modifier extensions. Modifier extensions SHALL NOT change the meaning of any elements on Resource or DomainResource (including cannot change the meaning of modifierExtension itself).
Requirements Modifier extensions allow for extensions that cannot be safely ignored to be clearly distinguished from the vast majority of extensions which can be safely ignored. This promotes interoperability by eliminating the need for implementers to prohibit the presence of extensions. For further information, see the definition of modifier extensions.
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.
Cardinality 0..*
Type Extension
Modifier yes — Modifier extensions are expected to modify the meaning or interpretation of the element that contains them
Invariants ele-1, ext-1
Also called extensions, user content, modifiers

Task.input.type

Short Label for the input
Definition A code or description indicating how the input is intended to be used as part of the task execution.
Requirements Inputs are named to enable task automation to bind data and pass it from one task to the next.
Comments If referencing a BPMN workflow or Protocol, the "system" is the URL for the workflow definition and the code is the "name" of the required input.
Cardinality 1..1
Type CodeableConcept
Invariants ele-1
Also called Name

Task.input.value[x]

Short The referenced chart element (any resource)
Definition The value of the input parameter as a basic type.
Cardinality 1..1
Type Reference(Resource)
Invariants ele-1

Task.input:suggestion

Short The contained prototype Bundle (local #id reference)
Definition References the transaction Bundle CONTAINED in this Task that holds the suggested resources. The reference SHALL be local (#id, enforced by nexus-sugg-1) and SHALL resolve to a Bundle contained in this same Task (nexus-sugg-2). Both are error severity. ONE reference, not one per suggested resource: the Bundle holds them all, as its entries.
Requirements Resources and data used to perform the task. This data is used in the business logic of task execution, and is stored separately because it varies between workflows.
Comments Read focus to answer 'which chart element is this task on'; input never answers that question on its own. input.type is a human-readable label for now; a controlled chart-element vocabulary may be bound later. Non-reference input parameters are not supported -- use note/description for free text.
Cardinality 0..1
Type BackboneElement
Must Support yes
Invariants ele-1
Also called Supporting Information

Task.input:suggestion.id

Short Unique id for inter-element referencing
Definition Unique id for the element within a resource (for internal references). This may be any string value that does not contain spaces.
Cardinality 0..1
Type http://hl7.org/fhirpath/System.String

Task.input:suggestion.extension

Short Additional content defined by implementations
Definition 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.
Cardinality 0..*
Type Extension
Invariants ele-1, ext-1
Also called extensions, user content

Task.input:suggestion.modifierExtension

Short Extensions that cannot be ignored even if unrecognized
Definition May be used to represent additional information that is not part of the basic definition of the element and that modifies the understanding of the element in which it is contained and/or the understanding of the containing element's descendants. Usually modifier elements provide negation or qualification. 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. Applications processing a resource are required to check for modifier extensions. Modifier extensions SHALL NOT change the meaning of any elements on Resource or DomainResource (including cannot change the meaning of modifierExtension itself).
Requirements Modifier extensions allow for extensions that cannot be safely ignored to be clearly distinguished from the vast majority of extensions which can be safely ignored. This promotes interoperability by eliminating the need for implementers to prohibit the presence of extensions. For further information, see the definition of modifier extensions.
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.
Cardinality 0..*
Type Extension
Modifier yes — Modifier extensions are expected to modify the meaning or interpretation of the element that contains them
Invariants ele-1, ext-1
Also called extensions, user content, modifiers

Task.input:suggestion.type

Short Label for the input
Definition A code or description indicating how the input is intended to be used as part of the task execution.
Requirements Inputs are named to enable task automation to bind data and pass it from one task to the next.
Comments If referencing a BPMN workflow or Protocol, the "system" is the URL for the workflow definition and the code is the "name" of the required input.
Cardinality 1..1
Type CodeableConcept
Pattern {"coding":[{"code":"suggested-resource","system":"../CodeSystem/nexus-task-input-type"}]}
Invariants ele-1
Also called Name

Task.input:suggestion.value[x]

Short Local reference (#id) to the contained prototype Bundle
Definition The value of the input parameter as a basic type.
Cardinality 1..1
Type Reference(Bundle)
Invariants ele-1

Task.output

Short Information produced as part of task
Definition Outputs produced by the Task.
Requirements Resources and data produced during the execution the task. This data is generated by the business logic of task execution, and is stored separately because it varies between workflows.
Cardinality 0..*
Type BackboneElement
Invariants ele-1

Task.output.id

Short Unique id for inter-element referencing
Definition Unique id for the element within a resource (for internal references). This may be any string value that does not contain spaces.
Cardinality 0..1
Type http://hl7.org/fhirpath/System.String

Task.output.extension

Short Additional content defined by implementations
Definition 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.
Cardinality 0..*
Type Extension
Invariants ele-1, ext-1
Also called extensions, user content

Task.output.modifierExtension

Short Extensions that cannot be ignored even if unrecognized
Definition May be used to represent additional information that is not part of the basic definition of the element and that modifies the understanding of the element in which it is contained and/or the understanding of the containing element's descendants. Usually modifier elements provide negation or qualification. 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. Applications processing a resource are required to check for modifier extensions. Modifier extensions SHALL NOT change the meaning of any elements on Resource or DomainResource (including cannot change the meaning of modifierExtension itself).
Requirements Modifier extensions allow for extensions that cannot be safely ignored to be clearly distinguished from the vast majority of extensions which can be safely ignored. This promotes interoperability by eliminating the need for implementers to prohibit the presence of extensions. For further information, see the definition of modifier extensions.
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.
Cardinality 0..*
Type Extension
Modifier yes — Modifier extensions are expected to modify the meaning or interpretation of the element that contains them
Invariants ele-1, ext-1
Also called extensions, user content, modifiers

Task.output.type

Short Label for output
Definition The name of the Output parameter.
Requirements Outputs are named to enable task automation to bind data and pass it from one task to the next.
Cardinality 1..1
Type CodeableConcept
Invariants ele-1
Also called Name

Task.output.value[x]

Short Result of output
Definition The value of the Output parameter as a basic type.
Requirements Task outputs can take any form.
Cardinality 1..1
Type base64Binary, boolean, canonical, code, date, dateTime, decimal, id, instant, integer, markdown, oid, positiveInt, string, time, unsignedInt, uri, url, uuid, Address, Age, Annotation, Attachment, CodeableConcept, Coding, ContactPoint, Count, Distance, Duration, HumanName, Identifier, Money, Period, Quantity, Range, Ratio, Reference, SampledData, Signature, Timing, ContactDetail, Contributor, DataRequirement, Expression, ParameterDefinition, RelatedArtifact, TriggerDefinition, UsageContext, Dosage, Meta
Invariants ele-1