Task — Operational FHIR activity

Where ServiceRequest says what, Task says where we are: received, accepted, in progress, completed. The operational workflow pivot.

Purpose

Task describes an activity to perform or being performed: process a request, deliver a medication, get a prescription approved, run a questionnaire. Where ServiceRequest carries the request, Task carries the operational follow-up: who executes, when, in what state, with what inputs and outputs.

Common pattern: a clinician creates a ServiceRequest; a Task with focus = ServiceRequest/... is created to notify the laboratory it must fulfill it. The lab advances the Task through received → accepted → in-progress → completed.

Key fields

Statuses and transitions

The canonical state diagram: draft → requested → received → accepted or rejected. An accepted task goes ready → in-progress → completed on success, or failed / cancelled. on-hold is reversible.

JSON example

A fulfill Task for a CBC order, assigned to the central lab:

{
  "resourceType": "Task",
  "id": "fulfill-labtest-001",
  "status": "in-progress",
  "intent": "order",
  "priority": "routine",
  "code": {
    "coding": [{
      "system": "http://hl7.org/fhir/CodeSystem/task-code",
      "code": "fulfill",
      "display": "Fulfill the focal request"
    }]
  },
  "description": "Fulfill CBC order for Mr. Doe",
  "focus": { "reference": "ServiceRequest/sr-cbc-001" },
  "for": { "reference": "Patient/doe-john" },
  "encounter": { "reference": "Encounter/enc-2026-05-15" },
  "executionPeriod": {
    "start": "2026-05-15T08:30:00+02:00"
  },
  "authoredOn": "2026-05-15T08:25:00+02:00",
  "lastModified": "2026-05-15T09:10:00+02:00",
  "requester": { "reference": "Practitioner/dr-smith" },
  "owner": { "reference": "Organization/lab-central" },
  "businessStatus": {
    "coding": [{
      "system": "http://example.org/CodeSystem/lab-status",
      "code": "in-analyzer"
    }]
  },
  "input": [{
    "type": { "text": "Specimen" },
    "valueReference": { "reference": "Specimen/spec-001" }
  }]
}

Common pitfalls

• Confusing Task with ServiceRequest — ServiceRequest = the request, Task = the execution follow-up. A ServiceRequest can spawn multiple Tasks (per step, per executor).
• Invalid status transition — going from completed to in-progress isn't allowed without flipping through entered-in-error.
• Missing owner — without an owner, the task is orphaned: no worklist will surface it.
• Confusing requestedPeriod with executionPeriod — the former is planned, the latter actual. Mixing them up skews delay KPIs.
• Polling instead of Subscription — for active task lists, a Subscription on Task?owner=...&status=ready,in-progress beats polling load.

Related resources

• ServiceRequest — the request Task fulfills.
• MedicationRequest — Task fulfill in hospital pharmacy.
• Questionnaire — Task asking the patient to fill out a form.
• TaskList — task container (Bundle or Composition).
• Provenance — traceability for status changes.