Concepts/Allergy & Intolerance: Difference between revisions

Content deleted Content added

Inline

Latest revision as of 09:29, 6 July 2026

conceptclinicalFHIR: Allergy & IntoleranceCARE 3.0+

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 — low, high, or unable_to_assess — answering "how dangerous is the next exposure?" rather than "how sure are we this is real?", which is what verification status answers.

Lifecycle

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

Clinical status:      active → inactive → resolved
Verification status:  unconfirmed → presumed → confirmed
                                 ↘ refuted / entered_in_error

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 active yet only unconfirmed, and a refuted allergy is kept rather than deleted so the decision is auditable.

How it connects

Patient — every allergy belongs to one 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 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 medication request and other ordering logic, instead of relying on a clinician to read a note.

Permissions

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.

Permission	Description	System Roles
`can_write_patient`	Create an allergy record — the create path checks write access to the patient	Staff, Doctor, Nurse, Administrator, Admin, Facility Admin
`can_view_clinical_data`	View a patient's clinical data, including their allergies and intolerances	Staff, Doctor, Nurse, Admin, Facility Admin
`can_read_encounter_clinical_data`	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
`can_write_encounter_clinical_data`	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.

Concept: Concepts/Observation
Reference: References/Allergy Intolerance

Wiki: ohcnwiki.tellmey.fyi

@@ Line 89: / Line 89: @@
 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.
+{{Navbox clinical}}
 {{Related}}
+Wiki: ohcnwiki.tellmey.fyi