Usage scenarios

The following are supported usage scenarios for this profile:

• Query for a patient’s allergies/adverse reactions
• Record or update a patient’s allergies/adverse reactions

Comparison with other national and international IGs

A resource conforming to this profile is conformant to:

• IPA-AllergyIntolerance
• US Core AllergyIntolerance
• and MAY be conformant to Allergy Intolerance (IPS) if patient is supported as AllergyIntolerance.patient.reference

Conformance in reverse is not guaranteed, i.e. a resource conforming to International Patient Access, International Patient Summary, or US Core MAY NOT conform to AU Core.

Profile specific implementation guidance

• AllergyIntolerance.verificationStatus is “unconfirmed” where a sending system does not clearly have this element or “confirmed” depending on the level of certainty
• To represent that a patient does not have an allergy or category of allergies, an appropriate negation code (e.g. 716186003 |No known allergy| or 716184000 |No known latex allergy|) is used in AllergyIntolerance.code
• The use of coding can vary significantly across systems, requesters need to understand that they may encounter codes they do not recognise and be prepared to handle those resources appropriately. Responders SHOULD populate AllergyIntolerance.code.text and/or AllergyIntolerance.code.coding.display so that requesters can at least display the condition even if the requester does not recognise the code supplied.
• Refutation is not expected to be handled except as above - an appropriate negation code in AllergyIntolerance.code and AllergyIntolerance.verificationStatus of “confirmed” or “unconfirmed”
• Where only substance is known (e.g. 111088007 |Latex|) and not a statement of allergy or intolerance (e.g. 300916003 |Allergy to latex|), the substance is sent in AllergyIntolerance.code

Below is an overview of the mandatory and optional search parameters and combined search parameters. See the AU Core CapabilityStatements for a complete list of supported RESTful interactions for this IG.

FHIR search operations are described here and the syntax used to describe AU Core interactions is defined here.

Any search parameter defined in FHIR may be ‘allowed’ by the system unless explicitly marked as “SHALL NOT”. A few items are marked as MAY in this implementation guide to highlight their potential relevance.

Mandatory Search Parameters

The following search parameters and search parameter combinations SHALL be supported:

1. SHALL support searching using the patient search parameter:
   • SHOULD support chained searching of patient canonical identifier patient.identifier (e.g. patient.identifier=[system|][code])

   GET [base]/AllergyIntolerance?patient={Type/}[id] or optionally GET [base]/AllergyIntolerance?patient.identifier=[system|][code]

   Example:

   1. GET [base]/AllergyIntolerance?patient=5678
   2. GET [base]/AllergyIntolerance?patient.identifier=http://ns.electronichealth.net.au/id/medicare-number|32788511952
   3. GET [base]/AllergyIntolerance?patient.identifier=http://ns.electronichealth.net.au/id/hi/ihi/1.0|8003608833357361

   Implementation Notes: Fetches a bundle of all AllergyIntolerance resources for the specified patient (how to search by reference and how to search by token)

Optional Search Parameters

The following search parameters and search parameter combinations SHOULD be supported:

1. SHOULD support searching using the combination of the patient and clinical-status search parameters:
   • SHOULD support chained searching of patient canonical identifier patient.identifier (e.g. patient.identifier=[system|][code])

   GET [base]/AllergyIntolerance?patient={Type/}[id]&clinical-status={system|}[code]{,{system|}[code],...}

   Example:

   1. GET [base]/AllergyIntolerance?patient=5678&clinical-status=http://terminology.hl7.org/CodeSystem/allergyintolerance-clinical

      active

   Implementation Notes: Fetches a bundle of all AllergyIntolerance resources for the specified patient and status (how to search by reference and how to search by token)