Australian Digital Health Agency FHIR Implementation Guide
1.2.0-ci-build - draft
Australian Digital Health Agency FHIR Implementation Guide
1.2.0-ci-build - draft
Australian Digital Health Agency FHIR Implementation Guide, 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/ci-fhir-r4/ 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.
TBD: Insert guidance.
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 Document Composition limits what is considered valid for the element Composition.section.entry by mandating Composition.section.entry.reference to enforce population of a literal reference for each entry.
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 for 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).
TBD: Insert PBS.
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"
}
}
TBD: Insert guidance.
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. |
Blank cells in the above table indicate that the given element is absent from the resource.
In some uses cases the source of the information to be provided in a FHIR R4 resource is a different HL7 format or earlier version of FHIR.
TBD - conformance rules
terminology canonical url - transforming data from OID based a. Convert system OID for ANZSCO urn:oid:2.16.840.1.113883.13 to url http://www.abs.gov.au/ausstats/abs@.nsf/mf/1220.0 b. Convert system OID for PBS Manufacturer urn:oid:1.2.36.1.2001.1005.23 to url http://pbs.gov.au/code/manufacturer c. Convert system OID for Australian Immunisation Register Vaccine urn:oid:1.2.36.1.2001.1005.17 to url https://www.humanservices.gov.au/organisations/health-professionals/enablers/air-vaccine-code-formats
Handling introduction of new mandatory elements in a FHIR R4 resource in order of precedent: a. Direct population with data from the STU3 payload if possible b. Population with an appropriate fixed value as demonstrated in Coverage.insurer and Coverage.scope c. Only where neither of the above options is possible is the data to be handled as ‘missing data’
RIM Concept Descriptor (CD) to FHIR CodeableConcept
Converting from a data element of type RIM CD (source) data type to FHIR CodeableConcept data type (target).
The following CD attributes have no equivalent counterpart in CodeableConcept and are subject to complex rules: nullFlavor, displayName, and qualifier.
qualifier SHALL be handled using business rules to support a use case e.g. laterality for body sites.
If source nullFlavor is present:
nullFlavor if both source code and codeSystem exist or source originalText existscode and codeSystem using unknown from the DataAbsentReason Code System
Copy source originalText to target text.Ignore invalid codings, i.e. if source codeSystem does not exist, ignore source code, displayName and translation.
Convert valid codings:
code to target codecodeSystem to target system: coding.system = translate(system, ‘http://hl7.org/fhir/ConceptMap/special-oid2uri’, ‘uri’)codeSystemNamecodeSystemVersion to target versiondisplayName:
a. ignore if source originalText is present, otherwise copy source displayName to target text
b. if target display is mandatory in the FHIR resource then populate target display using terminology service lookuptranslation to target coding:
a. ignore invalid codings
b. convert valid codings
IG © 2023+ Australian Digital Health Agency. Package au.digitalhealth.r4#1.2.0-ci-build based on FHIR 4.0.1. Generated 2024-04-18
Links: Table of Contents |
QA Report
| Version History
| Report an issue or propose a change
