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, published by HL7 Australia. This guide is not an authorized publication; it is the continuous build for version 0.5.0-cibuild built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/hl7au/au-fhir-ps/ and changes regularly. 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
)
The content on this page is intended to address the need for jurisdictional patient summaries to (a) clarify whether they are based on the IPS and if they are (b) make it clear that their IPS summaries are proper IPS and (c) a reference to a section that describes the functional limitations of receiving an IPS document that does not conform to national expectations e.g. what is intended to happen or a possible problem if you are processing IPS documents that don't conform to the national specification. ( 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
)
AU Patient Summary Implementation Guide, published by HL7 Australia. This guide is not an authorized publication; it is the continuous build for version 0.5.0-cibuild built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/hl7au/au-fhir-ps/
and changes regularly. See the Directory of published versions
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
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
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
)
When populating Medication.code
producers SHALL
correctly populate Medication.code.coding
with either a code from Australian Medication
or PBS Item Codes
, or both, if a coded value is known and MAY
populate with a code from another code system.
Producers MAY
populate with only text if no coded value is known.
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
Medicine Substitution Reason
( preferred
to https://healthterminologies.gov.au/fhir/ValueSet/medicine-substitution-reason-1
)
When populating MedicationRequest.medicationCodeableConcept
producers SHALL
correctly populate MedicationRequest.medicationCodeableConcept.coding
with either a code from Australian Medication
or PBS Item Codes
, or both, if a coded value is known and MAY
populate with a code from another code system.
Producers MAY
populate with only text if no coded value is known.
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 populating MedicationStatement.medicationCodeableConcept
producers SHALL
correctly populate MedicationStatement.medicationCodeableConcept.coding
with either a code from Australian Medication
or PBS Item Codes
, or both, if a coded value is known and MAY
populate with a code from another code system.
Producers MAY
populate with only text if no coded value is known.
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 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)
and AU Patient Summary (AU PS) complement each other assisting in common understanding of clinical data concepts when implemented in systems and exchanged between systems.
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 PS requirements. Data within these examples, e.g. medications, is provided by the Sparked Patient Summary Clinical Focus Group
.
Within the AU PS
context (i.e. the Australian healthcare context), the Australian localised value sets, developed and published by the National Clinical Terminology Service
(NCTS) and the HL7 AU FHIR Working Group are preferred over IPS value sets to support the consumer on their healthcare journey in the AU healthcare context.
Obligations vary significantly for elements in the AU PS Composition profile, in particular obligations on Composition.section
reflect the expectations of The “IPS”
and ISO 27269
. A summary is provided below:
AU PS Producers SHALL
correctly populate Medication.code.coding
with either a code from Australian Medication
or PBS Item Codes
, or both, if a coded value is known. AU PS Producers MAY
populate with only text if no coded value is known.
AU PS Consumers SHALL
consume a Medication resource if Medication.code.coding
is present and containing any valid value. A valid value may be text, or may be a code from Australian Medication
or PBS Item Codes
, or both, or some other code. AU PS Consumers SHOULD
display the value of this element (if the SHOULD:display Obligation is defined) when presenting the data to a human user.
Options for access and exchange that have been discussed during AU PS meetings are briefly described in this guide with links to their source specifications. While recommendations on operations from IPS on generation are included in this guide, future implementation guides may provide alternative methods and further recommendations different than those outlined. In addition, Integrating the Healthcare Enterprise (IHE) has also published guidance on the IHE Sharing of IPS (sIPS)
which may be a helpful reference.
The DocumentReference and document Bundle transaction represents a simplified profile of the IHE MHD Provide Document Bundle [ITI-65]
transaction. The full ITI-65 specification also requires a List resource that provides document set metadata for all documents included in the transaction. This supports IHE Cross-enterprise Document Sharing (XDS) repository implementations where multiple documents or document attachments are submitted to a document store in a single transaction.
IHE provides an optional transaction profile, Simplified Publish [ITI-105]
. This transaction allows an AU PS Producer to create a DocumentReference resource containing a document Bundle instance that is base64-encoded and populated in DocumentReference.content.attachment.data
. It is the responsibility of the AU PS Producer to ensure that the metadata in the DocumentReference resource is populated in a way that supports document discovery via search.
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 PS project please complete this Registration form
or email Sparked@csiro.au to actively contribute to the development of the AU PS 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 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.
Systems SHOULD
use the Australian Cyber Security Centre (ACSC) TLS configuration guidelines
that include recommendations for configuring protocol features and acceptable cipher suites when implementing TLS.
A sample set of Consumer Journeys
, developed by the Sparked AU Patient Summary Clinical Focus Group, help illustrate the interactions and use of a patient summary during a consumer’s healthcare journey in the Australian healthcare context. These Consumer Journeys have been used to develop two example use cases
to assist implementers in understanding how AU PS could be implemented.
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
:
http://hl7.org/fhir/ValueSet/allergyintolerance-code
