Concepts/Allergy & Intolerance: Difference between revisions

|fhir=Allergy & Intolerance

An '''allergy or intolerance''' records that a patient reacts badly to a particular substance — a food, a medication, an environmental trigger, or a biologic. It is the standing safety flag that warns clinicians before a harmful exposure happens, and lets the platform check new orders against what a patient cannot tolerate.

== What it represents ==

In Care's FHIR-aligned model, this maps to the '''AllergyIntolerance''' resource. Each record captures:

* '''The substance''' — a coded allergen drawn from a curated SNOMED CT list, not free text, so it can be matched against medications and other clinical logic

* '''Clinical status''' — whether the sensitivity is currently active, inactive, or resolved

* '''Verification status''' — how certain the assertion is, from unconfirmed through confirmed, or even refuted or entered in error

* '''Criticality''' — the potential for serious harm if the patient is exposed again

* '''Category and type''' — what kind of substance it is, and whether it is a true allergy or a non-immune intolerance

* '''Timing and notes''' — when it was first recorded, the most recent known reaction, structured onset details, and a free-text clinical note

An allergy record is an assertion about a ''risk'', not a log of a reaction that occurred. A single confirmed peanut allergy stays on the record over time even if the patient never reacts again — it is the patient's standing safety profile, distinct from a one-off [[Concepts/Observation]] or a documented [[Concepts/Condition]].

== Type and classification ==

Two distinctions shape how a record reads:

* '''Type''' — an '''allergy''' is an immune-mediated response; an '''intolerance''' is a non-immune adverse reaction (for example, lactose intolerance). The default is allergy.

* '''Category''' — the kind of substance: '''food''', '''medication''', '''environment''', or '''biologic'''. Category is set when the record is created and is fixed thereafter.

'''Criticality''' sits alongside these to express stakes — <code>low</code>, <code>high</code>, or <code>unable_to_assess</code> — answering &quot;how dangerous is the next exposure?&quot; rather than &quot;how sure are we this is real?&quot;, which is what verification status answers.

A record carries two independent status axes. Clinical status tracks whether the sensitivity is live; verification status tracks how trustworthy the assertion is.

<syntaxhighlight lang="text">Clinical status: active → inactive → resolved

Verification status: unconfirmed → presumed → confirmed

↘ refuted / entered_in_error</syntaxhighlight>

* '''active''' — the allergy is currently relevant to the patient's care

* '''inactive''' — no longer considered active, but kept for history

* '''resolved''' — the patient is believed to have outgrown or recovered from the sensitivity

* '''unconfirmed / presumed / confirmed''' — increasing levels of certainty that the allergy is real

* '''refuted''' — investigated and found not to be a genuine allergy

* '''entered_in_error''' — recorded by mistake; flagged so it no longer drives safety logic

These axes move independently: a record can be clinically <code>active</code> yet only <code>unconfirmed</code>, and a <code>refuted</code> allergy is kept rather than deleted so the decision is auditable.

== How it connects ==

* '''Patient''' — every allergy belongs to one [[Concepts/Patient|patient]] and is part of their standing clinical profile. The patient is derived automatically and is never set by the client.

* '''Encounter''' — each allergy is recorded against the [[Concepts/Encounter|encounter]] in which a clinician asserted it, anchoring it to a moment in the patient's timeline. Records are tied to both, so an allergy never outlives the patient or encounter it belongs to.

* '''Medications''' — because the substance is a code from a curated value set rather than free text, an allergy can be matched against a [[Concepts/Medication Request|medication request]] and other ordering logic, instead of relying on a clinician to read a note.

Allergy and intolerance records have no permission file of their own — as patient clinical data, they are governed by the '''patient''' and '''encounter''' permissions a user holds in the relevant facility. Recording an allergy is gated by write access to the patient; reading is allowed by the patient's clinical-data permission, or, failing that, by the encounter's clinical-data read permission for a specified encounter; editing is gated by write access to the encounter's clinical data.

! Description

! System Roles

| <code>can_write_patient</code>

| Create an allergy record — the create path checks write access to the patient

| Staff, Doctor, Nurse, Administrator, Admin, Facility Admin

| <code>can_view_clinical_data</code>

| View a patient's clinical data, including their allergies and intolerances

| Staff, Doctor, Nurse, Admin, Facility Admin

| <code>can_read_encounter_clinical_data</code>

| Read an encounter's clinical data — the fallback used to reach allergies when patient-level clinical access is absent, scoped to the matching encounter

| Admin, Doctor, Nurse, Facility Admin

| <code>can_write_encounter_clinical_data</code>

| Update an allergy record — the update path checks write access to its encounter's clinical data

| Admin, Doctor, Nurse, Facility Admin

Roles are granted to users through organization, facility, and patient memberships; permissions cascade down the organization tree, so a role held higher up applies to the facilities and patients beneath it.

== FHIR reference ==

This concept aligns with the FHIR '''AllergyIntolerance''' resource, which represents a clinician's assertion of a patient's propensity for an adverse reaction to a substance. Care follows its core structure — coded substance, clinical and verification status, criticality, category, and type.

Wiki: ohcnwiki.tellmey.fyi