Clinical Document Architecture with Australian Schema, published by Australian Digital Health Agency. This guide is not an authorized publication; it is the continuous build for version 1.0.1 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/AuDigitalHealth/cda-au-schema/ and changes regularly. See the Directory of published versions
This Australian Digital Health Agency Implementation Guide provides a FHIR-based representation of the HL7 Clinical Document Architecture (CDA) standard, including Australian-specific CDA extensions, to support organisations transitioning from CDA to FHIR. It adapts the HL7 International CDA Logical Model Specification into FHIR StructureDefinitions, enabling implementers to understand and exchange CDA-based information within a FHIR framework while maintaining alignment with international standards. The guide includes Australian CDA extensions, CDA classes represented as FHIR logical models, and supporting vocabularies for content exchange, with a focus on interoperability and data modelling rather than document presentation, user experience, or system behaviour.
Home
Official URL: http://ns.electronichealth.net.au/cda/ImplementationGuide/au.digitalhealth.cda.schema
It is an adaptation of the HL7 International CDA Logical Model Specification with specific modifications and inclusions to represent the CDA schema including Australian CDA extensions using the FHIR StructureDefinition framework.
Document purpose and scope
The primary aim of this implementation guide is to support implementers who are contemplating a transition from CDA to FHIR. It contains CDA extensions in Australian context and the HL7 CDA classes using the Australian extensions.
This implementation guide does not describe presentation of the information, user experience, or expected behaviour of producing and receiving systems.
Wherever possible, material in this specification is based on existing standards. All efforts have been made to minimise divergence from the HL7 international CDA classes to provide for system interoperability and compatibility with other classes. Issues of an editorial nature in the source material (such as spelling or punctuation errors) are intentionally reproduced.
This implementation guide is aimed at software development teams, architects, and designers of CDA implementation in Australia.
This implementation guide and related artefacts are technical in nature and the audience is expected to be familiar with the language of health data specifications and to have some familiarity with health information standards and specifications, such as CDA.
Document information
Intellectual property considerations
This implementation guide and the underlying FHIR specification are licensed as public domain under the FHIR license.
This publication includes IP covered under the following statements.
This implementation guide builds on other specifications, helping ensure a consistent approach to data sharing that should ease adoption. The specific guides used, and the portions relevant from each of them are as follows:
IG
Package
FHIR
Comment
Clinical Document Architecture with Australian Schema
This IG defines the global extensions - the ones defined for everyone. These extensions are always in scope wherever FHIR is being used (built Sat, May 16, 2026 18:32+1000+10:00)
Package hl7.fhir.uv.tools.r5#1.1.2
This IG defines the extensions that the tools use internally. Some of these extensions are content that are being evaluated for elevation into the main spec, and others are tooling concerns (built Tue, Mar 24, 2026 11:13+1100+11:00)
Global profiles
There are no Global profiles defined
Known issues
This table lists known issues with this specification at the time of publishing. We are working on solutions to these issues and encourage comments to help us develop these solutions.
The terminology binding on the au-Participant1 `@typeCode` attribute has been changed to use the v3-ParticipationType valueSet rather than the valueSet as used in HL7 International CDA Participant1 class. This is due to the attribute value of `PART`, which is mandated in many of the My Health Record CDA implementations.