Task Profile

Canonical	../StructureDefinition/nexus-emr-core-clinical-task
Status	draft · 1.26.0
Base	Task (constraint)
Source	FSH · JSON

A unit of work in the chart: who asked for it, who owns it now, what has been said about it, and which chart element it concerns. Inbox items, to-dos, follow-ups, a result that needs review -- deliberately one kind of work item.

Overview

It also carries suggested chart entries, content awaiting someone's acceptance. Read the Overview before building anything that lists or displays tasks.

A decision-support producer may tag the state of the content behind a suggestion. A task projected from decision-support content that was loaded without requiring clinical sign-off carries unsigned-draft in meta.tag under the CDS Content Status code system. This profile does not model or slice meta.tag: the element is open on every resource, and that marker belongs to one producer rather than to the shape every clinical task conforms to. Read that code system for what the tag asserts, and in particular for why an ABSENT tag asserts nothing at all -- it is not a statement that the content was signed.

Handbook

Tasks is the narrative treatment: what this is for, why it is shaped this way, and how it is used. Proposals and Suggested-Resource Tasks cover the two things this profile carries beyond ordinary work. Read them before building anything that lists or displays tasks.

Nexus EMR Core Task Profile

There is deliberately one kind of work item in the chart, and this profile is it: an inbox item, a to-do, a follow-up, a colleague's question, a result that needs review. There is no separate message entity and no AI-specific inbox -- an inbox is a view over tasks, not a second model.

Forms, inbox documents and notes live in the chart as their own resources. A completed form is a QuestionnaireResponse, an arriving document is a DocumentReference, an authored note is a Composition, and a task points at one rather than containing it -- one copy, in the chart, readable by consumers that know nothing about task workflow.

The exception is content nobody has accepted yet, which is the one thing a task does contain -- see Suggested-resource tasks below.

Four independent questions

Most of the confusion this profile has caused came from reading one element to answer another's question. Four things vary independently, and every combination is legitimate:

question	element
What kind of work is it?	code	reminder, call, review-report...
Am I being asked to do it, or decide on it?	intent	order, proposal, option
Where is it in its lifecycle?	status	draft, ready, accepted...
Does it carry a suggested chart entry?	the contained Bundle	not a code at all

A review-report can be a proposal. An order can carry a suggested resource. A cancelled task can be either. Nothing here is a proxy for anything else.

What this profile guarantees

Never more than one owner, and an absent owner means something. requester is required. owner is 0..1: when it is present, responsibility has been NARROWED to that one party; when it is absent, the task is the responsibility of every user in the clinic and has not been narrowed to anyone. A task held by two parties is held by neither, which is why owner never repeats. Unassigned is not unowned -- but it is only safe if it is seen, so a consumer MUST surface unassigned tasks in every user's default inbox view rather than behind a filter or a tab. Both elements accept a Practitioner, a PractitionerRole, or a logical Device reference -- the last being how an AI-harness graph or a decision-support rule names itself as the party that raised or holds the work. owner additionally accepts a CareTeam, for pooled work held by a standing team. There is exactly one way to say "unassigned": leave owner out. Do not write a sentinel owner.

NOT YET SETTLED: whether an absent owner is permitted at all. The 0..1 cardinality is new in 1.26.0 and is under active review; 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.

The ask is stable. description is required and is the task's opening statement: what is being asked, and why the task exists. It does not change over the life of the task.

The conversation is separate from the ask. note is 0..*, typed to the Task Note profile, and every turn carries its author and time. The turns are what has been said since the task was created. A task nobody has commented on carries no note, and a writer should not copy description into note[0] to fill the thread.

Patient context is expected but not required. for is 0..1. A task created from a patient chart always sets it; a task without one is a valid standalone work item, not a malformed record.

A business identifier is recommended, not required. No canonical system is mandated -- a task born in the EMR is tracked by its server-assigned id alone. Machine-written tasks additionally carry a key under their own producer's namespace -- NamingSystem/nexus-harness-key for the AI harness, NamingSystem/nexus-cds-key for a decision-support rule -- which is what makes a re-run update its task instead of filing a second one. The namespaces are separate because a producer searches its key and updates what it finds, so a shared key space would let one producer's re-run overwrite the other's work item.

code: which bin it is filed under

code is optional and binds extensibly to the Task Codes value set: reminder, call, appointment, review-report, prevention, referral, billing, medication, other. The vocabulary is expected to grow.

It sorts tasks into bins for the people looking at them, and that is its whole job. It does not say whether the task carries a suggested resource, and it says nothing about what produced the task -- that is requester.

