AU Core Implementation Guide
2.0.1-ci-build - CI Build
AU Core Implementation Guide
2.0.1-ci-build - CI Build
AU Core Implementation Guide, published by HL7 Australia. This guide is not an authorized publication; it is the continuous build for version 2.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-core/ and changes regularly. See the Directory of published versions
| Page standards status: Informative |
AU Core promotes interoperability and adoption through common implementation and provides the basis for further implementation guide development for specific use cases.
AU Core uses AU Base representations as the base layer, where available, as the basis for AU Core FHIR structures and describes the minimum expectations for support for systems in Australia across use cases, jurisdictions, organisations, and digital health initiatives nationwide.
AU Core defines the data model and RESTful API interactions that set minimum expectations for a system to record, update, search, and retrieve core digital health and administrative information.
The approach to describing the 'minimum' in AU Core means modelling in such a way that 'at least' what is to be supported is defined without limiting meaningful options for use cases and business rules. AU Core artefacts are therefore modelled as open templates allowing for additional content including elements, extensions, resources, search parameters, operations, and terminology whilst ensuring the minimum requirements are met.
Australian realm IGs and implementers are expected to comply with AU Base and AU Core and to define extensions, search parameters or operations (in order of precedence):
AU Core profiles:
AU Core defines:
AU Core does not define new extensions, search parameters, operations or terminology; these artefacts are defined in AU Base. AU Core profiles these AU Base artefacts to describe minimum expectations for support in Australia. For more information on the definitional nature of AU Base see the guidance in AU Base Implementation Guide Approach.
AU Core does not define new extensions. All extensions included in AU Core are defined in the FHIR Extensions Pack or AU Base. A limited set of extensions are indicated as Must Support in AU Core resource profiles (see Use of Extensions in Resource Profile Approach).
AU Core profiles some complex extensions to define minimum support expectations, for example AU Core Sex Assigned At Birth profiles the Person Recorded Sex or Gender extension to indicate which parts of the extension are Must Support and the obligations for AU Core actors.
When modelling AU Core extension profiles, the AU Core resource profile approach is followed.
AU Core does not define new search parameters. All search parameters included in AU Core are defined in the FHIR Search Parameter Registry or AU Base.
AU Core profiles these search parameters to describe the additional minimum support expectations for search parameters for AU Core actors including support for chaining, modifiers, and comparators, e.g. AU Core profile of clinical-patient that defines support for chained identifiers.
The set of AU Core SearchParameters defined in this release of AU Core include search parameters with support for chained search. Future releases of AU Core will define the complete list of search parameters supported by AU Core.
AU Core does not define new terminology FHIR artefacts (e.g. value sets or code systems). Terminology supported in AU Core are published in AU Base, the FHIR standard, HL7 Terminology (THO), or the National Clinical Terminology Service (NCTS).
As part of profiling, AU Core indicates the support expectations for terminology for that resource using the terminology binding and Must Support flag (see Use of Terminology Bindings in Resource Profile Approach).
For a list of the terminology supported in AU Core refer to the Terminology page. See AU Base for guidance on Terminology Selection in HL7 AU implementation guides.
AU Core resource profiles set minimum expectations for a system to record, update, search, and retrieve core digital health and administrative information in Australia. AU Core profiles are derived from AU Base resource profiles, where available, and identify the additional mandatory core elements, extensions, vocabularies and value sets that are to be present in the resource when conforming to AU Core. These profiles define the minimum conformance requirements that downstream profiles are expected to comply with.
AU Core profiles:
Some aspects of the approach to profiling resources in AU Core are described in further detail in the subsections below:
Cardinality is only restricted where there is an agreed minimum data quality requirement for a supported element (i.e. element labelled Must Support). For example, in AU Core profiles of clinical resources the following are made mandatory (minimum cardinality is > 0):
AllergyIntolerance.code, Procedure.code, Condition.codeAU Core does not prohibit (cardinality 0..0) elements or extensions, as prohibition restricts the opportunities for downstream IGs and applications to define their own business rules.
AU Core profiles include conditional cardinality constraints (defined using invariants), which are:
Extensions are inherited from the underlying AU Base resource profile, where available, and the extensions that form part of the minimum support expectations for an AU Core profile are marked with Must Support.
Additional extensions are not added directly to an AU Core profile, unless there is no underlying AU Base resource profile to derive from. Some FHIR resource types are not profiled in AU Base as the resource type is too abstract to support meaningful localisation across use cases in a base resource profile (e.g. Basic, Observation, or Device).
While the work to include a new extension in the underlying AU Base resource profile is progressing, extensions can be added (but not defined) temporarily in an AU Core profile to support development and testing in a release.
Where the AU Core profile is derived, the underlying AU Base terminology binding is inherited. Terminology for a resource is localised in AU Base. In some cases that localised terminology is represented in the binding for a coded element, and in other cases it is represented as additional bindings that list the set of terminology recognised for use in Australia for that element.
New terminology bindings are not added in an AU Core profile unless there is no AU Base resource profile available to derive from (e.g. profiles of Observation, Device, Basic).
Terminology binding strength used in AU Core profiles:
AllergyIntolerance.code, Condition.code).New additional bindings are added to AU Core profiles when there is a candidate value set for consideration by the community that is stricter than the currently bound value set for an element (e.g. the value set Metric Body Weight Units is a candidate binding for Observation.value.code in AU Core Body Weight). These candidate value sets are included in a profile using the additional bindings extension with the binding purpose set to candidate.
Coded elements in AU Core profiles that define support for more than one value set include them in a profile by slicing the Coding part of the element and placing Must Support on each value set slice. Modelling optional slices of Coding allows systems to supply a text only value. See Use of Slicing, Pattern, and Fixed Value.
Additional terminology rules that cannot be represented using a binding are applied with the use of invariants (e.g. AU Core Procedure invariant au-core-pro-01: If a coded body site is provided, at least one coding shall be from SNOMED CT).
While the work to include a new terminology binding in the underlying AU Base resource profile is progressing, it can be added temporarily to an AU Core profile directly to support development and testing in a release.
AU Core profiles include invariants when a minimum data quality requirement requires logic that cannot be represented through other profiling techniques (e.g. cardinality or terminology binding). These invariants are formally defined using FHIRPath so that the constraint can be computationally evaluated.
Typically, invariants defined in AU Core are used to:
AU Core invariants are intentionally written to allow for the AU Core requirements on Missing Data to be met (e.g. AU Core Patient invariant au-core-pat-01: At least one patient identifier shall be valid, or if not available, the Data Absent Reason extension shall be present).
Slicing is avoided where possible to avoid limiting the opportunities for downstream IGs and applications to define their own business rules. Slicing is used to:
Medication.code.coding is sliced to define support for Australian Medicines Terminology (AMT) and PBS Item Codes)Patient.identifier is sliced to define support for IHI, Medicare Card Number, and DVA Number)Observation.code is sliced to identify the agreed LOINC and SNOMED CT codes that identify the concept)Slices are defined as open (i.e. slicing.rules is open) so that downstream IGs and applications can add additional patterns where required, provided the AU Core profile constraints are met.
Patterns and fixed values are used to define support for recognised clinical concepts:
Observation.code needs to have Observation.code.coding.code="1747861000168109" and Observation.code.coding.system="http://snomed.info/sct").Observation.code as Observation.code.coding.code="72166-2" and Observation.code.coding.system="http://loinc.org").Some AU Core profiles include slicing with a discriminator of type 'pattern' which is deprecated in R5+. For future compatibility, it is under consideration to use type=value with a pattern[x] instead.
To support validation, resource references for supported elements (i.e. elements labelled Must Support) are constrained to target AU Core profiles, or where not available, AU Base resource profiles (where they exist).
Types for supported elements (i.e. elements labelled Must Support) are restricted only where there is national agreement to restrict that usage. This is rare as AU Core profiles are modelled intentionally to not restrict meaningful use case options. Some examples where a restriction is applied are:
Condition.onset[x] is constrained to not allow onsetString.Observation.value is constrained to only allow valueCodeableConcept.Where no national agreement exists to restrict a type choice, all inherited types are allowed. For example in AU Core Patient, Patient.address inherits the FHIR data type Address and AU Base Australian Address data type profile from AU Base Patient.
New data type profiles are not added in AU Core to the set of allowed type choices unless there is no AU Base resource profile available to derive from (e.g. profiles of Observation, Device, Basic).
Must Support is used to indicate the elements and extensions that form the minimum requirements of AU Core. Labelling an element Must Support means that systems that produce or consume resources are to provide support for the element in some meaningful way. The FHIR standard does not define exactly what 'meaningful' support for an element means, but indicates that a profile needs to make clear exactly what kind of support is required when an element is labelled as Must Support.
When defining the meaning of Must Support in AU Core:
See Must Support and Obligation for a detailed description of how this is applied in AU Core.
AU Core actors are defined to describe the specific sets of functionality supported by systems that play a role in AU Core data exchange. Each actor is defined by:
AU Core capability statements are defined to describe the specific capabilities of a system when playing a particular role (i.e. actor) and includes the complete list of FHIR profiles, RESTful operations, and search parameters supported by that actor.
AU Core capability statements are defined as open, allowing additional resources, profiles, operations, and search parameters to be defined.
Every resource type that is the target of a Must Support element in a profile is modelled, with the agreed support expectations (incl. base and supported profiles, operations, search parameters), to ensure a complete description of the requirements for implementation.
AU Core capability statements include profile specific implementation guidance that provides qualifying narrative where further clarification for Must Support behaviour is required or where agreed relaxations apply.
For guidance on SNOMED CT-AU in FHIR, see the guidance defined in AU Base SNOMED CT Australian Edition.
In some circumstances, the content referred to in the resource reference does not have an independent existence apart from the resource that contains it - it cannot be identified independently, and nor can it have its own independent transaction scope. For example, use of a Medication resource to represent medicinal product identification within the context of a MedicationRequest. In these circumstances the resource can be contained.
In AU Core profiles:
Further guidance about the general use case for contained resources can be found in the FHIR standard.
A responder can send 'additional' elements beyond those flagged with Must Support in an AU Core profile. Additional elements are often required by other profiles the system may conform to, allowing local requirements, including technical and workflow context for the resource, to be reflected and extending the health information supported in exchanges. For this reason, extensibility is generally encouraged and expected in AU Core profiles. Only in some exceptionally rare use case profiles are rules tightened to limit the nature of additional information that can be sent. Specification authors are encouraged to enable greater interoperability and software re-use by avoiding reductions in an element's cardinality.
Depending on local requirements, a requester (i.e. client application) may ignore these 'additional' elements, may treat the data as for rendering only, or be capable of recognising and using the element.
When exchanging Procedure and Condition resources using AU Core profiles there may be a need to represent a relevant body site and associated laterality using CodeableConcept elements. In FHIR, body site and associated laterality can be recorded in various ways and implementers are encouraged to consider the following points when implementing:
bodySite element is not Must Support in AU Core profiles, there is no expectation to fill or meaningfully consume this element.CodeableConcept.text element is system populated and may reflect more specific detail than the CodeableConcept.coding concepts provided.See the guidance in AU Base Representing Body Site, Which May Include Laterality for what to do in each of the following scenarios:
Searching resources is defined by the FHIR RESTful API and included here for informative purposes. The AU Core CapabilityStatements document the server and client rules for the RESTful interactions described in this guide.
All the search interaction examples in this guide use the HTTP GET method with the following syntax:
GET [base]/[Resource-type]?[parameter1]{:m1|m2|...}={c1|c2|...}[value1{,value2,...}]{&[parameter2]{:m1|m2|...}={c1|c2|...}[value1{,value2,...}]&...}
token type SearchParameter (how to search by token), the syntax {system|}[code] means that the system value is optional for the client to supply.reference type SearchParameter (how to search by reference), the syntax {Type/}[id] means that the Type value is optional for the client to supply.date type SearchParameter (how to search by date), the syntax {gt|lt|ge|le}[date] means the date comparators "gt", "lt", "ge", and "le" are optional. Date type searches without a comparator prefix are equivalent to searches with the "eq" comparator even if a server does not support the comparator.In the simplest case, a search is executed by performing a GET operation in the RESTful framework:
GET [base]/[Resource-type]?name=value&...
For this RESTful search, the parameters are a series of name=[value] pairs encoded in the URL. The search parameter names are defined for each resource. For example, the Observation resource has the name "code" for searching on the LOINC or SNOMED CT-AU code. For more information, see the FHIR RESTful Search API.
Examples in AU Core do not demonstrate the url encoding rules for special characters e.g. "|".
IG © 2022+ HL7 Australia. Package hl7.fhir.au.core#2.0.1-ci-build based on FHIR 4.0.1. Generated 2026-01-28
Links: Table of Contents |
QA Report
| Version History |
|
Propose a change