Quartz 4

FHIR Condition

draft
Not verified

Created · Updated 4 min read

Ресурс для диагнозов, проблем, симптомов и других «состояний пациента». От Observation отличается семантически: Condition — это утверждение что у пациента есть проблема, не измерение. Отдельные оси clinicalStatus (есть / разрешено / в ремиссии) и verificationStatus (подтверждено / предположение / опровергнуто) делают модель богаче чем у Observation.

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

  • Хроники из medical-context (T2DM, asthma, hypothyroidism, hypertension) — каждое состояние из narrative-разбора документа = одна Condition.
  • Источник — narrative-to-FHIR pipeline. LLM (промпт narrative_to_entities) extracted entities → ExtractedConditionSchema → buildCondition() в narrative-to-fhir/fhir-builders/condition.ts.
  • Связь с symptoms — symptoms сейчас идут в Observation с category: exam (см. narrative-to-fhir/fhir-builders/observation.ts:93), а не в Condition. Это design decision — Observation семантически больше про clinician’s exam findings, Condition про диагнозы.

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

  • subject — Patient/{id}
  • code — что это за состояние (CodeableConcept). SNOMED CT когда LLM-coder его нашёл (narrative-to-fhir/snomed-coder.ts), иначе только text. См. snomed.
  • clinicalStatus — текущее состояние во времени. Enum ["active", "inactive", "resolved", "remission", "recurrence", "relapse"] (FHIR R4 condition-clinical codesystem). LLM extracted в clinical_status по schema ClinicalStatusEnum.
  • verificationStatus — уверенность в том что диагноз правильный. Enum ["unconfirmed", "provisional", "differential", "confirmed", "refuted", "entered-in-error"] (FHIR R4 condition-ver-status codesystem). LLM extracted в verification_status. clinicalStatus и verificationStatus ОРТОГОНАЛЬНЫ — можно быть active (болезнь у пациента сейчас) + unconfirmed (но мы не уверены что это именно эта болезнь).
  • category — у нас всегда problem-list-item (hardcoded). См. ниже про rationale.
  • recordedDate — когда мы записали (наш ingest time)
  • onsetDateTime — когда болезнь началась у пациента (LLM extracted из narrative; null если не известно)
  • severity — необязательно, LLM extracted в severity enum ["mild", "moderate", "severe"]
  • bodySite — необязательно, как text если LLM нашёл

Default category: "problem-list-item" — почему

(Файл narrative-to-fhir/fhir-builders/condition.ts:77-95, явное rationale в комменте.)

«encounter-diagnosis semantically refers к Encounter ресурсу. Но мы Encounter из narrative-to-FHIR pipeline не emit’им — reference будет incoherent. Все хроники (T2DM, asthma, hypothyroidism, hypertension) принадлежат problem list пациента. US-Core compliant EHR’ы query Condition?category=problem-list-item чтобы populate problem lists; encounter-diagnosis записи там бы не нашлись».

Грамотное coding decision уже сделано — не сломать.

US-Core добавляет третью category health-concern для self-reported concerns (например, «беспокоит боль в спине» — пациент озвучил, врач ещё не диагностировал). У нас не используется, но open вопрос — нужен ли.

Защита от false-positive confirmed

Default verificationStatus для narrative-extracted conditions в нашей pipeline — обычно зависит от source. Patient-reported («у меня диабет») должен быть unconfirmed или provisional пока не подтверждено в documented источнике (выписка, лаб). Это та же семантика что для AllergyIntolerance — patient self-report не promoted в confirmed без verification language.

Carry-over: проверить точное поведение default’а — verification_status enum в extract-entities.ts schema, как промпт инструктирует выбирать между provisional / unconfirmed / confirmed для разных source’ов narrative.

Failure modes

  • Дубль с Observation — если LLM extracts «glucose elevated» одновременно как narrative diagnosis и как lab Observation, можно получить и Condition, и Observation для одного факта. RULE 9 в промпте narrative_to_entities это блокирует когда labTablePresent: true (есть структурированная лаб-таблица из VLM) — narrative MUST NOT emit category: laboratory Observations. Но Condition’ы не блокируются — open question.
  • recordedDate ≠ onsetDateTime — мы пишем recordedDate как наш ingest time, не как clinical event date. Для Timeline это будет означать что Condition появляется на shared (system) timeline в момент ingestion, а на clinical timeline — на onsetDateTime. Совместимо с two-timeline separation, см. [[../product/timeline-page-design]] когда напишется.

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

  • Использовать ли health-concern (US-Core) для self-reported concerns пациента, или хватает problem-list-item + verificationStatus: unconfirmed?
  • Default verificationStatus — какое значение по умолчанию выставляем для разных source’ов (patient-reported vs document-extracted vs doctor-recorded)?

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

  • [[../domain/category-coverage]] (TBD) — какие category вообще выставляем по resource’ам
  • [[../domain/fhir-resource-origin-and-lifecycle]] — Condition с origin = user-uploaded (выписка) vs ai-generated (наша интерпретация)

Связано

  • [[fhir-resource-categories]] — общая концепция category на ресурсах
  • [[fhir-observation]] — отличие observation vs condition (измерение vs утверждение)
  • [[fhir-allergy-intolerance]] — соседний resource с похожей моделью clinicalStatus + verificationStatus
  • snomed — coding system для Condition.code

Источники

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

Сноски

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

  2. ValueSet condition-category, accessed 2026-05-17, https://hl7.org/fhir/R4/valueset-condition-category.html. ↩

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

  4. ValueSet condition-ver-status, accessed 2026-05-17, https://hl7.org/fhir/R4/valueset-condition-ver-status.html. ↩

  5. US-Core Condition profile (с health-concern extension), accessed 2026-05-17, https://hl7.org/fhir/us/core/StructureDefinition-us-core-condition.html. ↩

Graph View

Backlinks