AU eRequesting Implementation Guide, published by HL7 Australia. This guide is not an authorized publication; it is the continuous build for version 1.0.1-ci-build built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/hl7au/au-fhir-erequesting/ and changes regularly. See the Directory of published versions

AU eRequesting Workflow Guidance

Page standards status: Informative

In AU eRequesting, a workflow pattern using the ServiceRequest and Task resources is used to separate the diagnostic request details from its fulfilment. The ServiceRequest represents the request initiated by placers, while the associated Task is used by fillers for tracking and communicating the progress of the request through the fulfilment workflow.

The current state of a ServiceRequest or Task resource within its defined lifecycle is represented by the code assigned to the status element of the resource. The ServiceRequest.status reflects the placer’s overall view of the diagnostic request status, whereas the Task.status tracks and conveys the filler’s fulfilment status and the progress in fulfilling the diagnostic request.

This page provides guidance on managing workflow states in AU eRequesting. It covers Task state transitions, the use of supporting elements Task.statusReason, Task.businessStatus, and ServiceRequest.extension:statusReason to provide additional workflow context, and the relationship between Task and ServiceRequest status codes.

AU eRequesting Task Status Workflow

This section describes how the AU eRequesting Task Diagnostic Request profile is used to track the fulfilment of diagnostic requests in the context of community-based care in Australia. This guidance builds on the Task state machine, where states are encoded using status codes specified in the AU eRequesting Task Status value set.

Task Status Definitions

The AU eRequesting Task Status value set specifies a constrained subset of task status codes used in the Australian eRequesting context.

Task State Transitions

The Task state (status) transitions described here reflect the lifecycle of a Task within AU eRequesting workflows for community-based pathology and imaging. These state transitions are intended to guide implementers in supporting consistent and coordinated workflow behaviour. While implementation flexibility can exist to meet business needs and constraints, supporting the suggested states and transitions will help promote interoperability and alignment across systems.

The business rules that define which actors or system roles can modify or trigger changes to Task.status are not currently considered within the scope of AU eRequesting Release 1. However, guidance on aligning ServiceRequest.status and Task.status is provided in Relationship between ServiceRequest.status and Task.status.

The table below supplements Figure 1 by providing implementation guidance for AU eRequesting workflows and listing the allowed state transitions.

AU eRequesting Task State Represented by Task.status and Allowed Transitions
State	Implementation Guidance for AU eRequesting Workflows	Allowed Transitions To State(s)
requested	Tasks start in a "requested" state, indicating a formal request for a diagnostic service that is ready to be fulfilled by a filler.	received accepted rejected cancelled
received	Indicates that the task has been acknowledged and claimed by a filler. Some workflows may not distinguish between "received" and "accepted". In such cases, implementations may transition directly from "requested" to "accepted".	accepted rejected cancelled
accepted	Indicates that a filler has agreed to perform the task.	in-progress cancelled
rejected	Indicates that the filler has declined to perform the task before beginning any work. Use the optional Task.statusReason to provide explanatory context for "rejected".	N/A (typically a terminal state)
cancelled	Indicates termination of the task before completion, usually due to an external decision or changed circumstances, rather than an error condition. Example scenarios for transitioning to "cancelled": The placer cancels the task. The task is cancelled because it has been claimed by an alternative filler. A task cannot be "cancelled" once it is "in-progress". While the intention of a cancelled task is that all work authorised by the task is expected to cease, this may not always be possible. Fulfilment activity may still proceed, and a task output may be generated, even though the task remains in a "cancelled" state. Use the optional Task.statusReason to provide explanatory context for "cancelled".	N/A (typically a terminal state)
in-progress	Once the filler initiates activity on the task, the task transitions to the "in-progress" state, indicating that work is being performed. A task cannot be cancelled once it is "in-progress".	on-hold completed failed
on-hold	Use the optional Task.statusReason to provide explanatory context for "on-hold".	in-progress
completed	Once the task has been executed, it transitions to "completed".	N/A (typically a terminal state)
failed	Indicates that task execution was attempted but could not be completed due to an error or issue. Example scenarios for transitioning to "failed": Patient did not attend. Sample was insufficient. Use the optional Task.statusReason to provide explanatory context for "failed".	N/A (typically a terminal state)

Task.status and Relationship with Task.statusReason and Task.businessStatus

• Use Task.status to represent the current state of the Task. These states are encoded with values from the AU eRequesting Task Status value set.
• Use the optional Task.statusReason to explain why the Task transitioned to states such as "rejected", "cancelled", "on-hold", or "failed", providing context for deviations from the expected workflow.
  • There is no defined value set for Task.statusReason. When used, this element is expected to carry meaningful data including a human-readable description in Task.statusReason.text.
