AU Core R2 and AU eRequesting: Implementing FHIR for Australian diagnostic workflows

Direct answer

AU Core R2 (published 28 January 2026) is Australia's FHIR API baseline. AU eRequesting R1 covers community pathology and radiology requesting. Hybrid HL7 v2 plus FHIR still carries orders and results.

Sparked, AU Core R2, and the canonical URL to pin

Sparked is Australia's FHIR accelerator (Department of Health and Aged Care, Australian Digital Health Agency, CSIRO and HL7 Australia). It produces two complementary artefacts: clinician-agreed data requirements (AUCDI) and HL7 Australia FHIR implementation guides.

AU Core Implementation Guide 2.0.0 (R2) is the Working Standard published on 28 January 2026. Official URL: http://hl7.org.au/fhir/core/ImplementationGuide/hl7.fhir.au.core. Published home: https://hl7.org.au/fhir/core/. Package: hl7.fhir.au.core#2.0.0 on FHIR R4.0.1. It depends on AU Base 6.0.0.

AU Core sets minimum expectations to record, update, search and retrieve core administrative and clinical information. It is a national core in the same sense as US Core: profile-only support is not the same as profile support plus the documented RESTful interactions. Read the IG's conformance pages before you claim "AU Core" in a tender.

The identifier that is not an MRN: Australian IHI

Australian Patient resources that leave the hospital need the Individual Healthcare Identifier assigned under the Healthcare Identifiers Service. AU Base profiles it as AU IHI (http://hl7.org.au/fhir/StructureDefinition/au-ihi). The identifier system is fixed:

http://ns.electronichealth.net.au/id/hi/ihi/1.0

The IG's example value is 8003608833357361. That is a specification example, not a person. Do not publish a real IHI. Sixteen digits, NI identifier type, and the AU IHI invariants (including checksum rules in AU Base) belong in your Patient mapper before you argue about Observation codes.

{
  "resourceType": "Patient",
  "meta": {
    "profile": ["http://hl7.org.au/fhir/core/StructureDefinition/au-core-patient"]
  },
  "identifier": [
    {
      "type": {
        "coding": [
          {
            "system": "http://terminology.hl7.org/CodeSystem/v2-0203",
            "code": "NI"
          }
        ]
      },
      "system": "http://ns.electronichealth.net.au/id/hi/ihi/1.0",
      "value": "8003608833357361"
    }
  ]
}

Local MRNs still exist. They do not replace IHI when the receiver is a national or cross-organisation Australian FHIR endpoint.

AUCDI vs AU Core vs AU eRequesting

These three names are used interchangeably in vendor decks. They are not the same layer.

Official URL for AU eRequesting: http://hl7.org.au/fhir/ereq/ImplementationGuide/hl7.fhir.au.ereq. Sparked describes R1 as the first release of the AU eRequesting FHIR IG, focused on pathology and medical imaging requests in community-based care.

AUeReqDI (Australian eRequesting Data for Interoperability) is the clinical-data sibling of AUCDI for requesting. Map AUeReqDI groups into AU eRequesting profiles; do not treat AUCDI R2 as a requesting specification.

AU eRequesting R1: pathology and radiology in community care

AU eRequesting R1 is the first complete Australian FHIR standard for diagnostic requesting in that community scope. In-scope scenarios in the IG include:

• Pathology and medical imaging requests from community clinicians to private, public-hospital and interstate diagnostic providers
• Assigned and unassigned requests (patient choice)
• Outpatient-to-community requesting
• Fulfilment tracking of request status

Explicitly out of scope for R1: diagnostic reports, inpatient and inter-hospital workflows, sendaway specimens, specimen collection, appointment booking, authentication/authorisation, barcodes/QR, provider discovery, and claiming of requests by fillers.

That split matters if you already run HL7 v2 ORM/ORU. eRequesting replaces the request side in FHIR (ServiceRequest plus Task grouping). The report side is still a different contract — often still ORU / DiagnosticReport on a hybrid engine. The radiology and lab workflow guide is the place to keep accession, filler-order and patient IDs aligned when the request is FHIR and the result is not.

Why hybrid HL7 v2 plus FHIR still matters in Australia

Search demand on this site for HL7 v2 migration is already coming from Australia. That is a signal about the installed base, not a traffic trophy: Australian hospitals and diagnostic providers still fire ORM and ORU over MLLP, and AU Core plus AU eRequesting do not switch those feeds off.

The practical architecture is the same hybrid I describe in the HL7 v2 to FHIR migration playbook: keep v2 as the nervous system, project AU Core resources for new consumers, and introduce AU eRequesting only on the requesting path that the IG actually covers. Validate the FHIR side against AU Core R2 and AU eRequesting R1, not against unconstrained R4 Patient and ServiceRequest.

Do not rip out v2 because a slide says “Australia is on FHIR”. Pin hl7.fhir.au.core#2.0.0, map IHI, and keep a tested rollback on the v2 writer.

What this is not

This article is not an AU Core or AU eRequesting conformance certificate, not Sparked membership, and not legal advice. Publishing AU Core profiles in a CapabilityStatement does not mean the Australian Digital Health Agency, HL7 Australia or a jurisdiction has assured your product. IHI use is regulated; this page does not authorise you to call the HI Service. Nothing here is clinical advice about which test or image to request.

Implement next

1. Pin AU Core 2.0.0 and AU eRequesting 1.0.x in your package lock; re-validate when Sparked publishes the next sequence.
2. Put IHI on Patient before you map Pathology Request or Imaging Request.
3. Keep v2 ORM/ORU for in-scope hospital results until a report IG is the actual contract.
4. If you need the mapping and engine work, that is HL7 FHIR integration.