The recording of allergy and intolerance information in patient records is a major component of communicating the effects of external substances and compounds on patient health.
Note: Guidance replicated from that published for GPConnect.
The allergy and intolerance concept is broad and multi-dimensional:
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.
The following are expected use cases for the UK Core AllergyIntolerance profile:
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.
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.
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.
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.
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.
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.
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" } ] } }
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" } } } }
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.
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. }
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. }
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.
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
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
Refer to the Examples Index in this implementation guidance.
Out of scope for this version of UK Core.