Introduction

Note: Guidance replicated from that published for GPConnect.

The allergy and intolerance concept is broad and multi-dimensional:

• the causation of allergy and intolerance may be linked to specific medications or pharmaceuticals or substances (biological or chemical) in the environment
• the weight and significance that may be attached to recorded allergy or intolerance is affected by a number of factors including the certainty, the severity of the reaction and the likelihood of occurrence
• allergies and intolerances may be linked to other clinical events, such as diagnostic tests that confirm the presence of the allergy or intolerance or linked to instances of illness caused by the allergy or intolerance
• allergies and intolerances may be dynamic and evolving, increasing in severity over time, recurrent or perhaps only active and observed within defined periods.

The recording and handling of allergy and intolerance information has an important role to play in patient safety, not only with regard to clinical decision making, but also in the realm of prescribing decision support, where the presence of allergy information linked to causative agents can trigger automated alerts and restrictions when prescribing.

Given the complexity and depth of the allergy and intolerance domain there are significant differences and variations in the implementation of the allergy and intolerance concept across participating systems in terms of structure, terminology and the linkages between terminology and decision support. These differences limit the current interoperability of allergies and intolerances.

The AllergyIntolerance resource aims to improve the interoperability of allergies and intolerances through convergence towards a standardised structure and common terminology.

The clinical importance of allergy and intolerance information coupled with the variability of implementations across participating systems means that there is a need for clear guidance on the utilisation of the AllergyIntolerance resource by both providers and consumers.

Use Cases

The following are expected use cases for the UK Core AllergyIntolerance profile:

• Query for patient allergy information
• Exchange patient allergy information within a FHIR Document or FHIR Message
• Migration of allergies data between systems.

Use Case: Query

The query against a clinical system or shared record to return recorded allergies as AllergyIntolerance resources.

Returned results could be ordered by recordedDate and/or lastOccurence.

Returned results may include multiple instances of the same allergy, as per the causative agent (code), but with different clinicalStatus values. The newer of such records either by recordedDate or lastOccurence should be deemed the latest or current record of the allergy.

Use Case: Exchange

For when systems need to exchange allergy information within a point-to-point message. The AllergyIntolerance resources can be included within a FHIR Message (within the Bundle), or within a FHIR Document alongside other structured resources and text-based data.

To align with the published NHS Data Strategy, allergy information should not be duplicated between systems. When exchanging allergies data between systems be mindful of whether the receiving system plans to persist the data. If persisted, processes must be put in place to ensure the data is updated if/when the source record is updated.

Use Case: Migration

When allergy records are migrated between systems, the AllergyIntolerance resource could be used as a data migration standard.

Where migrated data is not coded, uses retired / invalidated codes, or coded with a terminology which cannot be mapped to SNOMED-CT, then refer to the guidance on using degraded drug / non-drug allergy codes.

Degraded Allergy Codes

Note: Guidance replicated from that published for GPConnect

It is recognised that allergy/intolerance information may not be fully interoperable between participating systems. Where allergy/intolerance information is not fully understood by a receiving system then it is the responsibility of the consumer to mitigate any risks arising and make related workflows as safe as possible.

Where allergy/intolerance information is integrated into the consuming system patient record then allergy/intolerance information MUST be degraded where the coded allergy/intolerance information is not fully understood by the consumer. In the context of drug allergies, an allergy/intolerance is only understood if the coded causative agent triggers equivalent prescribing decision support to that triggered on the producing system.

Degradation can be handled by coding the record entries resulting from the processed allergy as a 196461000000101 | transfer-degraded drug allergy (record artifact) or a 196471000000108 | transfer-degraded non-drug allergy (record artifact) preserving the original term for the received code as text.

XML

<code>
  <coding>
    <system value="http://snomed.info/sct"/>
    <code>196471000000108</code>
    <display>transfer-degraded non-drug allergy(record artifact)</display>
  </coding>
  <text>Latex</text>
</code>

JSON

