The UCUM codes, UCUM table (regardless of format), and UCUM Specification are copyright 1999-2009, Regenstrief Institute, Inc. and the Unified Codes for Units of Measures (UCUM) Organization. All rights reserved. https://ucum.org/trac/wiki/TermsOfUse
These codes are excerpted from ASTM Standard, E1762-95(2013) - Standard Guide for Electronic Authentication of Health Care Information, Copyright by ASTM International, 100 Barr Harbor Drive, West Conshohocken, PA 19428. Copies of this standard are available through the ASTM Web Site at www.astm.org.
This material contains content that is copyright of SNOMED International. Implementers of these specifications must have the appropriate SNOMED CT Affiliate license - for more information contact https://www.snomed.org/get-snomed
or info@snomed.org
.
AU Patient Summary Implementation Guide - Local Development build (v0.2.0-preview) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions ( src
)
HL7 FHIR® Licensing and Legal Terms should also be referenced as the underlying standards published terms on which HL7 Australia FHIR Implementation Guides depend. ( src
)
HL7®, HEALTH LEVEL SEVEN®, FHIR® and the FHIR logo are trademarks owned by Health Level Seven International, registered with the United States Patent and Trademark Office. ( src
)
Most trademarks used in conjunction with HL7® products, services and activities are registered and/or owned by HL7 International, rather than by HL7 Australia, and their use is subject to the associated HL7 International IP policies and licensing terms. ( src
)
There are examples where a medication request may include the option of an oral dose or an Intravenous or Intramuscular dose. For example, "Ondansetron 8mg orally or IV twice a day as needed for nausea" or "Compazine® (prochlorperazine) 5-10mg PO or 25mg PR bid prn nausea or vomiting". In these cases, two medication requests would be created that could be grouped together. The decision on which dose and route of administration to use is based on the patient's condition at the time the dose is needed. ( src
)
Unless not suitable, these codes SHALL be taken from For example codes, see
Indicator of Hypersensitivity or Intolerance to Substance http://hl7.org/fhir/ValueSet/allergyintolerance-code
( extensible
to https://healthterminologies.gov.au/fhir/ValueSet/indicator-hypersensitivity-intolerance-to-substance-2
)
The codes SHOULD be taken from For example codes, see
Clinical Finding http://hl7.org/fhir/ValueSet/clinical-findings
( preferred
to https://healthterminologies.gov.au/fhir/ValueSet/clinical-finding-1
)
Unless not suitable, these codes SHALL be taken from For example codes, see
Clinical Condition http://hl7.org/fhir/ValueSet/condition-code
( extensible
to https://healthterminologies.gov.au/fhir/ValueSet/clinical-condition-1
)
Unless not suitable, these codes SHALL be taken from For example codes, see
Body Site http://hl7.org/fhir/ValueSet/body-site
( extensible
to https://healthterminologies.gov.au/fhir/ValueSet/body-site-1
)
Unless not suitable, these codes SHALL be taken from
Clinical Condition
( extensible
to https://healthterminologies.gov.au/fhir/ValueSet/clinical-condition-1
)
Unless not suitable, these codes SHALL be taken from The codes SHOULD be taken from
Pathology Diagnostic Service Category http://hl7.org/fhir/ValueSet/observation-category
( extensible
to https://healthterminologies.gov.au/fhir/ValueSet/pathology-diagnostic-service-category-1
)
Unless not suitable, these codes SHALL be taken from For example codes, see
RCPA SPIA Pathology Reporting http://hl7.org/fhir/ValueSet/observation-codes
( extensible
to https://healthterminologies.gov.au/fhir/ValueSet/spia-pathology-reporting-1
)
Unless not suitable, these codes SHALL be taken from
Pathology Diagnostic Service Category
( extensible
to https://healthterminologies.gov.au/fhir/ValueSet/pathology-diagnostic-service-category-1
)
Unless not suitable, these codes SHALL be taken from
RCPA SPIA Pathology Reporting
( extensible
to https://healthterminologies.gov.au/fhir/ValueSet/spia-pathology-reporting-1
)
The codes SHOULD be taken from For example codes, see
Service Type http://hl7.org/fhir/ValueSet/service-type
( preferred
to https://healthterminologies.gov.au/fhir/ValueSet/service-type-1
)
The codes SHOULD be taken from
Reason For Encounter http://hl7.org/fhir/ValueSet/encounter-reason
( preferred
to https://healthterminologies.gov.au/fhir/ValueSet/reason-for-encounter-1
)
Unless not suitable, these codes SHALL be taken from
Separation Mode
( extensible
to https://healthterminologies.gov.au/fhir/ValueSet/separation-mode-1
)
The codes SHOULD be taken from For example codes, see
Immunisation Anatomical Site http://hl7.org/fhir/ValueSet/immunization-site
( preferred
to https://healthterminologies.gov.au/fhir/ValueSet/immunisation-anatomical-site-1
)
The codes SHOULD be taken from For example codes, see
Immunisation Route of Administration http://hl7.org/fhir/ValueSet/immunization-route
( preferred
to https://healthterminologies.gov.au/fhir/ValueSet/immunisation-route-of-administration-1
)
The codes SHOULD be taken from
Immunisation Anatomical Site
( preferred
to https://healthterminologies.gov.au/fhir/ValueSet/immunisation-anatomical-site-1
)
The codes SHOULD be taken from
Reason Vaccine Administered
( preferred
to https://healthterminologies.gov.au/fhir/ValueSet/reason-vaccine-administered-1
)
The codes SHOULD be taken from
Vaccination Target Disease
( preferred
to https://healthterminologies.gov.au/fhir/ValueSet/vaccination-target-disease-1
)
The codes SHALL be taken from For codes, see
Australian Medication
( required
to https://healthterminologies.gov.au/fhir/ValueSet/australian-medication-1
)
The codes SHOULD be taken from For example codes, see
Medication Form http://hl7.org/fhir/ValueSet/medication-form-codes
( preferred
to https://healthterminologies.gov.au/fhir/ValueSet/medication-form-1
)
The codes SHOULD be taken from For example codes, see
Reason for Request http://hl7.org/fhir/ValueSet/condition-code
( preferred
to https://healthterminologies.gov.au/fhir/ValueSet/reason-for-request-1
)
The codes SHOULD be taken from For example codes, see
Route of Administration http://hl7.org/fhir/ValueSet/route-codes
( preferred
to https://healthterminologies.gov.au/fhir/ValueSet/route-of-administration-1
)
The codes SHOULD be taken from
Medicine Substitution Reason
( preferred
to https://healthterminologies.gov.au/fhir/ValueSet/medicine-substitution-reason-1
)
The codes SHOULD be taken from For example codes, see
Medication Reason Taken http://hl7.org/fhir/ValueSet/condition-code
( preferred
to https://healthterminologies.gov.au/fhir/ValueSet/medication-reason-taken-1
)
When selecting a code for Organization type, if a system is unable to provide a code from the preferred value set Healthcare Organisation Role Type
because the implementation context is not restricted to healthcare practitioner providers then it is recommended to select from the wider set available in SNOMED CT. If a suitable code from SNOMED CT is not available, a code from the code system Australian and New Zealand Standard Industrial Classification (ANZSIC), 2006 (Revision 2.0)
may be used.
When selecting a code for Organization type, if a system is unable to provide a code from the preferred value set Healthcare Organisation Role Type
because the implementation context is not restricted to healthcare practitioner providers then it is recommended to select from the wider set available in SNOMED CT. If a suitable code from SNOMED CT is not available, a code from the code system Australian and New Zealand Standard Industrial Classification (ANZSIC), 2006 (Revision 2.0)
may be used.
The codes SHOULD be taken from For example codes, see
Healthcare Organisation Role Type http://hl7.org/fhir/ValueSet/organization-type
( preferred
to https://healthterminologies.gov.au/fhir/ValueSet/healthcare-organisation-role-type-1
)
Unless not suitable, these codes SHALL be taken from
Contact Relationship Type http://hl7.org/fhir/ValueSet/patient-contactrelationship
( extensible
to https://healthterminologies.gov.au/fhir/ValueSet/contact-relationship-type-3
)
Unless not suitable, these codes SHALL be taken from The codes SHOULD be taken from
Common Languages in Australia http://hl7.org/fhir/ValueSet/languages
( extensible
to https://healthterminologies.gov.au/fhir/ValueSet/common-languages-australia-2
)
Unless not suitable, these codes SHALL be taken from
Contact Relationship Type
( extensible
to https://healthterminologies.gov.au/fhir/ValueSet/contact-relationship-type-3
)
Unless not suitable, these codes SHALL be taken from
Common Languages in Australia
( extensible
to https://healthterminologies.gov.au/fhir/ValueSet/common-languages-australia-2
)
The individual's gender identity is populated in the extension:value.value[x]
of the Individual Gender Identity
extension and shall contain one of the codes from the Gender Identity Response
value set if any of the codes within the value set can apply.
The individual's pronouns are populated in the extension:value.value[x]
of the Individual Pronouns
extension and shall contain one of the codes from the Australian Pronouns
value set if any of the codes within the value set can apply.
The codes SHOULD be taken from For example codes, see
Practitioner Role http://hl7.org/fhir/ValueSet/practitioner-role
( preferred
to https://healthterminologies.gov.au/fhir/ValueSet/practitioner-role-1
)
The codes SHOULD be taken from
Clinical Specialty http://hl7.org/fhir/ValueSet/c80-practice-codes
( preferred
to https://healthterminologies.gov.au/fhir/ValueSet/clinical-specialty-1
)
Unless not suitable, these codes SHALL be taken from For example codes, see
Procedure http://hl7.org/fhir/ValueSet/procedure-code
( extensible
to https://healthterminologies.gov.au/fhir/ValueSet/procedure-1
)
Unless not suitable, these codes SHALL be taken from The codes SHOULD be taken from
Related Person Relationship Type http://hl7.org/fhir/ValueSet/relatedperson-relationshiptype
( extensible
to https://healthterminologies.gov.au/fhir/ValueSet/related-person-relationship-type-1
)
Unless not suitable, these codes SHALL be taken from
Related Person Relationship Type
( extensible
to https://healthterminologies.gov.au/fhir/ValueSet/related-person-relationship-type-1
)
Unless not suitable, these codes SHALL be taken from For codes, see
Smoking Status
( extensible
to https://healthterminologies.gov.au/fhir/ValueSet/smoking-status-1
)
Unless not suitable, these codes SHALL be taken from
Smoking Status
( extensible
to https://healthterminologies.gov.au/fhir/ValueSet/smoking-status-1
)
Australian Clinical Data for Interoperability (AUCDI)
is the product of a national clinician focussed requirements gathering project operating as part of the Sparked AU FHIR Accelerator
. The AUCDI outputs form a set of data requirements to be considered and referred to as part of the development and definition of AU Patient Summary.
Australian Clinical Data for Interoperability (AUCDI)
is the product of a national clinician focussed requirements gathering project operating as part of the Sparked AU FHIR Accelerator
. The AUCDI outputs form a set of data requirements to be considered and referred to as part of the development and definition of AU Patient Summary.
AUCDI Release 2 Patient Summary component – Draft for Community Comment
has been released for review. This component version of AUCDI contains only Patient Summary content to allow a focused review and support an iterative development process of AUCDI. A full AUCDI Release 2, which supersedes AUCDI Release 1, will be published in June 2025, containing all of the content from AUCDI Release 1 plus the content from this component release.
In addition to the examples defined in this implementation, synthetic (realistic but not real) test data for developers and testers that conforms to HL7 Australia FHIR implementation guides is maintained in the HL7 AU FHIR Test Data
repository.
The following examples demonstrate technical and clinical use case aspects, conforming to the AU Patient Summary requirements. Data within these examples, e.g. medications, is provided by the Sparked Patient Summary Clinical Focus Group
.
Supported by the PS CFG, the AU PS Project Team will develop a set of technical use cases and define the rules about how FHIR resources are used to deliver Australia Patient Summaries, with associated documentation to support and clarify usage. Success of this project will depend on active participation from members of the community who are looking to implement a patient summary capability in FHIR, whether you have already expressed your interest or are new to considering the AU Patient Summary project please complete this Registration form
or email Sparked@csiro.au to actively contribute to the development of the AU Patient Summary FHIR IG.
National Electrical Manufacturers Association ( NEMA
). This specification may reference content from DICOM, which is copyright NEMA, and distributed by agreement between NEMA/DICOM and HL7. Implementer use of DICOM is not covered by this agreement
The primary intent of the Australian Core Data for Interoperability (AUCDI)
is to design and govern a collection of coherent, reusable building blocks known as ‘data groups’. These data groups specify “what” the clinical requirements of the clinical information that should be included for data entry, data use, and sharing of information supporting healthcare delivery. However, it does not specify “how” the data is exchanged; this is the role fulfilled by the FHIR standard. AUCDI is not required to be implemented as a whole single product. Parts can be implemented as required for specific use cases.
Updates to AU Patient Summary depend upon community input and we encourage our audience to submit questions and feedback to AU Patient Summary specifications by clicking on the Propose a change link in the footer of every page. In addition, we encourage requesting any necessary clarifications to AUCDI through the AUCDI process
that helps inform future updates to AU Patient Summary.
The following example demonstrates both technical and clinical aspects of the use case, conforming to the AU Patient Summary requirements. Data within this example, e.g. medications, is provided by the Sparked Patient Summary Clinical Focus Group
:
The following examples demonstrate technical and clinical use case aspects, conforming to the AU Patient Summary requirements. Data within these examples, e.g. medications, is provided by the Sparked Patient Summary Clinical Focus Group
: