Admin: Automated edit (via update-page on MediaWiki MCP Server)

2026-07-06T03:59:52Z

Automated edit (via update-page on MediaWiki MCP Server)

← Older revision		Revision as of 09:29, 6 July 2026
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.		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}}		{{Related}}
			Wiki: ohcnwiki.tellmey.fyi

Admin: OHC identity seed

2026-07-04T22:43:06Z

OHC identity seed

New page

{{Doc header
|type=concept
|domain=clinical
|title=Allergy & Intolerance
|order=4
|introduced=3.0
|fhir=Allergy & Intolerance
|concept=Concepts/Observation
|reference=References/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 "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.

<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.

== 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.

{| class="wikitable"
|-
! Permission
! 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.

{{Related}}

Concepts/Allergy & Intolerance - Revision history

Admin: Automated edit (via update-page on MediaWiki MCP Server)

Admin: OHC identity seed