{
"code": {
        "coding":  [
            {
                "system": "http://snomed.info/sct",
                "code": "196471000000108",
                "display": "transfer-degraded non-drug allergy(record artifact)"
            }
        ],
        "text": "Latex"
    }
    

Where the processing of an AllergyIntolerance resource results in degradation, or the FHIR resource is already coded as a degrade drug allergy code, then the consuming system MUST prevent prescribing while degraded drug allergies are present in the patient record and MUST inform users attempting prescribing actions that prescribing is being prevented due to the presence of degraded drug allergies.

In other contexts, task-based workflows have been utilised to assist users on consuming systems to process degraded drug allergies by re-coding them to concepts understood by the consuming system.

When considering the implementation of interoperability for use cases involving allergy/intolerance, suppliers MUST perform an appropriate clinical safety assessment and obtain the necessary clinical safety approvals for the processing performed by their system.

Negation - Handling of 'No known allergies'

There can be an explicit assertion of ‘No Known Allergies’ using the SNOMED 'No known allergy' hierarchy 716186003 | No known allergy, that contains six child concepts. The parent concept, or any child concept may be used.

XML

<code>
  <coding>
    <system>http://snomed.info/sct</system>
    <code>409137002</code>
    <display>No known drug allergy (situation)</display>
  </coding>
</code>

JSON

{
"code": {
        "coding":  [
            {
                "system": "http://snomed.info/sct",
                "code": "409137002",
                "display": "No known drug allergy (situation)"
            }
        ]
    }
}

If other AllergyIntolerance resources exist in the patient record with a clinicalStatus of active then the system must ignore the 'No Known Allergies' resource instance. The existence of recorded and active allergies takes precedence over instances of 'No Known Allergies' records.

Handling No Allergy Records

Where there are no AllergyIntolerance resources in the patient record, including none stating ‘No Known Allergies’ it is the responsibility of the provider system to make this clear to consumer systems.

Presenting no allergy information using a FHIR List

Where the provider system is returning allergy information within a FHIR List then the provider system MUST return an empty List with an emptyReason FHIR code: “No content recorded” and a List.note with the text: "Information not available". This aligns with the implementation used by GPConnect.

<list>
  <id>UKCore-NoAllergyData-List-Example</id>
  <meta>
    <profile>https://fhir.hl7.org.uk/StructureDefinition/UKCore-List</profile>
  </meta>
  <status>current</status>
  <mode>snapshot</mode>
  <code>
    <coding>
      <system>http://snomed.info/sct</system>
      <code>886921000000105</code>
      <display>Allergies and adverse reactions</display>
    </coding>
  </code>
  <patient>
    <reference>Patient/UKCore-Patient-RichardSmith-Example</reference>
    <display>Richard Smith</display>
    <identifier>
      <system>https://fhir.nhs.uk/Id/nhs-number</system>
      <value>9912003888</value>
    </identifier>
  </patient>
  <date>2021-07-21T12:00:00+00:00</date>
  <emptyReason>
    <coding>
      <system>https://fhir.hl7.org.uk/CodeSystem/UKCore-ListEmptyReasonCode</system>
      <code>no-content-recorded</code>
      <display>No Content Recorded</display>
    </coding>
  </emptyReason>
  <note>
    <text>Information not available</text>
  </note>
</list>

JSON

{
  "resource": {
    "resourceType": "List",
    "id": "UKCore-NoAllergyData-List-Example",
    "meta": {
      "profile": [
      "https://fhir.hl7.org.uk/StructureDefinition/UKCore-List"
      ]
    },
    "status": "current",
    "mode": "snapshot",
    "code": {
      "coding": [
        {
          "system": "http://snomed.info/sct",
          "code": "886921000000105",
          "display": "Allergies and adverse reactions"
        }
      ]
    },
    "patient": {
      "reference": "Patient/UKCore-Patient-RichardSmith-Example",
      "display": "Richard Smith",
      "identifier": [
        {
          "system": "https://fhir.nhs.uk/Id/nhs-number",
          "value": "9912003888"
        }
      ]
    },
    "date": "2021-07-21T12:00:00+00:00",
    "emptyReason": {
      "coding": [
        {
          "system": "https://fhir.hl7.org.uk/CodeSystem/UKCore-ListEmptyReasonCode",
          "code": "no-content-recorded",
          "display": "No Content Recorded"
        }
      ]
    },
    "note": [
      {
        "text": "Information not available"
      }
    ]
  }
}

Presenting no allergy information using a FHIR Bundle

Where the provider system is returning allergy information within a FHIR Bundle then, without extending the FHIR standard, provider systems should return as per the following;

XML

<Bundle>
	<id value="UKCore-NoAllergyData-Bundle-Example"/>
	<meta>
		<lastUpdated value="2021-07-21T12:00:00+00:00"/>
	</meta>
	<type value="searchset"/>
	<total value="0"/>
	<link>
		<relation value="self"/>
		<url value="https://[base]/AllergyIntolerance?patient%3Aidentifier=9912003888"/>
	</link>
</Bundle>

JSON

{
   "Bundle": {
      "id": {
         "_value": "UKCore-NoAllergyData-Bundle-Example"
      },
      "meta": {
         "lastUpdated": {
            "_value": "2021-07-21T12:00:00+00:00"
         }
      },
      "type": {
         "_value": "searchset"
      },
      "total": {
         "_value": "0"
      },
      "link": {
         "relation": {
            "_value": "self"
         },
         "url": {
            "_value": "https://[base]/AllergyIntolerance?patient%3Aidentifier=9912003888"
         }
      }
   }
}

Create

The adoption of a common POST API syntax would allow the same software to, for example, POST a FHIR resource point-to-point to a dispensing system, or a FHIR resource to a shared records service.

Create using FHIR RESTful architecture

When POSTing a FHIR resource using a RESTful API use;

POST [base]/{resource}

For example;

POST https://myfhirserver.net/AllergyIntolerance

with a body containing a single FHIR resource. Other resources referenced must be referenced with valid identifier values to allow the consumer system to locate those resources from either the same or another FHIR server.

{
    "resourceType": "AllergyIntolerance",
    "identifier": "a54219b8-f741-4c47-b662-e4f8dfa49ab6"
    // etc.
}

Create using FHIR Messaging architecture

When POSTing a FHIR Message use;

POST [base]/$process-message

with a body containing a FHIR Bundle within which is a FHIR MessageHeader resource and multiple other FHIR resources.

{
  "resourceType": "Bundle",
  "id": "0A1FD9EF-A3D5-4E95-84CD-552070A03083",
  "identifier": {
    "system": "https://tools.ietf.org/html/rfc4122",
    "value": "34470bbf-07cb-4b49-bef9-f958114f821f"
  },
  "type": "message",
  "entry": [
    {
      "fullUrl": "urn:uuid:0A1FD9EF-A3D5-4E95-84CD-552070A03083",
      "resource": {
        "resourceType": "MessageHeader",
        "id": "0A1FD9EF-A3D5-4E95-84CD-552070A03086",
        "eventCoding": { }, // etc.
        "sender": { }, // etc.
        "source": { }, // etc.
        "destination": { } // etc.
        }
    },
    {
      "fullUrl": "urn:uuid:a54219b8-f741-4c47-b662-e4f8dfa49ab6",
      "resource": {
        "resourceType": "AllergyIntolerance",
        "identifier": "a54219b8-f741-4c47-b662-e4f8dfa49ab6"
        // etc.
}

Read

The adoption of a common GET API syntax to read a specific resource or search a FHIR server would allow the same software to, for example, read a FHIR resource from a GP system or read a FHIR resource from shared records service. The query syntax can be the same for both use cases (or workflows), using a different base URL technical end-point.

GET by 'identifier'

To query a FHIR server for a specific resource by identifier;

GET [base]/{resource}?identifier={value}

For example;

GET https://myfhirserver.net/AllergyIntolerance?identifier=a54219b8-f741-4c47-b662-e4f8dfa49ab6

GET by 'identifier', such as NHS Number

To query a FHIR server for a specific resources for a given patient;

GET [base]/{resource}?patient:identifier=https://fhir.nhs.uk/Id/nhs-number|{NHS_Number}

For example;

GET https://myfhirserver.net/AllergyIntolerance?patient:identifier=https://fhir.nhs.uk/Id/nhs-number|123543254

Search Results

Refer to the Examples Index in this implementation guidance.

Update

Out of scope for this version of UK Core.

Refer to clinicalStatus for related guidance.

Delete

Out of scope for this version of UK Core.