T.3 Workflow Transaction and Routing Terminology

These terms distinguish communication and exchange from the work requested and the activities performed. Message, Transaction, Task, and Activity Lifecycles have separate boundaries. Document Lifecycle and Document Status are defined in T.2.

Term	Meaning and use
Message Lifecycle	The progression of a Direct message from creation and submission through transport to delivery or a terminal delivery failure under the applicable transport requirements. Each message, including a Workflow Status report, has its own Message Lifecycle. Successful delivery does not establish acceptance of the structured payload or completion of requested work.
Transaction	A defined unit of exchange between technical actors, governed by the applicable Transaction Definition. A transaction may involve an initiating Direct message, receiving-workflow processing, and correlated Workflow Status reports.
Transaction Lifecycle	The progression of a transaction from initiation to acceptance or rejection of the entire structured payload into the intended receiving workflow. The originating system also closes its tracking context as outcome unconfirmed and requiring follow-up when no correlated report arrives within the applicable interval. Timeout closure does not establish acceptance or rejection. TX8 is a separate subsequent transaction reporting the originating disposition; the lifecycle does not extend through completion of the requested clinical Task.
Task	A requested unit of work with an intended outcome, responsibility, and a state that can be tracked. A Task may require multiple Activities to achieve its outcome. The Workflow Activity Task carried in the structured payload represents the requested Shared Activity under the applicable transaction requirements.
Task Lifecycle	The progression of a Task from creation or request through decisions about execution, performance, and a terminal outcome such as completion, rejection, cancellation, or failure, as defined by the applicable workflow and resource specification. Acceptance of the structured payload into a workflow does not by itself establish acceptance of the Task for execution or completion of the Task.
Activity	Activities, which also can be called services, actually performed or attempted by a person, organization, or system. Activities may be planned before execution. A Task may require several sequential or concurrent Activities, including repeated attempts. Finishing an individual Activity does not necessarily fulfill the Task.
Activity Lifecycle	The progression of an operational Activity/Service through planning, initiation, performance, and conclusion, as applicable to the work. Its conclusion may represent successful performance, an unsuccessful attempt, or another terminal outcome. These are conceptual stages rather than a new set of status codes.
Provenance Activity	A specific kind of activity affecting data provenance that has occurred and is described in a provenance assertion, including who or what participated, when it occurred, and which information objects were used or generated, where applicable. In this guide, Provenance Activities are not tracked as having a lifecycle status; they are recorded retrospectively at the point of completion. See Chapter 3, Section 3.10 for Provenance fundamentals, the activity inventory, and agent participation types.
Routing Target	The Direct address selected for the current transaction’s message under the applicable routing rules. A Routing Target may be separate and distinct from the Intended Recipient, or they may coincide. It may identify an organizational endpoint or an intermediary and does not by itself establish acceptance authority. For TX8, the Routing Target(s) are always the specified Workflow Status Update Endpoint(s).
Delivery Notification	A transport-level notification about a Direct message’s delivery or disposition under the applicable transport requirements. Its meaning is determined by the notification type and specification; it does not substitute for a Workflow Status report.
Designated Notification Recipient	The endpoint designated to receive transport-level Message Disposition Notifications (MDNs), carried in the Direct message Disposition-Notification-To header. It is distinct from a Workflow Status Update Endpoint.
Workflow Status Update Endpoint	A pre-established Direct endpoint designated to receive a TX8 Workflow Status Report for the originating Transaction Instance. One or more endpoints are carried in the originating Workflow Activity Task. Subsequent Sender Actors preserve the existing endpoints; an intermediary may add its own. TX8 is sent to each unique accumulated endpoint, which specifies a Routing Target for that report.
Transport Disposition	The transport-level outcome for a particular Direct message, interpreted under the applicable transport specification. It describes delivery or delivery failure and does not establish the receiving workflow’s acceptance or rejection of the structured payload.
Workflow Status	Acceptance or rejection of the entire structured payload into the intended receiving workflow. It does not establish acceptance of a Task for execution, completion of subsequent processing, or the clinical or authoring status of an included document.
Workflow Status Report	The communication of a correlated Workflow Status through TX8 under the applicable requirements. Reports are sent to all specified Workflow Status Update Endpoints. A report communicates the structured payload acceptance or rejection decision; it is distinct from a transport delivery notification and from Task Status or Activity Status.
Structured Payload Disposition	The transaction-level outcome for a particular Direct message, interpreted under the applicable use case definition for the transaction. It describes acceptance or rejection of the structured payload into the intended receiving workflow.
Task Status	The task-level status which is defined for the use case. Communicated separately from Workflow status.
Activity Status	The activity-level status which is defined for the task within the context of the use case. Communicated separately from Workflow Status.

These lifecycle definitions describe conceptual boundaries. Implementations use the states, codes, and transition rules established by the applicable specifications. A transaction is a unit of exchange, while a FHIR Collection Bundle is a packaging construct; it does not imply a FHIR transaction Bundle.

The originating Transaction context concludes when the authorized Receiver Actor accepts or rejects the entire structured payload into the intended workflow. TX8 is a separate, subsequent Transaction Instance that reports that established disposition. Receipt of TX8 confirms the outcome to its recipients; it does not determine when the originating transaction concluded. Acceptance does not establish completion of subsequent clinical processing or service fulfillment.

If no correlated TX8 is received within the applicable reporting interval, the originating system SHALL close its transaction tracking context with the outcome unconfirmed and mark it as requiring follow-up. This administrative closure does not establish acceptance, rejection, or non-receipt and does not cancel required reporting. A late TX8 SHALL be correlated to the original transaction and used to resolve its recorded unconfirmed outcome; it SHALL NOT create a new originating Transaction Instance or erase the timeout and follow-up history.

A birth referral illustrates the distinction. The referral transaction concludes when the receiving workflow accepts or rejects its structured payload. TX8 subsequently reports that disposition. If the originating system receives no correlated report within the applicable interval, it closes its tracking context as outcome unconfirmed and requiring follow-up. The Task to fulfill an accepted referral may remain open while the care team performs several Activities. Provenance can record those Activities after they occur. The referral document retains its separate Document Lifecycle throughout these exchanges.

A provenance assertion may be corrected or superseded. That concerns management of the assertion as an information object rather than a prospective lifecycle for the Provenance Activity it describes.