Australian Digital Health Agency FHIR
1.2.0-ci-build - draft
Australian Digital Health Agency FHIR
1.2.0-ci-build - draft
Australian Digital Health Agency FHIR, published by Australian Digital Health Agency. This guide is not an authorized publication; it is the continuous build for version 1.2.0-ci-build built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/AuDigitalHealth/mcv/ and changes regularly. See the Directory of published versions
"Business" identifiers are used extensively in ADHA profiles to consistently identify real world entities across systems, contexts of use, and other formats (e.g. HL7 v2 , CDA , XDS, and many more).
For ADHA profiles, the following identifier elements are populated with business identifiers:
Device.identifierDiagnosticReport.identifierHealthcareService.identifierMedicationDispense.identifierMedicationRequest.identifierOrganization.identifierPatient.identifierRelatedPerson.identifierPractitioner.identifierPractitionerRole.identifierServiceRequest.identifierBusiness identifiers will typically be a national identifier (ABN, Medicare Provider, IHI), registry / exchange service identifier (ETP, eRx), or local identifier (MRN, Placer Identifier).
HL7 AU Australian Base Implementation 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. An identifier data element SHALL conform to the applicable HL7 AU Identifier profile.
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 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 their 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 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:
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/8003621566699776"
The value contains the local identifier, e.g.:
"value" : "AMC-GA-001"
The assigner contains the name of the organisation that issues or manages the identifier, e.g.:
assigner" : {
"display" : "Algregster Medical Center QLD"
}
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/8003621566699776",
"value" : "AMC-GA-001",
"assigner" : {
"display" : "Algregster Medical Center QLD"
},
...
}
ABN scoped identifier
ABN scoped identifiers enable exchange of an organisation's local identifiers for items such as a patient medical record by combining a dedicated 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:
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/004085616"
The value contains the local identifier, e.g.:
"value" : "123456"
The assigner contains the name of the organisation that issues or manages the identifier, e.g.:
assigner" : {
"display" : "Test Hospital Org 1"
}
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/004085616",
"value" : "123456",
"assigner" : {
"display" : "Test Hospital Org 1"
},
...
}
All Australian addresses SHOULD conform to the Australian Address profile.
References between resources in ADHA profiles are supported as reference (literal reference), identifier (logical reference), and display (text description of target).
ADHA profiles may include constraints on elements of Reference type that limit what is considered valid. For example, the profile ADHA Record of Claim against MBS or DVA limits what is considered valid for the element ExplanationOfBenefit.referral by mandating ExplanationOfBenefit.referral.reference to enforce population of a literal reference if the referral element is provided.
If an identifier (logical reference) is supplied, that identifier SHALL be populated with a meaningful business identifier according to the section on Business identifiers that identifies the logical entity across systems, contexts of use, and other formats (e.g. HL7 v2 , CDA , XDS, and many more).
References to a patient
References to a patient SHALL populate identifier and when applicable populate a reference to a Patient resource:
identifier SHOULD be populated with a verified IHIreference SHALL be populated and it SHALL resolveExample: Observation resource with a Reference to a Patient resource as identifier and reference
{
"resourceType" : "Observation",
...
"subject" : {
"reference" : "Patient/88923001",
"identifier" : {
"type" : {
"coding" : [
{
"system" : "http://terminology.hl7.org/CodeSystem/v2-0203",
"code" : "NI",
"display" : "National unique individual identifier"
}
],
"text" : "IHI"
},
"system" : "http://ns.electronichealth.net.au/id/hi/ihi/1.0",
"value" : "8003608000228445"
},
...
}
In some circumstances, the content referred to in the resource reference does not have an independent existence apart from the resource that contains it - it cannot be identified independently, and nor can it have its own independent transaction scope. For example, use of a Medication resource to represent medicinal product identification within the context of a MedicationRequest. In these circumstances the resource should be contained.
If referencing a contained resource, both the contained resource and the referencing resource SHALL conform to an ADHA profile. Further guidance about the general use case for contained resources can be found in the base FHIR specification.
In ADHA profiles:
There are situations when information for a particular data element is missing and the source system does not know the reason for the absence of data. If the source system does not have data for an element with a minimum cardinality = 0 (including elements labelled MustSupport), the data element SHALL be omitted from the resource. If the data element is a Mandatory element (in other words, where the minimum cardinality is > 0), it SHALL be present even if the source system does not have data. The core specification provides guidance for what to do in this situation, which is summarised below:
unknown where the value is expected to exist but is not known.Example: ExplanationOfBenefit resource where the patient's insurance coverage is not available
{
"resourceType" : "ExplanationOfBenefit",
...
"outcome" : "complete",
"insurance" : [
{
"focal" : true,
"coverage" : {
"extension" : [
{
"url" : "http://hl7.org/fhir/StructureDefinition/data-absent-reason",
"valueCode" : "unknown"
}
]
}
}
],
...
}
display element.unknown from the DataAbsentReason Code System.Example: AllergyIntolerance resource where the manifestation is unknown
...
"reaction" : [
{
"manifestation" : [
{
"coding" : [
{
"system" : "http://terminology.hl7.org/CodeSystem/data-absent-reason",
"code" : "unknown",
"display" : "unknown"
}
]
}
]
}
]
...
if the value set does not have the appropriate “unknown” concept code you must use a concept from the value set otherwise the instance will not be conformant.
AllergyIntolerance.clinicalStatus*Condition.clinicalStatus*Composition.statusDiagnosticReport.statusDocumentReference.statusExplanationOfBenefit.statusImmunization.statusList.status*The clinicalStatus element is conditionally mandatory based on resource specific constraints.
In some circumstances, specific pieces of data may be hidden due to security or privacy reasons. Elements with a minimum cardinality = 0 (including elements labelled MustSupport) SHALL be omitted from the resource if they are suppressed.
For mandatory elements (minimum cardinality is > 0), the element SHALL be populated but it may exceed the data receiver’s access rights to know that the data is suppressed:
masked from the DataAbsentReason Code System following the section on Missing data.unknown from the DataAbsentReason Code System following the section on Missing data.A sending system may send "additional" elements beyond those labelled with MustSupport in an ADHA profile. Additional elements allow local requirements to be reflected including technical and workflow context for the resource, and extending the health information supported in exchanges. For this reason extensibility is generally allowed in ADHA profiles, and only in some use case profiles are the rules tightened to limit the nature of additional information that can be sent.
Depending on local requirements, a receiving or persisting system may ignore these "additional" elements, may treat the data as for rendering only, or be capable of recognising and using the element. A resource exchanged containing an additional element SHALL conform to ADHA conformance requirements. Requirements applicable to handling "additional" elements are summarised below:
Orphaned resources, i.e. not referenced by an element in supported resource, SHALL NOT be allowed.
System obligations on handling additional elements are:
The FHIR standard defines the following resources for exchanging medicine information:
ADHA Core Medication is profiled to support medicinal product identification in an Australian healthcare context. ADHA profiles of MedicationStatement (with ADHA Core Medication) are used to support summary statements of medicine use. ADHA profiles of MedicationAdministration (with ADHA Core Medication) are used to support medication chart and other administration use cases. ADHA profiles of MedicationDispense (with ADHA Core Medication) are used to support to support dispense records and ePrescribing use cases. ADHA profiles of MedicationRequest (with ADHA Core Medication) are used to support prescription, ordering, and ePrescribing use cases.
Medicinal product identification
For extemporaneous medications, the medication code is the mandatory primary mechanism to identify a medicine but contain only a text list of ingredients or it may be a code from a medicines terminology.
For non-extemporaneous medications, the medication code (or set of codes) is the mandatory primary mechanism to identify a medicine and its defining attributes (by terminology lookup) including form and strength.
Australian Medicines Terminology (AMT) is the national terminology for identification and naming of medicines in clinical systems for Australia. The AMT is published monthly to include new items on the Australian Register of Therapeutic Goods from the TGA, as well as items listed on the Pharmaceutical Benefits Scheme. The AMT is published as part of SNOMED CT-AU (Australian edition of SNOMED CT) and can be downloaded in a variety of formats from the National Clinical Terminology Service (NCTS).
In addition to the medication code, the majority of use cases support exchange of structured medicine information as separate data elements covering brand name, generic name, item form and strength, and manufacturer.
These data elements may be supported as coded, or text, and systems are likely to use a combination of coded and text elements when constructing a Medication resource. The guidance for how to support coded or text is summarised below:
code.coding with Medication Type extension using BPD from the Medication Type code systemcode.coding with Medication Type extension using UPD from the Medication Type code systemcode.coding with Medication Type extension using UPDSF from the Medication Type code systemcode.coding with Medication Type extension using BPDSF from the Medication Type code systemform, ingredient.itemCodeableConcept and ingredient.strengthmanufacturer.identifierExample: Medication with coded brand name, generic name, manufacturer, item form and strength
{
"resourceType": "Medication",
...
"code": {
"coding": [
{
"extension": [
{
"url": "http://hl7.org.au/fhir/StructureDefinition/medication-type",
"valueCoding": {
"system": "http://terminology.hl7.org.au/CodeSystem/medication-type",
"code": "UPD",
"display": "Unbranded product with no strengths or form"
}
}
],
"system": "http://pbs.gov.au/code/item",
"code": "02647H",
"display": "BENZYLPENICILLIN"
},
{
"extension": [
{
"url": "http://hl7.org.au/fhir/StructureDefinition/medication-type",
"valueCoding": {
"system": "http://terminology.hl7.org.au/CodeSystem/medication-type",
"code": "BPD",
"display": "Branded product with no strengths or form"
}
}
],
"system": "http://snomed.info/sct",
"code": "3539011000036105",
"display": "Benpen"
},
{
"extension": [
{
"url": "http://hl7.org.au/fhir/StructureDefinition/medication-type",
"valueCoding": {
"system": "http://terminology.hl7.org.au/CodeSystem/medication-type",
"code": "UPDSF",
"display": "Unbranded product with strengths and form"
}
}
],
"system": "http://snomed.info/sct",
"code": "32753011000036104",
"display": "benzylpenicillin 3 g injection, 1 vial"
},
{
"extension": [
{
"url": "http://hl7.org.au/fhir/StructureDefinition/medication-type",
"valueCoding": {
"system": "http://terminology.hl7.org.au/CodeSystem/medication-type",
"code": "BPDSF",
"display": "Branded product with strengths and form"
}
}
],
"system": "http://snomed.info/sct",
"code": "32328011000036106",
"display": "Benpen 3 g powder for injection, 1 vial"
}
]
},
"manufacturer": {
"identifier": {
"system": "http://pbs.gov.au/code/manufacturer",
"value": "CS"
}
},
"form": {
"coding": [
{
"system": "http://snomed.info/sct",
"code": "129011000036109",
"display": "injection"
}
],
"text": "Injection"
},
"ingredient": [
{
"itemCodeableConcept": {
"coding": [
{
"system": "http://snomed.info/sct",
"code": "1849011000036104",
"display": "benzylpenicillin"
}
]
},
"strength": {
"numerator": {
"value": 3,
"unit": "g"
},
"denominator": {
"value": 1,
"unit": "unit"
}
}
}
]
}
code.textmanufacturer.displayExample: Medication with text only brand name, generic name, item form and strength
{
"resourceType": "Medication",
...
"extension": [
{
"url": "http://hl7.org.au/fhir/StructureDefinition/medication-generic-name",
"valueString": "Benzylpenicillin"
},
{
"url": "http://hl7.org.au/fhir/StructureDefinition/medication-brand-name",
"valueString": "Benpen"
}
],
"code": {
"text": "Benpen 3 g powder for injection, 1 vial"
},
"manufacturer": {
"display": "Seqirus"
}
}
Patient
The table below provides guidance on representing communication preferences for a patient. Blank cells in the table indicate that the given element is absent from the resource.
| Scenario | communication.language | communication.preferred | extension:interpreterRequired | Notes |
|---|---|---|---|---|
| Preferred language is English | No element sent, as per the guidance in the Comments of Patient.communication | |||
| Preferred language is other than English | language.coding | 'true' | ||
| Interpreter required, language is known | language.coding | 'true' | 'true' | |
| Interpreter required, language is not known | 'true' | |||
| Interpreter is not required | 'false' | |||
| Communicates with multiple languages | language.coding | Each language instantiated in separate communication nodes; communication.preferred and extension:interpreterRequired may be sent as needed. |
Example: Patient resource with interpreter required and language is known
{
"resourceType" : "Patient",
...
"extension" : [
{
"url" : "http://hl7.org/fhir/StructureDefinition/patient-interpreterRequired",
"valueBoolean" : true
}
]
},
...
"communication" : [
{
"language" : {
"coding" : [
{
"system" : "urn:ietf:bcp:47",
"code" : "yue"
}
],
"text" : "Cantonese"
},
"preferred" : true
}
]
}
RelatedPerson
The table below provides guidance on representing communication preferences for a related person. Blank cells in the table indicate that the given element is absent from the resource.
| Scenario | communication.language | communication.preferred | Notes |
|---|---|---|---|
| Preferred language is English | No element sent, as per the guidance in the Comments of RelatedPerson.communication | ||
| Preferred language is other than English | language.coding | 'true' | |
| Communicates with multiple languages | language.coding | Each language instantiated in separate communication nodes; communication.preferred may be sent as needed. |
IG © 2023+ Australian Digital Health Agency. Package au.digitalhealth.r4#1.2.0-ci-build based on FHIR 4.0.1. Generated 2024-09-16
Links: Table of Contents |
QA Report
| Version History
| Report an issue or propose a change
