Introduction to Australian FHIR Implementation Guides
Australian FHIR Implementation Guides (IGs) define the local constraints, extensions, and usage requirements for implementing FHIR in the Australian healthcare context. These IGs ensure consistent, interoperable health data exchange across the nation.
Implementation Guides are developed through the Sparked FHIR Accelerator program using the Australian FHIR Community Process (AFCP), ensuring broad stakeholder input and consensus-based standards.
IG Hierarchy
Australian IGs follow a layered approach: AU Base provides the foundation, AU Core defines the minimum dataset for interoperability, and domain-specific IGs (eRequesting, Patient Summary) address particular use cases.
- AU Base: Australian constraints on international FHIR R4
- AU Core: Minimum dataset for clinical interoperability
- AU eRequesting: Pathology and diagnostic imaging requests
- AU Patient Summary: Care transition documentation
- AU Medication: Medication management workflows
AU Base: Australian Foundation Profiles
AU Base defines Australian-specific constraints, extensions, and terminology bindings on top of the international FHIR R4 standard. It serves as the foundation for all other Australian FHIR profiles.
Key Features of AU Base
- Australian address formats (state codes, postal formats)
- Australian name conventions and title codes
- Indigenous status extension with Australian code set
- Country of birth extension with ISO 3166 bindings
- Healthcare identifier support (IHI, HPI-I, HPI-O, HPI-A)
- Australian telephone number formats
- Medicare number and DVA number identifier systems
AU Base Extensions
Common AU Base extensions
| Extension | URL | Purpose |
|---|---|---|
| Indigenous Status | http://hl7.org.au/fhir/StructureDefinition/indigenous-status | Record Aboriginal and Torres Strait Islander origin |
| Country of Birth | http://hl7.org.au/fhir/StructureDefinition/country-of-birth | Record patient birth country using ISO 3166 |
| Australian Postal Code | http://hl7.org.au/fhir/StructureDefinition/au-postal-code | Validate Australian postal code format |
| Name Qualifier | http://hl7.org.au/fhir/StructureDefinition/name-qualifier | Record Australian name qualifiers (e.g., AM, OAM) |
| Indigenous Language | http://hl7.org.au/fhir/StructureDefinition/indigenous-language | Record preferred Indigenous language |
AU Base Patient Profile Example
AU Base Patient Resource
Structured JSON example rendered with depth controls for easier inspection.
Click on an annotation to highlight it in the JSON
Base vs Core
AU Base defines what Australian FHIR resources look like. AU Core defines which resources and elements must be supported for interoperability. Think of AU Base as the "dictionary" and AU Core as the "required vocabulary".
AU Core: Minimum Interoperability Dataset
AU Core defines the minimum set of FHIR resources, elements, and search parameters required for basic clinical interoperability in Australia. It is aligned with AUCDI (Australian Core Data for Interoperability) requirements.
AU Core Resources
AU Core required resources
| Resource | AU Core Profile | Purpose |
|---|---|---|
| Patient | au-core-patient | Patient demographics and identifiers |
| Practitioner | au-core-practitioner | Healthcare provider information |
| Organization | au-core-organization | Healthcare organization details |
| Observation | au-core-observation | Vital signs, lab results, clinical measurements |
| Condition | au-core-condition | Problems, diagnoses, health concerns |
| MedicationRequest | au-core-medicationrequest | Medication orders and prescriptions |
| AllergyIntolerance | au-core-allergyintolerance | Allergy and intolerance records |
| Immunization | au-core-immunization | Vaccination history |
| DiagnosticReport | au-core-diagnosticreport | Laboratory and imaging reports |
| ServiceRequest | au-core-servicerequest | Pathology and imaging orders |
| CarePlan | au-core-careplan | Care plans and treatment goals |
| Encounter | au-core-encounter | Healthcare visits and interactions |
AU Core Search Requirements
AU Core mandates support for specific search parameters on each resource to enable consistent querying across systems:
- Patient: _id, identifier, name, birthdate, gender, address
- Observation: patient, category, code, date, value-quantity
- Condition: patient, category, clinical-status, code, onset-date
- MedicationRequest: patient, status, intent, medication, authoredon
- AllergyIntolerance: patient, clinical-status, code
- Immunization: patient, status, vaccine-code, date
- DiagnosticReport: patient, category, code, date, status
Conformance Requirement
Servers claiming AU Core conformance MUST support all mandatory search parameters and MUST accurately declare capabilities in their CapabilityStatement.
CapabilityStatement: Declaring Server Capabilities
A CapabilityStatement is a FHIR resource that declares what a FHIR server supports: which resources, interactions, search parameters, profiles, and operations are available.
CapabilityStatement Structure
- url: Canonical identifier for the CapabilityStatement
- version: Version of the CapabilityStatement
- status: draft | active | retired | unknown
- kind: instance | capability | requirements
- fhirVersion: Supported FHIR version(s)
- format: Supported MIME types (application/fhir+json, etc.)
- rest: RESTful interface capabilities
REST Interface Declaration
The rest element contains detailed server capabilities:
- mode: server | client
- security: Authentication and authorization methods
- resource: Supported resources with profiles
- interaction: System-level operations (transaction, batch, search-system)
- searchParam: Supported search parameters per resource
- operation: Custom operations supported
AU Core CapabilityStatement Example
AU Core Server CapabilityStatement
Structured JSON example rendered with depth controls for easier inspection.
Click on an annotation to highlight it in the JSON
CapabilityStatement Types
CapabilityStatement kind values
| Kind | Purpose | Use Case |
|---|---|---|
| instance | Describes a specific server instance | GET /metadata returns actual server capabilities |
| capability | Describes a class of server instances | Vendor product capability documentation |
| requirements | Describes required capabilities | Implementation Guide conformance requirements |
Discovery Endpoint
FHIR servers expose their CapabilityStatement at the well-known endpoint: GET /metadata. Clients should retrieve this before interacting with the server to understand supported capabilities.
FHIR CapabilityStatement Specification
HL7 FHIR CapabilityStatement resource definition
CapabilityStatement SpecMust Support Requirements
The Must Support (MS) flag in FHIR profiles indicates elements that servers must be capable of populating and that clients may request. It does not mean the element is mandatory in every instance.
Must Support Semantics
Per the FHIR specification, Must Support means:
- Servers SHALL support the element (can populate it with meaningful values)
- Clients MAY request the element (can ask for it in queries)
- Servers are NOT required to populate it in every instance
- Clients MUST handle missing Must Support elements gracefully
Common Misconception
Must Support does NOT mean "mandatory". A server can return a valid AU Core Patient without populating all MS elements, as long as it is capable of supporting them when clinically appropriate.
AU Core Must Support Elements
Must Support requirements by resource
| Resource | Must Support Elements | Rationale |
|---|---|---|
| Patient | identifier, name, gender, birthDate, address | Core patient identification and demographics |
| Practitioner | identifier, name, telecom, qualification | Provider identification and contact |
| Organization | identifier, name, telecom, address | Healthcare organization identification |
| Observation | status, category, code, subject, effectiveDateTime, value[x] | Clinical measurements and results |
| Condition | clinicalStatus, verificationStatus, category, code, subject, onsetDateTime | Problem list and diagnoses |
| MedicationRequest | status, intent, medication[x], subject, authoredOn, requester | Medication orders and prescriptions |
| AllergyIntolerance | clinicalStatus, verificationStatus, code, patient, recordedDate | Allergy and adverse reaction records |
| Immunization | status, vaccineCode, patient, occurrenceDateTime | Vaccination history |
| DiagnosticReport | status, category, code, subject, effectiveDateTime, conclusion | Laboratory and imaging reports |
| ServiceRequest | status, intent, category, code, subject, authoredOn | Pathology and imaging requests |
Client Handling of Must Support
Clients should:
- Request Must Support elements using _elements parameter
- Handle missing MS elements without failing
- Understand that missing MS elements may indicate "not known" or "not applicable"
- Use Alternative representations (_summary, _contents) appropriately
GET /Patient/123?_elements=identifier,name,birthDate,gender
# Server response includes only requested elements:
{
"resourceType": "Patient",
"id": "123",
"identifier": [...],
"name": [...],
"birthDate": "1980-01-15",
"gender": "male"
}AU eRequesting: Electronic Requests
AU eRequesting standardises electronic requesting for pathology and diagnostic imaging services using FHIR ServiceRequest and related resources, enabling seamless digital referral workflows.
AU eRequesting Resources
- ServiceRequest: The request/order for pathology or imaging
- DiagnosticReport: The resulting report from the service
- Observation: Individual test results within a report
- Specimen: Specimen collection details (pathology)
- ImagingStudy: Imaging study metadata (diagnostic imaging)
AU Pathology Request Profile
The AU Pathology Request profile constrains ServiceRequest for pathology orders:
- category: Fixed to "path" (pathology)
- code: LOINC coded pathology tests or panels
- requester: Practitioner or PractitionerRole with HPI-I
- performer: Pathology organization with HPI-O
- reasonCode: Clinical indication using SNOMED CT-AU
- supportingInfo: Related conditions, medications, notes
AU eRequesting ServiceRequest Example
AU Pathology ServiceRequest
Structured JSON example rendered with depth controls for easier inspection.
Click on an annotation to highlight it in the JSON
AU Diagnostic Imaging Request Profile
Diagnostic imaging requests follow similar patterns with imaging-specific extensions:
- category: Fixed to "diag" (diagnostic imaging)
- code: LOINC or local codes for imaging procedures
- bodySite: Anatomical location using SNOMED CT-AU
- reasonCode: Clinical indication for imaging
- note: Special instructions (e.g., contrast required)
eRequesting Benefits
Electronic requesting reduces errors from illegible handwriting, enables decision support at order entry, provides faster turnaround, and supports automated result routing back to the requesting provider.
AU Patient Summary: Care Transitions
AU Patient Summary defines a standardized format for sharing essential patient health information during care transitions, such as hospital discharge, specialist referral, or when a patient presents to a new provider.
Patient Summary Structure
The AU Patient Summary uses the FHIR Composition resource to organize clinical information into sections:
- Allergies and Intolerances
- Current Medications
- Problem List / Diagnoses
- Recent Observations (vital signs, lab results)
- Immunizations
- Medical History
- Care Plans
- Encounters
Composition Resource
The Composition resource provides the document structure:
- status: preliminary | final | amended | entered-in-error
- type: LOINC code for document type (60591-5 for Patient Summary)
- subject: The patient the summary is about
- date: When the summary was created
- author: Healthcare provider(s) who created the summary
- attester: Providers who attested to accuracy
- custodian: Organization responsible for maintaining the summary
- section: Organized clinical content sections
AU Patient Summary Example
AU Patient Summary Composition
Structured JSON example rendered with depth controls for easier inspection.
Click on an annotation to highlight it in the JSON
Section Requirements
Patient Summary sections
| Section | LOINC Code | Required |
|---|---|---|
| Allergies | 48765-2 | Required |
| Medications | 10160-0 | Required |
| Problems | 11450-4 | Required |
| Observations | 60588-1 | Optional |
| Immunizations | 11369-6 | Optional |
| Medical History | 11348-0 | Optional |
Relationship to My Health Record
AU Patient Summary aligns with My Health Record Shared Health Summary and Event Summary document types, enabling consistent information exchange between local systems and the national infrastructure.
Profile Inheritance and Conformance
Australian FHIR profiles follow a hierarchical inheritance model, with each layer adding constraints and extensions on top of the base FHIR standard.
Profile Inheritance Hierarchy
Australian FHIR profile inheritance
Loading diagram...
StructureDefinition Resource
Profiles are formally defined using the StructureDefinition resource:
- url: Canonical URL identifying the profile
- name: Human-readable name
- status: draft | active | retired | unknown
- baseDefinition: URL of the profile being constrained
- derivation: specialization | constraint
- differential: Changes from base (for publication)
- snapshot: Complete profile definition (for validation)
Conformance Levels
Australian IG conformance status
| IG | Purpose | Scope | Status | Version |
|---|---|---|---|---|
| AU Base | Australian FHIR foundation profiles | All FHIR resources with AU extensions | Normative | 4.0.1 |
| AU Core | Minimum dataset for interoperability | Core clinical resources | Trial Use | 1.0.0 |
| AU eRequesting | Electronic pathology/imaging requests | ServiceRequest, DiagnosticReport | Trial Use | 2.0.0 |
| AU Patient Summary | Care transition summaries | Composition, related clinical resources | Trial Use | 1.0.0 |
| AU Medication | Medication management | Medication, MedicationRequest, etc. | Trial Use | 1.0.0 |
Conformance vs Validation
A resource can validate against a profile (syntactically correct) but a server claiming conformance must also support the required interactions, search parameters, and security requirements.
Validation Process
- Load the IG package (NPM) into the FHIR Validator
- Validate resources against the profile StructureDefinitions
- Check terminology bindings (CodeSystem, ValueSet)
- Verify required elements are present
- Validate cardinality and data types
- Check extension usage conforms to definitions
# Validate a Patient resource against AU Base
java -jar validator_cli.jar patient-example.json -ig hl7.fhir.au.base#4.0.1 -tx http://tx.fhir.orgSummary & Key Takeaways
Australian FHIR Implementation Guides provide the foundation for consistent, interoperable health data exchange across the nation's healthcare system.
Core Concepts Recap
- AU Base: Australian constraints and extensions on FHIR R4
- AU Core: Minimum dataset for clinical interoperability
- CapabilityStatement: Server capability declaration
- Must Support: Elements servers must support (not mandatory)
- AU eRequesting: Standardized pathology/imaging requests
- AU Patient Summary: Care transition documentation
Implementation Checklist
- Load AU Base and AU Core IG packages
- Implement required resource profiles
- Support mandatory search parameters
- Create accurate CapabilityStatement
- Validate resources against profiles
- Test with AU Core test suites
- Participate in Connectathon testing
Next Steps
After understanding Australian IGs, explore AWS infrastructure for FHIR deployment, security compliance requirements (IRAP PROTECTED), and SMART on FHIR authorization patterns.
Touchstone FHIR Testing Platform
FHIR conformance testing platform used for interoperability and implementation-guide validation exercises.
Touchstone TestingKnowledge Check
Test your understanding with this quiz. You need to answer all questions correctly to mark this section as complete.