Clinical Tasks: the idea

An EMR is a living list of work that passes from person to person. ClinicalTask is how Nexus EMR represents that work: who asked, who holds it now, what has been said about it, and which chart element it concerns.

This page is the model in one read. Clinical Task Design is the detail.

One rail

There is one kind of work item in the chart. An AI suggestion, a decision-support recommendation, an incoming result that needs review, a colleague's question, a note that needs signing — all of them are a Task, with the same lifecycle, the same ownership rule, and the same audit trail.

There is no separate message entity, no notification type, and no AI-specific inbox. An inbox is a view over tasks, not a store and not a second model. If you are building a worklist, a chart sidebar, or a suggestion panel, you are querying Task with different filters.

The alternative — a resource per surface — is how work goes missing between systems, and how two teams end up building two half-models of the same thing.

Ownership is narrowing

Not yet settled: whether an absent owner is permitted at all

This is under active review and may change. Permitting an absent owner is new in 1.26.0. The competing position -- every task names an owner when it is written, with a configured default where the producer has nobody to name -- is held by product and 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. See Ownership.

owner is 0..1. Never many, and its absence means something specific.

An absent owner means the task is the responsibility of every user in the clinic. Not nobody's, and not unknown. Work arrives unassigned — an incoming result, a fax nobody has triaged, a task a third-party integration wrote without naming anyone — and until somebody narrows it, the clinic holds it collectively.

A present owner means responsibility has been narrowed to one named party: a practitioner, a practitioner role, a CareTeam, or a Device meaning an AI agent. Assignment is that act of narrowing. A task starts as everyone's and becomes someone's.

Unassigned work must be visible without going to look

An absent owner is only "everyone's" if everyone can see it. A system implementing this profile MUST surface unassigned tasks in the default inbox view of every user — present by default, not behind a filter, a tab the reader has to select, or a saved search, and counted wherever outstanding work is counted.

This is part of what the element means, not a UI preference. Without it, an absent owner is just work that exists, that no worklist shows, and that nobody is looking for.

A task held by two people is held by neither, so owner never repeats. A team can hold a task: the one-owner rule is about the cardinality, not the target type — owner is still exactly one reference when it names the nursing pool, and "the nursing pool has this" is a true statement about who holds the work. A member claims it by becoming the owner, which is a real transfer with real Provenance.

There is one spelling of unassigned: the absent element. Do not invent a sentinel owner to keep the field populated — a per-tenant "unassigned" CareTeam, or an Organization standing for the practice. A sentinel reads as narrowed to every consumer that checks whether owner is set, which makes un-narrowed work indistinguishable from work a team is actually holding.

Work moves by reassignment, and each move is recorded as Provenance in relevantHistory whether or not anyone chose to comment on it. This is what makes "who had it, and when" answerable a year later.

The task is the conversation

The ask is description — required, written by whoever created the task, and stable for the life of it. That is the reason the task exists, and it is one field, in one place.

Task.note carries the exchange that follows, oldest first, each turn with its own author and time. It is 0..*: the turns are what has been said since the task was created — the question that came with a forward, the answer that came back, the reason it went on hold. A task nobody has commented on yet has no notes at all, which is the ordinary state of new work rather than a malformed record. Do not copy description into note[0] to fill the thread; that says the same thing twice and opens the conversation with something nobody said.

A task handed to you is only intelligible if the conversation travels with it, which is why the turns live on the task rather than in a separate resource. Notes are what people said; relevantHistory is what happened. Both matter, and they are kept apart on purpose.

Machines are participants, not a special case

An AI agent creates tasks, holds tasks, and writes turns using the same elements a person does. It is named by a logical Device reference — an identifier under the nexus-harness-graph naming system — with no Device resource to register or fetch, because an agent is a running graph rather than a piece of equipment.

Two consequences worth knowing before you build against this:

• intent separates work from proposals. #order means authorized work, assigned — "this is mine to do." #proposal means machine output awaiting a human decision — "this is mine to decide." A consumer that ignores intent will present unapproved machine output as though a human had assigned it. That is the failure this element exists to prevent.
• A proposal is not in the chart yet. The suggested resource is contained in its review task, so a search for MedicationRequest does not return un-approved suggested medications. Nothing has to remember to filter them out. Acceptance lifts the payload into the chart; rejection keeps both the task and what was declined, because that is part of the record too.

Handing a task to an agent moves ownership, not accountability.

Where to go next

• Conversation Threading — the one mechanism behind a colleague's question, an accepted suggestion, and a back-and-forth with an agent.
• Clinical Task Design — the profile, the state machine, ownership transfer, agent identity in all three positions it appears, and how tasks, the inbox and the AI harness fit together.
• Task Profile — the normative element definitions and invariants.