Common Components FHIR Implementation Guide, published by Australian Digital Health Agency. This guide is not an authorized publication; it is the continuous build for version 26.0.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/AuDigitalHealth/common-components/ and changes regularly. See the Directory of published versions

General Guidance

Conventions

Must support

This IG follows the approach taken in AU Core to must support and obligation.

Labelling an element Must Support means that systems that produce or consume resources SHALL 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 SHALL make clear exactly what kind of support is required when an element is labelled as Must Support.

In this IG, the meaning of Must Support is specified in terms of Obligation Codes in obligation extensions on the element definition. These obligations can also be applied at more granular levels, such as individual data type choices, terminology bindings, identifiers, or sub-elements.

To interpret elements labelled as must support follow the guidance in AU Core at Interpreting Profile Elements Labelled Must Support.

Must Support & Obligations

This implementation guide defines obligations to specify behaviour for data elements when using the extensions and profiles defined in this IG. While this IG builds upon AU Core profiles, implementers should refer to the specific obligations defined in their implementation context.

Generally the main obligations applied within this IG are:

  • SHALL:populate-if-known obligation: Systems SHALL populate-if-known the data element in accordance with the FHIR obligation definition. This means that if the system knows the correct value for the element it will include it. The obligation does not require the element to always be present, but when the system has the relevant data and it is appropriate for the resource context, the element must be populated if known.

  • SHOULD:handle obligation: Systems SHOULD be capable of receiving and processing the data element when it is present in resources in accordance with the FHIR obligation definition. This provides flexibility for implementers to support data elements based on their specific use cases and integration requirements.

For elements without FHIR obligations:

  • Data elements that do not have specific FHIR obligations defined can be ignored by implementers unless explicitly required by their specific use case or local requirements.

Experimental dependencies

This table lists the experimental dependencies used within this specification at the time of publishing. We acknowledge that while not ideal, the reasons for doing so are valid and described below.

Reference Description
XXXX XXXXX
XXXX XXXXXXX

Extension Summary Table

Extension Name IG Where First Published Found in Subsequent IGs Associated Terminology
Active Period PCA HCPD N/A
Alternate Name PCA HCPD N/A
Amenity PCA HCPD NCTS Facility Amenity ValueSet / CodeSystem
IAR Levels of Care PCA HCPD NCTS IAR Levels of Care ValueSet / CodeSystem
New Patient Availability PCA HCPD NCTS New Patient Availability ValueSet / CodeSystem
Practitioner Role Communication PCA HCPD NCTS Common Languages
Referral Information for Referrer PCA HCPD N/A
Suppressed HCPD — Common Components IG ValueSet / CodeSystem
Medication Formula String ADHA Data Format Mapping TBD N/A
Medication Dispense Quantity Description ADHA Data Format Mapping TBD N/A
Medication Additional Therapeutic Good Detail String ADHA Data Format Mapping TBD N/A
Medication Dispense Unique Prescription Number String ADHA Data Format Mapping TBD N/A
Medication Dispense Repeat Status Code ADHA Data Format Mapping TBD Common Components IG ValueSet / CodeSystem
Medication Dispense Maximum Number Of Repeats ADHA Data Format Mapping TBD N/A
Source CDA Document Identifier ADHA Data Format Mapping TBD Common Components IG ValueSet / CodeSystem