• Use the optional Task.businessStatus to convey business-specific substates that provide additional workflow context within a Task.status.
  • For example, values assigned to Task.businessStatus such as "collected", "acquired", or "preliminary" from the AU eRequesting Task Business Status value set can indicate important workflow milestones while the Task.status remains "in-progress".
  • Since Task.businessStatus serves to augment Task.status when further categorisation is useful, Task.businessStatus may be omitted if no further categorisation is needed.
• When updating the Task.status, it is recommended to review and update the Task.statusReason and Task.businessStatus to maintain alignment. If previously set values are no longer relevant, they are expected to be cleared to avoid propagating outdated or misleading information.

The following table outlines the recommended mapping between AU eRequesting Task Business Status codes and AU eRequesting Task Status codes, indicating the relationship by which a task business status can convey a business-specific substate providing workflow context to task status. Implementers are encouraged to adopt these mappings to support interoperability, although conformance is not currently enforced. This mapping may be formalised in a future release of this IG.

Context	AU eRequesting Task Business Status codes for Task.businessStatus	AU eRequesting Task Business Status code definition	Relationship to AU eRequesting Task Status codes for Task.status
Shared (pathology and radiology)	service-booked	Service has been booked.	accepted
	request-claimed	The task has been cancelled as the request has been claimed by another filler.	cancelled
	request-cancelled-placer	The task has been cancelled as the request has been cancelled by the placer.	cancelled
	cancel-handled	Cancelled task has been handled by the filler.	cancelled
	request-data-issue	Rejected fulfilment task due to an issue with the request data.	rejected
	preliminary-results	There are preliminary results.	in-progress
	addendum-report-complete	Addendum report is complete.	completed
Pathology	specimen-collected	The specimen has been collected.	in-progress
Pathology	pathology-in-lab	Specimen is in a pathology lab.	in-progress
Radiology	image-acquired	Image acquisition complete.	in-progress

Relationship Between AU eRequesting Task Group Task.status and AU eRequesting Task Diagnostic Request Task.status

The AU eRequesting Task Group is used to represent and coordinate the overall group of requests. It allows the AU eRequesting Filler actor to manage the group as a single coordinated request, supporting fulfilment, progress tracking and status updates across the group. See Diagnostic Request Grouping guidance for more information.

It is expected that the status of the task group will reflect the most appropriate status among the individual AU eRequesting Task Diagnostic Request(s), however this is not enforced. Changes to other resources, such as ServiceRequest.status, cannot be reliably acted on by the filler unless those changes are also reflected in the status of the task group.

AU eRequesting Diagnostic Request Status

Request Status Definitions

The AU eRequesting RequestStatus value set specifies a constrained subset of ServiceRequest status codes used in the Australian eRequesting context.

Request States

In AU eRequesting workflows for community-based pathology and imaging, the state (status) of an AU eRequesting Diagnostic Request is managed by the AU eRequesting Placer actor.

The table below provides request state implementation guidance for AU eRequesting workflows.

AU eRequesting Request States Represented by ServiceRequest.status
State	Implementation Guidance for AU eRequesting Workflows
active	Diagnostic requests start in an "active" state. Indicates a formal request for a diagnostic service.
on-hold	Use the optional ServiceRequest.extension:statusReason to provide explanatory context. Given there is no defined value set for ServiceRequest.extension:statusReason, when used, include meaningful data with a human-readable description in ServiceRequest.extension:statusReason.valueCodeableConcept.text.
revoked	Indicates the diagnostic request was withdrawn or cancelled by the placer before it was fulfilled. Use the optional ServiceRequest.extension:statusReason to provide explanatory context. Given there is no defined value set for ServiceRequest.extension:statusReason, when used, include meaningful data with a human-readable description in ServiceRequest.extension:statusReason.valueCodeableConcept.text. The placer is expected to transition the corresponding task to "cancelled".
completed	Indicates the diagnostic service has been performed and task output provided. When the filler sets Task.status to "completed", the placer may update ServiceRequest.status accordingly. Alternatively, the update may occur when the expected output (e.g., results or reports) is received.
entered-in-error	Use is recommended only if no activity based on the request has occurred. Example scenarios for transitioning to "entered-in-error": Wrong patient selected during order entry. Test ordered in error. Use the optional ServiceRequest.extension:statusReason to provide explanatory context. Given there is no defined value set for ServiceRequest.extension:statusReason, when used, include meaningful data with a human-readable description in ServiceRequest.extension:statusReason.valueCodeableConcept.text. The placer is expected to transition the corresponding task to "cancelled".

