AU Base Implementation Guide, published by HL7 Australia. This guide is not an authorized publication; it is the continuous build for version 4.2.2-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-base/ and changes regularly. See the Directory of published versions

General Guidance

Intent of this Implementation Guide

This implementation guide does not attempt to constrain for specific use cases. Instead it defines representations of how commonly needed concepts, in an Australian context, can be applied generally.

This implementation guide can then be drawn on for specific use cases and further constraints added for the needs of those cases. By referencing the AU Base definition in downstream implementation guides there is a basic level of alignment in representation across those guides.
This alignment allows general processing and simpler exchange of information from one implementation guide domain to another without the need for extensive integration translation tasks. This becomes more useful as the number of specific use case implementation guides expands and the potential issues of movement of information into and out of multiple domains of interest is addressed.

This approach manifests as the following representation outcomes in this guide, as follows:

• Cardinality: most representations described have a cardinality as defined in the core FHIR specification (which is general in nature) to avoid required content for use cases that do not need or support the content.
• Must Support: the FHIR profiling Must Support flags are not used in this guide; for similar reasons to the cardinality there is no assertion of required support for any of the elements profiled in this guide.
• Terminology Binding: elements that can be bound to terminology are often sliced to offer one or more specific binding options that can be required in downstream guides; this also provides value sets that are common/suitable for the Australian context.
• Slice Constraints: in this guide choice or repeating elements are often sliced to define specific profiling options for that element, specific slices needed in downstream guides can be picked up and made required (cardinality), or must support as needed. Slicing on elements is left open to allow other slice profiles to be added as needed.

For a directly implementable usage of AU Base for a general level of capability it is recommended the AU Core implementation guide be considered. AU Core introduces a required level of element support that give a core set of capability that can be implemented and assumed.

Maturity Levels

These levels used for this Implementation Guide are associated with the FHIR Maturity Model and adjusted for local use.

The content of this release has been subject to significant review through ballot and other HL7 AU processes and many aspects of it have been implemented and subjected to interoperability testing through connectathons and early adoption. However, the degree of testing has varied. Some resources have been well tested in a variety of environments. Others have received relatively little real-world exercise. In general, the infrastructure should be considered to be more stable than the resources themselves. Guidance from early implementation will help address these areas.

All artifacts in this specification are assigned a “Maturity Level”,known as AFMM (after the well-known CMM grades) - Australian FHIR Maturity Model. The AFMM level can be used by implementers to judge how advanced - and therefore stable - an artifact is.

The following AFMM levels are defined:

DRAFT 0 The resource or profile (artifact) has been published on the current build. Artifacts with this level must have a standards status of Draft.

AFMM 1 DRAFT 0 PLUS the artifact produces no warnings or errors during the build process that have not been accepted by the responsible WG; and the responsible WG has indicated that they consider the artifact substantially complete and ready for implementation.

AFMM 2 AFMM 1 PLUS the artifact has been tested and successfully supports interoperability among at least three independently developed systems leveraging most of the scope (e.g. at least 80% of the core data elements) using appropriate data and scenarios based on at least one of the declared scopes of the artifact (e.g. at a connectathon). These interoperability results must have been reported to and accepted by the FHIRWG.

AFMM 3 AFMM 2 PLUS the artifact has been verified by the work group as meeting the Conformance Resource Quality Guidelines; has been subject to a round of formal balloting; has at least 10 distinct implementer comments recorded in the tracker drawn from at least 3 organizations resulting in at least one substantive change.

AFMM 4 AFMM 3 PLUS the artifact is published in a formal publication (e.g. a FHIR Implementation Guide), and implemented in multiple prototype projects. As well, the responsible work group agrees the artefact is sufficiently stable to require implementer consultation for subsequent non-backward compatible changes.

AFMM 5 AFMM 4 PLUS the artifact has been published in two formal publication release cycles at AFMM1+ (i.e. Trial Use level) and has been implemented in at least 5 independent production systems.

Normative AFMM 5 PLUS the responsible work group and the FHIRWG agree the material is ready to lock down according to the inter-version change rules and the artifact has passed HL7 AU normative ballot. This is synonymous with Normative standard status.

Reference should also be made to Version Management Policy.

Business Identifiers

“Business” identifiers are used extensively to consistently identify real world entities across systems, contexts of use, and other formats (e.g. HL7 v2 , CDA , XDS, and many more).

Defined in this implementation guide are profiles for business identifiers for use in populating the following data elements:

• Device.identifier
• DiagnosticReport.identifier
• HealthcareService.identifier
• Location.identifier
• MedicationDispense.identifier
• MedicationRequest.identifier
• Observation.identifier
• Organization.identifier
• Patient.identifier
• RelatedPerson.identifier
• Practitioner.identifier
• Practitioner.qualification.identifier
• PractitionerRole.identifier
• ServiceRequest.identifier

Business identifiers will typically be a national identifier (ABN, Medicare Provider, IHI), registry / exchange service identifier (ETP, eRx), or local identifier (MRN, Placer Identifier).

