CH UMZH Connect IG (R4), published by UMZH. This guide is not an authorized publication; it is the continuous build for version 1.0.0-cibuild built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/umzhconnect/umzhconnect-ig/ and changes regularly. See the Directory of published versions

Workflow States

Task Workflow States

The CoordinationTask lifecycle is governed by two complementary fields:

• Task.status — the FHIR base state machine (Task state machine); reflects the overall lifecycle of the task
• Task.businessStatus — a domain-specific qualifier that sits alongside Task.status to convey sub-states meaningful to the workflow; codes are drawn from COW business status codes

This IG follows the COW Workflow State Overview with the constraints documented below. Note that COW's received state is intentionally omitted in this version of the IG: a Task transitions directly from requested to accepted or in-progress.

Rules:

• Only the Fulfiller may change Task.status — it is not patchable by the Placer (see Workflow oriented API design)
• The Placer may only PATCH the Task when Task.owner references the Placer organization
• The Placer may only PATCH the fields: owner, businessStatus, input, and focus
• Task.businessStatus must only contain domain-specific workflow codes; Task.status codes must never be used as businessStatus values
• Cancellation by the Placer is not foreseen in this version of the IG
• Negative terminal states use base-FHIR rejected (Fulfiller declines before starting) and failed (accepted but not completed) rather than COW's cancelled + statusReason; COW's cancelled ("not selected") pattern assumes a multi-Fulfiller selection flow that is out of scope here

State Diagram

stateDiagram-v2
    direction LR

    [*] --> requested : Placer POSTs Task to Fulfiller

    requested --> in_progress   : Fulfiller accepts & starts
    requested --> accepted      : Fulfiller explicitly accepts\n(request-with-acceptance pattern)
    requested --> rejected      : Fulfiller declines

    accepted  --> in_progress   : Fulfiller starts work

    state "in-progress\n[awaiting-information]" as awaiting
    in_progress --> awaiting    : Fulfiller needs more info\n(owner → Placer)
    awaiting    --> in_progress : Placer provides info\n(owner → Fulfiller)

    in_progress --> completed   : Fulfiller completes
    in_progress --> failed      : Fulfiller unable to complete

    completed --> [*]
    rejected  --> [*]
    failed    --> [*]

State Transition Table