Relationship Between ServiceRequest.status and ServiceRequest.extension:statusReason

• Use ServiceRequest.status to represent the current state of the AU eRequesting Diagnostic Request. These states are encoded using codes from the AU eRequesting RequestStatus value set.
• ServiceRequest.extension:statusReason provides optional explanatory context about why the request is in that particular state. It is not typically required for normal progression through the workflow (e.g. from "active" to "completed"), however it is intended to provide business-relevant context in exception scenarios, such as when a request is placed "on-hold", "revoked", or marked "entered-in-error".
  • There is no defined value set for ServiceRequest.extension:statusReason. When used, this element is expected to carry meaningful data including a human-readable description in ServiceRequest.extension:statusReason.valueCodeableConcept.text.

Relationship Between ServiceRequest.status and Task.status

• While the AU eRequesting Diagnostic Request and AU eRequesting Task Diagnostic Request are loosely coupled, in practice, changes in ServiceRequest.status are expected to be reflected in the corresponding Task.status to maintain alignment across resources involved in the workflow. Placers are responsible for managing this alignment, as changes in the diagnostic request status often require corresponding updates in fulfilment management. Failure to maintain this alignment can lead to workflow inconsistencies, such as orphaned tasks or misaligned expectations between placers and fillers.
• Some typical business rules on these status relationships are outlined in the Request States table above.

Transaction Bundle Assembly

This section describes how to package a new diagnostic request as a single FHIR transaction Bundle suitable for submission to an AU eRequesting Server. It is non-normative narrative guidance accompanying the AU eRequesting Diagnostic Request Bundle profile family.

Profile family

Profile	Use when
AU eRequesting Diagnostic Request Bundle	Abstract — defines the common shape; do not instantiate directly.
AU eRequesting Pathology Request Bundle	Submitting one or more pathology requests as a single transaction.
AU eRequesting Imaging Request Bundle	Submitting one or more imaging requests as a single transaction.

Composition

A conformant bundle must contain:

• exactly one Patient
• exactly one requesting Practitioner and one PractitionerRole
• one or two Organization entries (the placer organization is mandatory; the filler organization is optional and used for assigned requests)
• one or more ServiceRequest entries conforming to the appropriate concrete diagnostic request profile
• exactly one Task conforming to the AU eRequesting Task Group profile
• one or more Task entries conforming to the AU eRequesting Task Diagnostic Request profile — one per ServiceRequest

The bundle may also contain Encounter, Coverage, DocumentReference, CommunicationRequest, Observation, and Location resources as required by the request scenario.

Transaction semantics

• Bundle.type is fixed to transaction. The transaction is atomic — if any single entry fails server-side validation the entire transaction is rolled back.
• Every entry.fullUrl is a urn:uuid: value. The server assigns the canonical resource id when each POST succeeds; references between resources inside the bundle use the matching urn:uuid: so they resolve within the bundle.
• Workflow resources (ServiceRequest, Task, Encounter, Coverage, DocumentReference, CommunicationRequest, Observation) use POST only — they are created unconditionally as new resources.
• Actor resources (Patient, Practitioner, PractitionerRole, Organization) use plain POST by default — each submission creates a new resource. This is the simplest and most deterministic behaviour and is recommended unless there is a specific reason to reuse a server-side resource.
• Two optional patterns are available when the placer knows the actor's identifier on the target server:
  • POST with entry.request.ifNoneExist populated — conditional create. The server creates the resource only if no existing identifier match is found. The ifNoneExist query is typically an identifier search (e.g., HPI-I, HPI-O, IHI, Medicare Provider Number).
  • PUT with the search query embedded in entry.request.url (for example, Organization?identifier=...) — conditional update by identifier. The server creates if no match, updates if exactly one match.
• Caution — conditional update has cross-request effects. A PUT (conditional update) to a shared resource such as the requesting Organization modifies the stored resource in place. That change is then seen by every other diagnostic request that references that Organization, not just the request being submitted. Plain POST avoids this because it always creates a fresh resource. Choose conditional update only when updating the shared resource for all of its consumers is the intended outcome.

Example bundles

• bundle-pathology-multitest-1 — four pathology ServiceRequests for an obstetric clinic visit; all entries use plain POST (create new).
• bundle-imaging-1 — single chest X-ray imaging request; all entries use plain POST (create new).
• bundle-imaging-put-1 — the same chest X-ray request, but the Organization entries use PUT (conditional update by identifier) to demonstrate reuse of an existing shared resource and its cross-request effects.