Ресурс для аллергий и непереносимостей. От Condition отличается тем, что связан с конкретным веществом (substance) которое триггерит реакцию, а не с состоянием пациента. У нас — каждая аллергия / непереносимость из narrative-разбора документа = одна AllergyIntolerance.

Использование в BloodGPT

  • Источник — narrative-to-FHIR pipeline. LLM (промпт narrative_to_entities) extracted entities → ExtractedAllergySchemabuildAllergyIntolerance() в narrative-to-fhir/fhir-builders/allergy-intolerance.ts.
  • Critical safety field — verificationStatus — patient-reported allergies MUST default к unconfirmed. См. ниже.
  • Closed-enum categoryfood / medication / environment / biologic. Все 4 значения R4 поддерживаются LLM-extracted enum.

Ключевые поля для нас

  • patientPatient/{id} (внимание: поле называется patient, не subject как у Observation/Condition)
  • code — substance что триггерит реакцию (CodeableConcept). SNOMED CT когда coder его нашёл, иначе только text.
  • categoryfood / medication / environment / biologic. Closed enum — нельзя custom-coding (поле примитивного типа code, не CodeableConcept). Из LLM enum AllergyCategoryEnum (все 4 значения R4).
  • clinicalStatus — текущий статус. Enum ["active", "inactive", "resolved"] (AllergyClinicalStatusEnum). Default "active", "resolved" только когда narrative explicit («outgrew penicillin allergy», «allergy resolved per challenge test»).
  • verificationStatus — уверенность что аллергия реальная. Enum ["unconfirmed", "confirmed", "refuted", "entered-in-error"] (AllergyVerificationStatusEnum). Default — unconfirmed. См. ниже.
  • typeallergy (IgE-mediated) или intolerance (non-immune, например лактоза, сульфиты). LLM extracted, может быть null когда narrative не disambiguates.
  • criticalitylow / high / unable-to-assess. У нас mapping из severity (mild → low, severe/moderate → high).
  • reaction[] — список реакций. У нас manifestation: [{ text }] + severity (mild / moderate / severe).
  • recordedDate — наш ingest time

Default verificationStatus: "unconfirmed" — clinical safety

(Файл narrative-to-fhir/fhir-builders/allergy-intolerance.ts:33-47 + schema 67-77 с явным rationale.)

Patient-reported «у меня в детстве была сыпь от пенициллина» не должно promoted в confirmed без explicit verification language. False-positive confirmed allergy в EHR — documented driver suboptimal prescribing (Macy E, Contreras R, 2014, JACI 133(3):790).

confirmed reserved для explicit clinical verification:

  • «skin-prick positive»
  • «IgE-confirmed»
  • «allergist diagnosed»
  • «documented anaphylaxis»
  • «RAST positive»

refuted — для narrative что explicitly негирует ранее сообщённую аллергию: «previously reported penicillin allergy ruled out via challenge test».

Это паттерн который нам стоит распространить на другие resource’ы (Condition, MedicationStatement) — particularly при self-reported данных от пациента.

clinicalStatus vs verificationStatus — ортогональность

Можно быть:

  • active + unconfirmed — пациент сейчас реагирует на что-то, но мы не уверены что это эта substance
  • active + confirmed — врач подтвердил, аллергия активна
  • inactive + confirmed — аллергия была подтверждена, сейчас нет реакции (например выходит сезонная)
  • resolved + confirmed — пациент перерос
  • (любой) + entered-in-error — запись по ошибке, удалить нельзя но можно flag’нуть

Failure modes

  • Closed enum не покрывает все случаи — например, lifestyle-related sensitivities (caffeine, gluten без celiac diagnosis) не попадают чисто ни в food (это технически тоже food) ни как allergy. LLM в таких случаях скорее всего выберет food с type: intolerance. Open вопрос — extension с более тонкой классификацией.
  • Severity → criticality mapping не идеаленmildlow это безопасно, но moderatehigh дискуссионно. Anaphylaxis всегда high независимо от severity narrative.

Открытые вопросы

  • Расширять ли через extension для drug-class категоризации (NSAIDs / beta-lactams / opioids)? FHIR R4 не даёт стандартного способа на этом resource.
  • Auto-promote в confirmed если документ — discharge summary с подписью врача? Или всё-таки требовать explicit verification language?

Связанные решения

  • [[../domain/category-coverage]] (TBD) — overall category strategy
  • [[../domain/fhir-resource-origin-and-lifecycle]] — origin tag (user-uploaded vs document-extracted)

Связано

  • [[fhir-resource-categories]] — общая концепция category на ресурсах + closed-enum особенность
  • [[fhir-condition]] — соседний resource с похожей моделью двух статусов
  • snomed — substance coding (через narrative-to-fhir/snomed-coder.ts)

Источники

Источники: 1 2 3 4.

Сноски

  1. HL7 R4 spec, accessed 2026-05-17, https://hl7.org/fhir/R4/allergyintolerance.html.

  2. ValueSet allergy-intolerance-category (closed), accessed 2026-05-17, https://hl7.org/fhir/R4/valueset-allergy-intolerance-category.html.

  3. ValueSet allergyintolerance-clinical, accessed 2026-05-17, https://hl7.org/fhir/R4/valueset-allergyintolerance-clinical.html.

  4. ValueSet allergyintolerance-verification, accessed 2026-05-17, https://hl7.org/fhir/R4/valueset-allergyintolerance-verification.html.