This page is part of the AU Core (v0.4.1-preview: QA Preview) based on FHIR (HL7® FHIR® Standard) R4. . For a full list of available versions, see the Directory of published versions

General Guidance

Contained Resources

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 can be contained.

In AU Core profiles:

• Systems constructing a resource that represent medication information are encouraged to make use of contained resources within the context of a FHIR transaction. Operations on Medication resources are expected to be within the context of a referencing resource query such as an MedicationAdministration, MedicationDispense, MedicationRequest or MedicationStatement.
• If referencing a contained resource, both the contained resource and the referencing resource SHALL conform to the applicable AU Core profile.
• Otherwise, when responding to a query, it is recommended that servers avoid using inline contained resources to represent the returned data.

Further guidance about the general use case for contained resources can be found in the base FHIR specification.

Extensibility – “additional” elements

A server may send “additional” elements beyond those flagged with Must Support in an AU Core profile. Additional elements are often required by other profiles the system may conform to, allowing local requirements, including technical and workflow context for the resource, to be reflected and extending the health information supported in exchanges. For this reason, extensibility is generally encouraged and expected in AU Core profiles. Only in some exceptionally rare use case profiles are rules tightened to limit the nature of additional information that can be sent. Specification authors should strive to enable greater interoperability and software re-use by not reducing an element’s cardinality.

Depending on local requirements, a client application may ignore these “additional” elements, may treat the data as for rendering only, or be capable of recognising and using the element.

Representing communication preferences

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.

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
    }
  ]
}

Read/Search Syntax

Searching resources is defined by the FHIR RESTful API and included here for informative purposes. The AU Core CapabilityStatements document the server and client rules for the RESTful interactions described in this guide.

All the search interactions in this guide use the GET command with the following syntax:

GET [base]/[Resource-type]?[parameter1]{:m1|m2|...}={c1|c2|...}[value1{,value2,...}]{&[parameter2]{:m1|m2|...}={c1|c2|...}[value1{,value2,...}]&...}

• GET is the HTTP verb used for fetching a resource
• Variables surrounded by “[]” are mandatory for the client to supply and will be replaced by the string literal identified.
• Variables surrounded by “{}” are optional for the client to supply and will be replaced by the string literal identified.
• Variables:
  • base: The Service Root URL (e.g., “https://fhir-open-api-dstu2.smarthealthit.org”)
  • Resource-type: The name of a resource type (e.g., “Patient”)
  • parameter: the search parameters as defined for the particular interaction (e.g.,”?patient=Patient/123”)
  • value: the search parameter value for a particular search
    • When searching using the token type SearchParameter (how to search by token), the syntax {system|}[code] means that the system value is optional for the client to supply.:
    • When searching using the reference type SearchParameter (how to search by reference), the syntax {Type/}[id] means that the Type value is optional for the client to supply:
    • When searching using the date type SearchParameter (how to search by date), the syntax {gt|lt|ge|le}[date] means the date comparators “gt”, “lt”, “ge”, and “le” are optional. Date type searches without a comparator prefix are equivalent to searches with the “eq” comparator even if a server does not support the comparator.
  • {:m1|m2|…}: The list of supported search parameter modifiers
  • {c1|c2|…}: The list of supported search parameter comparators
  • {,value2,…}: Optional multiple ‘OR’ Values
  • {&parameter2={:m1|m2|…}={c1|c2|…}[value1{,value2,…}&…}: Optional multiple ‘AND’ search parameters

In the simplest case, a search is executed by performing a GET operation in the RESTful framework:

GET [base]/[Resource-type]?name=value&...

For this RESTful search, the parameters are a series of name=[value] pairs encoded in the URL. The search parameter names are defined for each resource. For example, the Observation resource has the name “code” for searching on the LOINC or SNOMED CT-AU code. For more information, see the FHIR RESTful Search API.