review-report is named for the work rather than the source on purpose. Diagnostic imaging and other non-laboratory reports arrive on the same inbound stream, so a category called lab would either exclude them or quietly redefine lab.

intent: what am I being asked to do?

intent answers one question, and a consumer branching on it should not have to look anywhere else. It binds required to three codes:

• order -- the work is authorized and assigned. The owner is expected to do it. A user sees orders in a Tasks list.
• proposal -- something is 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.
• option -- one of a set of alternatives sharing a groupIdentifier. Approving one moots the rest.

intent was previously fixed to order for every clinical task. That was accurate when a clinical task meant an inbox item, and it stopped implementers minting a scatter of intents for identical work. Carrying suggested content on the same profile made the fixed value wrong: it left "awaiting your approval" indistinguishable from "assigned to you to do". The binding is narrowed rather than reopened, so the scatter is still prevented.

For a proposal or an option, the accept/decline state is status.

intent does not say whether a task carries a suggested resource

A suggested-resource task is one carrying a contained transaction Bundle, and it can be raised at any of these three intents -- including order, where the suggested entry is already authorized and only needs recording. Read the containment, not intent.

status: where it is in its lifecycle

status binds required to the Clinical Task Statuses value set, a deliberate subset of R4's TaskStatus:

status	means
draft	being composed. In nobody's list yet
ready	actionable, in its owner's list. A CareTeam owner means it is in the pool, unclaimed
accepted	claimed by its owner, not yet started. Out of common circulation
in-progress	actively being worked
on-hold	deliberately parked: snoozed, or waiting on something outside this task
completed	the work was done
cancelled	the work will not be done

These are meanings, not a path. Any state may follow any other: ready straight to completed is an ordinary day's work, and accepted back to ready is handing something back.

Five base codes are excluded. requested was a second name for ready. received is a fulfilment-chain step this model does not have. failed is a technical outcome rather than a clinical one, and entered-in-error has no workflow here that writes it.

rejected is deliberately absent, and it is the one worth knowing. A declined proposal is cancelled, the same as one that became moot when its alternative was approved. Those are different clinical records, so statusReason is what tells them apart -- which matters more here than anywhere else on this profile.

businessStatus is not a second lifecycle

It binds extensibly to Task Business Statuses and flags the chart element a task is filed against, not the task. needs-review is deprecated and inbound-only. Workflow state belongs in status; do not carry a parallel vocabulary here.

Suggested-resource tasks

This profile also carries suggested chart entries: things somebody has to accept before they become part of the record.

Such a task is not a separate profile. It is a Task carrying its suggested resources in a contained transaction Bundle -- the same mechanism a reusable letter template uses -- rather than writing them to the chart, which is what keeps them invisible to type-level queries until someone accepts them.

The containment is what defines it. Neither code nor intent says so, and all four combinations of "carries a suggested resource" and "is a proposal" occur.

The Suggested-Resource Tasks handbook page is the full treatment: why the prototypes ride in a Bundle (dom-2 forbids a contained resource from containing anything, and Bundle is the one container exempt), the add/update/retire shapes carried by entry.request.method, the three verbs, decision-support cards, and the idempotency key.

The actions a task supports

action	changes	notes
comment	appends a note	any user; the turn carries its author and time
comment and reassign	appends a note, changes owner	reply and forward are both this
accept	status to accepted	claims it; a CareTeam owner becomes the claiming person
approve	intent to order	one-way; moves it between lists and writes nothing
instantiate	writes chart resources	fills the prototypes in and POSTs the contained Bundle
start	status to in-progress
snooze / pause	status to on-hold
complete	status to completed	optional comment
cancel	status to cancelled	optional comment; statusReason where a proposal was declined

Approve, accept and instantiate are three different acts, and conflating any two of them is the most common mistake against this profile. Approving moves a task between lists and writes nothing. Accepting claims the work. Instantiating is the one that writes to the chart.

A priority below routine

priority binds required to R4's request-priority, whose floor is routine, and the element is a bare code with no second coding slot. A profile may only strengthen a binding, so there is no way to add a lower value to the element itself.

A refinement therefore rides the priority-detail extension, currently carrying trivial. When it is present, priority shall be routine -- so a consumer that does not read the extension sorts the task as routine, which understates it rather than mis-sorting it.

Terminology bindings

Path	Strength	Value set
Task.status	required	Clinical Task Statuses
Task.businessStatus	required	Task Business Statuses (all recognised)
Task.intent	required	Clinical Task Intent Value Set
Task.priority	required	request-priority
Task.code	extensible	Task Codes