AU eRequesting Implementation Guide
1.0.0-ci-build - CI Build Australia flag

AU eRequesting Implementation Guide, published by HL7 Australia. This guide is not an authorized publication; it is the continuous build for version 1.0.0-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

General Guidance

Page standards status: Informative

SNOMED CT Australian (SNOMED CT-AU) Edition

For guidance on SNOMED CT-AU in FHIR, see the guidance defined in AU Base SNOMED CT Australian Edition.

Diagnostic Request Grouping

In AU eRequesting, grouping is applied to requests created by an AU eRequesting Placer actor. This reflects common patterns in Australia where multiple related pathology tests or imaging exams are requested in a single event.

AU eRequesting follows the shared requisition id approach from the FHIR Request pattern, where multiple request resources created as part of the same ordering event share a common identifier. The Placer Group Number (PGN) is the common identifier assigned by the AU eRequesting Placer actor at the time of request creation and is recorded in either the requisition or groupIdentifier elements of resources in the group.

A single 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.

Each individual requested test or exam in the group is represented using an AU eRequesting Diagnostic Request, and each individual communication request is represented using an AU eRequesting CommunicationRequest. These individual requests are paired with a corresponding Task to track the fulfilment of that request.

Each request will also include supporting clinical, administrative and contextual information represented using other FHIR resources (e.g. Patient). These resources form part of the overall request and may be shared across the group or be specific to individual requests. The full set of AU eRequesting profiles used to support the request is listed on the Profiles and Extensions page.

AU eRequesting example request group

Figure 1: AU eRequesting example request group

Request Group Guidance

  • A task group:
    • Is used to manage the group as a single coordinated request and is implemented using AU eRequesting Task Group
    • SHALL always be created, including when there is only a single request for a test or exam. This ensures consistent implementation and uniform processing by the AU eRequesting Filler actor.
    • Is assigned the Placer Group Number (PGN) in Task.groupIdentifier by the AU eRequesting Placer actor to logically associate all requests in the order
    • Is identified by the Task.meta.tag of “fulfilment-task-group”
  • Each task request in the group:
  • Each diagnostic request in the group:
    • Represents a request for a single test or exam and is implemented using the relevant ServiceRequest profile:
    • Is assigned the Placer Group Number (PGN) in ServiceRequest.requisition
    • Is assigned an optional ServiceRequest.displaySequence that reflects the visual order or sequence of diagnostic requests within the group as they appear on a paper request form
  • Each communication request in the group:

Implementation Considerations

This section highlights aspects for implementers to consider when designing and developing AU eRequesting solutions.

Human-Readable Narrative

It is recommended that FHIR resources exchanged as part of AU eRequesting include a human-readable narrative in the text element, consistent with the FHIR DomainResource specification. When narrative is absent, a system that cannot fully interpret the structured content may misrepresent or omit the clinical intent, creating clinical safety risks. Narrative ensures that the clinical meaning is available to receiving systems, regardless of whether they process the structured content, supporting the safe and progressive adoption of structured data.

Transaction Bundles

In AU eRequesting, an order typically involves multiple related FHIR resources. To help ensure consistent linkage and referential integrity across these related resources, AU eRequesting Placer actors could consider using a FHIR Bundle of type transaction to create the resources on the server as part of a single atomic transaction. This means all resources in the request are either created successfully or rejected together, which aligns with FHIR transaction processing rules and the FHIR Request pattern.

If a transaction Bundle is not used, the sequence in which resources are created to satisfy dependencies and uphold referential integrity needs to be carefully considered. This consideration is particularly important for the AU eRequesting Task Group, which serves as the entry point for AU eRequesting Filler actors to find and manage fulfilment tasks for the same request.

Workflow Event Tracking

AU eRequesting Placer, Filler, and Patient actors are likely to need to discover and monitor changes to key resources throughout the diagnostic request and fulfilment lifecycle. See the AU eRequesting Workflow Guidance page.

FHIR provides mechanisms that enable client systems to monitor resource changes and can be used track the status and progression of requests through the fulfilment workflow. These include:

  • Polling: clients periodically query the server using search parameters to find and track updates.
  • Subscriptions: clients register a Subscription to receive notifications when resources matching specific criteria are created or updated, using the FHIR Subscriptions framework.

References

FHIR defines several types of references, including literal, logical, and contained references. The characteristics and implications of these reference types are described in the FHIR Resource References page.

AU eRequesting Release 1 does not constrain the choice of reference type, and implementers should be aware of the implications of the different approaches within their implementation context.

Re-use of Referenced Resources

Some referenced resources, such as Patient, PractitionerRole, Practitioner, and Organization, may be used more broadly than the context of a single ordering event. They may be created for the context of a request, managed for reuse within an organisation, or shared across systems. The way these resources are created or reused has implications for how they are used across implementations. Key aspects to consider are:

  • Ownership: which system is responsible for creating and maintaining the resource
  • Scope: whether the resource is managed for a request, within an organisation, or across systems
  • Updates: how changes to the resource are managed and how those changes affect requests that already reference it