AU eRequesting Implementation Guide
1.0.0-ballot - Ballot
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-ballot 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
Official URL: http://hl7.org.au/fhir/ereq/ImplementationGuide/hl7.fhir.au.ereq | Version: 1.0.0-ballot | |||
IG Standards status: Draft | Maturity Level: 1 | Computable Name: AUeRequestingImplementationGuide | ||
Copyright/Legal: Used by permission of HL7 International, all rights reserved Creative Commons License. HL7 Australia© 2024+; Licensed Under Creative Commons No Rights Reserved. |
This ballot is opened during this cycle to solicit feedback and approval from the wider community. Feedback provided during the balloting process will be reconciled by the AU eRequesting Technical Design Group.
Key updates and changes in this version are shown in the AU eRequesting Change Log.
The ballot period is 11 August 2025 to 07 September 2025.
Information on how to provide feedback for balloters is available on this Confluence page: Guidance: Ballot Voting.
AU eRequesting is provided to support the use of HL7® FHIR®© for diagnostic requesting in an Australian context. It sets the minimum expectations on FHIR resources to support conformance and implementation in systems.
AU eRequesting defines the data model and RESTful API interactions that set minimum expectations for placing and accessing electronic requests.
The focus of AU eRequesting Release 1 (R1) is to support pathology and medical imaging requests in community-based care, while also considering future applications beyond this scope.
This implementation guide is under development through the AU eRequesting project as part of the Sparked AU FHIR Accelerator. The Sparked AU FHIR Accelerator is a collaborative community of government, technology vendors, provider organisations, peak bodies, practitioners, and domain experts, working together to accelerate the creation and use of national FHIR standards for health information exchange.
The Sparked AU FHIR Accelerator includes:
The Australian eRequesting Data for Interoperability (AUeReqDI) is focused on an agreement of the minimum data required to support standardised eRequesting within the Australian health context, and forms a common language foundation that allows systems to exchange semantically accurate data for eRequests. AUeReqDI outputs form a set of data requirements to be considered and referred to as part of the development and definition of AU eRequesting.
The scope of AU eRequesting Release 1 is the support of pathology and medical imaging requests in community-based care provision.
The following diagnostic request scenarios are in scope for Release 1:
See AU eRequesting Use Cases for complete use case descriptions.
The following diagnostic request scenarios are outside the scope of Release 1:
As Release 1 focuses on defining a foundational FHIR data model and RESTful API interactions, several technical aspects are intentionally out of scope. This approach supports alignment and adoption by emerging diagnostic requesting solutions, while maintaining flexibility to respond to evolving national policy directions and infrastructure considerations in future releases or downstream implementation guides.
The following technical aspects were not considered priority for the scope of Release 1:
Package hl7.fhir.uv.extensions.r4#5.2.0 This IG defines the global extensions - the ones defined for everyone. These extensions are always in scope wherever FHIR is being used (built Mon, Feb 10, 2025 21:45+1100+11:00) |
Package hl7.fhir.au.base#6.0.0-ballot This implementation guide is provided to support the use of FHIR®© in an Australian context. (built Wed, Jul 30, 2025 04:56+0000+00:00) |
Package hl7.fhir.uv.extensions.r4#1.0.0 This IG defines the global extensions - the ones defined for everyone. These extensions are always in scope wherever FHIR is being used (built Sun, Mar 26, 2023 08:46+1100+11:00) |
Package hl7.fhir.uv.ipa#1.1.0 This IG describes how an application acting on behalf of a patient can access information about the patient from an clinical records system using a FHIR based API. The clinical records system may be supporting a clinical care provider (e.g. a hospital, or a general practitioner), or a health data exchange, including a national health record system. (built Wed, Mar 19, 2025 14:34+0000+00:00) |
Package hl7.fhir.au.core#2.0.0-ballot This implementation guide is provided to support the use of FHIR®© in an Australian context, and defines the minimum set of constraints on the FHIR resources to create the AU Core profiles. This implementation guide forms the foundation to build future AU Realm FHIR implementation guides and its content will continue to grow to meet the needs of AU implementers. (built Thu, Jul 31, 2025 00:07+0000+00:00) |
Package hl7.fhir.uv.extensions.r4#5.1.0 This IG defines the global extensions - the ones defined for everyone. These extensions are always in scope wherever FHIR is being used (built Sat, Apr 27, 2024 18:39+1000+10:00) |
AU eRequesting defines four system actors involved in the exchange of diagnostic requests: the AU eRequesting Placer, Filler, Patient and Server actors. The Actors and Capabilities page provides a summary of these actors and includes links to their definitions and CapabilityStatements. Each capability statement outlines the RESTful interactions supported by that actor, including create
, update
, read
and search
operations.
Figure 1 shows typical FHIR RESTful interactions between these AU eRequesting actors:
Figure 1: Typical FHIR RESTful interactions between AU eRequesting actors
Figure 2 shows an example of FHIR interactions between AU eRequesting actors, and demonstrates the use of ServiceRequest and Task to support the placement and tracking of pathology and imaging requests. While the diagram focuses on these coordinating resources, the associated exchange also includes other FHIR resources (e.g. Patient) that provide clinical, administrative and contextual information. The full set of profiles used to support the requests is provided on the Profiles and Extensions page.
Figure 2: Example AU eRequesting interaction flow
The steps illustrated in Figure 2 are summarised below:
This guide is divided into several pages which are listed at the top of each page in the menu bar.
This guide is the product of collaborative work undertaken with participants from:
Primary Editors: Brett Esler, Jaymee Murdoch, Michael Osborne.