FHIR Task vs CarePlan for Workflow Orchestration

A workflow orchestration design has to pick a primary anchor resource. In FHIR, the two natural candidates are Task and CarePlan. The two model different things in the spec, but in practice teams reach for one or the other and end up with very different runtime behavior. The comparison below covers what each anchor implies for orchestration in 2026. For broader context, see the FHIR product comparison index.

What Task Models Well

Task is the FHIR spec's representation of a single requested unit of work, with status, owner, requester, partOf, and outcome. It is event-shaped: a Task is created, transitions through statuses, and eventually completes or terminates. The lifecycle maps cleanly to the way orchestration engines think about steps, which is why Task-anchored orchestration is the default in most FHIR-native workflow engines.

Where Task shines is the granularity. Each clinical step is its own resource, with its own audit trail, its own ownership, and its own search surface. Coordinators can list every Task assigned to a worker, every Task partOf a parent process, every Task in status `requested` over a time window. The Task resource tools roundup covers the implementations that handle this surface well.

Where Task falls short is the longer arc. Task does not model "a six-week post-discharge follow-up plan" cleanly. It models the next step in that plan. Modeling the whole plan as a single Task collapses information the rest of the system needs.

What CarePlan Models Well

CarePlan is the spec's representation of a longer-running intent: the goals, the activities, the schedule, the responsible parties, and the context the plan was created in. CarePlan-anchored orchestration treats the plan as the durable state and the Tasks (or activities) as the operational projection of that plan.

The win is that the plan survives reorganization of the steps. Adding, removing, or rescheduling a step does not invalidate the plan; it updates the plan's activity list. Care managers reason about CarePlan; ops teams reason about Task transitions.

The loss is that CarePlan was not designed as a workflow execution substrate. Status transitions on activities are looser than on Task. Many engines model CarePlan well for read but punt the execution surface to Task underneath, which means teams end up with both anyway.

How to Pick the Anchor in Practice

Three questions decide the anchor. The first is the time horizon. Short-lived workflows that wrap a handful of clinical steps fit Task-anchored designs. Multi-week or multi-month care arcs fit CarePlan-anchored designs with Task as the operational projection.

The second is the audience. Engineering teams orchestrating internal work pick Task. Care management teams reasoning about patient programs pick CarePlan. Teams serving both audiences usually keep both in the model and accept the integration cost.

The third is the BPM question. Workflows complex enough to need a BPMN engine almost always land in Task at the FHIR layer, because BPMN's user-task primitive maps to Task, not to CarePlan. The FHIR BPM tools roundup covers this pairing in detail.

The right anchor depends less on which resource is "better" and more on what part of the clinical arc the orchestration layer is actually responsible for. Most stacks running both end up healthier than stacks that committed to one and tried to make it cover both surfaces.