This guide publishes and maintains rules on how to exchange various business identifiers in Australia as a set of Identifier data type profiles, e.g. AU PBS Prescriber Number.

While national and registry / exchange service identifiers will define the namespace to use when sending an identifier, a local identifier requires the organisation to define their own namespace when exchanging identifiers they manage.

When constructing a local identifier it is preferable that an organisation uses their own local system identifier namespace (e.g. “https://local organisation domain/identifier type”) but if that is not available then an organisation can use their HPI-O or ABN to construct a legal, globally unique identifier system for some local identifiers.

HPI-O scoped Identifiers

HPI-O scoped identifiers enable exchange of an organisation’s local identifiers for items such as a patient medical record or a pathology report by combining a dedicated Australian Digital Health Agency published namespace and their HPI-O to construct a legal, globally unique identifier system for their local identifiers.

The full list of available identifier namespaces can be found by browsing the ns.electronichealth.net.au identifier namespaces; there are several HPI-O scoped identifier namespaces available:

• http://ns.electronichealth.net.au/id/hpio-scoped/accessionnumber/1.0
• http://ns.electronichealth.net.au/id/hpio-scoped/dispense/1.0
• http://ns.electronichealth.net.au/id/hpio-scoped/medicalrecord/1.0
• http://ns.electronichealth.net.au/id/hpio-scoped/order/1.0
• http://ns.electronichealth.net.au/id/hpio-scoped/prescription/1.0
• http://ns.electronichealth.net.au/id/hpio-scoped/report/1.0
• http://ns.electronichealth.net.au/id/hpio-scoped/service-provider-individual/1.0

There are four parts to using a HPI-O scoped identifier in FHIR: system, value, assigner and depending on the identifier profile requirements, a coded type.

The system value is constructed in the format of [baseURL]/HPI-O, e.g.:

"system" : "http://ns.electronichealth.net.au/id/hpio-scoped/service-provider-individual/1.0/8003621566684455"

The value contains the local identifier, e.g.:

"value" : "3235209"

The assigner contains the name of the organisation that issues or manages the identifier, e.g.:

"assigner" : {
    "display" : "Devonport Family Medicine Clinic"
}

Example: PractitionerRole resource with an employee number (local identifier)

{
  "resourceType" : "PractitionerRole",
    ...
    "identifier" : [
      {
        "type" : {
          "coding" : [
            {
              "system" : "http://terminology.hl7.org/CodeSystem/v2-0203",
              "code" : "EI",
              "display" : "Employee number"
              }
            ],
          "text" : "Employee Number"
      },
      "system" : "http://ns.electronichealth.net.au/id/hpio-scoped/service-provider-individual/1.0/8003621566684455",
      "value" : "3235209",
      "assigner" : {
        "display" : "Devonport Family Medicine Clinic"
    },
  ...
}  

ABN scoped Identifiers

ABN scoped identifiers enable exchange of an organisation’s local identifiers for items such as a patient medical record by combining a dedicated Australian Digital Health Agency published namespace and their ABN to construct a legal, globally unique identifier system for their local identifiers.

The full list of available identifier namespaces can be found by browsing the ns.electronichealth.net.au identifier namespaces; there are two ABN-scoped identifier namespaces available:

• http://ns.electronichealth.net.au/id/abn-scoped/medicalrecord/1.0
• http://ns.electronichealth.net.au/id/abn-scoped/service-provider-individual/1.0

There are four parts to using an ABN scoped identifier in FHIR: system, value, assigner and depending on the identifier profile requirements, a coded type.

The system value is constructed in the format of [baseURL]/ABN, e.g.:

"system" : "http://ns.electronichealth.net.au/id/abn-scoped/medicalrecord/1.0/51824754455"

The value contains the local identifier, e.g.:

"value" : "12345446"

The assigner contains the name of the organisation that issues or manages the identifier, e.g.:

"assigner" : {
    "display" : "Test Hospital Org"
}

Example: Patient resource with a medical record number (local identifier)

{
  "resourceType" : "Patient",
    ...
      "identifier" : [
        {
        "type" : {
          "coding" : [
            {
              "system" : "http://terminology.hl7.org/CodeSystem/v2-0203",
                     "code" : "MR",
                     "display" : "Medical record number"
                   }
                 ],
          "text" : "Medical Record Number"
        },
        "system" : "http://ns.electronichealth.net.au/id/abn-scoped/medicalrecord/1.0/51824754455",
        "value" : "12344456",
        "assigner" : {
          "display" : "Test Hospital Org"
    },
  ...
}

Australian Health Practitioner Regulation Agency (Ahpra) Data Guidance

This guidance on the representation of Ahpra-sourced data is taken and adapted from Ahpra’s practitioner information exchange (PIE) interoperability specification: Find registration.

Ahpra data items should be exchanged using a Practitioner resource.

This guidance matches Ahpra data items to the corresponding element in a Practitioner resource, making use of extensions Ahpra Profession Details and Ahpra Registration Details as needed.

Ahpra Person Data

Ahpra Qualification Data

Ahpra Profession Data

Ahpra Registration Data